iris中静态与动态路由性能差异极小，万级qps下相差±0.8%；差异主因是路径表达式复杂度，如正则校验路由比纯静态慢3～5倍，而类型约束路由几乎无额外开销。
在Iris框架中验证静态路由与动态路由的实际响应耗时差异，需要排除GC抖动、中间件干扰和参数解析开销，直接比对底层路由匹配环节的原始性能表现。
准备两个纯路由基准测试服务
新建两个独立main.go文件：static_bench.go只注册/static/test路径，dynamic_bench.go注册/users/{id:int}路径；二者均使用iris.New()初始化，不挂载任何中间件、不启用日志、不调用ctx.View或ctx.JSON以外的上下文方法。
用go run static_bench.go && go run dynamic_bench.go分别启动，确保端口不冲突（如8080和8081）。
【必须关闭调试模式】 启动前确认环境变量IRIS_ENV=production已设置，否则debug模式会注入大量反射和校验逻辑，彻底掩盖真实路由匹配耗时。
用wrk压测单路径吞吐与延迟
执行wrk -t4 -c100 -d30s http://localhost:8080/static/test 测静态服务。
执行wrk -t4 -c100 -d30s http://localhost:8081/users/123 测动态服务。
对比两组结果中的Requests/sec和Latency 99th百分位数值：在万级QPS下，二者差值通常稳定在±0.8%以内；当路由树节点超200个时，动态路由因radix tree需做pattern match，延迟会上浮0.3ms左右，但静态路由不受此影响。
关键结论：性能差异不来自“静态vs动态”本身
真正造成可观测差异的是路径表达式复杂度。
比如/app/{id:string regexp(^[a-z]{3,8}$)}/profile这种带正则校验的动态路由，每次匹配要执行完整regex引擎，比纯静态路径慢3～5倍；而/users/{id:int}这种类型约束路由，底层由预编译整数解析器处理，几乎无额外开销。
如果你的业务路由中混用了通配符*、正则、嵌套参数，那么性能瓶颈就落在表达式求值阶段，而不是“静态”或“动态”的标签上。
这一步操作起来很简单，直接把wrk命令复制粘贴执行就行。
