不能直接改老代码而要加适配器，因为旧XML接口被多系统调用、上线紧、测试成本高，动解析逻辑会触发全链路回归，而新JSON API需严格遵循Swagger字段名与结构；适配器是隔离变更的必要边界。
为什么不能直接改老代码，而要加适配器
因为旧 XML 接口被多个下游系统调用，上线时间紧、测试成本高，动 ParseXML 或 WriteXML 会触发全链路回归；新 JSON API 又必须按 Swagger 定义的字段名和嵌套结构返回。硬改等于重写，风险远高于包一层——适配器不是过渡方案，是隔离变更的必要边界。
Adapter 结构体怎么设计才不泄漏 XML 细节
关键在「只暴露 JSON 侧契约」：Adapter 不该有 xml.Unmarshal 相关字段，也不该把 XMLNode 类型透传出去。它只接收原始 XML 字节或字符串，只返回符合新 API 的 struct 指针或 error。
- 输入用
[]byte或io.Reader，避免依赖具体 XML 解析库（比如别用xml.Decoder做成员变量） - 输出 struct 必须用
jsontag，且字段名与新 API 文档完全一致，例如UserID对应"user_id" - 绝不导出内部 XML 模型，哪怕只是临时解析用，也定义在 adapter 包内匿名 struct 或私有类型里
// ✅ 正确：对外只承诺 JSON 结构
type UserJSON struct {
UserID int `json:"user_id"`
FullName string `json:"full_name"`
}
func (a *XMLToJSONAdapter) Convert(xmlData []byte) (*UserJSON, error) { ... }
// ❌ 错误：把 XML 模型暴露出去
type UserXML struct { XMLName xml.Name `xml:"user"` ... }
func (a *XMLToJSONAdapter) Parse(xmlData []byte) (*UserXML, error) { ... }
处理字段映射时最容易踩的空指针和类型错位
XML 常有可选字段、空字符串、数字混成字符串（如 <age>25</age> vs <age></age>），JSON API 却要求 int 字段非空。直接 strconv.Atoi 会 panic，用 xml.Unmarshal 到 struct 再转又容易漏判零值。
- 对数值字段，先用
strings.TrimSpace清空再判断是否为空，再尝试转换，失败就返回明确 error（如fmt.Errorf("invalid age: %q", rawAge)） - 对布尔字段，XML 常用
"true"/"false"、"1"/"0"、甚至空标签，统一收口到一个parseBoolFromXML工具函数 - 嵌套结构别硬解两层，用
xml.Unmarshal到中间 struct 后，立刻校验关键字段是否存在，避免后续访问user.Profile.Name时 panic
要不要在 Adapter 里做 HTTP 请求转发
不要。Adapter 的职责是数据格式转换，不是网络调度。如果旧接口是 HTTP XML 端点，应该由上层 handler 调用 http.Client 获取响应体，再把 resp.Body 交给 Adapter；同理，新 API 的响应写入也该由 handler 控制 json.NewEncoder(w)。
立即学习“go语言免费学习笔记（深入）”；
- Adapter 保持无副作用，方便单元测试（喂入字节，断言输出 struct）
- HTTP 超时、重试、鉴权这些逻辑放在 handler 层，和 Adapter 解耦
- 如果真要复用连接池，把
*http.Client当参数传进 Convert 方法，而不是存在 Adapter 实例里
复杂点永远在字段语义对齐——比如 XML 里的 <status>active</status> 要映射成 JSON 的 "status": 1，这种业务规则不能藏在适配器深处，得显式写成映射表或 switch 分支，否则半年后没人记得当初为什么 active=1。
