<p>正确触发方式是 on: push: tags: ['v']，仅当推送符合 v 格式的标签（如 v1.2.0）时触发构建；需分 Linux/Windows 独立 job，设 CGO_ENABLED=0 并显式上传、下载 artifact 后发布。</p>
触发条件必须用 tag，不是 push 主分支
GitHub Actions 跨平台构建二进制，最常见失败原因是误配 on: push —— 这会导致每次提交都跑构建，但 Windows/Linux 构建耗时长、资源占用高，且多数场景下你只希望「正式发版时」才生成安装包或可执行文件。
正确做法是监听 tags 事件，且约定 tag 格式为 v*（如 v1.2.0）：
-
on:下写push:→tags: ['v*']，不是branches: ['main'] - tag 必须本地打完并
git push origin <tag>推上去，仅git tag v1.2.0不触发工作流 - GitHub Releases 页面的 “Draft a new release” 按钮本质就是打 tag + 传描述，它本身不运行构建
Linux 和 Windows 构建必须分 jobs，不能合在一个 job 里
GitHub 提供的 runner 是单 OS 环境：ubuntu-latest 只能 build Linux 二进制，windows-latest 只能 build Windows（.exe），想同时产出两者，就得拆成两个独立 job，并用 needs: 或 if: always() 控制发布逻辑。
典型结构：
- job
build-linux：runs-onubuntu-latest，设GOOS=linux，输出dist/app-linux-amd64 - job
build-win：runs-onwindows-latest，设GOOS=windows，输出dist/app-windows-amd64.exe - job
release：runs-onubuntu-latest，用softprops/action-gh-release@v1合并上传两个产物
别试图在 Linux job 里用 GOOS=windows 交叉编译出 .exe 再直接上传——Windows 二进制在 Linux 上无法验证签名、无法测试运行、且部分项目（如含资源绑定或 manifest）会失败。
CGO_ENABLED=0 是跨平台静态链接的前提
Go 默认启用 CGO，一旦依赖 libc 或 Windows API，交叉编译出的二进制在目标平台大概率报错：cannot execute binary file: Exec format error（架构错）或 failed to load DLL（缺运行时）。
解决方法统一加环境变量：
- Linux 构建：加
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 - Windows 构建：加
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 - 额外建议：加上
-ldflags="-s -w"剥离调试信息，体积减少 30%~50%
如果项目确实要用 CGO（比如调用 SQLite C API），那 Windows job 必须用 windows-latest + 安装 MinGW 工具链，Linux job 则需手动装 gcc-mingw-w64，复杂度陡增，不推荐初学者走这条路。
release job 上传前必须用 actions/download-artifact 拉取产物
每个 job 运行在隔离环境，build-linux 生成的文件不会自动出现在 build-win 的机器上，更不会进 release job。必须显式声明 artifact 并下载：
- build-linux 步骤末尾加：
- uses: actions/upload-artifact@v4，with: name: linux-bin, path: dist/app-linux-amd64 - build-win 步骤末尾加：
- uses: actions/upload-artifact@v4，with: name: win-bin, path: dist/app-windows-amd64.exe - release job 里先用
actions/download-artifact@v4把两个 artifact 拉下来，再传给softprops/action-gh-release
漏掉 download 步骤，release job 里看到的就是空目录，最终 Release 页面什么也传不上——这个坑特别隐蔽，日志里还不报错，只会显示 “0 files uploaded”。
