Go flag包适用于简单命令行工具，但复杂场景易出错；String返回*string指针，StringVar需传入变量地址；混用会panic；flag.Args()返回未识别参数；布尔标志不支持=赋值；不支持短选项组合和子命令。
Go 的 flag 包足够应付绝大多数命令行工具开发需求，不需要一上来就引入 cobra；但直接用它写稍复杂的工具时，容易在参数绑定、错误处理和位置参数边界上出问题。
flag.String 和 flag.StringVar 的区别在哪？
核心区别是返回值类型和内存管理方式：flag.String 返回 *string 指针，flag.StringVar 接收已有变量的地址并直接写入。
-
flag.String("name", "default", "help")创建新变量，必须用*name解引用取值 -
flag.StringVar(&name, "name", "default", "help")要求name是已声明的string变量，解析后直接更新原变量 - 混用两者（比如对同一个标志名既调
String又调StringVar）会导致 panic：重复注册标志 - 如果想让多个标志共用同一变量（如 -v 和 --verbose 都控制 verbose），只能用
StringVar+ 手动注册别名，flag本身不支持短/长选项自动映射到同一变量
flag.Parse() 后，怎么拿到没被识别的参数？
flag.Parse() 会把所有匹配成功的标志从 os.Args 中“摘走”，剩下未被识别的部分可通过 flag.Args() 获取 —— 这不是 os.Args[1:] 的简单切片，而是经过解析后剩下的原始字符串数组。
-
go run main.go -port=8080 file1.txt file2.json→flag.Args()返回[]string{"file1.txt", "file2.json"} - 注意：如果用户输错标志（如
-unkown），flag.Parse()会打印错误并调用os.Exit(2)，根本不会执行到flag.Args() - 想捕获解析失败而不退出？必须在
flag.Parse()前重定向flag.CommandLine.ErrorLog并设置flag.CommandLine.Init()，但代价是放弃默认错误提示逻辑
布尔标志为什么不能写成 -debug=true？
flag 对布尔类型做了特殊处理：只要标志出现在命令行中，就视为 true；显式写 =true 或 =false 会被当作非法值报错。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 正确：
-debug、--debug、-debug=true（仅当用flag.BoolVar且值为true时兼容，但不推荐） - ❌ 错误：
-debug=false（解析失败）、--debug false（会被当成位置参数） - 想支持显式赋值（如
--debug=false），得自己实现flag.Value接口，或改用字符串类型再做转换 - 短选项组合不支持：
-abc不等价于-a -b -c，这是flag的硬性限制，不是 bug
真正容易被忽略的是：flag 包没有“子命令”概念，所有标志都平铺在根命令下；一旦需要 git commit、git push 这类结构，就得手动拆分 flag.Args() 并二次解析，或者直接换 cobra。这不是设计缺陷，而是定位使然 —— 它只负责“参数解析”，不负责“命令路由”。
