调试Iris项目“没反应”或panic不明，主因是未理解框架行为：中间件写响应后漏ctx.StopExecution()致重复执行，或依赖注入字段为nil未校验而解引用panic。
调试 Iris 项目卡在“没反应”或“panic 不明”，八成不是代码逻辑错，而是框架行为没被理解——比如中间件提前写响应却漏掉 ctx.StopExecution()，或者依赖注入字段为 nil 却没做空检查。
中间件里写了响应却不阻断执行流
Iris 不会自动判断你是否已发送响应，ctx.StatusCode(401) 或 ctx.JSON() 后若不显式调用 ctx.StopExecution()，控制权仍会交给下一个中间件甚至最终 handler，导致重复写响应、状态码覆盖、甚至 panic（比如 handler 尝试再写 header）。
- 典型错误：JWT 验证失败后直接
ctx.JSON(401, ...)，末尾还写着ctx.Next() - 正确做法：所有提前返回分支末尾必须加
ctx.StopExecution()，且确保ctx.Next()在所有条件判断之外、仅当验证通过时才执行 - 调试技巧：在中间件开头加
fmt.Printf("[MIDDLEWARE] %s → %s\n", ctx.Method(), ctx.Path())，观察日志是否意外出现多次
依赖注入字段始终是 nil
字段注入失败不会报错，只会静默留空。控制器里一解引用（如 c.UserService.GetUser()）就 panic，但错误堆栈不指向注入问题，容易误判为业务逻辑崩溃。
- 必须同时满足三个条件：字段带
inject:""标签、控制器类型用app.RegisterController[MyController]()注册、被注入类型（如*UserService）已用app.Register()或app.Singleton[]显式注册 - 常见漏点：
app.Register(UserService{})是错的——传值会导致类型推导失败；应传指针：app.Register((*UserService)(nil)) - 快速暴露问题：在控制器
BeginRequest方法里加if c.UserService == nil { panic("UserService not injected") }
服务启动后无响应或立即退出
这不是 bug，是没调 app.Listen() 或 app.Run()。Iris 的 iris.New() 只建实例，不启 HTTP server。
- 现象：终端无日志、进程闪退、浏览器打不开 —— 检查
main.go最后是否有app.Listen(":8080")或app.Run(iris.Addr(":8080")) -
Listen()是阻塞调用，它之后的代码不会执行；想做启动后初始化，改用app.OnStarted(func(){...}) - VS Code 调试时若断点不生效，先确认 Go 插件已安装、
go env -w GO111MODULE=on已启用、且调试配置用的是dlv而非直接go run
路由参数取不到值
新手常把路径参数（如 /user/{id:uint64} 中的 id）和查询参数（?page=2）混淆，结果 ctx.URLParam("id") 返回空字符串，但程序不报错，逻辑悄悄走偏。
- 路径参数必须用
ctx.Params().Get("id")或带类型转换的ctx.Params().GetInt64("id") -
ctx.URLParam()只处理 query string，比如/search?keyword=go→ctx.URLParam("keyword") - 参数名大小写敏感：路由定义是
{userID}，就不能用ctx.Params().Get("userid")；拼错时返回空字符串，不会 panic，务必加校验
最易忽略的其实是「中间件控制流」和「注入字段空值」这两类静默失败——它们不抛明确错误，只让程序在某个看似无关的点突然崩掉。调试时优先在这两处埋日志或 panic 断言，比盲目翻业务逻辑高效得多。
