Go用excelize导出Excel需避开三类故障：①中文乱码因非UTF-8字节序列，须确保字符串为合法UTF-8；②大文件卡死应改用StreamWriter流式写入；③文件损坏多因列宽超限、字体大小非法或文件句柄未关闭。
Go 用 excelize 做 Excel 导出，不是“能不能”，而是“怎么避开模板错位、中文乱码、大文件卡死”这三类高频故障。
导出时单元格内容是乱码或空白？检查 SetCellValue 的类型和编码
常见错误现象：中文写进去显示为 ??? 或空值，尤其在 macOS/Linux 下更明显。
-
excelize默认不处理字符编码转换，所有字符串必须是 UTF-8 字节序列 —— Go 字符串天然满足，但如果你从io.Reader（比如 CSV 文件）读取后做了错误的string(bytes)转换，就可能破坏 UTF-8 结构 - 不要用
SetCellFormula写中文内容，它只接受公式表达式；该用SetCellValue - 如果数据来自数据库，确认字段类型是
TEXT或VARCHAR，而非BLOB；否则sql.Scan可能返回[]byte，需显式转成string
示例：
sheet.SetCellValue("A1", "姓名") // ✅ 正确<br>sheet.SetCellValue("A2", string([]byte{0xff, 0xfe, 0x4e, 0x00})) // ❌ 错误：这是 UTF-16LE 乱码字节
导出大量数据（>5 万行）内存暴涨甚至 OOM？用 StreamWriter 替代普通 f.Save
使用场景：后台定时导出用户行为日志、订单明细等批量数据，单 Sheet 超过 3 万行时，常规方式会把整个工作表结构全载入内存。
立即学习“go语言免费学习笔记（深入）”；
- 普通
f.SaveAs("out.xlsx")会构建完整 XML 树再序列化，内存占用 ≈ 行数 × 列数 × 平均字符串长度 × 3～5 倍 -
StreamWriter是流式写入，边生成边刷盘，内存基本稳定在几 MB 级别 - 注意：
StreamWriter不支持合并单元格、图表、条件格式等高级特性；仅适用于纯数据表格导出
关键代码片段：
sw, err := f.NewStreamWriter("Sheet1")<br>if err != nil { return err }<br>sw.SetRow("A1", []interface{}{"ID", "Name", "Time"})<br>for _, v := range data {<br> sw.SetRow(fmt.Sprintf("A%d", i), []interface{}{v.ID, v.Name, v.Time})<br>}<br>sw.Flush()<br>f.SaveAs("out.xlsx")
导出后 Excel 打不开或报“文件已损坏”？检查 Style 和 ColumnWidth 的合法性
错误类型典型提示：Excel found unreadable content... 或 macOS Numbers 直接拒绝打开。
-
SetColWidth的列宽值必须在0 ~ 255之间；传入负数或超限值（如999）会导致 ZIP 包内 XML 格式异常 - 自定义样式（
NewStyle）中，Font.Size必须 > 0；设为0或-1会生成非法 XML 属性 - 文件路径含中文没问题，但若用
os.Create创建临时文件再交给f.SaveAs，要确保文件句柄已关闭，否则 Windows 下可能被锁住导致写入不全
为什么改了代码 Excel 内容却没更新？留意 f.SaveAs 的覆盖逻辑和缓存残留
常见于本地开发调试阶段：改完代码重新运行，浏览器下载的还是旧表格。
-
f.SaveAs是覆盖写入，但如果上一次执行 panic 了、或进程被 kill，可能导致文件处于半写入状态；下次打开时 Excel 会自动恢复损坏副本，看起来像“没更新” - 浏览器端常缓存
Content-Disposition: attachment; filename="data.xlsx"，即使服务端文件变了，也可能加载本地缓存；加时间戳或随机参数可绕过：data.xlsx?t=1715823400 - 用
curl -I检查响应头中的Content-Length是否变化，比肉眼点开更可靠
真正麻烦的从来不是“怎么写进去”，而是“写进去之后，谁在悄悄改它”。比如 Excel 自动把长数字转成科学计数法、把以 0 开头的文本当数字截断——这些都在你导出之后发生，excelize 管不了，得靠预设单元格格式（SetColStyle + 自定义 NumberFormat）兜底。
