argc是参数个数，argv是C风格字符串指针数组，argv[0]为程序名，argv[argc]必为nullptr；越界访问会导致未定义行为；判断参数需用if (argc > 1)。
argc 和 argv 到底怎么用才不崩
直接说结论：argc 是参数个数，argv 是指向 C 风格字符串的指针数组，argv[0] 是程序名，argv[argc] 一定是 nullptr —— 这是 C++ 标准保证的，不是约定俗成。越界访问 argv[argc] 或更高索引会触发未定义行为，常见表现是段错误或读到垃圾内存。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
argc至少为 1（哪怕没传任何参数），所以判断参数是否存在必须写if (argc ，而不是 <code>if (!argc) - 不要假设
argv元素非空：用户可能传空字符串参数（如./a.out ""），此时argv[1]是合法的""，不是nullptr - Windows 下命令行解析由 CRT 完成，空格、引号规则和 Linux 不同；跨平台时别手写解析逻辑，优先用
std::string_view(argv[i])封装后再处理
用 std::string 包一层就安全了吗
把 argv[i] 直接构造 std::string 看似稳妥，但容易忽略两个坑：编码和生命周期。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- Linux/macOS 默认 UTF-8，但终端 locale 可能是 GBK 或其他编码；如果参数含中文，
std::string s(argv[1])能存，但后续按 UTF-8 解析会出错 —— 没有银弹，得明确知道运行环境编码，或改用std::wstring+wmain（Windows） -
argv的内存由 OS 分配，生命周期只到main返回前；在全局对象或线程里长期持有std::string没问题，但若用std::string_view(argv[1])并把它存到main外部，就危险了 ——argv所指内存随时可能失效 - 简单场景下，推荐立即转成
std::vector<:string></:string>：std::vector<:string> args(argv, argv + argc)</:string>，之后只操作这个副本
需要解析选项（-h / --help / -o file）怎么办
C++ 标准库不提供命令行选项解析器，硬写容易漏边界情况（比如 -abc 拆成三个单字母选项，还是当一个长选项？--output=file 和 --output file 是否等价？）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 小项目直接用
getopt（POSIX）或getopt_long：它处理短选项、长选项、参数绑定、错误提示都成熟，但 Windows 默认不带，需 MinGW 或自己移植 - 跨平台项目推荐
boost::program_options，但它依赖 Boost，编译重；轻量替代是CLI11（header-only，MIT 许可），支持子命令、类型自动转换、帮助生成 - 别自己写正则匹配
argv：选项顺序、连字符数量、等号分隔这些细节极易出错，且无法兼容 POSIX 语义
argv 中的路径或文件名为什么总出错
用户输入路径时习惯加引号或反斜杠，而 argv 已经是 OS 解析后的结果，你看到的已经是“干净”的字符串 —— 但这个“干净”常被误解。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- Linux 下
./app "/home/user/file.txt"→argv[1]就是/home/user/file.txt（不含引号）；但./app /home/user/file.txt效果一样，所以别去 strip 引号 - Windows 下
app.exe "C: emp est.txt"→argv[1]是C: emp est.txt，注意反斜杠是合法字符，不是转义符；C++ 字符串字面量里才需要双写\ - 路径拼接别用
+拼字符串：用std::filesystem::path（C++17），它自动处理分隔符差异和规范化（path / "sub" / "file"）
最麻烦的其实是 shell 层的 glob 展开：Linux 下 * 会被 shell 替换成匹配文件列表，而 Windows 不展开 —— 如果你的程序要一致行为，得自己做 glob，或者统一禁用（启动时加 setenv("GLOB", "0", 1) 不起作用，得换方案）。
