iris项目必须调用listen()启动服务，v12中run()已弃用；路径参数用ctx.params().get()，中间件响应后需调ctx.stopexecution()；配置应分离业务与http参数，环境变量优先用于敏感配置。
启动 Iris 项目不是调 iris.New() 就完事——没配好启动参数，服务要么起不来、要么起得不对、要么线上行为和本地不一致。
Listen() 和 Run() 到底用哪个
别再混用 Run() 和 Listen()。v12 中 Run() 已被标记为 deprecated，下个小版本可能直接移除；Listen() 是当前唯一推荐的启动方式。
-
app.Listen(":8080")最简写法，等价于app.Run(iris.Addr(":8080"))，但语义更清晰 - 要加调试日志？传第二个参数：
app.Listen(":8080", iris.WithLogLevel("debug")) - 想用 HTTPS 或 Unix socket？必须用
iris.TLS()或iris.Unix()配置项，不能只改端口号字符串 - 如果用了自定义
http.Server（比如设了ReadTimeout），必须用app.ConfigureHost()，否则配置不生效
iris.Configuration 只管 HTTP 服务器行为，不管业务参数
很多人往 iris.Configuration{} 里塞数据库地址、JWT 密钥、缓存 TTL，这是错的——这个结构体只影响 Listen() 启动时的 HTTP server 行为，和你的业务逻辑完全无关。
- 有效字段举例：
Timeout: 30 * time.Second（HTTP 读写超时）、DisableInterruptHandler: true（禁用 Ctrl+C 自动关服） -
Charset字段默认就是"UTF-8"，改它对 JSON 响应编码没影响，JSON 由ctx.JSON()内部控制 - 业务参数（如
db.host、cache.ttl）必须定义为自定义 struct，用viper.Unmarshal()或os.Getenv()加载后，再注入 handler 层
环境变量 vs Viper：选哪个取决于部署场景
小项目或容器化部署，os.Getenv() 足够快也足够稳；大项目或多格式配置（YAML/TOML/JSON 混用），才值得上 Viper。
- Docker/K8s 天然支持
env:注入，无需挂卷、无文件 I/O 开销，os.Getenv("PORT")是纯内存读取 - 用 Viper 却忘了
viper.AutomaticEnv()？viper.Get("DB_HOST")会返回空——环境变量名和代码对不上 - 坚持用 Viper 的话，初始化必须在
main()最开头，且在iris.New()之前完成viper.Unmarshal()，否则 handler 里取不到值 - 硬编码配置仅适合 demo；上线必须外置，否则每次改端口都要重新编译
中间件注册顺序和路由参数取值是高频踩坑点
这两个地方出错，不会报编译错误，但请求永远进不了 handler，或者取到空值，排查起来特别费时间。
-
app.Use()必须在所有app.Get()/app.Post()之前，否则对已注册的路由完全无效 - 路径参数（如
/user/{id:uint64}）要用ctx.Params().Get("id")，不是ctx.URLParam()——后者只取查询参数（?id=123） - 中间件里写了响应但没调
ctx.StopExecution()？后续 handler 还会执行，可能重复写 body 或 panic - 没显式调
app.Listen()？进程会立刻退出或阻塞但无响应——Iris 不自动监听，这点和很多框架不同
真正难的不是“怎么启动”，而是“哪些配置该从环境来、哪些该走文件、哪些该在启动时校验”。比如 JWT 密钥必须从环境变量加载并做非空检查，而 API 版本号可以常量写死——这种判断比选 Listen() 还重要。
