你写了三千行代码，源代按下编译键，编译屏幕上弹出一行红字：error: expected ';' before '}' token。什情你盯着看了半天，源代觉得那个分号明明就在那里。编译这种事每个程序员都遇到过，什情但“源代码未编译”这件事，源代远不止报错那么简单。编译

最常见的什情情况是编译器压根没跑起来。比如你刚拉下一份开源项目，源代README里写着“make即可”，编译结果一执行，什情提示找不到cmake。源代或者你用的编译是Windows，项目却依赖autotools那套Unix工具链。什情这时候源代码完好无损，只是编译环境没搭对。我见过一个同事折腾了一下午，最后发现是PATH里少了/usr/local/bin——编译器装是装了，系统不知道它在哪。

另一种情况更隐蔽：编译器跑了，但生成的目标文件不是你要的。比如你改了头文件里的一个宏定义，按说所有包含它的源文件都该重新编译。但Makefile里依赖关系写漏了，只重新编译了直接引用宏的那个.c文件，其他文件还用着旧的目标文件链接。最终二进制跑出来的行为跟源码对不上。你对着源码 debug 到天亮，问题其实藏在构建系统里。这种“未编译”不是没编译，是编译得不完整、不一致。

还有一类跟代码本身无关。磁盘满了。听起来很蠢，但真的常见。编译一个大型C++项目，中间文件动辄几十GB，/tmp分区先撑不住。gcc报的错五花八门，有时候是“cannot write output file”，有时候直接段错误。你以为是代码写崩了编译器，其实是写崩了文件系统。清理一下，重新make，世界安静了。

权限问题也值得单说。在Linux下用root编译过一次之后，生成的.o文件属主是root。下次你以普通用户身份make，编译器想覆盖那些.o文件，权限不够。报错信息可能是“Permission denied”，也可能被make吞掉，只显示“nothing to be done for 'all'”。你以为编译过了，其实用的是上次的旧产物。这种坑在共享开发机上特别多，每个人都有自己的故事。

交叉编译的场景下，“未编译”的含义又不一样。你在x86机器上给ARM板子编译程序，工具链是arm-linux-gnueabihf-gcc。如果你不小心用了本机的gcc，编译也能过，链接也能过，但生成的二进制在板子上跑不起来——格式不对。这时候源代码“编译”了，只是编译成了错误的架构。严格说，对于目标平台而言，它从未被正确编译过。

头文件路径也是老生常谈。你#include <openssl/ssl.h>，编译器说找不到。你明明装了libssl-dev。问题在于头文件在/usr/include/openssl/下，而你的编译命令没加-I/usr/include。或者更绕的，你装了多个版本的OpenSSL，pkg-config返回的路径指向了一个你不想要的那个。源代码没动，编译命令的搜索路径变了，结果就是编译失败或者链接到错误的库。

最让人抓狂的是那种“有时编得过有时编不过”的情况。并行make -j8的时候，两个目标文件同时依赖同一个中间产物，但Makefile没写对依赖顺序。单线程make没事，多线程就随机失败。你重跑一次，过了。再跑一次，又挂了。源代码没问题，构建脚本有竞态条件。这种bug比代码里的空指针还难查，因为它不可复现。

说到底，“源代码未编译”这个状态，很少是源代码本身的问题。它更多是环境、工具链、构建脚本、文件系统、权限、甚至运气的问题。写代码只是整个流程里最可控的一环。真正消耗时间的，往往是那些跟代码逻辑无关的破事。编译不过的时候，先别急着改代码，看看编译器到底有没有在跑、跑的是不是你想的那个、跑的时候有没有权限写文件。这几个问题问完，大半的“未编译”就现形了。