iris开发web应用核心流程为三步：初始化application、注册路由、调用listen或run启动服务；iris.new()返回空实例，适合完全控制场景，iris.default()自动注入日志与recover中间件，适合快速验证。
用 Iris 开发 Web 应用，核心流程就三步：初始化 Application、注册路由（含中间件与参数处理）、调用 Listen 或 Run 启动服务。没有“启动前必须配一堆配置”的强制门槛，但跳过关键细节会导致运行失败或行为异常。
如何正确创建和配置 Application 实例
iris.New() 和 iris.Default() 都返回 *iris.Application，但行为差异明显：
-
iris.New()返回空实例：无默认日志、无 recovery 中间件、无静态文件服务 —— 适合需要完全控制启动行为的场景 -
iris.Default()自动注入logger.New()和recover.New()，还预设了错误页模板 —— 适合快速验证或开发初期 - 生产环境建议用
iris.New()显式添加所需中间件，避免隐式依赖影响可观测性 - 若需自定义日志级别，必须在
app.Use()前调用app.Logger().SetLevel("error")，否则默认是"info"
路由注册时参数类型与验证器怎么写才不报错
路径参数如 {id:int} 看似简单，但实际容易因类型不匹配或验证器位置错误导致 404 或 panic：
- 参数类型必须紧贴参数名后，
{id:int min(1)}合法，{id:min(1):int}会解析失败 - 内置类型只有
string（默认）、int、long、bool、letter、file、path，不存在uint或float - 数值验证器
min()/max()只对int和long生效；字符串验证器prefix()/regexp()才对string有效 - 若参数未通过验证，Iris 默认返回 404，不会进 handler —— 这不是 bug，是设计行为，别指望在 handler 里做兜底校验
Listen 和 Run 的区别及端口监听常见陷阱
app.Listen(":8080") 和 app.Run(iris.Addr(":8080")) 功能一致，但底层逻辑不同：
-
Listen是简化封装，直接调用http.Server.Serve，不支持传入自定义http.Server配置 -
Run接收iris.Configurator，可组合iris.TLS、iris.WithCharset等选项，适合 HTTPS 或定制超时 - 监听
:80或:443在 Linux 上需 root 权限；普通用户应监听高位端口（如:8080），再由 Nginx 反向代理 - 若本地已占用端口，
Listen会 panic 并打印"listen tcp :8080: bind: address already in use"，不会静默失败
MVC 模式下控制器方法命名规则不能错
使用 mvc.New(app.Party("/api")).Handle(new(MyController)) 时，方法名决定路由映射，拼写或大小写错误直接导致 404：
- 基础 HTTP 方法必须全大写首字母：
Get()、Post()、Delete()—— 写成get()或GET()均无效 - 带路径后缀的方法名格式为
GetByXXX()、PostLogin()，其中ByXXX/Login会自动转为小写路径段，即GetByUser()→/user，PostLogin()→/login - 方法签名必须严格匹配：返回值只能是
any或mvc.Result，参数不能多也不能少（如Get(id string)不被识别） -
BeforeActivation是唯一可干预路由注册时机的钩子，用于动态注册子路由或绑定依赖，错过这个点就无法修改 MVC 路由结构
真正卡住人的往往不是语法，而是类型约束的隐式生效时机、MVC 方法签名的大小写敏感、以及 Listen 对端口状态的零容忍 —— 这些地方没报错信息，但请求就是不进 handler。
