iris在标准压测下qps稳定在7.5万左右，latency为13.03ms±3.80ms，远超gin、echo；其高性能源于radix tree路由优化、context对象复用及静态文件零拷贝，但需注意mvc强制分层和部分中间件适配成本。
Iris的路由性能实测数据到底多少
直接说结论：在标准压测场景下，Iris的QPS稳定在7.5万左右（wrk -d 100s -c 1024 -t 8），这个数字和C++自研框架接近，远超gin、echo在同配置下的表现。关键不是“快”，而是它在高并发下延迟抖动小——Latency 13.03ms ± 3.80ms，说明请求处理时间更集中，不容易因某次GC或锁竞争突然拉长。
为什么Iris压测结果比gin高一截
根本原因在底层路由实现：Radix Tree匹配无回溯、无正则解析开销；而gin默认用httprouter（也是Radix Tree），但Iris做了两处关键优化：
- 路径参数解析提前缓存，避免每次请求都做字符串切分
- 中间件链路使用
sync.Pool复用Context对象，减少GC压力 - 静态文件服务默认启用
http.ServeFile的零拷贝路径（io.Copy不走内存缓冲）
这些细节在ab或wrk压测中不显眼，但在真实抽奖系统里——比如每秒上万次/lottery/draw请求带用户ID和活动ID两个参数——就直接反映为P99延迟下降30%以上。
压测时容易被忽略的环境陷阱
很多人跑出的Iris QPS只有2–3万，问题通常不在框架本身，而在测试环境配置：
-
ulimit -n没调高，Linux默认1024文件描述符，wrk -c 1024直接卡住连接建立 - 没关掉Go的GC日志（
GODEBUG=gctrace=1），日志IO拖慢吞吐 - 用
curl或浏览器手动点，根本测不出并发，必须用wrk或hey - 本地单机压测时，客户端和服务端共用网卡，TCP连接数到瓶颈前先撞上端口耗尽（
TIME_WAIT堆积）
真正有效的压测，得把wrk单独部署在另一台机器，且服务端启动前执行ulimit -n 65535并确认net.core.somaxconn已调大。
Iris高性能的代价是什么
它快，但不是没有取舍：
- MVC结构强制分层，写简单接口比gin多2–3行代码（要定义
Controller结构体+Register方法） - 文档里没明说但实际存在：
iris.Context不是net/http.ResponseWriter的直接封装，某些需要原生ResponseWriter的中间件（如Prometheus的InstrumentHandler）得额外适配 - WebSocket支持虽有，但
Conn.WriteMessage默认不带超时控制，高并发推送时容易阻塞goroutine
如果你的系统90%接口是纯JSON读写、路由嵌套深、还要快速接入监控和版本管理，Iris的性能优势能直接落地；但如果只是做个内部工具API，gin的轻量和生态成熟度反而省事。
