Go fcgi.ListenAndServe在Nginx下超时，因其不支持FastCGI长连接，需改用net.Listen+fcgi.Serve并启用fastcgi_keep_conn；Go fcgi不支持单连接并发请求，吞吐取决于单请求延迟与Nginx连接池配置。
Go fcgi.ListenAndServe 为什么在 Nginx 下总超时？
因为 fcgi.ListenAndServe 默认不处理连接复用和长连接，Nginx 的 fastcgi_keep_conn on 会等一个保持连接的信号，而 Go 标准库的 fcgi 实现压根不发 —— 它每次响应完就关 socket，Nginx 等不到下一次请求，直接断连重试，日志里反复出现 upstream timed out (110: Connection timed out)。
实操上必须绕过 fcgi.ListenAndServe，自己接管 listener 并显式启用 keep-alive 支持：
- 用
net.Listen("tcp", ":9001")启监听，别用fcgi.ListenAndServe - 对每个 accept 到的
net.Conn，用fcgi.Serve(conn, handler)处理（注意是单次调用，不是传 listener） - Nginx 配置里必须加
fastcgi_keep_conn on;，且fastcgi_pass指向这个 TCP 地址（如127.0.0.1:9001），不能用 Unix socket（Go fcgi 对 Unix socket 的 keep-alive 支持更弱）
Go 的 http.Handler 能直接喂给 fcgi.Serve 吗？
能，但要注意中间件和状态泄漏。标准库 fcgi.Serve 会为每个 FastCGI 请求新建一个 http.Request，并复用同一个 http.ResponseWriter 实例（底层是 fcgi.ResponseWriter）。这意味着：
- 不能在 handler 里缓存或复用
http.Request的 body（它是一次性读取的，二次读会返回 EOF） - 如果用了类似
gorilla/mux或自定义中间件，确保它们不依赖 server 端的 connection 生命周期（比如基于http.CloseNotify的逻辑会失效） -
ResponseWriter.Header().Set("Connection", "keep-alive")没用 —— FastCGI 协议本身不走 HTTP header 传连接控制，keep-alive 完全由 Nginx 和 fcgi 连接层协商
为什么本地测试正常，上线后 CPU 翻倍？
因为 Nginx 默认的 fastcgi_buffers 和 Go fcgi 的写入行为不匹配：Nginx 会把多个 FastCGI record 缓起来再刷给客户端，而 Go 的 fcgi.ResponseWriter 在 Write() 时可能频繁 flush，触发小包发送，加上 TCP Nagle 算法，导致大量微小 write() 系统调用。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
优化关键在两端协同：
- Nginx 侧：增大缓冲区，例如
fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; - Go 侧：避免在 handler 中频繁
fmt.Fprintf(w, ...)，改用io.WriteString或预拼接字符串；如果响应体大，直接w.Write([]byte{...})一次写入 - 禁用 Nagle：
conn.(*net.TCPConn).SetNoDelay(true)（在 accept 后、传给fcgi.Serve前设置）
Go fcgi 是否支持并发请求复用同一连接？
不支持。FastCGI 协议本身是 request-response 串行模型，一个连接同一时刻只能处理一个请求。所谓“并发”，其实是 Nginx 用连接池管理多个 fcgi 连接，每个连接顺序处理请求。Go 的 fcgi.Serve 是同步阻塞的 —— 它读完一个完整 FastCGI record，处理完 handler，再写回 response，才开始下一轮。
所以真正影响吞吐的是：
- 单连接处理延迟（handler 耗时越短，并发连接数需求越低）
- Nginx 的
fastcgi_max_requests（建议设为 1000–5000，避免单个 Go 进程跑太久内存泄漏） - Go 进程数 —— 必须用 systemd 或 supervisord 管理多个 fcgi 实例，Nginx 用 upstream 负载均衡到它们
很多人卡在以为 “开了 goroutine 就能并行处理”，其实没用 —— fcgi.Serve 内部不启动 goroutine，它就是个单线程 request loop。
