定期安全审查需组合使用 composer outdated --all 和 composer audit --dev，因前者默认仅查直接依赖且忽略旧 patch 版本漏洞，后者默认跳过开发依赖、私有包及平台兼容性校验，漏报率高。
定期审查不能只跑一次 composer outdated 或 composer audit 就算完——它默认不扫开发依赖、不校验平台兼容性、不覆盖私有包，且老版本根本连不上 Snyk，漏报率极高。
为什么 composer outdated 总是“没东西可升”
常见错误现象：执行后空输出，误以为依赖已最新，实际可能卡在旧小版本里（比如 guzzlehttp/guzzle 还停在 7.2.0，而 7.5.1 已修复 CVE-2023-41277）。
- 默认只显示语义化版本中「安全可升」的更新（如
^7.2.0允许升到7.9.9，但不会跨到8.0.0），很多漏洞就藏在 7.x 的旧 patch 版本里 - 加
--all才能查全量可升级项：composer outdated --all - 日常巡检建议加
--direct只看你自己require声明的包，避免被传递依赖干扰 - 若项目用了
"minimum-stability": "stable"+"prefer-stable": true，候选更新会被过滤掉——得临时关掉再跑 - CI 中推荐用
composer outdated --direct --no-dev --minor-only --format=json，结构化输出方便解析告警
composer audit 默认根本不查 require-dev
CI 流水线里漏掉 --dev，等于把 phpunit/phpunit、mockery/mockery 等测试链漏洞全豁免。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 固定写法：
composer audit --dev --no-interaction，避免交互中断流水线 - 想只拦截高危以上漏洞，加
--severity=high,critical - 老版本 Composer（composer self-update --2
-
composer audit --format=json输出里的"advisories_count"字段才是真实漏洞数，别信终端颜色渲染或截断后的“No advisories found” - 私有包、fork 包、
path类型本地依赖，默认静默跳过，不是报错——得在composer.json里手动配"type": "package"并提供security-advisories元数据
composer validate --strict 必须和 audit 并行跑
audit 只管漏洞，不管你的 platform 配置是否合理。比如项目锁死 "php": "8.2"，但某个依赖最新版只支持 8.3+，audit 完全不会提醒——部署时直接崩溃。
-
composer validate --strict会校验 PHP 版本、扩展是否存在、platform是否与composer.lock一致 - 某些 CI 镜像（如阿里云、腾讯云 Composer 镜像）会缓存或丢弃
platform元数据，核心项目建议直连https://packagist.org - 运行前先确认源是否生效：
composer config repositories，警惕非packagist.org的自定义仓库，尤其无 HTTPS 或域名生僻的 - 人工补位：对关键私有包，定期查其 GitHub/GitLab 仓库的
SECURITY.md或issue标签，关注最近 commit 和 maintainer 活跃度
真正难的不是命令怎么写，而是每次审查都要同时盯住三件事：哪些包有已知漏洞、哪些升级会破坏平台兼容性、哪些私有依赖根本不在扫描范围内——漏掉任何一项，审查就只是走形式。
