必须确保php为arm64原生架构且使用阿里云镜像源，并配置platform.arch=linux/arm64及清理x86_64残留文件，否则即使换镜像仍会卡在依赖解析或执行报错。
确认 PHP 和 Composer 都是 arm64 原生架构
加速源只是表象，如果底层 PHP 是 Rosetta 转译的 x86_64 版本，换再快的镜像也卡在 Resolving dependencies 或直接报 illegal instruction: 4。必须先验证：
运行 file $(which php)，输出里得有 arm64；
运行 which php，路径必须是 /opt/homebrew/bin/php；
运行 php -v，版本建议 ≥ 8.2，且不能带 x86_64 字样。
用阿里云镜像源替换 Packagist 默认源
默认源 https://packagist.org 在国内访问极不稳定，超时、空响应、慢到以为卡死——这不是你网络问题，是源本身基础设施限制。
执行这条命令即可全局生效：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：composer config -g repo.packagist 应输出该 URL。
注意：这个配置只影响包元数据下载（即 Loading composer repositories 阶段），不改变 vendor 中二进制文件的实际来源。
强制平台声明，防 x86_64 二进制混入 vendor
即使用了国内镜像，某些包（比如 spatie/image）仍可能拉到 x86_64 的预编译二进制（如 vendor/bin/gm），在 ARM 下执行直接报 cannot execute binary file: Exec format error。
加一条平台约束，让 Composer 主动过滤非 arm64 包：composer config -g platform.arch linux/arm64
必要时可再禁用二进制包分发：composer config -g bin-dir null（让工具走纯 PHP 实现，比如用 phpunit/phpunit 替 phpunit/phpunit-bin）
清理残留 x86_64 二进制再重装
之前跑过 composer install 的项目，vendor/ 里很可能藏着已失效的 x86_64 文件，Composer 不会自动删它们。
手动清掉常见嫌疑项：find vendor/ -type f -name "*.so" -o -name "gm" -o -name "convert" | xargs rm -f
然后重新安装关键依赖，强制走源码编译：composer reinstall ext-xdebug --ignore-platform-reqs
如果是 Laravel Sail 这类工具，还要检查 vendor/bin/sail 是否含 --platform linux/amd64，得改成 --platform linux/arm64。
composer install 的耗时通常从 5–10 分钟降到 30 秒内，但前提是 PHP 真正在 arm64 下跑、vendor 里没遗留 x86_64 文件——这两点最容易被忽略，也是绝大多数“换了镜像还是慢”的根本原因。
