直接用 go-ini/ini@v1.67.0 加载后做显式校验更可靠，90% 线上配置异常源于节名拼错、key 不存在或类型转换失败；必须检查 err、路径合法性、BOM、节名字符合法性（禁用冒号/短横线）、大小写匹配，并优先使用 Must 系列方法设默认值。
直接用 go-ini/ini@v1.67.0 加载后做显式校验，比写正则或手写 parser 更可靠；但不校验就直接取值，90% 的线上配置异常都源于节名拼错、key 不存在或类型转换失败。
加载阶段必须检查 err 和路径合法性
ini.Load() 返回 nil 不代表文件读到了，只说明加载失败——常见原因不是配置内容错，而是路径不对、BOM 未清除、节名含非法字符（如冒号、短横线）。
- 别传相对路径
"config.ini"：它按os.Getwd()解析，而线上二进制启动目录和配置常不在一起；改用filepath.Join(filepath.Dir(os.Args[0]), "config.ini") - UTF-8 BOM 必须手动清除：读取后先
bytes.TrimPrefix(data, []byte("\xef\xbb\xbf"))，再用ini.LoadSources()加载字节流 - 节名只允许字母、数字、下划线、点号和空格；
[db.port]合法，[db:port]或[db-port]会直接报invalid section name - 务必判断
err != nil：一旦出错，cfg是nil，后续任何.Section()都 panic
节与键存在性不能靠 “不 panic” 来推断
默认 strict mode 下，cfg.Section("mysql") 找不到节就 panic；即使开了 Loose: true，返回空节也不等于“存在”，.Key("host").String() 还是空字符串——这容易掩盖配置缺失问题。
- 显式检查节是否存在：
cfg.HasSection("mysql")，而非依赖链式调用兜底 - 键存在性必须用
.HasKey("host")或.Key("host").Exists()，因为.String()对不存在的 key 也返回空串 - 嵌套节如
[database.mysql]是独立节名，不是database的子节；cfg.Section("database.mysql")和cfg.Section("database")完全无关 - 大小写敏感默认开启：配置里是
[Database]，代码写cfg.Section("database")就查不到；加Insensitive: true选项才匹配
类型转换必须用 Must 系列方法并设合理默认值
.Int64() 或 .Bool() 这类无 Must 前缀的方法，在 key 不存在、值为空或格式错误时一律返回零值（0、false），程序静默跑偏；比如 timeout = 30s 被当整数解析，结果得 0。
立即学习“go语言免费学习笔记（深入）”；
- 优先用
.MustInt64(30)、.MustBool(true)等，明确 fallback 行为 - 带单位的字段（如
timeout = 5s）别让go-ini自动转：先.String()读出原始值，再用time.ParseDuration() -
.String()不 trim 空格：若配置写成host = 127.0.0.1，取出来就是带空格字符串；需手动strings.TrimSpace() - 结构体绑定（
MapTo()）隐式行为太多，调试困难；建议显式逐 key 取值，控制每一步
验证逻辑要覆盖真实部署场景
本地跑通 ≠ 线上可用。很多验证漏掉了跨环境差异：比如开发机配置有 [redis.dev]，但生产启动时没传环境变量，代码却硬写 cfg.Section("redis." + env).Key("host")，结果访问空节。
- 动态节名拼接前，先确认该节真实存在：
cfg.HasSection("redis." + env) - 插值语法（如
%(host)s）默认关闭，需显式启用AllowPythonInterpolation: true，且只支持同节或[DEFAULT]中的 key - 并发读写不安全：若配置热更新，需自己加
sync.RWMutex，go-ini本身不保证 -
SaveTo()不原子：崩溃可能损坏配置文件；生产环境写入应先写临时文件，再os.Rename()
真正难的不是解析语法，而是让配置在各种路径、编码、大小写、缺失字段、单位混用、环境变量注入等现实条件下依然可预期地工作——这些细节不写进验证逻辑，就永远在救火。
