vendor/autoload.php 是第一攻击面，因其内容固定且 composer 不校验；需通过哈希比对和敏感函数扫描双重检测，并设 vendor 为只读、强制重装来防护。
vendor/autoload.php 被篡改后，Composer 从不报错、不警告、也不还原——它只管“装”，不管“有没有被动过”。你得自己动手卡住这个入口。
为什么 autoload.php 是第一攻击面？
它不是动态生成的，而是固定写死的一行：require_once __DIR__ . '/composer/autoload_real.php';。一旦被替换成 eval($_GET['x']) 或 system($_GET['cmd'])，所有请求都会执行恶意逻辑。
- Composer 完全不校验这个文件：它不在
composer.lock里记录哈希，composer dump-autoload不读它，composer install也不比对它 - CI 流水线里哪怕加了
composer validate，也完全扫不到这行代码 - 最常见篡改方式是直接覆盖内容，而非删文件——所以只检查
file_exists()毫无意义
如何快速检测 autoload.php 是否干净？
别依赖“是否存在”，要验证“内容是否可信”。两种方式必须组合使用：
- 基础内容比对：
sha256sum vendor/autoload.php应该恒等于echo 'require_once __DIR__ . "/composer/autoload_real.php";' | sha256sum（输出前 64 字符） - 敏感函数扫描：
grep -q "eval\|system\|shell_exec\|base64_decode\|assert(" vendor/autoload.php && echo "INFECTED" || echo "OK" - CI 中建议加守门逻辑：
grep -q "autoload_real\.php" vendor/autoload.php || exit 1，防住最粗暴的整行替换
verify-checksums --strict 能不能覆盖 autoload.php？
不能。这个命令只校验 dist 包解压后的文件（比如 vendor/symfony/console/），但 vendor/autoload.php 是 Composer 自己生成的引导文件，不属于任何包的 dist 内容，因此被完全跳过。
- 必须显式启用：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict，否则命令不存在 - 它只处理
dist安装的包；--prefer-source或 Git 克隆的包直接忽略 - 即使校验通过，也不能说明
vendor/autoload.php安全——这是最容易被忽略的盲区
生产环境唯一可靠的防护姿势
把 vendor/ 设为只读，并在部署流程中强制重装，而不是“修”或“检”：
- 部署前执行：
chmod -R a-w vendor/（Linux/macOS）或attrib +R vendor /s（Windows） - CI 构建时用：
rm -rf vendor && composer install --no-cache --prefer-dist --no-scripts --no-plugins - 禁止在生产机上运行
composer dump-autoload或任何写 vendor 的操作——它不该是运行时行为
真正危险的不是“怎么查”，而是“查完还留着”。只要 vendor 目录可写，autoload.php 就永远处在裸奔状态。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
