Viper 默认不支持 XML，需导入 xml 包并调用 SetConfigType("xml")；XML 解析依赖标签嵌套结构，字段须导出并加 xml tag；大小写敏感，热重载需手动实现。
Go 用 Viper 读 XML 配置时为啥总报 Unsupported Config Type
Viper 默认不支持 XML，必须显式注册解码器，否则哪怕文件存在、路径正确，也会卡在 viper.ReadInConfig() 报错 Unsupported Config Type。
实操上要两步：先导入 github.com/spf13/viper/xml（注意不是 viper 主包），再调用 viper.SetConfigType("xml") 显式声明类型——即使后缀是 .xml，Viper 也不会自动推断。
- 别漏掉
import _ "github.com/spf13/viper/xml"，下划线导入是为了触发包内init()注册 XML 解码器 -
viper.SetConfigName("config")和viper.AddConfigPath("./conf")要在ReadInConfig()前调用 - 如果配置文件带 XML 声明（如
<?xml version="1.0"?>），Viper 能处理；但注释（<!-- -->）不影响加载，无需删
XML 结构怎么写才让 Viper 正确映射到 Go struct
Viper 解析 XML 时按标签名逐层展开，不依赖属性或命名空间，只认嵌套层级和标签文本内容。它不会把 <host>localhost</host> 自动转成 struct 字段，得靠 viper.Unmarshal() 或手动 GetString() 提取。
推荐用 viper.Unmarshal() + Go struct，比链式 GetString("server.host") 更安全、可维护。struct 字段必须导出（大写首字母），且建议加 xml tag 明确对应关系。
立即学习“go语言免费学习笔记（深入）”；
- XML 中
<database><host>127.0.0.1</host><port>5432</port></database>对应 struct 字段Host string `xml:"host"` - 数组需用重复标签，例如多个
<item>foo</item><item>bar</item>可映射为[]string `xml:"item"` - 属性（如
<log level="debug">）不会被默认解析，要用xml:",attr"tag 单独声明字段
为什么 viper.Get("xxx") 返回 nil 或空字符串
常见原因是路径大小写不一致或层级断裂。XML 是大小写敏感的，<DB> 和 <db> 在 Viper 里是两个 key；另外，Viper 的 key 路径是用点号分隔的，但 XML 标签名本身不能含点，所以路径完全取决于你写的标签名嵌套结构。
- 检查实际 XML 标签名是否全小写，比如
<server><port>8080</port></server>，那就要用viper.GetInt("server.port")，不是"Server.Port" - 如果 XML 有根节点（如
<config><server>...</server></config>），key 路径就得带上config.server.port，除非你用viper.SetConfigName时已隐含根名 - 用
viper.AllKeys()打印所有已加载 key，确认结构是否符合预期，比盲猜快得多
XML 配置热重载不生效？Viper 的 WatchConfig 本身不支持 XML 文件变更监听
viper.WatchConfig() 底层依赖 fsnotify，它能监听文件变化，但 Viper 不会自动重新解析 XML —— 它只对 JSON/YAML/TOML 等部分格式做了内置重载逻辑，XML 没包含在内。
真要热重载 XML，得自己补一层：监听文件事件后，手动调用 viper.ReadInConfig()，并确保之前已设置好 config name/path/type。不过要注意并发读写冲突，生产环境建议加锁或用 channel 控制重载节奏。
- 别直接在
OnConfigChange回调里调viper.Unmarshal()，先确保ReadInConfig()成功返回 - XML 解析失败时
ReadInConfig()会 panic，务必用recover或提前校验文件内容合法性 - 如果只是开发期调试，用
go run配合air或fresh重启进程，比手写热重载更稳
XML 不是 Viper 的一等公民，很多细节得自己兜底，比如大小写、根节点、属性解析、热重载——这些地方不踩一次坑，很难意识到它和 YAML 的行为差异有多大。
