composer diagnose 不检查 vendor 目录文件是否存在或是否被系统回收，仅验证其可写性与目录属性；即使 vendor 为空或 autoload.php 缺失，diagnose 仍显示 ok，真实问题需通过系统命令或后续 install/require 暴露。
composer diagnose 不会检测 vendor 目录是否被操作系统回收——它压根不扫描 vendor/ 下的文件存在性、完整性或生命周期状态。
composer diagnose 根本不检查 vendor 文件是否存在
它只检查 vendor/ 目录当前是否有写权限，以及是否为目录（而非文件），但不会遍历、校验、或感知其中文件是否被删除、覆盖或被系统清理。比如 Linux 的 tmpfiles.d 规则、Docker 容器重启后未挂载 volume、macOS 的 Time Machine 误删、或 Windows Defender 隔离了某些 .phar 文件——这些行为都不会在 composer diagnose 输出中留下任何痕迹。
- 运行
composer diagnose时，只要vendor/目录存在且可写，就显示OK - 即使
vendor/autoload.php已被删光、vendor/composer/installed.json是空文件、甚至整个vendor/是个空目录，它也照常通过 - 真正暴露问题的时刻是后续执行
composer install或require时：报错Failed opening required 'autoload.php'或卡在Generating autoload files
怎么确认 vendor 是否真被回收了
别依赖 diagnose，直接用系统命令验证：
- 检查目录内容是否为空：
ls -A vendor/ | head -n 5（Linux/macOS）或dir vendor\（Windows） - 验证关键文件是否存在：
test -f vendor/autoload.php && echo ok || echo missing - 查最近修改时间：
stat -c "%y" vendor/（Linux）或Get-ChildItem vendor | Sort-Object LastWriteTime -Descending | Select -First 1（PowerShell） - Docker 场景下重点看是否挂载了 volume：
docker inspect <container> | jq '.[0].Mounts'</container>，确认vendor/路径没被遗漏
哪些系统机制会静默回收 vendor 文件
这不是 Composer 的 bug，而是环境层的“合理清理”行为，容易被忽略：
-
/tmp类路径被设为vendor/：某些 CI 脚本误设COMPOSER_VENDOR_DIR=/tmp/vendor，而系统定时清空/tmp - Docker 使用
ephemeral存储驱动（如overlay2未配 volume），容器退出即丢弃所有写入 - macOS 上启用了
Optimize Mac Storage，可能将未访问的vendor/归档或移至 iCloud - Windows 组策略启用“临时文件自动清理”，且
vendor/被识别为“临时用途目录”
vendor 目录不是缓存，它是项目运行必需的代码载体；一旦被回收，composer diagnose 不会预警，php index.php 却会直接 fatal error——这点必须手动守住。
