根本原因是结构体字段未导出（首字母小写），导致json/xml/gconv等工具静默忽略嵌套字段，解码后为零值且不报错；所有中间层字段必须大写导出，并确保指针初始化与类型定义一致。
深层嵌套结构体在跨模块传递时数据丢失，根本不是“传不进去”，而是字段未导出、指针未初始化、或转换逻辑跳过了中间层——Go 不会自动穿透私有字段，也不会帮你 new 指针。
结构体字段未导出导致序列化/转换时静默丢弃
Go 的 json/xml/gconv 等工具只处理首字母大写的导出字段。如果嵌套结构体里有 name string（小写），哪怕它在 User 里嵌套十层，最终解析出来也是空值，且不报错。
- 检查所有中间层结构体字段：必须是
Name string，不能是name string - 特别注意 map 或 interface{} 中动态解出来的子结构——它们的字段也得导出，否则
json.Unmarshal后仍是零值 - 用
go vet -v可检测未导出字段被用于 JSON/XML 标签的可疑用法
gconv.Scan 处理嵌套指针字段时 nil 值不自动初始化
当源结构体字段是值类型（如 string），目标结构体对应字段是指针（如 *string），gconv.Scan 默认不会为指针分配内存，结果就是 nil，后续访问 panic。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须显式启用指针初始化：
gconv.ScanWithOptions(src, &dst, gconv.ScanOption{PointerInitialization: true}) - 该选项只对一级指针生效；若嵌套结构体内部还有指针字段（如
Config struct{ Name *string }），需确保整个路径上每一层都参与转换，不能只传src.Config给&dst.Config单独转 - 避免混用值类型和指针类型定义——同一业务对象在不同模块中定义成
Name string和Name *string，是跨包数据丢失的高发源头
XML 解析时路径断裂导致中间层级“消失”
XML 是树，Go 结构体也得是树。如果 XML 是 <root><data><items><item></item></items></data></root>，而你只在顶层定义 Items []Item `xml:"item"`，那 <data></data> 和 <items></items> 这两层没人接，item 就永远读不到。
- 要么老老实实嵌套定义：
Data struct { Items []Item `xml:"items>item"` }，再让外层字段指向它 - 要么用路径式标签，但注意：多级路径如
"root>data>items>item"在某些 Go 版本中支持不稳定，建议拆成两级以内，例如"data>items" + "item"分步解析 - 调试时先用
xml.Unmarshal到map[string]interface{}看原始结构，确认层级是否真如预期
JSON 多层嵌套中 json.RawMessage 未判空直接解码
用 map[string]json.RawMessage 提取未知结构时，key 对应的 value 可能是 JSON null，此时 json.RawMessage 是长度为 0 的切片，直接 json.Unmarshal 会静默失败，字段保持零值。
- 每次解码前必须检查：
if len(raw) > 0，不能只靠ok判断 key 是否存在 - 不要对
json.RawMessage做string(raw)或正则匹配——它不含格式保证，可能带换行或多余空格 - 若 key 集合固定（如仅
"user"/"config"），优先定义具体结构体 +json.RawMessage字段组合，比全用interface{}更安全可控
最易被忽略的一点：跨模块传递嵌套结构体时，别依赖“看起来一样”的字段名和类型。两个包各自定义的 User，哪怕字段完全一致，只要没共享类型定义或没做显式转换，Go 就认为它们是不同类型——接口断开、反射失效、gconv 不识别，数据就卡在边界上出不来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
