应避免直接使用 os.Args 拼接参数，因其不区分标志与值、无类型转换和校验；flag.StringVar 更适合脚本场景，绑定变量地址、结构清晰；flag.Parse() 必须在所有 flag 定义之后、首次读值之前调用；标志参数须置于位置参数之前。
为什么不用 os.Args 直接拼接参数
因为 os.Args 只是原始字符串切片，不区分标志、值、位置参数，也不做类型转换或合法性校验。比如执行 ./tool -port 8080 input.txt，os.Args 会返回 ["./tool", "-port", "8080", "input.txt"]，但你得自己判断 -port 后面那个是不是它的值，还得手动转成 int，出错就 panic。脚本化场景下容易写错逻辑，尤其当参数顺序变化或用户漏传时。
常见错误现象：
-
os.Args[2]硬编码取值 → 运行时报index out of range - 把
"8080"当整数用 →strconv.Atoi忘加 error check，程序直接崩溃 - 用户输成
--port=8080或-port=8080→os.Args不识别等号形式，解析失败
flag.String 和 flag.StringVar 哪个更适合脚本场景
flag.StringVar 更适合。它直接绑定已有变量地址，结构清晰、调试方便，且避免解引用操作（比如 *name），减少空指针风险。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 声明变量在前，
flag.StringVar(&var, "name", "default", "help")在后，顺序不能反 - 不要在
init()里调用flag.StringVar—— 多个文件时初始化顺序不可控，可能导致 flag 未注册就调用flag.Parse() - 如果变量名和 flag 名相同（如
port对应-port），命名更直观，也方便后续映射到配置结构体 -
flag.String返回指针，必须用*var访问值，脚本中易漏星号，导致打印出地址而非内容
flag.Parse() 必须放在哪儿
必须在所有 flag.XxxVar 或 flag.Xxx 调用之后、首次读取参数值之前。典型错误是把它放在 main() 最开头，或夹在 flag 定义中间。
正确姿势：
-
flag.Parse()是“开关”，它触发实际解析动作，此前所有 flag 定义只是注册规则 - 解析后，
flag.Args()才返回未被 flag 消费的剩余参数（即位置参数），比如./app -v file1.txt file2.json中的file1.txt和file2.json - 如果提前访问
flag.Args()（比如在flag.Parse()前），它永远返回空切片 - 若用
flag.Parse()后又想重置状态（比如测试多组输入），需用flag.NewFlagSet构建独立解析器，标准flag包不支持重复解析
如何兼容位置参数 + 标志参数混合使用
Go 的 flag 包默认把第一个非 - 开头的参数及之后全部视为位置参数（flag.Args()），但前提是所有标志参数必须放在位置参数之前。这是最常被忽略的约束。
例如：
- ✅ 正确：
./app -log debug file1.txt file2.txt→flag.Args()返回["file1.txt", "file2.txt"] - ❌ 错误：
./app file1.txt -log debug file2.txt→flag.Args()返回["file1.txt", "-log", "debug", "file2.txt"]，-log不再被识别为标志 - 若必须支持任意顺序，得放弃标准
flag，改用cobra或手写词法分析 —— 但脚本级工具通常没必要，统一约定参数顺序更简单可靠 - 可加一行提示：在
flag.Parse()后检查len(flag.Args()) == 0，若为真且业务要求至少一个输入文件，就报错并输出 usage
位置参数没有自动 help 提示，得靠文档或 fmt.Println("Usage: ./app [flags] <input-file> [output-file]")</input-file> 补充说明。
