根本原因是composer.json约束与服务器PHP版本/扩展不匹配，或composer.lock基于开发环境生成而服务器不满足；需用php -v、php -m验证环境，并运行composer check-platform-reqs提前暴露问题。
部署环境报错，不是 Composer 坏了，而是你本地能跑、服务器装不上——根本原因是 composer.json 里写的约束和服务器真实 PHP 版本/扩展不匹配，或者 composer.lock 锁的是开发机环境，而服务器压根没那条件。
为什么 composer install 在服务器直接失败
常见现象是卡在 Resolving dependencies... 后无响应，或报 Your requirements could not be resolved，但本地完全正常。这不是网络或权限问题，而是服务器 PHP 环境和 composer.lock 不兼容。
- 运行
php -v和php -m | grep -E "(intl|mbstring|gd|xml|curl|json)"，确认版本和扩展是否真启用（注意大小写，mbstring不是MBString） - 检查
php --ini输出的配置路径，别改了本地 php.ini 却在服务器用另一个 -
composer.lock里记录的是你本地 PHP 版本和扩展能力，如果服务器 PHP 是 8.1，而 lock 文件里锁了只支持 8.2 的包，install 就会当场放弃 - Docker 或 CI 环境常漏装扩展：Ubuntu 上缺
php-intl，Alpine 上没php82-intl，都直接触发 platform 检查失败
config.platform 是双刃剑，别乱设
很多人加 "config": {"platform": {"php": "8.1.22", "ext-gd": "8.1.22"}} 是为了“假装”环境达标，结果上线后 Class 'IntlDateFormatter' not found。这字段不是补丁，是告诉 Composer：“就当这些已存在”，但它不装扩展，也不改 PHP 版本。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果服务器确实缺扩展，删掉
config.platform.ext-xxx行，老老实实装扩展（sudo apt install php-intl或docker-php-ext-install intl） - 若真不能装（比如共享主机），必须确认所有依赖包都明确支持 polyfill 方式，而不是只写
"require": {"ext-intl": "*"} -
config.platform.php设太死（如"8.1.22"）会导致新包进不来；设太松（如"8.1"）又可能锁住不兼容的旧版 —— 推荐用"^8.1"，兼顾语义化和兼容性
CI/CD 流程里最常踩的三个坑
CI 报 file_put_contents(/var/www/html/vendor/composer/installed.json): Permission denied 或 Class not found，90% 出在流程设计上。
- 别在 CI 中用
root用户跑composer install，文件属主错乱会导致后续 Web 进程读不了 vendor；应指定非 root 用户（如www-data）或加--no-scripts避免自动执行权限敏感脚本 - Git 提交了
vendor/？立刻git rm -r --cached vendor并加到.gitignore——vendor是生成物，不是源码 - CI 脚本里混用
composer install和composer update：前者按lock装，后者重算依赖。部署阶段只该用install；update只应在开发机上运行并提交新lock
如何让一次 composer install 在所有环境都稳
核心就一条：composer.lock 必须反映目标环境能力，而不是开发机快感。它不是缓存，是契约。
- 每次改
composer.json后，先在最低支持 PHP 版本的 Docker 容器里跑一遍composer update --dry-run，确认不爆红再提交 lock - 团队统一用
phpenv或asdf锁定 PHP 小版本，避免 “我本地是 8.1.22，他拉的是 8.1.0” 这种隐形差异 - 上线前最后一道检查：
composer check-platform-reqs—— 它会逐条比对当前 PHP 是否满足lock文件里所有 platform 要求，比install更早暴露问题
真正难的不是命令怎么敲，而是搞清哪一行 config.platform 是遮羞布、哪一行 require 其实偷偷绑定了 PHP 小版本、以及为什么 composer.lock 里某个包的 dist.shasum 在服务器校验不过——这些细节藏在 lock 文件末尾的 platform 字段和每个包的 require 块里，不打开看，永远以为是玄学。
