生产环境只允许运行 composer install --no-dev --no-interaction --no-progress --optimize-autoloader，必须确保 composer.lock 已提交且存在，禁用 --scripts 和 --prefer-source，CI 中需强制 audit 失败即终止构建。
别让 composer update 或 composer require 在生产环境或 CI 中直接运行——它们本质是依赖图重解析，会绕过 composer.lock 的精确约束，等于主动放弃安全锁定。
哪些命令算“高风险”，为什么
高风险不取决于命令名字，而取决于它是否触发依赖树重新计算和版本浮动：
-
composer update（含composer update vendor/package）：强制刷新所有或部分依赖版本，忽略composer.lock中记录的精确 commit hash、dist shasum 和子依赖版本 -
composer require vendor/package:dev-main或任何带dev-前缀的版本：composer.lock会存 commit hash，但该 hash 可被 force push 覆盖，audit 也会跳过扫描 -
composer install时composer.lock缺失或被.gitignore忽略：等效于隐式执行update，结果不可控 -
composer install --prefer-source：启用 Perforce/Git 等 VCS 拉取逻辑，可能触发 CVE-2026-40261 指令注入（尤其在未升级到 2.2.27/2.9.6 的旧版 Composer 上）
生产环境只允许用这一个命令
部署阶段唯一合法命令是：
composer install --no-dev --no-interaction --no-progress --optimize-autoloader
关键点：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须确保
composer.lock已提交进 Git，且 CI 流水线第一步就校验它存在：ls -la composer.lock -
--no-dev不仅省体积，更防止roave/security-advisories这类 dev-only 包意外进入生产环境（它放错位置会导致运行时报错） - 禁用
--scripts（除非明确需要 post-install-cmd），避免执行未经审计的任意 PHP 代码 - 绝不在生产机上装 Composer 二进制，也不开放 SSH 后执行任何
composer命令
CI 中做安全卡点的实操方式
不能靠人眼扫 composer audit 输出，得让构建失败可预期、可收敛：
- 先确认 Composer 版本 ≥ 2.5.0：
composer --version，否则audit命令不存在 - 启用实验特性：
composer config --global experimental.audit true（某些镜像默认关） - 使用精准过滤，避免 low 级漏洞干扰：
composer audit --severity=critical,high --no-dev --no-interaction --timeout=30 - 网络不稳定时加超时，防卡死；私有包需确保
repositories正确声明且支持security-advisories字段 - 若要用 JSON 解析，必须配
jq：composer audit --format=json --no-dev | jq -e '.advisories[] | select(.severity == "critical")' > /dev/null
修复漏洞时最容易踩的坑
composer audit 只报不修，后续动作极易引入新风险：
- 执行
composer update monolog/monolog后，必须立刻git add composer.lock并提交——否则别人install还是旧版，漏洞照旧 - 不要用
composer update全量升级，优先指定包名 + 版本号：composer update monolog/monolog:^2.9.0，避免连带升级其他包引发兼容问题 - 如果
composer.json里写的是"monolog/monolog": "^2.0"，而修复版是 2.9.0，update 后composer.lock会锁死 2.9.0，但下次有人改代码再跑update，又可能漂移到 2.10.x —— 所以长期策略是收紧约束，比如改写成"monolog/monolog": "2.9.0" - 遇到 CVE-2026-40261 类漏洞，升级 Composer 是唯一解；临时缓解只能禁用
--prefer-source，改用 dist 包安装
真正危险的不是命令本身，而是执行它的上下文：没有 composer.lock 的 install、没验证版本的 audit、没提交 lock 的 update——这些组合起来，才构成实际攻击面。
