ini.load() 一调就 panic 的根本原因不是配置内容错误，而是加载阶段路径错误、utf-8 bom 未清除、节名或 key 名含非法字符（如冒号、短横线、前导空格）、未检查 err 导致 cfg 为 nil 后续调用崩溃。
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()不会自动 strip；先os.ReadFile()，再bytes.TrimPrefix(data, []byte("\xef\xbb\xbf"))，最后用ini.LoadSources() - 节名和 key 名有硬限制：
[db.port]合法，[db:port]、[db-port]、[ db ]（前导空格）都会报错；key 名不能为空或以空格开头 - 必须检查
err：一旦err != nil，返回的cfg是nil，后续任何.Section()都直接 panic
嵌套节名不是“嵌套”，只是字符串命名
[database.mysql] 和 [database] 完全无关，go-ini 不做递归挂载，也不支持继承。它把整个 database.mysql 当作一个独立节名字符串处理，这点和 Python 的 configparser 行为不同，容易误解。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 动态选节得拼字符串：
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()不 trim 空格，需要干净值就自己strings.TrimSpace() - 判断键是否存在必须用
.Exists()，不是看.String()是否为空 —— 空字符串也是合法值
写入不原子，SaveTo() 会丢格式
ini.File 默认只读；修改后必须显式调用 cfg.SaveTo("path") 才会落盘。它不提供原子写入能力，进程崩溃可能导致配置损坏，且会丢失原始注释、空行、缩进等格式信息。
- 不要依赖
SaveTo()做生产环境配置热更新 - 若需保留格式，建议只读取 + 生成新文件 +
os.Rename()替换（模拟原子写） - 结构体绑定（
MapTo()）隐式行为太多：大小写策略难控、类型失败静默忽略、默认值覆盖逻辑模糊；显式取值更可控
os.Getwd() 和 os.Args[0] 的差异几乎必踩。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
