Go新手最常因goroutine泄漏踩坑：启动协程往无缓冲chan发数据却无人接收，或用context控制生命周期却未在select中处理ctx.Done()，导致静默内存泄漏。
Go新手做项目，最常栽在“看似简单、实则埋雷”的地方——不是语法不会，而是对语言设计哲学和工程惯性缺乏体感。下面这几个坑，90%的初学者都在头两个项目里踩过。
goroutine 泄漏：没配对的 chan 或没响应的 ctx.Done()
协程泄漏不是报错，而是静默吃内存。最典型的是启动一个 goroutine 往无缓冲 chan 发数据，但没人接收；或者用 context 控制生命周期，却忘了在 select 里处理 。
- 永远确保通道通信是“发送+接收”配对，或改用带缓冲通道 + 超时：
ch := make(chan int, 1) - 所有长期运行的 goroutine 必须监听
ctx.Done()，且不能只写default:分支来“假装处理” - 用
sync.WaitGroup等待时，defer wg.Done()要放在 goroutine 内部最开头，避免因 panic 漏掉
func handleV1(ctx context.Context, items []Request) {
var wg sync.WaitGroup
for _, req := range items {
wg.Add(1)
go func(r Request) {
defer wg.Done()
select {
case <-ctx.Done():
return // 真正退出
default:
processItem(r)
}
}(req)
}
wg.Wait()
}
变量隐藏：用 := 在 if 里悄悄创建新变量
这是 Go 特有的“语法糖陷阱”。在 if 块里用 := 重声明同名变量，会创建新的局部变量，外部变量不受影响——配置加载、错误恢复等场景极易出错。
- 检查所有
if err != nil后的:=，确认是否真要新建变量 - 关键逻辑分支中，统一用
=赋值，或换新变量名（如defaultCfg）显式区分作用域 - 启用
go vet或静态分析工具，它能捕获大部分变量隐藏警告
// ❌ 错误：config 和 err 都被重新声明
if config.DatabaseURL == "" {
config, err := loadDefaultConfig() // 新变量！外部 config 不变
if err != nil { return err }
}
// ✅ 正确：复用原有变量
if config.DatabaseURL == "" {
defaultConfig, err := loadDefaultConfig()
if err != nil { return err }
config = defaultConfig // 显式赋值
}
依赖与模块管理：盲目 go mod tidy 反而引入不兼容版本
go mod tidy 是好命令，但新手常忽略它“自动选最新兼容版”的行为——比如某个间接依赖升到 v2，而你的代码还用着 v1 的接口，编译就挂了。
- 执行
go mod tidy后，立刻看go.mod文件里有没有意外升级的包（尤其带v2、v3的） - 遇到冲突，别急着删
go.sum，先用go list -m all | grep 包名查清谁拉进来的 - 国内开发务必设
GOPROXY：go env -w GOPROXY=https://goproxy.cn,direct
配置与初始化：把 main() 当万能胶水，硬塞所有启动逻辑
很多新手把数据库连接、日志初始化、HTTP 路由注册全堆在 main() 函数里，结果一加新功能就乱成一团，测试也写不了。
- 按职责拆：用
/cmd放入口，/internal放核心逻辑，/config专管配置解析（推荐viper） - 初始化函数要可重入、可测试，比如
initDB(cfg DBConfig) (*gorm.DB, error)，别直接操作全局变量 - JWT 的
AppKey这类敏感项，绝不能写死在代码里，必须从环境变量或配置文件读取
真正卡住新手的，往往不是“不会写”，而是“不知道哪一步该停住去检查”。比如跑通 go run main.go 后，别急着加功能——先写一个 TestMainInit，验证配置加载、DB 连通、日志输出是否都按预期发生。小步验证，比后期 debug 十个 goroutine 更省时间。
