Composer install触发mach-o架构错误的根本原因是PHP解释器与扩展的CPU架构不一致，如arm64 PHP加载x86_64扩展，需统一为arm64架构：检查file $(which php)和file $(php -r "echo PHP_EXTENSION_DIR;")/ext.so，用Homebrew重装arm64 PHP及pecl安装扩展，必要时arch -arm64手动编译。
Composer 本身不报 mach-o 架构错误，真正出问题的是它拉下来的 PHP 扩展（比如 igbinary、redis、protobuf）或你本地的 PHP 二进制本身。
为什么 Composer install 会触发架构报错
当你执行 composer install 时，如果项目依赖了含 C 扩展的包（如 ext-redis），Composer 会调用 phpize + make 编译。若当前 PHP 是 Rosetta 2 下运行的 x86_64 版本，但系统默认 clang 或 Homebrew 已切换为 arm64，则编译产物会出现 have 'x86_64', need 'arm64' 或反过来的冲突。
- 典型错误信息：
dlopen(.../redis.so, 0x0002): tried: ... (mach-o file, but is an incompatible architecture) - 根本不在 Composer，而在 PHP 运行时加载扩展的环节
- Homebrew 安装的 PHP（
php@8.3）默认是 arm64，但如果你用arch -x86_64 brew install php装过，就混了
确认 PHP 和扩展的真实架构
别猜，直接查：
- 看 PHP 解释器架构：
file $(which php)—— 输出含arm64或x86_64 - 看已加载扩展架构：
php -r "echo PHP_EXTENSION_DIR;"，然后file $(php -r "echo PHP_EXTENSION_DIR;")/redis.so - 检查当前 shell 架构：
uname -m（应为arm64）；若输出x86_64，说明你在 Rosetta 终端里
重装 PHP 及扩展必须统一 arm64
Homebrew 是最稳妥路径（避免手动编译踩坑）：
- 卸载所有 PHP 相关：
brew uninstall --ignore-dependencies php@8.1 php@8.2 php@8.3 - 清理残留：
rm -rf /opt/homebrew/etc/php（Homebrew 默认路径） - 只装 arm64 版：
brew install php@8.3（不要加arch -x86_64） - 装扩展用 pecl，但必须指定 arm64 编译：
pecl install redis→ 它会自动调用正确的phpize和clang - 验证：
php -m | grep redis+php -i | grep "PHP Extension Dir"
遇到 pecl 编译失败？手动强制 arm64 编译
某些扩展（如 igbinary）的 pecl 包没及时更新，可能仍尝试用 x86_64 工具链。这时跳过 pecl，源码直编：
- 下载源码：
curl -L https://github.com/igbinary/igbinary/archive/refs/tags/4.2.3.tar.gz | tar xz - 进入目录后执行：
arch -arm64 phpize && arch -arm64 ./configure && arch -arm64 make && sudo make install - 确保
extension=igbinary.so写入php.ini，且php --ini显示该 ini 文件被加载
关键点不是“让 Composer 工作”，而是确保整个 PHP 生态（解释器、扩展、编译工具）全链路跑在 arm64 下——哪怕只有一环是 x86_64，mach-o 错误就会在 php -v 或 composer install 后首次 require 扩展时爆发。
