Golang导出CSV必须严格控制三件事：加UTF-8 BOM防Excel中文乱码、用csv.Writer流式写入防OOM、正确调用http.ResponseWriter.Flush()防下载为空，缺一不可。
直接说结论：Golang 导出 CSV 不是“写完就完”，而是必须控制三件事——BOM防 Excel 中文乱码、csv.Writer流式写入防 OOM、Flush调用时机防下载为空。漏掉任一，用户打开就是方块、空文件或卡死。
CSV 下载打开全是方块？加 UTF-8 BOM 才算真正完成
Excel 默认用 ANSI（如 GBK）解析无标记的 UTF-8 文件，不是 Go 写错了，是它没“认出”编码。标准库 csv.Writer 输出纯 UTF-8，不带 BOM，所以必须手动补。
-
w.Write([]byte("\xEF\xBB\xBF"))必须在csv.NewWriter(w)之前、第一行数据之前执行，且只能写一次 - HTTP 场景下，BOM 要写进
http.ResponseWriter，不能写到中间缓冲区里被截断 - 本地文件场景下，先
os.OpenFile获取*os.File，再写 BOM，最后传给csv.NewWriter - 别用
golang.org/x/text/encoding转 GBK——其他工具（如 Python pandas）读不了，且违反 CSV 标准
导出为空或浏览器卡住？Flush 调用对象错了
常见错误是写了数据但没刷出去，浏览器收不到完整响应体。关键点在于：csv.Writer.Flush() 和 http.ResponseWriter.Flush() 是两回事，Web 场景下必须调后者。
- 当
w是http.ResponseWriter时：csv.NewWriter(w)创建后，循环写完每批数据（比如 500 行），要显式调w.(http.Flusher).Flush() -
csv.Writer.Flush()只负责把内部缓冲推给底层io.Writer，对 HTTP 响应无效；它只在本地文件场景下配合defer file.Close()用 - 本地文件导出时，
defer file.Close()必须放在csv.NewWriter(file)之后，否则file提前关闭，内容写不全 - 大数据量时，每写 1000 行就
Flush()一次，避免连接超时或客户端断连
字段含逗号、换行、双引号就崩？别拼字符串，交给 csv.Writer
手拼 CSV 字符串（比如 fmt.Sprintf("%s,%s", a, b)）看似快，实际遇到用户输入 "他说："你好"" 或地址 "上海市,浦东新区\n张江路" 就直接格式错乱。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须用
w.Write([]string{"a", "b,c", "d\nf", `他说:"你好"`})，csv.Writer自动加引号、转义双引号为""、处理换行 -
w.Comma可改分隔符，但 Excel 默认只认英文逗号；设成\t就该用 TSV，文件名也得改成.tsv - 结构体导出不要靠反射自动取字段——时间、空值、布尔类型格式不可控；推荐为类型实现
CSVRecord() []string方法，显式格式化 - 空值字段（
nil）需提前转成空字符串""，否则csv.Writer会 panic
百万行导出内存爆了？流式 + 分页 + 缓冲区调优
调用 csv.WriteAll([][]string{...}) 或先把所有数据 db.Find(&list) 到内存，等于主动申请 OOM。
- 数据库导出必须用游标：
rows, _ := db.Query("SELECT ...")，然后for rows.Next()配合rows.Scan()边查边写 - 缓冲区默认 4KB 太小，大数据建议
csv.NewWriter(bufio.NewWriterSize(w, 64*1024))（64KB） - HTTP 响应下，
bufio.NewWriterSize的底层io.Writer是http.ResponseWriter，确保它实现了http.Flusher - 千万别并发写同一个
*os.File——磁盘 I/O 是物理串行的，goroutine 越多越慢，还可能写坏行边界
最易被忽略的是：BOM 写的位置、Flush 调用的对象、以及结构体字段是否真的按预期转成了字符串——这三个点不出错，CSV 导出才算稳了。
