直接用系统自带PHP启动最省事：macOS Sonoma及以上预装PHP 8.1+，执行php -S localhost:8000即可快速启动内置服务器用于开发调试，无需安装配置，但仅限本地测试，不支持生产环境。
直接用系统自带PHP启动最省事
如果你只是想快速跑一个PHP脚本测试逻辑，或临时调试单文件，php -S 是最快路径——不用装任何东西，不改配置，不启服务。macOS Sonoma 及更新系统都预装 PHP 8.1+，足够应付基础需求。
常见错误现象：php: command not found（其实是 zsh 没加载系统 PATH）、浏览器访问 http://localhost:8000 显示空白但无报错（默认路由没匹配到文件）、404 Not Found（请求的 PHP 文件不在当前目录下）。
- 确保你在项目根目录执行：
php -S localhost:8000，不是随便某个路径 - 如果提示
command not found，运行which php看是否输出/usr/bin/php；没输出就手动加路径：export PATH="/usr/bin:$PATH"临时生效 - 它不解析
.htaccess，也不支持 Apache 的 rewrite 规则；要处理路由，得自己写router.php并用-t指定文档根目录，例如：php -S localhost:8000 router.php - 仅限开发，禁止用于生产：没有并发控制、无 HTTPS、不支持长连接、无法处理静态资源缓存
Homebrew装PHP + Nginx + PHP-FPM是主力方案
这是目前 macOS 上最可控、可复现、易维护的组合，适合日常开发、多版本切换、需要扩展（如 pdo_mysql、gd）的项目。
容易踩的坑集中在三处：PHP-FPM 监听地址与 Nginx 配置不一致、php.ini 路径被忽略、权限导致 502 Bad Gateway。
立即学习“PHP免费学习笔记（深入）”；
- 安装后务必检查 PHP 版本：
php -v，确认输出的是 Homebrew 安装的版本（路径通常是/opt/homebrew/bin/php），不是系统自带的 - PHP-FPM 默认监听
127.0.0.1:9000，Nginx 的fastcgi_pass必须严格匹配；Apple Silicon Mac 上部分旧版配置写成unix:/opt/homebrew/var/run/php-fpm.sock更稳定，需同步修改php-fpm.d/www.conf中的listen行 -
php --ini才是找对php.ini的唯一可靠方式；Homebrew 的配置文件在/opt/homebrew/etc/php/8.3/php.ini（版本号随安装变动），别去改/etc/php.ini - 启动顺序不能错：先
brew services start php，再brew services start nginx；停服务也得反着来，否则 Nginx 可能卡在502
Apache + 系统PHP适合零配置尝鲜
系统自带 Apache 和 PHP 绑定简单，适合第一次接触 PHP、只想看 phpinfo() 是否生效的人。但它最大的问题是 PHP 版本老旧（Sonoma 默认是 8.1，Ventura 是 7.4），且扩展启用麻烦。
典型问题：Parse error: syntax error, unexpected token "..."（PHP 8.1 不支持 8.2+ 的新语法）、Call to undefined function mysqli_connect()（扩展没启用）。
- 启动 Apache：
sudo apachectl start，不是apachectl start（少 sudo 会失败） - 编辑
/etc/apache2/httpd.conf时，只取消注释这一行：LoadModule php_module libexec/apache2/libphp.so；其它 PHP 相关模块（如php7_module）是过时的，删掉或注释掉 - PHP 文件必须放
/Library/WebServer/Documents/，不能放你自己的项目目录里；想换路径就得改DocumentRoot并重启 Apache - 扩展启用靠改
php.ini，但系统 PHP 的php.ini在/etc/php.ini.default，得先复制一份并重命名：sudo cp /etc/php.ini.default /etc/php.ini，再编辑
Docker部署LEMP环境适合团队协作
当你需要和同事共享完全一致的环境、项目依赖特定 PHP 扩展版本、或要模拟生产服务器行为时，Docker 是唯一靠谱的选择。它不污染宿主系统，也能绕过 macOS 对 php-fpm 权限的奇怪限制。
实际痛点不在写 docker-compose.yml，而在 volume 挂载权限、时区同步、以及 Composer install 失败这类“看着像PHP问题、其实是容器权限问题”的情况。
- 挂载代码目录时，用
./src:/var/www/html:delegated（macOS），别用cached或默认模式，否则文件变更不实时 - PHP 容器内用户是
www-data，但宿主机文件属主是你的用户；在docker-compose.yml里加user: "501:20"（对应 macOS 用户 UID/GID）可避免Permission denied - 务必在 PHP 容器里运行
date.timezone = Asia/Shanghai，否则date()返回 UTC 时间；宿主机时区不会自动透传进容器 - 不要在容器里装 Composer：宿主机装好
composer，然后composer install --no-dev生成vendor后再挂载进去，比每次docker-compose up都跑一遍快得多
真正麻烦的从来不是“怎么装”，而是“装完之后哪条路径生效、哪个 php.ini 在起作用、谁在监听哪个端口”。Mac 上 PHP 环境冲突的核心，永远是 PATH、配置文件位置、服务监听地址这三者的错配。动手前，先跑一遍 which php、php --ini、lsof -i :8000，比盲目改配置高效十倍。
