在 CentOS 上打包 Go 应用，难点通常不在命令本身，而在于每一步到底解决什么问题：是先用系统仓库装 Go，还是手动装指定版本；是直接 go build，还是顺手做压缩和服务化。下面按实际部署顺序梳理一遍，你可以据此判断自己只需要基础构建，还是要进一步处理体积、启动方式和跨环境兼容性。
先把 Go 运行环境装好
打包之前，首先要确保 CentOS 上已经安装好 Go。最省事的方式是直接用 yum：
sudo yum install golang如果你更在意版本可控，或者需要指定较新的版本，也可以手动下载安装包。原文示例使用的是 1.18.1：
wget https://golang.org/dl/go1.18.1.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.18.1.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin这里的 go1.18.1 需要替换成你实际要用的版本号。安装完成后，可以立即检查是否生效：
go version只要能正常输出版本信息，就说明 Go 已经可用。
配置 GOROOT、GOPATH 和 PATH
在 CentOS 上构建 Go 项目前，环境变量最好一次配清楚。文中提到的两个核心变量分别是：
GOROOT：Go 的安装目录GOPATH：项目代码和相关工作目录
常见配置如下：
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin如果不想每次登录都重新设置，建议把这几行写入 ~/.bashrc 或 ~/.bash_profile。这样后续构建、安装工具和执行命令时，环境会稳定得多。
编写应用并生成可执行文件
代码可以放在 $GOPATH/src/myapp 目录下，按自己的业务逻辑完成开发。准备好之后，进入项目目录执行构建：
go build -o myapp命令执行完成后，当前目录会生成一个名为 myapp 的可执行文件。按照原文说明，这种默认构建结果通常是动态链接；如果目标机器依赖库完整，直接分发使用通常没有问题。
需要分发时，可以再做一次体积压缩
如果你的目标是把二进制文件发到其他服务器，或者需要通过网络传输，压缩可执行文件会更实用。这里可以使用 upx：
sudo yum install upx
upx --best myappupx --best myapp 会对生成的二进制做进一步压缩，通常能明显减小文件大小。对于发布包、临时分发包，或者需要频繁传输产物的场景，这一步很常见。
要长期运行时，再补一个启动脚本
如果这个 Go 应用不是手工跑一次就结束，而是准备作为服务常驻运行，那么可以补一个启动脚本。原文给出的示例如下：
#!/bin/bash
# myapp.service
# Start and stop script for the myapp application.
case "$1" in
start)
echo "Starting myapp"
/path/to/myapp &
;;
stop)
echo "Stopping myapp"
pkill myapp
;;
*)
echo "Usage: /etc/init.d/myapp {start|stop}"
exit 1
;;
esac
exit 0将它保存为 /etc/init.d/myapp 后，再赋予执行权限：
sudo chmod +x /etc/init.d/myapp后续就可以通过以下命令控制服务：
service myapp start
service myapp stop这种方式适合需要统一启动、停止入口的传统部署流程。
上线前测试，以及跨环境部署的两个选择
在真正打包发布前，最好先在开发环境完整跑一遍测试。这个步骤看起来普通，但往往决定了后面排查问题的成本，尤其是服务化之后，环境差异常常会把问题放大。
原文还补充了一个很关键的判断：以上流程在 CentOS 7 和 CentOS 8 上都能直接使用，其他版本可能需要微调。如果你的应用要部署到不同环境，最好考虑更稳定的交付方式。
一种常见做法是静态编译：
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w'这样可以尽量减少对目标环境依赖库的要求。另一种思路则是直接使用 Docker，把运行环境一起封装进去，进一步降低部署时的兼容性问题。
如果只是同版本 CentOS 机器之间分发，直接构建加可选压缩通常已经够用；如果涉及多台机器、不同环境甚至不同镜像基线，静态编译或容器化会更稳妥。
