在 CentOS 环境里跑 Go 服务，内存占用过高通常不是单点问题：有的出在对象分配过多，有的出在 GC 节奏不合适，也有的其实是系统参数和部署方式拖了后腿。要把内存压到合理范围，同时尽量不牺牲吞吐，比较稳妥的做法是从代码、编译、运行时、系统配置到监控手段逐层排查。
下面按实际排障顺序整理一遍常用方法。看完后，你可以判断哪些优化适合直接落地，哪些需要结合业务负载和 CPU 余量再做取舍。
代码层先减分配，优先处理最容易放大的问题
如果应用本身存在频繁分配、重复拷贝或对象生命周期过长的问题，单靠调 GC 往往只能缓解，不能根治。
减少不必要的内存分配
高频路径上反复创建对象，会直接推高堆分配量，也会增加 GC 压力。对于可复用对象，sync.Pool 是比较常见的优化手段，尤其适合频繁创建和销毁的大对象场景。
大对象优先传指针
当函数之间传递体积较大的结构体时，值传递会带来额外拷贝成本。改用指针传递，通常能减少一次内存复制，对高调用频率的代码路径更有意义。
全局变量谨慎使用
全局变量不只是常驻内存的问题，更麻烦的是它容易拉长对象生命周期，让本该及时释放的数据持续存活。能收敛到局部作用域的，就尽量不要挂到全局。
编译阶段能做的瘦身和优化
有些内存和体积问题，可以在构建阶段先处理掉，成本低，收益也比较直接。
用 -ldflags="-s -w" 缩小二进制体积
这个参数会去掉符号表和调试信息，能让生成的二进制文件更小。原文将它归到“内存占用自然也小了”这一类收益里，实际落地时更适合作为部署体积优化手段一并采用：
-ldflags="-s -w"开启编译器优化选项
例如 -O2 或 -O3，可以让编译器参与更多代码层面的优化。它更偏向运行效率提升，但在一些场景下也能间接改善资源使用表现。
运行时调优，核心看 GOGC 和内存观测
Go 的运行时已经帮开发者处理了大量内存管理工作，但在 CentOS 上部署服务时，GC 触发节奏仍然值得结合业务特征做针对性调整。
调整 GOGC，在内存和 CPU 之间做取舍
GOGC 默认值是 100，表示堆内存增长到上次垃圾回收后的两倍时触发 GC。如果希望把内存控制得更紧一些，可以把它调小，例如：
export GOGC=50这样做的直接效果是 GC 会更早、更频繁地执行，堆空间通常更紧凑；代价则是 CPU 开销会上升。所以它不是越小越好，而是要看服务更怕内存吃紧，还是更怕 GC 抢 CPU。
用 runtime 包采样，而不是频繁手动 GC
runtime.GC() 可以手动触发垃圾回收，但不适合当成常规优化手段滥用。相比之下，更推荐通过 runtime.ReadMemStats 获取内存统计信息，再根据数据决定是否需要继续调参数或改代码。
系统层配置，避免应用被 CentOS 环境拖慢
应用写得没问题，系统参数也可能让内存表现失真，尤其是高并发连接和 swap 参与之后。
先把文件描述符上限提到可用范围
高并发服务如果文件描述符限制太低，问题往往先表现为连接异常，但资源占用也会随之变得混乱。常见做法是先提高上限：
ulimit -n 65535这不是直接降低内存的方法，但它能减少并发上来以后因为系统限制触发的连锁问题。
控制 vm.swappiness，尽量别让 Go 进程掉进 swap
vm.swappiness 用来控制内核使用交换空间的倾向。如果机器内存够用，通常可以设置为 0 或 1，尽量避免应用运行时被换出到 swap。对延迟敏感服务来说，这一步往往比表面上的“省内存”更重要。
监控和分析工具，决定优化是不是做对了
不看数据就调参数，很容易把问题从“内存高”改成“CPU 高”或者“延迟抖动”。监控工具的作用，就是把热点分配、泄漏和异常占用区分开。
用 pprof 查 heap profile
Go 自带的 pprof 是定位内存问题的核心工具，适合查看堆内存画像、热点分配位置以及是否存在泄漏迹象：
go tool pprof http://localhost:6060/debug/pprof/heap如果你已经怀疑某个模块分配异常，优先看这里，通常比盲调 GOGC 更有效。
结合 top、htop 看系统视角的数据
系统级工具虽然不告诉你具体是哪一行代码导致分配增加，但看 RES 和 VIRT，基本能先判断内存使用是否异常，以及问题更像是进程真实占用上升，还是虚拟内存映射扩大。
容器部署时，直接给资源边界
如果服务跑在 Docker 这类容器环境里，资源限制本身就是内存治理的一部分。
用内存限制减少环境差异
容器可以对内存、CPU 做硬限制，例如：
--memory=512m这样做的价值在于，应用不会因为换了一台宿主机就无上限地吃资源，也更方便复现和比较不同参数下的表现。
一个典型示例：用 sync.Pool 降低大对象重复创建成本
下面这段示例代码展示了 sync.Pool 的基本用法。场景很典型：如果某类大对象会被频繁创建和销毁，把它放进池里复用，通常能明显减轻 GC 压力。
package main
import (
"fmt"
"sync"
)
type BigStruct struct {
data [1024]byte
}
var pool = sync.Pool{
New: func() interface{} {
return &BigStruct{}
},
}
func main() {
bigStruct := pool.Get().(*BigStruct)
defer pool.Put(bigStruct)
// 使用bigStruct
fmt.Println(bigStruct.data)
}这类优化最适合对象数量多、复用价值高、生命周期短而稳定的场景。如果对象本身不常创建，或者池化之后增加了维护复杂度，就需要重新评估收益。
实际落地时，建议按“先观测、再收敛、后调参”的顺序推进
整体来看，CentOS 下的 Go 内存优化至少要覆盖五个层面：代码分配行为、编译构建选项、运行时 GC 参数、系统配置，以及容器资源边界。真正有效的做法，通常不是只改一个参数，而是先通过 pprof、top、htop 找出问题位置，再决定是改代码、调 GOGC，还是处理系统和部署环境。
如果你的目标是把内存稳住，又不明显影响性能，这套顺序通常比一上来就“压 GC、限容器、调内核”更可靠。
