Beego控制器测试不能直接new Controller()，因其依赖框架注入的Ctx、Data等字段，裸实例化会导致nil pointer panic；应通过httptest+Beego.Handler集成测试或手动构造带Mock上下文的控制器进行单元测试。
Beego控制器测试为什么不能直接 new Controller()
因为 beego.Controller 严重依赖框架注入的上下文（Ctx）、响应写入器（Data, TplName）、中间件钩子（Prepare, Finish）等，裸实例化会导致空指针 panic。比如调用 c.Data["json"] = xxx 前没初始化 Data 字段，就会 crash。
常见错误现象：panic: assignment to entry in nil map 或 nil pointer dereference。
所以 Mock 的核心不是“绕过 Beego”，而是“构造最小可行上下文”，让控制器能安全执行生命周期方法。
用 httptest + beego.BeeApp.Handlers.ServeHTTP 做集成级 Mock
这是最贴近真实请求链路的方式，不 mock 控制器本身，而是 mock 整个 HTTP 处理流程——把请求发给 Beego 内置的路由处理器，它会自动匹配路由、初始化控制器、调用 Prepare/Get/Post 等方法。
适用场景：验证路由注册是否正确、参数绑定（this.Ctx.Input.Param, this.GetString）是否生效、模板渲染或 JSON 输出是否符合预期。
关键点：
-
beego.TestBeegoInit("github.com/your/app")必须在测试前调用，否则路由和配置不加载 -
beego.BeeApp.Handlers是一个http.Handler，可直接传给httptest.NewRecorder() - 不要手动调用
c.Get()，那是破坏封装；应走完整 Handler 链 - GET 请求示例中，
w.Body.String()可断言 HTML 内容，但注意模板未渲染时可能为空（需确认TplName已设且模板存在）
手动构造控制器实例做轻量单元测试（需 Mock Ctx 和 ResponseWriter）
当你要隔离测试控制器内部逻辑（比如某个业务校验函数），又不想启动整个路由层时，可以手动构造控制器，并用 httptest.ResponseRecorder 和自定义 context.Context 替换依赖。
实操步骤：
- 用
http.NewRequest("GET", "/fake", nil)构造请求 - 用
context.WithValue(req.Context(), contextKey, value)注入必要上下文（如用户 ID） - 创建
beego.Controller实例后，手动赋值：c.Ctx = &context.Context{Input: &context.Input{Req: req}} - 为
c.Data初始化：c.Data = make(map[interface{}]interface{}) - 若涉及 JSON 输出，需传入
httptest.NewRecorder()到c.Ctx.ResponseWriter
注意：ServeJSON()、Render() 等方法会直接写入 ResponseWriter，漏掉这步会 panic；Redirect() 同理，需检查 w.Code 是否为 302。
Mock 外部依赖（DB、RPC、缓存）推荐 testify/mockery 组合
控制器里通常调用 service 层，service 层再访问 DB 或远程服务。这时控制器测试的重点是“行为验证”，而非“集成执行”。
建议做法：
- 定义清晰 interface（如
UserService），控制器依赖该 interface - 用
mockery生成 mock 实现：mockery --name=UserService - 在测试中注入 mock 实例：
c.UserSvc = &mocks.UserService{} - 用
mock.On("GetUser", "123").Return(&User{}, nil)设定返回
性能影响：mock 调用比真实 DB 快 2–3 个数量级，适合高频运行的单元测试；但要注意——它无法发现 SQL 拼写错误、索引缺失等真实 DB 问题，这类必须靠集成测试兜底。
容易被忽略的是：mock 对象必须在每次测试前重置（mock.ExpectedCalls = nil 或使用 mock.AssertExpectations(t)），否则历史调用记录会干扰后续测试。
