argc是argv数组长度且至少为1，argv[0]仅为启动时首个字符串而非可靠程序名，argv末尾必为nullptr。
main函数的argc/argv参数到底怎么用
标准C++不提供内置命令行解析库，main函数接收的argc和argv就是最底层、最通用的入口。别绕开它去搜“高级库”，先搞懂这两个参数的行为边界，否则用什么封装都容易出错。
常见误解是认为argv[0]一定是可执行文件名——其实它只是启动时传入的第一个字符串，可能为空、可能被篡改、也可能不含路径（比如用execv手动调用时）。真正可靠的程序名得靠/proc/self/exe（Linux）或GetModuleFileName（Windows）获取。
-
argc是argv数组长度，至少为1（即使没传参，argv[0]也存在） -
argv末尾一定为nullptr，可用for (int i = 0; i 安全遍历 - 参数含空格必须用引号包裹，shell负责拆分；C++层看到的已是拆分后的C字符串，不带引号
- 中文路径或参数在Windows控制台默认是GBK编码，Linux终端通常是UTF-8，
argv内容编码取决于环境，不是C++标准规定
手写短选项解析（-h, -v, -o file）的要点
短选项即单字符前缀，如-h、-v、-o filename。手写解析不难，但几个细节决定健壮性：
- 支持连写：把
-hv当作-h和-v两个独立选项，而不是报错 - 选项后紧跟参数时（如
-ofile），要能识别-o后无空格的file；若-o单独出现，则下一个argv项才是值 - 遇到
--停止解析选项，之后所有内容视为位置参数（positional arguments） - 不要假设
argv[i]以"-"开头就一定是选项——可能是负数（如./app -42），需检查是否全由数字和符号组成
示例判断逻辑片段：
立即学习“C++免费学习笔记（深入）”；
if (argv[i][0] == '-' && argv[i][1] != '\0') {
if (argv[i][1] == '-') { /* 长选项或-- */ }
else { /* 短选项，逐字符处理argv[i]+1 */ }
}长选项（--help, --output=FILE）为什么比短选项更难处理
长选项看似直观，但实际解析逻辑更复杂，尤其在等号绑定、缩写匹配和冲突处理上容易翻车。
-
--output=file和--output file都应被接受，但--output=后面不能是空字符串（除非明确允许空值） - GNU风格允许缩写，如
--out匹配--output，但必须确保无歧义；若同时有--output和--override，--out就该报错 - 长选项名通常区分大小写，但有些工具（如Git）对部分选项忽略大小写，这属于业务约定，不是标准行为
- POSIX不定义长选项，所以
getopt_long是GNU扩展，跨平台项目若用它，需在Windows上自行实现或引入兼容层
注意：getopt_long的struct option中val字段若设为0，表示该选项不触发getopt_long返回对应字符，而是通过flag指针写入值——这个机制常被误用导致逻辑混乱。
用第三方库前先想清楚三个问题
cpp-argparse、CLI11、cxxopts这些库确实省事，但引入前得确认它们是否真解决你的痛点，而不是制造新约束。
- 你的程序是否需要支持子命令（如
git commit、git push）？多数轻量库只支持扁平参数，嵌套解析得自己补逻辑 - 是否要求零依赖、单头文件？CLI11是header-only，但cpp-argparse依赖Boost.Filesystem做路径验证，会拖入整个Boost
- 错误提示是否要本地化？几乎所有C++库的报错都是硬编码英文字符串，且不预留i18n接口
另外，所有现代库内部仍基于argc/argv解析，只是做了封装。一旦遇到shell转义异常（如./app "-f \"a b\"" -v）、编码混杂或argv被提前修改的情况，调试链路反而更长——你得先确定是库的bug，还是argv本身已被污染。
