composer install才是唯一正确入口，因其严格按composer.lock快照还原精确版本、commit hash和校验和，而非解析composer.json范围约束；漏lock文件、php/扩展不匹配或私有源未认证均会导致失败。
直接复制项目目录、只拷 composer.json 然后 composer install，90% 会失败——因为没带 composer.lock，也没校验 PHP 版本和扩展是否匹配原环境。
为什么 composer install 才是迁移的唯一正确入口
composer install 不是“装依赖”，而是“按快照还原”。它只读 composer.lock，严格安装其中记录的每个包的精确版本、Git commit hash（对 dev 包）、dist URL 和校验和，完全无视 composer.json 里的 ^2.0 或 ~3.5 这类范围约束。
常见错误现象：
- git clone 后直接跑
composer update→ vendor 里多出原项目没有的包，CI 报Class not found - 漏掉
composer.lock，install自动退化为update→ 本地能跑，线上ArgumentCountError - 团队有人只提交了
composer.json→ 其他人install时环境悄然分裂
必须确认三件事才执行 composer install：
-
composer.lock文件存在且未被.gitignore忽略（检查命令：ls -la | grep composer.lock） -
vendor/目录为空或不存在（install不清理旧文件，混杂加载会导致Autoload error） - PHP 版本和已启用扩展满足
composer.lock中"platform"字段声明（例如 lock 顶部有"php": ">=8.1.0"，而你本地是 PHP 7.4，就会跳过部分包甚至报Your requirements could not be resolved）
同步私有包或自定义源时卡住的典型原因
composer.lock 里若含 GitLab、Satis、本地路径等私有源包，composer install 会严格按 lock 记录的源地址拉取——但它不会帮你配权限，也不会自动 fallback。
常见错误现象：
- 报
Cloning into ''或401 Unauthorized→ 缺少对应仓库的认证凭据 - 报
Could not find a matching version of package xxx→ 源不可达，或该包在目标源中根本不存在 - 用
--repository-url临时指定源但格式非法 → 必须是合法 JSON，如{"type":"vcs","url":"/path/to/repo"}
实操建议：
- 提前在
~/.composer/auth.json或项目级auth.json中配置 token（注意：该文件不能提交到 Git） - 若用私有 Satis，确保其 provider-list 已更新，且
composer.lock中的 dist URL 可直连 - 本地路径类型包（如
"monolog/monolog": {"type": "path", "url": "../monolog"}）无法走 dist，会 fallback 到 source，且不参与并发下载——迁移前建议先转成 dist 发布
国内环境下必须立刻生效的三项全局配置
不配镜像、不调并发、不设 prefer-dist，composer install 就是慢性死亡。尤其在国内，元数据请求直连 packagist.org 是默认行为，改 repositories 数组完全无效。
必须执行（顺序不能错）：
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/—— 唯一有效写法，验证用composer config -g repo.packagist -
composer config -g parallel-downloads 10—— Composer 2.2+ 才支持，1.x 设了也白搭；CI 中若报Connection refused，可临时降为 6 -
composer config -g prefer-dist true—— 强制下 ZIP 包，避免 Git clone、SSH 认证等开销；若项目composer.json里写了"prefer-source": true，需手动删掉
执行完立即清缓存：composer clear-cache。否则它可能还在用旧的 packagist.org 元数据，镜像等于白配。
生产环境同步最易被忽略的 lock 清洁问题
composer.lock 里存着 require-dev 的完整版本记录，但 --no-dev 只跳过安装，不跳过解析。如果 lock 文件来自开发分支、含大量旧版 dev 包，可能导致主依赖被强制降级或冲突。
上线构建前务必做两件事：
- 运行
composer update --no-dev -o，强制刷新 lock 中 production 部分（-o表示--optimize-autoloader） - 检查 lock 是否干净：
grep -q '"require-dev"' composer.lock && echo "warning: dev section exists" || echo "clean" - Git 提交前确认
composer.lock在暂存区 —— 否则 CI 拉的是旧 lock，--no-dev也救不了
真正关键的不是“怎么装快”，而是“装出来的是否和原环境一模一样”：lock 文件是否原始、PHP 平台是否一致、私有源凭证是否就位、dev 包是否被污染——这些点任何一个出错，都会让迁移变成线上事故的导火索。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
