section.comment为空或不全是因为ini.load()仅捕获节上方最近连续注释行，自动丢弃空行、前导空白及节名后内联注释；需紧贴[section]写注释、避免行末分号，否则无法精确保留位置。
Go 解析带注释的 INI 文件时，Section.Comment 为什么总是空或不全
因为 ini.Load() 默认只捕获「节上方最近一段连续的注释行」，且会自动丢弃空行、前导空白和节名后的内联注释。比如：
[db] ; 生产库配置 ; 注意超时设置 host = 127.0.0.1
这段里，Section.Comment 可能只返回第一行 ; 生产库配置，第二行和空行全丢失；而 [db] ; 生产库 这种写法，分号后内容直接被忽略。
- 节前注释必须紧贴
[section]上方，中间不能插空行 - 避免在
[section]行末加;或#注释——它不属于该节 - 若需精确保留位置（如人工维护配置），别依赖
.Comment字段，改用ini.LoadSources()+ 自定义ini.LoadOptions，或换用 AST 级解析器
Key.Comment 只捕获行尾注释，但值里含 ; 怎么办
Key.Comment 严格匹配键行末尾的 ; 或 # 后内容，不会解析值中自带的分号。例如：
path = /tmp;log ; 存放日志
这里 Key.Comment 是 存放日志，但 path 的值会被截成 /tmp——除非你显式启用 IgnoreInlineComment: true，否则分号触发注释截断逻辑。
- 值中含
;或#必须用双引号包裹：path = "/tmp;log" - 设
IgnoreInlineComment: true可让整个;当作值一部分，但代价是Key.Comment永远为空 - 若需同时支持注释管理 + 值内分号，优先走引号包裹路线，而非关掉注释识别
手写 bufio.Scanner 解析器能不能可靠处理注释
能提取注释文本，但无法绑定到具体节或键，更不能在保存时还原原始位置和格式。你写的简易解析器大概率会把以下内容全部当作普通行或跳过：
; 全局开关 [feature] enabled = true # 开启新功能 ; 日志相关 [logging] level = debug
- 节前注释、节后注释、键行尾注释、空行——它们在语义上归属不同，但 Scanner 只按行切，无上下文
- 没有 AST 结构，就无法实现 round-trip：读出来再写回去，注释顺序、缩进、混合风格（
;和#并存）全乱 - 真要自定义，建议基于
gopkg.in/ini.v1扩展，而不是从零写 lexer；400 行左右的手写 parser 已有成熟实现可参考
为什么别用标准库硬解 YAML/TOML/INI，而要选 Viper 或 yaml.v3
因为注释只是表层问题，深层是类型转换、嵌套合并、环境变量覆盖、热重载这些事，标准库一行不干。比如：
database: host: localhost port: 5432 timeout: 5s # 这里的 5s 是 time.Duration，不是 int
手写解析器碰到 5s 就得自己写 duration 解析逻辑；Viper + yaml.v3 直接靠 struct tag `yaml:"timeout" validate:"required"` 就搞定。
- 用
gopkg.in/yaml.v3解析，配合 struct tag 控制默认值、校验、env fallback，比手写正则+strconv稳得多 - Viper 的
WatchConfig()能监听文件变化，但回调里必须手动加锁更新全局 config 实例，否则并发 panic - 加密配置不要塞进 Viper 流程，应先解密为
*bytes.Buffer，再调viper.ReadConfig()
注释位置保不保得住，取决于你选的库是否做 AST 级解析；但类型安全、环境合并、热更新这些，没现成库支撑，很快就会卡死在第 3 个需求上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
