iris服务必须显式调用listen()或run()才能启动，否则进程静默退出或阻塞；路径参数用ctx.params().get()，查询参数用ctx.urlparam()；中间件响应后须调ctx.stopexecution()阻止后续执行。
iris.Context 类型写错、go mod init 没执行、app.Listen() 漏掉——这三处不落实，教程再全也跑不起来。
为什么照着教程写完却连 8080 都打不开
不是代码有语法错误，而是服务根本没启动。Iris 不会自动监听端口，iris.New() 只是初始化一个空壳实例。
- 必须显式调用
app.Listen(":8080")或app.Run(iris.Addr(":8080"))，否则进程启动后立刻退出或静默阻塞 - 常见现象：终端无日志、浏览器请求超时、
ps aux | grep go看不到监听进程 -
Listen()是阻塞调用，它之后的代码不会执行；想做启动后初始化，得用app.OnStarted()回调
ctx.Params().Get("id") 和 ctx.URLParam("id") 到底该用哪个
路径参数（如 /user/{id}）和查询参数（如 /user?id=123）走的是两套机制，混用就取不到值。
-
ctx.Params().Get("id")：用于 RESTful 路径中花括号定义的参数，类型安全可配合GetInt64("id")自动转换 -
ctx.URLParam("id")：只解析 URL 查询字符串（?id=123），对/user/123返回空字符串 - 参数名大小写敏感：路由定义是
{userID}，但写了ctx.Params().Get("userid")，结果就是空——Iris 不报错，只默默返回 ""
中间件里写完响应为什么还进了 handler
Iris 不像 Gin 那样自动中断执行流，ctx.Next() 不管前面有没有写过响应，它都照常把控制权交出去。
- 一旦调了
ctx.StatusCode(401)+ctx.JSON()，必须紧跟ctx.StopExecution()，否则后续中间件和最终 handler 仍会运行 - 典型错误模式：
if err != nil { ctx.JSON(401); ctx.Next() }—— 这里的ctx.Next()在校验失败时也执行了 - 正确结构是：
if err != nil { ctx.StatusCode(401); ctx.JSON(...); ctx.StopExecution(); return }，确保ctx.Next()只在校验通过时才调
JWT 中间件里 ctx.User.Get() 总是 nil
ctx.User 是个空接口容器，不是登录态自动绑定的魔法字段，它的值完全取决于你是否在合适时机、用合适方式调用了 ctx.User.Set()。
- 赋值必须发生在认证中间件里，且要在
ctx.Next()之前；如果中间件注册顺序在路由之后，或者被更早的ctx.StopExecution()截断，Set()根本不会执行 - 如果用了
app.Party("/admin")分组路由，中间件要注册在分组上：admin.Use(authMiddleware)，而不是全局app.Use() -
ctx.User.Get()返回nil时，先检查go.mod里是不是真引入了github.com/kataras/iris/v12，旧版 v11 的User接口行为不同
app.Use() 必须在所有 app.Get() 之前，ctx.User.Set() 必须在校验成功后、ctx.Next() 之前——这些顺序约束不满足，代码能编译、能启动，但行为完全不可控。
