Go INI 大小写不敏感模式为什么会改变节和键查找

Go INI 的大小写不敏感模式并不只是“查询时多试几种写法”。它会在创建节和键、保存到内存结构，以及后续查找时，把名称统一规范化为小写。因此，[Service] 与 [service] 可能落到同一个节，Port 与 port 也可能变成同一个键，最后表现为复用或覆盖。

官方地址：https://github.com/go-ini/ini

大小写不敏感到底改变了哪一层

默认的 ini.Load 使用空的 LoadOptions，节名和键名按原样保留。打开不敏感模式后，go-ini 会在建立内部索引时把名称转成小写，查找时也对传入名称做同样处理。

package main

import (
    "fmt"

    ini "gopkg.in/ini.v1"
)

func main() {
    text := []byte("[Service]\nPort = 8080\n") // 配置故意使用大写节名和键名

    strict, err := ini.Load(text)
    if err != nil {
        panic(err) // 读取失败时不要继续使用半成品配置
    }
    _, err = strict.GetSection("service")
    fmt.Println(err != nil) // 默认模式下，大小写不同仍可能查找失败

    loose, err := ini.InsensitiveLoad(text)
    if err != nil {
        panic(err) // 不敏感模式也必须先处理加载错误
    }
    section, err := loose.GetSection("SERVICE")
    if err != nil {
        panic(err) // 查找端使用另一种大小写仍能命中同一节
    }
    key, err := section.GetKey("port")
    if err != nil {
        panic(err) // 键名也按同一规范化规则查找
    }
    fmt.Println(section.Name(), key.Name(), key.String())
}

三个开关如何分工

LoadOptions 中的三个字段不是三个互斥模式，而是一个总开关和两个细分开关。Insensitive 为真时，节和键都会转小写；只打开 InsensitiveSections 时，节名变得不敏感，但键名仍按大小写区分；只打开 InsensitiveKeys 时则相反。

cfg, err := ini.LoadSources(ini.LoadOptions{
    InsensitiveSections: true, // 只把节名统一为小写
    // InsensitiveKeys: true,  // 只有确认键名也不区分大小写时再打开
}, []byte("[Service]\nPort = 8080\n"))
if err != nil {
    return // 配置加载失败时交给上层处理，避免继续读取错误对象
}

section, err := cfg.GetSection("service") // 节名可用任意大小写查找
if err != nil {
    return // 节不存在时不要用 Section() 静默创建新节
}
_, err = section.GetKey("port") // 仅打开节开关时，键名仍需匹配原始 Port
fmt.Println(err != nil)

这里还有一个容易忽略的区别：GetSection 和 GetKey 是显式返回错误的查找方法；Section 与 Key 在找不到时可能创建一个零值对象。排查大小写问题时优先使用带错误的 API，否则“查找失败”可能被误读成“读到了空配置”。

真正危险的是名称合并后的配置冲突

大小写不敏感模式的风险不止是“查找更方便”。当同一文件或多个数据源里同时出现大小写变体时，规范化后的名称相同，后续内容可能复用已有节并更新已有键。下面的示例只展示结构关系，不把某次运行输出当成证据：

text := []byte("[Service]\nPort = 8080\n[service]\nport = 9090\n") // 两组名称只有大小写不同
cfg, err := ini.InsensitiveLoad(text)
if err != nil {
    panic(err) // 先处理解析错误，再讨论名称冲突
}

section, err := cfg.GetSection("SERVICE")
if err != nil {
    panic(err) // 三种大小写都指向规范化后的 service
}
key, err := section.GetKey("PORT")
if err != nil {
    panic(err) // PORT 与 port 使用同一个规范化键名
}
fmt.Println(section.Name(), key.Name(), key.String()) // 关注名称合并后的最终值

如果配置来自环境变量、用户上传文件或多份覆盖源，不能把这种合并当成无害兼容。更稳妥的做法是：默认保持大小写敏感；只有在协议明确规定“不区分大小写”时才打开对应开关；一旦启用，就把规范化后的名称当作唯一键，并在合并前拒绝重复来源。

如何选择并固定防护边界

可以按下面的顺序做决定：

1. 先确认外部格式的约定：是节名不敏感、键名不敏感，还是两者都不敏感。
2. 只打开必要的开关，优先使用两个细分字段，避免用 Insensitive 把不需要改变的层也一起改掉。
3. 对规范化后的节名和键名做重复检查；不要把大小写变体当作两个合法配置。
4. 用成功查找、严格失败和冲突三条测试路径固定行为。

func mustHavePort(cfg *ini.File) error {
    section, err := cfg.GetSection("service") // 测试约定的规范化节名
    if err != nil {
        return err // 缺少节时直接暴露配置错误
    }
    key, err := section.GetKey("port") // 测试约定的规范化键名
    if err != nil {
        return err // 键名大小写策略不匹配时保留失败
    }
    if key.String() == "" {
        return fmt.Errorf("service.port 不能为空") // 空值不能伪装成已配置
    }
    return nil
}

核心原则是把大小写策略当成配置协议的一部分，而不是某次读取失败后的临时补丁。这样既能兼容真实存在的历史文件，也不会让两个看起来不同的配置名称在内存里悄悄争夺同一个值。

常见问题

InsensitiveSections 会让键名也不敏感吗？

不会。它只影响节名的创建和查找；键名仍然使用原始大小写。需要同时改变两层时，才使用 Insensitive 或额外打开 InsensitiveKeys。

不敏感模式只是查询时调用 strings.ToLower 吗？

不是。源码在创建节和键时也会规范化名称，所以大小写变体可能被当作同一项。处理覆盖配置时，必须考虑合并和覆盖，而不只是考虑能否查到。

想保留原始大小写，应该怎么做？

保持默认的 ini.Load，并在业务层明确配置名称规范。若确实需要兼容外部大小写，再选择单独的节或键开关，同时在入口处检查冲突。