应优先使用 flag 包解析带语义的参数；os.Args 仅为原始字符串切片，直接访问 os.Args[1] 易因参数缺失导致 panic，须先检查长度；flag.Parse() 会修改 os.Args 并移除已匹配的 flag，剩余参数应通过 flag.Args() 获取。
别直接用 os.Args 解析带语义的参数——它只是原始字符串切片，不是解析器。
为什么 os.Args[1] 会 panic
因为 os.Args[0] 是程序路径（如 "./app" 或 "/tmp/go-build/main"），真正用户参数从 os.Args[1] 开始。但若没传参数，len(os.Args) 就是 1，此时访问 os.Args[1] 直接越界 panic。
- 必须先检查
len(os.Args) > 1才能安全取os.Args[1] - 想取“所有用户参数”，用
os.Args[1:]切片，而不是硬写os.Args[1]、os.Args[2]等下标 - 运行
go run main.go "hello world"时，os.Args是["/tmp/xxx", "hello world"]，引号已被 shell 去掉，Go 拿到的就是完整字符串
什么时候该换 flag 包而不是硬拆 os.Args
只要参数含开关（-v）、赋值（--port=8080）、默认值或类型需求（把 "42" 变成 int），os.Args 就该让位。
-
flag.String("output", "out.txt", "output file path")声明后，支持-output=file.txt、--output file.txt、-output file.txt三种写法 -
flag.Parse()后，用*outputFlag取值，不是os.Args里手动找 - 未被
flag消费的剩余参数（如文件路径）通过flag.Args()获取，不是os.Args[1:] - 若在
flag.Parse()后还去读os.Args[1]，可能越界或拿到已被“划掉”的旧值
os.Args 和 flag.Args() 混用的典型翻车点
很多人以为 flag.Parse() 只是“读一下”，其实它会原地修改 os.Args：把匹配的 flag 全部移除，只留下非 flag 部分。
立即学习“go语言免费学习笔记（深入）”；
- 执行前：
os.Args == ["./app", "-v", "--port=8080", "config.yaml"] - 执行
flag.Parse()后：os.Args变成["./app", "config.yaml"]（假设只注册了-v和--port） - 此时
flag.Args() == ["config.yaml"]，而os.Args[1]虽然也等于"config.yaml"，但这是巧合；如果没传config.yaml，os.Args[1]就会 panic - 子命令场景（如
mytool serve --port=3000）中，os.Args[1]是"serve"，但flag.Parse()会把它当 flag 处理——除非你提前切分并路由
最易被忽略的是：参数分词由 shell 完成，Go 只负责接收。你看到的 os.Args 已经是 shell 处理后的结果，不要试图在 Go 里再做引号解析或空格重拼。
