如何通过Composer命令检查 vendor 目录下是否存在被篡改的文件-composer-PHP中文网

唯一可靠方式是启用实验命令composer_experimental=1 composer verify-checksums --strict，它逐包计算vendor/实际文件sha256并与composer.lock中dist.sha256严格比对；其他如composer install成功、--dry-run或validate均不校验已安装文件完整性。

如何通过composer命令检查 vendor 目录下是否存在被篡改的文件

composer install 或 update 后如何验证 vendor 文件完整性

Composer 本身不提供类似 npm audit 那样的主动校验机制，但能通过锁文件和哈希比对间接验证。关键在于：你依赖的 composer.lock 文件记录了每个包确切的 dist.sha256（或 sha1）值，这些是下载归档时的原始校验和。只要 lock 文件未被篡改，就能反向验证 vendor 中的文件是否与发布时一致。

常见错误现象：手动修改 vendor 里某个类、删掉某行日志、甚至植入恶意代码，但没更新 lock 文件——此时 composer install 不会报错，因为 lock 没变，它只管“照着装”，不管“装完对不对”。

执行 composer install --dry-run 只检查依赖解析，不校验文件内容
composer update 会重写 lock，覆盖原有哈希，失去比对基础
若项目没提交 composer.lock（比如 .gitignore 里忽略了它），则完全失去校验依据

用 composer validate + 手动比对 dist.sha256 校验和

Composer 没有内置命令直接扫描 vendor 目录并报告篡改，但可组合使用已有能力逼近目标。核心思路是：从 composer.lock 提取每个包的 dist.sha256，再对 vendor 下对应路径的文件重新计算哈希，逐个比对。

使用场景：CI 流水线中做安全卡点、上线前人工抽检、排查“为什么本地和线上行为不一致”。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

确保 composer.lock 是可信来源（比如 Git 仓库中已提交且未被篡改）
运行 composer validate 先确认 lock 文件语法合法，避免解析失败
提取哈希需注意：有些包只有 dist.sha1（老版本包），有些是 dist.sha256；优先读后者， fallback 到前者
vendor 路径下实际文件位置 = vendor/{vendor-name}/{package-name}/，但 dist 归档解压后结构可能不同——校验对象是整个 dist 归档解压后的根目录（即 vendor 中该包的全部内容），不是单个文件

用第三方工具 composer-verify 快速完成校验

社区有个轻量工具 composer-verify，专门填补这个空白。它读取 composer.lock，重新下载 dist 归档（或复用 Composer cache），解压后与 vendor 中对应目录做递归文件比对（含权限、mtime 等可选），最后输出差异列表。

性能影响小：默认复用 Composer 的 ~/.composer/cache，不重复下载；仅比对文件内容，不扫描全盘。

安装：composer global require youknowone/composer-verify
运行：composer-verify（当前目录需有有效的 composer.lock 和 vendor/）
若提示 “Package xxx differs”，说明 vendor 中该包内容与 lock 记录的 dist 不一致——可能是手动修改、git checkout 错误、或缓存污染
注意：它不校验源码（source 类型包），只处理 dist 类型（绝大多数 Packagist 包）