go调用系统命令应使用os/exec.command拆分参数，需shell特性时用sh -c并确保输入可控；读写/proc或/sys用os.readfile/writefile并处理换行和权限；监听文件系统用fsnotify并手动递归添加路径、位运算判断事件；95%系统操作无需cgo。
Go 怎么调用系统命令执行 shell 操作
直接用 os/exec 包的 exec.Command，别自己拼字符串再传给 sh -c——后者容易被注入、难调试、跨平台行为不一致。
常见错误是把整个命令行当一个字符串传给 exec.Command，比如 exec.Command("ls -la /tmp")，这会失败，因为 Go 会把整个字符串当程序名找，找不到就报 "exec: \"ls -la /tmp\": executable file not found"。
- 正确写法：按参数拆开，
exec.Command("ls", "-la", "/tmp") - 需要 shell 特性（管道、重定向、通配符）？用
exec.Command("sh", "-c", "ls *.go | head -n 1")，但确保输入可控 - 记得调用
cmd.Output()或cmd.Run()，否则命令根本不执行 - Windows 下注意：内置命令如
dir要用cmd而非sh，exec.Command("cmd", "/c", "dir")
Go 如何安全读写 /proc 或 /sys 文件
Go 没有专用系统接口封装，靠 os.ReadFile / os.WriteFile 就够用，但得处理权限、竞态和格式细节。
比如读 /proc/sys/net/ipv4/ip_forward 得自己 trim 换行符，写之前得确认目标文件可写且接受纯数字字符串；直接 WriteFile 写 "1\n" 可能失败，有些 sysctl 接口只认 "1"（无换行）。
- 读取后用
strings.TrimSpace去掉\n和空格，别直接== "1" - 写入前检查
os.IsPermission(err)，避免静默失败 -
/proc下多数文件是只读的，/sys下部分节点只支持单次写入（如触发设备重扫），重复写会报invalid argument - 不要用
ioutil（已弃用），统一用os.ReadFile
Go 怎么监听 inotify 事件做文件系统监控
标准库不提供 inotify 封装，必须用第三方包，fsnotify 是事实标准，但默认行为容易漏事件或卡死。
典型问题：监听目录时没递归，子目录新建文件收不到；或者没处理 Event.Op&fsnotify.Write 位，把写入当成创建；还有在 for range events 循环里不做超时控制，导致阻塞。
- 初始化用
watcher, _ := fsnotify.NewWatcher()，然后对每个要监的路径调watcher.Add(path)，它不自动递归 - 监听子目录需手动遍历
filepath.WalkDir并逐个Add，或改用golang.org/x/exp/inotify（实验性，更底层） - 判断事件类型别写
if e.Op == fsnotify.Write，要用位与：if e.Op&fsnotify.Write != 0 - 务必启动 goroutine 读
watcher.Events，主逻辑别卡在 for-range 上；同时别忽略watcher.Errors通道
Go 系统编程里 CGO 是不是必须开
95% 的系统操作不需要 CGO，开了反而限制部署（静态编译失效、musl 兼容问题、交叉编译麻烦）。只有三类情况绕不开：
- 调用未被 Go 标准库封装的 syscall，比如
membarrier、pidfd_open这类较新的 Linux API - 对接 C 库（如 libudev、libbpf），这时必须开
// #include <xxx.h></xxx.h>+import "C" - 需要精确控制内存布局或指针运算（极少见，比如写内核模块 loader 工具）
开 CGO 后 CGO_ENABLED=0 go build 会失败，Docker 多阶段构建里容易踩坑；另外 os/user.Lookup* 在 CGO 关闭时用纯 Go 实现，但可能不兼容某些 LDAP/NIS 配置——这不是 bug，是设计取舍。
真正难的从来不是“怎么开 CGO”，而是想清楚：这个功能是不是非 C 不可，以及你愿不愿意为它放弃静态二进制和跨平台简易性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
