Go FlagSet 为什么仍输出到标准错误

Go FlagSet 在使用 ContinueOnError 后仍输出到标准错误，是因为“返回错误”和“写出诊断”是两个职责。应在解析前对同一个集合调用 SetOutput，再检查自定义 Usage、全局 flag 函数及外层日志是否绕过了这个输出目标。

flag 官方文档：https://pkg.go.dev/flag

ContinueOnError 为什么没有让解析器安静

一个嵌入式命令面板可能希望把参数错误返回给界面，而不是打印到宿主进程的终端。仅把新集合设成 flag.ContinueOnError，并不等于选择了“静默模式”。它改变的是 Parse 在失败之后怎样交还控制权，解析器生成的错误和用法文本仍有自己的输出目标。

可以把结构拆成六个对象：FlagSet、Parse、ErrorHandling、Usage、Output 和 io.Writer。Parse 使用集合的错误处理策略；Usage 负责用法文本；Output 表达当前写入目标，具体 writer 承接文本。不要把 ErrorHandling 当成 writer 的配置。

把诊断文本收进独立缓冲区

下面是原创的完整示例，只用标准库。每次调用创建新的集合和缓冲区，函数同时返回解析结果、诊断文本与错误；顶层调用方决定如何展示。把它保存为独立 Go 模块中的 main.go，不要混入已有 main 函数。

package main

import (
    "bytes"
    "errors"
    "flag"
    "fmt"
    "os"
)

// Options 只在参数全部解析成功后返回给业务层。
type Options struct {
    Limit int
}

func parseOptions(args []string) (Options, string, error) {
    var messages bytes.Buffer
    fs := flag.NewFlagSet("catalog", flag.ContinueOnError)
    // 必须在 Parse 之前设置，捕获这个集合的诊断与默认帮助文本。
    fs.SetOutput(&messages)
    limit := fs.Int("limit", 20, "最多显示的条目数")

    if err := fs.Parse(args); err != nil {
        return Options{}, messages.String(), err
    }
    // 语法解析不等于业务校验；业务错误由调用方统一表达。
    if *limit 

预期是 many 无法转成整数，解析函数返回非空错误，并把解析器文本留在 diagnostics；main 为展示示例主动写到标准输出。这不是本机实测日志。例子重点是文本所有权，不是完整 CLI 退出码策略；正式命令应在最外层为参数错误选择非零退出码，库函数不要自行退出宿主程序。

如果真实代码仍在 if err != nil 里调用默认日志器，或显式 fmt.Fprintln(os.Stderr, err)，那部分输出来自调用方，不受 fs.SetOutput 控制。保留 diagnostics 又再次打印 err，常常会把同一原因显示两遍。

自定义 Usage 应该写到哪里

自定义 Usage 最容易重新引入标准错误。若闭包内部直接写 os.Stderr，集合换了 writer 也不会改变这条显式写入。让帮助头和默认参数列表都从同一个 fs 出发，配置才能保持一致。

// 集成片段：fs 是前文创建且已设置输出目标的同一个 *flag.FlagSet。
fs.Usage = func() {
    // 通过 fs.Output 获取当前目标，不硬编码 os.Stderr。
    fmt.Fprintln(fs.Output(), "用法: catalog [选项]")
    fs.PrintDefaults()
}

这个片段放在参数定义之后、Parse 之前。fs.PrintDefaults 只描述该集合；不要在闭包里误用 flag.PrintDefaults()，否则可能打印全局集合的参数和输出。自定义 flag.Value 的 Set 方法同样可能含业务日志，集合并不能拦截任意回调内部的写入。

全局命令行和子命令不是同一个集合

flag.CommandLine 是包级函数使用的全局集合，新建的子命令集合则是另一个实例。设置子命令 fs 的输出，不能改变全局集合；设置全局集合，也不会自动传给后来创建的所有子命令。顶层集合、子命令集合、自定义 Usage、外层日志和各自的 writer 应有明确归属。

在共享库中通常优先使用独立集合，不为了捕获一条命令去替换全局状态或重定向整个进程的 os.Stderr。后一种办法影响范围更大，多个调用同时解析时也更难确定归属。示例的 bytes.Buffer 不提供并发写保证，因此它与集合一起按单次调用隔离，不跨 goroutine 共享。

帮助请求与参数错误分别处理

当未自行定义 h 或 help 参数而请求默认帮助时，ContinueOnError 模式可以返回 flag.ErrHelp。调用方应把“用户要帮助”和“参数格式有误”分开，否则帮助文本可能被错误地包装成一次业务失败。

前文使用 errors.Is 单独识别帮助。若改用 ExitOnError，解析器可能直接退出进程，外层处理代码没有机会接手；它不适合需要把结果交还宿主界面的解析函数。无论选择哪种模式，诊断写到哪里都应单独明确。

还要注意，Parse 返回错误时，前面某些参数可能已经被赋值。示例通过错误分支返回零值 Options，避免把半解析结果当作完整业务配置。是否接受位置参数、上限范围等属于业务规则，也应在成功解析之后明确处理。

选择捕获还是丢弃输出

// 集成片段：只希望丢弃当前集合的解析诊断时，仍需处理 Parse 返回值。
fs.SetOutput(io.Discard)
if err := fs.Parse(args); err != nil {
    return err
}

这个片段需要引入 io，且位于返回 error 的函数内；它不是前文 main 的直接替换代码。捕获到缓冲区适合界面展示、测试断言与统一格式化；丢弃适合调用方已有另一套诊断表达的场景。不能把丢弃文本误当成解析成功。

SetOutput(nil) 能静默吗？ 不能，nil 会让集合使用标准错误。需要丢弃时明确用 io.Discard。

只把 Usage 设为空函数够吗？ 这只能影响用法文本，不能据此认为所有解析错误消息都不会写出。输出目标仍应明确设置。

换了 writer 为什么日志还出现？ 先确认日志来自同一个 fs，再检查 Usage、回调和调用方。SetOutput 不是进程级重定向。

一个清楚的接口应让错误值、诊断文本和展示出口各有负责人。先确定谁写出了那行文字，再配置对应 writer，通常比反复切换 ErrorHandling 更有效。