excelize是Go语言Excel导出最成熟方案，纯Go实现、支持.xlsx、中文/公式/样式/多Sheet；不可用encoding/csv替代因其不支持格式、类型控制及高级功能；需注意UTF-8编码、列宽设置、字符串类型写入、内存优化（手动GC/流式写入）及并发安全（避免全局样式）。
Go 语言做 Excel 导出，excelize 是当前最成熟、最常用的方案，它纯 Go 实现、无需外部依赖、支持 .xlsx 格式（不支持旧版 .xls），且对中文、公式、样式、多 Sheet 等场景覆盖良好。但直接上手容易踩坑：比如中文乱码、日期写入异常、内存暴涨、并发导出崩溃等。
为什么不能用 encoding/csv 代替 excelize？
CSV 文件本质是纯文本，无法承载 Excel 的核心能力：
-
excelize能写入带格式的单元格（加粗、背景色、边框、数字格式），encoding/csv只能输出逗号分隔的字符串 - Excel 打开 CSV 时会自动按区域解析数字/日期，常导致手机号变科学计数法、0 开头编号被截断——而
excelize可显式设置单元格类型为CellTypeString - 多 Sheet、图表、冻结窗格、数据验证等高级功能，CSV 完全不支持
- 用户双击打开 CSV 时，Excel 默认用系统区域设置解析，中文路径或内容可能显示为乱码；
excelize生成的是标准 ZIP 包结构，无编码歧义
f.SetCellValue 写入中文却显示方块或问号？
这不是字体问题，而是单元格未声明为 UTF-8 兼容类型，或写入前未调用 f.SetColWidth 导致 Excel 自动缩列隐藏文字。真正起作用的是两步：
- 确保 Go 源文件本身保存为 UTF-8 编码（VS Code / GoLand 默认即如此，但 Sublime 或老旧编辑器可能存为 GBK）
- 写入后主动设置列宽：
f.SetColWidth("Sheet1", "A", "A", 20)（单位是字符宽度） - 如需强制字符串类型（防止 Excel 自动转数字），改用
f.SetCellStr而非f.SetCellValue，例如：f.SetCellStr("Sheet1", "A1", "00123")
导出大数据量（>10 万行）时内存飙升甚至 OOM？
excelize 默认将整个工作簿构建在内存中，逐行 SetCellValue 会持续累积对象。关键优化点不在“写得快”，而在“别全堆内存”：
立即学习“go语言免费学习笔记（深入）”；
- 禁用自动计算：
f.Calculation = &excelize.Calculation{CalcMode: "manual"}，避免每写一行都触发公式重算 - 关闭样式缓存（如果不用复杂样式）：
f.StyleSheet = nil（需在f.NewSheet后、写入前设置） - 分批写入 + 手动触发 GC：
runtime.GC()在每 5 万行后调用一次（实测有效，但勿滥用） - 终极方案：改用流式写入模式（v2.7.0+ 支持），启用
f.NewStreamWriter，它只维护当前行状态，内存占用稳定在 MB 级别
并发导出多个 Excel 文件报 panic："concurrent map read and map write"？
excelize.File 实例**不是并发安全的**。即使每个 goroutine 创建自己的 f := excelize.NewFile()，若共用同一个全局 excelize.DefaultStyle 或调用 excelize.SetDefaultFont，仍会触发底层 map 竞态。
- 绝对不要在 init() 或全局变量中调用
excelize.SetDefaultFont - 每个导出任务必须独立创建
*excelize.File，且所有样式通过f.NewStyle获取 ID 后再应用，例如：styleID, _ := f.NewStyle(&excelize.Style{Font: &excelize.Font{Bold: true}}) - 如需统一字体，改为在每个
f.NewStyle调用中显式传入Font字段，而非依赖全局默认
真正难的不是“怎么导出”，而是“导出时如何控制内存、避免竞态、保证中文和数字不被 Excel 自作聪明地篡改”。这些细节不会报错，但上线后用户一反馈就是生产事故。
