flag.Parse()必须在所有flag定义之后、任何使用之前调用，否则参数值无法正确解析；StringVar更适合配置结构体绑定和测试，混合位置参数应通过flag.Args()获取。
Go语言写命令行工具，flag 包够用，但必须按顺序、分阶段用；盲目套用示例或提前访问变量，90% 的参数读不到值。
flag.Parse() 必须在所有 flag 定义之后、任何使用之前调用
这是最常踩的坑：定义了 flag.String("port", "8080", "") 就直接打印 *port，结果永远是默认值。因为 flag.Parse() 才真正从 os.Args 中提取并赋值——它不自动触发，也不延迟生效。
- 错误写法：
port := flag.String("port", "8080", "")→ 紧接着fmt.Println(*port)（此时仍是空字符串或 0） - 正确顺序：所有
flag.Xxx()或flag.XxxVar()调用完毕 → 立即调用flag.Parse()→ 再读取变量 - 位置很重要：
flag.Parse()一般放在main()开头，紧贴 flag 定义块下方；若中间插入了fmt、log或配置加载逻辑，就可能漏掉解析
String 与 StringVar 的选择影响测试和结构体绑定
flag.String 返回指针，flag.StringVar 写入已有变量地址——区别不只是语法，而是生命周期和可测性。
- 用
flag.StringVar(&cfg.Port, "port", 8080, "")更适合把参数直接注入配置结构体，避免后续解引用和空指针风险 - 用
port := flag.String("port", "8080", "")适合临时参数、快速原型，但必须记得每次用都加*解引用，比如http.ListenAndServe(":"+*port, nil) - 测试时，
StringVar更友好：传一个局部变量地址进去，断言该变量值即可；String需要重置全局flag.CommandLine或用flag.NewFlagSet隔离
混合位置参数和 flag 时，别碰 os.Args[1]
想让程序支持 ./tool config.yaml --verbose 这类“文件路径 + flag”混合用法，绝不能在 flag.Parse() 前读 os.Args[1]——因为用户可能把 flag 放前面，os.Args[1] 根本不是文件名。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：调用
flag.Parse()后，用flag.Args()拿剩余未被解析的参数，它们就是位置参数 -
flag.NArg()返回个数，flag.Arg(i)按索引取，比手撕os.Args安全得多 - 如果要求至少一个位置参数，检查
len(flag.Args()) ，而不是 <code>len(os.Args)
flag 不支持子命令，别硬撑
一旦出现 mytool serve --port 3000 或 mytool migrate up 这类结构，flag 包就到头了。它没有子命令树、没有嵌套 help、无法隔离不同命令的 flag 集合。
- 强行用
flag.Parse()两次？会 panic：全局flag.CommandLine已被修改，第二次调用报 “flag redefined” - 想支持子命令，必须换
github.com/spf13/cobra；它内部用pflag（兼容flag），但提供AddCommand、Flags().String等层级 API - 过渡方案：先用
flag.Arg(0)判断第一个位置参数是不是已知子命令名，再手动跳转到对应逻辑——但这只是模拟，没 help 分组、没补全、没自动错误提示
真正难的不是写几个 flag.String，而是守住解析边界：flag 只管启动参数，交互式输入、多步向导、密码隐藏、动态选项列表——这些都得靠额外库或手写逻辑，flag 从不越界。
