beego项目标准结构严格遵循mvc分层：conf/app.conf为必载配置，controllers处理请求逻辑，models定义数据模型，routers映射url与方法，views渲染模板，static存放前端资源，main.go为唯一启动入口。
要快速理解一个Beego项目如何组织代码、各部分职责如何划分，必须从其标准目录结构入手——这不是随意堆砌的文件夹，而是严格遵循MVC分层思想、由bee工具生成并被框架运行时依赖的固定布局。
conf目录：存放项目配置的核心位置
该目录下必须存在app.conf文件，Beego启动时会自动加载它。没有这个文件，【beego.Run()将直接panic退出】。
runmode=dev是开发模式必备项；若缺失，框架默认以prod模式运行，日志不输出、错误不显示，调试时会完全卡死在黑盒中。
你也可以在此添加数据库连接串、Redis地址、JWT密钥等环境相关参数，用${}语法做变量替换。
controllers目录：处理HTTP请求的业务逻辑中枢
所有用户请求最终都会路由到该目录下的Go文件中。每个控制器文件对应一个或多个HTTP Handler函数。
default.go是最小可运行项目的默认入口控制器，包含MainController结构体及其Get方法，响应/路径的GET请求。
实际项目中应按功能拆分控制器：admin.go处理后台管理，api/v1/user.go处理用户接口，避免单文件膨胀到500行以上。
models目录：数据建模与持久化操作的专属区域
这里存放struct定义、ORM模型注册、数据库初始化逻辑。Beego ORM通过orm.RegisterModel(new(User))识别模型。
注意：models.go里不能直接调用orm.RunSyncdb——这会导致每次import该包就执行建表，【应在routers/init.go或main.go中统一调用一次】。
字段标签如`orm:"pk;auto"`决定主键和自增行为，写错会导致Insert失败且无明确报错。
routers目录：URL路径与控制器方法的映射枢纽
router.go是路由注册中心，所有HTTP动词（GET/POST/PUT/DELETE）和路径规则都在这里声明。
第一步：打开router.go，确认已导入"github.com/astaxie/beego"和"your_project_name/routers"；
第二步：检查func init()中是否调用了beego.Router("/", &MainController{}, "get:Get")这类绑定；
第三步：确认main.go中是否以_ "your_project_name/routers"方式隐式导入该包——这是触发init函数执行的关键，漏掉则整个路由系统失效。
views目录：HTML模板渲染的输出层
Beego使用Go原生template引擎，支持嵌套、循环、条件判断和自定义函数。index.tpl是首页模板，由MainController.Get方法调用this.TplName = "index.tpl"指定。
模板中引用静态资源需用{{.StaticUrl "css/app.css"}}而非硬编码/static/css/app.css，否则在启用CDN或子路径部署时会404。
如果项目是纯API服务，此目录可为空，但目录本身不能删除，否则Beego初始化阶段会报错找不到views路径。
static目录：前端资源的物理存放地
css、js、img、ico四个子目录为约定俗成结构，Beego自动将/static/路径映射到该目录，无需额外配置。
注意：favicon.ico必须放在static根目录，否则浏览器会反复发起/favicon.ico请求并返回404，污染日志。
所有放入static的文件都将被直接HTTP响应，不经过任何Go逻辑，因此敏感配置文件绝不可放在这里。
main.go：整个Beego应用的唯一启动入口
文件内容极简：导入beego包 + 调用beego.Run()。但它承担着初始化全局配置、加载路由、启动HTTP服务器三重责任。
切勿在此文件中写业务逻辑或数据库操作——所有初始化动作应下沉至routers/init.go或models/init.go中完成。
如果修改了main.go但未重启bee run进程，新代码不会生效，因为bee run监听的是.go文件变更并热重载，但main.go变更后必须手动重启。
