gopkg.in/ini.v1 是读取 ini 文件最稳妥的选择，支持节、键值对、注释、内嵌变量、类型转换和结构体绑定；需显式处理路径、检查错误、用 Exists() 判断键存在，SaveTo() 不保证原子性且会丢失格式。
用 gopkg.in/ini.v1 读取 ini 文件最稳妥
Go 标准库不支持 ini，必须依赖第三方库；gopkg.in/ini.v1 是目前最成熟、文档清晰、维护活跃的选择。它支持节（section）、键值对、注释、内嵌变量（${key}）、类型转换和结构体绑定，覆盖绝大多数真实项目需求。
安装命令：
go get gopkg.in/ini.v1
- 不要用已归档的
github.com/go-ini/ini（v1 分支已迁至 gopkg.in） - 避免使用
github.com/spf13/viper单独读 ini：它抽象层太厚，报错信息模糊，ini 特性支持不如原生库完整（比如 section 继承、原始注释保留） - 若配置项极少且无节，可用
bufio.Scanner手动解析，但极易漏掉空行、分号注释、引号包裹值等边界情况，不推荐
加载时注意文件路径和错误处理
ini.Load() 不会自动处理相对路径——它按当前工作目录（os.Getwd()）解析，不是按源文件位置。线上运行时容易因启动路径不同导致 open config.ini: no such file or directory。
- 推荐显式构造绝对路径：
cfgPath := filepath.Join(filepath.Dir(os.Args[0]), "config.ini")
- 必须检查
err：即使文件存在，ini 语法错误（如未闭合引号、非法字符在 key 名中）会导致cfg为nil，直接调用cfg.Section().Key()会 panic - 常见错误信息示例：
line 5: invalid section name "db.port"（section 名不能含点）或line 12: invalid key name ""（空 key）
用 cfg.Section().Key().String() 取值比结构体绑定更可控
结构体绑定（cfg.MapTo(&conf)）看似简洁，但隐式行为多：默认值覆盖、类型转换失败静默忽略、大小写敏感策略难干预。调试时很难定位为什么某个字段没被赋值。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 显式取值能精确控制每一步：
port := cfg.Section("server").Key("port").MustInt(8080) -
MustInt()/MustBool()等方法自带默认值，避免判空；Value()返回原始字符串，适合需要自定义解析的场景（如逗号分隔列表） - section 不存在时
cfg.Section("xxx")不返回 error，而是返回一个空 section，其Key()也返回空 key —— 所以务必用Key().Exists()判断键是否存在，而非只看Key().String()是否为空字符串
写入 ini 文件需手动调用 SaveTo()，且不支持原子写入
ini.File 默认只读；修改后必须显式调用 cfg.SaveTo("path") 才会落盘。没有类似 os.WriteFile 的原子写入能力，进程崩溃可能导致配置损坏。
- 若需安全更新，先写临时文件（
cfg.SaveTo(tempPath)），再用os.Rename()原子替换原文件 -
Key().SetValue()修改的是内存副本，不影响磁盘；多次修改后一次SaveTo()即可，无需每次改完都保存 - 注意：
SaveTo()会抹掉原始文件中的手工注释和格式（空行、缩进），仅保留语义内容。不要把 ini 当作用户可编辑的文档来维护
ini 解析的坑主要在路径、错误传播和默认行为上——不是语法难，而是那些没报错却读不到值、或读到意外默认值的情况最难排查。
