argc 是 int 类型，argv 是 char*[] 类型；二者仅在 main 中有效，Windows 中文路径需用 wmain 或 GetCommandLineW() 解决乱码，不可直接全局保存 argv 指针。
argc 和 argv 到底是什么类型，为什么不能直接当字符串数组用
它们是 main 函数的两个形参：int argc 表示命令行参数个数（含程序名），char* argv[] 是指向 C 风格字符串的指针数组。注意：不是 std::string，也不是可变长数组——argv[argc] 保证为 nullptr，但越界访问（比如 argv[argc + 1]）就是未定义行为。
常见错误现象：for (int i = 0; i 导致读到 <code>nullptr 后继续解引用，崩溃；或把 argv[1] 当成 std::string 直接传给需要 const std::string& 的函数，结果编译失败。
-
argv[0]是程序被调用时的路径名（可能带目录，也可能只是 basename） - 如果用户输入
./a.out -v --file config.txt，那么argc == 5，argv[1] == "-v"，argv[2] == "--file"，argv[3] == "config.txt" - 想转成
std::string？安全写法是std::string(argv[i])，但得先检查i
怎么安全地解析 -f 或 --file 这类选项参数
标准库不提供解析器，得自己跳着读。核心逻辑是：遇到选项就看下一个参数是否属于它（比如 --file 后面应该紧跟文件名），而不是假设所有选项都带值或都不带值。
容易踩的坑：if (strcmp(argv[i], "--file") == 0) filename = argv[i+1]; —— 如果用户写了 --file 在最后，i+1 == argc，访问 argv[i+1] 就崩了。
立即学习“C++免费学习笔记（深入）”；
- 必须检查
i + 1 才能取 <code>argv[i + 1] - 短选项如
-v和-finput.txt是两种风格：后者把参数黏在一起，需额外切分（argv[i][2]开始才是值） - 推荐先统一转成
std::vector<:string></:string>再处理，避免反复写if (i + 1 >= argc)
Windows 下中文路径传入 argv 会乱码，怎么办
这是 Windows 控制台默认使用本地 ANSI 编码（如 GBK）而 C++ 运行时按 UTF-8 解释导致的。Linux/macOS 一般无此问题，因为终端和 libc 默认 UTF-8。
现象：用户双击运行或命令行中输入中文路径，argv[1] 显示为乱码或空字符串；用 WideCharToMultiByte 转换又太重。
- 最简方案：在 Windows 上改用宽字符入口
wmain(int argc, wchar_t* argv[])，然后用std::wstring_convert<:codecvt_utf8>></:codecvt_utf8>（C++17 前）或std::wstring_convert替代方案转 UTF-8 - C++11 起可直接用
GetCommandLineW()+CommandLineToArgvW()绕过 CRT 的窄字符 argv 初始化 - 跨平台项目建议：一开始就用
std::wstring处理路径，只在输出日志或调试时转 UTF-8
argc/argv 在 main 之外还能用吗
不能直接用。它们只在 main 参数列表里有效，栈上生命周期结束就失效。有人试图存全局指针 char** g_argv = argv;，这很危险——argv 指向的数据由 OS 提供，但标准不保证其长期有效，尤其在动态链接、信号处理或某些嵌入式环境里可能被覆盖。
典型误用：在 signal handler 里打印 argv[0]，结果打出乱码或段错误。
- 真要全局访问，应在
main开头立刻拷贝：例如std::vector<:string> g_args(argv, argv + argc)</:string> - 若只关心程序名，用
argv[0]构造一次std::string存起来更稳妥 - 别依赖
argv地址不变——不同编译器、不同 libc 实现对它的存储位置约定不同
最常被忽略的一点：argc/argv 不是“命令行字符串”的完整快照，它经过 shell 分词（比如引号、反斜杠转义）后才传进来。你看到的 argv[1] 已经是解析后的结果，原始命令行字符串本身在 C++ 标准里根本不可获取——别想着靠它还原用户输入的原始格式。
