复用gRPC连接等四点优化可使QPS翻倍、降CPU内存压力，因新建连接重复DNS解析/TCP握手/TLS协商且易触达ulimit-n限制。
直接复用 gRPC 连接、禁用日志体打印、静态文件交由 sendfile、合理配置超时 —— 这四点改完，QPS 通常能翻倍，CPU 和内存压力明显下降。
为什么不能每次请求都新建 gRPC 连接
常见错误现象：too many open files 报错、服务启动几分钟后响应变慢、grpc.Dial 耗时飙升（常达 100ms+）。
根本原因：DNS 解析 + TCP 握手 + TLS 协商全在每次调用里重复执行，且连接不复用会快速耗尽系统 ulimit -n 限制。
实操建议：
- 在
app.Run前全局初始化一次：conn, err := grpc.Dial("backend:50051", grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithBlock()) - 用
app.RegisterValue(&itempb.ItemServiceClient{}, itempb.NewItemServiceClient(conn))注入，别塞进 controller 字段 - 每次调用前必须派生新 context：
ctx2, cancel := context.WithTimeout(ctx.Request().Context(), 3*time.Second)，立刻defer cancel()
日志中间件怎么避免拖垮吞吐量
默认开启 LogRequestBody: true 时，Iris 会把整个 POST body 读进内存再打印 —— 对上传接口或大 JSON 尤其致命，GC 频繁、分配激增。
使用场景：生产环境必须关；调试阶段可按需开，比如只对 4xx/5xx 状态码记录 request ID 和错误摘要。
实操建议：
- 初始化 logger 时显式禁用：
iris.Logger().SetLevel(iris.LogInfo), LogRequestBody: false, LogResponseBody: false - 绝对不要在中间件里调
ctx.ReadBody()或ctx.PostValues()—— 它们会提前消费 body，后续 handler 读不到数据 - 若需审计特定字段（如 user_id），从 header 或 query 提取，而非解析完整 body
静态文件为什么不能走 iris.FileServer
纯 Go 实现的 iris.FileServer 在处理 >1MB 文件或高并发请求时，CPU 占用高、内存拷贝多，远不如操作系统级 sendfile 系统调用高效。
性能影响：实测 100 并发下载 2MB 文件，iris.FileServer CPU 使用率 85%+，而 http.FileServer + os.Open + http.ServeContent 组合稳定在 15% 以下。
实操建议：
- 用标准库
http.FileServer替代：app.HandleDir("/static", iris.Dir("./assets"))不再推荐，改用http.StripPrefix("/static", http.FileServer(http.Dir("./assets"))) - 确保文件服务器启用
http.ServeContent的底层优化（Go 1.16+ 默认开启） - 配合 Nginx 做前置缓存更佳，Iris 层只负责动态逻辑
Listen() 和 Run() 配置哪些参数最影响并发表现
不调 Run() 或配错 ConfigureHost，服务可能跑着跑着就卡死或被系统 kill —— 很多“高并发问题”其实只是基础配置没兜住。
关键参数差异：
-
MaxConns控制最大并发连接数，默认不限，但受系统ulimit -n限制，建议设为5000防雪崩 -
ReadTimeout/WriteTimeout必须设（如30 * time.Second），否则慢请求长期占 goroutine -
IdleTimeout推荐设为60 * time.Second，防长连接空耗资源 - 用
app.ConfigureHost(func(su *iris.Supervisor) { su.Server = &http.Server{...} })才能生效，Listen()不支持这些细粒度控制
真正容易被忽略的是：这些配置必须在 app.Run() 之前完成，且 Run() 是 v12+ 唯一推荐入口 —— Listen() 已逐步弃用，它不兼容 TLS 和自定义 http.Server 实例。
