Beego 配置管理依赖环境变量注入与 conf/app.conf 模板协同，必须用双引号包裹 ${VAR||default} 格式；v2 需显式调用 core/config.LoadConfig 加载配置，否则 AppConfig 为空；多环境共用同一配置文件，通过环境变量动态覆盖，严禁硬编码或复制多份配置文件。
Beego 的配置管理不是靠写死 conf/app.conf，而是靠环境变量注入 + 配置文件模板协同工作。硬编码不同环境的数据库地址、端口或缓存参数，等于把部署逻辑锁死在代码里，CI/CD 流水线一跑就炸。
conf/app.conf 支持环境变量语法，但必须用双引号包裹
Beego 内置的配置解析器只识别 ${VAR||default} 这种格式，且整个值必须用双引号包围，否则会被当成字符串字面量处理。
- ✅ 正确写法：
db_host="${MINDOC_DB_HOST||127.0.0.1}" - ❌ 错误写法：
db_host=${MINDOC_DB_HOST||127.0.0.1}（无引号 → 解析失败） - ❌ 错误写法：
db_host="${MINDOC_DB_HOST}127.0.0.1"（拼接写法 → 环境变量不生效） - 注意：Beego v1 和 v2 对该语法的支持一致，但 v2 的
core/config包更严格校验引号缺失
多环境部署时，不要改 app.conf 文件名，而是靠环境变量切换行为
很多人以为要准备 app.dev.conf、app.prod.conf 多个文件，再根据环境 copy 覆盖——这违背 Beego “约定优于配置” 原则，也破坏容器镜像不可变性。
- 所有环境共用一份
conf/app.conf，内容含完整环境变量占位符 - CI/CD 中通过
export MINDOC_DB_ADAPTER=mysql等方式注入变量，启动时自动覆盖 - Docker 场景下，直接在
docker run或docker-compose.yml的environment:块里定义变量即可 - 若用
bee run本地调试，需确保终端已export相关变量，否则 fallback 到默认值（如sqlite3）
Beego v1 升级到 v2 后，配置加载路径和默认行为有差异
v2 版本拆分了包结构，beego.BConfig 不再自动加载 conf/app.conf，必须显式调用 core/config.LoadConfig("ini", "conf/app.conf")，否则所有配置都是空值。
- v1 中：
beego.Run()自动读取conf/app.conf - v2 中：
beego.Run()不再加载配置文件，需提前初始化：cfg, _ := core/config.LoadConfig("ini", "conf/app.conf") beego.BConfig = cfg.(*core/config.BConfig) - 若忽略这点，
beego.AppConfig.String("httpport")会返回空字符串，进程监听 0.0.0.0:8080（Go 默认）而非配置值 - 环境变量注入语法在 v2 中仍有效，但前提是配置已成功加载
最常被忽略的一点是：Beego 的配置解析发生在 main() 函数早期，如果在控制器或中间件里才去读环境变量，或者依赖 os.Getenv() 手动取值，就绕过了框架的配置合并机制——这意味着你写的 ${DB_USER||root} 永远不会被展开，只能拿到原始字符串。
