beego 的 app.conf 不支持热重载，因其启动时一次性加载配置到内存且无运行时重读机制；需通过 bee.json 配置监听 conf 后缀并配合 bee run 实现伪热重载，runmode 切换也必须重启进程。
Beego 的配置文件（如 conf/app.conf）本身不支持运行时热重载——修改后必须重启进程才生效，但可通过 bee run 的监听机制实现“伪热重载”效果。
为什么 app.conf 修改后不自动生效？
Beego 在应用启动时一次性读取并解析 conf/app.conf，所有配置项（如 RunMode、sessionprovider）被加载进内存并固化。框架没有内置运行时重新加载配置的逻辑，这与 Go 的编译型特性和配置即常量的设计哲学一致。
常见错误现象：改完 app.conf 中的 Listen.HTTPPort = 8081 并保存，浏览器仍访问 :8080 —— 因为旧进程还在跑，新配置根本没被读取。
- Beego 不会在每次请求中重新解析配置文件
- 即使启用了
dev模式，app.conf的变更也不会触发自动 reload - 只有通过
bee run启动，并配合bee.json显式声明监听.conf后缀，才能让修改触发进程重启
如何让 conf/app.conf 修改触发重启？
关键不是 Beego 本身，而是 bee 工具的文件监听能力。默认它只监听 .go 文件，需手动扩展监听范围。
- 在项目根目录创建
bee.json文件 - 写入以下内容，明确包含
conf：
{
"watch_ext": ["go", "conf", "tpl", "html", "js", "css"]
}
保存后，再修改 conf/app.conf，终端会立即输出 [INFO] Restarting myapp，新配置随之生效。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
注意：bee.json 必须放在与 main.go 同级的项目根目录；若路径错误或 JSON 格式非法，bee run 会静默忽略该文件，不报错也不监听。
RunMode 切换必须重启，且有副作用
RunMode 是 Beego 启动阶段最关键的配置项之一，它决定日志级别、模板缓存策略、错误渲染行为等。一旦设为 prod，很多开发期特性（如控制器热重载提示、详细 panic 堆栈）会被禁用。
- 从
dev改成prod后不重启 → 所有 dev 行为照旧，毫无意义 - 从
prod改回dev后不重启 → 仍无热重载、无调试日志 - 切换
RunMode同时涉及 Session provider 变更（如从memory切到redis），必须重启才能初始化新 provider 实例
所以不要幻想“动态切 mode”，它本质是启动参数，不是运行时开关。
真正需要热重载配置的场景，该怎么做？
如果业务要求某些配置项（比如 API 熔断阈值、白名单 IP 列表）能运行时更新，Beego 原生不支持，得自己加一层：
- 把这类配置单独抽到外部 JSON/YAML 文件（如
conf/runtime.json） - 用
fsnotify库监听该文件变更，收到事件后重新json.Unmarshal加载 - 避免直接修改 Beego 内部配置结构体，而是维护自己的配置变量和读取函数
Beego 的 app.conf 适合做部署级静态配置；运行时可变配置，得自己管。别把它当 Spring Boot 的 @ConfigurationProperties(reloadable=true) 用。
