不能用c.File或csv.WriteAll，因其会全量加载数据至内存导致OOM；应使用csv.NewWriter(c.Writer)配合UseCRLF、手动Flush、BOM头写入及预编译ToCSVRow方法实现安全流式导出。
为什么大宽表导出不能用 c.File 或全量 csv.WriteAll
因为宽表（比如 50+ 列、每行数据超 10KB）叠加万级行数后，c.File 会把整个文件读进内存再吐出去；csv.WriteAll 会先把所有行转成字符串切片缓存，内存占用呈 O(n×m) 爆炸式增长。实测 2 万行 × 60 列 UTF-8 字符串，堆内存峰值轻松破 800MB——不是慢，是直接触发 GC 频繁或 OOM Kill。
csv.NewWriter(c.Writer) 必须配合 writer.UseCRLF = true 和手动 flush
宽表字段含换行符、逗号、双引号时，encoding/csv 默认用
换行，但 Windows Excel 识别的是
。不设 writer.UseCRLF = true，打开 CSV 时整行错位、单元格跨行——这不是显示问题，是解析失败。
更关键的是：Gin 的 c.Writer 默认不自动 flush，尤其在宽表单行写入耗时稍长时，客户端可能卡住几秒才收到第一个字节。必须在写标题后、写首行数据前，显式调用：
writer.Write(header) writer.Flush() // ← 这一行不能省
否则浏览器进度条不动，用户以为挂了。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
宽表字段含中文/特殊字符时，BOM 头和编码声明要分两步走
只设 Content-Type: text/csv; charset=utf-8 不够。Excel for Windows 默认用 ANSI 编码打开无 BOM 的 UTF-8 文件，中文全变乱码。必须在写入第一行前，手动写入 UTF-8 BOM：
c.Writer.Write([]byte{0xEF, 0xBB, 0xBF})- 再调
writer.Write(header) - 再
writer.Flush()
注意：csv.Writer 本身不处理 BOM，它只是按 byte 写入。BOM 必须绕过 writer 直接写到 c.Writer 底层，否则会被 csv 转义或截断。
逐行构造宽表数据时，避免 struct tag 反射开销
如果用 reflect 自动提取 struct 字段（比如遍历 Student 的 60 个字段），每行反射耗时约 1.2μs —— 10 万行就是 120ms，纯 CPU 浪费。实际生产中应提前生成字段名映射和取值函数：
type WideRow struct {
ID, Name, Email string
// ... 其他 57 个字段
}
// 预编译取值逻辑，而非 runtime 反射
func (w *WideRow) ToCSVRow() []string {
return []string{strconv.Itoa(w.ID), w.Name, w.Email, /* ... */ }
}
宽表字段多、类型杂（time.Time、sql.NullString、float64 带精度控制），硬编码 ToCSVRow() 比通用反射快 8–12 倍，且可控格式（如时间统一为 "2006-01-02"，空值统一写 "" 而非 "<nil>"</nil>）。
宽表流式导出最易被忽略的点：字段内嵌换行符必须由 csv.Writer 自动加引号包裹，但前提是**你没提前手动转义**。一旦对字段做 strings.ReplaceAll(field, "
", "\n")，csv.Writer 就不再加引号，Excel 会把该单元格内容拆成多行——这个 bug 在测试环境几乎不暴露，上线后用户反馈“导出的表格少了一半数据”，排查要花半天。
