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），后面几位就开始四舍五入。

QuickBooks Mileage CSV

使用 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 和实际存储内容，比写十行转换代码都管用。