把 Go 程序部署到 CentOS 时，很多“权限问题”表面上看起来都像一回事，实际却可能分别出在安装路径、可执行权限、文件归属、SELinux 策略甚至端口放行上。与其反复重试命令，不如按一条清晰的排查路径逐项确认，通常几分钟内就能判断问题落在哪一层。
为什么在 CentOS 打包 Go 应用时容易遇到权限拒绝
Golang 编译出的二进制文件本身通常没有复杂依赖，但在 CentOS 上真正出错的环节往往发生在“编译之后”：例如把程序复制到 /usr/local/bin/、调整执行权限、修改文件属主，或者首次运行时访问系统端口和安全策略。
也就是说，报错虽然常常只有一句“Permission denied”，背后对应的处理方式并不一样。下面这几类场景，基本覆盖了大多数常见问题。
先确认是否只是缺少管理员权限
如果报错出现在编译输出后的复制、安装阶段，最先要检查的就是当前操作是否需要更高权限。像 /usr/local/bin/ 这类系统目录，普通用户通常没有直接写入权限。
这种情况下，可以先用 sudo 重新执行相关命令：
sudo go build -o myapp
sudo cp myapp /usr/local/bin/如果加上 sudo 后问题立即消失，说明故障点主要在目标目录的写权限，而不是 Go 编译过程本身。
文件不能执行或移动时，检查 chmod 和 chown
可执行权限不足时用 chmod
有些情况下，二进制已经成功生成，但执行或移动时仍然报错。这时要看文件本身是否具备执行权限。
可以先补上可执行位，再继续移动到目标路径：
chmod +x myapp
sudo mv myapp /usr/local/bin/这一步适合处理“文件存在，但系统不允许执行”的场景。
需要调整文件归属时用 chown
如果问题出在文件所有者或所属组不合适，而你又希望后续由特定用户接管该文件，就需要修改属主属组。
例如把文件交给 root 用户和 root 组：
sudo chown root:root myapp这类操作常见于把程序放入系统目录、交由系统服务或管理员统一维护的场景。
权限都没问题仍报错时，重点看 SELinux
CentOS 默认启用 SELinux。很多时候，传统的 Unix 权限看起来都已经正确，但程序仍然无法执行、访问或被移动，原因就在于 SELinux 额外拦截了操作。
可以先尝试为文件设置合适的 SELinux 上下文：
sudo chcon -t bin_t myapp如果这样处理后程序恢复正常，说明问题并不在 chmod 或 chown，而是在安全上下文不匹配。
必要时可切到 Permissive 模式，但要谨慎
如果 SELinux 持续拦截，而你需要先验证问题是否确实由它引起，可以临时考虑改为 Permissive 模式。这个模式下 SELinux 不强制阻止操作，但仍会记录告警。
修改方式是编辑 /etc/selinux/config，把：
SELINUX=enforcing改为：
SELINUX=permissive然后重启系统。
这一步适合定位问题，不适合随意在生产环境长期使用，因为它会降低系统安全性。
程序要监听端口时，别漏掉防火墙放行
如果你的 Go 应用需要监听端口，例如 8080，即使文件权限和 SELinux 都已经处理完，外部仍可能无法访问服务。此时需要继续检查 CentOS 防火墙是否已放行对应端口。
可以使用以下命令开放 8080/tcp：
sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp
sudo firewall-cmd --reload这类问题常被误判为程序启动失败，实际上进程可能已经正常运行，只是请求被防火墙挡住了。
更高效的排查顺序建议
如果你不想把上面几种方法全试一遍，可以按下面的顺序判断：
- 先看是否写入了系统目录，若是，优先检查
sudo。 - 再看二进制是否具有执行权限，必要时执行
chmod +x。 - 如果涉及系统接管或用户切换，再确认
chown是否合理。 - 传统权限都没问题时，把重点转向 SELinux。
- 程序需要对外提供服务时，最后检查防火墙端口。
如果以上步骤都排查过仍然无法解决，下一步就不该继续“盲改权限”了，而是要结合具体报错信息做针对性分析。
