Viper读取config.yaml需用绝对路径拼接、避免init加载、显式设YAML类型、检查ReadInConfig错误、生产优先环境变量、INI库注意BOM和节名合法性、多环境动态命名配置文件。
用 viper 读取 config.yaml 时找不到文件
直接写 config.yaml 当路径，运行时大概率报 open config.yaml: no such file or directory。因为 Go 程序默认从当前工作目录（os.Getwd()）找文件，而线上二进制启动位置和配置文件常不在一处。
- 改用绝对路径：用
filepath.Join(filepath.Dir(os.Args[0]), "config.yaml")拼出与二进制同级的配置路径 - 别在
init()里加载 —— 单元测试时无法 mockos.Args，会导致测试失败或 panic - 加
viper.SetConfigType("yaml")，否则自动推断可能出错（尤其文件无扩展名时） - 调
viper.ReadInConfig()后必须检查err，否则后续viper.GetString("server.port")可能返回空字符串，静默失效
开发用 YAML、生产别硬塞 config.yaml
YAML 在开发阶段写配置确实方便，有缩进、支持注释；但上线后，K8s/云平台基本靠环境变量或 ConfigMap 注入配置，硬塞一个 config.yaml 反而增加运维负担，且 YAML 解析比 JSON 慢，还存在类型隐式转换风险（比如 yes 被转成 true）。
- 生产环境优先走
viper.AutomaticEnv()，配合viper.SetEnvPrefix("APP")，读取APP_HTTP_PORT这类变量 - 如果必须用文件，生产上改用 JSON：
viper.SetConfigType("json")，解析更快、无歧义 - 所有配置项都设默认值，例如
viper.GetString("db.host")改成viper.GetString("db.host")+ 显式 fallback，避免空值穿透到业务逻辑
用 ini 库读 config.ini 容易 panic 的几个点
gopkg.in/ini.v1 是目前最稳的 INI 库，但常见 panic 几乎都跟底层加载细节有关，不是配置内容写错了。
- 文件带 BOM？读取后先
bytes.TrimPrefix(data, []byte("\xef\xbb\xbf"))再喂给ini.LoadSources() - 节名含冒号或短横线？
[db:port]或[db-port]都非法，只允许字母、数字、下划线、点号、空格 -
cfg.Section("log").Key("level").String()这种写法 key 不存在时返回空字符串，极易埋坑；一律换成MustString("info")，兜底更安全 - 写入时
cfg.SaveTo("config.ini")是覆盖式，不保留注释和空行；要保留格式，必须先ini.Load()再改再存
多环境配置别写死文件名
把 config.dev.yaml 硬编码在代码里，上线一换环境就得改源码，根本没法 CI/CD。
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Getenv("ENV")或命令行 flag 获取环境标识，比如ENV=prod go run main.go - 动态设名：
viper.SetConfigName("config." + env)，再调viper.ReadInConfig() - 配置文件按约定命名：
config.dev.yaml、config.prod.yaml、config.test.yaml - 禁止在
init()中初始化 viper —— 测试时无法重置环境变量，mock 失效
真正麻烦的不是读配置，而是让配置在 dev/test/prod 之间可预测地切换，同时不破坏测试隔离性。路径、BOM、节名合法性、环境变量注入时机，这些细节漏掉一个，就可能卡在上线前最后一刻。
