Composer怎么定义安装限制条件 Composer项目依赖安全性设置

直接说结论：默认情况下，composer install 不会因为锁文件里藏着已知的高危漏洞就罢工——哪怕你锁着的是一个公开的 RCE 版本。所谓的安全拦截功能，默认只对 update 命令生效，而且是从 Composer 2.9 才开始默认开启的。所以，要想在安装阶段就卡住风险，必须主动加一道检查。

composer install 时如何真正卡住高危漏洞

很多人以为 Composer 的 install 流程会自动拦截漏洞，其实它完全是闷头干活的状态。哪怕 composer.lock 里锁着的是 guzzlehttp/guzzle 的已知 RCE 版本，它也不会停一下。必须组合命令才能让安装阶段具备卡点的能力：

• 先跑 composer install --no-interaction，然后紧接着执行 composer audit --severity=high --severity=critical --no-dev。
• 在 CI 环境中，千万别忘了加 --no-dev——否则像 phpunit 或 mockery 这类开发依赖的中低危漏洞，会把你真正想卡住的高危风险给淹没了。
• 有一点要特别注意：--severity 参数只接受 high 和 critical，不支持 medium 或 low，写了也白写。
• 如果你的网络环境受限（比如内网 CI），可以提前运行 composer security:check --no-interaction 把结果缓存下来，这个命令对旧版本也更友好。

如何确认 audit 命令真正在工作

这里有个常见的误区：很多人以为跑了 composer audit 就万事大吉了，但实际上它并不是开箱即用的功能。这个命令从 Composer 2.5 才开始引入，默认是关闭的，而且依赖全局配置和网络连通性。

在执行之前，建议先核实三件事：

• 运行 composer --version 看看版本，如果低于 2.5.0，直接升级，别在旧版上浪费时间试 audit。
• 运行 composer config --global experimental.audit，输出应该是 true；如果为空，就执行 composer config --global experimental.audit true 手动开启。
• 手动访问一下 https://packagist.org/advisories，确认能返回 JSON 数据。很多公司的防火墙会拦截这个地址，如果访问不了，audit 就会静默失败——你完全察觉不到。

还有一个容易让人踩坑的假阴性问题：如果锁文件里依赖的是 dev-main 或 dev-feature/x 这类开发版本，audit 会直接跳过——它只比对 Packagist 官方收录的稳定版。所以开发分支的依赖，你得自己想办法盯着。

依赖来源可信怎么才算真正生效

很多人觉得 composer.lock 文件里的 hash 校验已经够用了，其实远远不够——那个 hash 是可以被篡改的。真正建立信任链要靠 Packagist 的签名机制，但这个东西需要手动开启，而且只对签名包有效。

关键操作其实就两步：

• 运行 composer config --global security.signature-verification true（注意：仅 Composer 2.5+ 支持）。
• 运行 composer show --security，如果输出里有 Signature verification: enabled，这才算真正生效。

有一个需要警惕的细节：security.signature-verification 对私有仓库是无效的。如果你用的是阿里云、腾讯云这类国内镜像源，它们通常关闭了签名验证，要么切回 https://packagist.org，要么自己配置仓库级的签名策略。

vendor 权限问题的根源不在 chmod

遇到 vendor/ 目录权限报错，很多人第一反应就是 chmod 777——这其实是典型的误操作。问题的根源几乎从来不是权限数字太小，而是属主错位。尤其当你不小心用了 sudo composer install，或者在 Docker 里以 root 身份运行的时候。

后果很直接：PHP 文件、bin 脚本、autoload 文件全归 root 所有，普通 Web 用户（比如 www-data）想写入缓存或覆盖文件，就直接报 file_put_contents(...): Permission denied。

修复顺序必须正确：

• 先查属主：ls -ld vendor/，如果显示 root root，那就找到病根了。
• 改归属：sudo chown -R $USER:$USER vendor/ composer.lock。
• 清理缓存：composer clear-cache，避免旧缓存干扰。
• 在 Dockerfile 里加一条 RUN umask 0022 && composer install --no-dev，从源头就把问题掐死。

全局缓存目录（~/.composer）的权限错位更隐蔽，会导致所有 global 命令都失败——同样需要用 chown -R 来修复。