Composer开发环境与线上冲突_Composer多环境依赖同步处理【教学】-composer-PHP中文网

根本原因是composer.lock未被当作依赖契约严格执行，或platform配置与实际环境不一致；本地能过而线上报错，是因Composer将PHP版本、扩展等运行时环境纳入依赖求解，常见于platform声明失真、扩展缺失或lock文件跨平台失效。

composer开发环境与线上冲突_composer多环境依赖同步处理【教学】

开发环境和线上环境依赖不一致，不是 Composer 坏了，而是 composer.lock 没被当契约用，或者 platform 配置没对齐——直接删 lock 或跑 composer update 只会让问题更难定位、更难协同修复。

根本不是网络或权限问题，而是 Composer 解析依赖时把运行时环境（PHP 版本、已加载扩展、config.platform）也当作约束条件参与求解。常见诱因包括：

composer.json 里写了 "config": {"platform": {"php": "8.1.0"}}，但线上是 PHP 8.2 —— Composer 会按声明去匹配包，不是按真实环境
本地装了 ext-intl，线上没装，而某个包在 require 里写了 "ext-intl": "*"，install 时平台检查直接失败
composer.lock 是用 PHP 8.1 + --with-all-dependencies 生成的，但线上用 PHP 7.4 执行 install，SAT 求解器策略不同，卡在 Resolving dependencies
Git 合并时破坏了 composer.lock（比如 .gitattributes 强制 text 合并），导致字段错位或哈希失效

报错里出现 Conclusion: don't install vendor/package:v2.1.0，先别改版本号。运行：

composer why-not vendor/package:v2.1.0

它会列出所有「当前已安装包」中，哪些版本通过 require 或 conflict 封杀了该版本。如果输出为空，说明阻断源不在已安装包里，大概率来自 composer.json 根声明或 platform 配置。这时加 -v 再试：

composer why-not vendor/package:v2.1.0 -v

对比团队成员的输出：若 A 看到 laravel/framework v10.30.0 requires php ^8.1，而 B 的输出是 phpunit/phpunit v9.6 requires php >=7.3，就明确了分歧源头是 PHP 版本策略不统一。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

漏加这个参数是线上事故高频原因。它只跳过 require-dev 里的包安装，不删配置、不改 autoload 规则，但能避免把 phpunit、barryvdh/laravel-debugbar 这类工具意外装上并启用。搭配使用更稳妥：

注意：--no-dev 不影响 autoload-dev 的定义，只是不装包；但如果代码里硬写了 new \Tests\FooTest()，运行时仍会报 Class not found。

团队共享 composer.lock 的前提是它能在所有目标环境中稳定解析。合并或部署前务必确认：

所有人执行 composer show --platform，核对 php、ext-*、lib-* 输出是否一致；不一致就先统一 Dockerfile 或 .php-version
运行 composer update --dry-run，观察是否出现 Resolving dependencies 卡顿（超 30 秒基本可判定平台不兼容）
CI 流水线第一行加 composer validate --strict，校验 composer.json 和 composer.lock 是否匹配，且 JSON 格式合法