go测试中应手动mock iris.context接口而非application，通过httptest驱动真实http流程；外部依赖需提前抽象为接口注入，时间等逻辑抽成可替换函数；避免复用mock context实例以防状态污染。
Go 测试中如何 Mock Iris 的 Context 和 Application
Iris 本身不内置 Mock 工具，但它的 Context 是接口（iris.Context），Application 也可通过构造函数控制依赖，这使得 Mock 成为可行且轻量的事。关键不是“替 Iris 写 Mock 库”，而是利用其设计特性做最小侵入式模拟。
常见错误是试图 mock iris.New() 返回的完整 *iris.Application 实例——它内部含大量状态和 goroutine，强行 mock 易崩溃或漏覆盖；正确做法是只 mock handler 入参的 ctx iris.Context，并用 httptest 驱动真实 HTTP 流程。
- 对单元测试 handler：用
iris.New().NoLayout().Handler创建一个无启动、无路由的裸 handler，再传入自定义httptest.ResponseRecorder和http.Request，通过iris.Context的 mock 实现（如ctx.Values().Set("user_id", 123)）注入测试数据 - 对集成测试路由行为：直接用
iris.New()启动测试服务，但禁用日志、关闭服务器监听（app.Run(iris.Raw, iris.WithoutServer)），配合httptest.NewRequest和httptest.NewRecorder发起请求 - 避免在测试里调用
app.Listen或app.Run—— 这会真正绑定端口、启动 goroutine，导致测试间干扰或端口占用
数据库/HTTP 客户端等外部依赖怎么隔离？
Iris 不强制你用什么数据库或 HTTP 客户端，所以 Mock 外部依赖的关键在于“提前抽象”——不是在 handler 里直接 new sql.DB 或调用 http.Get，而是把它们作为接口依赖注入。
例如，定义一个 UserRepo 接口：
type UserRepo interface {
FindByID(ctx iris.Context, id int) (*User, error)
}
测试时用 struct 实现该接口并返回预设值，生产时用真实实现。这样 handler 只依赖接口，完全不知道底层是 MySQL 还是 mock 数据。
- 不要在 handler 函数体内初始化 DB 或 client：会导致无法替换，测试只能走真实网络或数据库
- HTTP 外部调用统一走
http.Client接口，测试时用httpmock或自定义RoundTripper拦截请求 - 时间相关逻辑（如
time.Now()）也应抽成函数变量（如nowFunc := time.Now），测试时可替换为固定时间
为什么不用 gomock 或 mockgen 自动生成 Iris 相关接口？
因为 Iris 的核心接口（如 Context）方法多、生命周期短、常带 context 参数，用代码生成工具反而增加维护成本。实际项目中，90% 的测试只需手动实现 1–3 个方法的 mock struct 就够用。
比如一个最简 Context mock：
type mockContext struct {
iris.Context
mockValues map[string]interface{}
}
func (m *mockContext) Values() iris.Map { return m.mockValues }
func (m *mockContext) GetStatusCode() int { return 200 }
func (m *mockContext) JSON(statusCode int, obj interface{}) error { return nil }
- 生成工具 mock 出来的方法往往包含未使用参数（如
context.Context），需额外 stub，反而模糊测试意图 - Iris 的
Context方法行为高度依赖当前请求生命周期，自动 mock 很难覆盖真实路径（如中间件修改Values()后的读取顺序） - 手写 mock 更快、更可控，且能精准暴露 handler 对
Context的实际依赖（比如它只用了Values()和JSON()，那就只实现这两个）
容易被忽略的 Context 生命周期陷阱
很多人 mock 了 Context，却忘了 iris.Context 的底层是基于 http.Request.Context() 构建的，而 Go 的 context.Context 是不可变的——一旦超时或取消，所有派生 context 都失效。测试中若没显式设置 deadline 或 cancel，某些 handler 里的 ctx.Done() 可能永远不触发，导致 timeout 相关逻辑无法验证。
- 测试带超时的 handler 时，必须用
context.WithTimeout包装原始 context，并传给 mockContext的构造逻辑 - 不要复用同一个 mock
Context实例跑多个测试用例——Values()是共享 map，易造成状态污染 - Iris 的
ctx.Next()和中间件链依赖真实的Application路由结构，纯 mockContext无法测试中间件跳转逻辑；这类场景必须用httptest真实发起请求
