Go 解析 INI 配置：路径与 BOM 问题才是导致崩溃的元凶
说到 Go 语言解析 INI 配置文件，很多开发者初次尝试就会 panic——问题往往并非配置内容写错，而是加载阶段直接崩溃。典型错误如 open config.ini: no such file or directory，或者 line 5: invalid section name "db:port"。这些错误与键值对内容无关，只与文件路径、编码格式以及节名合法性有关。可以说，真正棘手的并非语法解析本身，而是那些前置条件未能满足，导致后续所有操作都建立在不可靠的基础上。
Go ini.Load() 为何一调用就发生 panic
根本原因并非配置编写错误，而是加载阶段就已崩溃。常见现象是 open config.ini: no such file or directory 或 line 5: invalid section name "db:port" —— 这些错误与键值内容无关，只与路径、编码、节名合法性有关。
- 路径必须使用绝对路径：传入
"config.ini"会基于os.Getwd()解析，而线上环境中二进制启动目录与配置文件通常不在一起；建议改用filepath.Join(filepath.Dir(os.Args[0]), "config.ini")获取绝对路径 - BOM 头必须手动清除：UTF-8 编码的文件若包含 BOM（
\xef\xbb\xbf），ini.Load()不会自动去除；需要先通过os.ReadFile()读取内容，再使用bytes.TrimPrefix(data, []byte("\xef\xbb\xbf"))移除 BOM，最后调用ini.LoadSources()加载 - 节名和键名有硬性限制：
[db.port]合法，但[db:port]、[db-port]、[ db ]（前导空格）都会报错；键名不能为空或以空格开头 - 必须检查
err：一旦err != nil，返回的cfg为nil，后续任何.Section()调用都会直接 panic
尤其在线上部署时，os.Getwd() 和 os.Args[0] 的差异几乎是必踩的坑。
嵌套节名并非“嵌套”，只是字符串命名约定
[database.mysql] 和 [database] 完全无关，go-ini 库不做递归挂载，也不支持继承。它把整个 database.mysql 当作一个独立节名字符串处理，这一点与 Python 的 configparser 行为不同，容易造成误解。
- 动态选择节需拼接字符串：例如
env := "prod"→cfg.Section("redis." + env)，而不是指望cfg.Section("redis").Section(env)这种链式调用 - 点号仅是约定，
cfg.Section("database.mysql")和cfg.Section("database/mysql")是两个完全独立的节 - 没有 fallback 机制：想要复用
host值，必须手动读取cfg.Section("database").Key("host").String()，再 fallback 到cfg.Section("database.prod").Key("host").String()
类型转换别依赖 String()，优先使用 Must 方法
Key().String() 返回空字符串，Key().Int64() 解析失败时返回 0 —— 这种静默失败对数字和布尔类型极其危险。例如配置写了 timeout = 30s，.Int64() 直接返回 0，程序看似正常运行但逻辑已错乱。
- 一律使用
MustInt64(30)、MustBool(true)等带Must前缀的方法，并传入合理的默认值 - 包含单位的字段（如
timeout = 5s）不要依赖自动类型转换，应该先用.String()获取字符串，再通过time.ParseDuration()解析 .String()不会修剪空格，需要干净值时请自行调用strings.TrimSpace()- 判断键是否存在必须使用
.Exists()，而不是通过.String()是否为空来判断——空字符串也是合法值
写入不原子，SaveTo() 会丢失格式
ini.File 默认只读；修改后必须显式调用 cfg.SaveTo("path") 才会落盘。该函数不提供原子写入能力，进程崩溃可能导致配置损坏，并且会丢失原始注释、空行、缩进等格式信息。
- 不要依赖
SaveTo()做生产环境的热更新 - 若需要保留格式，建议只读取原文件，然后生成新文件 + 使用
os.Rename()替换（模拟原子写入） - 结构体绑定（
MapTo()）隐式行为过多：大小写策略难以控制、类型失败时静默忽略、默认值覆盖逻辑不清晰；显式取值方案更可控
总而言之，困扰开发者的并非 INI 语法解析的复杂性，而是文件路径、BOM 编码、节名合法性这些前置条件未能正确判断，导致所有后续操作都建立在脆弱的基础上。尤其是在线上部署场景中，os.Getwd() 与 os.Args[0] 的差异几乎是必踩的坑，提前在测试阶段踩一遍，远胜于在生产环境中崩溃一次。
