生产环境绝不能运行composer update，因其会无视composer.lock重算依赖树，擅自升级包并重写锁文件，破坏版本一致性，导致Class not found、Method does not exist等故障；必须仅执行composer install --no-dev --optimize-autoloader --no-interaction，并通过环境变量、权限管控和流程约束四层防护封死update入口。
生产环境绝不能运行 composer update，它会无视 composer.lock，擅自升级依赖、破坏版本一致性，90% 的线上类加载失败或方法不存在报错都源于此。
为什么 composer update 在生产环境是危险操作
它不是“更新一下而已”，而是重新执行整套依赖求解：读取 composer.json 中的宽松约束（如 "monolog/monolog": "^3.0"），在 Packagist 上找满足条件的最新兼容版，可能拉入未测试的次版本变更、API 不兼容改动，甚至引入已知安全漏洞。更关键的是，它会重写 composer.lock —— 而这个文件本该是开发阶段锁定并提交到 Git 的唯一权威快照。
- 常见错误现象：
Class not found、Method does not exist、服务突然 502，日志里却找不到明确堆栈 - 真正诱因往往不是代码改了，而是某次上线后偷偷跑了
composer update，又把新生成的composer.lock提交了 -
composer install失败时，有人习惯性删掉composer.lock再跑update—— 这等于主动放弃环境一致性保障
composer install 必须带哪些参数才真正安全
只执行 composer install 还不够，缺参数照样埋雷。核心是切断 dev 包、关闭交互、优化加载路径，并确保行为可预测。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--no-dev：跳过安装require-dev中的包（如 phpunit、phpstan）。注意：它只跳过安装，不清理已有 vendor；若之前装过 dev 包，得先rm -rf vendor/ -
--optimize-autoloader：生成 classmap，避免运行时动态扫描文件，提升性能且规避某些 PSR-4 路径解析问题 -
--no-interaction：防止卡在确认提示（如 license 询问），CI/CD 或部署脚本中必须加 -
--prefer-dist：优先用压缩包而非 git clone，更快更稳定，尤其在弱网或私有仓库场景 - 别用
--ignore-platform-reqs当常态——它掩盖 PHP 版本或扩展缺失问题，应在构建镜像时就配齐环境
如何从流程和环境上彻底封死 update 入口
靠人盯不如靠机制。光写文档说“不准 run update”没用，得让命令本身在生产环境跑不起来。
- 部署脚本开头强制设置环境变量：
COMPOSER_NO_INTERACTION=1 COMPOSER_DISABLE_XDEBUG=1，前者防卡住，后者避免 PHP 8.2+ 下 xdebug 导致 fatal error - Dockerfile 中直接写：
ENV COMPOSER_NO_INTERACTION=1 COMPOSER_DISABLE_XDEBUG=1，让容器内所有 composer 命令默认受控 - CI/CD 流水线里，构建阶段只允许
composer install --no-dev --optimize-autoloader --no-interaction，且构建产物只含vendor/和composer.lock，不打包composer.phar或允许执行命令的权限 - 生产服务器上，可考虑移除
composer二进制文件，或用chmod -x /usr/bin/composer，让update命令根本无法执行
验证是否真做到了“只 install 不 update”
部署后别只看有没有报错，要主动检查依赖状态是否符合预期。
- 进生产环境执行：
composer show | grep -E "(phpunit|phpstan|friendsofphp|symfony/debug-bundle)"，输出为空才表示 dev 包确实没装 - 检查
vendor/autoload.php是否包含'classmap-authoritative' => true（需配合--optimize-autoloader和--classmap-authoritative参数） - 对比本地与线上
composer.lock的content-hash字段，一致才说明还原的是同一份快照 - 留意
composer install日志末尾是否出现Installing dependencies from lock file，而不是Resolving dependencies through SAT（后者是 update 的特征）
最容易被忽略的一点：团队协作中，composer.lock 文件一旦被误提交覆盖，所有人的 install 就都失效了——它不是中间产物，是环境契约，必须纳入 Git 严格管理，且每次修改都要有明确 commit message 和 code review。
