argc 和 argv 是 main() 函数接收命令行参数的两个形参，非输入函数；argc 表示参数个数，argv 是指向参数字符串数组的指针，首项 argv[0] 为程序名，末项为 NULL。

argc 和 argv 是什么，不是什么

它们不是 C 语言的“输入函数”，也不是用来读取用户键盘输入的工具。argc 和 argv 是 main() 函数的两个参数，只负责接收操作系统在启动程序时传进来的命令行参数——仅此而已。你敲 ./a.out hello world -v，argc 就是 4，argv[0] 是 "./a.out"，argv[1] 是 "hello"，以此类推。

常见错误现象：argv[1] 段错误、argc 突然变小、中文参数乱码（其实是编码问题，不是 argv 本身的问题）

• 别假设 argc > 1 —— 一定要先检查，否则访问 argv[1] 会崩溃
• argv 数组最后一个元素永远是 NULL，但你不该依赖它来遍历；用 argc 控制更安全
• argv[0] 不一定是可执行文件名，可能是任意字符串（比如用 execv() 启动时手动指定的）

怎么安全地解析 argv 中的选项和参数

直接硬写 if (strcmp(argv[1], "-h") == 0) 很快就会失控。真实项目里推荐用 getopt()（POSIX 标准），它专为这事设计，能自动处理 -abc、--verbose、-o file.txt 这类常见模式。

使用场景：写命令行工具、需要支持开关（-v / --version）、带参数的选项（-f config.json）

• getopt() 返回值是匹配到的选项字符，没匹配上就返回 -1；遇到非法选项默认打印错误，加 opterr = 0 可关闭
• 带参数的选项（如 -f filename）要在 optstring 里对应字符后加冒号，比如 "hf:o:"
• optind 是下一个未处理参数的下标，循环结束后，剩余非选项参数从 argv[optind] 开始

argc/argv 在不同平台上的行为差异

Windows 和 Linux 对命令行字符串的拆分逻辑不同，尤其影响含空格或引号的参数。比如你在 Windows 命令提示符里输 app.exe "foo bar" baz，argv[1] 是完整的 "foo bar"；但在某些 Windows GUI 启动方式下，引号可能被提前剥离。

性能 / 兼容性影响：几乎为零——这是启动时一次性拷贝的数据，不涉及运行时开销。但跨平台时要注意：

• 不要在代码里写死路径分隔符，argv 里的路径（如 "data/input.txt"）要统一用 / 或走 PATH_MAX + strchr() 判断
• UTF-8 环境下，Linux 的 argv 是原始字节流；Windows 的 main() 默认是 ANSI 编码，要用 wmain() + wargv 才能可靠拿到 UTF-16
• Shell 的转义规则（比如 \*、$HOME）在参数到达你的程序前已被 shell 处理完毕，argv 里不会看到未展开的 $

容易被忽略的边界情况

最常出问题的地方不在主逻辑，而在启动那一瞬间。

常见错误现象：argc == 1 却仍去读 argv[1]；把 argv[0] 当作“当前目录”；认为 argv 内存可以长期持有（其实生命周期只到 main() 返回）

• argv 指向的字符串存储在栈或进程环境段里，不能 free()，也不建议长期保存指针——如果要持久化，得 strdup() 一份
• 空参数是合法的：./a.out "" "x" → argv[1] 是空字符串，不是 NULL；判断空要用 argv[1][0] == '\0'，不是 !argv[1]
• 某些嵌入式或精简环境（如 freestanding）可能根本不提供 argc/argv，main() 只能写成 void main(void)

真正麻烦的从来不是怎么写 main(int argc, char *argv[])，而是忘了它只是操作系统塞给你的一串字节——没有语义，没有验证，也没有重试机会。