XAMPP 在 M1/M2 Mac 上不是“不能运行”，而是默认以 x86_64 架构通过 Rosetta 2 模拟运行，这导致它与原生 ARM64 的系统组件、扩展、命令行工具之间频繁出现架构错配——这才是绝大多数问题的真实根源。
确认 XAMPP 当前运行的架构
别猜，直接验证。打开终端，执行以下命令：
arch
再启动 XAMPP 控制面板后，运行：
/Applications/XAMPP/xamppfiles/bin/php -v
观察输出中是否包含 x86_64（常见于 M1 上的 XAMPP）或 arm64（极少见，除非你手动编译过）。若 PHP 输出显示 x86_64，说明整个 XAMPP 进程链（Apache、PHP、MySQL）都处于 Rosetta 2 模拟态，后续所有扩展、CLI 工具、依赖包都必须匹配该架构。
用 file /Applications/XAMPP/xamppfiles/bin/php 可进一步确认二进制文件实际架构如果 arch 返回 arm64，但 php -v 显示 x86_64，说明你当前终端是原生 arm64，但调用的 php 是 Rosetta 转译的——这是典型 PATH 混乱信号
extension=phalcon.so 加载失败：核心是架构对齐，不是文件路径
报错 PHP Warning: PHP Startup: Unable to load dynamic library ‘phalcon.so’ (tried: … (mach-o file, but is an incompatible architecture (have ‘arm64’, need ‘x86_64’))) 是最典型的症状。它不意味着扩展没放对位置，而意味着你放了一个给原生 arm64 PHP 编译的 phalcon.so，去喂给 x86_64 架构的 XAMPP PHP。
必须下载或编译出 x86_64 架构的 phalcon.so，而非从 Homebrew/MacPorts 直接安装（它们默认产出 arm64）扩展目录路径必须严格匹配 PHP 的 ZTS/NTS 和 API 版本号，例如 /Applications/XAMPP/xamppfiles/lib/php/extensions/no-debug-non-zts-20220829/（其中 20220829 是 PHP 8.2 的 ABI ID，可通过 php-config –php-api 查得）修改 /Applications/XAMPP/xamppfiles/etc/php.ini 后，必须重启整个 XAMPP 控制面板，仅重启 Apache 不生效
用 Homebrew 安装的 MySQL/PHP 与 XAMPP 冲突怎么办
Homebrew 默认安装的是 arm64 版本，且其 mysql 或 php 命令会抢占 PATH，导致你在终端里敲 mysql 用的是 Homebrew 的，但 XAMPP 控制面板里连的是它自带的 x86_64 MySQL——两个服务监听同一端口（3306），必然起一个崩一个。
临时方案：启动 XAMPP 前，在终端执行 export PATH="/Applications/XAMPP/xamppfiles/bin:$PATH"，确保优先调用 XAMPP 自带工具长期方案：彻底卸载 Homebrew 的 mysql 和 php（brew uninstall mysql php），改用 XAMPP 自带服务；如需 CLI 开发，用 XAMPP 的 /Applications/XAMPP/xamppfiles/bin/mysql 显式调用切勿同时运行 Homebrew MySQL 和 XAMPP MySQL，端口冲突不会报错，只会静默失败或连接超时
为什么不用原生 arm64 的替代方案（如 Laravel Valet + Homebrew PHP）
可以，而且更轻量。但如果你已深度依赖 XAMPP 的控制面板、phpMyAdmin 集成、特定版本 Apache 模块或遗留项目配置，强行切换会引入新的兼容层（比如 Valet 对 M1 的 nginx 配置仍偶发 DNS 解析异常）。XAMPP 的价值在于“开箱即用的确定性”，代价就是接受 Rosetta 2 的存在。
真正容易被忽略的一点是：php.ini 文件有两份——XAMPP 控制面板读取的是 /Applications/XAMPP/xamppfiles/etc/php.ini，而终端里 php -i | grep ‘Loaded Configuration File’ 显示的可能是另一份（比如 Homebrew 的）。改错地方，等于没改。
评论(0)