os/exec调用shell命令卡住或无输出，因默认不继承stdout/stderr，需显式处理输出、加超时、注意shell特性（如|、>需sh-c）。
用 os/exec 调用 shell 命令时为什么总卡住或没输出？
Go 的 os/exec 默认不会自动继承父进程的 stdout 和 stderr，直接 cmd.Run() 可能导致命令看似“执行了”，但实际输出被丢弃、超时或阻塞（尤其遇到交互式命令或缓冲未刷新）。
- 始终显式处理输出：用
cmd.CombinedOutput()拿全部输出，或分别设置cmd.Stdout/cmd.Stderr为bytes.Buffer或os.Stdout - 避免无限制等待：给命令加超时，
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，再用exec.CommandContext(ctx, ...) - 注意 shell 特性：Go 不调用 shell 解释器（如
/bin/sh），所以管道|、重定向>、通配符*都不生效；真要这些，得显式调用sh -c "cmd | grep xxx"
用 github.com/spf13/cobra 写运维 CLI 工具时如何组织子命令和配置？
Cobra 是 DevOps 工具的事实标准，但新手常把所有逻辑堆在 Run 函数里，导致难测试、难复用、难维护。
- 每个子命令对应一个独立函数（如
deployCmd、rollbackCmd），只做参数解析和调度，核心逻辑抽到单独包（如pkg/deploy） - 配置优先级要明确：命令行 flag > 环境变量 > 默认值；用
pflag的Lookup判断是否由用户显式设置，避免环境变量覆盖用户意图 - 敏感信息（如 token、密钥）不要通过 flag 传，改用
--config /path/to/config.yaml或从~/.mytool/config.toml加载，并在initConfig()中校验文件权限（stat.Mode().Perm() & 0o077 != 0应报错）
用 golang.org/x/sys/unix 做系统级操作时哪些 syscall 容易出兼容性问题？
DevOps 工具常需绕过高级封装直调系统调用（比如查进程打开文件、设资源限制），但 unix 包跨平台行为差异大，Linux/macOS/FreeBSD 的常量名、参数顺序甚至语义都可能不同。
git摸鱼周报自动化
下载
生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。
-
unix.Sysctl在 macOS 上返回字符串，在 Linux 上需自己解析二进制 blob；查vm.swappiness这类 sysctl，先用runtime.GOOS == "linux"分支处理 -
unix.Setrlimit的Rlimit.Cur和Max在不同内核版本含义不同（如RLIMIT_NOFILE的Cur设太小会导致后续open()失败），建议只设Max，Cur保持原值 - 避免直接用
unix.Kill发信号——它不检查进程是否存在，容易误杀；改用unix.PtraceAttach+unix.Wait4组合确认目标存活后再操作
CI/CD 流水线里编译 Go 二进制为什么体积大、启动慢、依赖多？
运维工具部署到目标机器时，常因二进制含调试符号、动态链接 libc、或启用了 CGO 导致无法跨平台运行或启动延迟高。
立即学习“go语言免费学习笔记（深入）”；
- 编译前关掉 CGO：
CGO_ENABLED=0 go build -ldflags="-s -w" -o mytool ./cmd/mytool；-s去符号表，-w去 DWARF 调试信息，体积通常减半 - 若必须用 CGO（如调
libz），确保 CI 环境的libc版本 ≥ 目标机器（常见坑：Alpine 上用musl，但生产机是 glibc，直接运行报not found） - 启动慢往往是因为 init 阶段做了重操作（如扫描整个
/proc、加载大量 YAML）；用pprof的runtime/pprof.StartCPUProfile快速定位 init 耗时函数
真正麻烦的不是写单个自动化脚本，而是让这些脚本在不同内核、不同权限模型、不同容器运行时下稳定工作——比如 unshare 系统调用在 rootless Podman 和 systemd-nspawn 里行为就不一样，得实测，不能只信文档。
