go无法原生处理word和excel，必须依赖第三方库：word解析首选纯go的baliance/gooxml（仅支持.docx，跨平台稳定），excel读写强烈推荐excelize（支持公式、日期等，需手动判类型）；com方式（go-ole）仅限windows+office环境，不可跨平台。
直接说结论：Word 和 Excel 在 Go 里不能靠标准库搞定，必须用第三方库；但选哪个、怎么用、在哪踩坑，差别很大——尤其 Word 解析和 Excel 读取的底层逻辑完全不同，混用同一套思路会出错。
Word 解析优先用 baliance/gooxml，别碰 COM
Windows 上用 go-ole 调 Word COM 接口（比如 oleutil.CreateObject("Word.Application")）看似能转 PDF 或提取文本，但实际部署在 Linux/macOS 就直接失效，且依赖 Office 安装、权限高、进程难管理。生产环境几乎不用。
-
baliance/gooxml是纯 Go 实现，只解析 .docx（不支持 .doc），无需外部依赖，跨平台稳定 - 它把文档结构映射为
document.Paragraphs()→para.Runs()→run.Text()，适合提取正文、标题、列表等语义内容 - 不支持页眉页脚、批注、OLE 对象等复杂元素；表格内容需额外遍历
para.Tables()，不是所有表格都能正确还原嵌套结构 - 示例中
doc.Paragraphs()返回的是段落切片，但空段落、分节符、样式继承不会自动过滤，需自己判空或跳过
Excel 读取强烈推荐 excelize，tealeg/xlsx 已过时
tealeg/xlsx 库自 2021 年后基本停止更新，读取含公式、条件格式、日期时间的单元格常返回 nil 或错误类型（比如 f.GetCellValue("Sheet1", "A1") 返回 "" 而不是实际值），且大文件内存占用爆炸。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
-
excelize支持 .xlsx/.xlsm/.xltx/.xltm，能正确处理 Excel 内部时间戳（time.FromExcelTime(44562.5, false)）、共享字符串表、合并单元格边界 - 读取前务必检查工作表是否存在：
if f.GetSheetCount() == 0，否则f.GetSheetRow("Sheet1", 1)会 panic - 单元格值类型需手动判断：
f.GetCellType("Sheet1", "A1")返回excelize.CellTypeNumber或CellTypeString，不能直接用string()强转 - 中文列宽默认 8.43 字符，显示不全；必须调用
f.SetColWidth("Sheet1", "A", "Z", 12)才能正常渲染
COM 方式仅限 Windows + Office 环境下的 PDF 导出
如果硬要转 PDF（比如 Word 转 PDF、Excel 设置页边距后导出），go-ole 是唯一可行路径，但它不是“解析”，而是启动真实 Office 进程执行操作。
- 必须在 Windows 上运行，且系统已安装对应版本的 Microsoft Office（32/64 位需匹配 Go 编译目标）
-
ole.CoInitialize(0)必须在 goroutine 开头调用，且每个 goroutine 都要配对ole.CoUninitialize()，否则资源泄漏 -
oleutil.MustCallMethod(document, "SaveAs2", "out.pdf", 17)中的17是 PDF 格式常量，写错会静默失败（不是报错） - 后台无界面时（如服务端），需设置
oleutil.PutProperty(word, "Visible", false)，但某些 Office 版本仍会弹窗卡住进程
真正容易被忽略的是：Word 和 Excel 的“解析”目标不同——Word 关注语义结构（段落、样式、层级），Excel 关注网格坐标与数据类型；用同一个库或同一套错误处理逻辑去套两者，十有八九会在空单元格、合并单元格、日期格式或隐藏工作表上翻车。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
