应统一响应格式封装：根据Accept头自动选JSON/XML/Protobuf，显式设Content-Type与charset，XML需xml:""标签，Protobuf须注册类型，共用错误结构。
Go HTTP handler里怎么统一处理JSON/XML/Protobuf响应格式
直接用 http.ResponseWriter 写不同格式容易漏掉 Content-Type、状态码不一致、错误路径不统一。核心是把序列化逻辑和响应包装抽离，让 handler 只关心业务数据。
推荐用一个中间层函数封装：接收任意结构体 + 请求的 Accept 头，自动选格式并写响应。不要在每个 handler 里重复写 json.Marshal 或 xml.Marshal。
-
Accept头为空或*/*时，默认走 JSON（兼容性最好） - 显式声明
application/xml或application/x-protobuf才触发对应格式 - Protobuf 需要提前注册
proto.Message实现，且响应体必须是预编译的.pb.go类型 - 所有格式共用同一套错误结构（比如
{ "error": "xxx", "code": 400 }），避免前端解析逻辑分裂
为什么 encoding/xml 默认不支持 struct tag 里的 json: 字段别名
因为 xml 包只认 xml: tag，和 json: 完全无关。混用会导致字段丢失或空值，尤其在共享 struct 同时用于 JSON 和 XML 响应时。
常见错误现象：json.Marshal 正常输出 "user_name"，但 xml.Marshal 输出的是 <username>xxx</username>，前端收不到预期字段名。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须显式加
xml:"user_name"tag，且注意大小写——XML 标签名区分大小写，Go 字段首字母大写不影响 tag 解析 - 如果字段同时导出给 JSON 和 XML，建议统一用
json:"user_name" xml:"user_name" - 嵌套结构中，
xml:",omitempty"和json:",omitempty"行为一致，但xml:"-"会跳过字段，而json:"-"是标准写法
Protobuf 响应在 Go HTTP 中怎么避免 marshal: type not registered
这个错误不是代码写错了，而是 Protobuf 消息类型没被 google.golang.org/protobuf/encoding/protojson 或 encoding/xml 等包识别。HTTP handler 里直接传 *MyProtoMsg 给 proto.Marshal 没问题，但若用了封装的通用响应函数，就容易漏注册。
根本原因是：Protobuf 的反射信息需要在运行时注册，尤其是用 any.Any 或动态消息时。
- 确保
import _ "your-project/pb"（下划线导入 proto 生成的包），触发 init 函数注册 - 检查生成的
.pb.go文件里是否有func init() { proto.RegisterMap(...)类似语句 - 不要用
interface{}包装 proto 消息再传给通用 marshaler——它无法推断具体类型 - 测试时用
curl -H "Accept: application/x-protobuf" ...，别只测 JSON
Content-Type 和 charset 在 JSON/XML/Protobuf 中要不要手动设
要，而且必须精确。Go 的 http.ServeContent 不会自动补 charset=utf-8，而浏览器和某些客户端对缺失 charset 的 XML/JSON 行为不一致。
Protobuf 是二进制，不能带 charset；JSON 和 XML 则建议显式声明，尤其当响应含中文等非 ASCII 字符时。
- JSON：设
w.Header().Set("Content-Type", "application/json; charset=utf-8") - XML：设
w.Header().Set("Content-Type", "application/xml; charset=utf-8")，且 XML 声明里也要写<?xml version="1.0" encoding="UTF-8"?> - Protobuf：只设
"application/x-protobuf"，加 charset 会被客户端拒绝 - 别依赖
http.DetectContentType——它只看前 512 字节，对 protobuf 完全无效
格式切换看着只是改几行代码，但 Accept 解析顺序、错误响应一致性、charset 缺失导致的乱码、Protobuf 类型注册遗漏——这些点一旦漏掉，线上就只能靠日志硬查。
