Go语言适合编写CI/CD工具，需注意：用os/exec时设Stdout/Stderr、用context控制超时、正确处理ExitError；交叉编译须用go build并正确设置GOOS/GOARCH；embed仅编译期生效，热更新需外置文件；校验完整性必须用哈希而非文件大小；状态清理与可重试设计至关重要。
Go 语言本身不直接提供 CI/CD 能力，但它极适合编写轻量、可靠、跨平台的构建与部署工具——关键在于用对地方、避开常见陷阱。
用 os/exec 安全调用 shell 命令时如何避免阻塞和错误吞没
很多自动化脚本直接用 exec.Command("sh", "-c", cmd).Run()，但实际运行中容易卡死、超时无感知、错误输出被丢弃。
- 始终设置
cmd.Stdout和cmd.Stderr（哪怕指向io.Discard），否则管道缓冲区满会导致子进程挂起 - 用
cmd.Start()+cmd.Wait()配合time.AfterFunc或context.WithTimeout实现可控超时 - 不要忽略
err：即使命令返回非零码，Run()也会返回*exec.ExitError，需用errors.Is(err, exec.ErrExit)判断
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
cmd := exec.CommandContext(ctx, "git", "clone", url, dir)
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
if err := cmd.Run(); err != nil {
if ctx.Err() == context.DeadlineExceeded {
log.Fatal("git clone timeout")
}
log.Fatal("git clone failed:", err)
}
交叉编译部署二进制时为何 GOOS/GOARCH 不生效
本地开发环境设了 GOOS=linux 却仍生成 macOS 二进制，通常是因为构建命令未在 clean 环境下执行，或误用了 go run（它不支持交叉编译）。
-
go build才支持交叉编译，go run总是编译并运行当前平台版本 - 环境变量必须在
go build命令前导出，或用GOOS=linux GOARCH=amd64 go build -o myapp .形式 - 若项目含 cgo，交叉编译需对应平台的 C 工具链；禁用 cgo 可绕过：
CGO_ENABLED=0 GOOS=linux go build
用 embed 内嵌模板或配置文件时如何热更新失效
//go:embed 是编译期行为，内嵌内容固化进二进制，运行时无法修改。有人误以为能“动态加载” embedded 文件，结果改了 config.yaml 却发现程序始终读旧值。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
立即学习“go语言免费学习笔记（深入）”；
-
embed.FS读取的是打包时快照，不是运行时文件系统路径 - 需要热更新？把配置文件放在外部路径（如
/etc/myapp/config.yaml），仅用embed提供默认 fallback - 模板同理：用
template.ParseFS(embeddedFS, "templates/*.tmpl")加载内嵌模板，但生产环境建议优先从磁盘加载，失败再 fallback 到 embed
部署阶段验证二进制完整性为何不能只比对文件大小
发布流程中常有人用 os.Stat().Size 校验上传是否完整，但网络传输或磁盘写入异常可能导致文件截断却大小一致（尤其 ext4 默认启用 delayed allocation）。
- 必须用哈希校验：
sha256sum或 Go 的crypto/sha256 - 构建时生成 checksum 文件：
sha256sum myapp > myapp.sha256，部署端下载后执行sha256sum -c myapp.sha256 - 若用 Go 自动校验，注意打开文件后立即
defer f.Close()，避免句柄泄漏影响后续部署步骤
真正难的不是写个 deploy.go，而是让每个环节的失败都可定位、可重试、不残留状态——比如 git clone 失败后临时目录没清理，下次执行就因权限或冲突报错。Go 的简洁性容易让人低估状态管理的复杂度。
