给 Go 应用打包后，很多人会卡在“怎么证明这个二进制确实是我发布的”这一步。对于 CentOS 环境，一个常见做法就是使用 GPG 为可执行文件生成独立签名；本文按“编译、签名、分发、验证”四个环节重排流程，读完你可以直接照着执行，也能判断哪些文件该发给用户、哪些内容必须自己保管。
先准备好 Go 构建产物
签名对象不是源码，而是已经编译完成的可执行文件。因此第一步仍然是确认 CentOS 机器上已经安装好 Golang。
如果本机还没有安装，可以从官方页面下载对应版本：
完成安装后，先把应用编译出来。例如：
go build -o myapp myapp.go这条命令会生成一个名为 myapp 的可执行文件。后续的 GPG 签名，针对的就是这个输出文件。
在 CentOS 上安装 GPG
Go 负责构建程序，真正执行签名的是 gpg（GNU Privacy Guard）。如果系统里还没有这个工具，可以直接安装：
sudo yum install gpg安装完成后，就具备了生成密钥、创建签名和验证签名的基础能力。对发布场景来说，GPG 的价值在于它能把“文件内容”和“发布者身份”绑定起来，用户拿到你的公钥后，就能独立确认下载到的文件是否被篡改。
先生成一对 GPG 密钥
正式签名前，需要先准备密钥对。执行下面这条命令：
gpg --full-generate-key按照命令行提示完成配置后，系统会生成：
- 私钥：用于签名，必须妥善保管；
- 公钥：用于分发给用户，供对方验证签名。
这里最重要的判断标准很简单：私钥只留在签名方手里，公钥才是可以对外发送的文件。原文里提到生成密钥时会关联邮箱信息，这通常用于标识密钥身份，但下面的签名命令本身并不需要额外把邮箱写进命令行。
为 Go 可执行文件生成签名
密钥准备好之后，就可以给编译好的程序生成一个独立签名文件：
gpg --output myapp.sig --detach-sig myapp这条命令的结果是输出一个 myapp.sig 文件，其中：
myapp是待签名的可执行文件；myapp.sig是生成后的签名文件；--detach-sig表示生成“分离签名”，也就是签名文件与原始程序分开保存。
这种分离签名方式很适合软件分发：你可以同时发布程序本体和签名文件，而不需要改动二进制本身。
发布时要一起提供哪些文件，用户如何验签
到这一步，发布方通常需要准备两类可交付物：
- 应用程序本体，例如
myapp； - 对应签名文件，例如
myapp.sig。
除此之外，用户还需要拿到你的公钥，例如 mykey.pub。在用户侧，先导入公钥：
gpg --import mykey.pub然后执行验签：
gpg --verify myapp.sig myapp如果签名有效，gpg 会返回确认信息，说明当前的 myapp 与签名匹配，并且该签名可由已导入的公钥验证通过。对最终用户来说，这一步的意义在于确认下载文件没有被替换或修改。
这套流程里最容易混淆的几个点
签名对象是编译产物，不是源码
必须先执行 go build，再对生成的可执行文件签名。否则用户验证的就不是最终发布件。
私钥签名，公钥验证
签名时使用私钥，用户验证时导入公钥。这是整个机制成立的前提，不能把私钥随程序一起分发。
签名文件和程序文件是分开的
gpg --output myapp.sig --detach-sig myapp 生成的是独立的 .sig 文件，发布时不要漏传。
原文里的邮箱提示属于说明信息
原文提到把 your@email.com 换成生成密钥时使用的邮箱，但实际给出的签名命令里并没有邮箱参数。这里更准确的理解是：邮箱可能出现在密钥身份信息中，但不是这条示例命令的必填项。
小结
在 CentOS 上为 Go 应用添加签名，核心就是四步：先用 go build 生成可执行文件，再安装并使用 gpg 生成密钥，随后输出分离签名文件，最后让用户导入公钥并执行验签。只要把“私钥不外发、签名跟随发布、用户按公钥验证”这几个原则理顺，这套流程就可以直接纳入你的发布步骤里。
