gin导出csv易oom或卡死的根本原因是未包装bufio.writer导致频繁系统调用、未提前设置响应头造成延迟发送、以及未处理bom和换行符兼容性问题；必须用64kb缓冲区包装csv.writer、显式flush、流式消费数据库rows并复用变量、手动写bom及启用crlf。
直接用 csv.NewWriter(c.Writer) 写 Gin 响应体，不加缓冲、不控制 flush、不处理 BOM，导出 10 万行就可能卡顿或丢数据；真正压垮内存的不是 CSV 库本身，而是没切断「数据生成 → 写入 → 刷盘」链路上的隐式缓存和错误时机。
为什么 Gin 导出 CSV 容易 OOM 或卡死
现象不是“写得慢”，而是进程 RSS 突增、HTTP 连接挂起、客户端收不到响应头——根本原因有三个：
-
csv.NewWriter(c.Writer)没包bufio.Writer，每次Write()都触发系统调用，GB 级文件会把 CPU 耗在 syscall 上 - 没提前设置
c.Header()，Gin 默认延迟发送响应头，直到第一次Write()才发，但此时可能已卡在驱动层（尤其 MySQL 查询未流式） - 字段含换行符或双引号时，
csv.Writer自动加引号，但若底层c.Writer缓冲区太小（如默认 4KB），引号跨 buffer 就 panic
必须手动包装 bufio.Writer 并控制 Flush
csv.Writer 本身无缓冲，必须用 bufio.NewWriterSize 包一层，且大小不能拍脑袋设：
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 缓冲区至少
64 * 1024（64KB）：太小会导致引号/换行符被截断；太大让 GC 扫描压力陡增 - 必须显式调
w.Flush()：defer 不可靠，panic 时不会执行；建议每写 1000 行后w.Flush()，并检查w.Error() - 别用
w.WriteAll(records)：它会先把所有[][]string全 load 进内存，100 万行 ≈ 1.5GB+，和ReadAll()是同一类陷阱
数据库查询必须配合 Rows.Next() 流式消费
哪怕你用了流式响应，如果 SQL 查询本身没流式，照样 OOM：
- MySQL 驱动默认启用
parseTime=true，时间字段会缓存整批结果；PostgreSQL 驱动若没显式声明游标，Query()也会等全量返回 - 必须每调一次
rows.Next()，立刻用rows.Scan()消费，且复用[]interface{}切片，避免为每行分配新变量 - 连接池要限流：
db.SetMaxOpenConns(5)，否则百万行导出可能占满数据库全部连接
BOM、中文名、换行兼容性三处硬坑
这些不是“可选优化”，是 Windows + Excel 用户开箱即崩的默认路径：
- 中文文件名必须用
url.QueryEscape()，再拼进Content-Disposition，否则 IE/Edge 直接乱码 - UTF-8 BOM（
0xEF, 0xBB, 0xBF）要手动写在响应体开头，csv.Writer不管这个；不写，Excel 2016 及更早版本打开就是乱码 - 必须设
w.UseCRLF = true：Linux 换行是\n，Excel 默认只认\r\n，否则所有换行符显示为方块
最易被忽略的是：**rows.Scan() 不是可选步骤，是强制消费动作；没它，rows.Next() 下次调用就卡住，整个 HTTP 响应永远发不出第一字节。**
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
