Composer不能替代人工评审，它仅解析依赖、下载包和注册自动加载，不具备检测能力；真正的安全扫描、静态分析和代码修复需依赖phpstan、composer audit等独立工具；业务语义、上下文变更和许可证合规性三类问题必须人工判断。
不能替代，连辅助都算不上——Composer 没有检测能力，更不参与评审。
Composer 根本不“检测”任何东西
很多人误以为 composer install 或 composer update 会扫描代码、检查安全漏洞、验证逻辑正确性，甚至拦截恶意包。事实是：Composer 只做三件事——解析 composer.json、下载指定版本的 ZIP 包、按 PSR-4/PSR-0 规则注册自动加载路径。它不执行代码，不分析 AST，不校验输入输出，也不读取你写的业务逻辑。
常见错误现象包括：
- 把
composer require friendsofphp/php-cs-fixer当成“装上就自动格式化全项目”，结果发现没生效——因为没运行php-cs-fixer fix - 看到某包在 Packagist 上标了 “abandoned”，就以为 Composer 会警告或阻止安装——实际只在
composer show中显示提示，install照常通过 - 依赖中存在已知 CVE 的旧版
guzzlehttp/guzzle，但composer update没报错——因为 Composer 不查 CVE 数据库
真正起作用的是你手动集成的工具链
所谓“检测”，实际来自你额外引入并显式调用的独立工具，它们和 Composer 是松耦合关系：
-
phpstan/psalm：静态分析，需单独运行命令，且要配置 level 和 baseline -
security-checker（已归档）或composer audit（v2.5+ 内置）：后者才真正查 CVE，但默认不启用，需加--format=summary或配合 CI 脚本触发 -
php-cs-fixer/phpcbf：代码风格修复，必须显式执行，不会在autoload阶段自动介入 - Laravel 的
php artisan ide-helper:generate：生成 IDE 支持文件，和 Composer 的 autoload 无关，只是利用了它导出的类映射
性能影响很小，但混淆边界会导致严重误判：比如在 CI 中只跑 composer install 就认为“已过安全扫描”，漏掉真实风险。
人工评审不可绕过的三个硬点
即使你配齐所有自动化工具，仍有三类问题必须靠人眼判断：
-
业务语义合理性：一个订单状态从pending直接跳到shipped而跳过paid，静态分析无法识别，但人工看一眼状态机流转就发现问题 -
上下文依赖变更：第三方 API 返回字段名从user_id改为uid，类型未变、结构兼容，但业务含义断裂——这类 break change 不在 SemVer 范围内，Composer 和大多数扫描器都沉默 -
许可证合规性：某个依赖间接引入了 GPL v3 包，是否违反你公司的开源政策？这需要法律+技术交叉判断，不是composer licenses命令能回答的
最容易被忽略的是：Composer 的 lock 文件本身是信任锚点，但它只保证“下载内容一致”，不保证“内容正确”。一旦上游包被投毒（如恶意修改 autoload 中的 files 数组执行任意 PHP），你本地 composer install 会照单全收——这时候，人工核对提交哈希、审查 vendor 下关键文件，仍是最后一道防线。
