Navicat导入Excel时浮点数变0.0或科学计数法，本质是Excel将超15位数字存为双精度浮点数并四舍五入，Navicat读取的是已被篡改的底层值而非显示文本；提前设文本格式无效，因仅影响手动输入且Navicat读取Cell.Value而非Cell.Text；真正有效的是在SQL中用CONCAT(CAST(price AS CHAR), '\t')等加制表符强制转文本，使数据从源头脱离Excel数值体系。
Navicat导入Excel时浮点数变0.0或科学计数法，本质是Excel提前“转义”了
Navicat本身不解析浮点数精度，它读的是Excel文件里已渲染好的单元格值。而Excel在保存时会把长数字（如123456789012345678）自动转成双精度浮点数并四舍五入——一旦原始数据超过15位有效数字，后面全丢，Navicat拿到的就是一个被Excel篡改过的近似值。你看到的“123456789012345000”，不是Navicat导错，是Excel早就存错了。
为什么设成“文本格式”在Excel里无效？
在Excel中提前把列设为“文本格式”，只对后续手动输入生效；对已有数值型单元格，这个设置不会回溯转换。更关键的是：Navicat导入时读取的是Excel的底层存储值（Cell.Value），而非显示格式（Cell.Text）。即使你看到单元格里显示“123456789012345678”，底层实际存的是123456789012345000，Navicat照单全收。
- 验证方法：在Excel中右键单元格 → “设置单元格格式” → 看“分类”是不是“常规”或“数值”，如果是，说明它仍是数字类型
- 真正有效的做法：在Excel中用公式
=TEXT(A1,"0")生成新列，再导入该列；或复制后用“选择性粘贴 → 数值”破坏Excel的自动识别逻辑
导出CSV再导入也出问题？检查BOM和分隔符干扰
很多人以为转CSV就能绕过Excel精度陷阱，结果发现CSV里数字还是被截断。常见原因有两个：UTF-8 without BOM导致Excel用ANSI打开、误判字段类型；或者CSV中数字被引号包裹（如"123456789012345678"），Navicat在解析时可能触发隐式类型转换。
- 务必用Notepad++或VS Code确认CSV编码是
UTF-8 with BOM - 导出CSV时关闭“文本限定符”（即不加引号），避免Navicat把带引号的纯数字当字符串又转回数值
- 如果必须保留引号，导入前在Navicat「导入向导」第3步 → 对应列点击「…」→ 勾选
Ignore quotes
终极方案：SQL层强制转文本，跳过所有中间解析
最稳的方式不是靠Excel或CSV格式，而是让数据在进Navicat之前就失去“可被当数字解析”的特征。和身份证号处理一样，给浮点数末尾加制表符\t，Excel和Navicat都会把它当纯文本处理，完全跳过精度丢失链路。
- MySQL写法：
CONCAT(CAST(price AS CHAR), '\t') - PostgreSQL写法：
(price::TEXT || E'\t') - SQL Server写法：
CONVERT(VARCHAR, price) + CHAR(9) - 注意：别用空格或单引号替代
\t，空格易被Trim，单引号在部分版本Navicat里会引发语法误判
浮点数精度丢失的根子不在Navicat，而在Excel的双精度存储机制和Navicat对Excel底层值的忠实读取。任何指望“格式设置”或“导入选项”来修复它的尝试，都容易漏掉这个前提——得先让数据在源头就脱离Excel的数值体系，才能真正守住精度。
