Go协程是自动化运维批量任务落地的关键，必须用带缓冲channel（如sem := make(chan struct{}, 20)）限流，避免无限启动goroutine导致系统崩溃。
Go 的协程不是“锦上添花”，而是自动化运维中批量任务能否真正落地的关键——不用它，os/exec 调用几十台机器就会卡死；用了它，goroutine + channel 控制并发数，500 台服务器的健康检查 3 秒内完成。
为什么 go 关键字不能乱用？
新手常把每个 exec.Command 都包一层 go，结果瞬间起几千个 goroutine，系统直接被 fork 崩溃。这不是 Go 并发模型的问题，是没理解调度边界。
- 必须用
semaphore或带缓冲的channel限流，比如控制最多同时执行 20 个 SSH 命令：sem := make(chan struct{}, 20) - 每个 goroutine 执行前先
sem ，结束时 <code><-sem，否则会泄露 -
time.Sleep在 goroutine 内部不能替代限流——它只暂停当前协程，不释放信号量
exec.Command 在并发场景下的坑
exec.Command 本身不是线程安全的，但更关键的是它的底层依赖 os.StartProcess，在高并发下容易触发系统 RLIMIT_NPROC 限制，报错 fork: resource temporarily unavailable。
- 避免在循环里反复调用
exec.Command后直接.Run()—— 改用.Start()+.Wait()，并配合context.WithTimeout - SSH 场景优先用
golang.org/x/crypto/ssh替代 shell 调用，减少进程创建开销 - 如果必须用
exec.Command，记得重定向StdoutPipe和StderrPipe，否则缓冲区满会导致阻塞
如何让 goroutine 真正可控地退出？
运维脚本常驻运行（比如轮询监控），但一不留神就变成 goroutine 泄漏黑洞——旧任务没结束，新任务又启动，内存持续上涨。
立即学习“go语言免费学习笔记（深入）”；
- 所有长期运行的 goroutine 必须接收
context.Context，并在select中监听ctx.Done() - 不要用
for {}死循环，改用for ctx.Err() == nil或显式判断ctx.Err() != context.Canceled - 用
sync.WaitGroup等待子 goroutine 结束再退出主函数，否则main返回后 goroutine 还在跑
协程的威力不在数量，而在可控的并发粒度。一个没加限流的 go func() { ... }()，和一个带超时、带信号量、带上下文取消的 go runTask(ctx, sem)，实际稳定性差十倍不止。写完记得压测 ps -eLf | grep your-binary | wc -l，确认 goroutine 数量符合预期。
