Composer 本身不依赖 CPU 架构，M1/M2 上问题多因 PHP 或扩展非原生 arm64；需确认 Homebrew、PHP 及关键扩展均为 arm64，禁用 Rosetta 终端，并用官方安装器安装 Composer。
Composer 本身是纯 PHP 脚本，不依赖 CPU 架构，但它的运行完全受制于底层 PHP 环境和扩展的 ARM64 兼容性——M1/M2 上出问题，99% 不是 Composer 的锅，而是 PHP 或扩展没跑在原生 arm64 上。
确认 Homebrew 和 PHP 都是 Apple Silicon 原生版本
混用 Intel 和 ARM 工具链是 M1/M2 上 Composer 报错最隐蔽的根源。比如 brew install php 装出来却是 x86_64 版本，后续所有扩展（如 openssl、fileinfo）都会失效，导致 composer install 直接失败或报 ext-xxx not found。
- 运行
which brew，必须输出/opt/homebrew/bin/brew；若为/usr/local/bin/brew，说明装的是 Intel 版，需卸载重装：arch -arm64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
- 运行
php -v后，再执行file $(which php)，输出中必须含arm64字样；若显示x86_64，说明 PHP 是 Rosetta 模式运行，不可靠 - 验证关键扩展是否启用：
php -m | grep -E '^(openssl|fileinfo|mbstring|json)$'—— 缺任一都可能让 Composer 拒绝安装某些包
别用 brew install composer，官方已弃用
Homebrew 社区自 2023 年起将 composer 包标记为 deprecated，原因很实在：它无法保证与你本地 PHP 版本严格对齐，且常因权限、路径或 PHAR 签名问题导致 composer --version 报错或静默失败。
- 正确做法是用官方安装器直装：
curl -sS https://getcomposer.org/installer | php
- 然后手动移到 Homebrew bin 目录并赋权：
sudo mv composer.phar /opt/homebrew/bin/composer
sudo chmod +x /opt/homebrew/bin/composer - 这样生成的
composer会直接调用系统 PATH 中的php，确保与你的 ARM64 PHP 完全绑定
处理依赖时警惕平台架构“隐形假设”
Composer 不识别 arm64，但它会检查 PHP 版本和扩展是否存在。有些包（尤其是含 C 扩展的，如 grpc、igbinary、xdebug）在 require 里写了 "ext-grpc": "*"，而你的 PHP 没装 ARM64 版 grpc，就会卡住。
- 若确定目标环境有该扩展，可用
--ignore-platform-reqs绕过检查（仅限开发/CI）：composer install --ignore-platform-reqs - 更稳妥的做法是显式声明兼容平台：
{"config": {"platform": {"php": "8.3.0", "ext-openssl": "8.3.0"}}，写进项目根目录composer.json，避免本地缺失导致误判 - 查看第三方包是否提供
arm64wheel 或预编译二进制：运行pecl search grpc，确认返回结果含arm64或darwin-arm64标签
最容易被忽略的一点：VSCode 内置终端或 iTerm2 若启用了 Rosetta（右键图标 → “显示简介” → 勾选“使用 Rosetta 打开”），哪怕 brew 和 php 都是 arm64，终端启动的进程也会降级为 x86_64，导致 composer 实际运行在翻译层上——性能下降还是其次，某些扩展加载会直接失败。务必确认终端进程在活动监视器中类型为“Apple”，而非“Intel”。
