核心是encoding/csv+bufio.writer+显式flush：自动转义特殊字符防解析失败；http需设content-type、content-disposition（含bom防中文乱码）；大数据须边查边写+分批flush防oom。
直接用 encoding/csv + bufio.Writer + 显式 Flush() 就是高性能 CSV 导出的全部核心，其余都是围绕它做适配和兜底。
为什么不用 fmt.Fprintf 或 strings.Join 拼接 CSV
看似省事，实则埋雷：字段含逗号、换行符或双引号时，手动拼接会直接破坏 CSV 结构。Excel 打开后列错位、数据吞掉、解析报错都是必然结果。
-
csv.Writer会自动包裹双引号、转义内部引号（"→""）、处理跨行字段 - 而
fmt.Fprintf(w, "%s,%s\n", a, b)完全绕过这些逻辑，等于把解析责任甩给下游工具 - 哪怕只有一行含
"他说:\n"，整个文件就不可靠
HTTP 响应中导出 CSV 必须设对三个头
漏掉任一，用户看到的可能是乱码、页面内渲染、默认文件名或下载失败。
-
w.Header().Set("Content-Type", "text/csv; charset=utf-8")—— 告诉浏览器这是 UTF-8 编码的 CSV -
w.Header().Set("Content-Disposition", `attachment; filename="data.csv"`)—— 注意用反引号包住，避免双引号冲突；filename值里不能含路径或控制字符 - 如需带时间戳的 Unicode 文件名（如
导出-20260430.csv），改用filename*=UTF-8''%E5%AF%BC%E5%87%BA-20260430.csv，但旧版 IE 不支持，生产环境建议仍用 ASCII 名
百万行导出不 OOM 的关键动作
不是“调大缓冲区”就够，而是“边读边写 + 分批刷盘”。否则内存随行数线性增长，50 万行就可能吃光 1GB。
- 数据库查询必须用
rows, err := db.Query(...)，而非db.Find(&list)全量加载 - 每轮
rows.Next()后立即rows.Scan()，再调csvWriter.Write() - 每写 1000 行，显式
csvWriter.Flush()—— 把缓冲内容推给http.ResponseWriter或文件，释放内存 - 若用
csv.NewWriterSize(w, 64*1024)配合bufio.NewWriterSize，吞吐能提升明显，但不替代定期Flush()
中文在 Excel 里显示为方块？加 BOM 是最稳解法
Excel 默认用系统 ANSI 编码（Windows 是 GBK）读 CSV，而 Go 输出的是 UTF-8。这不是 Go 的错，是 Excel 没“认出”编码。
- 写文件前先写入
\xEF\xBB\xBF（UTF-8 BOM），Excel 就能自动识别为 UTF-8 - 别用
golang.org/x/text/encoding转 GBK —— 非标准，LibreOffice、pandas 等会读错 - HTTP 响应中，BOM 要写在
csv.Writer开始写之前，且不能被中间件截断或 gzip 压缩干扰 - 如果导出后仍乱码，优先检查是否漏了 BOM，而不是怀疑数据库连接或字段类型
真正难的从来不是“怎么写出 CSV”，而是“怎么让每一行都可预期地被 Excel、Numbers、pandas 正确打开”。BOM、Flush 频率、空值处理、表头顺序——这些细节卡住的不是编译，而是上线后的用户投诉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
