Go环境配置错误会导致代理工具性能异常、goroutine泄漏、TLS握手失败等隐性故障；须确保GOROOT唯一且与go env一致，禁用冗余GOPATH，构建时加-s -w，显式配置http.Transport连接池并避免复用DefaultClient。
直接上结论：Go环境搭不对，后续所有代理工具（比如 ccproxy、1proxy、go-mysql）的编译、调试、甚至运行时连接复用和并发表现都会出问题——不是报错，而是性能掉档、goroutine 泄漏、HTTPS 代理握手失败这类“看起来能跑，但一压就崩”的隐性故障。
确认 Go 安装路径和 GOROOT 是否干净
很多代理项目依赖 net/http 和 crypto/tls 的行为一致性，而这些包在不同 GOROOT 下可能因版本或补丁差异导致 TLS 握手超时、HTTP/2 fallback 失败。Windows 用户尤其容易中招：MSI 安装器有时会把旧版 Go 留在 C:\Go，又把新版装到 C:\Program Files\Go，PATH 里混着两个 bin 目录。
- 执行
which go（macOS/Linux）或where go（Windows），只允许输出一行路径 - 检查
go env GOROOT输出是否与上述路径一致；如果不一致，手动清空系统环境变量里的冗余GOROOT，让 go 自动推导 - 避免手动设置
GOPATH—— Go 1.16+ 默认启用 module 模式，GOPATH仅影响go install全局二进制存放位置，对代理项目构建无实质影响
go build 时必须加 -ldflags '-s -w'
代理工具常部署在边缘设备或容器中，静态二进制体积直接影响启动速度和内存占用。未 strip 的可执行文件会包含 DWARF 调试符号和反射信息，对 ccproxy 这类需高频 fork 或 hot-reload 插件的工具来说，每次加载都多几百 KB 内存开销。
-
go build -ldflags '-s -w' -o proxy ./cmd/proxy是标准做法 - 别信某些教程说 “加了 -s 就没法 debug”，代理服务本身不依赖源码级调试，日志 +
pprof足够定位 goroutine 阻塞或内存泄漏 - 若用 CGO（比如集成 OpenSSL），需额外加
-extldflags '-static'，否则容器里缺 so 文件直接exec format error
HTTPS 代理必须验证 net/http.DefaultTransport 配置
几乎所有 Go 实现代理（1proxy、自研正向代理）都基于 http.Transport 转发请求。默认 transport 的 MaxIdleConnsPerHost 是 2，意味着同一域名最多维持 2 个空闲连接——在高并发 API 调试场景下，这会导致大量 TIME_WAIT 和连接重建，吞吐量卡死在 100 QPS 左右。
立即学习“go语言免费学习笔记（深入）”；
- 务必在代码里显式配置 transport：
&http.Transport{MaxIdleConns: 100, MaxIdleConnsPerHost: 100, IdleConnTimeout: 30 * time.Second} - 不要复用全局
http.DefaultClient，它共享这个保守的 transport；每个代理实例应持有独立 transport 实例 - 若代理需处理客户端证书（如 mTLS），
TLSClientConfig必须设为&tls.Config{InsecureSkipVerify: false}，否则中间人攻击风险无法规避
真正难的不是写转发逻辑，而是让每一个 goroutine 都在该退出时干净退出、让每一条 TLS 连接都复用而非重连、让每一个 http.Request.Body 都被正确关闭——这些细节藏在环境初始化和 transport 配置里，而不是 main 函数里。
