flag.parse()必须在所有flag定义之后调用，否则参数变量保持零值或静默失效；flag.xxx()必须置于flag.parse()前，推荐集中放在main()开头；短长选项需显式注册别名；优先使用flag.stringvar以提升安全性和可测试性；csv格式参数须自定义flag.value实现。
flag.Parse() 必须在所有 flag 定义之后调用
不调用 flag.Parse()，所有参数变量永远是零值；提前调用，后续定义的 flag.String()、flag.IntVar() 全部失效——而且不会报错，只会静默失败。这是最常踩的坑。
- 所有
flag.Xxx()调用（如flag.String()、flag.BoolVar()）必须写在flag.Parse()之前 - 推荐把 flag 定义和
flag.Parse()放在main()开头，中间不穿插日志初始化、配置加载等逻辑 - 如果需要在解析前检查是否传了
-h，别直接用flag.Parse()，改用flag.CommandLine = flag.NewFlagSet(os.Args[0], flag.ContinueOnError)手动控制
短选项（-h）和长选项（--help）不能自动共用同一变量
Go 标准库 flag 不支持别名映射。flag.Bool("h", false, "") 和 flag.Bool("help", false, "") 是两个独立 flag，用户同时传 -h --help 会触发两次赋值，最终以后者为准，但语义已错乱。
- 高频短选项（如
-h、-v）可以保留，但必须显式注册：用flag.BoolVar(&help, "h", false, "show help")和flag.BoolVar(&help, "help", false, "") - 业务逻辑里统一判断：
if *help || *h { printUsage(); os.Exit(0) } - 别指望
-h自动触发--help的帮助输出——flag.Usage默认只响应未识别 flag，需手动拦截
用 flag.StringVar 还是 flag.String？
flag.String() 返回 *string，必须解引用；flag.StringVar() 直接写入已有变量地址，更安全、更易测试，尤其适合配置 struct。
- 结构体字段必须已声明，且生命周期覆盖到
flag.Parse()之后，例如：var cfg struct{ Host string }; flag.StringVar(&cfg.Host, "host", "localhost", "") - 传参必须是指针：
flag.StringVar(cfg.Host, )会编译失败，正确写法是&cfg.Host - 脚本类一次性工具可用
flag.String()，但指针管理容易出错，不推荐混用
解析逗号分隔字符串（如 --tags=a,b,c）必须实现 flag.Value
flag.StringSlice 只支持空格或引号分隔，对 --tags=a,b,c 这种 CSV 格式无效。原生 flag 不处理语法糖，得自己实现 flag.Value 接口。
- 核心是两个方法：
Set(string) error和String() string -
Set里要处理空字符串、空白字符，建议用strings.Split(strings.TrimSpace(value), ",")并过滤空项 - 多次传参（如
--tag a --tag b）需在Set中用append累积，否则只保留最后一次值
flag.Value 的 Set 方法必须是无状态的、可重入的，且错误处理不能被忽略——返回非 nil error 才会让 flag.Parse() 停止并调用 Usage。很多人漏掉空字符串过滤或没做类型校验，导致参数看似解析成功，实际内容不可用。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
