runmode 是 beego 运行时行为总开关，决定日志级别、错误堆栈暴露、模板重编译等；必须通过 conf/app.conf 或环境变量配置，且需定义对应环境 section（如 [prod]）才能生效，bee run 强制 dev 模式，生产部署须用 go build 后运行二进制。
runmode 配置项决定调试行为
Beego 的 runmode 不是开关，而是运行时行为的总开关。它直接控制日志级别、错误堆栈是否暴露、模板自动重编译、静态资源缓存策略等——这些在开发期和生产期必须差异化。硬编码写死 beego.BConfig.RunMode = "prod" 是无效的，必须通过配置文件或环境变量驱动。
conf/app.conf 中的多环境 section 必须显式引用
仅写 runmode = dev 在文件开头是不够的。Beego 会先读取全局段，再按 runmode 值加载对应 section（如 [dev] 或 [prod]），并覆盖同名键。若没定义 [prod] 段，即使 runmode = prod，所有参数仍沿用全局默认值，包括 httpport 和 autorender。
- 正确写法示例：
[dev] httpport = 8080 autorender = true recoverpanic = true [prod] httpport = 80 autorender = false recoverpanic = false
启动时 Beego 自动合并：先载入全局段，再载入 [prod] 段，同名 key 被后者覆盖。
bee run 启动时 runmode 不受 bee.json 控制
bee.json 只影响文件监听和重启行为，不影响 Beego 运行时的 runmode 判定。bee run 默认强制设为 dev，即使 conf/app.conf 里写了 runmode = prod 也无效。要验证真实 mode，启动后看控制台第一行日志：[INFO] Run mode is dev —— 这才是最终生效值。
- 想用
bee run模拟 prod 行为？不行。它专为开发设计，会强制开启autoreload、禁用静态资源压缩、保留完整 panic 堆栈。 - 真正部署 prod？必须用
go build编译后手动运行二进制，此时才严格按conf/app.conf解析runmode。
recoverpanic 和 autorender 在 prod 下必须关掉
这两个配置在 prod 下不关，等于主动暴露服务脆弱面：recoverpanic = true 会让未捕获 panic 返回 500 页面并附带完整调用栈；autorender = true 会导致每次请求都重新解析模板，严重拖慢响应速度且无法利用内存缓存。
-
recoverpanic = false：panic 发生时返回空白 500，不泄露路径、函数名、变量值。 -
autorender = false：模板只在首次访问时编译一次，后续全部走内存缓存。 - 漏掉任一配置，上线后可能被扫描器抓到敏感路径或触发性能雪崩。
最易忽略的是：修改 conf/app.conf 后，bee run 不会自动重载该文件——它只监听 .go 文件变更。切换模式必须手动停止再 bee run，或改用编译后执行方式验证 prod 行为。
