是，composer self-update能否原生运行取决于php及git、unzip等工具是否均为arm64架构；需用file $(which php)和file $(which git)等命令逐一验证，任一x86_64组件都会触发rosetta转译。
Composer 本身不区分 arm64/x86_64，但 self-update 能否原生运行，完全取决于你当前的 PHP 和关键工具链是否为 arm64 架构。 如果其中任一环节（比如 php、git、unzip）是 x86_64，self-update 过程中就会触发 Rosetta 转译——你可能感觉不到卡顿，但子进程启动变慢、内存占用翻倍、偶尔 hang 住，都是典型信号。
如何确认 PHP 是 arm64 原生？
这是最关键的一步。不要只看 php -v 输出，要查二进制文件实际架构：
- 运行
file $(which php)，输出里必须含arm64；若含x86_64，说明 PHP 正在被 Rosetta 翻译 - 检查 Homebrew 是否为 ARM 版：
which brew应返回/opt/homebrew/bin/brew，而非/usr/local/bin/brew - 如果
brew install php@8.2后仍是 x86_64，大概率残留了 Intel 版 Homebrew 的旧配置，需手动清理/usr/local/etc/php并重装
为什么 self-update 成功了却还是 Rosetta 转译？
因为 composer self-update 只更新 composer.phar 文件，它不控制子进程。而 Composer 在执行时会调用 git、unzip、curl 等命令——这些工具若不是 arm64，系统会自动拉起 Rosetta 实例。
- 逐个检查：
file $(which git) $(which unzip) $(which curl)，全部应显示arm64 - 常见陷阱：用 Intel 版 Homebrew 装的
git，即使 PHP 是 arm64，composer install或self-update中的 fetch 阶段仍会转译 - 修复方式：
brew reinstall git（确保当前是 ARM Homebrew），或手动删掉/usr/local/bin/git再重装
self-update 报错 “The openssl extension is required” 怎么办？
这不是 Composer 错误，而是你的 PHP CLI 缺少 OpenSSL 扩展。M1/M2 上用 Homebrew 安装的 PHP 默认不启用该扩展，尤其在未配置 php.ini 时高频出现。
- 先确认：
php -m | grep openssl，无输出即缺失 - Homebrew PHP 的扩展配置文件通常在
/opt/homebrew/etc/php/8.2/php.ini（路径随版本变化），打开后取消注释extension=openssl - 重启终端或重新加载配置（如使用 zsh，执行
source ~/.zshrc），再试composer self-update
真正容易被忽略的是：即使所有命令都显示 arm64，只要 composer.lock 里有依赖预编译扩展（如 ext-igbinary），且对应 .so 文件是 x86_64 编译的，self-update 虽能跑完，后续 install 仍会在静默中失败或报 undefined symbol。这类问题不会出现在 self-update 日志里，得等真正装依赖时才暴露。
