Excel打开CSV时数字变科学计数法，因自动识别导致精度丢失；应使用“数据→从文本/CSV”导入并设列为文本，或用pandas显式指定dtype=str避免误转。
Excel 里打开 CSV，数字自动变 1.23E+10 怎么办
这不是 python 或 pandas 的问题，是 excel 自己的“贴心”行为——它在导入 csv 时会主动识别并格式化数字列，把长数字（比如身份证、订单号、手机号）按浮点数处理，再一显示就变成科学计数法。你双击单元格再回车，可能发现末尾几位已经变 0 了。
解决思路很直接：不靠 Excel 打开，改用「文本导入向导」手动指定列为「文本」；或者彻底绕过 Excel，用代码控制类型。
- Windows 上右键 CSV → 「打开方式」→ 「Excel」会触发自动识别，必踩坑
- 正确做法：Excel 菜单栏 → 「数据」→ 「从文本/CSV」→ 选中文件 → 在预览页点击对应列标题 → 顶部下拉选「文本」→ 「加载」
- Mac Excel 没有该向导，建议改用 Numbers 或直接上代码
pandas read_csv() 读出来还是字符串？怎么强制转数字
常见错觉是「我明明没设 dtype，怎么数字列成了字符串？」——其实不是 pandas 强制转了字符串，而是它检测到某行该列有空值、字母、前导零（如 "00123"）或超长整数（超过 int64 表示范围），就会整个列 fallback 成 object 类型，里面混着 str 和 float。
关键不是“强转”，而是“提前声明”和“容错处理”：
- 用
dtype={'col_name': str}显式锁死为字符串，避免误转（适合身份证、编码类字段） - 用
dtype={'col_name': 'Int64'}（注意大写 I）支持缺失值的整型，比int64更安全 - 若已读成
object，别直接.astype(int)，先用.str.strip().replace('', np.nan).astype('Int64')清洗 -
converters参数更灵活：例如converters={'id': lambda x: str(x).zfill(11)}，适合固定长度补零场景
Python 读 CSV 后数字显示成 1.23456789e+10，其实是 float 精度丢失
这是典型长整数被存成 float64 的后果。比如 18 位的微信 openid 或 19 位的 MySQL BIGINT，超出 float64 精确整数范围（2^53 ≈ 9e15），后面几位就开始四舍五入。
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
根本解法只有一条：不让它进 float。
- 不要依赖
infer_objects()或默认行为，必须显式指定dtype - 对可能超长的数字列，统一用
str读入，后续需要计算再局部转int（确认无溢出）或用decimal.Decimal -
pd.read_csv(..., float_precision='round_trip')只影响小数解析，对整数无效，别白试 - 检查列类型：打印
df['col'].dtype，看到object不代表就是字符串，df['col'].apply(type).unique()才知道真实构成
用 to_csv() 保存后，Excel 再打开又变科学计数法
导出环节的坑常被忽略：即使你在 pandas 里存的是字符串，如果导出时没关掉 index 或没处理好引号，Excel 仍可能重新解析。
- 确保字符串字段每个值都带英文双引号，加参数
quoting=csv.QUOTE_NONNUMERIC或quoting=csv.QUOTE_ALL - 避免
index=True导出第一列是纯数字索引，Excel 会把它当数值列识别 - 导出后用记事本打开 CSV，确认关键列的值是否被双引号包裹（如
"001234567890123456"），没引号大概率还会被 Excel “优化” - 终极方案：导出为
.xlsx（用openpyxl引擎），直接写入单元格格式为「文本」，一劳永逸
真正麻烦的从来不是“怎么转类型”，而是“谁在哪个环节偷偷动了你的数据”。Excel 的自动识别、pandas 的类型推断、float 的精度边界——三者叠加，一个不留神，18 位 ID 就少两位。盯住每一步的 dtype 和实际存储内容，比写十行转换代码都管用。
