beego配置管理强制加载conf/app.conf，缺失或语法错误会导致启动panic；支持ini多环境覆盖（如app.conf.prod）和环境变量优先，但需显式加载json/yaml等额外配置。
Beego 的配置管理不是“选配”，而是启动时就强制加载 conf/app.conf，不按规范放文件或写错格式，bee run 会直接 panic 报错，而不是静默忽略。
conf/app.conf 是默认入口，但不能只靠它
Beego 启动时自动读取项目根目录下 conf/app.conf，格式必须是 INI（即使你用 JSON/YAML 写了其他配置，也要确保这个文件存在且语法合法）。如果该文件缺失或有语法错误（比如漏了引号、section 名重复），bee run 会卡在初始化阶段并报类似 parse conf/app.conf error: invalid section name 的错误。
- INI 格式支持
[section]分组，key 用section::key方式访问，例如web.AppConfig.String("database::host") - 若想用 JSON/YAML 等格式做额外配置（如微服务地址、第三方密钥），需手动初始化解析器：
config.NewConfig("json", "conf/extra.json")，不能指望框架自动识别 -
app.conf中的runmode值（"dev"/"prod"）会触发对应环境下的conf/app.conf.prod等覆盖文件，但这些文件必须显式存在，框架不会自动生成
多环境配置要靠 runmode + 文件名约定
Beego 不支持像 Spring Boot 那样用 spring.profiles.active 动态切配置，而是硬编码依赖文件名后缀：当 runmode = "prod" 时，框架会尝试加载 conf/app.conf.prod 并合并进主配置。但注意：它只是“覆盖”，不是“替换”——所有未在 .prod 文件中出现的 key，仍沿用 app.conf 的值。
- 合并逻辑是浅层覆盖，不支持嵌套结构合并（比如
databasesection 下只重写了host，那port还是取自app.conf） - 若
app.conf.prod存在语法错误，整个应用启动失败，错误信息里不会明确提示是哪个文件出问题，需手动检查所有conf/app.conf.*文件 - 环境变量优先级高于配置文件：设置
BEEDB_HOST=10.0.1.5后，web.AppConfig.String("database::host")会返回该值，而非文件里的内容
AppConfig.String() 看似简单，实则容易空指针
web.AppConfig.String("mysqluser") 这类调用不会 panic，但返回空字符串。如果你没在 app.conf 或环境变量中定义该 key，它不会报错，也不会给默认值，只会默默返回 ""——这在数据库连接、API 密钥等关键字段上极易引发运行时错误。
- 务必配合
web.AppConfig.DefaultString("mysqluser", "root")使用，避免依赖未定义行为 - 对数值型配置（如端口、超时时间），别用
String()再转 int，直接用Int("httpport")，否则遇到非数字字符串会返回 0 而不是报错 - 所有
AppConfig方法都只读取已加载的配置源（app.conf+ 环境变量 + 显式加载的其他文件），不会动态监听文件变更
自定义配置文件必须显式 NewConfig，且格式名要写对
想加载 conf/redis.json？不能只写路径，必须指定格式名。写成 config.NewConfig("json", "conf/redis.json") 才行。格式名错一个字母（比如写成 "jsn"），就会返回 nil 和 error，但很多示例代码会忽略 error 检查，导致后续 String() 调用 panic。
- 支持的格式名只有
"ini"、"json"、"xml"、"yaml"四种，大小写敏感 - JSON/YAML 文件不支持 INI 那样的
section::key访问方式，只能用扁平 key，例如{"redis": {"host": "127.0.0.1"}}中的redis.host，而非redis::host - 多个自定义配置文件之间无合并机制，每个
NewConfig返回独立实例，需自行协调使用场景
最常被忽略的一点：Beego v2 的 web.AppConfig 是全局单例，但它的底层数据源在应用启动后就冻结了。改了 app.conf 文件内容再热重载，新值不会生效——必须重启 bee run。
