在CentOS上跑Go应用，性能优化其实是个系统工程——从操作系统底层到编译器参数，再到代码层面的微雕，每个环节都可能成为瓶颈。下面就把这几条路线拆开来聊聊，希望能给你一些可落地的思路。
系统配置优化
先说操作系统层面。很多时候应用跑不快，不是Go的问题，而是Linux内核默认参数没调。
文件描述符限制：高并发场景下，Go可能会同时打开大量网络连接或文件，默认的1024远远不够。建议通过
ulimit -n 65535提高上限，必要时在/etc/security/limits.conf里永久设置。TCP参数调优：如果你的应用是网络密集型（比如HTTP服务），几个内核参数值得关注。比如增大
net.ipv4.tcp_max_syn_backlog（建议8192以上），以及扩大本地端口范围net.ipv4.ip_local_port_range="1024 65535"，避免端口耗尽。文件系统选择与挂载：优先使用XFS或ext4这类成熟高性能的文件系统。挂载时加上
noatime选项，可以避免每次读取文件时更新访问时间戳，减少磁盘I/O开销。内存与交换：交换空间（swap）要合理配置——太少容易OOM，太多会导致频繁换页影响性能。关键参数
vm.swappiness建议调低（比如10或更小），让系统尽量优先使用物理内存。
Go编译器选项
编译阶段其实能榨出不少水分，只是很多人忽略了。
二进制瘦身：线上部署时，调试符号和调试信息没必要带着跑。加上
-ldflags="-s -w"可以同时去掉符号表和DWARF信息，二进制体积能缩小30%~50%，加载和部署都会更快。go build -ldflags="-s -w" -o myapp编译器优化控制：如果你需要调试性能问题，可以用
-gcflags="-N -l"禁用内联和优化，方便分析。但正式环境一般不需要动，Go编译器默认开启的内联和逃逸分析已经做得很好了。
代码优化
这是最核心的部分，也是最能体现经验的地方。
并发模型：Go的goroutine轻量，但并非越多越好。每个goroutine至少占用几KB栈空间，大量创建反而会增加调度压力。推荐的实践是使用工作池（worker pool）模式，控制并发数。channel的设计也要注意避免阻塞和死锁。
内存分配与GC：Go的垃圾回收器一直在进化，但频繁的分配仍然会导致STW停顿。复用对象是有效手段——
sync.Pool是官方提供的对象池，能显著降低GC压力。另外，尽量预分配切片和map的容量（用make指定len/cap），减少扩容时的内存拷贝。数据结构与算法：选择合适的数据结构比微优化更关键。比如高频查找用map，有序遍历用slice加排序。遇到瓶颈时，别忘了用
go tool pprof做CPU和内存性能分析，定位热点代码比凭感觉优化靠谱得多。I/O处理：磁盘I/O往往是最大短板。能用内存缓存就不用磁盘，能用异步/非阻塞I/O就别同步等待。Go的
io.Reader和io.Writer接口非常灵活，搭配bufio可以大幅减少系统调用次数。
其他优化
有些优化看似老生常谈，但效果立竿见影。
硬件层面：如果预算允许，把机械硬盘换成SSD（特别是NVMe），磁盘随机读写性能提升一个数量级，这是最简单粗暴的方法。
网络调优：除了之前提到的内核参数，还可以调整TCP读写缓冲区大小（
net.core.rmem_max和net.core.wmem_max）。如果业务能接受，用CDN或反向袋里缓存静态内容，也能减少后端压力。监控与日志：别等出问题再排查。Prometheus配合Grafana搭建一套实时监控，能让你直观看到CPU、内存、GC、请求延迟等指标。日志方面，用标准库log的
SetOutput配合日志轮转，同时注意生产环境日志级别不要太低（比如Info或Error即可），避免大量写盘影响性能。
优化这件事，最终还得回到你的具体业务场景。上面这些方法可以作为起点，但真正见效的组合往往需要反复测试和调整。记住一个原则：先测后改，用数据说话。
