Go无法关闭垃圾回收，但可通过减少逃逸、复用buffer、设超时等优化GC压力；go mod已取代GOPATH，新项目直接go mod init即可；net/http足够实现RESTful服务，应避免过早引入gorilla/mux。
go 环境本身不提供“关闭垃圾回收”的编译选项，所谓“无垃圾回收干扰”是误解。Go 的 GC 是运行时核心机制，无法在编译时禁用或剥离；但你可以通过控制内存分配模式、减少临时对象、避免逃逸等方式显著降低 GC 压力——这才是实际可操作的优化路径。
go version 和 GOPATH 已不是必设项
Go 1.11+ 默认启用模块（go mod），不再强制依赖 GOPATH。安装后只需验证：go version 输出带 go1.21 或更高版本即可，无需手动配置 GOPATH。
常见误操作：在新项目里还执行 export GOPATH=... 并把代码放进去——这反而可能触发旧式构建逻辑，导致 go mod 行为异常。
- 新建项目直接
mkdir myapi && cd myapi - 运行
go mod init myapi初始化模块 -
main.go里用标准库net/http起服务即可，无需任何第三方依赖
用 net/http 写极简 RESTful handler，别碰 gorilla/mux 除非真需要路径参数
学生项目或 MVP 阶段，net/http 完全够用。硬上 gorilla/mux 反而增加心智负担和二进制体积。
立即学习“go语言免费学习笔记（深入）”；
关键点在于：用 r.Method 分发，而不是靠 r.URL.Path 字符串匹配——后者无法支持 /users/123 这类动态路径，且易出错。
- GET 请求取参用
r.URL.Query().Get("id") - POST/PUT 解析 JSON 必须用
json.NewDecoder(r.Body).Decode(&v)，别用ioutil.ReadAll+json.Unmarshal（已弃用） - 每个 handler 开头必须写
w.Header().Set("Content-Type", "application/json; charset=utf-8")，否则前端可能解析失败 - 错误统一走
http.Error(w, msg, status)，不要panic或裸 print
GC 不可关，但能压：避免逃逸、复用 buffer、慎用闭包
Go 编译器会自动判断变量是否逃逸到堆。高频分配小对象（如 struct、map、[]byte）是 GC 主要压力源。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型逃逸场景：
- 函数内 new 一个 struct 并返回指针 → 逃逸到堆
- 把局部 slice 传给
fmt.Sprintf→ 底层分配新 buffer - handler 里定义匿名函数并捕获 request 参数 → 整个
*http.Request可能逃逸
实操建议：
- 用
sync.Pool复用 JSON 解码用的bytes.Buffer或结构体实例（适合高并发读写） - 结构体字段尽量用值类型（
int,string），避免嵌套指针 - 路径参数提取逻辑别封装成闭包，直接写在 handler 里更可控
- 用
go tool compile -gcflags="-m" main.go查看逃逸分析结果，重点关注 “moved to heap” 提示
启动 server 时必须设 ReadTimeout / WriteTimeout
没设超时的 http.Server 在连接异常（如客户端断开、网络卡顿）时会长期挂住 goroutine，积累大量 idle connection，最终拖慢 GC 周期甚至 OOM。
正确写法：
srv := &http.Server{
Addr: ":8080",
Handler: router,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
}注意：ReadTimeout 从连接建立开始计时，WriteTimeout 从响应头写入开始计时——两者都必须设，缺一不可。
另外，务必监听 os.Interrupt 和 syscall.SIGTERM 实现优雅退出，否则 kill -15 后连接不会真正关闭，GC 仍要扫描残留 goroutine。
真正难的不是让服务跑起来，而是让 runtime.ReadMemStats 里 NextGC 和 NumGC 在压测中保持平稳——这取决于你写的每一行分配逻辑，而不是选了哪个框架。
