Iris不支持真正的“可选路由参数”；必须用两条独立路由实现：/users（列表）和/users/{id:uint64}（详情），且无参路由须前置；或慎用{id:path}手动解析，但丧失类型校验与路径精确匹配能力。
Iris不支持真正的“可选路由参数”
直接说结论：Iris框架原生没有类似 {id?} 这种语法来声明可选路径参数。所有花括号包裹的参数都是必填的，匹配失败就 404。想实现“有 ID 走详情、没 ID 走列表”这类逻辑，必须用其他方式绕过。
用两个独立路由覆盖“可选”语义
最稳妥、最符合 Iris 设计习惯的做法是显式注册两条路由，分别对应“带参数”和“不带参数”的场景：
-
app.Get("/users", listUsersHandler)—— 列表页，无参数 -
app.Get("/users/{id:uint64}", getUserHandler)—— 详情页，强类型约束 ID
注意顺序：必须把无参路由写在前面。因为 Iris 路由匹配是**从上到下第一个成功即止**；如果把 /users/{id} 放前面，/users 请求会被错误地当成 {id} = "s"（字符串 "s" 尝试转 uint64 失败），最终 404。
用 {id:path} 捕获并手动解析（慎用）
如果你坚持用单一路由表达“可选”，可以用 {id:path} 捕获剩余路径段，再在 handler 里判断是否为空或是否符合 ID 格式：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
app.Get("/users/{id:path}", func(ctx iris.Context) {
idStr := ctx.Params().Get("id")
if idStr == "" {
listUsersHandler(ctx)
return
}
// 手动尝试解析
id, err := strconv.ParseUint(idStr, 10, 64)
if err != nil {
ctx.StatusCode(400)
ctx.WriteString("invalid id format")
return
}
// 继续处理详情逻辑
getUserByID(ctx, id)
})
风险点：{id:path} 会吞掉整个后续路径，比如 /users/123/extra 也会被匹配，idStr 得到的是 "123/extra"，需额外切分或校验；且无法享受 {id:uint64} 的编译期自动拦截能力，错误处理全靠自己写。
别误用 ctx.URLParam() 或查询参数模拟
有人试图用 /users?id=123 这种查询参数方式“假装”可选路径参数，这是设计错位：
-
ctx.URLParam("id")是读?id=123，不是路径参数，和 RESTful 风格不符 - 搜索引擎、缓存、前端路由都更倾向路径结构化，查询参数适合过滤、分页等非核心标识场景
- Iris 的
{id:uint64}宏校验、自动生成 URL 等能力对查询参数完全失效
真正需要“可选”的地方，大概率是业务语义上本就该拆成两个资源端点——列表和详情本来就是不同资源，硬塞进一个路由只会让 handler 越来越胖、校验逻辑越来越散。
