xml.unmarshal不适合大xml解析，因其需全量加载并构建dom树，100mb文件常占300mb+内存；应改用xml.newdecoder流式解析，内存稳定在几mb。
大 XML 或 HTML 文件一解析就 OOM？不是代码写错了，是选错了 API —— xml.Unmarshal 和 html.Parse 本身就不适合流式场景，必须换用 xml.NewDecoder 或 html.NewTokenizer 才能稳住几 MB 内存。
为什么 xml.Unmarshal 一上大文件就崩
xml.Unmarshal 必须先把整个输入读进 []byte，100MB XML 实际内存占用常超 300MB；而 xml.NewDecoder 基于 io.Reader，边读边解，内存只跟当前节点深度和字段长度有关，稳定在几 MB 级别。这不是“调优能救”，是设计层面的不匹配。
- 别碰
os.ReadFile+xml.Unmarshal组合，哪怕加了//nolint也挡不住 OOM - HTTP Body、gzip 压缩流、日志归档文件——这些都该直接传给
xml.NewDecoder，中间不落地 - 结构极简单且确定永远 xml.Unmarshal 反而更直觉，没必要硬套流式
DecodeElement 后字段全为零值的真凶
常见错误是循环读 Token() 却忘了调用 decoder.DecodeElement(&v, &se)，结果结构体字段始终是零值，还查不出错在哪。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 进入目标节点后，必须用刚读到的
StartElement实例（即&se）传给DecodeElement，传错或传 nil 就绑定失败 - 解析完立刻调用
decoder.Skip()跳过子树，漏掉这步会导致后续 token 流彻底错位 - 想提前退出循环？先调一次
decoder.Token()消费掉当前 token，再break或return
命名空间匹配总失败？别硬编码 Local
只要 XML 带 xmlns="http://example.com/ns"，StartElement.Name.Space 就非空，硬编码 "item" 必然失败。
- 方案一：解析前设
decoder.DefaultSpace = "http://example.com/ns"，之后所有无前缀标签按此 URI 处理 - 方案二：匹配时同时校验
token.(xml.StartElement).Name.Space == nsURI&&token.(xml.StartElement).Name.Local == "item" - 别用
xml.Name{Local: "item"}去比对——Name是输出结构，不是匹配工具 - 上游用前缀如
dc:title，注意token.Name.Space存的是 URI，不是前缀字符串
CharData 里的空格和 Skip 漏调是两个隐形炸弹
xml.Decoder 不自动跳过注释或空白文本节点，xml.CharData 类型 token 里可能全是换行和空格；漏调 decoder.Skip() 会让后续所有 token 错位，解析结果完全不可信。
- 遇到
xml.CharData，必须手动strings.TrimSpace，否则前后空格混进字段 -
decoder.Skip()是状态机关键一环，嵌套深时尤其容易漏，建议每个DecodeElement后紧跟它 - 这两个点一旦出错，token 流就乱序，后面所有解析逻辑都失效，但错误现象往往表现为“字段为空”或“解析跳过部分节点”，很难定位
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
