os/exec 是唯一正解，因需精确控制超时、捕获退出码语义、避免shell管道错误；应读 /proc 文件而非解析命令输出；结果需结构化输出或HTTP暴露；systemd下须用绝对路径并显式设PATH。
巡检脚本该用 os/exec 还是直接调系统命令？
Go 写巡检脚本，核心不是“能不能跑命令”，而是“要不要自己解析输出”。os/exec 是唯一正解，硬编码 sh -c 或拼接字符串执行会丢失错误上下文、无法控制超时、难以捕获非零退出码的语义。
常见错误：用 exec.Command("bash", "-c", "df -h | grep '/$'") —— 一旦 grep 没匹配到，整个命令返回 1，但你误以为是 df 失败了。
- 始终用
exec.Command分开调用主命令，管道逻辑在 Go 里用io.Pipe或分步读取实现 - 必须设置
cmd.Stdout和cmd.Stderr为bytes.Buffer，否则输出丢失 - 调用
cmd.Run()后，检查err是否为*exec.ExitError，再看ExitCode()判断是命令失败还是业务不满足
内存/CPU/磁盘指标怎么取才可靠？
别信 top、free 的默认输出 —— 它们带单位、有表头、格式随 locale 变化，解析极易崩。Linux 下应直接读 /proc 文件，稳定、无依赖、零解析成本。
典型场景：查剩余内存不能看 free -h 的 “Available”，而要看 /proc/meminfo 的 MemAvailable: 行（单位 kB）；查磁盘使用率别用 df -P，改读 /proc/mounts + statfs 系统调用（或 golang.org/x/sys/unix.Statfs）。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
/proc/loadavg第一个字段是 1 分钟平均负载，直接strings.Fields()取就行 -
/proc/diskstats解析需跳过前 3 列（major/minor/name），第 4 列是读完成次数，第 8 列是写完成次数 - 避免轮询
/proc/stat计算 CPU 使用率——采样间隔短于 100ms 误差极大，且需两次读取做差值
如何让巡检结果可落地，而不是只打印日志？
巡检脚本的价值不在“跑完”，而在“能触发动作”。硬编码 log.Printf 是最常见浪费——没人盯终端，日志也不聚合。
关键取舍：轻量级场景用 os.WriteFile("health.json", data, 0644) 输出结构化结果，配合外部监控轮询；中等规模加个 HTTP handler（http.HandleFunc("/health", ...)），让 Prometheus 抓取；千万别内置 SMTP 发邮件——认证、限流、退信处理全是坑。
- 每个检查项返回
struct{ OK bool; Msg string; Value float64 }，统一序列化为 JSON - 对磁盘路径、端口、进程名等输入参数，必须校验是否存在、是否可访问，否则
os.Stat或net.DialTimeoutpanic 会中断整个巡检 - 超时必须全局可控：
context.WithTimeout包裹所有exec.Command和网络操作，单个检查超过 5 秒就放弃
为什么本地跑通了，放到 systemd 里就失败？
因为 systemd service 默认没加载用户环境变量，PATH 极简（通常只有 /usr/bin:/bin），且工作目录是根目录。巡检脚本里写的 ps aux | grep nginx 在 shell 里能跑，在 systemd 里大概率找不到 ps 或 grep。
错误现象：exec: "ps": executable file not found in $PATH 或 fork/exec /bin/sh: no such file or directory（后者说明连 /bin/sh 都不在 PATH 里）。
- 所有命令用绝对路径：
/usr/bin/ps、/bin/grep、/usr/bin/systemctl - service 文件里显式设置
Environment="PATH=/usr/local/bin:/usr/bin:/bin" - 不要依赖当前目录：
os.Getwd()在 systemd 下常返回/，配置文件路径必须写绝对路径或用os.Executable()推导
真正麻烦的是权限问题——比如检查 systemctl is-active docker，systemd user session 和 system session 隔离，脚本得跑在 system scope 下才能查服务状态。这点容易被忽略，直到线上巡检永远报 “inactive”。
