os.Args[0]是程序名而非用户参数，真正参数从os.Args[1]开始；需检查长度防panic，带标识参数应优先用flag包解析，位置参数用flag.Args()获取，空格等由shell分词后传入Go。
os.Args 是最直接的方式，但要注意索引偏移和空参数处理 —— 它不是“用户输入”，而是程序启动时传入的原始参数切片。
为什么 os.Args 的第一个元素是程序名而不是第一个参数
Go 运行时把执行命令完整拆分成字符串切片：os.Args[0] 对应二进制路径或命令名（如 ./main 或 go run main.go），真正用户传的参数从 os.Args[1] 开始。如果直接取 os.Args[0] 当作参数，大概率会读到意外路径或报 index out of range。
- 运行
go run main.go hello world时，os.Args实际是["/tmp/go-build.../main", "hello", "world"]（路径因环境而异） - 运行
./myapp -v --port=8080时，os.Args是["./myapp", "-v", "--port=8080"]，所有内容都保持原始字符串形态，不解析 flag 或等号 - 若没传参数就访问
os.Args[1]，会 panic；务必先检查len(os.Args) > 1
用 flag.String 解析带标识的字符串参数更安全
当参数有语义（比如 -name="Alice" 或 --output=file.txt），硬拆 os.Args 容易出错。flag 包能自动类型转换、提供默认值、生成帮助文本，且忽略顺序。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
name := flag.String("name", "anonymous", "user name")声明一个字符串 flag，未提供时回退为"anonymous" - 必须在
flag.Parse()之后读取，否则值仍是零值；flag.Parse()会截断os.Args，只留下非 flag 部分到flag.Args() - 支持多种形式：
-name=Alice、-name Alice、--name=Alice都有效；但-n Alice需额外注册短选项 - 注意：flag 不处理位置参数（如
myapp file1.txt file2.txt中的file1.txt），那些得用flag.Args()拿
遇到空格、引号、特殊字符时怎么保真传递
shell 层已做初步解析，Go 拿到的是 shell 分词后的结果 —— 也就是说，./app "a b" 'c d' 传入 Go 后，os.Args 是 ["./app", "a b", "c d"]，引号本身不会出现。你不需要手动去引号，但也不能假设参数里绝无空格。
立即学习“go语言免费学习笔记（深入）”；
- 如果用户输入含换行或制表符，需确认 shell 是否允许（通常不推荐）；Go 本身不做额外转义
- 从
stdin读字符串（比如fmt.Scanln(&s)）和命令行参数是两回事：前者是运行时交互输入，后者是启动时静态传入 - 避免用
strings.Split(os.Args[1], " ")拆分带空格的参数 —— 这会错误切开本应一体的值，正确做法是直接用整个os.Args[1]
真正容易被忽略的是：参数边界由 shell 决定，Go 只负责接收。写脚本调用 Go 程序时，如果拼接参数用了 $(cmd) 或变量未加引号，会导致空格截断 —— 这个坑不在 Go 侧，但在实际部署中高频出现。
