unidoc/unioffice 是目前唯一能稳定生成合规 .docx 的 Go 开源库，基于 ECMA-376 标准，支持样式、表格、图片等，需显式构建文档结构，不支持 .doc，避免 ZIP 手动操作。
用 unidoc/unioffice 生成 .docx 文件最可靠
Go 原生不支持 Word 文档生成，unidoc/unioffice 是目前唯一能稳定生成合规 .docx（非纯 XML 拼接）的开源库。它基于 ECMA-376 标准实现，生成的文件可被 Word、WPS、LibreOffice 正常打开，且支持样式、表格、图片、页眉页脚等核心功能。
注意：它不是零依赖——需要调用 unioffice 的文档模型 API，而非简单模板填充；也不支持 .doc（旧二进制格式），只处理 .docx。
安装方式：
go get github.com/unidoc/unioffice/document
关键点：
立即学习“go语言免费学习笔记（深入）”；
-
document.New()创建新文档，不是从模板加载（如需模板，得先用 Word 手动保存为 .docx 再用document.Open()读取） - 段落、运行（run）、文本（text）需显式添加，没有“直接写字符串”接口
- 中文需确保字体存在（如设置
run.SetFont("Microsoft YaHei")），否则 Word 可能回退为默认西文字体导致乱码
避免用 tealeg/xlsx 或 360EntSecGroup-Skylar/excelize 生成 Word
这两个库专为 Excel（.xlsx）设计，强行操作 .docx ZIP 结构会破坏 OPC（Open Packaging Conventions）包关系，导致文件打不开或内容丢失。常见错误现象：Word 报错“无法打开文件，因为内容有误”，或打开后仅显示空白页。
有人尝试把 .docx 当成 ZIP 解压后改 word/document.xml 再重打包——这理论上可行，但实际极易出错：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- XML 命名空间缺失或错位 → Word 拒绝解析
- 未同步更新
[Content_Types].xml和_rels/.rels→ 关系链断裂 - 时间戳、压缩方式、ZIP 中央目录顺序不符合规范 → WPS 兼容性差
除非你已完整读过 ECMA-376 第 1 部分，否则不建议走这条路。
unioffice 插入表格和样式的典型写法
表格不是“画出来”的，而是按行列逐单元格构造；样式不能全局设置，必须绑定到段落或运行对象上。
例如插入一个带边框的 2×2 表格：
table := doc.AddTable(2, 2)
row := table.Row(0)
row.Cell(0).AddParagraph().AddRun().SetText("姓名")
row.Cell(1).AddParagraph().AddRun().SetText("年龄")
// ……继续填第二行
// 设置表格边框（必须对 table 对象调用）
table.SetBorder(1, 0, 0, 0, 0, 0)
常见疏漏：
- 忘记调用
paragraph.AddRun()就直接SetText()→ 文本不显示 - 对
table设置了边框，但没对cell设置内边距 → 单元格文字贴边难看 - 用
doc.SaveToFile("out.docx")后没检查 error → 文件可能为空或损坏
生成大文档时内存和性能怎么控
unioffice 是内存驻留型生成器：所有内容先构建在结构体中，最后一次性序列化为 ZIP 流。10 页以内文档无压力；但若动态生成上千段落或嵌套表格，容易触发 GC 压力或 OOM。
实操建议：
- 用
runtime.GC()在批量插入每 200 段落后手动触发一次回收（实测可降 30% 峰值内存） - 避免在循环里反复调用
doc.AddParagraph()—— 改用复用paragraph对象 +Clear()重置内容（需确认版本支持该方法） - 导出前用
doc.Clean()清理冗余样式引用（v1.2.0+ 支持） - 如需流式生成（如 HTTP 响应直接输出 .docx），必须用
doc.WriteTo(w io.Writer)，而非先存文件再读取，否则多一次磁盘 I/O
真正麻烦的从来不是“能不能生成”，而是“生成的文档在不同 Office 版本里是否表现一致”——字体 fallback、样式继承、列表编号这些细节，往往要靠真机反复测试才能踩准。
