go-flags比flag更优，因其原生支持嵌套子命令、结构体绑定、环境变量fallback、短选项合并及友好错误提示；需注意tag用法、解析错误类型判断及子命令嵌套实现。
为什么不用 flag 标准库而选 go-flags
标准库 flag 能干活，但遇到嵌套子命令、自动生成帮助文本、结构体绑定、类型校验或 JSON/YAML 配置回写时，就得自己补一堆胶水代码。go-flags 用反射直接把 struct tag 映射成参数，天然支持子命令、环境变量 fallback、短选项合并（比如 -v -d → -vd），而且错误提示更友好——比如用户输错枚举值，它会明确告诉你合法选项是哪些。
定义参数结构体时的 tag 写法细节
go-flags 依赖 struct tag 解析，long、short、description 是最常用字段，但容易漏掉几个关键点：
-
envtag 必须显式声明才启用环境变量读取，例如`env:"DB_HOST"``，否则即使设置了DB_HOST环境变量也不会生效 - 布尔类型字段若没设
default，默认值是false，但命令行不传该 flag 时，go-flags 不会覆盖 struct 原始值——得加no-flagtag 或手动初始化为 false 才可靠 - 切片类型（如
[]string）要支持多次出现（-t a -t b），必须用no-ini防止被配置文件误覆盖，且需确认版本 ≥ 1.5.0（旧版对重复 flag 支持不稳定） - 如果字段名含下划线（如
log_level），go-flags 默认按驼峰转连字符（--log-level），但若想保留下划线，得加name:"log_level"
解析失败时如何拿到具体错误而不是 panic
调用 parser.Parse() 时，错误类型是 *flags.Error，不是普通 error。直接 fmt.Println(err) 只会输出 “flag parse error”，真正有用的上下文在 err.Type 和 err.Message 里：
if err != nil {
if flagsErr, ok := err.(*flags.Error); ok && flagsErr.Type == flags.ErrHelp {
os.Exit(0) // 用户敲 -h，正常退出
}
log.Fatal("CLI parse failed: ", err)
}
常见错误类型有：flags.ErrUnknownFlag（拼错参数名）、flags.ErrInvalidArgument（类型转换失败，比如字符串塞给 int 字段）、flags.ErrRequiredMissing（必填项没给）。别用 strings.Contains(err.Error(), "unknown") 这种脆弱判断。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
子命令怎么组织才不混乱
子命令不是靠 if-else 分支硬写，而是用嵌套 struct 实现。主 parser 的 Command 字段指向一个实现了 flags.Commander 接口的结构体，它的 Execute(args []string) 方法负责该子命令逻辑：
type ServeCmd struct {
Port int `long:"port" default:"8080" description:"HTTP port"`
}
func (x *ServeCmd) Execute(args []string) error {
fmt.Printf("Starting server on port %d\n", x.Port)
return nil
}
var opts struct {
Serve ServeCmd `command:"serve" alias:"s" description:"Start HTTP server"`
}
这样运行 ./app serve --port 3000 就自动路由到 ServeCmd.Execute。注意：子命令 struct 不能是匿名字段，否则反射找不到；所有子命令字段必须用 command: tag 标记，否则会被当成普通 flag。
复杂服务往往有多个层级子命令（比如 app db migrate up），这时得链式嵌套：外层 struct 的字段是另一个带 command tag 的 struct，逐层下沉即可。但每层都得实现 Execute，别指望 go-flags 自动递进调用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
