burntsushi/toml是go中解析toml最稳最轻量的只读方案，字段须首字母大写、类型严格匹配，嵌套表需对应导出struct，表数组必须用切片接收，decodefile返回解析键数便于校验漏配。
burntsushi/toml 是当前 Go 项目中解析 TOML 最稳、最轻量的选择，但只读不写；如果你只需要启动时加载一次配置，它比 viper 更直接、错误提示更清晰，也比 pelletier/go-toml/v2 更少抽象、更容易调试。
字段名必须首字母大写，否则解析后全是零值
Go 反射无法访问小写字段，toml.DecodeFile 会静默跳过它们，不报错但值永远是零值（0、空字符串、false）。
- 错误写法：
type Config { port int }→config.Port永远是0 - 正确写法：
type Config { Port int }，对应 TOML 中的port = 8080（默认按小写匹配） - 若 TOML 键是
PORT = 8080，则需加 tag：Port int `toml:"PORT"` - 嵌套表如
[database]必须对应导出字段：Database DatabaseConfig `toml:"database"`，不能用匿名 struct 或小写字段
数组和表数组必须类型严格匹配，否则静默失败
TOML 的 [[servers]] 是“表数组”（array of tables），不是单个 [servers] 表。Go 结构体里必须用切片接收，否则解析可能成功但字段为空或 panic。
-
[[servers]]→Servers []Server `toml:"servers"` -
[servers]（单个表）→Servers Server `toml:"servers"` - 多维数组如
hosts = [ ["a", "b"], ["c"] ]→ 字段声明为[][]string，不是[]string - 时间字段（如
created = 2025-03-29T14:22:00Z）必须是time.Time类型，否则解析失败或 panic
DecodeFile 返回键数，可用来快速判断是否漏字段
toml.DecodeFile 返回两个值：(int, error)，第一个是成功解析的键数量。这个数字比单纯看 err == nil 更有信息量。
- 若 TOML 有 12 个键，但返回
5，说明大部分字段没映射上 —— 很可能是结构体字段未导出、tag 写错、或类型不兼容 - 常见陷阱：TOML 写了
port = "8080"（字符串），但结构体定义Port int→ 解析失败，该键不计入计数，也不报错（除非开启严格模式） - 建议在开发期加一行日志：
log.Printf("parsed %d keys", n)，配合配置文件人工核对
别混用库，struct tag 和 API 完全不通用
burntsushi/toml、pelletier/go-toml/v1、pelletier/go-toml/v2 三者之间不能混用：struct tag 解析逻辑不同，API 不兼容，错误处理方式也不同。
-
burntsushi/toml只认toml:"xxx"，不支持omitempty等选项 -
pelletier/go-toml/v2支持toml:",omitempty"和格式控制，但它的Unmarshal不识别burntsushi的 tag - 一个项目里同时 import 两个库，再用同一套 struct，大概率部分字段解析失败且难以定位
- 如果后续需要写入 TOML，不要硬扛着改
burntsushi，直接切到pelletier/go-toml/v2并重定义 struct
os.Stat("config.toml") 先检查，比反复猜 err 是什么更有用。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
