因为 flag 包不支持子命令、短选项连写、位置参数混合等复杂 CLI 场景，需用 os.Args 手动实现状态机解析器，配合 Command 结构体和 Flag 类型实现可复用、可扩展的命令行工具。
为什么不用 flag 包而要自己写解析器
因为 flag 无法处理子命令（如 git commit -m "xxx"）、位置参数混合、短选项连写（-abc）、或自定义错误提示格式。当你需要支持类似 mytool deploy --env=prod service-a 这种结构，且要求 service-a 是必填位置参数、--env 可省略时，flag 的静态注册机制就僵住了。
真正需要自定义解析的典型场景：CLI 工具需兼容 POSIX 风格 + GNU 扩展（比如 --help 和 -h 同时生效），或要对未识别参数做降级处理（转给下游命令），又或者参数语义依赖上下文（mytool run --debug 中 --debug 只在 run 下有效）。
用 os.Args 做基础切片和状态机驱动
别碰正则匹配参数 —— 容易漏掉引号包裹的空格、转义符、边界情况。直接从 os.Args[1:] 开始逐项扫描，用一个状态变量记录当前解析阶段（比如：等待 flag、收集位置参数、读取 flag 值）。
-
--foo=bar和--foo bar要视为等价，但--foo=应报错（除非该 flag 允许空值） - 遇到
--就终止 flag 解析，之后所有内容全作位置参数 - 短选项连写如
-abc拆成-a -b -c，但若-c需要值（如-c port），则-abc8080应解析为-a -b -c 8080，而非-a -b -c8080 - 错误时不要 panic，返回
error并附带原始输入片段（如"unknown flag '--xyz'"），方便调用方统一输出帮助信息
如何设计可复用的 Command 结构体
每个子命令（如 deploy、rollback）应是一个独立 Command 实例，而不是靠 if-else 分支。核心字段至少包括：Name、Usage、Flags（map[string]*Flag）、Args（校验规则，如 "at least 1"）、Run（func(*Context) error）。
立即学习“go语言免费学习笔记（深入）”；
Flag 类型必须含 Shorthand（'v'）、Longhand（"verbose"）、HasValue（是否需后续参数）、DefaultValue（避免零值歧义）。特别注意：HasValue=false 的 flag（如 --help）不能接受 = 形式赋值，--help=true 应报错。
示例：定义 deploy 命令的 --env flag：
EnvFlag := &Flag{
Longhand: "env",
Shorthand: 'e',
HasValue: true,
DefaultValue: "staging",
}
这样在解析时就能自动绑定到结构体字段，且默认值不污染用户显式传入的空字符串。
容易被忽略的边界：引号、空格和 Windows 路径
Go 的 os.Args 在 shell 层已做过一次拆分，但 Windows cmd.exe 和 PowerShell 行为不同：cmd 把双引号内空格当字面量，PowerShell 还会吃掉反斜杠。所以不要假设 os.Args 是“干净”的输入 —— 比如用户敲了 mytool run "C:\temp\file.txt"，在 Windows 上 os.Args[2] 可能是 C:\temp\file.txt（引号被剥离），也可能是 "C:\temp\file.txt"（取决于启动方式）。
实操建议：
- 对每个位置参数调用
strings.Trim(s, `"`)，再检查是否以"开头且以"结尾（防误删路径中的引号） - 避免在解析层处理通配符（
*、?），那是 shell 的事；你的模块只管接收最终传进来的字符串 - 如果用户传入
--config ./conf.json，不要自动补全为绝对路径 —— 留给业务逻辑决定是否filepath.Abs
最麻烦的其实是测试：得在 Linux/macOS/Windows 上分别验证 sh -c 'mytool cmd -f "a b" c' 和 cmd /c mytool.cmd cmd -f "a b" c 是否产出一致的 Args 切片。这点没绕过去的捷径。
