最稳起点是直接用argc和argv遍历；C++标准保证main(int argc, char* argv[])接口，argv为shell拆分好的C字符串数组，argv[argc]必为nullptr，遍历时须防越界，如检查argv[i+1]前需确认i+1
直接用 argc 和 argv 遍历是最稳的起点
别一上来就找库或封装类。C++标准只保证 main(int argc, char* argv[]) 这个接口，argv 是已由 shell 拆分好的 C 字符串数组，argv[argc] 必为 nullptr —— 这就是你安全遍历的铁律。
常见错误是越界访问：比如检查 argv[i+1] 前没确认 i + 1 ，结果读到 <code>argv[argc] 以外的内存；或者把 argv[0] 当作可靠程序名，其实它可能为空、被篡改，甚至不含路径。
- 从
i = 1开始处理，跳过argv[0] - 用
for (int i = 1; i ，不是 <code> - 判断选项时，先看
argv[i][0]是否为'-'，再看argv[i][1]是否为'\0'（避免把"-42"当成选项）
-f file 和 --input=file 的解析逻辑完全不同
短选项（如 -f）通常允许“粘连值”：-finput.txt 和 -f input.txt 都应识别为 file = "input.txt"；而长选项（如 --input）要支持等号语法，且必须拒绝空值：--input= 应报错，除非你明确允许空字符串。
GNU 风格还支持缩写，但得防歧义：若同时定义了 --input 和 --interactive，--in 就不能自动匹配任一者，否则用户会莫名其妙。
立即学习“C++免费学习笔记（深入）”；
-
-f后若紧跟非'-'字符（如-finput.txt），提取argv[i] + 2作为值 -
--key=value形式需用std::string::find('=')分割，且检查等号后是否为空 -
--key value形式需确保i + 1 且 <code>argv[i+1][0] != '-'
遇到 -- 就停止解析选项，后面全是位置参数
-- 是 POSIX 标准分隔符，意思是“之后所有内容都不再视为选项，哪怕以 - 开头”。这在脚本中很关键，比如 mytool --verbose -- -f broken.txt，其中 -f broken.txt 是传给子命令的原始参数，不是 mytool 自己的选项。
手写解析器时，一旦遇到 argv[i] == "--"，就跳出选项解析循环，把 i+1 到 argc-1 全部收进一个 std::vector<:string></:string> 里，后续按顺序取用即可。
- 不要把
--当作普通长选项处理 - 检测时用
strcmp(argv[i], "--") == 0或std::string(argv[i]) == "--" - 位置参数顺序敏感，比如
cp src dst，不能靠 key 查，得靠索引
Windows 和 Linux 对空格、编码、引号的处理差异真会咬人
Shell 负责拆分参数并去掉外层引号，C++ 层看到的 argv 已是干净字符串。但问题在于：Linux 终端默认 UTF-8，Windows 控制台默认 GBK（或当前系统代码页），如果用户传中文路径，argv 里的字节序列在两边含义不同——这不是你解析器的 bug，是环境层的现实。
另一个坑是 Windows 下 execv 系列函数对含空格路径的处理不如 Linux robust，有时需要手动拼接引号逻辑（虽然标准不建议）。更实际的做法是：接受 argv 的原始字节流，不做假设，把编码转换留给上层业务决定。
- 别在解析器里做
std::wstring_convert或MultiByteToWideChar—— 编码适配应由调用方控制 - 测试时务必用带空格的路径：
"my file.txt"，验证是否被正确拆成单个argv[i] - 跨平台项目若用
getopt_long，Windows 上必须自己补实现或引入兼容层，别指望原生支持
真正难的不是识别 --help，而是当用户输错时，你能指出哪一段非法、为什么非法、该怎么改。比如 --output= 缺值、-vvv 中第三个 v 未定义、--in 匹配到两个候选——这些反馈粒度，决定了你的工具是让人想砸键盘，还是愿意多试一次。
