每个 PHP 开发者的电脑里都少不了一个“本地环境工具箱”。但工具箱和工具箱之间的差别往往比很多人想象中要大得多。我在技术群里最常见的一类问题就是PHPStudy 和 FlyEnv 到底选哪个大多数人的思路是二选一我的答案却是两个都装而且两个都在日常开发里扮演不同的角色。我不是那种喜欢把工具囤一堆、每个都用不上的人。恰恰相反正因为我在 PHP 开发这条路上踩过太多环境相关的坑才慢慢摸索出一套“双工具箱”的用法。这篇文章不打算给你一份标准答案而是把我为什么同时保留 PHPStudy 和 FlyEnv 的完整思路、实际配置、冲突处理和踩坑记录都摊开来讲清楚。如果你也经常被本地环境折腾得头疼或者正纠结要不要从其中一个切换到另一个这篇应该能给你一个不同的参考角度。1. 这不是一道二选一的题两个工具解决的是不同层级的问题很多人把 PHPStudy 和 FlyEnv 放在同一个天平上对比然后试图找出“哪个更好”。我最初也是这么干的但用久了以后发现这个问法本身就有点问题。打个比方这就像问“工具箱里的螺丝刀和扳手哪个更好”——答案取决于你眼前是哪种螺丝、哪种螺母。PHPStudy 和 FlyEnv 虽然都叫“本地环境工具”但它们侧重的场景其实是两套逻辑。1.1 当我用 PHPStudy 时我在解决“开机即用”的问题PHPStudy 是老牌集成环境管理工具了它的核心价值概括成四个字就是“一键启停”。不管是 Apache、Nginx、MySQL 还是 PHP 多版本装好之后基本都是可视化界面里点几下就能跑起来。对于要快速验证一段代码、复现客户报的 bug、或者做一个临时演示PHPStudy 的响应速度是最快的。这也决定了它的定位它是一个“全局环境管理面板”。它默认服务是面向整台电脑的你把 MySQL 启动那它就在 3306 端口等着连接你把 Nginx 启动那它就在 80 端口监听。这种设计对一个开发者常年只做一套技术栈的人来说非常高效。我接触过的很多 PHP 老项目thinkphp 3、Laravel 5、甚至更早的 CI 框架在 PHPStudy 里切个 PHP 版本、配一下伪静态规则基本都能跑起来兼容性相当稳。1.2 当我用 FlyEnv 时我在解决“项目隔离”的问题FlyEnv 这个工具是这几年才在我日常里频繁出现的它走的是另一条路线更强调按项目隔离环境。你可以单独为某一个项目指定 PHP 版本、指定扩展、指定 Nginx 配置还可以把 MySQL、Redis 这些服务编排在项目范围内来管理。这解决了一个 PHPStudy 模式下很难受的问题——全局污染。举个例子你电脑上同时有三个项目一个要求 PHP 7.4一个要求 PHP 8.1还有一个要用到 Redis另外两个用不到。在传统集成环境里你需要手动切版本、启停服务稍不注意就会影响正在运行的其他项目。FlyEnv 的按项目配置方式相当于给每个项目一个“独立小房间”互不干扰。所以你看一个解决“快速启动”和“全局兼容”一个解决“项目隔离”和“环境可控”。这不是同一个需求的两个候选方案而是两个不同需求各自的最优解。为了更直观地理解我把两个工具在我的工作流里的定位做过一个简单对比对比维度PHPStudyFlyEnv核心定位全局集成环境管理面板项目级环境编排工具上手门槛极低适合新手中等需要理解项目配置的概念多版本切换全局切换操作直观按项目指定隔离性强服务管理集中启停 MySQL/Nginx/Apache/Redis 等可单独管理项目依赖的服务适合场景快速验证、旧项目维护、临时环境多项目并行、现代框架开发、团队成员协作资源占用全局服务常驻占用相对固定按需启动但改造成本略高这两个工具在我电脑里不是竞争关系而是互补关系。下面我展开说说每个工具到底在什么具体场景中“不可替代”。2. PHPStudy 为什么一直留在我的开发机里快速验证与旧项目兜底先说 PHPStudy。虽然我后来花了不少时间折腾 FlyEnv但 PHPStudy 始终没有被卸载原因很简单它做对了三件事。2.1 开机即用的“兜底环境”干 PHP 开发的人应该都有这种经历有时候收到一段别人扔过来的代码或者线上突然报了个错你需要最快速度在本地起一个环境来复现。这时候打开 PHPStudy点一下“启动 Nginx”和“启动 MySQL”再往根目录里丢一个 index.php几秒钟就能开始调试。这种“随手可用”的体验是我对本地环境最基本的要求。相比之下如果我要用 FlyEnv 去跑一个临时接手的压缩包代码我得先创建项目、配置 Nginx 站点、确认 PHP 版本、再加 MySQL 数据库流程是完备但前置步骤多了不少。并不是说 FlyEnv 不好而是它在设计上并不追求“零思考快速启动”这个目标。临时救火这种活还是 PHPStudy 顺手。2.2 旧项目和特定扩展环境的兼容性PHP 生态里有一个绕不开的现实存量老项目非常多。公司内部管理系统、客户维护了七八年的电商站、外包交付的遗留代码这些项目往往用的是 PHP 5.6、PHP 7.0 甚至更老的版本还依赖一些老扩展。PHPStudy 对这类场景的兼容做得非常扎实。它内置的 PHP 版本列表覆盖很广而且可以在面板里直接切换 Apache/Nginx 的版本组合还能一键开启常用扩展。我记得有一次接手一个使用 php_dbase 操作 DBF 文件的老系统当前 PHP 7.4 里已经移除了这个扩展我花了一下午编译扩展都没搞定最后是 PHPStudy 里切换到 PHP 5.6 版本扩展早已内置直接跑通。这种时候FlyEnv 或者 Docker 都帮不上忙反而是“传统集成环境”的老底子更管用。2.3 数据库运维的顺手程度PHPStudy 集成的 phpMyAdmin 对新手和日常快速操作来说依然是效率工具。虽然安全性上我一直强调生产环境别用但在本地要导出、导入一个几百 MB 的 SQL 文件或者快速看一眼表结构phpMyAdmin 的体验是现成的、稳定的。FlyEnv 里也有数据库管理的入口但很多高级操作还是习惯性回 PHPStudy。再加上 PHPStudy 在 Windows 环境下的权限问题处理比较成熟MySQL 服务不会动不动因为权限原因启动失败。Mac 用户可能感受不到Windows 下本地环境各种服务能否稳定被拉起这本身就是很大的一个价值点。2.4 一个典型的踩坑记录PHPStudy 中 MySQL 无法启动用 PHPStudy 也不是没踩过坑最典型的就是 MySQL 无法启动。我遇到过两次现象一致面板里点启动状态闪了一下绿色然后又变红日志文件里只有一句笼统的报错。第一次排查时我以为是端口被占。跑到命令行执行netstat -ano | findstr :3306发现 PID 对应的是另一个本地开发工具的服务。那时我才想起来之前为了测试给另一个工具也装过 MySQL两个服务抢同一个端口PHPStudy 当然拉不起来。解决办法很简单把那个多余服务的端口改掉或者先停掉它PHPStudy 的 MySQL 就能正常启动。第二次遇到类似问题是在系统强制重启之后。那次检查了端口没有被占日志提示的是ibdata1文件异常。当时第一反应是 MySQL 数据文件损坏后来才知道是上次非正常关机导致 InnoDB 的 redo log 没有正常 flush。好在那只是本地测试库我直接备份了 data 目录下的业务库文件把 MySQL 数据目录临时改到一个新目录启动成功后重新导入 SQL问题解决。这件事给我的经验是本地 MySQL 出问题先按这个顺序排查——端口占用、磁盘空间、数据文件权限、最后才是配置错误。别一上来就重装重装是最后的办法。2.5 PHPStudy 的使用建议用 PHPStudy 这几年我沉淀下来的使用心得只有几条根目录和站点路径不要放在 C 盘系统盘Windows 更新、权限变动都可能影响项目读写。生产环境不要用 phpMyAdmin 远程管理数据库这玩意儿只适合本地开发。版本切换后记得确认 CLI 的 PHP 版本是否也切过来了。PHPStudy 面板里切换的版本有时候只影响 Apache/Nginx 的模块命令行里的php -v可能还是原来那个。命令行版本这个问题尤其容易被忽略后面我会单独讲操作方案。3. FlyEnv 让我留下来的核心项目隔离与现代化开发工作流聊完 PHPStudy再来说说 FlyEnv。我在文章开头提到它是“项目级环境编排”这里展开讲讲它到底是怎么改变我的开发方式的。3.1 一个严重被低估的需求项目之间的环境隔离大多数 PHP 开发者最开始都是 PHPStudy 或者类似的集成环境起步的。这个模式有个潜在问题所有项目都跑在同一套 PHP、同一套 MySQL 实例里A 项目为了临时调试改了 PHP 配置B 项目可能第二天就跑不了C 项目的数据库连接串写的是 localhost:3306D 项目的连的也是同一个稍不注意就误操作了数据。项目少的时候这种问题不明显项目一旦多起来全局环境就变成了谁都不敢动的公共区域。FlyEnv 的核心设计就是为解决这件事而来的。你可以把每个项目当成一个独立单元单独指定它的 PHP 版本、PHP 扩展、Nginx 配置甚至单独管理这个项目依赖的 MySQL 数据库。用的时候启动这个项目不用的时候停掉完全不影响其他项目。我第一次用 FlyEnv 跑一个 Laravel 11 项目的感受非常深PHP 8.2、Composer 依赖、Redis、队列用的数据库连接全部按项目配置好之后我关掉了原本全局运行的 MySQL 和 Nginx整个电脑安静了很多内存占用也明显下降。从此我再也不用担心“为了跑新项目把老项目的环境弄坏”了。3.2 FlyEnv 的配置逻辑一段服务编排文件搞定一切FlyEnv 和传统面板的另一个关键差异在于它的配置是可文件化的。传统面板里你点点点设置都保存在工具自己的数据目录里换电脑、传给别人环境无法一键复现。FlyEnv 这种用配置文件描述项目和服务的工具天生就适合把环境配置纳入代码仓库统一管理。我在项目根目录维护了一份本地环境配置文件里面声明了当前项目依赖的 PHP 版本、Nginx 站点参数、MySQL 数据库名等。新同事入职把代码拉到本地用 FlyEnv 导入配置启动项目一套环境就起来了前后不到十分钟。这比之前“写一页文档教新人怎么装环境”舒服太多了。3.3 与 Composer、Node、Redis 的配合体验现在做 PHP 项目基本绕不开 Composer而 Composer 要求的 PHP 版本和运行扩展经常与项目不完全一致。FlyEnv 对我来说很好的一点是它在项目内管理 PHP 版本的方式让 Composer 的执行环境也和项目默认环境一致。简单说我在终端里跑composer install它用的就是当前项目指定的那套 PHP而不会出现“项目里明明配置了 PHP 8.2命令行却还在用 PHP 7.4 解析 Composer”这种错位。除了 PHP本地开发还要跟前端工程配合。FlyEnv 也可以把 Node 相关的服务纳入编排范围跑 Laravel Mix 或者 Vite 时Node 版本也可以按项目锁定。虽然这些能力不是 PHP 开发必备但确实让本地环境这个“工具箱”的覆盖面更完整了。3.4 一年使用下来 FlyEnv 的一些注意点FlyEnv 并不是没有代价的。第一次从传统面板迁到 FlyEnv 时我花了一些时间理解它的配置模型。另外因为它更偏向“开发者工具”新手第一次用可能会觉得不如集成面板那么直观特别是没有现成 phpMyAdmin 那种一键管理界面数据库操作得靠 Navicat 或者命令行之类的工具辅助。不过一旦你跨过“项目隔离”这个学习曲线再回去用全局面板会明显觉得别扭——你会开始担心这个项目改了环境会不会影响那个项目。我现在的工作习惯是长期维护的项目都放在 FlyEnv 里管理临时验证和旧项目兼容在 PHPStudy 里解决。两个工具箱各司其职。4. 两套环境共存后那些一定会遇见的冲突与解决办法既然我同时保留了 PHPStudy 和 FlyEnv就必须正视一个问题两个工具都管理 Nginx、MySQL服务端口和系统资源难免产生冲突。这一节我把我实际碰到过的冲突和对应的处理方案完整列出来希望能帮你少走弯路。4.1 MySQL 端口冲突3306 是兵家必争之地最常见的冲突是 MySQL 端口。PHPStudy 的 MySQL 默认监听 3306FlyEnv 里的 MySQL 服务默认大概率也是 3306。两个工具同时启动的时候后启动的那个必定失败日志里往往只有一句含糊的错误根本定位不到原因。我的处理办法是端口规划而不是只用其中一个。既然我要让两个工具箱同时存在干脆让它们各自用独立的端口。我给 PHPStudy 的 MySQL 保留 3306给 FlyEnv 的项目 MySQL 指定 3307 端口。这样一来两个环境的数据库可以同时在线连接互不影响。具体操作用例在 FlyEnv 对应的项目配置里把 MySQL 服务定义一段的 host 端口映射改为 3307然后在项目.env文件里把DB_PORT也改成 3307两边对齐即可。PHPStudy 那边不用动。如果你的场景刚好相反那就改 PHPStudy 的 my.ini 里的port 3307效果是一样的。4.2 Nginx 端口冲突80 端口只有一个Nginx 默认监听 80 端口Apache 默认监听 80 或 8080这又是一个容易打架的点。我最初两套一起用的时候经常出现“明明启动成功了浏览器访问 localhost 却打不开”的情况原因就是两个 Web 服务器在抢 80 端口。我的规划方式是一个工具用 80 端口做默认 Web 入口另一个工具改成 8081 等自定义端口。比如 PHPStudy 这边启动的 Nginx 继续监听 80方便临时项目直接通过localhost/xxx访问FlyEnv 管理的项目站点则统一使用独立端口访问比如http://localhost:8081。这样就不会有冲突了。如果你是同时启动两个 Nginx 实例还要注意它们的日志和临时文件目录不要设置成同一个否则运行时可能会出现权限或文件锁冲突。本地开发虽然不至于崩但日志文件互相覆盖这种问题排查起来很浪费时间。4.3 命令行 PHP 版本乱掉PATH 环境变量的优先级问题这个坑比上面两个更隐蔽也更影响日常效率。Windows 下安装 PHPStudy 或 FlyEnv 时它们往往会往系统 PATH 里加自己的 PHP 路径。当两个工具都加了 PATH 时你在命令行输入php -v最终生效的到底是哪一版完全取决于 PATH 里的顺序而不是你“当前打开了哪个工具”。这种错乱特别恼火因为你在面板里明明切到了 PHP 8.2命令行一查却还是 PHP 7.4Composer 也跟着用错版本。我的解决方案是不依赖工具的全局 PATH而是自己维护命令行环境变量。我在系统 PATH 里只保留一个默认的 PHP 路径通常是 PHPStudy 的然后在具体的项目终端里通过 FlyEnv 提供的终端工具进入项目环境——它会在当前会话里临时把项目的 PHP 版本放到 PATH 最前面。这样项目内命令行和项目环境完全一致终端窗口一关系统环境还是原样不会污染全局。对我来说这个“工具提供的项目终端”是一个很大的加分项。它把“环境隔离”从面板里延伸到了终端会话中整个开发链路都是互相匹配的。4.4 服务启动顺序和资源占用最后提一下开机自启的问题。两个工具箱如果都设置了开机自动启动一开机内存就会被顶得很高。我的办法是PHPStudy 不开机自启需要的时候手动打开FlyEnv 也不设置自启但我平时主要用哪个项目会在工作前手动启动那个项目环境。这样电脑开机后是干净的状态内存留给编辑器、浏览器和数据库客户端人也清爽很多。冲突类型现象我的处理方案MySQL 端口3306 被占导致服务无法启动保留一个 3306另一个改 3307并同步改 .envWeb 端口80 被占导致访问失败一个用 80另一个用 8081 等独立端口PATH 版本错乱php -v 与面板版本不一致只留一个全局 PATH项目内用工具自带终端自启服务冲突开机后多个服务抢占资源全部取消自启按需手动启动5. 一套可复制的“双工具箱”工作流配置参考前面讲了很多理念和冲突处理这一节我把我目前电脑上的实际工作流从头到尾整理出来供你参考。当然我的配置只是其中一种合理方案你可以按自己的项目类型调整。5.1 目录规划把代码、服务数据、临时目录分开我的本地方案里三个目录各司其职D:\Work\Projects所有正式开发的项目代码每个项目一个子目录。D:\DevTools\PHPStudyPHPStudy 安装目录服务数据默认在其下一般不手动动它。D:\DevTools\FlyEnvFlyEnv 安装目录项目环境配置和本地服务数据都在里面。代码目录和服务工具目录分开很重要。过去我把项目直接放在工具默认的 WWW 根目录里后来工具升级、重装项目路径被影响非常被动。现在项目一律放在独立目录工具只是“运行这些项目的手段”互相不绑定。迁移环境时只要重新配置工具指向代码目录即可。5.2 项目环境配置文件示例以一个使用 Laravel 框架的项目为例我在项目根目录放了一份本地服务编排配置文件内容大致是# 本地环境配置示例具体字段以你使用的工具版本为准 name: shop-api services: web: type: nginx port: 8081 root: ./public php: 8.2 database: type: mysql version: 8.0 port: 3307 database: shop_api_local user: shop_dev password: local_dev_password cache: type: redis port: 6380项目里的.env文件对应配置如下APP_URLhttp://localhost:8081 DB_CONNECTIONmysql DB_HOST127.0.0.1 DB_PORT3307 DB_DATABASEshop_api_local DB_USERNAMEshop_dev DB_PASSWORDlocal_dev_password REDIS_HOST127.0.0.1 REDIS_PORT6380这样做的直接好处是任何一个新同事拉到代码后只要安装好 FlyEnv导入这份服务编排配置再执行composer install和php artisan key:generate本地项目就能跑起来。不用再靠 Word 文档手把手教“先装 PHPStudy再改 php.ini再建库”环境配置跟着代码走等于把“环境”这个以前不可控的因素纳入了版本管理。5.3 数据库管理的分工因为我给两个工具的 MySQL 分配了不同端口管理上也有明确分工PHPStudy 的 3306 MySQL用来跑临时验证脚本、旧项目数据库以及一些随手要用的本地业务数据。FlyEnv 的 3307 MySQL只放 FlyEnv 管理的正式项目的数据库。这样划分之后我永远不会出现“连错数据库”的问题因为端口本身就代表了一套环境边界。数据库可视化工具里我也分别建了两个连接命名成“PHPStudy-Local”和“FlyEnv-Projects”一眼就能分清。5.4 几个自动化的小优化如果你愿意多花一点时间还可以做两个优化第一在项目根目录写一个.env.local文件把本地方案里那些特定端口、特定路径放进去然后让.gitignore忽略它。这样队友拉代码后自己的本地差异配置不会污染公共代码。第二用命令别名把常用操作缩短。比如在终端里定义一个flystart命令用于启动当前目录对应的项目环境。不用每次都在工具图形界面里点来点去。命令行习惯一旦建立日常操作的效率会提升不少。6. 双工具箱之外的几点真实心得与选择建议最后聊几个争议点也是我经常被问到的问题。6.1 什么时候其实一个工具就够了如果你满足下面这些条件未必需要两套并存项目数量很少两三个以内技术栈统一PHP 版本常年不变。基本都是一个人开发不需要给团队搭统一环境。你主要写一些临时脚本、维护小站点对项目隔离没有痛感。这种情况下老老实实用 PHPStudy 或 FlyEnv 其中一个就好多一套工具就多一份维护成本。我的双工具箱方案本质上是为了解决多项目、多版本、多依赖同时存在的复杂场景。没有这个复杂度就不需要这个方案。6.2 什么时候改用 Docker 更合适FlyEnv 解决的还是“本地一套环境”的问题如果你已经进阶到需要完全复刻生产环境、或者团队规模大到必须统一所有成员环境那 Docker 容器化是更彻底的方向。用 Docker Compose 可以把 PHP、Nginx、MySQL、Redis 全部容器化环境一致性最强。但我必须说Docker 在 Windows 本地开发的门槛和资源占用都不低特别是老项目的本地文件读写性能、端口映射、容器和宿主机之间的文件同步都需要额外配置。因此我的路线是临时和兜底用 PHPStudy多项目隔离用 FlyEnv需要跟生产环境严格对齐的模块再单独用 Docker。三种手段各管一段不会用其中一种硬扛全部需求。6.3 团队协作时尽量把环境配置当成代码来管不管是 PHPStudy、FlyEnv 还是 Docker我认为最值得养成的习惯是把本地环境配置当成代码来维护而不是当作某个机器上的私有记忆。项目依赖什么 PHP 版本、需要哪些扩展、数据库初始化的方式、Redis 是否需要密码这些都写在项目文档或配置里。这样换电脑、招新人、找前任同事交接都不至于从零摸索。我自己有一次惨痛教训一个老项目完全跑在 PHPStudy 的全局服务里数据库账号、密码、端口全都只存在于当时那台电脑的配置中。后来电脑更换我花了整整一天才把项目重新跑起来中间还因为某些扩展版本不匹配浪费了很多时间。从那以后我强制自己在每个项目的 README 里写清楚环境要求并用 FlyEnv 这类可配置的工具来固化环境描述。如果你现在还是“本地环境能跑就行从不管它是怎么搭的”状态我真心建议选择一个项目花半小时把环境配置梳理清楚。这个半小时投入的回报会在未来每一次换机、每新增一个协作者时被放大很多倍。工具会不断更新但“按需求分层选工具、把环境纳入版本管理”这个思路是长期适用且不会过时的。