GitHub Actions 可用于 Go 项目 CI/CD，但自动化部署需谨慎：runner 无状态，须显式配置凭据与安全策略；Go 1.11+ 模块下无需手动设 GOPATH；构建应指定 GOOS/GOARCH 并用 -ldflags 减小体积；跨平台需禁用 CGO；二进制传输须用 secrets 存私钥，配合 scp-action 安全部署。
Go 项目用 GitHub Actions 做 CI/CD 是可行的，但直接“自动化部署”需要谨慎判断：GitHub Actions 默认运行在临时、无状态的 runner 上，无法直接 SSH 到生产服务器执行 git pull 或 systemctl restart；真要部署，必须显式配置凭据、目标环境和安全策略。
Go 测试与构建必须指定 GOPATH 和 GOBIN 吗？
不需要。Go 1.11+ 启用模块（go mod）后，GOPATH 对构建已非必需；GitHub Actions 的 Ubuntu runner 预装 Go，且默认工作目录就是仓库根（含 go.mod），直接运行 go test ./... 和 go build -o bin/app . 即可。
常见错误是误设 GOPATH 导致模块解析失败——尤其当 workflow 中用了 actions/setup-go 但又手动覆盖环境变量时。
- 用
actions/setup-go时，不额外设GOPATH，让其使用默认值（如/home/runner/go） - 构建二进制建议加
-ldflags="-s -w"减小体积 - 若项目含 cgo，需提前安装
build-essential或对应 C 工具链
go build 成功但二进制无法运行？检查 CGO 和目标平台
本地 macOS 编译的二进制不能直接丢到 Linux server 上跑。GitHub Actions 默认 runner 是 Linux x64，但如果你在 go build 里没约束 GOOS/GOARCH，而本地开发机是 macOS，就容易忽略跨平台问题。
立即学习“go语言免费学习笔记（深入）”；
CI 中应显式声明目标环境：
go build -o bin/app -ldflags="-s -w" -gcflags="all=-trimpath=/home/runner/work" -asmflags="all=-trimpath=/home/runner/work" .
如果要发布多平台版本（如 darwin/amd64），需用 matrix 策略，并注意：
-
CGO_ENABLED=0是跨平台静态编译的关键，否则会依赖 host libc - macOS runner 不支持
docker操作，Linux runner 才能推镜像或调用ssh - 交叉编译时，
GOOS=linux GOARCH=arm64 go build生成的文件，需确认目标机器架构匹配
如何安全地把二进制推到远程服务器？别硬编码密码
GitHub Actions 不允许明文写密码或私钥到 workflow YAML 里。正确做法是：
- 用
secrets.SSH_PRIVATE_KEY存 RSA 私钥（id_rsa内容，非文件路径） - 用
ssh-action或appleboy/scp-action传文件，而非自己写ssh命令拼接 - 目标服务器必须预先配置好 SSH 公钥认证，且用户有对应目录写权限（如
/opt/myapp）
示例关键片段：
- name: Deploy binary
uses: appleboy/scp-action@v0.1.7
with:
host: ${{ secrets.HOST }}
username: ${{ secrets.USERNAME }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
source: "bin/app"
target: "/opt/myapp/"之后再通过另一 step 调用 ssh 执行 sudo systemctl restart myapp ——但该命令需在目标服务器上配置免密码 sudo 权限，否则卡住。
真正难的不是写 workflow，而是厘清部署链路中每个环节的信任边界：GitHub runner 是否可信？目标服务器是否隔离？私钥泄露后能否快速轮换？这些比语法细节更影响落地稳定性。
