composer 2.5+ 内置 composer security:check 命令足够常用，它离线比对本地缓存的 symfony 安全公告库，不上传 lock 文件、不依赖网络，兼顾隐私与稳定性；需先确保存在 composer.lock，发现 critical/high 漏洞须手动修复。
Composer 2.5+ 自带 composer security:check 就够用，不需要额外装 PHAR 或 Go 工具，除非你有离线、隐私或 CI 集成的特殊需求。
为什么优先用 Composer 原生命令？
Composer 2.5 起内置的安全检查不是调用远程 API，而是本地比对缓存的 Symfony Security Advisories 数据库（默认每周自动更新一次），不上传 composer.lock，也不依赖外部网络——这解决了绝大多数团队对隐私和稳定性的核心顾虑。
- 执行
composer security:check时，它只读取当前目录下的composer.lock，包括require-dev中的包 - 若提示 “No lock file found”，说明项目还没运行过
composer install或composer update，得先生成composer.lock - 输出里标
CRITICAL或HIGH的条目才真要立刻处理；MEDIUM级别建议排期，LOW可暂时忽略 - 它不解决冲突，只报漏洞。修复动作仍需手动执行
composer update vendor/package-name或改composer.json
遇到 “Your dependencies are OK” 却仍有已知 CVE 怎么办？
常见原因是本地缓存过期或数据库未同步。Composer 的安全公告库不是实时更新的，官方同步频率约为每周一次，但你可以强制刷新：
- 运行
composer security:check --update：主动拉取最新 advisories 缓存（需要能访问https://security.sensiolabs.org） - 如果公司防火墙拦截该域名，可临时配代理：
export HTTPS_PROXY=http://your-proxy:8080 - 检查缓存位置：
composer config --global home，然后进cache/security-advisories/目录看最近修改时间 - 极端情况下，删掉整个
security-advisories缓存目录再重试，Composer 会自动重建
自动更新不能直接开，得加约束条件
盲目执行 composer update 可能破坏兼容性，尤其在生产环境。真正可行的“自动更新”是带策略的增量升级：
- 只更新含漏洞的包：
composer update vendor/package-name --with-dependencies，避免全量漂移 - 用
--dry-run先预览变更：composer update monolog/monolog --dry-run - CI 中建议结合
composer outdated --direct --minor-only筛出可安全升小版本的包，再针对性更新 - 永远不要在
composer.json中写死"^"或"*"版本约束——这会让composer update拿到非预期大版本，引发 break change
Local PHP Security Checker 适合什么场景？
它不是替代品，而是补位工具：当你无法联网、审计要求留痕、或需要输出 junit 格式供 Jenkins 解析时才启用。
- 安装后首次运行会慢，因要下载完整漏洞库；后续走本地缓存，速度接近原生命令
- 支持
--format=json和--output=report.json，比 Composer 命令更易集成进自动化流水线 - 注意它默认扫描
require-dev，但某些 CI 场景下你只想关注生产依赖，得加--no-dev参数（部分旧版不支持，需确认 v0.4.0+） - 它的
--local模式完全离线，但必须提前用在线模式跑一次生成缓存，否则报错 “no advisory database found”
最常被忽略的一点：安全扫描结果只是起点，不是终点。composer security:check 报出的每个 CRITICAL 漏洞，都得对应到具体 commit、测试用例和上线灰度方案——没验证过的更新，和没更新一样危险。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
