excel双击打开csv时自动将长数字识别为数值导致精度丢失，正确做法是用“从文本/csv”导入向导并手动设列为文本，或在sql中用concat加制表符/单引号等方式强制转文本。
这不是 navicat 的问题，是 excel 自动识别 csv 时的默认行为 —— 它把看起来像数字的长字符串（如身份证号、银行卡号）当数值处理，超过 15 位就丢精度，变成 1.23457e+17 并把后三位抹成 0。
导出 CSV 后用 Excel 直接双击打开，为什么数字就“变样”了？
Excel 不是逐字读取 CSV 内容，而是启动一个自动类型推断引擎：遇到一串纯数字，宽度又够显示，它会直接设为“数值”格式。一旦该数字 ≥ 16 位，Excel 就强制截断到前 15 位有效数字，后面全归零 —— 这个过程不可逆，哪怕你之后手动设成“文本”，原始数据已丢失。
- 你看到的
1.23457E+17是显示形式，实际单元格存储值已是123456789012345000（末三位被毁） - Navicat 导出的 CSV 文件本身内容正确，用记事本或 VS Code 打开，数字完整无误
- 问题只发生在“用 Excel 双击打开 CSV”这个动作上，不是导出环节出错
最稳妥的绕过方式：用 Excel 的「从文本/CSV」导入向导
跳过自动识别，自己控制每列类型。Windows 上操作路径：Excel 菜单栏 → 数据 → 从文本/CSV → 选中你的 CSV 文件 → 在预览界面点击目标列标题（如“身份证号”）→ 顶部下拉选择 文本 → 点击 加载。
- Mac 版 Excel 没有这个向导，建议改用 Numbers 或直接用脚本处理
- 导入过程中若没看到预览，检查编码是否选对：
UTF-8最常用，中文乱码时可试GBK - 此法不修改原始 SQL 或导出设置，适合临时救急或下游用户无法改查询的情况
根治方案：在 Navicat 的 SQL 查询里提前“打标签”
让 Excel 在解析时第一眼就认出这是文本，而不是数字。核心是破坏“纯数字”结构，常见手段有：
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 加制表符：
CONCAT(id_card_number, '\t')—— 最轻量，不占显示空间，兼容所有数据库 - 加单引号：
CONCAT('''', id_card_number)—— 注意是三个单引号：''' + field，因为第一个'是字符串起始符，第二个'才是要拼进去的字符 - 加英文引号：
CONCAT('"', id_card_number, '"')—— 需配合 Excel 导入时启用“文本限定符”选项
别用 FORMAT(..., '0') 或 CAST(... AS CHAR)，前者可能补零或四舍五入，后者在某些数据库（如 MySQL 5.7）里仍会被 Excel 当数值识别。
导出 Excel（.xlsx）格式反而更容易踩坑
Navicat 直接导出 .xlsx 看似绕过 CSV，但实际仍可能触发 Excel 的自动类型判断 —— 尤其当字段声明类型为 BIGINT 或 NUMBER 时，Navicat 会按数值写入，Excel 加载后照样科学计数。
- 导出 Excel 前，务必确认目标字段在 SQL 中已被显式转为字符串（用
CONCAT或CAST(... AS VARCHAR)） - Navicat 15 的导出设置里没有“强制文本列”开关，不能依赖界面选项解决
- 如果必须导出 .xlsx 且字段含长数字，优先走 SQL 层字符串化，而非寄希望于导出配置
真正容易被忽略的是：只要字段内容是纯数字 + 无任何非数字字符，无论你导出 CSV 还是 XLSX，Excel 都可能把它当数值处理。所以“加什么字符”比“选什么格式”更关键。
