go-flags不支持子命令自动解析，必须手动注册每个子命令并分别调用parse；结构体标签仅标记字段用途，不触发自动路由，需在parse后检查非nil字段并用findcommand获取对应command实例再调用parseargs解析其参数。
go-flags 本身不支持嵌套子命令的自动解析，必须手动注册每个子命令并分别调用 Parse；直接套用结构体标签无法处理动态参数数量、互斥选项或条件依赖。
为什么 go-flags 的结构体绑定对子命令无效
很多人以为给结构体字段加 subcommand 标签就能自动识别子命令，但实际只是把字段标记为“可能存放某个子命令结构体”，go-flags 不会主动扫描、实例化或路由到对应结构体。它只做一层字段映射，子命令逻辑必须由你显式控制。
- 主结构体中声明
CmdFoo *FooCmd `long:"foo" description:"do foo"`，仅表示“如果命令行出现--foo，就尝试把后续参数塞进FooCmd” - 真正触发子命令解析，得在
Parse后检查哪个字段非 nil，再对那个字段单独调用parser.ParseArgs - 如果不手动分发，所有子命令参数都会被丢进主结构体的
Args字段，导致解析失败或静默忽略
如何正确注册并解析带参数的子命令
核心是：每个子命令定义独立结构体 + 独立 Parser 实例 + 手动判断和转发。不能指望一个 Parser 通吃全部层级。
- 主结构体只保留顶层标志（如
--verbose）和子命令字段指针，不放具体逻辑 - 每个子命令结构体需实现
Interface（通常空实现即可），并用parser.AddCommand注册，而非靠结构体标签 - 调用
parser.Parse()后，检查返回的remaining—— 它包含未被主解析器消费的参数，也就是子命令名和其参数 - 用
parser.FindCommand(remaining[0])获取对应子命令的*Command，再调用其Parse(remaining[1:])
示例关键片段：
type Root struct {
Verbose bool `long:"verbose"`
Foo *FooCmd `long:"foo"`
}
type FooCmd struct {
Name string `long:"name" required:"true"`
}
// 注册
parser := flags.NewParser(&root, flags.Default)
parser.AddCommand("foo", "do foo", "", &FooCmd{})
_, err := parser.Parse()
if err != nil {
log.Fatal(err)
}
// 手动分发
if root.Foo != nil {
// 注意：这里不能直接 Parse(root.Foo)，必须用 parser.FindCommand 得到的 cmd 实例
cmd, _ := parser.FindCommand("foo")
_, err := cmd.ParseArgs(os.Args[2:]) // 需跳过程序名和子命令名
if err != nil {
log.Fatal(err)
}
}
处理互斥选项和动态参数数量的替代方案
go-flags 的 required 和 noarg 标签只能做静态校验，无法表达“A 和 B 不能同时出现”或“至少提供一个 --input 或 --stdin”。这类逻辑必须放在 Parse 之后手动检查。
- 用
parser.GetOpts()拿到原始选项列表，遍历判断冲突（比如同时存在--file和--url） - 对变长参数（如
files ...），结构体字段类型必须是[]string，且不能加short标签，否则解析会失败 - 如果需要位置参数（如
cmd run <task-id> --timeout 30</task-id>），主结构体需定义Args []string `positional-args:"true"`，并在解析后从Args取值，而不是依赖子命令结构体的字段 - 性能上，每次
AddCommand都会构建新命令树，子命令超过 10 个时建议拆成多个Parser实例，避免启动延迟
最常被忽略的是：子命令的 ParseArgs 接收的是“剩余参数切片”，不是完整 os.Args；传错索引会导致参数错位或 panic。另外，go-flags 对 --flag value 和 --flag=value 的兼容性不一致，某些版本在子命令中只认后者，务必在目标 Go 版本下实测。
