Composer临时文件（如installed.json.tmp）不影响OPcache，因其无PHP语法、不被require、不进入autoload映射，OPcache仅缓存实际加载的正式文件（如autoload_static.php）。
Composer临时文件（如vendor/composer/installed.json.tmp）不影响OPcache
Composer在执行install或update时会生成带.tmp后缀的临时文件（例如installed.json.tmp、autoload_static.php.tmp），这些只是写入过程中的中间产物，不会被PHP加载，也**完全不进入OPcache缓存路径**。
OPcache只缓存实际被include、require或自动加载机制触发的PHP脚本文件——而临时文件既无PHP语法结构，也不会出现在autoload_classmap.php或PSR映射中。即使它们和正式文件同目录，只要没被require_once调用，OPcache就根本“看不见”。
- 临时文件名含
.tmp，PHP解析器默认不识别为可执行PHP文件 - Composer会在原子写入完成后重命名（如
mv installed.json.tmp installed.json），旧文件被删除，新文件是全新inode - OPcache是否缓存新文件，取决于
opcache.revalidate_freq设置和文件修改时间戳，与临时文件无关
真正影响OPcache的是vendor/composer/autoload_*.php这类“正式产出”
Composer生成的autoload_static.php、autoload_classmap.php等文件，是自动加载逻辑的入口，会被项目启动时require，进而被OPcache编译缓存。它们的变更才是OPcache失效的关键触发点。
-
autoload_static.php：包含类名到文件路径的静态数组，高频访问，强烈建议进OPcache -
autoload_classmap.php：启用--classmap-authoritative后生成，替代动态查找，更易被OPcache高效缓存 - 如果这些文件被覆盖但OPcache未刷新，就会出现“类存在但
Class not found”——因为OPcache还在执行旧版本的映射逻辑
为什么有人误以为临时文件“污染”了OPcache？
典型现象是：执行composer install后立刻刷新页面，报错Class not found，同时发现vendor/composer/下残留.tmp文件。这其实是时间差导致的误解：
- 临时文件残留说明Composer进程异常中断（如被kill、磁盘满），此时
autoload_*.php可能未完整写入，已损坏 - 但OPcache错误不是因读了
.tmp，而是因加载了半截的autoload_static.php——它语法错误，PHP解析失败，连编译步骤都过不去，自然无法进OPcache - 检查方法：手动
php -l vendor/composer/autoload_static.php，若报syntax error，就证实是写入不完整，而非临时文件干扰
部署时该关注什么，而不是临时文件？
真正需要纳入部署检查清单的，是那些会被OPcache持续服务的“稳定文件”，以及它们的加载上下文：
- 确认
opcache.validate_timestamps = 0时，必须靠opcache_reset()或重启PHP-FPM来更新缓存，不能依赖文件时间戳 - 使用
--optimize-autoloader后，autoload_files.php里列出的每个文件都会被require_once，它们全部要能被OPcache覆盖（检查opcache.max_accelerated_files是否够大） - 避免在
post-install-cmd里直接调用opcache_reset()——CLI环境下该函数无效；改用curl触发Web端重置脚本，或统一走systemctl restart php-fpm
临时文件只是磁盘上的“影子”，OPcache只认内存里的opcode。盯住autoload生成逻辑、文件完整性、以及重置时机，比清理.tmp重要得多。
