flag.Parse不支持嵌套子命令、重复flag累加和自动拆分逗号字符串，因其设计追求简单无副作用；需用独立FlagSet、自定义Value接口及高优先级命令行覆盖策略来安全扩展。
flag.Parse 为什么不能直接处理嵌套或重复参数
flag.Parse 本身只做一次线性扫描，遇到第一个非 flag 参数就停止解析，后续内容全扔进 flag.Args()。它不支持子命令（比如 tool serve --port=8080 和 tool migrate --dry-run）、也不识别重复 flag（如多次传 -v 应该累加为 verbosity 级别），更不会自动拆分逗号分隔的字符串为切片。这些不是 bug，是设计取舍：标准库追求简单、确定、无副作用。
常见错误现象包括：flag: invalid argument "subcmd" for "-f"（把子命令误当成 flag 值）、flag provided but not defined（子命令后定义的 flag 没注册到当前上下文）、或者 flag.Args() 返回空但实际有参数——因为 flag.Parse() 在遇到第一个非 flag 字符串时就截断了。
- 子命令必须在
flag.Parse()前手动提取，比如用os.Args[1]判断再分流 - 重复 flag 需用
flag.CountVar或自定义flag.Value实现，不能靠flag.StringSlice直接解决（它只接受逗号分隔或多次-s a -s b，但默认不支持-v -v -v） - 嵌套结构（如 JSON 配置覆盖 flag）得靠外部解析后手动赋值，
flag.Parse()不参与
如何安全地在子命令场景下复用 flag 包
核心思路是：每个子命令维护独立的 flag.FlagSet，避免全局 flag.CommandLine 被污染。否则执行 tool serve 后再跑 tool migrate，可能因前一个命令注册的 flag 导致冲突或 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要调用
flag.Parse()全局入口；改用flag.NewFlagSet(os.Args[0], flag.ContinueOnError)为每个子命令建隔离实例 - 子命令参数从
os.Args[2:]开始传入（跳过命令名），再调用对应FlagSet.Parse() - 错误处理必须显式检查返回值：
if err != nil && err != flag.ErrHelp { os.Exit(2) }，否则flag.ContinueOnError会继续执行后续逻辑 - 共享 flag（如
-h、--config）可提前提取并预处理，再把剩余参数交给子命令专用 FlagSet
自定义 flag.Value 实现动态参数类型（比如 duration slice）
标准 flag 类型（String、Int 等）无法表达“多个持续时间，如 -timeout 1s -timeout 5s”，这时必须实现 flag.Value 接口。容易忽略的是：该接口的 Set(string) 方法会被每次 flag 出现时调用，不是只调用一次。
示例片段：
type DurationSlice []time.Duration
func (d *DurationSlice) Set(s string) error {
dur, err := time.ParseDuration(s)
if err != nil {
return err
}
*d = append(*d, dur)
return nil
}
func (d *DurationSlice) String() string {
return fmt.Sprint([]time.Duration(*d))
}
// 使用：
var timeouts DurationSlice
flag.Var(&timeouts, "timeout", "timeout duration (can be repeated)")
关键点：
- 接收指针类型（
*DurationSlice），否则Set修改的是副本 -
String()方法只用于打印默认值或帮助文本，不影响解析逻辑 - 如果需要校验（如限制最多 3 个 timeout），应在
Set内部做，而非依赖外部逻辑
flag.Parse 与配置文件、环境变量的优先级协调
flag.Parse() 本身不读配置文件或环境变量，但真实工具往往要支持三者混合。常见错误是先解析 flag，再读配置覆盖——结果用户明明写了 -port 9000，却被 config.yaml 里的 port: 8080 覆盖了。
推荐顺序（由高到低）：命令行 flag > 环境变量 > 配置文件 > 默认值。实现时注意：
- flag 解析后立刻用
flag.Lookup("xxx").Value.String()检查是否被用户显式设置（注意：未设置时返回默认值字符串，不是空） - 环境变量应使用一致命名（如
TOOL_PORT对应-port），且仅在 flag 未设置时读取 - 配置文件加载宜放在 flag 解析之后、业务逻辑之前，避免提前读取导致 flag 无法覆盖
- 不要用
flag.Set()反向写入 flag 值——它不触发Value.Set()，且可能破坏 flag 的已设置状态判断
真正麻烦的是 flag 类型和配置文件字段类型的隐式转换（比如 YAML 里 verbose: true vs -v），这部分没法靠 flag.Parse 解决，得靠统一配置结构体 + 显式赋值逻辑来兜底。
