<p>argc 是 int 类型，表示命令行参数个数（至少为 1）；argv 是 char** 类型，指向 C 风格字符串数组，由操作系统在程序启动时填充，argv[0] 为调用名，argv[argc] 保证为 nullptr。</p>
argc 和 argv 到底是什么类型、从哪来
它们是 main 函数的两个形参，由操作系统在启动程序时填好：整数 argc 表示命令行参数个数（含程序名），指针数组 argv 指向每个参数的 C 风格字符串（char*）。注意：argv[0] 是程序被调用时的路径或名字，不一定是可执行文件名——比如用软链接运行，argv[0] 就是链接名。
常见错误现象：argv[argc] == nullptr 是标准保证的，但有人误以为 argv[argc-1] 之后还能读；越界访问会触发未定义行为，尤其在嵌入式或 ASan 关闭时可能“看起来正常”。
-
argc至少为 1（即使没输参数） -
argv内存由运行时管理，不能free，也不能长期持有指针（除非复制） - Windows 下命令行解析有额外转义规则（如双引号、反斜杠），
argv已经过 shell 或 CRT 解析，不用再手动 split
怎么安全地遍历和解析 argv
别直接写 for (int i = 0; i 然后硬编码处理逻辑。真实项目里参数常带选项（<code>-h、--output=file.txt），手写容易漏边界、混淆位置参数和选项。
推荐做法：先跳过 argv[0]，再用 std::string_view 或 std::string 包装每个参数做比对。避免用 strcmp，C++17 起 std::string_view("foo") == std::string_view(argv[i]) 更简洁安全。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 检查
argc > 1再访问argv[1]，否则崩溃 - 若需提取数值（如端口号），用
std::stoi而非atoi：前者抛异常可捕获，后者遇到非法输入返回 0，无法区分 “0” 和 “解析失败” - 路径类参数（如
argv[2]）建议立刻转成std::filesystem::path，后续路径操作更鲁棒
Windows 下 wmain 和宽字符 argv 的坑
中文路径或含 Unicode 参数时，普通 main 在 Windows 上可能拿到乱码——因为控制台默认用本地 ANSI 编码（如 GBK），而 argv 是按该编码解码的。真正可靠的方式是改用 wmain：
int wmain(int argc, wchar_t* argv[]) { ... }此时 argv 是宽字符，能准确表示任意 Unicode 字符。但要注意：这仅在 Windows 生效；Linux/macOS 不支持 wmain，且 glibc 的 main 原生就是 UTF-8 编码的字节流。
- 用
wmain后，不能再混用printf打印argv[i]，得用wprintf或转std::wstring_convert（C++17 已弃用） - 跨平台项目建议统一用普通
main+ UTF-8 处理，Windows 下启动时调用SetConsoleOutputCP(CP_UTF8)并确保终端字体支持 UTF-8 - 第三方库如
boost.program_options默认只支持窄字符main，换wmain得自己适配
argc/argv 不能替代配置文件或环境变量
命令行参数适合传一次性、显式、用户主动输入的值（如 --verbose、input.txt）。但它不适合：敏感信息（密码）、大量配置项、动态变化的设置。
常见错误：把数据库密码写死在 argv[3] 里，结果 ps aux 或进程快照里直接可见；或者把 20 个开关全塞进命令行，导致启动命令超长难维护。
- 密码、密钥走环境变量（
getenv("DB_PASSWORD")）或专用凭据文件（需权限检查） - 复杂配置用 JSON/TOML 文件 +
argv只传--config=config.toml -
argv解析逻辑别写进核心业务类，抽成独立函数或使用absl::ParseCommandLine/CLI11等轻量库，降低耦合
最易被忽略的一点：argc/argv 是只读的，但有人会尝试修改 argv[i] 内容来“临时修复”参数——这在某些旧系统上可能破坏运行时栈布局，现代编译器通常禁止写 argv 指向的内存。真要改，必须 strdup 或构造新字符串。
