必须用 composer install 且需 composer.json 和 composer.lock 成对存在、vendor 为空、PHP 环境匹配 platform 要求；单独 composer.lock 无法还原依赖，因它仅记录安装快照，不含版本约束和 autoload 配置。
直接用 composer install，但必须满足三个前提：composer.json 和 composer.lock 成对存在、vendor/ 为空或不存在、PHP 环境匹配 lock 文件中声明的 platform 要求。
为什么不能只传 composer.lock？
单独一个 composer.lock 文件无法还原依赖 —— 它只是“安装清单”，不包含包来源、版本约束意图或 autoload 配置。没有 composer.json，composer install 会报错：Could not find a composer.json file in /path/to/project。
-
composer.json声明“想装什么”（比如"monolog/monolog": "^2.0"） -
composer.lock记录“实际装了哪个精确版本+校验和+dist URL”（比如"monolog/monolog": "2.10.0"） - 两者缺一不可；Git 提交时漏掉
composer.lock，等于每次部署都在抽盲盒
composer install 失败常见原因及应对
报错 Your lock file does not contain a compatible set of packages 是最典型信号，本质是当前 PHP 环境不满足 composer.lock 里记录的 platform 约束。
- 先运行
composer check-platform-reqs，它会明确列出缺失的 PHP 版本或扩展（如ext-mbstring、ext-xml） - 检查
composer.lock顶部的platform字段（例如"php": ">=8.1.0"），再用php -v和php -m核对 - 若只是小版本偏差（如锁文件要 PHP 8.1，你有 8.2），可临时加
--ignore-platform-reqs强行过，但得确认代码真没用到 8.2 特性 - 别用
composer update来“修复”——它会重写composer.lock，导致环境漂移
迁移前必须清理 vendor/ 目录
composer install 不会自动清理已存在的 vendor/。混杂旧文件会导致 autoloader 加载错乱、类行为不一致，甚至静默失败。
- 务必手动删掉整个
vendor/目录（rm -rf vendor或del /s /q vendor） - 确保
vendor/autoload.php不存在，否则 Composer 可能跳过 autoload 重建 - 如果项目改过
autoload配置（比如新增了 PSR-4 映射），装完后还得补一句composer dump-autoload -o - Linux 下注意路径大小写：若
composer.json写的是"App\": "app/Http/Controllers"，但目录实际是app/http/controllers，dump-autoload会生成错误映射，运行时报Class not found
私有包或镜像源配置容易被忽略
如果 composer.lock 里有来自私有 Git 仓库、Satis 或 Private Packagist 的包，新环境没配 auth 或源地址，composer install 会在下载阶段卡住或报 401。
- 检查旧环境是否设过全局 token：
composer config -g --list | grep http-basic - 在新环境补上对应配置，例如：
composer config -g http-basic.gitlab.example.com token username - 若用了自定义镜像源（如阿里云、腾讯云），确认
composer config -g repo.packagist指向正确；失效时可切回官方源：composer config -g repo.packagist composer https://packagist.org - CI/CD 中尤其要注意：某些镜像源在无 TTY 时会超时，建议加
--no-suggest参数避免 fetch 建议包
真正关键的不是“怎么导入 lock 文件”，而是确保它所依赖的上下文（PHP 版本、扩展、源配置、文件系统行为）完全复现。任何环节松动，composer install 就只是表面成功。
