go fmt 和 goimports 需串联使用：先 go fmt 统一格式，再 goimports -w 自动管理导入；vs code 中应设 “go.formattool”: “goimports” 避免重复触发。
go fmt 和 goimports 怎么配着用才不踩坑
只用 go fmt 会保留未使用的导入，导致编译失败；只用 goimports 又可能漏掉格式细节（比如空行、括号换行）。两者必须串联，且顺序不能反。
-
go fmt负责统一缩进、空格、换行风格，但不处理 import 行 -
goimports -w .自动增删 import，并按字母序重排，但默认不简化代码（如_ = fmt.Println不会删） - CI 中建议组合执行：
go fmt ./ && goimports -w .，否则 PR 里常出现“格式 OK，但 import 缺失”的误报 - VS Code 配置里如果启用了
"go.formatTool": "goimports"，就别再开go fmt自动保存，否则会重复触发
测试写到哪一层？go test 的真实使用边界
go test 不是万能的单元测试入口，它只跑 *_test.go 文件里以 Test 开头的函数。想覆盖集成或端到端场景，得手动组织。
- 纯逻辑函数：直接写
func TestXXX(t *testing.T)，用t.Run做子测试分组 - http handler 测试：别 mock net/http.Server，用
httptest.NewRecorder()+http.HandlerFunc构造请求上下文 - 数据库相关：gin/echo 等框架的测试要禁用中间件（
r.Use()后加r.NoRoute()），否则 panic 报错信息里找不到真实原因 - 避免在测试里写
time.Sleep——改用testify/suite或ginkgo的异步断言机制
pprof 性能分析为什么总卡在 runtime.mcall
看到火焰图顶部堆满 runtime.mcall 或 runtime.gopark，基本不是你的业务代码慢，而是 goroutine 在等锁、channel 阻塞或 GC 扫描中。
- 先确认是否开启 GC trace：
GODEBUG=gctrace=1，如果 GC 频繁，优先看内存分配热点（go tool pprof -alloc_space） - 阻塞分析用
go tool pprof http://localhost:6060/debug/pprof/block，重点查sync.Mutex.Lock和chan receive调用栈 - Web 服务里没设
http.Server.ReadTimeout，会导致大量 goroutine 卡在net.(*conn).Read，进而拖垮整个 block profile - 别依赖
go tool pprof -http的默认视图——点击“Focus”输入main.过滤掉 runtime 底层，才能看清自己代码的耗时分布
GORM 连接池配置不对，context deadline exceeded 就反复出现
错误不是数据库连不上，而是连接被占满后新请求等超时。GORM 默认的 MaxOpenConns=0（不限制），在高并发下反而容易打爆 DB。
立即学习“go语言免费学习笔记（深入）”；
- 生产环境必须显式设限：
db.SetMaxOpenConns(20)、db.SetMaxIdleConns(10)，数值按 QPS × 平均响应时间预估 - 别在每次 HTTP 请求里调用
gorm.Open——连接对象是线程安全的，全局复用一个*gorm.DB实例 - 事务内嵌套调用其他 service 方法时，记得把
*gorm.DB当参数传进去，而不是在方法里重新db.WithContext(ctx)，否则事务上下文丢失 - 用
db.session(&gorm.Session{PrepareStmt: true})开启预处理语句，避免高频 sql 解析开销（尤其带IN (?)的查询）
工具本身不难，难的是每个环节的隐式约束：格式化工具依赖文件编码是否为 UTF-8，pprof 依赖启动时是否开了 http.DefaultServeMux，GORM 的日志开关会影响 context 取消传播……这些细节不写进代码，只靠文档根本记不住。