rk-boot 的 locale 机制通过 REALM::REGION::AZ::DOMAIN 四维标识实现精准配置加载，比单纯依赖 os.Getenv("ENV") 更可靠；它支持地理与阶段组合（如“北京生产”“上海预发”），避免硬编码分支，匹配优先级由通配符精度决定，且需显式设置各维度环境变量以防静默加载默认配置。
直接用 rk-boot + viper 的 locale 机制，比手写环境判断更可靠，也避免在代码里硬编码 if env == "prod" 这类逻辑。
为什么不能只靠 os.Getenv("ENV") 做配置切换
单纯读取一个 ENV 环境变量，容易忽略云原生中多维环境的现实：比如「北京生产集群」和「上海预发集群」可能都标为 ENV=prod，但配置必须不同。硬编码分支会快速失控，且无法与配置中心（如 Consul、Nacos）对齐。
-
rk-boot使用REALM/REGION/AZ/DOMAIN四维标识，天然支持地理+阶段组合 - 配置加载顺序由
locale字符串匹配决定，"*::beijing::*::*"比"*::*::*::*"优先级更高 - 不依赖 Go 代码里的条件判断，配置变更无需重新编译
boot.yaml 中 config.locale 的匹配规则
locale 是四段式字符串：REALM::REGION::AZ::DOMAIN，每段支持通配符 *。匹配时从左到右逐段比对，越具体的规则越先命中。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
"*::beijing::*::*"→ 匹配所有 REALM、仅 REGION=beijing、任意 AZ 和 DOMAIN -
"myapp::beijing::az1::prod"→ 精确匹配北京一区生产环境 -
"*::*::*::*"→ 兜底，默认配置，必须保留 - 若多个 locale 都匹配，取第一个（顺序重要！）
启动前必须设置的环境变量
仅设 REGION 不够，rk-boot 默认按四维全量解析。没设的字段会被视为空字符串，导致 locale 匹配失败。
- 至少设置
REGION和DOMAIN，例如：os.Setenv("REGION", "shanghai"); os.Setenv("DOMAIN", "staging") - 如果不用某维，显式设为
*，比如：os.Setenv("AZ", "*")，否则空值会导致"*::shanghai::::staging"这种非法 locale -
REALM建议设为业务名（如"user-service"），便于后期接入统一配置中心
config 文件路径和 name 的常见误用
name 字段不是文件名，而是配置块的逻辑标识；path 才是实际读取的 YAML 文件路径。很多人误以为 name 会影响加载行为，其实它只用于后续通过 rk-boot 的 API 获取配置实例。
- 多个
config块可以共用同一个name（如都叫my-config），只要locale不同，就不会冲突 -
path必须是相对boot.yaml所在目录的路径，不要写成./config/beijing.yaml，而应写config/beijing.yaml - YAML 文件里不能有重复 key，
viper合并时后加载的会覆盖先加载的，所以兜底配置（*::*::*::*）要放在最前面
真正麻烦的是 locale 字符串拼错或环境变量漏设——这类问题不会报错，只会静默加载默认配置，排查时得翻日志里 rk-boot 输出的「Loaded config with locale: ...」那一行确认实际匹配结果。
