xml.Unmarshal会将XML文本节点深拷贝为新字符串，导致内存激增；应改用[]byte字段或xml.Decoder流式处理避免OOM。
xml.Unmarshal 会把整个 XML 字符串拷贝进结构体字段吗
会，而且不止一次。Go 的 xml.Unmarshal 在解析时，对每个文本节点（如 <name>张三</name>）默认执行深拷贝：先从底层 []byte 中切出子 slice，再转成 string 分配新内存。如果原始 XML 里有多个 1MB 的 <content> 节点，每个都会生成独立的字符串对象，heap 上就是实实在在的几 MB 额外开销。
更隐蔽的是：即使你用 string 字段接收，Go 还会在内部做一次 UTF-8 验证和可能的 runtime.convT2E 封装——这对小字段无感，但遇到几百 KB 的 CDATA 或 base64 内容时，GC 压力立刻可见。
- 实测：10MB XML 含 5 个 1MB
<body>，xml.Unmarshal后 heap 峰值常达 25MB+ - 避免方式：若只需读取不修改，改用
[]byte字段 +xml:",chardata"，跳过 string 转换 - 注意：
[]byte仍共享底层数组，若后续要长期持有，需手动append([]byte{}, data...)复制
为什么结构体里放 big string 字段会导致 GC 频繁
Go 的 GC 是标记-清除式，string 底层是只读的 struct{ptr *byte, len, cap int}。当结构体字段存了大 string，它本身不参与逃逸分析判定，但它的 ptr 指向的内存块会被 GC 视为活跃对象。一旦这类结构体数量多（比如解析出几千个带 100KB 描述的 Item），heap 上就堆满离散的大块，GC 扫描和标记成本陡增。
- 典型现象：pprof 查看
runtime.mallocgc占比高，gc pause波动明显 - 验证方法：用
go tool trace看 GC event，同时对比runtime.ReadMemStats中HeapAlloc和HeapInuse差值 - 临时缓解：在解析后立即调用
runtime.GC()不解决问题，反而干扰调度；应从源头减少大 string 分配
流式解析时怎么避免大文本字段触发 OOM
用 xml.Decoder 时，别急着把所有内容 decode 到结构体。遇到大文本节点（如 <content>），直接用 decoder.Token() 拿到 xml.CharData，然后按需处理——比如写入文件、计算哈希、或仅检查长度是否超限。
立即学习“go语言免费学习笔记（深入）”；
- 关键动作：收到
xml.StartElement后，先判断是否目标大字段；若是，用循环读xml.CharData直到下一个xml.EndElement，中间不构造 string - 示例片段：
for token := decoder.Token(); token != nil; token = decoder.Token() { if t, ok := token.(xml.CharData); ok && inContent { buf.Write(t) } } - 陷阱：别在循环里反复调
string(t)，每次都会分配新 string；用buf.Write(t)复用 bytes.Buffer 更稳
结构体字段用 *string 还是 string 对内存影响更大
用 *string 反而更容易 OOM。因为每个 nil 指针本身占 8 字节没问题，但一旦赋值，就要额外分配一个 string header + 底层数组；而空的 string 字段（零值）根本不占额外内存。
- 真实代价：
*string解析时若字段存在，需 malloc 两次（指针 + 字符串数据）；string只 malloc 一次（字符串数据） - 例外场景：仅当 90%+ 的该字段为空，且你明确要用
nil表达“未设置”，才考虑*string；否则一律用string - 替代方案：若想区分“空”和“不存在”，用自定义类型封装，比如
type Content struct { Data string; Present bool }
[]byte，只要没主动复制，它就还连着原始 XML 的大 buffer——在长生命周期对象里，这等于悄悄拖住整块内存不释放。 
