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[])，而是忘了它只是操作系统塞给你的一串字节——没有语义，没有验证，也没有重试机会。
