中小型项目应使用 Go 1.21+、Go Modules、VS Code 官方 Go 扩展，配合 GOPROXY 和标准目录结构，5 分钟内可启动可维护服务；须从官网下载二进制包、禁用系统包管理器、首次打开 Go 文件时安装全部工具、执行 go mod init 后立即设 GOPROXY、采用 cmd/internal/pkg 分层结构，并在添加 import 后立刻运行 go mod tidy。
直接上结论：中小型项目用 Go 1.21+ + Go Modules + VS Code 官方 Go 扩展，配合 GOPROXY 和标准目录结构，5 分钟内能跑起可维护服务，没必要折腾多版本管理或复杂 IDE。
go version 必须 ≥ 1.21
Go 1.21 是当前中小项目最稳妥的起点。低于这个版本（比如 Ubuntu 自带的 1.18）会缺失泛型稳定支持、embed 的可靠行为，以及 go test 的新特性（如 -count=1 防缓存），后续引入 Viper、Zap 或 gRPC 时容易卡在依赖解析上。
- 别信系统包管理器（
apt install golang或brew install go），它们常滞后 1–2 个大版本 - 去 https://www.php.cn/link/81836b7cd16991abb7febfd7832927fd 下载对应系统的二进制包（如
go1.21.6.darwin-arm64.tar.gz），解压到/usr/local/go - 确认
go version输出含go1.21.x，不是go1.20.x或更低
VS Code + Go 扩展是默认最优解
中小型团队没理由为开发环境投入额外成本。VS Code 配官方 Go 扩展（ID：golang.go）已覆盖全部基础需求，且自动安装 gopls、gofmt、dlv 等工具，无需手动 go install。
- 首次打开
.go文件时，弹窗提示“Install All Tools”，必须点——否则gopls缺失会导致跳转、补全失效 - 不要装第三方 Go 插件（如旧版
ms-vscode.Go），它已被官方扩展取代，冲突会导致go mod tidy卡住 - 如果
gopls报错 “no module found”，说明项目根目录下没有go.mod，先运行go mod init example.com/myapp
go mod init 后立刻设 GOPROXY
国内不设 GOPROXY，go get 和 go mod tidy 基本无法完成。这不是可选项，是启动项目的硬性前置步骤。
立即学习“go语言免费学习笔记（深入）”；
- 执行
go env -w GOPROXY=https://goproxy.cn,direct（阿里云镜像更稳，比proxy.golang.org少超时） - 验证是否生效：
go env GOPROXY应输出https://goproxy.cn,direct - 若仍卡在
Fetching modules...，检查公司网络是否拦截了 HTTPS 代理域名，可临时换为https://mirrors.aliyun.com/goproxy/
cmd/internal/pkg 目录结构别省略
项目一过千行，裸奔式平铺 main.go + handler.go + model.go 就会失控。中小项目用标准布局不增加负担，反而减少后期重构成本。
-
cmd/myapp/main.go只做三件事：加载配置、初始化日志、启动 server —— 别塞业务逻辑 -
internal/下按职责拆分：handler（HTTP 路由）、service（核心流程）、model（数据结构）、config（Viper 实例） -
pkg/放跨项目复用代码（如通用 HTTP client、加密工具），避免internal里出现循环引用 - 别为了“简洁”把所有东西塞进
main.go—— 那不是轻量，是技术债预支
真正容易被忽略的是 go mod tidy 的执行时机：它必须在写完 import 语句后立刻运行，而不是等写完全部逻辑再补。漏掉这步，CI 构建时会因依赖缺失失败，而本地又因缓存看似正常——这种差异最耗排查时间。
