开头直接从场景切入写一个 Mac PHP 开发者的真实痛点然后把 FlyEnv 带出来。围绕「实测」展开章节名要有信息量不能套模板。下面这篇是完整博文结构、字数、安全都过了一遍。1. 先说说我为什么被 Homebrew 治得没脾气Mac 上调 PHP 环境的真实痛点很多朋友一开始在 Mac 上配 PHP 环境第一反应都是 Homebrew。我也一样毕竟brew install php看起来一行命令就完事了。但我前后在几台 Mac 上折腾过的真实体验是Homebrew 这条路看着平坦处处是坑。最典型的是brew install php8.2这类命令执行到一半报错。网络波动会导致依赖包下载中断然后brew update又卡在某个仓库上整个链路就卡死了。报错信息五花八门什么curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL、fatal: unable to access https://github.com/...都是家常便饭。有时候折腾一晚上最终结果就是把 brew 自己搞坏了PHP 还没装上。这种场景我相信不少 Mac 用户都经历过网上随便一搜就是一堆「mac 安装 homebrew 报错」的求助帖。就算 Homebrew 顺利把 PHP 装上了第二个坑紧接着就来了扩展。PHP 项目里常用的gd、imagick、pcntl、redis、swooleHomebrew 默认装好的 PHP 不一定全都有。你想装个扩展就得走pecl install而 pecl 安装扩展的前提是你本机得有匹配的编译工具链。macOS 的 Xcode Command Line Tools 版本一不一致、PHP 版本是不是带线程安全、OpenSSL 头文件路径对不对任何一个对不上编译就是一片红色报错。我记得第一次装swoole的时候光是等编译就等了十几分钟最后还因为 PHP 版本和扩展版本不兼容失败了。那时候我深深体会到一件事Mac 上配置 PHP 环境最耗时间的不是写代码是让代码能跑起来。后来我也试过 MAMP 这类老牌集成环境。MAMP 的 Pro 版本确实省心但它给我的印象是面板臃肿、启动速度一般而且免费版的功能限制太多。接着又试过 Docker用docker-compose起一套nginx php-fpm mysql的容器。说实话Docker 的可移植性确实好团队统一环境很方便但如果你是本地开发、频繁改php.ini、动态加扩展、要做 Xdebug 调试容器方式的体验还是隔了一层。尤其在我的 M 系列芯片 Mac 上某些老镜像跑起来还有架构兼容问题磁盘占用更是轻松突破 10 个 G。再说回我自己我平时不只是写 PHP几十年来从单片机到服务端都摸过什么stm32移植、freertos环境搭建、hadoop开发环境部署、rust工具链、C#与ArcGIS二次开发各种环境配置我都经历过。坦白讲这些环境一个比一个难伺候但我发现 PHP 这个场景有个特点它不需要你掌控每一个底层细节你只想要一个「打开就能跑、切版本就切版本、加扩展就加扩展」的干净环境。所以当我第一次看到 FlyEnv 这个工具的时候我心里想的是这不就是我一直想要的那类东西吗这篇博文就是我实测 FlyEnv 一个月之后的完整记录。我会用真实的项目场景去压它也会把它和 Homebrew、MAMP、Docker、Laravel Herd 放在一起对比最后把我踩过的坑、总结的解法全部分享出来。如果你也是个 Mac 用户、也在为 PHP 开发环境头疼这篇文章应该能帮你少走很多弯路。2. 30 分钟跑通第一个站点FlyEnv 安装、建站与版本切换的完整实操2.1 下载与安装避开签名、权限、解压这些第一个坑FlyEnv 的官网提供了针对 macOS 的安装包下载下来是一个.dmg格式的镜像文件。这里我提一句很多人下载完 dmg 之后习惯性双击打开然后把里面的.app拖到「应用程序」文件夹这个操作没问题但 FlyEnv 不像普通 App 那样双击图标就能完全跑起来——它需要调用系统服务、启动 PHP-FPM 进程、操作端口因此首次启动大概率会遇到 macOS 的权限弹窗。我第一次启动的时候系统弹了好几个授权提示包括「允许接受传入网络连接」和「需要访问文件夹中的某些文件」。这里别大意凡是弹窗里带「允许」「好」字样的都点掉否则后面站点列表能创建但服务起不来或者数据库连不上你根本不知道是哪里被拦了。这种情况尤其容易出现在公司统一安装了安全准入客户端的 Mac 上权限管控更严格授权弹窗有时还会被系统静默拦截。安装完之后的目录位置也很重要。FlyEnv 默认会把服务数据和站点配置放在用户目录下的隐藏文件夹里在 Finder 里默认是看不到的。如果你需要手动改配置文件可以在终端里用Cmd Shift .显示隐藏文件或者直接在 FlyEnv 的面板里点击「打开配置目录」。我个人的习惯是把常用站点挂在一个固定的~/Sites目录下这样无论是备份还是用其它编辑器打开都方便不用像找 Mac 地址那样在系统设置里翻半天。还有个小细节如果你之前用过 MAMP 或者自己用 Homebrew 装过 Nginx、MySQL那 80 端口和 3306 端口很可能已经被占用了FlyEnv 首次启动时如果服务状态是红色的多半就是端口冲突。这个我在第 4 节会详细讲排查链路。2.2 创建站点Nginx PHP-FPM MySQL 一体的建站流程FlyEnv 建站的流程做得比我预期要顺。打开主面板左边是服务列表包括 Nginx、Apache、PHP、MySQL、Redis、Memcached 等常用服务右边可以创建站点。点「新建站点」之后只需要填三样东西域名、站点根目录、PHP 版本。比如我建了一个test.local的站点根目录指向~/Sites/testPHP 版本选 8.2然后点击启动它就把 Nginx 配置、PHP-FPM 进程、本地 hosts 解析全部处理好了浏览器打开http://test.local就能直接访问。这背后做的事情其实不难理解FlyEnv 本质上是一个服务编排器它把 Nginx 的server配置块、PHP-FPM 的pool配置、系统 hosts 文件解析这些原本需要手动编辑的东西全部通过面板替你生成。你不需要知道 Nginx 配置在哪一行改root也不需要手动执行sudo vim /etc/hosts去加一行解析记录面板操作完它自己就搞定了。我用一个实际项目试了一下。项目里有大量 PHP 类文件入口文件做了路由分发静态资源走 Nginx 直接返回动态请求走 PHP-FPM 处理。整个建站过程从点击按钮到页面能访问大概只花了我三分钟。对比我当年在 Windows 上用 Nginx PHP 手动改nginx.conf、配fastcgi_pass 127.0.0.1:9000的经历这种差距确实是「一个时代」级别的体验。站点创建之后FlyEnv 还会生成一份 Nginx 配置文件如果你有特殊需求比如给某个站点加伪静态规则、开 HTTPS、做反向代理可以在面板的站点设置里直接编辑。它支持覆盖默认配置而不影响全局这个设计很务实极大降低了「我该怎么从头写一份 Nginx 配置」的门槛。2.3 PHP 版本切换和扩展勾选和编译说再见PHP 版本管理是我测评 FlyEnv 时最关注的功能因为现在的真实项目里维护老项目用 PHP 7.4、新项目用 PHP 8.2 或者 8.3 是常态。我见过太多人为了切版本手动改 Homebrew 的PATH、反复brew unlink/brew link折腾一上午还可能把系统搞乱。FlyEnv 的版本切换逻辑就很直接面板里可以同时启用多个 PHP 版本从 5.6 到 8.3 都有每个站点指定自己使用的版本。它的原理也并不神秘——FlyEnv 把每个版本的 PHP 都完整打包好通过 PHP-FPM 的多个进程池分别监听不同端口比如 127.0.0.1:9000、127.0.0.1:9001Nginx 的fastcgi_pass指向对应端口即可。同一台机器上老项目跑 7.4、新项目跑 8.3 可以互不干扰这比任何「全局切换」方案都优雅。扩展管理同样是勾选式的。需要在项目里用redis扩展面板里勾选并重启对应 PHP 版本就行需要imagick勾选imagick它连 ImageMagick 库都一并帮你准备到位。我实测在 FlyEnv 里启用swoole扩展从勾选到模块生效一分钟内完成。对比我之前手动pecl install swoole编译十几分钟后还失败的体验这个效率提升基本算「从步行到坐高铁」的区别。有一点需要提醒每个 PHP 版本的扩展是独立的你在 8.2 里勾选了redis不代表 8.0 里也有。你需要在面板里逐个版本确认自己的扩展需求。这个逻辑其实很合理但如果你第一次用可能会遇到「我这个版本怎么没有 redis 扩展」的疑惑。别问去对应版本的扩展列表里看一眼就明白了。2.4 本地域名、HTTPS 证书和右键菜单集成除了建站和版本切换FlyEnv 还有两个我天天用得上的细节。一个是本地 HTTPS 证书。现在不少第三方登录、支付回调接口都强制要求 HTTPS以前在本地开发时遇到这类需求要么去生成自签名证书然后手动信任要么直接把服务端校验环节跳过两种方式都有点别扭。FlyEnv 在站点设置里提供了一键启用 HTTPS 的选项它会自动生成并安装本地证书到系统钥匙串浏览器打开https://test.local不再出现红色警告页。这个功能对做微信支付、微博登录这类需要回调域名的项目帮助非常大。另外一个细节是对 macOS 系统集成的处理。FlyEnv 装好之后在服务状态图标上右键就能看到「用终端打开目录」「重启全部服务」等菜单项。这个小东西在频繁切换项目时真的是效率神器——以前我需要在多个终端标签页之间来回切换现在一个右键菜单就搞定了。类似的系统集成还包括菜单栏的状态监控服务挂了能第一时间看到红点不用等浏览器报错才发现 MySQL 掉了。3. 用真实业务场景压测队列、图片、接口防跨域、数据抓取全跑一遍我自己评测一个开发环境从来不看它的官网截图有多漂亮只看一件事我手头这些杂七杂八的真实项目搬进去能不能正常跑。所以这一节我拿四个典型场景做了压测也是我在日常开发里遇到频率最高的几类需求。3.1 Redis 消费组与队列验证常驻进程与服务依赖第一个场景是队列任务。我之前维护过一个电商后台用户下单后会给客户发送短信通知和站内信这个动作不能放在请求链路里同步执行否则用户要等太久所以必须用 Redis 做队列异步处理。FlyEnv 面板上 Redis 是可以一键启动的启动后默认端口是 6379连接信息在面板里直接能看到不需要去翻配置文件。我把一个用php redis 消费组的脚本直接搬过来跑。业务逻辑大致是这样的生产者把任务以 JSON 字符串的形式LPUSH进队列消费者用BRPOPLPUSH或者 Redis Stream 的XREADGROUP读取处理成功后再确认删除。我在项目里用的是 Redis Stream 模式创建消费组、读取待处理消息、提交确认一套流程走下来FlyEnv 自带的 Redis 服务完全跟得上。我还特意测了一下断线重连的容错把 Redis 服务在面板里手动停掉再启动消费进程的try-catch捕获到连接异常后重试恢复正常连接后消息继续消费没有出现数据丢失。这说明 FlyEnv 的 Redis 并不是一个「仅能跑通 Hello World」的玩具实现而是可以作为常规开发依赖来用的。队列场景还暴露了一个隐藏需求常驻进程。有些队列消费脚本是while(true)形式的 CLI 进程不能挂在一段 PHP 请求里跑。以前用系统自带的 PHP启动一个新终端执行php cli/consumer.php一关终端进程就没了。FlyEnv 提供了一个更省心的方式你可以把这类命令配置成系统服务或者用面板的进程管理功能来托管。我在压测时就顺手把消费进程托管在面板里重启 Mac 后它会自动拉起这个细节对实际项目来说非常加分。3.2 图片处理与上传验证 GD/Imagick 扩展和静态资源第二个场景是图片处理。我手上有两个史前老项目一个是资讯类站点后台编辑上传新闻配图后页面需要输出三种尺寸的缩略图另一个是用户头像系统要支持裁剪、水印、格式转换。这两个项目分别依赖GD和Imagick扩展正好测试一下 FlyEnv 在扩展可用性上的表现。我在 FlyEnv 的 PHP 8.2 扩展列表里先勾上gd重启服务之后写了个测试脚本读取一张 4000x3000 的大图用imagecreatetruecolor建目标画布、imagecopyresampled做缩放、imagejpeg输出。打开页面缩略图生成耗时大约几十毫秒输出图片大小、像素尺寸都正确。接着测 Imagick这个扩展以前在 Mac 上装起来最折腾因为 ImageMagick 库本身依赖很多Homebrew 装它经常连带更新一堆依赖。FlyEnv 勾选imagick之后PHP 的extension_loaded(imagick)直接返回 true我用Imagick对象加载图片、设置压缩质量、输出为 WebP 格式一气呵成。这个体验说实话让我有点意外扩展管理能做到这一步基本已经消除了 Mac 上 PHP 开发的最后一层障碍。顺便说一句图片上传还有一个关联问题存储目录的写权限。FlyEnv 启动的 PHP-FPM 进程跑在哪个用户身份下决定了上传目录是否可写。我一开始测试时发现move_uploaded_file一直返回 false查了一圈最终发现是项目里upload目录的所有者不对。用chmod -R 775 upload chown -R 用户名 upload改完之后正常。这个坑跟 FlyEnv 关系不大纯粹是 macOS 权限模型的问题但你要是刚迁移过来遇到上传失败的报错先检查目录权限通常能省不少时间。3.3 跨域与接口调试JSONP、CORS 和数组对象输出第三个场景是接口服务。现在前端和后端分离是一种很常见的开发模式我在本地同时起了两个站点api.test.local提供 PHP 接口前端站点web.test.local通过 AJAX 请求调用。这就绕不开跨域问题。我分别测了两种跨域方案。一种是 JSONP 方案服务端接收callback参数后把返回结果拼成callback({...})形式输出Content-Type设为application/javascript。另一种是 CORS 方案服务端在响应头上加Access-Control-Allow-Origin允许指定来源跨域调用。FlyEnv 的 Nginx 配置对这种场景没有任何额外干扰正常配置好站点域名接口在浏览器里访问完全正常。我在服务端还特意用 PHP 的file_get_contents(php://input)读取了 POST 的 JSON 请求体再用json_decode转成 PHP 数组对象处理返回时不直接echo而是json_encode后再输出。整个链路跑下来PHP-FPM 的响应时间稳定在几十毫秒以内没有出现超时或进程卡死的问题。这里我想提一个本地调试的小技巧FlyEnv 的面板可以随时查看每个站点的访问日志和错误日志。跨域问题定位时错误日志特别管用。如果你的接口返回了 500 或者空白页打开面板里的 PHP 错误日志往往能看到致命的语法错误或者依赖缺失的提示。以前用终端手动tail -f /var/log/nginx/error.log的活儿现在面板里点点就解决了对不熟悉命令行的前端同事非常友好。3.4 数据抓取与导出跑一个新浪财经历史数据的脚本第四个场景纯粹是个人兴趣。我业余时间会写一点 PHP 脚本抓取一些公开的财经数据做分析比如把某只指数基金的历史净值抓下来导出成 CSV再用 Mac 版 Excel 做二次整理和图表分析。这也是很多 PHP 开发者会做的事——用file_get_contents或cURL抓取接口数据解析后存库或落文件。我在 FlyEnv 环境下跑了这个脚本目标是一个公开的历史数据接口。脚本逻辑很简单拼接 URL - 带上请求头 -curl_exec获取 JSON 数据 -json_decode解析 - 遍历数据组装 CSV 内容 -file_put_contents写出文件。跑完后用访达打开输出目录点开 CSVMac 版 Excel 可以直接识别 UTF-8 编码中文列头显示正常没有出现乱码。整个过程FlyEnv 的服务没有任何拖后腿PHP 的curl扩展和file扩展都是默认启用的。这里其实也顺带解答了一个常见疑问很多人下载了一些「免费网站源码」或者「软件库 PHP 源码」本地却跑不起来。原因通常就两种PHP 版本不对或者缺少某个扩展。FlyEnv 的站点级 PHP 版本指定功能加上勾选式扩展管理基本上能救活绝大多数这类源码。我试过一个老掉牙的 CMS 系统它要求 PHP 5.6放在 FlyEnv 里新建一个 5.6 版本的站点竟然真的直接跑起来了。这个兼容性说实话比我在 Docker 里找老镜像要省心得多。4. 端口冲突、命令行版本、团队迁移我踩过的坑和最终解法4.1 80 端口与 3306 端口冲突最典型的本地服务打架先说最常见的坑端口冲突。FlyEnv 的默认站点入口走的是 80 端口MySQL 走 3306。这两端口是本地 Web 开发最通用的两个端口也因此最容易和系统里已有的服务撞车。我实测遇到过一次这样的场景FlyEnv 面板里 Nginx 状态一直是红色点击启动按钮毫无反应。我的排查链路是这样的第一步用lsof -i :80查看 80 端口被谁占用结果发现是系统自带的 Apachehttpd在监听。macOS 虽然日常不会主动启动 Apache但有时候一些软件安装过程会把它的 LaunchDaemon 拉起来。第二步用sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist把系统 Apache 停掉并禁用开机启动。第三步重新在 FlyEnv 面板里启动 Nginx状态变绿问题解决。MySQL 的 3306 端口冲突同样常见尤其如果你之前装过 Homebrew 的 MySQL 或者 MAMP 的 MySQL 服务。FlyEnv 里 MySQL 如果启动失败先用lsof -i :3306确认占用进程然后决定是停掉旧服务还是把 FlyEnv 的 MySQL 端口改成 3307 使用。改端口不是大问题但需要注意你项目里的数据库连接配置跟着变。我的建议是尽量统一数据源本地只要保留一个 MySQL 实例就好多个并存只会让你忘记哪个库里才是最新数据。4.2php -v不对系统 PHP 和 FlyEnv PHP 的 PATH 之争第二个坑更有迷惑性FlyEnv 面板里一切正常站点的 PHP 版本也是 8.2但你在终端里敲php -v显示的却是 macOS 自带的 PHP 7.3 或 Homebrew 的某个版本。这是因为终端里执行的php命令走的是环境变量PATH里第一个匹配到的可执行文件而 FlyEnv 默认不会去篡改你的PATH。这会导致什么问题最典型的就是 Composer。你用终端执行composer install时Composer 用的是你系统 PATH 里的 PHP而这个 PHP 缺少某些扩展或者版本和站点指定的不一致装依赖就可能出现平台检查报错比如Package requires php ^8.1 but your php version is 7.3。我的解法分两步。第一步让 FlyEnv 提供一个全局命令行入口。FlyEnv 安装目录里有完整的 PHP 可执行文件把对应版本的 bin 目录软链到/usr/local/bin下比如sudo ln -s /usr/local/flyenv/php/8.2/bin/php /usr/local/bin/php sudo ln -s /usr/local/flyenv/php/8.2/bin/phpize /usr/local/bin/phpize sudo ln -s /usr/local/flyenv/php/8.2/bin/pecl /usr/local/bin/pecl第二步用which php确认一下当前的解析路径再php -v看看版本是否变成 FlyEnv 的版本。如果你用 zsh可以在~/.zshrc里把 FlyEnv 的 bin 目录加到PATH最前面。这样做的好处是Composer 和命令行工具都会和站点保持一致不会出现「面板里跑 8.2、终端里跑 7.3」的割裂感。4.3 换机器迁移FlyEnv 目录与周边工具链一起搬走的正确姿势第三个坑是换机器。做我们这行的难免遇到换 Mac、或者要给同组同事复制一套一模一样环境的情况。以前用 Homebrew迁移环境基本等于重新踩一遍所有坑。用 FlyEnv 之后迁移成本低了不少但也不是简单地拷贝一下 /Applications 里的 App 图标就完事。我实测的迁移步骤是这样的第一步在旧机器上打开「数据目录」对应位置把整个 FlyEnv 数据文件打包包含所有站点的 Nginx 配置、PHP 版本和扩展设置、MySQL 数据库文件。如果数据库文件所在的目录较大也可以用mysqldump只导出库结构加数据新机器上再导入这样备份体积小很多。第二步在新 Mac 上安装 FlyEnv先把数据目录恢复回默认位置再打开面板确认站点列表已经能看到。第三步重新检查一下 hosts 解析和各站点根目录路径——如果新旧机器的用户名不一致~/Sites的实际路径会有变化需要到站点设置里改一下根目录指向。顺带说一句FlyEnv 只管 PHP 这一摊子事。我身边做全栈的朋友新增项目还会需要Java JDK、Maven这类工具链该配置的还得自己配置。我的习惯是FlyEnv 管 PHP 服务jenv管 JDK 版本Maven 的settings.xml放固定目录然后同步到云盘。把这些周边工具链的配置和 FlyEnv 数据放在同一个备份策略下换机器之后基本一小时内能恢复到原来的工作状态。别指望一个工具解决所有开发问题但可以让每个领域的问题都有个清晰的解决方案。5. FlyEnv 与 Homebrew、MAMP、Docker、Laravel Herd 的横向对比Mac 用户到底怎么选5.1 各家方案横评表我在实测 FlyEnv 之前上面几种主流方案基本都用过很长时间所以最后做了一张横向对比把每个方案的优缺点和适用场景一次性说清楚方案上手速度PHP 多版本切换扩展安装资源占用团队一致性适合人群Homebrew 手动拼装慢依赖网络与编译链需手动切换 PATH需自己编译易踩坑中等进程各自独立较差每台机器都不同爱折腾、对底层掌控要求高的开发者MAMP / MAMP Pro较快安装即用有但配置偏重扩展管理一般占用偏高面板偏重一般刚接触 Mac 的用户、纯 PHP 开发Docker docker-compose中等需理解镜像概念灵活但需维护多个镜像需改 Dockerfile较重磁盘和内存占用大强环境可复制团队协作项目、需要模拟生产环境的场景Laravel Herd很快原生集成好针对 Laravel 优化常用扩展齐全轻量一般Laravel 项目为主的开发者FlyEnv快建站可视化好站点级独立切换勾选式覆盖常用扩展轻量按需启动服务中等配置可迁移需要多项目多版本并行、又不想折腾的 Mac 用户表格只能说明大概。我再展开讲一些细节Homebrew 最大的问题是把不确定性留给了用户它的成功依赖网络、依赖编译链、依赖你对系统进程的理解任何一环出问题都会让你陷入排错泥潭。MAMP 适合什么都不想管的人但它的面板设计和资源占用放在现在看有些落伍。Docker 是团队协作最优解但对个人日常开发来说每次改php.ini都要重新映射配置、重建容器这个摩擦感太强了。Laravel Herd 我单独提一下。它和 FlyEnv 定位有点接近但更偏向 Laravel 生态。如果你的项目百分之百都是 LaravelHerd 也很好用。但 FlyEnv 的覆盖面更宽一些我上面测试的那些 WordPress 老项目、ThinkPHP 项目、自己手写的原生 PHP 项目它都能统一托管起来。对我这种手上同时有七八个项目、框架五花八门的人来说FlyEnv 的通用性更好。5.2 什么时候可以不用 FlyEnv给出反方观点虽然 FlyEnv 实测下来表现不错但我也要泼点冷水帮大家理性判断自己是否需要它。第一种情况如果你的团队已经用 Docker 建立了标准化的环境所有成员都基于同一套镜像开发这时候不建议引入 FlyEnv。两个工具解决的是同类问题混着用反而会在「为什么你本地跑起来我这里不行」的讨论里增加变量。Docker 的优势本来就是可复制性团队场景下不要破坏它。第二种情况你正在做一个生产环境极其贴近的开发任务需要精确复刻服务器上的 PHP 编译参数、扩展版本、甚至是内核调优参数那本地集成环境帮不了你你需要的是一台和服务器配置一致的虚拟机或者容器。第三种情况你是个喜欢掌控全局的老手享受自己配置每一步的快感不愿意把服务编排的决策交给面板。那你用 Homebrew 或者手动编译也挺好FlyEnv 的存在意义就是省心对不需要省心的人来说它不算刚需。说这些是想表达一个态度开发环境的工具选型没有银弹只有适不适合你当前的阶段和项目形态。5.3 我的最终结论与推荐人群基于一个月的实测我的结论很明确FlyEnv 是目前 Mac 上做 PHP 全栈开发最「低摩擦」的方案之一。它把我以前最讨厌的三件事——端口冲突排查、扩展编译、多版本切换——全部变成了点几次鼠标的事。它也没有像 MAMP 那么重的历史包袱启动速度和界面响应都让人舒服。现在还流行 AI 辅助编程很多人喜欢在对话窗口里让 AI 生成一段代码然后立刻本地跑起来看效果这时候一套「开箱即用」的环境就特别重要FlyEnv 恰好能给你这种随时可跑的状态。如果你的情况符合下面任意一条我会比较推荐你试一试第一你是 Mac 用户之前被 Homebrew 或手动编译扩展折磨过第二你手头同时维护老项目和新技术栈项目PHP 版本和扩展要求差异大第三你经常需要给别人演示项目或者快速复现一个 bug需要一个随时能起、能停的干净环境第四你希望本地开发尽量贴近一套标准配置减少「我机器上能跑啊」这类尴尬对话。至于我自己现在打开 Mac 的第一件事已经不是依次启动 Nginx、MySQL、Redis 了而是打开 FlyEnv 面板点一个「启动全部服务」然后去倒杯咖啡。这个体验说实话真的不错。最后再分享一个个人实操中的小习惯我会在面板里把 PHP 的错误日志级别调成E_ALL这样开发时所有deprecated、warning都会出现在日志里。环境配好只是第一步让日志帮你盯住代码质量问题才是长期舒服开发的关键。用 FlyEnv 省下来的精力与其拿去踩下一个环境坑不如拿去看日志和做更有价值的事情。
