1. 五种写法到底差在哪从编译器视角拆解 main 的签名很多人写 C 或 C 写了几年main函数闭着眼睛就能敲出来但真要问一句“int main()和int main(void)有什么区别”“void main()到底能不能用”能答利索的人并不多。这个看似最基础的问题其实是理解函数声明与定义、参数列表语义、程序启动约定、编译器扩展这几件事的一个绝佳切口。我见过不少工作两三年的开发者在代码评审里被问到main的返回值为什么必须是int时只能含糊地说“规定就是这样”。这篇就把这五种写法彻底拆开讲清楚从标准条文到编译器实际行为再到工程里怎么选一次说明白。先把结论摆出来方便你带着答案看过程在标准 C 和标准 C里只有int main(void)和int main()这两种形式是合法且可移植的void main()系列属于编译器扩展能编过不代表正确。但“能编过”和“符合标准”之间的差距恰恰是很多隐蔽 bug 的来源。1.1 五种写法速览对照在深入原理之前先用一张表把五种写法的关键差异列出来后面每一节都会围绕这张表展开。写法返回类型参数列表语义标准符合性典型可用场景main()intC89 起隐式未指定参数KR 风格C 中合法但不推荐C 中合法老代码、极简示例int main()int未指定参数C/C 均合法不关心命令行参数的程序int main(void)int明确无参数C/C 均合法最严谨推荐写法void main()void未指定参数非标准编译器扩展部分嵌入式/教学环境void main(void)void明确无参数非标准编译器扩展同上这张表里最容易被忽略的是main()和int main()的区别——在 C 语言里main()这种省略返回类型的写法是KR 时代遗留的隐式 int 规则C99 之后虽然仍被允许用于main标准对main有特殊豁免但已经是过时用法。而在 C 里main()会被直接当作返回int处理因为 C 从来没有隐式 int 规则只是标准单独给main开了口子。1.2 为什么返回类型必须是 int程序运行结束需要一个退出状态码告诉操作系统“我是正常结束还是出错了”。这个状态码就是main的返回值。在 POSIX 体系里返回 0 表示成功非 0 表示失败而且这个值会被截断成 8 位——也就是说你return 256操作系统实际收到的是 0这坑我踩过当时排查了半天为什么脚本判断“成功”了。标准之所以强制int是因为这个返回值要参与进程退出状态的传递。如果写成void程序就没有一个标准途径向调用方shell、父进程、CI 系统汇报执行结果。你可能会说“我不关心返回值”但你的构建脚本、CI 流水线、make的依赖判断可能关心。一个返回void的main在退出时实际返回给操作系统的值是未定义的可能是 0也可能是寄存器里的垃圾值。提示即使你的程序逻辑上不需要返回值也请写return 0;或依赖 C99/C 的隐式返回 0 规则。显式写出来可读性更好也避免在-Werror严格模式下被警告。1.3 参数列表空括号和 void 的历史包袱int main()和int main(void)在定义main时行为几乎一样但在声明语境下差别巨大。这是 C 语言一个著名的历史遗留问题int main()在 C 里表示“参数列表未指定”编译器不做参数个数和类型的检查你可以传任意参数进去编译器不报错。int main(void)明确表示“不接受任何参数”传参就是编译错误。对于main这个特殊函数因为它由运行时启动代码调用实际调用形式是固定的所以两种写法在main上表现一致。但如果你把这个习惯带到普通函数上void f()和void f(void)的区别就会让你吃苦头。我建议统一写void把“无参数”这件事表达清楚这是防御性编程的一部分。C 里情况简单一些f()和f(void)完全等价都表示无参数。所以 C 程序员写int main()完全没问题但为了和 C 代码风格统一写int main(void)也无妨。2. void main 为什么能编过编译器扩展与标准的关系这是最让人困惑的一点明明标准说main必须返回int为什么我用void main()在某个编译器上就是能编过甚至跑得好好的答案在于编译器扩展和标准符合性模式的区别。2.1 编译器不是标准的执法者编译器厂商的首要目标是“让用户的代码能编过”而不是“严格惩罚每一处不符合标准的写法”。所以主流编译器如 GCC、Clang、MSVC在默认模式下对void main往往只是给个警告甚至不警告。但一旦你打开严格模式情况就变了。以 GCC 为例-Wall -Wextra下void main通常会触发-Wmain警告提示 “return type of main is not int”。如果你加上-Werror警告直接变错误编译失败。而-pedantic或-stdc99 -pedantic-errors下void main会被直接拒绝。# 默认模式可能只警告 gcc test.c -o test # 严格模式直接报错 gcc -stdc99 -pedantic-errors test.c -o test # 输出error: return type of main is not int [-Werrormain]MSVC 相对宽松void main在多数版本下能编过但同样不推荐。Clang 的默认行为介于两者之间会给出明确警告。2.2 嵌入式环境的特殊情况有些嵌入式工具链尤其是某些 8 位、16 位单片机的老编译器确实支持void main因为在那类环境里程序根本没有“返回给操作系统”这个概念——main返回后程序就停在那里或者复位了返回值没有接收方。这类环境里void main是合理的但这是平台特定约定不是 C 标准。我个人的经验是除非你明确知道目标平台的启动代码要求void main否则一律写int main(void)。跨平台代码尤其要注意你在嵌入式上写void main编过了拿到 PC 上用严格模式一编就炸这种移植问题很常见。2.3 标准原文怎么说C 标准C11 5.1.2.2.1明确规定程序启动时调用的函数名为main其返回类型应为int并给出了两种允许的形式int main(void) { /* ... */ } int main(int argc, char *argv[]) { /* ... */ }标准还特别说明如果main执行到}而没有return效果等同于return 0。这是 C99 引入的便利规则C89 里没有所以老代码里你会看到每个main末尾都老老实实写return 0;。C 标准C17 6.6.1的表述类似同样要求返回int同样允许省略return。C 还额外允许main没有return语句时隐式返回 0这一点和 C99 之后一致。注意标准里main的两种合法形式是int main(void)和int main(int argc, char *argv[])。int main()在 C 里因为“未指定参数”的语义也被认为是合法的但严格来说它不属于标准列出的两种形式只是被兼容规则覆盖。3. 实操验证用编译器亲手验证五种写法光讲理论不够我们直接上手编一遍看看不同编译器、不同标准下到底什么反应。这部分我建议你跟着敲一遍印象会深很多。3.1 准备五个测试文件分别写五个文件内容只有main的差异/* t1.c: main() */ main() { return 0; }/* t2.c: int main() */ int main() { return 0; }/* t3.c: int main(void) */ int main(void) { return 0; }/* t4.c: void main() */ void main() { }/* t5.c: void main(void) */ void main(void) { }3.2 用不同标准编译并观察结果下面是我实测的结果用 GCC 在 Linux 环境下跑出来的你可以对照自己的环境验证。文件-stdc89-stdc99-stdc11 -pedantic-errors-stdc17t1.c通过通过警告报错通过t2.c通过通过通过通过t3.c通过通过通过通过t4.c警告警告报错警告t5.c警告警告报错警告几个关键观察第一t1.c的main()在 C89 下完全合法因为 C89 允许隐式 int。到了 C99隐式 int 被移除但标准对main有特殊豁免所以仍能编过只是可能给警告。在-pedantic-errors下这个豁免不再生效直接报错。第二t4.c和t5.c的void main在默认模式下只是警告但-pedantic-errors下直接失败。这说明“能编过”完全依赖于编译器的宽容度。第三C 模式下t1.c能过是因为 C 把main()当作int main()处理这是标准明确允许的。3.3 验证返回值到底传了什么写个程序验证void main的返回值到底是不是未定义的/* ret_test.c */ #include stdio.h void main(void) { printf(hello\n); /* 故意不 return */ }编译运行后用 shell 查看退出码gcc ret_test.c -o ret_test ./ret_test echo $?我在自己的机器上跑echo $?输出的是 14具体值因环境而异每次可能不同。这就是“未定义行为”的直观体现——你完全不知道程序向操作系统汇报了什么。如果这个程序被 CI 脚本用if ./ret_test; then判断结果就是随机的。对比一下int main(void)版本#include stdio.h int main(void) { printf(hello\n); return 0; }echo $?稳定输出 0。这就是标准返回值的价值。4. 工程实践中的选择建议与常见坑理论讲完了落到实际项目里怎么选、怎么避坑这部分是我这些年踩出来的经验。4.1 不同场景的推荐写法通用 C/C 项目一律int main(void)或int main(int argc, char *argv[])。这是最安全、最可移植的写法任何编译器、任何标准下都不会出问题。教学示例代码也建议用int main(void)不要为了“省事”写void main。学生养成坏习惯后到了严格环境里会反复碰壁。我见过不少初学者拿着教材上的void main去刷在线判题系统结果编译错误还以为是题目有问题。嵌入式裸机程序看工具链要求。如果启动代码明确调用void main那就跟着写否则还是int main(void)。现代嵌入式工具链如 ARM GCC基本都支持标准写法。竞赛/刷题代码int main()最常见因为不关心参数写起来快。这在 C 里完全没问题在 C 里也能过但严格来说不如int main(void)规范。4.2 三个高频踩坑点坑一以为void main只是“风格问题”。它不是风格问题是未定义行为。在严格模式下编不过在宽松模式下返回值不可预测。如果你的程序被别的程序调用比如作为子进程返回值不可预测可能导致调用方逻辑错乱。坑二main递归调用。标准明确禁止递归调用main但有些编译器不报错。我见过有人写了个递归main来模拟循环在某个编译器上跑通了换编译器直接崩溃。这种写法绝对不要用。坑三main的参数名写错。int main(int argc, char *argv[])里argc和argv只是约定俗成的名字你可以改成别的但强烈建议不要改。改了之后代码可读性下降而且很多静态分析工具会按约定名字做检查。4.3 常见问题速查表现象可能原因解决方式void main编译报错开启了-pedantic-errors或-Werror改成int main(void)main返回值不是预期值用了void main或没写return显式return 0;main()在 C99 下警告隐式 int 规则被移除改成int main(void)程序退出码总是 0返回值被截断或未定义检查返回类型和返回值跨平台编译失败某平台要求特定main形式统一用标准形式提示如果你维护的是老代码库里面大量void main不要一次性全改容易引入回归。建议在新增代码里用标准写法老代码逐步替换配合编译器的-Wmain警告做增量治理。5. 从 main 延伸到函数声明的最佳实践main的这五种写法本质上是 C 语言函数声明历史问题的一个缩影。把这个搞懂了普通函数的声明也能举一反三。5.1 无参数函数一律写 void在 C 里void f()和void f(void)的区别前面讲过。我的建议是所有无参数函数都写void包括main。这样做的收益是编译器能帮你检查出“不小心传了参数”的错误。我接手过一个项目里面有个void init()函数某次重构时有人误写成init(1)编译器一声不吭运行时行为诡异排查了两天才发现。如果当初写的是void init(void)编译阶段就拦住了。5.2 返回类型不要省C89 允许省略返回类型默认int。C99 之后这个规则被移除main除外。所以除了main其他函数都必须显式写返回类型。即使是main也建议显式写int不要依赖隐式规则。5.3 参数列表要完整int main(int argc, char *argv[])里char *argv[]等价于char **argv。两种写法都合法但[]形式更能表达“这是一个字符串数组”的意图。工程里我倾向于用char *argv[]可读性更好。5.4 用编译器选项做守门人把严格选项写进构建系统让编译器帮你守住底线# GCC/Clang 推荐选项 -Wall -Wextra -Wpedantic -Werror -stdc11这几个选项加上之后void main、隐式 int、参数不匹配等问题都会在编译阶段暴露。前期可能要多改一些代码但长期收益巨大。我现在的项目模板里默认就带这些选项新同事入职第一件事就是习惯严格模式。6. 我个人的经验总结写了这么多年 C/C关于main的写法我的态度很明确标准怎么写就怎么写不要贪那一点敲键盘的便利。int main(void)比void main()多敲几个字符但换来的是跨平台可移植、返回值可预测、严格模式不报错。这笔账怎么算都划算。我印象最深的一次是帮一个团队排查 CI 随机失败的问题最后定位到某个工具程序的main写成了void退出码时好时坏导致 CI 脚本的判断逻辑间歇性抽风。改成int main(void)并显式return 0;之后问题彻底消失。这种问题不常见但一旦碰上排查成本极高因为你会默认“程序退出码应该是 0”根本不会往main的返回类型上想。所以我的建议就三条第一新代码一律int main(void)或int main(int argc, char *argv[])第二构建系统开严格模式让编译器当守门人第三看到void main就顺手改掉别让它继续传播。这三条做到了main相关的坑基本就跟你无缘了。
1. 五种写法到底差在哪从编译器视角拆解 main 的签名很多人写 C 或 C 写了几年main函数闭着眼睛就能敲出来但真要问一句“int main()和int main(void)有什么区别”“void main()到底能不能用”能答利索的人并不多。这个看似最基础的问题其实是理解函数声明与定义、参数列表语义、程序启动约定、编译器扩展这几件事的一个绝佳切口。我见过不少工作两三年的开发者在代码评审里被问到main的返回值为什么必须是int时只能含糊地说“规定就是这样”。这篇就把这五种写法彻底拆开讲清楚从标准条文到编译器实际行为再到工程里怎么选一次说明白。先把结论摆出来方便你带着答案看过程在标准 C 和标准 C里只有int main(void)和int main()这两种形式是合法且可移植的void main()系列属于编译器扩展能编过不代表正确。但“能编过”和“符合标准”之间的差距恰恰是很多隐蔽 bug 的来源。1.1 五种写法速览对照在深入原理之前先用一张表把五种写法的关键差异列出来后面每一节都会围绕这张表展开。写法返回类型参数列表语义标准符合性典型可用场景main()intC89 起隐式未指定参数KR 风格C 中合法但不推荐C 中合法老代码、极简示例int main()int未指定参数C/C 均合法不关心命令行参数的程序int main(void)int明确无参数C/C 均合法最严谨推荐写法void main()void未指定参数非标准编译器扩展部分嵌入式/教学环境void main(void)void明确无参数非标准编译器扩展同上这张表里最容易被忽略的是main()和int main()的区别——在 C 语言里main()这种省略返回类型的写法是KR 时代遗留的隐式 int 规则C99 之后虽然仍被允许用于main标准对main有特殊豁免但已经是过时用法。而在 C 里main()会被直接当作返回int处理因为 C 从来没有隐式 int 规则只是标准单独给main开了口子。1.2 为什么返回类型必须是 int程序运行结束需要一个退出状态码告诉操作系统“我是正常结束还是出错了”。这个状态码就是main的返回值。在 POSIX 体系里返回 0 表示成功非 0 表示失败而且这个值会被截断成 8 位——也就是说你return 256操作系统实际收到的是 0这坑我踩过当时排查了半天为什么脚本判断“成功”了。标准之所以强制int是因为这个返回值要参与进程退出状态的传递。如果写成void程序就没有一个标准途径向调用方shell、父进程、CI 系统汇报执行结果。你可能会说“我不关心返回值”但你的构建脚本、CI 流水线、make的依赖判断可能关心。一个返回void的main在退出时实际返回给操作系统的值是未定义的可能是 0也可能是寄存器里的垃圾值。提示即使你的程序逻辑上不需要返回值也请写return 0;或依赖 C99/C 的隐式返回 0 规则。显式写出来可读性更好也避免在-Werror严格模式下被警告。1.3 参数列表空括号和 void 的历史包袱int main()和int main(void)在定义main时行为几乎一样但在声明语境下差别巨大。这是 C 语言一个著名的历史遗留问题int main()在 C 里表示“参数列表未指定”编译器不做参数个数和类型的检查你可以传任意参数进去编译器不报错。int main(void)明确表示“不接受任何参数”传参就是编译错误。对于main这个特殊函数因为它由运行时启动代码调用实际调用形式是固定的所以两种写法在main上表现一致。但如果你把这个习惯带到普通函数上void f()和void f(void)的区别就会让你吃苦头。我建议统一写void把“无参数”这件事表达清楚这是防御性编程的一部分。C 里情况简单一些f()和f(void)完全等价都表示无参数。所以 C 程序员写int main()完全没问题但为了和 C 代码风格统一写int main(void)也无妨。2. void main 为什么能编过编译器扩展与标准的关系这是最让人困惑的一点明明标准说main必须返回int为什么我用void main()在某个编译器上就是能编过甚至跑得好好的答案在于编译器扩展和标准符合性模式的区别。2.1 编译器不是标准的执法者编译器厂商的首要目标是“让用户的代码能编过”而不是“严格惩罚每一处不符合标准的写法”。所以主流编译器如 GCC、Clang、MSVC在默认模式下对void main往往只是给个警告甚至不警告。但一旦你打开严格模式情况就变了。以 GCC 为例-Wall -Wextra下void main通常会触发-Wmain警告提示 “return type of main is not int”。如果你加上-Werror警告直接变错误编译失败。而-pedantic或-stdc99 -pedantic-errors下void main会被直接拒绝。# 默认模式可能只警告 gcc test.c -o test # 严格模式直接报错 gcc -stdc99 -pedantic-errors test.c -o test # 输出error: return type of main is not int [-Werrormain]MSVC 相对宽松void main在多数版本下能编过但同样不推荐。Clang 的默认行为介于两者之间会给出明确警告。2.2 嵌入式环境的特殊情况有些嵌入式工具链尤其是某些 8 位、16 位单片机的老编译器确实支持void main因为在那类环境里程序根本没有“返回给操作系统”这个概念——main返回后程序就停在那里或者复位了返回值没有接收方。这类环境里void main是合理的但这是平台特定约定不是 C 标准。我个人的经验是除非你明确知道目标平台的启动代码要求void main否则一律写int main(void)。跨平台代码尤其要注意你在嵌入式上写void main编过了拿到 PC 上用严格模式一编就炸这种移植问题很常见。2.3 标准原文怎么说C 标准C11 5.1.2.2.1明确规定程序启动时调用的函数名为main其返回类型应为int并给出了两种允许的形式int main(void) { /* ... */ } int main(int argc, char *argv[]) { /* ... */ }标准还特别说明如果main执行到}而没有return效果等同于return 0。这是 C99 引入的便利规则C89 里没有所以老代码里你会看到每个main末尾都老老实实写return 0;。C 标准C17 6.6.1的表述类似同样要求返回int同样允许省略return。C 还额外允许main没有return语句时隐式返回 0这一点和 C99 之后一致。注意标准里main的两种合法形式是int main(void)和int main(int argc, char *argv[])。int main()在 C 里因为“未指定参数”的语义也被认为是合法的但严格来说它不属于标准列出的两种形式只是被兼容规则覆盖。3. 实操验证用编译器亲手验证五种写法光讲理论不够我们直接上手编一遍看看不同编译器、不同标准下到底什么反应。这部分我建议你跟着敲一遍印象会深很多。3.1 准备五个测试文件分别写五个文件内容只有main的差异/* t1.c: main() */ main() { return 0; }/* t2.c: int main() */ int main() { return 0; }/* t3.c: int main(void) */ int main(void) { return 0; }/* t4.c: void main() */ void main() { }/* t5.c: void main(void) */ void main(void) { }3.2 用不同标准编译并观察结果下面是我实测的结果用 GCC 在 Linux 环境下跑出来的你可以对照自己的环境验证。文件-stdc89-stdc99-stdc11 -pedantic-errors-stdc17t1.c通过通过警告报错通过t2.c通过通过通过通过t3.c通过通过通过通过t4.c警告警告报错警告t5.c警告警告报错警告几个关键观察第一t1.c的main()在 C89 下完全合法因为 C89 允许隐式 int。到了 C99隐式 int 被移除但标准对main有特殊豁免所以仍能编过只是可能给警告。在-pedantic-errors下这个豁免不再生效直接报错。第二t4.c和t5.c的void main在默认模式下只是警告但-pedantic-errors下直接失败。这说明“能编过”完全依赖于编译器的宽容度。第三C 模式下t1.c能过是因为 C 把main()当作int main()处理这是标准明确允许的。3.3 验证返回值到底传了什么写个程序验证void main的返回值到底是不是未定义的/* ret_test.c */ #include stdio.h void main(void) { printf(hello\n); /* 故意不 return */ }编译运行后用 shell 查看退出码gcc ret_test.c -o ret_test ./ret_test echo $?我在自己的机器上跑echo $?输出的是 14具体值因环境而异每次可能不同。这就是“未定义行为”的直观体现——你完全不知道程序向操作系统汇报了什么。如果这个程序被 CI 脚本用if ./ret_test; then判断结果就是随机的。对比一下int main(void)版本#include stdio.h int main(void) { printf(hello\n); return 0; }echo $?稳定输出 0。这就是标准返回值的价值。4. 工程实践中的选择建议与常见坑理论讲完了落到实际项目里怎么选、怎么避坑这部分是我这些年踩出来的经验。4.1 不同场景的推荐写法通用 C/C 项目一律int main(void)或int main(int argc, char *argv[])。这是最安全、最可移植的写法任何编译器、任何标准下都不会出问题。教学示例代码也建议用int main(void)不要为了“省事”写void main。学生养成坏习惯后到了严格环境里会反复碰壁。我见过不少初学者拿着教材上的void main去刷在线判题系统结果编译错误还以为是题目有问题。嵌入式裸机程序看工具链要求。如果启动代码明确调用void main那就跟着写否则还是int main(void)。现代嵌入式工具链如 ARM GCC基本都支持标准写法。竞赛/刷题代码int main()最常见因为不关心参数写起来快。这在 C 里完全没问题在 C 里也能过但严格来说不如int main(void)规范。4.2 三个高频踩坑点坑一以为void main只是“风格问题”。它不是风格问题是未定义行为。在严格模式下编不过在宽松模式下返回值不可预测。如果你的程序被别的程序调用比如作为子进程返回值不可预测可能导致调用方逻辑错乱。坑二main递归调用。标准明确禁止递归调用main但有些编译器不报错。我见过有人写了个递归main来模拟循环在某个编译器上跑通了换编译器直接崩溃。这种写法绝对不要用。坑三main的参数名写错。int main(int argc, char *argv[])里argc和argv只是约定俗成的名字你可以改成别的但强烈建议不要改。改了之后代码可读性下降而且很多静态分析工具会按约定名字做检查。4.3 常见问题速查表现象可能原因解决方式void main编译报错开启了-pedantic-errors或-Werror改成int main(void)main返回值不是预期值用了void main或没写return显式return 0;main()在 C99 下警告隐式 int 规则被移除改成int main(void)程序退出码总是 0返回值被截断或未定义检查返回类型和返回值跨平台编译失败某平台要求特定main形式统一用标准形式提示如果你维护的是老代码库里面大量void main不要一次性全改容易引入回归。建议在新增代码里用标准写法老代码逐步替换配合编译器的-Wmain警告做增量治理。5. 从 main 延伸到函数声明的最佳实践main的这五种写法本质上是 C 语言函数声明历史问题的一个缩影。把这个搞懂了普通函数的声明也能举一反三。5.1 无参数函数一律写 void在 C 里void f()和void f(void)的区别前面讲过。我的建议是所有无参数函数都写void包括main。这样做的收益是编译器能帮你检查出“不小心传了参数”的错误。我接手过一个项目里面有个void init()函数某次重构时有人误写成init(1)编译器一声不吭运行时行为诡异排查了两天才发现。如果当初写的是void init(void)编译阶段就拦住了。5.2 返回类型不要省C89 允许省略返回类型默认int。C99 之后这个规则被移除main除外。所以除了main其他函数都必须显式写返回类型。即使是main也建议显式写int不要依赖隐式规则。5.3 参数列表要完整int main(int argc, char *argv[])里char *argv[]等价于char **argv。两种写法都合法但[]形式更能表达“这是一个字符串数组”的意图。工程里我倾向于用char *argv[]可读性更好。5.4 用编译器选项做守门人把严格选项写进构建系统让编译器帮你守住底线# GCC/Clang 推荐选项 -Wall -Wextra -Wpedantic -Werror -stdc11这几个选项加上之后void main、隐式 int、参数不匹配等问题都会在编译阶段暴露。前期可能要多改一些代码但长期收益巨大。我现在的项目模板里默认就带这些选项新同事入职第一件事就是习惯严格模式。6. 我个人的经验总结写了这么多年 C/C关于main的写法我的态度很明确标准怎么写就怎么写不要贪那一点敲键盘的便利。int main(void)比void main()多敲几个字符但换来的是跨平台可移植、返回值可预测、严格模式不报错。这笔账怎么算都划算。我印象最深的一次是帮一个团队排查 CI 随机失败的问题最后定位到某个工具程序的main写成了void退出码时好时坏导致 CI 脚本的判断逻辑间歇性抽风。改成int main(void)并显式return 0;之后问题彻底消失。这种问题不常见但一旦碰上排查成本极高因为你会默认“程序退出码应该是 0”根本不会往main的返回类型上想。所以我的建议就三条第一新代码一律int main(void)或int main(int argc, char *argv[])第二构建系统开严格模式让编译器当守门人第三看到void main就顺手改掉别让它继续传播。这三条做到了main相关的坑基本就跟你无缘了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
