goland只是ide，不决定并发能力；百万级并发取决于代码是否正确配置http.server超时、连接池、goroutine控制及sync.pool复用等。
GoLand 本身不决定并发能力，它只是开发工具
GoLand 是 JetBrains 出的 Go 语言 IDE，它不参与运行时调度、网络 I/O 或内存管理。百万级并发连接能否跑起来，取决于你写的代码是否用对了 net/http 底层模型、是否规避了阻塞调用、是否合理使用 goroutine 和 sync.Pool，而不是 GoLand 开了什么开关。
常见误解是：换一个“更高级”的 IDE 就能撑住高并发——实际项目上线后卡在 http.Server 默认配置或 context.WithTimeout 漏设上，跟 GoLand 没半毛钱关系。
必须重写 http.Server 的默认配置
Go 标准库 http.Server 默认参数完全不适合网关场景：超时没设、连接数没限、读写缓冲区太小、TLS 握手没优化。不改就跑百万连接，大概率在 10k 连接时就开始 accept 队列溢出或 goroutine 泄漏。
-
ReadTimeout和WriteTimeout必须设（建议 ≤ 5s），否则慢客户端拖垮整个连接池 -
IdleTimeout推荐设为 30–60s，避免长连接空转占用 fd -
MaxConns（Go 1.19+）或配合net.ListenConfig控制LimitListener，防止 fd 耗尽 -
ConnState回调里记录连接状态变化，方便排查StateClosed是否被正确回收
示例关键片段：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
srv := &http.Server{
Addr: ":8080",
Handler: proxyHandler,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 60 * time.Second,
MaxConns: 1_000_000,
}
代理逻辑不能直接用 httputil.NewSingleHostReverseProxy
标准库 httputil.NewSingleHostReverseProxy 是玩具级实现：它把整个请求体 io.Copy 到后端，中间无流控、无超时传递、无 header 过滤、不复用底层 http.Transport 连接池。百万连接下，每个请求都新建 transport 连接，瞬间打爆后端或耗尽本地端口。
- 必须自定义
http.Transport：设MaxIdleConns、MaxIdleConnsPerHost（建议 ≥ 10000）、IdleConnTimeout - 转发时用
req.Body原始 reader +io.Copy分块转发，避免全量读入内存 - 显式设置
req.Header.Set("Connection", "keep-alive")，否则 HTTP/1.1 代理默认关闭连接 - 所有下游调用必须带
context.WithTimeout，且 timeout 要短于上游ReadTimeout
GoLand 调试百万连接时的实际限制
IDE 的调试器本质是注入 dlv，而 dlv 在高并发下会严重干扰调度：断点触发时暂停所有 goroutine，runtime.GC 被阻塞，连接堆积，最终触发内核 tcp_abort_on_overflow。这不是 bug，是调试器原理决定的。
- 压测阶段禁用 GoLand 的 debugger，改用
pprof（/debug/pprof/goroutine?debug=2）查 goroutine 泄漏 - 日志用结构化输出（如
zerolog），避免fmt.Printf在高并发下锁全局 io - GoLand 的 “Run with coverage” 会显著降低吞吐，仅用于单链路功能验证，别在压测环境开
真正卡点永远在系统层：ulimit -n 设置、epoll/kqueue 事件循环效率、TIME_WAIT 回收速度、GC pause 时间——这些 GoLand 看不见，你也得自己看 ss -s 和 go tool trace。
