Go flag.FlagSet 的 ContinueOnError 和 ExitOnError 有什么区别

在 Go 的 flag.FlagSet 里，ContinueOnError 和 ExitOnError 的核心区别只有一句话：前者把解析失败交还给调用者，后者让当前进程结束。子命令、库函数和单元测试通常需要前者；真正的命令行入口如果确定错误只能终止程序，才适合后者。

官方地址：https://pkg.go.dev/flag#ErrorHandling

这里比较的是标准库 flag 的控制流，不涉及 Cobra 等第三方框架。先记住一个容易忽略的细节：ExitOnError 对参数解析错误通常调用 os.Exit(2)，但处理 -h 或 -help 时会以退出码 0 结束。

先看 Parse 的返回与退出差异

FlagSet 的错误策略由 NewFlagSet 的第二个参数决定。官方把 ContinueOnError 定义为返回描述性错误，把 ExitOnError 定义为调用 os.Exit(2)（帮助请求则是 os.Exit(0)）。还有一个本文不展开的 PanicOnError，它会用描述性错误触发 panic。

所以这两个常量不是“错误提示风格”的切换，而是调用栈能否继续掌握控制权的切换。使用 ContinueOnError 时，Parse 返回后可以记录错误、选择另一个子命令流程，或者把错误交给测试断言；使用 ExitOnError 时，错误路径不会回到当前函数继续执行。

FlagSet 和默认 CommandLine 不是同一种默认行为

自建的 FlagSet 适合表达一个独立的参数集合，例如 start、stop 这样的子命令。零值 FlagSet 的错误处理策略是 ContinueOnError，而包级的默认 CommandLine 使用 ExitOnError。这也是许多小程序一调用全局 flag.Parse()，遇到未知参数就直接退出的原因。

如果一个函数内部解析的是调用者传入的参数切片，就不要让它悄悄结束整个进程。把参数集合显式创建出来，策略和输出位置都会更容易控制。

用 ContinueOnError 把错误交给子命令上层

子命令函数通常不拥有整个进程的生命周期。它只负责识别自己的参数，并把失败原因返回给更外层的调度函数，这时可以使用 ContinueOnError：

package main

import (
    "flag"
    "fmt"
    "io"
)

func parseStartArgs(args []string) (string, error) {
    fs := flag.NewFlagSet("start", flag.ContinueOnError)
    // 子命令只处理自己的参数，错误由上层决定如何展示和退出。
    fs.SetOutput(io.Discard)
    addr := fs.String("addr", ":8080", "监听地址")
    if err := fs.Parse(args); err != nil {
        return "", fmt.Errorf("解析 start 参数失败: %w", err)
    }
    // Parse 成功后再读取指针，避免错误路径继续使用未确认的配置。
    return *addr, nil
}

func main() {
    addr, err := parseStartArgs([]string{"-addr", ":9090"})
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println("准备监听", addr)
}

这里的关键不是把错误包装成中文，而是 Parse 的返回值仍然存在。上层可以决定打印到哪里、是否显示完整用法、是否为多个子命令统一转换退出码，也可以在测试里直接断言错误。

为什么单元测试更适合 ContinueOnError

如果被测试函数内部使用 ExitOnError，错误参数会触发 os.Exit，测试进程本身也会被结束，调用者没有机会检查返回结果。使用 ContinueOnError 后，测试可以把参数解析看成普通函数行为。

func parseMode(args []string) (string, error) {
    fs := flag.NewFlagSet("mode", flag.ContinueOnError)
    // 禁止测试输出干扰测试日志，生产入口可改成 os.Stderr。
    fs.SetOutput(io.Discard)
    mode := fs.String("mode", "safe", "运行模式")
    if err := fs.Parse(args); err != nil {
        return "", err
    }
    return *mode, nil
}

func exampleTest() error {
    // 未定义的参数应返回错误，而不是结束测试进程。
    _, err := parseMode([]string{"-unknown"})
    if err == nil {
        return fmt.Errorf("期望未知参数返回错误")
    }
    return nil
}

示例中的 exampleTest 只是展示断言边界；真实测试中可以改写成 TestParseMode 并使用测试框架的断言。只要解析函数不直接退出，错误路径就能被重复覆盖。

正式 CLI 入口何时使用 ExitOnError

在最外层的命令行入口，参数解析失败往往意味着程序没有可靠的运行配置。此时使用 ExitOnError 可以让标准库负责调用用法函数并结束进程，入口函数不需要在每个参数后写重复的错误分支：

package main

import (
    "flag"
    "os"
)

func main() {
    fs := flag.NewFlagSet("worker", flag.ExitOnError)
    // 顶层入口确认解析失败就结束当前命令，因此选择 ExitOnError。
    workers := fs.Int("workers", 4, "并发数量")
    fs.Usage = func() {
        // 自定义用法仍由 Parse 失败路径调用，然后再按策略退出。
        fs.PrintDefaults()
    }
    fs.Parse(os.Args[1:])
    // 能走到这里，说明 Parse 没有触发退出策略。
    _ = workers
}

这里的“正式入口”是边界条件，不是说所有 CLI 都必须使用 ExitOnError。如果入口还要把错误转换成统一的 JSON、写入结构化日志、执行清理或由宿主程序接管生命周期，仍然可以选择 ContinueOnError，由外层明确调用 os.Exit。

Usage 会不会改变两者的本质

FlagSet 有一个 Usage 函数，用于解析错误时输出参数说明。自定义 Usage 只改变“输出什么”，不改变 ErrorHandling 决定的“输出之后怎么办”。

• ContinueOnError：先按当前 Usage 输出，再把描述性错误返回给调用者。
• ExitOnError：先按当前 Usage 输出，再结束进程；普通解析错误的退出码是 2。
• -h 或 -help：在 ExitOnError 下属于帮助请求，退出码是 0，不应与非法参数混为一谈。

如果不希望子命令在解析失败时自动打印一大段帮助，可以通过 SetOutput 和自定义 Usage 调整输出；不要为了隐藏输出而误选退出策略。

按调用场景选择

可以把选择原则压缩成一个问题：解析失败后，当前调用者还需要做决定吗？需要，就用 ContinueOnError；不需要，且这是进程最外层，就可以用 ExitOnError。

小结

ContinueOnError 和 ExitOnError 解析的规则没有不同，改变的是失败之后的控制权。前者返回错误，适合子命令、库函数和测试；后者在普通解析错误时调用 os.Exit(2)，适合由标准库直接结束的顶层入口。Usage 负责输出内容，不能替代错误策略的选择。

相关问题

• 为什么自建 FlagSet 遇到未知参数没有直接退出？因为零值策略是 ContinueOnError，或者创建时显式选择了它。
• ExitOnError 的错误码是不是永远为 2？非法参数等解析错误是 2；-h 或 -help 是帮助请求，退出码为 0。
• 自定义 Usage 后还能捕获错误吗？可以，Usage 只负责输出；是否返回、退出或 panic 仍由 ErrorHandling 决定。
• 子命令为什么不建议直接调用全局 flag.Parse？全局 CommandLine 的默认策略是 ExitOnError，会把子命令的错误处理权提升为整个进程的退出。