gopkg.in/ini.v1 默认区分 section 大小写，需显式启用 Insensitive:true；JSON 解析要求字段导出且正确声明 json tag；INI 与 JSON 混用时环境变量覆盖需手动实现，错误提示粒度差异大，易静默失败。

用 gopkg.in/ini.v1 读取 INI 文件时，section 名区分大小写

INI 文件默认按 section 名做键匹配，而 gopkg.in/ini.v1 的 GetSection() 和 Sections() 默认区分大小写。若配置中写的是 [Database]，但代码里调用 cfg.GetSection("database")，会返回 nil，不报错也不提示。

• 显式调用 cfg.SectionStrings() 查看所有实际 section 名，确认大小写
• 初始化时传入 ini.LoadOptions{Insensitive: true} 启用不区分大小写的查找
• 避免在 section 名中混用下划线和驼峰（如 [db_config] vs [DBConfig]），统一团队命名约定

cfg, err := ini.LoadSources(ini.LoadOptions{Insensitive: true}, "config.ini")
if err != nil {
    log.Fatal(err)
}
dbSec := cfg.Section("database") // 现在能匹配 [Database] 或 [DATABASE]

解析 JSON 配置时，结构体字段必须导出且带 json tag

Go 的 encoding/json 只能序列化/反序列化导出字段（首字母大写），且若字段名与 JSON key 不一致，必须用 json: tag 显式声明。漏掉 tag 或写错 key 名会导致字段始终为零值，无错误提示。

• 检查结构体字段是否首字母大写；小写字段（如 port int）永远读不到值
• json:"port" 和 json:"port,string" 行为不同：后者会把字符串格式的数字（如 "8080"）自动转为 int
• 使用 json:",omitempty" 可跳过零值字段，但注意布尔类型 false、整型 0 也会被忽略

type Config struct {
    DBHost string `json:"db_host"`
    DBPort int    `json:"db_port,string"`
    Debug  bool   `json:"debug,omitempty"`
}
var cfg Config
if err := json.Unmarshal(data, &cfg); err != nil {
    log.Fatal(err)
}

混合使用 INI 和 JSON 配置时，环境变量覆盖逻辑需手动实现

INI 和 JSON 库本身都不支持像 viper 那样自动按优先级合并多源配置。若你同时加载 config.ini 和 config.json，再想用 os.Getenv("DB_PORT") 覆盖其中某项，必须自己写逻辑——库不会帮你做 fallback。

• 建议先加载基础配置（如 JSON），再用 INI 做可选覆盖，最后逐字段检查 os.Getenv()
• 对数值型字段，用 strconv.Atoi(os.Getenv("X")) 并判断 error，别直接强制转换
• 避免在多个配置源中重复定义同一字段，否则难以调试最终生效的是哪一份

读取失败时，ini 和 json 的错误信息粒度差异很大

encoding/json 在解析失败时通常只报“invalid character … at offset N”，不指明是哪个字段；而 gopkg.in/ini.v1 报错更具体，例如 “line 12: unknown field 'log_level' in section 'server'”。这意味着 JSON 配置出错更难定位。

• JSON 场景下，建议先用在线校验工具（如 jsonlint.com）验证原始内容语法正确
• INI 场景下，注意 Windows 换行符（\r\n）可能导致解析器误判行号，用 unix2dos 或编辑器转 LF
• 无论哪种格式，都应在 defer 中关闭文件句柄，并检查 os.Open 是否出错——这是最常被忽略的第一道关卡