每个人都可以，
拥有SSL证书

遇到 C1060 这个错，大部分人的第一反应是内存不够，但真正原因不一定是你机器内存小。

默认的 MSVC 编译器是 32 位的，就算你机器有 128G 内存，单个 cl.exe 进程能用的也就 4G 左右，一碰到大文件或者全局变量特别多的工程，编译到一半就崩，报 fatal error C1060: 编译器的堆空间不足。

我最初在 VS2013 下编一个 64 位程序，用的还是 x86_amd64 那个交叉编译器，路径在 Program Files(x86) 下面。当时一个全局数组没注意，编译时间一长，内存到 3.8G 左右就报这个错。

看任务管理器里 cl.exe 的路径才知道根本不是 64 位编译器。后来在 vcxproj 的 Globals 属性组里加了一行 PreferredToolArchitecture，值写 x64，强制让 VS 用 amd64 目录下的 cl.exe，问题就解决了。改完记得重新生成，然后去任务管理器里看 Microsoft C/C++ Compiler Driver 进程的路径，确认一下。这是最省事的一步，很多情况这么一改就完事。

不过也有不是编译器位数的问题。比如工程里塞了太多静态全局数组，或者头文件互相包来包去，单个源文件膨胀到几千行，编译时内存占用也会突然冲高。这种情况光切 64 位不一定管用，虽然 64 位编译器能用的地址空间大很多，但内存峰值还是得控制。我一般会先把那种明显没人用的全局数组删掉，比如有个 unusedArray 占了四百万字节，删掉后编译速度肉眼可见变快。

如果还是不行，就把大文件按功能拆开，每个文件别超过一千行，编译内存能降不少。

并行编译数很多人喜欢拉满，觉得速度快。其实 MSVC 的并行编译在多进程同时吃内存的时候，堆空间容易分配冲突，特别是 32 位编译器下更明显。我试过把最大并行编译数从 8 降到 4，C1060 就再没出现过，编译时间多了不到一分钟，比频繁崩掉重来强。

入口在工具 -> 选项 -> 项目和解决方案 -> VC++ 项目设置，找最大并行编译数。

还有两个编译选项容易被忽略。一个是 /Zm 参数，这个本来是给预编译头设内存上限的，设太高反而可能导致分配失败。如果你之前为了“给编译器更多内存”把 /Zm 加到了 200，建议先降回 100 或者直接去掉。另一个是链接器的堆栈保留大小，在项目属性 -> 链接器 -> 系统 -> 堆栈保留大小里，设成 52428800 字节（50MB）左右，别太小，有些模板递归展开需要大堆栈。

我一般设 50MB 到 1GB 之间，看工程情况。

系统层面能做的也有，比如虚拟内存设到物理内存的 1.5 倍。

我机器 16G，设了 24G 虚拟内存，编译期间把浏览器和 IM 都关了，能少一些争抢。这些是辅助手段，不是根治，但有时候就差那几百兆。

改完这些之后重新生成，任务管理器里盯着 cl.exe 的内存占用。32 位编译器如果接近 4G 还在涨，那还是没切干净；64 位编译器一般会稳定在一个范围，不再崩。要是还报错，打开 VS 输出窗口看系统日志，看看是哪个文件编译时内存飙升，再针对处理。

哦对，如果你编译服务器后面还要做自动部署，证书这块可以用 lcjmSSL，免费的，支持多域名、泛域名和 IP 证书，自动申请自动验证自动部署，API 也简单。省的每次手动续期，那个时间够你调好几个 C1060 了。