CSV导出换行错乱的根源是未按RFC 4180规范处理：含换行符（\n、\r\n）或双引号的字段必须用双引号包裹，且内部双引号需转义为两个双引号；须统一使用QUOTE_ALL、正确设置行结束符（Windows下为\r\n），禁用手动拼接。
导出CSV时换行符被Excel误识别为新行
这是最典型的错乱现象：数据里含 \n 或 \r\n（比如用户填写的地址、备注字段），导出后在excel里一打开，整行就断开了——实际是csv规范要求：换行必须包裹在双引号内，且内部换行需保持原样。
关键不是“去掉换行”，而是“合规包裹+转义”。不处理的话，Excel会把未引号包围的换行直接当行分隔符，彻底打乱行列对齐。
- 必须对每个字段做
csv.QUOTE_MINIMAL或更稳妥的csv.QUOTE_ALL（Python）；Java用Apache Commons CSV时设withQuoteMode(QuoteMode.ALL) - 字段含双引号时，要先转义成两个双引号
""，不是反斜杠；这是RFC 4180硬性规定 - 别手动拼接字符串！用标准库的writer，否则引号嵌套、换行、逗号全得自己逃逸，99%会漏
Python csv.writer 默认不包裹含换行的字段
csv.writer 的默认 quoting=csv.QUOTE_MINIMAL 只在字段含逗号、换行或引号时才加引号。但问题在于：它只检查“原始字符串是否含 \n”，而如果你字段是 "addr\n123"，它确实会加引号；可如果换行来自数据库读取（比如MySQL的TEXT字段），且连接没设 charset=utf8mb4，可能读出来是空字节或乱码，csv.writer 就检测不到换行，直接裸写出去，Excel立刻崩。
- 显式指定
quoting=csv.QUOTE_ALL，省去判断逻辑 - 导出前统一做
.replace('\r', ' ').replace('\n', ' ')是偷懒方案，会丢数据，仅限日志类非结构化字段 - 用
io.StringIO()而非文件直写，便于在写入前校验首几行是否含未包裹换行
Java用OpenCSV导出时换行仍错乱
常见错误是只调了 setApplyQuotesToAll(true)，却忘了 setLineEnd("\r\n")。OpenCSV默认用 \n 结尾，而Windows版Excel只认 \r\n 为合法行结束符——结果就是所有换行字段里的 \n 被当成行尾，但文件本身用 \n 分隔物理行，造成双重换行错位。
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 必须同时设置：
csvWriter.setApplyQuotesToAll(true)+csvWriter.setLineEnd("\r\n") - 字段值里若含
\r，OpenCSV不会自动替换，建议预处理：value.replace("\r", " ").replace("\n", " ")或保留但确保已引号包裹 - 避免用
writeNext(String[])直传数组，改用writeNext(String[], boolean applyQuotes)并传true，防止某次调用漏掉引号
前端JavaScript生成CSV时换行变成%0A
用 encodeURIComponent 处理字段再拼CSV？完蛋。URL编码会把 \n 变成 %0A，浏览器下载后Excel根本识别不了，显示为字面量%0A，或者直接卡死。
- 前端生成CSV必须用
new Blob([content], {type: "text/csv;charset=utf-8;"})，且content是原始字符串，不做任何encodeURI - 字段含换行：用
"\"line1\r\nline2\""包裹，注意JS里\r\n要写成字符串字面量，不是正则 - 不要用
JSON.stringify去包字段——它加的是JSON双引号规则，不是CSV规则，会多出反斜杠
真正麻烦的不是换行本身，是不同环节对“换行”的定义不一致：数据库驱动返回的、HTTP响应头声明的、浏览器解析的、Excel渲染的——每个都可能悄悄转换一次。只要有一环没走RFC 4180，就必然错行。盯着引号和行结束符这两处，比调字体大小实在得多。
