Composer安装过程中中断如何继续安装
Composer安装中断后能否继续，取决于composer.lock、installed.json及缓存ZIP文件的完整性。若完整，重试命令会跳过已安装的包；若损坏或不完整，需手动删除vendor目录和全部缓存再重新安装。常见原因包括ZIP文件损坏、installed.json截断或内存不足。低带宽时可配置国内镜像，或手动下载ZIP文件到缓存。
先说说我这几年的经验：Composer 安装半路中断，直接重来一遍究竟能不能行？答案其实没那么绝对——得看你是哪种“翻车”。
直接跑 composer install 或 composer update 确实能解决不少情况，但这有个大前提——你不能遇到 ZIP 损坏、installed.json 被写一半截断、或者内存溢出直接把进程干趴了。否则你会发现，机器每次都卡在同一个包上，像中了“复读机”诅咒。
为什么重试有时有效，有时无效
Composer 能不能“续传”，关键要看三个东西是否正常运作：composer.lock 的完整性、vendor/composer/installed.json 是否可读、还有缓存里的 ZIP 文件是否能通过校验。如果这些都没被破坏，重跑之后，Composer 会聪明地跳过那些已经解压成功的包，只盯着失败或者还没开始的包干活。
- ✅ 有效场景：网络抖了一把，某个包下载超时，临时文件被清掉了，但其他包都稳稳装好了。这时候重试，直接从下一个包走起。
- ❌ 无效场景：弹出
The zip extension and unzip command are both missing（其实背后是 ZIP 包没下全）、Invalid argument supplied for foreach()（installed.json被砍了个尾巴）、或者直接显示Killed（内存不够，系统帮你强行终止了）。 - ⚠️ 最坑人的一种情况：
vendor/目录里堆着部分包，但installed.json已经坏了。这种“假成功真失败”会让重试要么报错，要么悄悄跳过那些它以为已经存在的依赖——酿成大祸。
中断后必须手动清理的几种情况
一旦碰到下面这些报错，就别再傻傻重试了，赶紧动手清理：
Failed to extract vendor/package-name: unable to open archive→ 确认 ZIP 坏了，删掉vendor/整个目录，再去~/.composer/cache/files/里找到对应的包一并清掉。Invalid argument supplied for foreach()或者解析installed.json报错 → 这个文件多半不完整，没别的办法，vendor/全部清空。- 终端突然冒个
Killed→ 这是内存顶不住了。先补上 swap，或者调高memory_limit，然后和上面一样，删掉vendor/再清缓存。
标准清理流程很简单：rm -rf vendor → composer clear-cache → 重新跑安装命令。
低带宽或不稳定网络下的稳妥做法
好过事后补锅，不如一开始就别让它翻车。几个硬功夫：
- 强制用压缩包分发：
composer install --prefer-dist（避开 git clone 那些大仓库）。 - 插件太老可能反作用：
composer install --no-plugins（特别是旧版 Prestissimo，并发一高反而容易挂）。 - 国内用户必须配镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/——说实话，比什么重试参数都管用。 - 极端慢网络还有一个绝招：先用
wget -c手动把对应的 dist ZIP 拉下来，然后放到~/.composer/cache/files/vendor/name/xxx-sha256.zip里。Composer 会自动认出它，直接跳过下载环节。
真正容易被忽略的关键点
很多人觉得中断了“继续”就是等着 Composer 自己恢复，但往往瓶颈在于接入的是 packagist.org 还是阿里云镜像、cache-dir 是否可写、vendor/ 的目录权限有没有被 IDE 或者杀毒软件怼住，Windows 下还可能有长路径的变态限制。这些因素比重新下载一次更隐蔽，更容易把所谓的“续传”变成新一轮灾难。
PHP开发中，定位类文件不应依赖composerdump-autoload（仅重新生成映射文件，不会自动发现新类）。有效方法：使用composershow--path查包路径并结合PSR-4规则定位；或使用ripgrep搜索类定义；IDE跳转需确保索引正确，来避免误定位。并且避免直接修改vendor目录。
composershow列出所有包及版本（含开发依赖），--direct查看顶层依赖，--name-only输出纯包名，--format=json输出JSON。composeroutdated检查可更新包，composershow-t显示依赖树层级。版本号基于composer.lock，不保证vendor真实状态，需先运行composerinstall（或-
使用composerclear-cache命令可以安全地清除缓存，仅清理缓存目录下的内容。安装新版本需要先删除composer.lock后执行install或update，CI/CD中务必加--no-interaction参数。在缓存目录下files/可以删除旧包以释放空间，vcs/可以安全清除，repo/不建议删除该目录以免影响依赖解析。
Composer的稳定性配置中，minimum-stability是硬性过滤闸，低于该级别的版本被直接忽略；require里加@后缀可精准授权单个包；prefer-stable仅在候选版本中影响选择；子依赖的minimum-stability可能覆盖项目设置，需用stability-flags压制，以此确保依赖版本符合预期。
Composer不安装PHP扩展，仅当执行install或update时，会检查ext-xxx是否启用，若缺失则中断并报错。扩展声明须在require或require-dev中，版本号仅用于约束，无实际校验作用。扩展名必须与php-m输出的模块名完全一致。config.platform仅模拟环境，不能绕过运行时校验。
使用Phinx时需要手动配置phinx.php或phinx.yml文件并补全数据库连接信息；迁移文件须手写up和down方法，并仔细检查字段类型及索引细节；多环境切换时必须严格确认配置优先级和命名格式，否则极易导致迁移失败甚至报错。
使用replace时需注意：它仅仅声明替代关系，不会自动删除旧包，也不会继承旧包的autoload配置。因此，开发者必须手动移除旧包，并完整配置autoload，同时添加conflict字段来避免依赖冲突。另外，replace适用于替换具体包，而实现接口则应使用provide。
Composer是Yii根基，需正确配置composer.json区分require与require-dev，准确设置入口文件autoload.php路径，用create-project安装而非直接require核心库，锁死版本约束防兼容问题，并注意cookieValidationKey等环境配置。
Postman是一套面向API全生命周期的开发与测试平台，可在Mac上发送和调试多种协议请求，管理集合、环境及认证信息，并完成脚本测试、模拟服务、监控、文档发布和团队协作。它适合开发、测试及运维人员使用，提供个人免费方案。
Docker Desktop 是 Docker 官方为 Mac 提供的容器开发环境，集成 Docker Engine、命令行工具、Compose、Build、Kubernetes 与图形化管理界面。
Android Studio 是 Google 面向安卓应用开发提供的官方集成开发环境，基于 IntelliJ IDEA 构建。它整合智能代码编辑、Gradle 构建、界面预览、设备模拟、性能分析、调试测试及 APK 分析等工具。
PixPix 是面向品牌、卖家和内容团队的在线 AI 图片视频创作平台，提供图视频 Agent、无限画布、图片生成、视频生成、自然语言编辑及商品套图、产品精修和带货视频等电商工具。
Postman 是面向 API 全生命周期的开发与协作平台。Windows 桌面版可用于构建和发送 HTTP、GraphQL、gRPC、WebSocket、MQTT 等请求，并提供环境变量、集合、脚本测试、模拟服务、监控、文档及团队工作区等
Docker Desktop 为 Windows 开发者提供集成式容器环境，内置 Docker Engine、命令行工具、Compose、Build 与 Kubernetes 等组件，可在本机完成镜像构建、容器运行、日志查看和资源管理。