composer install是唯一能复刻原项目依赖环境的操作，因其严格按composer.lock的版本、commit hash、dist url和sha256校验和安装，不解析composer.json约束；复制vendor目录90%失败，因含平台路径、abi痕迹和权限问题；迁移前必须确保composer.lock存在且未修改、vendor为空、php版本及扩展满足lock中platform声明。
composer install 是唯一能复刻原项目依赖环境的操作，前提是 composer.lock 存在且未被修改、vendor/ 为空、PHP 环境匹配。其他方式都会导致版本漂移、类加载失败或运行时异常。
为什么必须用 composer install 而不是 composer update
composer update 会忽略 composer.lock，重新解析 composer.json 中的版本约束（如 ^2.0），求解“最新兼容版本”，结果不可控：
- 装上
monolog/monolog3.6.0 而不是 lock 里锁死的 3.5.0，可能触发未测 BC break - Git 包拉取新 commit，但原项目依赖的是特定 hash，行为已不可复现
- CI 流水线构建产物与本地不一致，线上偶发
Class not found
composer install 则严格查表执行：只读 composer.lock，按其中记录的精确版本号、dist URL、SHA256 校验和、Git commit hash 安装，不碰 composer.json 的任何约束。
composer install 执行前必须检查的三件事
缺一不可，否则失败常发生在运行时而非安装阶段：
-
composer.lock必须存在且未被.gitignore屏蔽：运行ls -la | grep composer.lock确认；若缺失，需回原环境执行composer update --lock -
vendor/必须为空或不存在：旧文件残留会干扰 autoloader 映射，引发类行为错乱；执行rm -rf vendor再运行 - 当前 PHP 版本和扩展必须满足
composer.lock顶部"platform"字段声明：例如"php": ">=8.1.0"，用php -v和php -m核对，比看composer.json更准
私有包拉取失败时怎么快速定位
composer.lock 里若含 GitLab、Satis 或本地路径包，composer install 会严格按 lock 记录的源地址拉取，但不会自动处理权限或 fallback：
- 报
Cloning into ''或401 Unauthorized：说明缺认证凭据，需在项目根目录放auth.json，内容为{"http-basic": {"gitlab.example.com": {"username": "token", "password": "PAT_abc123"}} - 报
Could not find a matching version of package xxx：目标源中该包不存在，或源地址已失效；可用--repository-url临时指定，值必须是合法 JSON，如{"type":"vcs","url":"https://gitlab.example.com/php/shared-utils.git"} - 避免 SSH URL（如
git@gitlab.example.com:）——CI 环境通常没配 SSH key，HTTPS + PAT 更可控
离线环境或 U 盘迁移后 autoload 失效怎么办
直接拷贝 vendor/ 到新机器，vendor/autoload.php 常因绝对路径硬编码或 classmap 缓存未更新而失效：
- 删掉旧
vendor/，在目标机执行composer install --no-dev --prefer-dist（确保 lock 中有 dist 归档） - 若必须用已有
vendor/（如无网络），先运行composer dump-autoload --optimize重生成 autoload，跳过旧路径缓存 - 确认自定义 autoload 路径（如
src/）存在且权限可读；Linux 下 U 盘挂载常带noexec或 uid/mask 错误 - 禁用
--classmap-authoritative，除非你刚完整扫描过所有类——U 盘迁移后通常没扫过
composer.lock 是否真实反映原环境、PHP 是否真满足 platform 声明、私有源是否在新机器上可触达——这些细节不验证，composer install 成功了也不等于能跑起来。
