Kratos配置管理核心在于解耦、可替换与热更新，必须显式传入Source（如file.NewSource或env.NewSource），支持多源叠加与覆盖优先级；热更需Watch+Value手动同步，敏感配置须用Secret注入而非ConfigMap挂载，Protobuf结构体变更后须执行make config生成新conf.pb.go。
Kratos 的配置管理不是“读个 YAML 就完事”，核心在于解耦、可替换、可热更——硬编码路径或只用本地文件，等于放弃框架的云原生能力。
config.New() 里必须显式传入 Source，不能依赖默认行为
默认不传 config.WithSource 时，Kratos 不会自动加载任何配置源。常见错误是只写 config.New()，结果 c.Load() 成功但 c.Scan(&bc) 得到零值结构体。
- 必须至少指定一个 Source：比如
file.NewSource("configs/config.yaml")或env.NewSource() - 多个 Source 可叠加，顺序决定覆盖优先级：
config.WithSource(file.NewSource(...), env.NewSource())表示环境变量 > 文件 - 路径必须可访问：若挂载 ConfigMap 到
/etc/kratos/config.yaml，就得传file.NewSource("/etc/kratos/config.yaml")，不能还写"configs/config.yaml"
热更新必须配合 Watch + Value，不能只靠 Scan
c.Scan(&bc) 是一次性快照，改了文件或配置中心内容不会自动同步字段。要响应变更，得用 c.Watch() 监听 key，并手动更新内存中的结构体字段。
- 监听粒度是 key 路径，如
"server.http.addr"，不是整个文件 - 回调里必须调用
c.Value(key).String()（或.Int()等）取新值，再赋给对应结构体字段 - 注意并发安全：若被多 goroutine 读写，字段需加锁或用 atomic；
conf.Bootstrap本身不是线程安全的 - Watch 不会触发重 Scan，别指望它让整个
bc自动刷新
敏感配置必须进 Secret，且避免挂载为文件
数据库密码、JWT 密钥等写进 ConfigMap 再挂载成文件，等于把密钥明文暴露在容器文件系统里——ls /etc/kratos/ 就能看见，日志或调试命令可能意外输出。
- Secret 应通过
envFrom注入环境变量，或用valueFrom.secretKeyRef单独注入单个变量 - 如果非得挂载文件（如某些证书），Secret 必须设
type: Opaque并用volumeMounts.subPath精确挂载，避免整个 Secret 目录可遍历 - 代码里读取时，统一走
env.NewSource()，不要混用file.NewSource()读 Secret 文件
Protobuf 定义结构体后，make config 不会自动重生成 conf.pb.go
internal/conf/conf.proto 改了字段，不手动运行 make config，conf.Bootstrap 结构体不会更新，c.Scan() 会静默跳过新增字段，也不报错。
-
make config本质是调protoc+protoc-gen-go，确保已安装且版本匹配 Kratos 要求 - Wire 注入时，若新字段没出现在
conf.pb.go，wire.Build()会编译失败，提示 “unknown field” - CI 流程中必须把
make config加进构建步骤，否则镜像里跑的是旧结构体
真正难的不是写对一行 c.Watch()，而是所有配置源的加载顺序、热更时机、结构体生命周期，三者必须对齐——漏掉任何一个，热更新就变成玄学 reload。
