Iris中通配符路由用{*\path}语法捕获任意深度子路径，必须置于路径末尾且仅出现一次，如/api/{*\path}匹配/api/v1/users等，捕获值不含开头斜杠，不可与{id}等参数混用。
通配符路由怎么写：用 {*path} 捕获任意深度子路径
Iris 中的通配符路由不是靠正则或模糊匹配，而是通过 {*path} 这种特殊语法实现的——它必须放在路径末尾，且只能出现一次。比如 /api/{*path} 能匹配 /api/v1/users、/api/static/js/main.js 甚至 /api/a/b/c/d/e，但不能写成 /api/{*path}/end，那样会直接 panic。
注意：{*path} 捕获的是完整子路径字符串（不含开头斜杠），不是分段参数。它和普通参数 {id} 或带约束的 {id:int} 互斥，不能混用在同一个路由里。
-
app.Get("/static/{*file}", staticHandler)→ 匹配/static/css/app.css，ctx.Params().Get("file")返回"css/app.css" -
app.Any("/proxy/{*path}", proxyHandler)→ 接收所有以/proxy/开头的请求，适合反向代理场景 - 若需区分层级（如树形节点），应改用多级参数路由
/nodes/{id}/children/{childID}，而非强塞通配符
为什么 {*path} 不生效？常见配置陷阱
通配符路由不触发，大概率是注册顺序或路径校正干扰导致的。Iris 默认启用路径校正（iris.WithoutPathCorrectionRedirection 未开启时），当客户端访问 /api/（带结尾斜杠）而你只注册了 /api/{*path}，它可能被重定向到 /api 并最终 404。
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 确保通配符路由注册在更具体路由之后——Iris 按注册顺序匹配，
/users/{id}必须在/users/{*path}前面，否则前者永远无法命中 - 如果希望
/admin/和/admin都走同一通配符处理，启动时显式加iris.WithoutPathCorrectionRedirection，否则/admin/会被 301 重定向，而重定向后的路径可能不匹配你的通配规则 - 检查是否误用了
{*path}的变体，比如{*anything}—— Iris 只认字面量{*path}，变量名不能改
{*path} 和中间件的区别：别用错地方
通配符路由本质仍是路由匹配，不是中间件。它只决定“哪个 handler 处理这个请求”，不自动注入上下文或共享逻辑。如果你只是想对某类路径统一加日志或鉴权，应该用 app.UseRouter() 或路径前缀分组，而不是堆砌通配符。
- 正确做法：
app.Party("/api").Use(authMiddleware).Get("/{*path}", apiHandler)—— 先分组再挂中间件 - 错误做法：为每个通配路由单独写
ctx.Next()调用中间件逻辑，既重复又难维护 -
{*path}适合代理、静态文件服务、CMS 路由兜底等真正需要动态解析路径的场景，不是“懒人中间件替代品”
性能影响：通配符路由真的慢吗？
Iris 的路由匹配基于 muxie，{*path} 是最后才检查的兜底分支，只要它排在注册列表末尾，对高频路径（如 /health、/user/{id}）完全无额外开销。但要注意：一旦触发通配匹配，Iris 就不再做进一步路径拆分，所有解析逻辑得你自己写（比如手动 split ctx.Params().Get("path")），这部分性能取决于你的代码，而非框架。
真正容易出问题的是嵌套过深的通配使用，比如 /v1/{*a}/v2/{*b} —— 这种写法非法，Iris 会拒绝启动。一个路由里只允许一个 {*path}，且必须结尾。
