flag.Parse()必须在所有flag定义之后调用，否则变量保持零值且静默失败；短选项与长选项不可共用同一变量；自定义类型需实现flag.Value接口；子命令须用flag.NewFlagSet隔离解析。
flag.Parse() 必须在所有 flag 定义之后调用
Go 的 flag 包是惰性注册机制：调用 flag.String、flag.Int 等函数只是把参数定义“登记”进全局 FlagSet，真正解析命令行字符串的动作发生在 flag.Parse()。如果提前调用，或漏掉这一步，所有变量值都保持零值（比如空字符串、0），且不会报错——这是最常踩的静默失败坑。
实操建议：
- 所有
flag.Xxx()调用必须写在flag.Parse()之前 - 习惯性把
flag.Parse()放在main()开头紧接定义之后，不要穿插其他逻辑 - 若需在解析前做预处理（如检查是否传了
-h），改用flag.CommandLine = flag.NewFlagSet(...)手动控制，避免污染默认 FlagSet
短选项（-v）和长选项（--verbose）不能共用同一个 flag 变量
flag 包不支持“一个变量绑定多个名称”，flag.Bool("v", false, "") 和 flag.Bool("verbose", false, "") 是两个独立 flag，哪怕类型和用途相同。用户同时传 -v --verbose 会触发两次赋值，最终以后者为准，但语义已混乱。
实操建议：
- 统一用长选项为主（如
--output），短选项仅保留高频、无歧义的（-h、-v） - 短选项必须单独定义，并确保逻辑一致：
debug := flag.Bool("d", false, "enable debug mode"); verbose := flag.Bool("v", false, "same as --debug")，再在业务逻辑里合并判断 - 别依赖
flag自动映射；需要别名支持，考虑用spf13/pflag替代
自定义类型必须实现 flag.Value 接口才能被 flag 解析
想让 flag 支持类似 --ports 8080,3000,8443 这种逗号分隔的切片？直接传 []int 会编译失败——flag 只认实现了 flag.Value 接口的类型（含 Set(string) error 和 String() string 方法）。
实操建议：
- 定义结构体并实现接口，例如
type PortList []int，然后实现Set(s string) error做字符串分割与转换 - 注意
Set方法里要处理错误并返回非 nil error，否则解析失败时静默忽略 - 避免在
Set中修改外部状态；flag 解析阶段应纯函数式 - 简单场景可用
flag.String接收后手动strings.Split，比实现接口更轻量
子命令参数解析要用 flag.NewFlagSet 分离上下文
像 git commit -m "msg" 这类带子命令的 CLI，主命令（git）和子命令（commit）的参数互不干扰。flag 默认只提供一个全局 FlagSet，强行复用会导致参数冲突或误解析。
实操建议：
- 为每个子命令创建独立
*flag.FlagSet：commitFlags := flag.NewFlagSet("commit", flag.ContinueOnError) - 子命令 flag 定义全部调用
commitFlags.String等，而非flag.String - 解析时传入子命令后的参数切片：
commitFlags.Parse(os.Args[2:])，注意索引偏移 - 错误处理模式选
flag.ContinueOnError，方便自己捕获并输出子命令帮助信息
flag 包够轻，但它的“约定大于配置”特性容易让人忽略上下文隔离和接口契约——尤其是 Parse() 的时机、Value 的实现细节、以及子命令的 FlagSet 切换，这三个地方出问题，调试成本远高于改用成熟 CLI 库。
