路由规则必须在注册时通过正则约束定义，如/user/{name:string regexp:^(?!admin$|root$).+$}，而非handler内判断；锚点^$、至少一个字符.+、显式string类型缺一不可；复杂校验应交由中间件或handler处理。
路由规则必须在注册时就定死，不能靠 handler 里 if 判断来“模拟排除”——否则请求已进入业务逻辑，404 就不干净，中间件也白跑。
用 {param:type regexp:...} 在路由层做关键字排除
想让 /user/{name} 拒绝 admin 和 root，就得把约束写进路由定义本身，而不是等进到 handler 再检查：
- 正确写法：
app.Get("/user/{name:string regexp:^(?!admin$|root$).+$}", handler) -
^和$必须写全，否则/user/admi或/user/admin/extra可能被误匹配 -
.+表示至少一个字符，避免空字符串/user/被接受 - 多个关键字用
|连接，不要加空格，如admin$|root$|test$ - 必须显式写
string类型，Iris 不识别裸{name regexp:...}
别指望 By 绑定或 RegisterParamFunc 做路由级排除
By 参数绑定（如 func(ctx iris.Context, name string)）只负责传参，不做任何校验；RegisterParamFunc 是解析后校验，返回的是 400，不是 404：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
/user/admin仍会匹配成功并进入 handler，只是你在里面手动 return - 无法和更精确的路由（如
/user/admin/dashboard）正确竞争优先级 - 路由表语义失真：本该“不存在”的路径，却在路由列表里占位
- 真正需要 404 的场景（比如 SEO 屏蔽、权限隔离），必须靠正则在匹配阶段拦截
复杂校验别塞进正则，拆到中间件或 handler 内部
正则适合做格式、关键字、长度等静态规则；查数据库、调外部服务、组合多字段逻辑，不适合放 regexp：
- 例如 “用户名不能与邮箱前缀相同”，这种得在 handler 里取
ctx.Params().Get("name")和ctx.URLParam("email")后比对 - 若多个路由共用同一套业务校验（如“ID 必须存在且属当前用户”），抽成中间件更干净：
app.Get("/post/{id:int}", authMiddleware, postExistsMiddleware, handler) - 正则太长会降低可读性，也难调试；Iris 的 regexp 支持有限，不支持条件断言、回溯引用等高级特性
嵌套路由组用 Party，别堆 app.Get
当路由超 10 条、有公共前缀（如 /api/v1/users）时，硬写一堆 app.Get 会导致中间件重复、冲突难排查、结构松散：
- 用
usersAPI := app.Party("/api/v1/users", authMw, logMw)创建分组，后续所有子路由自动继承中间件 - 嵌套也合法：
adminUsers := usersAPI.Party("/admin")，路径自动拼为/api/v1/users/admin -
Party返回新实例，不是原app，所以usersAPI.Get(...)才是正确调用方式 - 避免在
Party后直接写 handler，它不接受函数，只提供.Get/.Post等方法
正则写错最常踩的坑是锚点缺失和贪婪过度——写完务必用几个边界值手动测一遍 /user/、/user/admin、/user/admins、/user//，别只信单元测试覆盖。
