如何通过Composer命令检查 vendor 中是否有遗留的开发模式残留-composer-PHP中文网

应执行composer show --dev验证是否残留dev包，若输出非空则说明vendor中存在开发依赖；再检查composer.lock中"packages-dev"字段是否为空，确保锁文件未记录dev依赖。

如何通过composer命令检查 vendor 中是否有遗留的开发模式残留

检查 `composer.json` 中是否残留 `"require-dev"` 依赖在生产环境

直接运行 composer install --no-dev 后，vendor/ 目录里不该出现任何 require-dev 声明的包——但实际常有残留，尤其当之前用过 composer update 或手动删过文件。最可靠的方式不是看目录结构，而是比对当前 vendor/ 和 composer.lock 的实际安装记录。

执行：

composer show --dev

会列出所有已安装的 dev 依赖；如果输出非空，说明 vendor/ 里仍有开发包。再运行：

composer show --no-dev

确认生产依赖是否干净。两者结果不应重叠。

注意 composer show 默认只查已安装包，不读 composer.json 声明，所以它反映的是真实状态
如果 --dev 有输出但你确定不该有，先检查是否漏加 --no-dev 参数，或是否曾用 composer require --dev 临时装过调试工具没清理
composer install 不带参数时默认会装 require-dev，CI/部署脚本务必显式加 --no-dev

用 `composer dump-autoload --optimize` 暴露自动加载残留

有些开发工具（比如 phpunit、laravel/pint）即使没在 require-dev 里声明，也可能被手动拷进 vendor/ 或通过 autoload-dev 注册了类路径。这类残留不会出现在 composer show 结果中，但会在 vendor/autoload.php 加载时生效。

运行：

composer dump-autoload --optimize --no-dev

。如果报错类似 Class XXX not found，说明某个 dev-only 类仍被 autoload 规则引用，但又没被 --no-dev 排除——常见于 autoload-dev 里写了路径但没配 exclude-from-classmap。

重点检查 composer.json 的 "autoload-dev" 和 "autoload" 是否有重叠路径
--optimize 会生成 vendor/composer/autoload_classmap.php，可直接打开看里面有没有 dev 工具的类名
若发现不该存在的类名，删掉对应 autoload-dev 条目，再重新 dump-autoload

扫描 `vendor/` 目录下可疑的 dev 工具包名

某些包名字自带线索，比如含 test、phpunit、larastan、pestphp、infection、php-cs-fixer。这些通常只该在开发机存在。

Discussion Composer

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

下载

Linux/macOS 下快速排查：

ls vendor/ | grep -E "(phpunit|pest|stan|cs-fixer|infection|phpspec|behat)"

。Windows PowerShell 可用：

Get-ChildItem vendor | Where-Object Name -match "phpunit|pest|stan"

别只信目录名——有些包如 symfony/var-dumper 在开发和生产都可能用，得结合实际调用链判断
如果发现包但 composer show 不显示它，说明是手动复制进去的“幽灵依赖”，必须手动删并追查来源
vendor/bin/ 下的可执行文件更危险：哪怕包本身没 autoload，二进制文件也可能被 CI 脚本误调用

验证 `composer.lock` 是否锁定为无 dev 状态

composer.lock 是唯一可信的“安装快照”。即使 vendor/ 看似干净，只要 lock 文件里还记着 dev 包，下次 composer install 就会还原它们。

打开 composer.lock，搜索 "require-dev": {，确认其值为 {} 或根本不存在该字段。再搜 "packages-dev" —— 如果这个 key 存在且非空，说明 lock 文件记录了 dev 包，当前 vendor/ 可能只是暂时被删了，不是真正干净。

CI 部署前建议加校验步骤：

jq -e '.["packages-dev"] | length == 0' composer.lock >/dev/null

如果 packages-dev 非空，说明上次 composer install 没加 --no-dev，或有人 commit 了带 dev 的 lock 文件
不要手动编辑 composer.lock，正确做法是删掉 vendor/ 和 composer.lock，再用 composer install --no-dev 重建

真正麻烦的不是看到 dev 包，而是那些没注册 autoload、不写进 lock、也不在 show 列表里的“半残”残留——比如只拷了一个 vendor/bin/phpunit 却没装包本身。这种得靠 grep -r "phpunit" . --include="*.php" 反向追踪调用点。