Go flag.FlagSet.ErrorHandling 如何控制命令行失败：ContinueOnError 与测试输出

命令行工具最怕的不是参数写错，而是写错后直接退出，测试拿不到稳定的错误，调用方也无法决定是提示、重试还是记录审计信息。Go 标准库 flag 的独立 FlagSet 可以把这件事交给调用层：把错误策略设成 flag.ContinueOnError，让 Parse 返回错误，业务代码再决定怎么处理。

先把命令行错误留在调用方手里

flag.CommandLine 面向最简单的主程序；一旦工具有多个子命令，或者需要在测试里反复传入参数，更适合调用 flag.NewFlagSet。它的第二个参数就是错误策略。

我更建议把 ContinueOnError 作为解析层默认值。这样参数错误仍然是失败，但失败不会越过函数边界。

最小实现：静默用法输出，返回可断言的错误

func parse(args []string) (string, error) {
    fs := flag.NewFlagSet("deploy", flag.ContinueOnError)
    fs.SetOutput(io.Discard)
    env := fs.String("env", "dev", "target environment")
    if err := fs.Parse(args); err != nil {
        return "", fmt.Errorf("parse deploy flags: %w", err)
    }
    return *env, nil
}

这里有两个容易混淆的点。ContinueOnError 决定错误返回方式；SetOutput 只把默认 usage 写入目标改掉。生产 CLI 可以把输出设为 os.Stderr，测试则常用缓冲区或丢弃输出。示例中的 help requested 也是返回到 err 的结果，不代表进程异常退出。

为什么未知参数不会被当成普通业务参数

示例先传入 -env prod service-a，解析成功后 service-a 会进入 FlagSet.Args()。第二组传入 -unknown x，Parse 在识别到未知 flag 后返回错误，函数不会继续把它当作部署目标。

这是一条很实用的边界：只有 err == nil 时才读取业务参数；如果还要求只能有一个目标，就继续检查 len(fs.Args()) == 1。不要只看 env 是否有值，因为默认值可能让失败输入看起来像成功。终端中的 parsed=true 和 strategy=0 共同说明这次解析成功且采用了继续返回策略。

把错误策略当成安全边界来选

命令行参数通常来自用户、脚本或 CI。对库函数来说，ExitOnError 会让调用方失去恢复机会，PanicOnError 则可能把可预期的输入错误升级成进程级异常。它们不是“更严格的校验”，而是不同的控制流契约。

• 解析器属于可复用包：使用 ContinueOnError，由上层决定提示格式和退出码。
• 顶层 main 已经确认错误不可恢复：可以在最外层统一转换成退出码。
• 测试需要检查 usage：给 SetOutput 一个 bytes.Buffer，同时断言返回错误和输出内容。

测试时要同时检查错误、输出和剩余参数

一组稳定的测试至少覆盖：合法参数、未知参数、-h 帮助、默认值和第一个非 flag 参数。对 ContinueOnError，测试不应依赖进程退出状态，而应断言 err 非空、fs.Args() 符合预期，并根据需要核对输出缓冲区。

如果这是多子命令 CLI，建议每次调用都新建一个 FlagSet。复用同一个实例会把已解析状态、flag 值和输出策略带入下一次测试，导致顺序敏感。

常见问题

ContinueOnError 会不会吞掉错误？

不会。它只是让 Parse 返回错误，调用方仍需检查 err，否则才可能把失败误当成成功。

SetOutput(io.Discard) 会不会关闭错误提示？

它会隐藏默认 usage 输出，但不会改变 Parse 的返回值。需要给用户提示时，应传入明确的 stderr 或缓冲区。

什么时候使用 ExitOnError？

适合已经位于顶层、且参数错误必然结束当前 CLI 进程的场景；可复用解析函数不建议自行退出。

为什么要检查 FlagSet.Args？

flag 解析器允许 flag 后存在普通参数。业务命令若只接受一个目标，就必须单独校验剩余参数数量和内容。

落地检查清单

• 解析层是否使用独立的 FlagSet？
• 是否显式选择了 ErrorHandling，而不是依赖顶层默认行为？
• 测试是否覆盖未知参数、帮助参数和剩余参数？
• 调用方是否同时判断 err 与业务参数，而不是只使用默认值？

把错误策略写进解析函数的接口约定，命令行程序就能在“提示用户”“返回给上层”和“结束进程”之间做出明确选择。对大多数可复用 Go 代码，ContinueOnError 是最容易测试、也最不容易越权的起点。