composer install 报“找不到 composer.lock”时不会自动降级执行，而是明确报错中止；必须通过 composer update 生成 lock 文件，因其语义是解析依赖而非复现锁定版本，缺失 lock 将导致多环境依赖不一致。
迁移后直接 composer install 报错“找不到 composer.lock”
这是最常见的情况：旧项目没提交 composer.lock，或新环境漏掉了它。Composer 在没有 composer.lock 时会降级为 composer update 行为，不仅慢，还会装最新兼容版，可能引入不兼容变更。
实操建议：
- 先确认原项目根目录下是否存在
composer.lock—— 它比composer.json更关键； - 如果缺失，别急着
composer install，优先从原部署机、CI 构建产物、或 Git 历史中找回（git log --all -- composer.lock）； - 实在找不到，再用
composer update --lock生成一个最小化 lock 文件（仅锁定当前composer.json中声明的版本约束），再运行composer install； - 注意：这种生成方式不会复现历史安装结果，仅适合开发环境临时补救。
用了镜像源但 composer install 仍卡在 “Loading composer repositories”
迁移常发生在不同网络环境（比如从国内服务器迁到海外 CI），而 composer config -g repo.packagist 里还留着旧镜像配置，导致请求超时或 404。
实操建议：
- 运行
composer config -g --list | grep repo查看全局镜像设置； - 临时禁用镜像：执行
composer config -g repo.packagist composer https://packagist.org； - 若需保留镜像，确保新环境能访问对应地址（例如阿里云镜像
https://mirrors.aliyun.com/composer/需要出口 IP 在白名单内）； - 加
-vvv参数调试：composer install -vvv，观察卡在哪个 URL，再针对性处理 DNS 或代理。
PHP 版本不一致导致 composer install 失败或装错依赖
Composer 会根据当前 PHP 版本过滤 composer.lock 中满足 php 平台约束的包版本。比如 lock 文件里某包只标注了 "php": "^8.1"，但在 PHP 7.4 环境下就会跳过，转而装一个更低版本（甚至失败）。
实操建议：
- 迁移前先运行
php -v，和原环境比对； - 检查
composer.lock顶部的platform字段（如有），或查看各包的require.php值； - 若 PHP 版本较低，不要强行降级装包，优先升级 PHP；
- 万不得已需兼容低版本 PHP，可临时指定平台：
composer install --ignore-platform-req=php（仅调试用，生产禁用）。
vendor 文件夹权限或磁盘空间不足导致解压失败
尤其是从 Windows 打包迁移到 Linux 时，vendor 下某些文件可能带 Windows 特有属性，或解压过程因 noexec、inodes 耗尽、磁盘满而中断，报错类似 failed to open stream: Permission denied 或 tar: Unexpected EOF in archive。
实操建议：
- 清空残留：
rm -rf vendor composer.lock（先删 lock 再重装更稳妥）； - 检查磁盘：
df -h .和df -i .； - 确认当前用户对项目目录有读写权限，且未挂载为
noexec或nosuid； - 避免用
root用户执行composer install，否则 vendor 下文件属主为 root，后续 Web 服务可能无法加载。
真正耗时的不是命令本身，而是搞清 lock 文件来源、PHP 版本边界、和当前环境的真实限制——这三处任一出问题，composer install 就会变成黑盒等待。
