composer status 默认不检查非 PHP 文件，因为它仅校验 composer.lock 中记录的、被 autoload 或 scripts 引用的 PHP 类文件（如 .php、.inc）的哈希；非 PHP 文件（如 .js、.md）未被纳入哈希计算，故修改后不会触发警告。
composer status 为什么默认不检查非 PHP 文件
composer status 的设计目标是验证 vendor/ 中由 Composer 安装或更新的 PHP 包是否被意外修改，它只比对 composer.lock 记录的文件哈希 —— 而这些哈希仅覆盖 composer.json 中声明的 autoload、files、classmap 等机制实际涉及的 PHP 文件（含部分扩展如 .php、.inc、.phar）。非 PHP 文件（如 .js、.css、.json、.md）即使存在于包内，只要没被 autoload 或 scripts 引用，就不会被纳入哈希计算和校验范围。
这意味着：你手动改了某个包里的 README.md，composer status 完全不会报错；但改了 src/Helper.php，它立刻提示 Files modified。
如何让 composer status 检测非 PHP 文件变动
没有官方开关能直接开启对非 PHP 文件的校验 —— 因为 Composer 不记录它们的哈希。但你可以绕过限制，通过补全哈希信息来实现：
- 在对应包的
composer.json中（通常是本地开发时 fork 的包），显式添加"files"或"classmap"条目，把需要监控的非 PHP 文件路径列进去（例如"files": ["dist/bundle.min.js"]），然后运行composer update --lock；Composer 会重新计算并写入这些文件的 SHA-256 哈希到composer.lock - 更通用的做法：用
composer dump-autoload --optimize+ 自定义 autoloader 加载非 PHP 资源（不推荐，破坏语义） - 真正实用的替代方案：放弃
composer status，改用git status vendor/（前提是vendor/已提交或已跟踪）或diff -r对比原始包 tarball 解压目录与当前vendor/目录
常见误判场景和陷阱
即使你设法让某些非 PHP 文件进入哈希校验，仍可能触发误报：
立即学习“PHP免费学习笔记（深入）”；
-
composer install后自动生成的文件（如vendor/bin/*符号链接、vendor/composer/autoload_*.php）会被status当作“被修改”，因为它们每次生成内容都不同 - 某些包在安装时执行
post-install-cmd脚本（如构建前端资源），会覆盖dist/下的.js文件 —— 这些改动合法，但status无法区分“构建产物”和“人工篡改” - Windows 与 Linux 下换行符（CRLF vs LF）差异会导致哈希不一致，尤其影响
.json或.env.example类文本文件 -
composer status -v输出的“modified files”列表不显示具体哪一行变了，只告诉你文件名 —— 查变更还得靠git diff或cmp
更可靠的替代检测方式
如果你的核心诉求是“发现 vendor 中任何不该有的改动”，而不是执着于 composer status，建议组合使用：
- 对
vendor/开启 Git 跟踪（仅限开发环境）：git add --force vendor/，再配合git diff --no-index /dev/null vendor/快速识别新增/删除/修改 - 用
composer show --installed --format=json提取所有已装包名和版本，再逐个下载官方 dist zip，用diff -r <extracted> vendor/<vendor/name>做精确比对 - CI 环境中，在
composer install后立即运行find vendor/ -type f ! -name "*.php" -not -path "*/tests/*" -exec md5sum {} \; | sort生成快照，下次构建时比对 —— 这种方式不依赖 Composer 元数据，但需自行维护快照逻辑
真正的难点不在命令怎么敲，而在界定“哪些非 PHP 文件属于关键资产”。比如一个 Laravel 包里的 stubs/ 目录该不该监控？这取决于你的团队是否允许开发者覆盖默认 stub —— 规则必须先明确，工具才有意义。
