写代码的时候，很多人没太注意系统或编译器生成的临时文件。直到某天编译突然出错，或者构建失败，才开始怀疑：这些藏在隐藏目录里的“.tmp”、“build”、“obj”之类的文件，真的只是“临时”的，不会影响编译？
临时文件从哪来
当你运行一次编译，比如用gcc、javac，或者前端的webpack、vite，工具并不会直接把源码变成最终产物。中间会经历预处理、语法分析、生成中间代码等多个步骤。这些过程中产生的中间结果，通常会被存成临时文件，放在系统的缓存目录或项目下的临时文件夹里。
比如，C++ 编译时，每个 .cpp 文件会先被预处理成 .i 文件，再编译成 .s（汇编），然后是 .o（目标文件），最后链接。这些中间产物如果不清理，就会堆积下来。
什么时候会出问题
大多数情况下，现代编译系统能正确管理临时文件，旧的会被覆盖或删除。但某些场景下，它们确实会造成麻烦。
一种常见情况是磁盘空间不足。如果临时目录长期不清理，尤其是大型项目频繁编译，可能积累几GB甚至几十GB的数据。当系统盘快满了，编译器可能因为无法创建新的临时文件而报错，提示“no space left on device”或者“could not create temporary file”。
另一个问题是文件残留导致的“幽灵错误”。比如你改了一个头文件，但编译器因为某种原因没检测到变更，继续使用旧的临时目标文件进行链接，结果程序行为异常。这种情况在增量编译中更容易出现，特别是Makefile规则写得不够严谨，或者IDE缓存机制出问题时。
实际例子
有位开发者在Linux上用GCC编译一个嵌入式项目，每次修改config.h后，部分模块似乎没重新编译。查了半天发现，是因为某个子目录下的.o文件权限被设为只读，编译器跳过了更新，直接用了旧的临时目标文件。手动删掉obj目录后问题消失。
怎么避免干扰
最直接的办法是定期清理。很多构建系统提供 clean 命令：
make clean
npm run build -- --clean
gradle clean执行这些命令会删掉临时输出目录，确保下次编译从干净状态开始。CI/CD 流水线中也常在构建前加一步清除操作，避免历史残留影响结果。
还可以调整临时文件路径。比如把 TMPDIR 指向空间更大的分区：
export TMPDIR=/home/user/tmp
javac Main.java这样既避免系统盘被占满，也能提升I/O性能，特别是用SSD做临时存储时。
IDE 的“小聪明”有时也坏事
像Visual Studio、IntelliJ这类工具为了加快编译速度，会缓存大量中间结果。有时候你明明改了代码，但它“以为”不需要重编，结果运行起来还是老样子。这时候清一下IDE的缓存目录，比如 .idea 或 .vs，往往能解决问题。
有些团队在协作开发时，会把 build、target 这类目录加入 .gitignore，就是防止临时文件被提交，也避免不同环境之间的冲突。你不希望同事因为你的临时文件编译失败吧？
结论不是重点，习惯才是
临时文件本身不会“主动”破坏编译，但它们是潜在的风险点。特别是在长期运行的开发环境中，积累的旧数据可能让构建过程变得不可靠。养成定期清理、使用 clean 构建、关注磁盘状态的习惯，比等到出问题再排查更省心。