composer audit仅检测已知安全漏洞，不检查代码质量；代码质量问题需用phpstan、psalm等静态分析工具扫描vendor目录，且须手动配置路径与级别。
Composer 本身不监控依赖质量，它只负责安装和解析依赖；所谓“监控依赖质量”，实际是靠外部静态分析工具（如 PHPStan、Psalm）对已安装的 vendor 代码做扫描，不是 Composer 的功能，而是你主动加进去的检查环节。
为什么不能直接用 composer audit 查依赖质量问题
composer audit 只查已知安全漏洞，不查代码质量。它比对的是 Packagist 的 security-advisories 数据库，输出类似 CVE-2023-12345 这类条目，跟类型错误、空值解引用、未定义方法调用完全无关。想发现 Call to a member function toArray() on null 这种问题，必须上静态分析器。
PHPStan 扫描 vendor 依赖的正确姿势
默认情况下 PHPStan 不扫描 vendor/，这是设计使然——它专注分析你的项目代码。但如果你真要监控第三方包的质量（比如验证某个 fork 包是否引入了危险写法），得手动打开：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在
phpstan.neon中显式加入- vendor/some-vendor/some-package/src到paths - 确保该包的类能被自动加载：检查
vendor/some-vendor/some-package/composer.json的autoload字段是否合法，否则 PHPStan 会报Class not found - 慎用
autoload_files加载 vendor 内的引导文件——容易触发重复定义或运行时副作用 - 级别别拉太高：对第三方代码用
level: 3起步，level: 7+会大量误报，尤其对没类型注解的老包
Psalm 对依赖的深度介入更可控
Psalm 提供 --include-php-files 和 <projectfiles><file></file></projectfiles> 精确控制扫描范围，比 PHPStan 更适合渐进式覆盖 vendor：
- 用
vendor/bin/psalm --init后，手动编辑psalm.xml，在<projectfiles></projectfiles>下添加特定路径：<directory name="vendor/myorg/private-sdk/src"></directory> - 配合
<issuehandlers></issuehandlers>抑制已知噪音，例如屏蔽某 SDK 因兼容性保留的@deprecated方法调用：<invaliddocblock errorlevel="info"></invaliddocblock> - 不要开
totallyTyped="true"扫 vendor——那是给自有代码用的，第三方包没这义务 - 若该依赖用了动态调用（如
$obj->{$method}()），需在调用处补@psalm-var注解，否则 Psalm 直接跳过分析
真正难的不是加工具，而是决定“扫谁”和“信谁”。第三方包的质量水位差异极大，盲目全量扫描只会让 CI 卡在一堆不可控警告里。优先盯住你 fork 修改过的、或核心链路上的几个关键依赖，比扫完整个 vendor 更有效。
