os.Args 是 Go 启动时自动填充的原始命令行参数切片，首项为程序路径，其余为未解析的空格分隔字符串，不处理引号、选项格式或类型转换；需用 flag 包或 cobra 库实现语义化解析。
os.Args 是什么，为什么它不是“命令行参数解析器”
os.Args 是 Go 启动时自动填充的字符串切片，第一个元素是执行文件路径（os.Args[0]），后面才是用户输入的原始参数。它不处理空格、引号、短选项合并（如 -abc）、长选项（--help）或类型转换——这些都得自己写逻辑或换库。直接拿 os.Args[1:] 当参数用，等于裸奔进命令行世界。
常见错误现象：./app -v file.txt 里想取 file.txt，结果错把 -v 当成文件名；或者参数含空格（"hello world"）被拆成两个元素；又或者把数字参数当字符串用，忘了 strconv.Atoi。
-
os.Args不做任何解析，只做分词（按空格/制表符切），引号不识别 - Windows 和 Linux 下
os.Args的生成时机一致，但 shell 层面的转义行为不同，实际传入内容可能有差异 - 如果程序要支持
-h、--output=xxx或必填参数校验，立刻放弃os.Args手动解析
什么时候该用 flag 包而不是 os.Args
只要参数有“语义”，比如开关（-d 表示 debug）、配置项（-port=8080）、位置无关的输入（--config=config.yaml），就该切到 flag 包。它自动处理短横线、等号赋值、布尔标志、类型转换和基础帮助文本。
使用场景：CLI 工具、服务启动配置、脚本化调用（需要稳定接口）。
立即学习“go语言免费学习笔记（深入）”；
-
flag.String、flag.Int等函数返回指针，记得用*解引用获取值 - 调用
flag.Parse()后，os.Args剩余未解析部分在flag.Args()里，可用于接收非选项参数（如文件路径） - 默认不支持
foo --bar baz这种空格赋值，必须写成foo --bar=baz；若需兼容，得手动处理flag.Args()并配对
flag.Parse() 之后还能读 os.Args 吗
能，但意义变了。flag.Parse() 会从 os.Args 中“消费”掉已注册的 flag 参数，剩下的是未识别部分，也就是 flag.Args() 返回的内容。此时再访问 os.Args 没问题，但它的长度和内容已不同于初始状态。
容易踩的坑：在 flag.Parse() 前后都打印 os.Args 对比，会发现元素变少；更隐蔽的是，在 flag.Parse() 后还去索引 os.Args[1]，可能越界或拿到错误值。
- 始终优先用
flag.Args()获取非 flag 参数，而不是硬算os.Args下标 - 如果必须依赖原始参数顺序（比如实现类似
git add -- file.txt的双横线分隔），flag.Parse()会破坏这个结构，此时得用flag.CommandLine = flag.NewFlagSet(...)并禁用默认解析 -
flag.Parse()遇到未知 flag 会直接调用os.Exit(2)，不抛异常——这在测试中容易导致子进程意外退出
简单 CLI 用 flag，复杂交互别硬刚
两三个参数、纯开关或单值配置，flag 足够轻量。但一旦出现子命令（app serve / app migrate）、参数互斥（-a 和 -b 不能共存）、补全、颜色输出或国际化帮助文本，flag 就开始反人类。
这时候该换 spf13/cobra：它把子命令当一级对象，参数绑定到对应命令，自动挂载 --help，还能生成 man page 和 bash completion。
-
cobra的cmd.Flags().StringP()支持短名/长名/默认值/用法说明，比原生flag清晰得多 - 不要在
init()里初始化 cobra root cmd，会导致测试时 flag 冲突；应在main()或显式入口函数中构建 - 如果只是临时脚本，连
flag都嫌重，可以用os.Args[1:]+strings.HasPrefix快速判断，但务必加注释说明“此处无参数校验”
真正难的不是读参数，而是定义清楚哪些是配置、哪些是操作、哪些是目标资源——参数设计模糊时，再好的解析库也救不了逻辑混乱。
