Beego 不适合零配置小项目，但适合长期维护的企业应用；路由需混用 RESTRouter 与 Router；app.conf 必配 RunMode、CopyRequestBody、SessionOn、EnableDocs；ORM 初始化须在 init 阶段完成；bee 工具需适配 CI/CD，配置须分层外置。
Beego 不适合“零配置快速上线”的轻量级小项目，但对需要长期维护、多人协作、含权限/审计/多环境部署的企业应用，它反而是少有的能兼顾开发效率与架构可控性的选择。
beego.Router 和 beego.RESTRouter 的选型差异
企业应用里路由逻辑往往混合 RESTful 资源操作和非标准动作（如 /users/export、/orders/approve），不能只靠 beego.RESTRouter 自动映射 CRUD。实际用法是：
-
beego.RESTRouter("/api/v1/users", &controllers.UserController{})用于标准资源路径，自动生成 GET/POST/PUT/DELETE 绑定 - 额外的非标准操作必须显式注册：
beego.Router("/api/v1/users/export", &controllers.UserController{}, "get:Export") - 避免在控制器里用
if c.Ctx.Input.Method() == "POST"做手动分发——这会破坏可读性和测试性 - 所有路由注册统一放在
routers/router.go的init()函数中，别分散到各 controller 文件里
conf/app.conf 中必须显式配置的 4 项企业级参数
默认的 app.conf 只启用了基础功能，企业场景下不改这四项，上线后大概率出问题：
-
RunMode = prod：开发时设为dev，但 CI/CD 流水线打包前必须检查此项，否则日志暴露堆栈、SQL 错误明文返回 -
CopyRequestBody = true：不开启会导致c.GetString("xxx")在 POST JSON 场景下始终为空——因为 Beego 默认不缓存原始 body -
SessionOn = true且SessionProvider = "redis"：企业级 session 必须外置，禁用 file 或 memory provider -
EnableDocs = false：Swagger 文档在生产环境必须关闭，bee run -downdoc=true仅限本地调试
models 目录下 ORM 初始化的坑
Beego ORM 不是“导入即用”，企业项目数据库连接失败常卡在这几步：
- 初始化必须在
main.go的init()阶段完成，不能拖到 controller 里首次调用时才orm.RegisterDriver，否则并发请求可能触发竞态 - MySQL 连接字符串末尾要加
?charset=utf8mb4&parseTime=True&loc=Local，缺parseTime会导致time.Time字段解析成零值 - 使用
orm.RunSyncdb("default", false, true)仅限开发环境自动建表；生产环境必须用bee migrate管理版本化 SQL，禁止 syncdb - 每个 model 结构体的
TableName()方法必须显式返回带 schema 前缀的表名（如"auth.users"），否则多租户或分库场景会错表
bee 工具在 CI/CD 中的真实可用性
bee 是开发期利器，但直接进生产流水线会翻车：
-
bee pack打包结果包含conf/app.conf明文，敏感字段（DB 密码、Redis 地址）必须通过环境变量注入，不能写死配置文件 -
bee dockerize生成的Dockerfile默认用go build，企业级镜像应改用CGO_ENABLED=0 go build -a -ldflags '-s -w'静态编译 -
bee run的热重载依赖fsnotify，在 Docker 容器内挂载代码目录时经常失效，生产部署必须用标准go run或二进制启动 - CI 脚本里别用
bee version判断环境，改用go list -m github.com/beego/beego/v2获取真实模块版本
企业应用最易被忽略的点是配置分层：app.conf 只存通用项，数据库、缓存、密钥等必须由外部配置中心（如 Consul、Nacos）动态加载，Beego 的 beego.AppConfig 支持 Set 覆盖，但很多人卡在没意识到要主动调用。
