测试 cli 应避免直接修改 os.args，而应解耦入口逻辑、用 os/exec.command 做端到端测试，并通过 t.cleanup 恢复 flag、stdout/stderr 等全局状态，同时校验 cmd.combinedoutput() 的 error 和退出码。
测试 CLI 命令时，别直接改 os.Args
直接赋值 os.Args = []string{"cmd", "--flag"} 看似简单，但会污染全局状态，尤其在并行测试中导致不可靠结果——多个测试用例可能互相覆盖 os.Args，出现偶发失败。
正确做法是封装入口逻辑，把参数解析和业务逻辑解耦：
- 把主流程抽成接受
[]string的函数（比如func mainWithArgs(args []string) error），而不是硬绑在func main()里 - 测试时传入受控的参数切片，不碰
os.Args - 如果必须测整个
main()，用os/exec.Command启子进程，捕获 stdout/stderr —— 这才是端到端的真实行为
用 testing.T.Cleanup 恢复被修改的全局变量
有些库（比如 flag 包）会在解析时修改内部状态，比如重置已定义的 flag；若测试中调用 flag.Parse()，后续测试可能因 flag 已被 parse 过而 panic 或静默失效。
稳妥做法是在测试开始时保存原始状态，并在结束前恢复：
立即学习“go语言免费学习笔记（深入）”；
- 对
flag.CommandLine，用flag.NewFlagSet替代默认实例，避免干扰 - 若必须用默认 flag set，先调用
flag.CommandLine = flag.NewFlagSet(os.Args[0], flag.ContinueOnError)重置，再用t.Cleanup恢复原 set -
os.Stdout/os.Stderr同理：测试前替换为bytes.Buffer，t.Cleanup中还原
捕获 CLI 输出时，别忽略 cmd.Run() 的返回值
用 os/exec.Command 测试 CLI 时，常见错误是只读 stdout 却忽略命令是否真的成功执行。比如 cmd.Output() 在非零退出码时直接 panic，而 cmd.CombinedOutput() 虽返回 err，但很多人只检查输出内容，不校验 err == nil。
实操建议：
- 统一用
cmd.CombinedOutput()，它合并 stdout/stderr 且返回 error - 显式检查
if err != nil，并用exec.ExitError类型断言判断是否为预期的非零退出（比如帮助信息触发--help应该成功，而参数缺失应失败） - 避免用
strings.Contains(string(out), "usage")判断帮助信息——输出可能被翻译、格式化或截断，优先依赖退出码 + 明确的标志位
os.Args 模拟与真实环境差异：Windows 下路径分隔符和空格处理
本地模拟 os.Args 时，容易忽略操作系统对命令行参数的实际拆分规则。例如：os.Args = []string{"mycmd", "a b", "c"} 在 Linux/macOS 下等价于命令行输入 mycmd "a b" c，但在 Windows 的 cmd.exe 中，引号行为略有不同，且 Go 运行时对 os.Args 的初始化还受 syscall.GetCommandLine() 影响。
这意味着：
- 含空格的路径（如
C:\Program Files\app）在 Windows 测试中必须加引号，否则会被拆成多个参数 - 跨平台测试时，不要假设
len(os.Args)在所有系统下一致；用filepath.Join构造路径，再按需包裹引号 - 真正关键的边界场景（如用户传入带引号的 JSON 字符串、shell 变量展开）无法靠模拟
os.Args覆盖，必须走exec.Command+ 真实 shell 调用
CLI 测试最麻烦的地方不在写断言，而在于搞清哪一层该测、哪一层不该碰——参数解析逻辑适合单元测试，而“用户敲下回车后看到什么”只能靠子进程捕获。越想绕过 exec 就越容易漏掉 shell 层的真实行为。
