配置中心与动态配置刷新

面试问法：GoFrame 的配置管理支持配置中心吗？改配置要不要重启？ 一句话结论：g.Cfg() 默认走文件适配器，支持多环境切文件；要接配置中心时，官方以 contrib 形式提供 Consul/Nacos/Apollo/etcd/Kubernetes ConfigMap 等适配器（列表以官方文档为准），通过 gcfg.SetAdapter 替换即可。是否“动态刷新”取决于所选适配器的监听能力，业务侧应养成“用的时候 g.Cfg().Get”的习惯而不是启动时快照。

基本认知

• 默认文件配置：检索可执行目录与 config、manifest/config 等目录下的 config.* 文件（目录顺序以官方文档为准）。
• 多环境切文件：准备 config.yaml、config.prod.yaml 等多份文件，用启动参数/环境变量指定实际加载的文件（如 GF_GCFG_FILE=config.prod.yaml，变量名以官方文档为准），同一套代码不同环境配置。
• 配置中心适配器是官方贡献组件，与 gcfg 的关系：适配器负责“从配置中心拉配置”，gcfg 仍提供统一的 Get 接口。

动态刷新落地套路

// 启动时替换适配器（示意：consul 适配器；具体初始化参数以官方文档为准）
adapter, err := consul.New("consul:8500", "my-app")
if err != nil { panic(err) }
gcfg.SetAdapter(adapter)

// 使用时每次都实时 Get，而不是启动时缓存到全局变量
addr := g.Cfg().MustGet(ctx, "server.address").String()

关键点：

• 配置中心适配器各自实现“拉取/监听”：支持 Watch 的（如 consul/etcd 类）改配置后能较快生效，其余可能是轮询或需重拉，能力差异以官方文档为准。
• 不要在服务启动时把配置读进 package 级变量长期使用——那样“热更新”形同虚设；需要缓存时用可原子替换的 gvar.Var 并在刷新点更新。
• 依赖配置强一致的场景（连接串变更）仍建议重启实例，避免半热半冷的状态。

常见追问

• 追问：文件配置改完会自动生效吗？——文件适配器具备重载/缓存机制，具体刷新语义与版本有关，以官方文档为准；配置中心类的动态性由适配器决定。
• 追问：动态配置刷新后组件（如日志级别、限流阈值）怎么感知？——读取点实时 Get 是最简单的；日志级别这类框架配置通常仍按启动值生效，需要组件提供刷新钩子时在回调里重设。

记忆点

• 一句话：默认文件 → 多环境切文件 → 配置中心靠 contrib 适配器 + SetAdapter。
• 动态刷新的真谛在“读取时机”，不在框架；细节以官方文档为准。