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 不记录它们的哈希。但你可以绕过限制，通过补全哈希信息来实现：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

• 在对应包的 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 文件进入哈希校验，仍可能触发误报：

• 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></vendor></extracted> 做精确比对
• CI 环境中，在 composer install 后立即运行 find vendor/ -type f ! -name "*.php" -not -path "*/tests/*" -exec md5sum {} \; | sort 生成快照，下次构建时比对 —— 这种方式不依赖 Composer 元数据，但需自行维护快照逻辑

真正的难点不在命令怎么敲，而在界定“哪些非 PHP 文件属于关键资产”。比如一个 Laravel 包里的 stubs/ 目录该不该监控？这取决于你的团队是否允许开发者覆盖默认 stub —— 规则必须先明确，工具才有意义。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！