excel 导出 csv 时自动转换数据类型是因导入逻辑而非 csv 本身问题；应通过源系统转字符串、命令行工具导出或流式处理确保原样输出，并严格遵循 rfc 4180 转义规则、强制 header、校验 schema 以保障下游准确解析。
导出 csv 时 excel 自动改数据类型怎么办
excel 打开 csv 后把 00123 变成 123、把 1e5 当科学计数、把长数字截断——这不是 csv 有问题，是 excel 在“好心办坏事”。csv 本身没格式，问题出在导入端。真正要的是“让下游（比如数据仓库）能原样读取”，不是让 excel 看着舒服。
- 导出前，在源系统里确保字段类型为字符串：比如数据库里用
CAST(id AS TEXT)或TO_CHAR(id)，避免数值型字段裸导出 - 如果必须从 Excel 导出，别用「另存为 CSV」，改用「数据 → 自文本/CSV → 导出为文本（制表符分隔）→ 再用 sed/awk 替换为逗号」，绕过 Excel 的自动类型推断
- 更稳妥的做法：用命令行工具生成，比如
psql -c "COPY (SELECT ... ) TO STDOUT WITH CSV HEADER" > data.csv，PostgreSQL 默认不加引号但会按需转义，比 Excel 可靠得多
CSV 字段含换行、逗号、双引号怎么不出错
原始日志、用户输入、JSON 片段这类内容直接拼 CSV 极易崩。常见错误现象是数据仓库报 Malformed CSV: unexpected newline 或字段错位。核心原则：只要字段含特殊字符，就必须加双引号 + 正确转义。
- 标准做法是用 RFC 4180 兼容方式：字段含
\n、,或"时，整个字段用"包裹；字段内有"则替换成""（两个双引号） - 别手写字符串拼接。Python 用
csv.writer（设quoting=csv.QUOTE_MINIMAL），Node.js 用fast-csv，命令行用mlr --icsv --ocsv cat，它们都默认处理转义 - 验证方法：用
head -n 5 data.csv | hexdump -C看有没有孤立的0x0a（换行）或未闭合的22（双引号），有就是格式破了
导出大文件时内存爆掉或超时
单次 SELECT 几千万行再写 CSV，Python 的 pandas.read_sql 或 Java 的 ResultSet 容易 OOM；Web 后端直接 response.write 大文件可能被 Nginx 中断。这不是 CSV 格式问题，是流式处理没做对。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 数据库侧优先用原生 COPY：PostgreSQL 用
COPY ... TO '/path/file.csv' WITH CSV HEADER（注意路径是服务端）；MySQL 用SELECT ... INTO OUTFILE - 应用层必须流式：Python 用
cursor.itersize = 10000+ 分批fetchmany()+csv.writer直接写文件句柄，不攒 list - 别依赖“导出按钮”前端触发：超过 100MB 的文件，应走异步任务（如 Celery + Redis），生成后提供下载链接，URL 带签名和短时效，避免暴露路径
字段顺序/列名变更导致数仓清洗失败
下游 ETL 脚本硬编码了列索引（如 row[3]）或列名（如 row['user_id']），但上游某天把 CSV 列序调换了，或加了新字段没同步文档——清洗直接跑空或错映射。CSV 没 schema，靠约定。
- 强制带 header：所有导出必须含第一行列名，且列名用下划线小写（
created_at），禁用空格、点、中文 - 禁止动态列：即使业务上允许可选字段，导出时也要补全，空值写
NULL或空字符串（统一约定），不能少列 - 发布前校验：用
csvkit csvsql --dialect sqlite --no-inference data.csv | head -20快速看字段类型推断是否合理，比肉眼检查靠谱
最麻烦的不是语法，是字段语义漂移——比如今天 status 是字符串枚举，明天变成 JSON 对象，但 CSV 文件名还是 orders.csv。这类问题没法靠格式解决，得靠导出时附带 schema.json 或往文件头加注释行（如 # schema_version: 2.1），否则清洗脚本迟早挂。
