主进程与启动进程间的参数传递不对称性问题

这问题问到点子上了！背后其实是Windows的历史遗留、兼容性考量，还有程序间解析规则差异共同作用的结果，咱们掰开揉碎了说：

为什么启动接口用单个字符串而非参数数组？ #

• 历史兼容性的硬要求：Windows的进程启动机制是从DOS时代一脉相承来的。在DOS里，命令行就是个单一的字符串，所有参数都塞在里面，程序得自己负责拆分。后来Windows升级到32位、64位，但为了兼容海量的DOS和早期Windows程序，CreateProcess这类核心接口必须沿用这个设计——要是突然改成数组形式，那些依赖自己解析命令行的老程序直接就会崩掉或者行为错乱，这代价实在太大。
• 程序解析规则的多样性：不同程序对命令行参数的解析逻辑可能千差万别。比如有些程序对引号的处理、空格的识别有自己的特殊规则，甚至还有不少程序根本不用标准C/C++运行时库（也就是main(int argc, char** argv)那套）来拆分参数。如果系统提供数组形式的接口，就意味着系统要替你把数组拼成一个符合目标程序预期的字符串，但系统根本没法预知每个程序的解析规则，反而容易帮倒忙。
• C/C++运行时的中间转换：其实你写的main(int argc, char** argv)并不是Windows系统直接调用的——这是C/C++运行时库（CRT）做的“翻译”工作。系统只会把完整的命令行字符串传给程序的真正入口（比如WinMain或者_tmain），然后CRT再把这个字符串拆分成argc和argv数组给你用。所以从系统底层来看，传递单一字符串是最通用、最不会出问题的方式。

为什么必须自己处理参数转义？ #

• 目标程序的拆分依赖字符串格式：既然最终传给目标程序的是一个完整的字符串，你就得确保这个字符串能被它正确拆成你想要的各个参数。比如参数里有空格（像路径C:\Program Files\MyTool.exe），你必须用双引号把整个路径括起来，不然目标程序会把C:\Program和Files\MyTool.exe当成两个独立参数，直接乱套。
• 没有统一的“标准”解析逻辑：虽然大多数C/C++程序用CRT的解析规则，但不是所有程序都遵循这套。比如一些脚本解释器、自定义工具，可能对反斜杠、引号的转义有自己的规则。这时候就得你手动处理转义细节——比如路径里本身有双引号，你得用反斜杠把它转义成\"，不然目标程序会把它当成参数的结束符。系统没法替你做这件事，因为它不知道目标程序会怎么解读这些特殊字符。

内容的提问来源于stack exchange，提问作者Thomas S.