风险路径藏在 advisories 数组每个条目的 source 字段里，是触发漏洞的最短依赖路径，如 ["myapp", "monolog/monolog", "phpunit/phpunit"]，顺序表示依赖流向，末尾不一定是漏洞包本身而是其有漏洞的子依赖。
composer audit --format=json 输出里哪部分表示风险路径？
安全风险路径藏在 advisories 数组每个条目的 source 字段里，它不是直接列出调用链，而是给出触发该漏洞的「最短依赖路径」——即从你的项目根开始，到引入问题包的那条最小依赖链。
常见错误是只看 title 或 severity 就去升级，结果发现升级后 composer audit 还报同一问题：因为没意识到路径里可能含间接依赖（比如 A → B → C → 漏洞包），而你只升级了 A。
-
source是一个数组，例如["myapp", "monolog/monolog", "phpunit/phpunit"]，顺序就是依赖流向 - 路径末尾不一定是漏洞包本身，可能是它的某个有漏洞的子依赖（如
phpunit/phpunit依赖了带漏洞的sebastian/version） - 同一漏洞可能出现在多条路径下，
advisories里会重复出现多个条目，需逐条检查
如何从 JSON 输出快速定位真实可修复的路径？
别直接人肉扫 JSON。用 jq 提取关键字段，聚焦「你能控制的那一段」：
composer audit --format=json | jq -r '.advisories[] | select(.source | length > 2) | "\(.source[-2]) → \(.source[-1]) | \(.title)"'
这个命令过滤掉直接依赖漏洞包的情况（length > 2 表示至少经过一层间接依赖），只看倒数第二级是谁拉进了最后一级——这才是你大概率能干预的位置。
- 如果倒数第二级是你自己写的包（如
mycompany/utils），就要去它composer.json里改require - 如果倒数第二级是第三方包（如
guzzlehttp/guzzle），得查它最新版是否已修复；没修复就只能等或换方案 - 注意
source路径里的包名可能带版本号（如"laravel/framework:9.52.0"），说明该路径锁定在特定版本，升级它可能打破兼容性
audit 输出里没有路径？可能是这几种情况
composer audit 默认只报告「当前 lock 文件中实际安装的包」的安全问题。如果某条路径没出现在输出里，不代表安全，只代表它没被装进 vendor/。
- 运行前没执行
composer install或composer update，composer.lock过期，audit 无从比对 - 用了
--no-dev安装，但漏洞在require-dev里，audit 默认不检查 dev 包（加--dev参数才扫） - 你本地 PHP 版本太低，某些 advisory 的
affectedVersions规则不匹配（比如规则写的是^8.1，你用 7.4，audit 就跳过） - 用了
platform配置伪造了扩展存在状态，导致某些包未被解析出依赖关系，路径丢失
为什么升级了路径末尾包，audit 还报老路径？
因为 composer update 没真正切断旧路径。Composer 的依赖解析是全局一致的，哪怕你手动删了 vendor/xxx，只要 composer.lock 里还记着旧版本，下次 install 就还原。
- 必须运行
composer update --with-dependencies，否则只更新指定包，不管它的子依赖是否也得升 - 某些路径涉及
conflict或replace关系，升级一个包可能触发另一条路径浮现（audit 结果会变，不是 bug） - 检查
composer show -t输出，确认目标包是否真的在树里「不可达」了——如果还能从根走到它，audit 就不会放过
路径不是静态快照，它随 lock 文件和平台环境实时变化。每次改依赖后，都得重新 composer install && composer audit 才算闭环。
