Composer install 报错“lock file 不兼容”是因为当前 PHP 版本、扩展或 Composer 版本与 composer.lock 中 platform 声明不一致，需检查 PHP 版本、启用扩展是否匹配，而非直接 update。

composer install 为什么报错“Your lock file does not contain a compatible set of packages”

这是 composer install 最常卡住的地方：你本地没改 composer.json，但执行时却提示锁文件不兼容。根本原因不是锁文件坏了，而是当前 PHP 版本、平台配置（如 ext-mbstring 是否启用）或 Composer 自身版本，和生成 composer.lock 时的环境不一致。

• 检查当前 PHP 版本是否满足 composer.lock 里 platform 字段声明的要求（比如锁文件写的是 "php": "^8.1"，而你用的是 PHP 7.4）
• 运行 composer show --platform 确认已启用的扩展是否匹配锁文件中声明的 platform 依赖
• 别用 composer update 强刷——这会重写 composer.lock，破坏协作一致性；应先统一开发环境，而不是绕过校验

composer install 和 composer update 到底该用哪个

一句话：团队协作项目里，只要存在 composer.lock，就只用 composer install；只有你自己在加/删/改 composer.json 中的依赖时，才用 composer update。

Workflow Decomposer

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

下载

• composer install 严格按 composer.lock 安装指定版本，确保所有人的 vendor 目录完全一致
• composer update 忽略锁文件，重新解析 composer.json 并拉取符合约束的最新兼容版本，同时重写 composer.lock
• CI/CD 流水线必须用 composer install --no-dev（如果不需要测试依赖），否则可能因 dev-only 包触发不必要的安装或权限问题

安装时跳过 autoload 生成或脚本执行

某些场景下（比如构建镜像、只部署 runtime 环境），你不需要自动生成 vendor/autoload.php，也不希望执行 post-install-cmd 类钩子——这些默认行为反而拖慢速度甚至失败。

• 加 --no-autoloader 跳过 autoload 文件生成（后续需手动调用 composer dump-autoload）
• 加 --no-scripts 阻止所有 scripts 段定义的命令执行（比如 Laravel 的 post-root-package-install）
• 若仅想跳过 dev 相关脚本，用 --no-dev --no-scripts 组合更稳妥，避免某些包把关键逻辑塞进 dev script 里

为什么 vendor 目录里有些包没被装上

不是 Composer 漏装，而是这些包被标记为 replace 或 provide，或者你的平台配置主动排除了它们。

• 检查 composer.json 中是否有 "replace" 字段（常见于 fork 替换原包），这类包不会实际安装
• 运行 composer why-not vendor/package-name 查看某个包为何未被安装（比如冲突、PHP 版本不满足、被 conflict 规则挡掉）
• 某些包声明了 "type": "metapackage"（如 laravel/framework），它本身不提供代码，只用来聚合依赖，所以 vendor 里看不到它的源码目录

锁文件不是摆设，它是多人协作时唯一能守住依赖确定性的防线。很多人在本地跑通就以为没问题，结果上线后因平台差异崩在 autoload 阶段——这时候再回头查 PHP 扩展列表，比重装系统还磨人。