本地Go代码演练环境的核心瓶颈是反复启动、路径加载和工具链初始化，而非编译速度；根本原因在于go run默认触发隐式模块解析与远程依赖检查，需显式启用模块、预初始化go.mod、配置代理并优化VSCode任务配置。
本地 Go 代码演练环境的核心瓶颈不在编译速度，而在反复启动、路径加载和工具链初始化——用 go run 直接执行单文件没问题，但一旦涉及模块依赖、多文件或调试，就容易卡在 go mod download 或 gopls 初始化上。
为什么 go run main.go 有时慢得反常
不是 Go 编译器本身慢，而是默认行为触发了隐式模块解析和远程包检查。尤其当项目没初始化 go.mod，或 GO111MODULE=auto 且当前路径在 $GOPATH/src 外时，go run 会尝试拉取所有未缓存的间接依赖（哪怕只用 fmt）。
- 确认是否启用模块：运行
go env GO111MODULE，应为on；若为auto，执行go env -w GO111MODULE=on - 新建演练目录后，立刻执行
go mod init tmp（模块名随意），避免每次go run都重新推导 - 禁用代理加速首次依赖获取：
go env -w GOPROXY=https://goproxy.cn,direct（国内推荐） - 如果只是临时跑几行代码，用
go run -gcflags="-l" main.go跳过内联优化，可省掉约 10–15% 编译时间
VSCode 中 Ctrl+Shift+B 编译卡住的真正原因
VSCode 默认调用的是 go build 而非 go run，且任务配置若未指定工作目录或输出路径，就会在错误位置生成二进制，再被 gopls 扫描引发重载延迟。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查
.vscode/tasks.json是否含"options": {"cwd": "${workspaceFolder}"}，缺失会导致路径错乱 - 避免使用
go build .，改用go build -o /dev/null .（Linux/macOS）或go build -o NUL .（Windows）跳过写磁盘，专注验证语法和依赖 - 关闭 VSCode 的
"go.useLanguageServer": true仅在纯脚本演练时启用；频繁保存小文件时，gopls的语义分析反而拖慢响应 - 如需热重载，别用官方任务，直接装
air：go install github.com/cosmtrek/air@latest，然后终端里跑air -c air.toml
go build 和 make 在演练阶段的取舍
对单文件或三五个文件的即兴实验，make 是累赘；但一旦开始分 handler、model、cmd 目录，不加 Makefile 就意味着每次都要手动敲一串 go build -ldflags、go test -race、go vet。
立即学习“go语言免费学习笔记（深入）”；
- 最简
Makefile只需三行：build: go build -o bin/app .、run: build && ./bin/app、clean: rm -f bin/app - 加个
.PHONY: build run clean防止与同名文件冲突 - 不要在
build目标里塞go mod tidy——演练期依赖变动频繁，手动运行更可控；等结构稳定后再放进make init - 跨平台编译不用
GOOS=linux GOARCH=amd64 go build反复输，写成build-linux: GOOS=linux GOARCH=amd64 $(MAKE) build
真正影响效率的从来不是编译耗时，而是你每次想试一行新逻辑时，要等多久才能看到结果。删掉多余插件、固定模块初始化、绕过磁盘写入、按需启用语言服务器——这些才是让 Go 演练“指哪打哪”的关键动作。
