在印度做工程踩过的一个坑：数字格式与货币本地化

去年给一个印度客户做后台报表导出，环境是 Python 3.10 + pandas 2.0，容器跑在孟买 region 的 EC2 上，单表 120 万行，导出 CSV 给财务团队。上线第一天，财务那边说金额全错，原本 1234567.89 的金额，他们看到的是 12,34,567.89，导进 Excel 直接被拆成两列。

一开始以为是编码问题，查了导出代码，发现我们用了 pandas 的 to_csv 默认格式，数字没做任何处理，但前端展示时用了 locale 库按 en_IN 格式化。问题出在印度数字分组规则：他们不是三位一组，而是前三位，之后每两位一组。所以 1234567 应该是 12,34,567，不是 1,234,567。财务用的 Excel 区域设置是 English (India)，粘贴时按本地规则解析，逗号位置不对就错位。

我的做法是导出时统一不加千分位，纯数字加两位小数，列名也改成英文无空格：

df.to_csv(
    path,
    index=False,
    float_format="%.2f",
    encoding="utf-8-sig",
)

同时给财务一份带格式的 PDF 预览，用 babel 的 format_decimal：

from babel.numbers import format_decimal
format_decimal(1234567.89, locale="en_IN")
# '12,34,567.89'

为什么这样取舍：CSV 是给机器读的中间格式，不该承担展示职责。印度财务的 Excel 环境不可控，有人用本地版有人用英文版，加千分位等于给自己埋雷。PDF 只做预览，格式错了不影响数据。代价是财务要多一步手动格式化，但他们更接受这个。

哪里会失效：如果对方要求 CSV 里直接带格式，这个方案不成立；另外 en_IN 在旧版 babel 里分组也有差异，我本地 2.9 和服务器 2.12 输出一致，但没做全版本验证。还有个坑：卢比符号 ₹ 在部分 Windows Excel 里显示成问号，导出 PDF 时我改用 INR 文本前缀，避免字体缺失。

你们在给印度团队做导出时，是坚持纯数字，还是按对方区域设置直接出格式？有没有遇到过 Excel 把 12,34,567.89 解析成日期的情况？