Excelize处理中文报表乱码需三步：校验utf8.ValidString(s)、清洗BOM并转码GBK、显式设文本格式NumFmt=49；读取需按CellType分支处理，导出万行须用WriteTo流式写入。
Excelize 能处理中国式复杂报表，但必须绕开“直接套用模板”的思维惯性；它不是 Word 或 WPS 的替代品，而是按 Office Open XML 规范精确操控单元格、样式、公式和结构的工具。
写入中文却显示方块或乱码？先检查三件事
这不是字体没装全的问题，而是 Excel 本身对字符串字节的解释逻辑被绕过了。
-
utf8.ValidString(s)必须在f.SetCellValue前校验——若返回false，说明输入含非法 UTF-8 字节（比如从旧 GBK CSV 直接读入未转码） - 模板文件若由 Excel 2003 或 Windows 记事本另存为“ANSI”，实际存的是 GBK 字节流，
excelize按 UTF-8 解析就会出错；需提前用bytes.TrimPrefix清洗 BOM，再用golang.org/x/text/encoding/simplifiedchinese.GBK.NewDecoder().Bytes()转码 - 单元格格式未设为文本或通用，会导致 Excel 自动按数字/日期解析：显式调用
f.SetCellStyle("Sheet1", "A1", "A1", styleID)，其中styleID来自f.NewStyle(&excelize.Style{NumFmt: 49})（49 是“文本”格式代码）
读取公式/日期/布尔值返回空或错值？别只用 GetCellValue
GetCellValue 返回的是 Excel 渲染后的字符串，对非纯文本类型极易失真。
- 先用
f.GetCellType("Sheet1", "A1")判断类型：excelize.CellTypeFormula、excelize.CellTypeDate、excelize.CellTypeBool都要单独分支处理 - 日期值必须用
f.GetCellFloat("Sheet1", "A1")拿原始浮点数，再传给time.DateFromExcel(float64, 0)（第二个参数是 Excel 日期基准：0 表示 1900 年，1 表示 1904 年） - 公式结果为空？确认
f.Calculation.On = true，且已调用f.Calculate()；否则默认只读静态缓存值
导出万行报表卡顿或 OOM？必须用流式写入
调用 f.SaveAs 会把整个工作簿加载进内存，10 万行 + 样式 + 合并单元格很容易突破 500MB。
立即学习“go语言免费学习笔记（深入）”；
- 改用
f.WriteTo(w io.Writer)，例如直接写入http.ResponseWriter：err := f.WriteTo(w)，全程无中间文件、不驻留内存 - 写入前禁用自动计算：
f.Calculation.On = false，避免每写一行都触发公式重算 - 避免频繁调用
f.SetCellStyle—— 改用f.SetColStyle("Sheet1", "A:A", styleID)批量设列样式（v2.9.1+ 支持），性能提升明显
合并单元格 + 自动换行失效？行高不是万能解法
用 f.SetRowHeight 粗暴拉高行高，会破坏 Excel 的自动换行逻辑，文字仍溢出或截断。
- 启用换行必须两步走：
f.SetCellStyle中设置WrapText: true，且对应列宽足够（f.SetColWidth("Sheet1", "A", "A", 30)） - 合并单元格后，样式只继承左上角单元格；若需统一控制，先
f.MergeCell("Sheet1", "A1", "C1")，再f.SetCellStyle("Sheet1", "A1", "C1", styleID) - 中文排版建议字体设为
"微软雅黑"或"SimSun"，避免用"Arial"等无中文字形的字体导致 fallback 失败
复杂报表真正的难点不在 API 调用，而在理解 Excel 的底层模型：它不是所见即所得的画布，而是一套基于坐标、格式代码、共享字符串表和公式依赖图的结构化数据容器。任何“看起来应该能自动适配”的操作，几乎都得手动指定格式、范围和行为边界。
