argc是参数个数，argv是C风格字符串数组，argv[0]为程序名，必须先检查argc>1再访问argv[1]，否则段错误；argv生命周期仅限main函数内；用std::string包装需先判空，跨平台注意CRT解析差异。
argc 和 argv 到底怎么用才不崩
直接说结论：argc 是参数个数，argv 是 C 风格字符串数组，argv[0] 是程序名，argv[1] 开始才是用户输入的参数——但很多人一上来就访问 argv[1] 而不检查 argc，结果段错误。
常见错误现象：Segmentation fault (core dumped)，尤其在没传参数时直接解引用 argv[1]；或者把空格分隔的字符串当整体处理（比如 ./a.out "hello world" 中 argv[1] 是 "hello world"，但漏掉引号就变成两个参数）。
- 必须先判断
argc > 1再访问argv[1]，否则未定义行为 -
argv的生命周期只到main返回前，不能存指针到全局或返回给其他函数长期使用 - Windows 下命令行解析由 CRT 预处理，可能和 Linux 行为略有差异（比如对反斜杠、引号的转义），跨平台时别依赖 shell 层面的分词逻辑
std::string 包装 argv 安全吗
安全，但要注意时机：必须在确认 argv[i] 非空后构造 std::string，否则传入空指针会触发 std::string 构造函数抛 std::logic_error（C++11 起）。
使用场景：你想用 std::string::find、substr 或和 STL 算法配合，比手写 strcmp 更自然。
立即学习“C++免费学习笔记（深入）”；
- 推荐写法：
if (argc > 2) std::string arg2(argv[2]); - 禁止写法：
std::string s(argv[5]);（无检查，崩溃风险高） - 性能影响几乎可忽略——
std::string构造是 O(n)，但命令行参数本身就很短，没必要为这点开销手写 C 风格处理
要不要用第三方库比如 argparse 或 cxxopts
小工具（cxxopts 或 argparse 真能省事，而且避免自己写错逻辑。
容易踩的坑：有人把 cxxopts::parse(argc, argv) 放在 try 外，结果参数格式错误时程序直接 abort；还有人忽略 cxxopts::parse() 返回的 ParseResult，没检查 result.count("flag") 就直接取值。
-
cxxopts默认开启异常，建议包在try/catch(cxxopts::exceptions::exception& e)里 - 类型转换失败（如声明
add_options()("port", "port number", cxxopts::value<int>())</int>却传了-port abc）会抛异常，不是静默失败 - 注意
cxxopts对--help的支持是内置的，但不会自动退出，得手动调exit(0)
Windows 下宽字符（wmain）和 Linux 的区别
Windows 命令行原生支持 Unicode，用 wmain(int argc, wchar_t* argv[]) 才能正确读取中文路径或参数；Linux 下 main 的 argv 是 UTF-8 编码字节流，直接当 char* 处理即可。
混淆点在于：即使你在 Windows 用普通 main，CRT 也会把宽字符转成当前代码页（比如 GBK），一旦遇到非本地编码字符就乱码或截断。
- 跨平台项目若需支持中文参数，要么统一用
wmain+MultiByteToWideChar（Windows）+ UTF-8（Linux），要么依赖像boost::program_options这类封装层 - Visual Studio 默认启用
/utf-8后，main的argv仍是窄字符，只是源码字符串编码变了，不影响参数接收 - 别在 Linux 下尝试用
wmain——glibc 不提供该入口，链接会失败
事情说清了就结束。最常被忽略的是：连 argc 检查都跳过，就急着 parse；还有人在 Windows 上硬扛窄字符处理中文路径，然后花半天查为什么 argv[1] 变成问号。
