Iris API性能取决于具体实现而非框架本身：需启用gzip压缩、调整内核somaxconn、避免handler中阻塞操作、使用连接池和异步日志等，否则压测QPS会严重失真。
Iris 框架本身在默认配置下就能支撑较高并发，但“API性能怎么样”不能只看框架名，得看你怎么用、有没有踩坑、压测环境是否真实反映业务场景。
ab 测试结果说明不了全部，但能暴露基础配置问题
你看到的 ab -n 10000 -c 1000 http://localhost:8080/ 结果里，QPS 数值受很多隐性因素影响：
-
app.Default()启动的实例默认没开gzip，静态响应体小（如 "Hello world!"）时影响不大，但一旦返回 JSON 或 HTML 片段，未压缩会显著拖慢网络层吞吐 - CentOS 7.4 的
net.core.somaxconn默认是 128，ab -c 1000实际可能大量连接被内核丢弃，表现为请求超时或连接拒绝，但ab报告里只显示Failed requests: 123这类模糊数字 - Iris 的
ctx.WriteString是同步写，如果 handler 里混入了阻塞操作（比如没设 timeout 的 HTTP 调用、无缓冲 channel 等待），整个 goroutine 就卡住，无法释放到 runtime 调度器
并发瓶颈通常不在 Iris 路由层，而在 handler 内部
从你贴的示例代码看，/ping 和 /hello 都是纯内存操作，这时 Iris 的路由匹配和 Context 初始化开销极低。真正掉性能的地方往往藏在下面：
- 数据库查询没走连接池，或
sql.Open放在 handler 里反复调用 → 每次新建连接，耗尽文件描述符 - 用了
time.Sleep(2 * time.Second)这类模拟耗时操作但没起 goroutine → 直接阻塞当前 HTTP goroutine - JSON 序列化大结构体时用了
json.Marshal而非fastjson或easyjson→ GC 压力陡增，尤其在高 QPS 下触发 STW - 日志写文件没加异步缓冲，每请求都
os.Write一次磁盘 → I/O 成为瓶颈
真实压测前必须改这三处 Iris 配置
不改这些，再好的硬件也跑不出框架标称性能：
- 显式启用 gzip：
app.Use(iris.Gzip)，否则所有文本响应都不压缩 - 限制最大连接数防雪崩：
app.ConfigureHost(func(su *iris.Supervisor) { su.Server.MaxConns = 5000 })，避免突发流量打垮系统 - 设置读写超时：
su.Server.ReadTimeout = 5 * time.Second和su.Server.WriteTimeout = 10 * time.Second，防止慢客户端长期占着连接
真正决定 API 性能上限的，从来不是框架名字，而是你 handler 里那几行代码有没有让 goroutine 真正“轻量”起来——它得进得快、干得快、退得快。别迷信 ab 数字，先确认你的 handler 里没藏着 http.Get、time.Sleep 或 log.Printf 这类隐形重操作。
