argc 是参数个数（至少为1），argv 是存储参数字符串的指针数组；argv[0]为程序路径，用户参数从 argv[1] 开始；转换为 std::vector 时需手写循环并显式构造 std::string。
main 函数的 argc 和 argv 到底是什么
它们不是“命令行参数库”，而是 C++（更准确说是 C 运行时）传给 main 的两个原生参数：整数 argc 表示参数个数，指针数组 argv 存储每个参数的 C 风格字符串。操作系统在启动程序时就填好这两个值，不依赖任何头文件或额外初始化。
常见错误现象：argv[0] 被误当成用户输入——它其实是可执行文件路径（如 "./a.out" 或 "mytool.exe"），真正第一个用户参数是 argv[1]；argc 为 1 时访问 argv[1] 会越界。
-
argc至少为 1（哪怕没输任何参数） -
argv是以nullptr结尾的指针数组，但别依赖这个，用argc更安全 - 所有
argv[i]都是const char*，不能直接赋给std::string变量再修改底层内存
怎么安全地把 argv 转成 std::vector<:string></:string>
手写循环最可控，避免隐式转换陷阱。不要用 std::vector(argv + 1, argv + argc) ——这会把 const char* 当作迭代器构造，编译都过不去。
使用场景：需要遍历、查找、过滤参数，或后续传给其他接受 std::vector<:string></:string> 的函数。
立即学习“C++免费学习笔记（深入）”；
- 从
i = 1开始遍历，跳过argv[0] - 显式构造
std::string：std::string(arg)，不是std::string(*arg) - 如果参数含空格或引号（比如
"hello world"），shell 已经帮你拆分好了，argv里就是单个元素，不用再解析
std::vector<std::string> args;
for (int i = 1; i < argc; ++i) {
args.push_back(std::string(argv[i]));
}
std::stoi 解析数字参数时为什么常崩
因为 std::stoi 遇到非数字字符（比如空字符串、纯字母、带前导空格）会抛 std::invalid_argument；遇到溢出则抛 std::out_of_range。而命令行参数全是字符串，没人保证它是合法整数。
性能影响：异常抛出开销大，且无法区分“用户输错”和“参数缺失”。
- 先检查
args.size() > 1再取args[1]，否则args[1]访问越界 - 用
std::from_chars（C++17）替代std::stoi：不抛异常、能返回解析位置、支持部分匹配 - 如果必须用
std::stoi，务必包在try/catch里，并检查args[1].empty()
Windows 下中文路径/参数乱码怎么办
根本原因是 Windows 控制台默认用本地 ANSI 编码（如 GBK），而 argv 在 UTF-8 环境下会被错误解释。Linux/macOS 通常无此问题（终端和 argv 均为 UTF-8）。
兼容性影响：用 GetCommandLineW() + CommandLineToArgvW() 可拿到宽字符版本，但得写平台相关代码；跨平台项目建议直接用 boost::program_options 或 CLI11 库接管参数解析。
- 简单项目可加
SetConsoleOutputCP(CP_UTF8)和SetConsoleCP(CP_UTF8)，但只影响输出，不修复argv本身 - Visual Studio 项目需在属性里设“字符集”为“使用 Unicode 字符集”，并改用
wmain入口 - 更稳妥的做法：让用户避免在参数里传中文路径，改用配置文件或环境变量
argc 边界、argv 生命周期、编码差异、数字解析异常，四个点串起来就是高频崩溃现场。尤其在 Windows 上混用中文和调试器启动时，argv 内容可能和你预期完全不同。 
