Go项目部署必须先用go build生成静态二进制文件，而非直接运行源码；交叉编译需指定GOOS和GOARCH，配置应通过flag与YAML分离管理，exec.Command须安全传参，避免shell注入。
go build 生成的二进制不是脚本，但可以当脚本用
Go 没有传统意义的“解释型脚本”机制（比如 #!/usr/bin/env go 不被系统支持），所以你写的 main.go 必须先编译成可执行文件才能运行。这不是缺陷，而是设计选择：它强制你面对构建、依赖、平台目标等真实部署问题。
常见错误是直接双击 main.go 或试图用 go run main.go 在生产环境反复执行——这会每次重新编译，浪费资源且无法保证版本一致性。
-
go build -o deploy ./cmd/deploy生成静态二进制，复制即用，不依赖 Go 环境 - 若需快速调试，
go run main.go可以，但上线前必须切回go build - 交叉编译时注意
GOOS和GOARCH，例如部署到 ARM64 服务器要设GOOS=linux GOARCH=arm64 - 避免在
main()里写大量逻辑；把核心动作拆成独立函数，方便单元测试
用 os/exec 安全调用 Shell 命令，别拼字符串
很多 Go 脚本本质是封装 Shell 操作（如 git pull、systemctl restart），但直接用 exec.Command("sh", "-c", "cd /app && "+cmd) 极易引发 shell 注入或路径空格崩溃。
正确做法是让 exec.Command 接收参数列表，由操作系统原生解析：
立即学习“go语言免费学习笔记（深入）”；
cmd := exec.Command("sh", "-c", "cd $1 && git pull", "sh", "/srv/myapp")
output, err := cmd.CombinedOutput()
这里 "sh" 是占位符（对应 <p>这里 <code>"sh" 是占位符（对应 $0），"/srv/myapp" 成为 $1，不会被 shell 展开。
"/srv/myapp" 成为 
- 永远用
cmd.CombinedOutput()，而非分开读Stdout/Stderr，否则日志顺序错乱 - 检查
err != nil后，务必打印string(output)，很多失败（如权限拒绝、目录不存在）只在输出里体现 - 需要交互式输入（如 sudo 密码）时，显式赋值
cmd.Stdin = os.Stdin，但生产环境应禁用密码，改用免密 key
替代 Shell 的关键能力：script 库能简化什么？
如果你频繁做 cat file | grep error | wc -l 这类操作，github.com/bitfield/script 确实能减少样板代码，但它不是标准库，引入后需维护依赖。
它适合快速原型或运维一次性任务，不适合长期维护的部署工具：
-
script.File("access.log").Match("500").CountLines()比手写os.Open+bufio.Scanner简洁，但性能略低（逐行读取+正则匹配） - 所有链式调用最终都转为
exec.Command或内存处理，没绕过系统调用开销 - 跨平台行为一致（比如
.CountLines()在 Windows/Linux 都按\n计数），而原生wc -l在 CRLF 文件上可能出错 - 不推荐在高并发场景（如每秒处理千个日志文件）中使用，优先考虑标准库流式处理
配置管理别硬编码，用 flag + YAML
Shell 脚本靠 ENV=prod ./deploy.sh 传参，Go 脚本也该如此，但更进一步：把环境差异抽成配置文件。
不要写 if env == "prod" { addr = "10.0.2.100" }，而是：
- 定义
config.yaml，含staging和prod两个 section - 用
gopkg.in/yaml.v3解析，通过-env=prod参数选节 - 命令行参数用
flag.String("env", "dev", "target environment")，比环境变量更明确、可文档化 - 敏感字段（如密码）从文件或 Vault 加载，绝不写死在 YAML 里
真正容易被忽略的是：配置加载失败时，脚本应立刻退出并打印清晰错误（比如 “missing required field database.url in config.yaml”），而不是静默用默认值导致后续操作失败。
