go是当前自动化运维工具链的事实标准语言，因其静态编译、无依赖部署及贴合运维的并发模型；默认关闭cgo可生成纯静态二进制适配alpine；exec.command需正确处理i/o、信号与超时；http.client需自定义配置连接复用与tls。
Go 不是“适合 DevOps 的又一种语言”，它是当前自动化运维工具链的事实标准实现语言——不是因为语法多优雅，而是因为静态编译、无依赖部署、并发模型贴合运维场景这三点，直接解决了脚本语言和 JVM 语言在真实生产环境里卡脖子的问题。
为什么 go build 编译出的二进制能直接扔进 Docker Alpine 镜像跑
因为 Go 默认生成的是静态链接可执行文件，不依赖 libc（除非你显式用了 cgo）。而大多数运维工具要塞进最小化镜像，最怕的就是动态链接失败或 glibc 版本冲突。
- 默认关闭
cgo：设环境变量CGO_ENABLED=0再go build，确保纯静态 - 如果必须用
cgo（比如调systemdAPI），就得用glibc镜像，或者交叉编译时指定CC=musl-gcc - Alpine 上运行报
no such file or directory？八成是忘了关cgo，系统找不到动态链接器
exec.Command 在容器里执行 shell 命令为啥常丢 stderr 或卡住
不是 Go 的问题，是没处理好子进程 I/O 管道和信号传递。运维脚本大量调 exec.Command 执行 curl、kubectl、ssh，但一上容器就表现异常。
- 别直接
cmd.Run()，用cmd.CombinedOutput()或分别StdoutPipe/StderrPipe拿流 - 务必设置
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}，否则容器里发SIGTERM时子进程收不到 - 超时控制不能只靠
context.WithTimeout，得配合cmd.Process.Kill()，否则僵尸进程堆积
Golang 的 http.Client 为什么比 Python requests 更适合写巡检服务
不是因为快，是因为连接复用可控、超时分层清晰、TLS 配置不黑盒——巡检服务天天轮询几十个 endpoint，连接泄漏或 TLS 握手卡死会直接拖垮整个检查周期。
立即学习“go语言免费学习笔记（深入）”；
- 别用默认
http.DefaultClient，自己建&http.Client{Timeout: 10 * time.Second} - 必须配
Transport：设置MaxIdleConns、MaxIdleConnsPerHost，不然短连接风暴打穿目标服务 - 自签名证书场景下，
tls.Config.InsecureSkipVerify要慎开；更安全的做法是把 CA 加进RootCAs
Go 在运维工具里的真正门槛不在语法，而在对进程生命周期、系统调用边界、资源释放时机的敏感度——写个 defer resp.Body.Close() 很容易，但漏掉一个 io.Copy 后的 CloseWrite，就可能让 SSH 连接挂住半天。
