config.Get() 返回的值来自命令行参数、环境变量、配置文件三层按优先级合并的结果，顺序为命令行（最高）→环境变量→配置文件（最低），每层仅覆盖前一层未设置的字段。
config.Get() 返回的值到底来自哪一层
Go 里没有内置配置优先级机制，os.Getenv()、flag.String()、json.Unmarshal() 各自独立，谁先读、谁后覆盖，全靠你手动控制顺序。常见错误是：先加载 config.json，再读环境变量，最后解析命令行——结果命令行没生效，因为后续没做赋值覆盖。
正确做法是「从高优先级往低优先级逐层合并」：先解析命令行参数（最高），再读环境变量（中），最后 fallback 到配置文件（最低）。每一步都只覆盖前一步未设置的字段。
- 用
flag.Parse()解析后，检查flag.Lookup("port").Value.String()是否非空，再决定是否覆盖当前配置值 - 环境变量名建议统一加前缀（如
APP_PORT），避免污染系统变量；用os.Getenv("APP_PORT")获取，空字符串视为未设置 - 配置文件只在命令行和环境变量都未提供时才加载，且应校验文件是否存在、可读，否则直接 panic 或 log.Fatal
如何避免 flag.String 和 viper 的冲突
很多人想用 viper 管理全部配置，但又保留原生 flag 解析逻辑，结果发现 viper.BindPFlag("port", flag.Lookup("port")) 不生效——根本原因是 flag.Parse() 必须在 viper.BindPFlag() 之后调用，否则 flag 值还没被解析，绑定就是空的。
更稳妥的做法是绕过 viper 的自动绑定，手动接管：
- 定义结构体字段（如
Port int `mapstructure:"port"`），不依赖viper.AutomaticEnv() - 调用
flag.Parse()后，用flag.CommandLine.Visit(func(f *flag.Flag) { ... })遍历所有已设置的 flag，写入结构体 - 再调用
viper.Unmarshal()加载配置文件，它会跳过已有值的字段（前提是viper.SetDefault()没提前塞默认值）
环境变量覆盖配置文件时的大小写陷阱
Linux/macOS 环境变量名默认全大写，而配置文件里字段通常是小写或驼峰（如 logLevel）。viper 默认把 LOG_LEVEL 映射到 log_level，不是 logLevel，导致覆盖失败。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
解决方式取决于你用不用 viper：
- 如果用
viper，必须显式调用viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))并统一字段命名风格（推荐全小写下划线，如log_level） - 如果手写解析逻辑，建议环境变量名和结构体 tag 严格对应：
Port int `env:"APP_PORT"`，然后用env.Parse()（第三方库）或自己遍历os.Environ()匹配 - 永远不要依赖系统自动转换：Go 的
os.Getenv()是精确匹配，APP_port和APP_PORT是两个不同变量
配置热加载会破坏优先级逻辑吗
热加载（比如监听 fsnotify 重读 config.json）本身不改变优先级，但容易让人误以为“新文件内容会立刻覆盖环境变量”。不会。环境变量和命令行参数在进程启动时就固定了，热加载只影响配置文件那一层。
所以热加载后，实际生效的仍是：命令行 > 环境变量 > 新配置文件。如果你希望热加载也能被更高优先级覆盖，就得在重载后重新执行一次「命令行 → 环境变量 → 新配置」的合并逻辑。
- 别在热加载回调里直接
viper.ReadInConfig()就完事，要补上viper.Unmarshal()+ 手动覆盖步骤 - 如果用了
flag，注意flag.Parse()只能调用一次，热加载期间不能再调用，否则 panic - 真正需要热生效的配置项（如日志级别），建议单独抽离为运行时可变对象，而非混在初始化配置里
优先级不是靠工具自动保证的，是靠你每次取值时明确知道来源，并在赋值路径上严格按顺序判断。最容易被忽略的是：命令行参数解析后没做任何判断就直接丢弃，或者环境变量读出来是空字符串却当成有效值覆盖了配置文件里的非零默认值。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
