必须用 composer install，因为它严格按 composer.lock 安装精确版本，确保生产环境一致性；而 require 会修改 composer.json、重算依赖并更新 lock 文件，易引入未测试的不兼容变更。
直接在服务器上跑 composer install 是最稳妥的做法，前提是项目已提交 composer.lock；别在生产环境乱用 composer require 或 composer update。
为什么必须用 composer install 而不是 composer require
服务器部署的核心目标是环境一致性，composer install 会严格按 composer.lock 安装每个包的精确版本，跳过依赖解析过程。而 composer require 会修改 composer.json、重新计算依赖树、更新 composer.lock，这在生产环境极易引发：
- 本地开发加了个包，忘了
git add composer.lock，上线后composer install因缺失 lock 文件退化为update行为，装出意外版本 -
require触发的自动升级可能引入不兼容变更（比如 Guzzle 6 → 7），导致 PHP Fatal error - CI/CD 流水线里混用命令，不同节点装出不同依赖，测试通过但线上报错
composer install 报 “Your requirements could not be resolved” 怎么办
这不是网络问题，而是本地环境与 composer.lock 声明的平台约束不匹配。重点排查：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
php -v确认 CLI 使用的 PHP 版本，和composer.lock顶部platform字段是否一致（如"php": "8.1.20"） - 检查是否缺扩展：运行
php -m | grep -E 'curl|json|mbstring'，composer.lock中若声明了"ext-curl": "*"，而实际没启用，就会失败 - 删掉
composer.lock再跑install是危险操作——它等价于update，应先确认是否真要重算依赖
如何让 composer install 在低版本 PHP 环境下装高版本依赖
某些包只支持 PHP 8.2+，但你的服务器 PHP 是 8.1。Composer 默认按当前 CLI 版本校验，这时需显式声明目标平台：
- 执行
composer config platform.php 8.2.10，该配置写入当前项目composer.json的config.platform字段，不影响系统 PHP - 不要用
--ignore-platform-reqs，它会跳过所有扩展检查（如ext-gd），上线后 runtime 直接崩 - 该配置只影响依赖解析，不改变实际运行环境——确保部署后 PHP 运行时确实满足包要求
vendor 目录放在 Web 根目录外是硬性安全要求
vendor/ 绝对不能被 Web 服务器直接访问，否则攻击者可通过 https://yoursite.com/vendor/composer/installed.json 获取全部依赖清单及版本，为漏洞利用铺路。
- Nginx 配置中，
root必须指向public/或web/，而非项目根目录 - Apache 同理，
DocumentRoot指向入口目录，且应在.htaccess中加Deny from all拦截vendor/访问 - 共享主机（如 cPanel）若只能上传到
public_html，就把vendor/放上级目录，入口文件里改require __DIR__.'/../vendor/autoload.php';
真正容易被忽略的是 composer.lock 的时效性——它不是“一次生成，永久有效”。当基础镜像升级、PHP 小版本更新、或某依赖发布紧急安全补丁时，必须由专人执行 composer update vendor/package-name 并提交新 lock 文件，而不是靠自动脚本无差别更新。
