go开发环境运行慢90%以上是代理、环境继承或配置未对齐所致：需确保goproxy=https://goproxy.cn,direct生效（direct必须在末尾），验证子进程是否继承该变量，ide如vs code需单独配置环境变量或修改系统级配置。
Go 开发环境运行慢，90% 以上不是代码或硬件问题，而是模块代理、IDE 环境继承、连接池或调试器配置没对齐。
go mod download 卡住或超时？检查 GOPROXY 和 direct 是否同时生效
现象：执行 go mod download 卡在某个模块几秒不动，最后报 dial tcp: i/o timeout 或反复重试 proxy.golang.org；即使运行过 go env -w GOPROXY=https://goproxy.cn,direct，日志里仍出现 GET https://proxy.golang.org/...。
根本原因不是网络差，而是子进程没读到变量——go env -w 只写入配置文件，不自动导出到当前 shell 环境。
- 验证方式：运行
go mod download -x github.com/gin-gonic/gin@v1.9.1，看输出中实际请求的 URL 是不是goproxy.cn - 临时修复：Linux/macOS 运行
export GOPROXY=https://goproxy.cn,direct；PowerShell 运行$env:GOPROXY="https://goproxy.cn,direct" - 持久生效：改完
go env -w后，必须重启终端或source ~/.zshrc（别只改.bashrc） -
,direct不能省：漏掉它，私有 Git 域名（如git.example.com/internal/lib）会直接被扔给goproxy.cn，导致not found或checksum mismatch
VS Code 调试卡两三分钟？重点查 gopls 是否继承了 GOPROXY
现象：VS Code 打开 Go 项目后，首次调试或跳转定义极慢，终端无响应，gopls 日志里反复尝试连接 proxy.golang.org。
这不是插件没装全，而是 gopls 启动时没拿到正确的代理环境。它默认从父进程（即 VS Code 启动的 shell）继承环境变量，但 GUI 应用常绕过 shell 配置。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 确认方式：终端里运行
go env GOPROXY正确，但在 VS Code 的集成终端里运行同一命令却为空 → 说明 GUI 启动未加载 shell 配置 - Mac/Linux：把
export GOPROXY=https://goproxy.cn,direct加到~/.zprofile（GUI 应用优先读这个，而非.zshrc） - Windows：用系统环境变量面板设置
GOPROXY，不要依赖 PowerShell 临时设置 - VS Code 设置中加
"go.toolsEnvVars": { "GOPROXY": "https://goproxy.cn,direct" }，强制透传
数据库操作或 HTTP 服务响应慢？别急着换框架，先看连接池和超时
现象：本地跑 Web 服务，接口首字节延迟高；或 DB 查询偶发卡顿，但 SELECT * 没报错。
常见误判是“Go 性能不行”，其实多数是连接复用失效或阻塞等待——尤其在开发机上未设限，反而更容易暴露问题。
- HTTP Server 必设三项：
ReadTimeout（防慢请求占连接）、WriteTimeout（防大响应拖垮）、IdleTimeout（防空闲连接堆积） - database/sql 连接池：不设
SetMaxOpenConns会导致连接数无限增长；不设SetConnMaxLifetime会触发 MySQL 的wait_timeout断连 - 批量插入别用循环
db.Exec：改用tx.Prepare+stmt.Exec，性能可提升 3–5 倍 - 调试时加
context.WithTimeout：避免单个查询 hang 住整个 handler
go build 太慢？增量编译和缓存清理比换工具更有效
现象：改一行代码，go build 仍要十几秒；go clean -modcache 后首次构建更慢。
Go 本身没有“智能增量编译”，但它的包级缓存机制非常可靠——只要 .a 文件没变，就不会重编。慢往往是因为缓存被破坏或路径污染。
- 删
$GOPATH/pkg/mod是最粗暴的清理方式，但会丢掉所有模块缓存；推荐用go clean -modcache - 避免混用
GO111MODULE=off和on：切换模式会污染pkg/mod，导致后续构建误判依赖变化 - 小项目用
go build -i能复用已安装的包（存进$GOPATH/pkg），但注意：任何依赖包更新都会让整个缓存失效 - 大型项目别依赖
-i，改用air或reflex监听文件变更，只在真正需要时触发go build
真正卡住的地方，往往藏在环境变量是否被子进程继承、direct 是否写在 GOPROXY 末尾、GUI 启动方式绕过 shell 配置这些细节里。调慢不是玄学，是变量没对齐。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
