go mod init 后 import 报错，90% 是因 GOPROXY 未配置或配置错误；需执行 go env -w GOPROXY=https://goproxy.cn,direct 并确认 GO111MODULE=on，删除旧 go.mod/go.sum 重新初始化，VS Code 需重启 Go 扩展。
go mod init 之后为什么 import 报错？
模块初始化后 import 失败，90% 是 GOPROXY 没配或配错。Go 1.16+ 默认启用模块模式，但国内不设代理就卡在 go get 或 import 解析阶段。
- 运行
go env -w GOPROXY=https://goproxy.cn,direct（国内推荐）或https://proxy.golang.org,direct（官方） - 确认
GO111MODULE=on已启用：执行go env GO111MODULE，输出必须是on - 删掉
go.mod和go.sum，重新go mod init your-module-name再试 - 如果用 VS Code，重启 Go 扩展或整个编辑器——它有时缓存旧的 module 状态
写 HTTP 服务时，net/http 和 Gin 到底怎么选？
别一上来就上框架。net/http 是标准库，轻、稳、无依赖；Gin 是第三方，快、灵活、但引入额外抽象层。选错会拖慢调试节奏。
- 练手、写 CLI 工具、内部小 API：直接用
net/http。5 行就能跑起来，错误堆栈干净，http.HandleFunc+http.ListenAndServe足够 - 需要中间件（鉴权、日志）、参数校验、RESTful 路由分组：上
Gin。但注意：它默认 panic 捕获机制会掩盖原始错误，开发期建议关掉gin.SetMode(gin.DebugMode) - 别混用：
net/http的http.ResponseWriter和 Gin 的*gin.Context类型不兼容，强行转换会 panic
goroutine 泄漏比内存泄漏更难发现？
是的。goroutine 不退出，栈内存持续占着，但 runtime.NumGoroutine() 又不报错，直到 OOM 或 CPU 暴涨才暴露。
- 典型泄漏场景：
for循环里起 goroutine 但没加超时或 channel 关闭控制 - 必加
context.WithTimeout或context.WithCancel，尤其调外部 HTTP 或 DB 时 - 用
pprof查：启动服务后访问http://localhost:6060/debug/pprof/goroutine?debug=2，看哪些 goroutine 卡在select或recv - 切忌用全局 channel 做“广播”，没消费者时发送方会永久阻塞
map 并发读写 panic 怎么快速定位？
fatal error: concurrent map read and map write 这类 panic 不会告诉你哪一行，只给 runtime traceback。靠猜不如靠配置。
立即学习“go语言免费学习笔记（深入）”；
- 开发期加编译标记：
go run -gcflags="-d=checkptr" main.go，能提前暴露部分不安全操作 - 更准的是开 race detector：
go run -race main.go，它会在第一次并发读写时立刻报错，并标出读/写两处代码行 - 修复方案不是加 mutex 就完事：高频读场景优先用
sync.Map；低频写+高频读可读写锁sync.RWMutex；纯配置数据考虑初始化后只读，用sync.Once构建
