1. 为什么需要FlyEnv本地环境管理工具到底在解决什么问题1.1 多项目并行开发时的经典痛点做Web开发的人尤其是PHP、Node、前端全栈混着做的几乎都经历过这种状态电脑上的开发环境越装越多最后变成一锅粥。今天要维护一个客户在两年前交付的老系统项目用的是PHP 7.0扩展还是老一套明天新接了一个项目一开始就要求PHP 8.2起步不然框架跑不起来。数据库那边更麻烦老项目只认MySQL 5.7的排序规则新项目想着直接用8.0的新特性。再加上Nginx、Apache、Redis光是把它们同时装进系统里端口冲突就能让人调一个下午。我见过不少同行解决这类问题的方式是“装两套环境需要哪个开哪个”。这种做法的代价很明显切换成本高、环境间相互干扰、改系统配置时容易把另一套环境搞挂。以前我为了兼容两个PHP项目手动改过无数次系统环境变量、PATH、php.ini的扩展路径每次切换还要重启命令行、清理php进程缓存效率极低而且特别容易出错。更麻烦的场景是两个项目都要常驻跑着——一个接口服务要给前端联调用另一个后台任务在持续采集数据这种“不能停旧项目又要起新项目”的需求单靠手动切换版本的工具根本做不到。本地开发环境管理工具解决的核心问题就在这。简单来说它把“装一个全局环境项目去适配环境”的旧逻辑颠倒过来变成“每个项目声明自己需要的环境由工具来分配和切换”。在Linux服务器上我们习惯用Docker去隔离但在本地开发机上Docker特别吃内存WSL2里挂着虚拟机再加上IDE和浏览器16G内存的电脑已经开始喘了。于是越来越多的人开始寻找更轻量、更贴近本地原生体验的替代方案。FlyEnv就是在这样一个背景下被越来越多人提到的工具它跟Laragon、XAMPP这类方案在思路上有相似处但在项目可配置性和版本切换体验上做了一些自己的取舍。1.2 传统环境和Docker方案各自的短板要搞明白一个工具好在哪得先知道替代方案差在哪。先拿最常见的集成环境来说这类工具的特点是“开箱即用”装完打开控制面板启动Nginx、启动MySQL本地就能跑项目。但它默认给你的是写死的一套组合一个PHP版本、一个MySQL版本、一个固定的网站根目录。项目多了以后要么把老项目往上兼容要么把新项目往下妥协。老项目在PHP 8.2上跑报错一大片deprecated警告刷屏甚至直接白屏最后只能拿兼容层补丁来补补的时候还不一定找得到历史扩展。再来看Docker方案。理论上Docker是最标准的解法每个项目一个容器组PHP版本、MySQL版本全部隔离互不干扰。可我自己用下来本地开发场景里有几个很实际的摩擦点。第一磁盘占用高每个项目拉一个PHP镜像加数据库镜像动辄几个G第二启动速度慢尤其用Docker Desktop的时候文件挂载在macOS或Windows下性能会打折刷新一下页面等一两秒是常有的事第三断点调试和本地服务联动很麻烦Xdebug要从容器里把端口映射出来本地工具要连库还得暴露端口还要配置权限。对一个只想快速改两行代码、刷新页面看效果的前端或全栈来说Docker的链路确实偏重了。说白了本地开发工具的诉求跟生产环境是有本质区别的。生产环境追求的是稳定、隔离、可复现而本地环境追求的是快速启动、不占资源、按需切换。FlyEnv这类“本机进程级方案”就是站在这个交叉点上做文章不搞虚拟机级隔离而是在进程层面动态切换组件让Nginx按需启动不同版本的PHP-FPM进程。用生活类比来说Docker像开了几个独立的厨房设备不共享、油烟互不干扰而FlyEnv像一个标准厨房里的可换灶台你需要猛火就把大火力灶头推过来需要慢炖就换另一个灶头厨具碗筷仍然是同一套省空间、快、灵活。1.3 FlyEnv的定位和整体处理思路FlyEnv的定位说白了就是面向本机多项目开发的轻量级环境管理器。它不是一套“装完就能跑”的静态包而是一个带管理界面和服务编排能力的本地环境中心。它把软件组件拆成了原子模块PHP各版本、MySQL各版本、Nginx、Apache、Redis、Memcached等安装时按需选择运行中按项目绑定。这个思路的核心是一套“环境上下文”逻辑。工作流可以概括为几个步骤在FlyEnv里为每个项目创建一个站点或工作区记录项目路径。给项目指定要使用的PHP版本和API端口。FlyEnv根据配置启动或复用对应版本的服务进程。本机域名无需手动改hosts工具自动完成指向。从用户端感受来说这套逻辑最直观的好处是切换项目时不再需要“换个环境、重启服务”而是项目之间天然共存。Windows下不用再在系统环境变量里反复折腾PATHmacOS下也不用再担心用brew装了一堆PHP版本却互相打架。这也是为什么FlyEnv在常被吐槽“本地环境难搞”的Windows平台上反而好评更多因为它把原本需要手动处理的部分收敛成了一次界面点击。2. FlyEnv整体设计环境隔离与组件动态切换的核心机制2.1 “项目即配置”的目录式管理逻辑FlyEnv和传统集成环境最大的差异在于它不是以软件为中心而是以项目为中心。传统工具里你打开面板要做的是“启动Apache”、“启动MySQL”所有项目共用同一个根目录和同一个服务配置。FlyEnv的思路是你在每个站点配置里声明好这个项目要什么工具去满足它。我这边实际使用中的体会是这个项目配置文件把周围很重要的信息都收拢了例如项目根路径、伪静态规则、PHP版本、端口映射、SSL证书开关。类似下面这种结构不同版本界面可能略有出入Project: laravel-old-app Path: D:\www\laravel-old-app Domain: laravel-old-app.test PHP: 7.1.33 MySQL: 5.7.36 Nginx vhost: laravel-old-app.test.conf这个声明带来了一个很明显的优势配置可以随项目走。换电脑、拉新同事代码库的时候项目里的.flyenv配置如果跟着进仓库他装好FlyEnv后只需要导入项目环境要求一目了然跑起来就是一致的。这跟Docker Compose在团队协作里的价值很像但代价又比Docker轻得多因为它不需要分发镜像只要机器上装了对应版本的运行组件直接就能启。不过要提醒一句的是端口和域名这类跟机器相关的信息我通常不放进仓库避免团队里有人本机端口被占用时产生无意义的冲突。机器相关的写在本地忽略文件里项目相关的才提交共享这是一个值得从第一天就养成的习惯。2.2 PHP多版本共存与请求转发原理FlyEnv能让不同项目使用不同PHP版本底层其实还是站在Nginx的fastcgi机制上做的文章。传统部署里Nginx通过fastcgi_pass 127.0.0.1:9000把请求转发给后端的PHP-FPM进程。当多个PHP版本共存时只要让不同版本的PHP-FPM监听不同端口再让Nginx按站点转发到对应端口就能实现“同一个Nginx服务背后同时跑着PHP 7.1和PHP 8.2两个处理器”。举个例子# PHP 8.2 项目站点配置 server { listen 80; server_name new-app.test; root D:/www/new-app/public; index index.php index.html; location ~ \.php$ { fastcgi_pass 127.0.0.1:9082; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }另一个项目用的PHP版本是7.1站点配置里只需要把端口换成对应的比如9081Nginx收到请求后自己去找对应的处理进程互不干扰。FlyEnv在这个过程中做的事就是把“下载对应PHP版本、准备对应php.ini、启动FPM进程、生成Nginx站点配置”这几步自动化。当你给项目切换PHP版本的时候它本质上干的事是停掉对应站点的旧FPM关联、把站点请求转发到另一个版本对应的端口、然后告知服务配置已更新。这也解释了为什么在同一时刻两个项目能各自跑在不同PHP版本上。它们根本不共享同一个执行引擎。静态文件、PHP解析各自独立谁也不会把谁的全局变量搞乱。2.3 服务端口冲突的自动处理逻辑服务端口冲突是本地环境最常遇到的问题。原本跑得好好的Redis装了个新软件后突然把6379占了MySQL默认3306被另一个项目里的独立库占用更经典的是80端口被IIS或者其他服务站着Nginx怎么都启不来。FlyEnv在端口处理上做了一些自动化和半自动化的工作。安装组件时它会检测常用端口是否可用发现冲突后会提供几个选项一是自动切换到备用端口二是提示用户手动指定。启服务的时候它会记录端口占用情况有进程冲突不会硬启动而是直接给出冲突进程的具体PID和程序路径。我自己实测下来这个机制在Windows上特别有用。Windows下查端口占用是个比较烦的事通常要打开命令行敲netstat -ano看到PID后再去任务管理器里找对应进程运气不好还要去服务控制台停掉一些莫名奇妙的系统服务。有了工具提示这个排查环节至少缩短了大半。还有一个加分项是FlyEnv能识别出自己管理的服务进程二次启动的时候不会重复拉起旧进程可以平稳替换配合自动刷新Nginx配置基本能做到“改完即生效”。3. 完整实测从安装到解决一个“双项目版本冲突”的复现过程3.1 安装与初始配置要点先说安装环节。FlyEnv的安装包是图形化引导的Windows和macOS都有对应版本。安装时它会让你选择要预装的组件这里有一个值得注意的地方不要因为求全就一口气把所有组件都勾上。各个PHP版本几百MB、数据库动辄大几百MB全装下来硬盘配额吃紧而且很多版本你根本用不到。我个人建议第一轮只装最刚需的一个主力PHP版本比如当前新项目要用的8.2、一个兼容旧项目的PHP版本如果已知有老系统顺手装7.4或8.0、一个MySQL 8.0、一个Redis。后面有真实需要再从工具里补装。这样装得快环境树也干净。安装完成后会有初始化设置主要涉及站点根目录、下载镜像源、服务开机自启等选项。我的习惯是关闭所有服务的开机自启。本地开发工具按需使用即可不然每次开机后台都挂着一堆服务不仅拖慢启动速度也容易在带笔记本外出时白白耗电。站点根目录建议选一个空间大、路径短、没有中文和空格的目录例如Windows下的D:\www避免后续因为路径编码问题让某些老扩展加载失败。3.2 模拟冲突场景搭建两个互相打架的项目为了验证FlyEnv解决版本冲突的能力我专门搭了一个典型的冲突场景。项目A是一个维护了两年的ThinkPHP 5项目项目B是一个Laravel 11新项目。如果放在同一套PHP环境里这俩属于直接“互斥”的ThinkPHP 5在PHP 8.2下会大量触发deprecated警告而Laravel 11明确要求PHP 8.2以上。操作步骤如下准备两个项目目录分别放入对应的代码。在FlyEnv中新建站点项目A指向旧代码目录项目B指向新代码目录。给项目A绑定PHP 7.1.33项目B绑定PHP 8.2.12。两个站点都绑定.test结尾的本地域名工具自动写入hosts解析。启动Nginx服务和两个对应版本的PHP服务。这个流程里最直观的一个感受是没有被迫停掉任何一个项目。如果是以前手动管理的方式为了让两个项目使用不同PHP版本唯一的办法就是关掉全局环境再启动另一个版本然后改Nginx配置这一个来回至少10分钟。在FlyEnv里整个过程只需要在界面里创建站点和选择版本。为了确认请求真正落到了对应版本我在两个项目根目录各放了一个简易探针文件。访问项目A的域名时页面显示的PHP版本是7.1.33访问项目B时显示8.2.12。两个页面只要服务开着可以同时访问、同时处理请求互不干扰。项目A的MySQL连接、Redis缓存也同步正常——因为数据库服务同样是可多版本并存的我给项目A用了MySQL 5.7实例项目B单独跑了MySQL 8.0实例。我顺手做了一遍两个项目各自的完整基础流程项目A跑通了数据库迁移脚本和原有后台接口项目B跑通了composer install、php artisan migrate以及队列监听。折腾一圈下来最大的体感是以前切换环境那种“拆东墙补西墙”的紧绷感没了前后端联调的时候不用再担心切换版本导致服务掉线。3.3 实际切换版本时的配置细节和注意事项FlyEnv支持在同一个项目上一键切换PHP版本。这个功能我在开发中也会用到比如一个项目需要对比在不同PHP版本下的表现差异或者在升级框架之前先跑一遍兼容性测试。需要注意版本切换的先决条件目标PHP版本必须已安装并且在可选版本列表里。切换前最好停掉正在运行的调试会话不然IDE里的Xdebug连接会中断。切换完成后不要忘了清理一下PHP的OPcache缓存否则某些框架可能在旧缓存中取到不兼容的类定义产生非常迷的“改完代码没生效”现象。PHP版本之间还会涉及扩展的差异。比如项目A用到php_curl、php_mbstring、php_openssl这些常用扩展基本在主流版本里都是默认打开的。但老项目如果有用到php_mysql不带i的旧扩展PHP 7.0就已经淘汰了这种情况只能在更高版本里找替代方案。遇到类似问题解决方案不是让工具去兼容而是要把代码里的旧API调用升级成mysqli或PDO。还有一个经常被忽略的细节是php.ini里扩展路径的写法。在Windows上每个PHP版本解压后的目录结构不同扩展目录需要保证extension_dir指向正确。FlyEnv在安装时会自动为每个独立版本设置一份基础的php.ini但还是建议在第一次使用某个版本时手动打开配置确认一下时区、内存限制、上传文件大小这几个高频参数。不然等真线上遇到“本地传不了大文件”排查半天发现是ini里upload_max_filesize还是默认的2M那种感觉比环境冲突还憋屈。3.4 项目级服务编排MySQL、Redis等组件如何跟项目走除了PHP版本隔离数据库和缓存组件的按项目隔离同样重要。我实测的项目A和项目B在数据库上用了两个不同主版本的MySQL实例。FlyEnv在服务管理界面中把这类组件也做成了可配置的单元和PHP版本对应关系的绑定方式类似都是项目声明依赖组件按实例运行。这里有个值得展开说的点数据库实例的隔离层级。如果你只是希望两个项目连不同数据库名只需要一个MySQL 8.0实例里建两个database即可但如果一个项目是老业务的MySQL 5.7另一个项目想要用新版MySQL 8.0的JSON特性、窗口函数那就得跑两个不同主版本的实例。FlyEnv支持安装多版本数据库实例它们监听不同端口数据目录各自独立。默认情况下5.7和8.0都能各自绑定3306不行——同一台机器同一端口不能同时被两个实例占用。工具会自动为后启动的版本分配一个高位端口比如3307。实际项目里配置数据库连接时容易犯的一个错误是写死端口。为了做到“项目配置随环境走”我建议把端口和数据库名都抽象成环境变量写在项目的.env文件里。这样从项目A切到项目B应用代码不用改只要环境变量指向的端口跟随FlyEnv的项目上下文变化就行。关于Redis也多说一句。老项目用的Redis可能没有密码新项目开启了ACL权限校验。FlyEnv在分配Redis实例时默认配置各不相同如果两个项目共享一个Redis实例搞不好就会因为密码不匹配导致连接失败。按项目分配独立实例虽然多占一点内存但能免掉很多跨项目key污染和认证冲突的心智负担。在本地开发阶段这点资源开销跟省下的排查时间相比实在太划算了。4. 踩坑记录本地环境管理最容易翻车的几个细节4.1 Windows下PHP扩展加载失败版本对不上怪现象在Windows环境使用任何本地PHP工具都绕不开一个经典问题扩展加载失败。FlyEnv在Windows上跑的PHP版本扩展文件一般区分为ts线程安全和nts非线程安全两类与它组合的Web服务器方式Apache模块还是NginxFPM要求不一样。如果装的版本本身是NTS却放了TS的扩展DLLPHP启动时就会报找不到模块或加载失败。排查这类问题最直接的办法是在命令行里对对应版本执行php -m或者php --ini先看配置是否正确、再看扩展模块是否能正常列举出来。FlyEnv的图形界面有时不会把详细启动错误直接吐给你但日志中心能看到PHP进程的启动输出。我建议养成一个习惯每一个PHP版本跑通后先在终端执行一次php -v php -m确认版本正确、扩展齐全再开始配置项目站点。否则等配置好站点才发现某个函数不存在回来排查的链路会拉长很多。4.2 hosts和域名解析项目目录对了却访问不到FlyEnv处理本地域名一般是自动的它会让本地域名指向127.0.0.1。但Windows上有个特殊情况系统代理或安全软件可能拦截本地hosts解析。这看起来跟环境工具没半毛钱关系但真出问题时极其迷惑。我遇到过不止一次站点配置没问题、服务也都启动正常浏览器里访问项目域名却跳到了某个搜索引擎或代理错误页。这背后通常是系统代理上开了“代理所有协议”而忽略了本地地址例外。解决办法是在系统代理设置里把.test本地域名加入“不使用代理”列表。否则你访问本地开发站点的流量先被代理转发出去然后才尝试解析后果就是这个站点对外根本不存在返回错误。另一个与hosts相关的场景是切换网络环境从办公室有线切到Wi-Fi后本地解析突然失效。解决方案也比较粗暴断开再重连网络或者用ipconfig /flushdns刷新DNS缓存。这类问题不是FlyEnv本身的设计缺陷但确实会直接影响工具的使用体验提前了解会让排查更快一些。4.3 端口被Windows服务或进程占用的经典场景Windows上端口被占用很多时候真凶不是开发工具而是系统自带的组件。比如IIS互联网信息服务会把80端口占掉SQL Server Reporting Services会把80也抢走World Wide Web Publishing Service更是常把Nginx挤到无端口可用。FlyEnv启服务时如果发现端口占用会给出提示。我在第一次遇到这个问题时通过它给出的PID找到了占用的进程名发现是系统服务W3SVC。这类系统服务最好用管理员身份打开服务控制台设为手动启动或禁用避免每次开机就把80端口抢占。调完之后Nginx能正常起来了FlyEnv的站点映射也一并生效。再补充一个小技巧如果你需要为某个项目临时换端口可以在站点配置里修改端口映射。但要注意改了端口以后项目里所有硬编码的URL也要同步调整。前后端分离的项目尤其容易踩这个坑前端代码里写的API baseURL还是8080端口本地服务却已经换到了8081测了半天接口不通最后发现根本没连上本地后端。4.4 数据库权限和缓存导致的连库失败本地数据库服务切换实例后经常会出现一个现象用旧的连接串连不上提醒密码错误或不允许连接。FlyEnv在安装新的数据库实例时会和已有的实例用不同的数据目录所以root密码可能不一样。如果你之前在项目A的MySQL 5.7上设置了密码123456切到项目B的MySQL 8.0实例上可能默认账号就不是同一个密码或者插件从mysql_native_password变更为caching_sha2_password老客户端不认新插件。解决方案是打开对应实例的命令行主动重置一次密码和认证插件。比如ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY your_password; FLUSH PRIVILEGES;这里需要特别提醒的是生产环境中不要用mysql_native_password这是为了兼容老客户端才做的妥协。本地开发时怎么顺手怎么来但线上一定用更安全的认证方式。另外本地常用连接工具如果是老版本遇到MySQL 8.0认证插件报错时优先升级客户端工具而不是把数据库降级省得后续新特性用不上。4.5 小版本差异7.4跑得好不代表8.0没问题FlyEnv解决的是大版本共存的问题但同一主版本下的小版本差异依然存在。我遇到过一个场景本地PHP 8.0.2跑一个项目完全正常但另一个同事环境是8.0.30却复现了一个依赖行为差异导致的问题。后来定位到是某个第三方扩展对不同小版本的兼容性不一样。遇到这种问题建议在FlyEnv中多装一个同主版本的最新小版本用最新维护版本消除一些已知bug的影响。因为本地开发环境不像线上需要精确定版保持每个主版本下的小版本为最新补丁版是成本最低的稳定性策略。当然个别老项目可能因为用了非公开渠道下载的第三方扩展对PHP小版本特别挑剔。这类扩展维护是个历史债务你能做的是在项目文档里记好“此项目必须在PHP 8.0.2及以上、且扩展包版本为X.Y.Z时运行”不给后来的维护者留坑。5. 补充进阶FlyEnv、Composer与Node等工具的协同配合5.1 本地环境管理工具和Composer的版本联动FlyEnv负责管理PHP运行时PHP的项目依赖管理器Composer也要跟着使用正确的PHP版本。实践上有一个很常见的错位场景终端里全局的php命令指向的是FlyEnv默认版本但项目A要求PHP 7.1此时运行composer install很可能因为Composer本身要求高版本PHP而直接失败。解决思路是让项目里的命令调用跟随项目上下文。你现在可以在项目A的配置里把FlyEnv分配的PHP 7.1路径找出来然后在项目终端里执行时直接指定解释器D:/www/flyenv/php/7.1.33/php.exe composer.phar install这样做确实不优雅很多人用FlyEnv时感觉它跟Composer“不是一家人”就是卡在这个环节。更顺滑的方案是创建项目别名或者在终端里切到该项目的绑定环境确保命令解析到的是当前项目的PHP版本。FlyEnv本身也在提供环境集成能力让终端会话跟随当前激活的项目省去手工确认PHP版本的麻烦。一个实操心得在项目根目录里放一个.env.version或者开发文档写明当前项目要求的PHP、MySQL、Composer版本区间。不管是新人接手还是自己隔了半年回来看文档比依赖肌肉记忆靠谱。5.2 与Laravel Valet / Herd / Laragon等其他工具横向对比FlyEnv并不是唯一一个做这件事的工具。市面上存在一批同类本地环境工具包括Laravel生态内的Valet和Herd也包含传统集成环境升级形态的Laragon。横向对比下来选择哪个更多取决于你的使用平台和项目生态。如果你主要在macOS上写Laravel项目Valet和Herd都是优秀方案它们干净利落对Laravel的集成度高。但假如项目里同时有多个老版本PHP系统或者你用Windows作为主力机器这在不少公司还是常态这类偏macOS生态的工具施展起来就有限制了。Laragon在Windows上口碑也不错它在易用性和可扩展性方面做了很久界面逻辑跟FlyEnv有相似之处。FlyEnv则是把“项目配置”的概念做得更突出多版本组件的编排能力更明确比较适合项目环境差异大的用户。我的建议是不要单纯迷信哪款工具更火而是把项目目录拿过去试用一遍看看以下几点是否符合预期同时启动两个不同PHP版本的项目是否顺畅域名映射是否需要手工改hosts数据库多实例切换时数据是否完整隔离重装或迁移电脑时环境恢复成本高不高如果这四个问题的体验都过关那工具本身跟你的工作流是匹配的选哪个纯粹是界面偏好问题。5.3 团队协作中本地环境配置的标准化本地开发工具的个人体验升级只走了一半另一半在团队协作里。现在很多团队已经意识到“在我机器上是好的”不能作为验收标准但完全推Docker到每个成员桌面也不现实。折中方案是运行时层继续用本地环境工具项目层补齐一份开发环境说明文档。说明文档可以写这几块内容PHP版本、依赖扩展清单、MySQL版本和初始账号、Redis是否启用密码、Node版本要求如果项目有前端构建、以及启动站点后用于验证是否正常的探针URL。FlyEnv这类工具的价值在于它把个人机器上的“环境事实”以可配置的方式管理起来那么团队里的公共信息就是那份简明文档和绑定的组件版本列表而不是某个人在群里口头说“我这边是能跑的你们装个什么什么就行了”。落地时还有个细节不要把所有组件装齐再开工。让新人按项目文档只装A和B需要的组件不仅装得快也更能验证文档的完整性——如果缺了某个扩展正好说明文档需要补。这套流程跑顺了以后新同事入职第一天就能把本地环境跑通你的时间省下来比什么都强。6. 实践心得本地环境这件事很容易被当成“能用就行”的边缘事务。可它是每个开发者在每个工作日开门第一件要做的事体验好坏直接决定了一天工作的起步效率。我在这几周实测下来的感觉是FlyEnv最打动我的并不是某个单点的花哨功能而是它在“不引入过重机制的前提下把多项目隔离这件事做得足够顺手”。跟我之前手动管理环境变量和多个PHP目录的日子比起来现在最大的变化是心里没有那根弦了不用在切换项目前先回忆一遍环境有没有被动过也不会出现启动完项目发现PHP扩展少了一个、连数据库报密码错的连锁问题。它把环境配置沉淀成了一份可以查看、可以修改、可以随项目走的结构这份可预期性就是本地开发工具真正的价值所在。我保留的一个习惯是定期整理站点列表长期不维护的项目从工具里删掉或停用为环境保持清爽。毕竟工具能管理的组件越多堆积不用的“环境尸体”也越容易变多定期清理会让工具保持轻盈排查新问题时也更聚焦。最后补一个实用建议如果你目前在维护的项目同时跨越两个或以上的PHP大版本与其抱着一个全局XAMPP不放不如花一个傍晚把FlyEnv这类工具装起来把旧项目按配置迁进去。这个迁移成本大概率比你想象的低而每天省下来的切换时间则会持续回报你。
FlyEnv本地环境管理工具：破解PHP多版本与多项目并行的开发困局
1. 为什么需要FlyEnv本地环境管理工具到底在解决什么问题1.1 多项目并行开发时的经典痛点做Web开发的人尤其是PHP、Node、前端全栈混着做的几乎都经历过这种状态电脑上的开发环境越装越多最后变成一锅粥。今天要维护一个客户在两年前交付的老系统项目用的是PHP 7.0扩展还是老一套明天新接了一个项目一开始就要求PHP 8.2起步不然框架跑不起来。数据库那边更麻烦老项目只认MySQL 5.7的排序规则新项目想着直接用8.0的新特性。再加上Nginx、Apache、Redis光是把它们同时装进系统里端口冲突就能让人调一个下午。我见过不少同行解决这类问题的方式是“装两套环境需要哪个开哪个”。这种做法的代价很明显切换成本高、环境间相互干扰、改系统配置时容易把另一套环境搞挂。以前我为了兼容两个PHP项目手动改过无数次系统环境变量、PATH、php.ini的扩展路径每次切换还要重启命令行、清理php进程缓存效率极低而且特别容易出错。更麻烦的场景是两个项目都要常驻跑着——一个接口服务要给前端联调用另一个后台任务在持续采集数据这种“不能停旧项目又要起新项目”的需求单靠手动切换版本的工具根本做不到。本地开发环境管理工具解决的核心问题就在这。简单来说它把“装一个全局环境项目去适配环境”的旧逻辑颠倒过来变成“每个项目声明自己需要的环境由工具来分配和切换”。在Linux服务器上我们习惯用Docker去隔离但在本地开发机上Docker特别吃内存WSL2里挂着虚拟机再加上IDE和浏览器16G内存的电脑已经开始喘了。于是越来越多的人开始寻找更轻量、更贴近本地原生体验的替代方案。FlyEnv就是在这样一个背景下被越来越多人提到的工具它跟Laragon、XAMPP这类方案在思路上有相似处但在项目可配置性和版本切换体验上做了一些自己的取舍。1.2 传统环境和Docker方案各自的短板要搞明白一个工具好在哪得先知道替代方案差在哪。先拿最常见的集成环境来说这类工具的特点是“开箱即用”装完打开控制面板启动Nginx、启动MySQL本地就能跑项目。但它默认给你的是写死的一套组合一个PHP版本、一个MySQL版本、一个固定的网站根目录。项目多了以后要么把老项目往上兼容要么把新项目往下妥协。老项目在PHP 8.2上跑报错一大片deprecated警告刷屏甚至直接白屏最后只能拿兼容层补丁来补补的时候还不一定找得到历史扩展。再来看Docker方案。理论上Docker是最标准的解法每个项目一个容器组PHP版本、MySQL版本全部隔离互不干扰。可我自己用下来本地开发场景里有几个很实际的摩擦点。第一磁盘占用高每个项目拉一个PHP镜像加数据库镜像动辄几个G第二启动速度慢尤其用Docker Desktop的时候文件挂载在macOS或Windows下性能会打折刷新一下页面等一两秒是常有的事第三断点调试和本地服务联动很麻烦Xdebug要从容器里把端口映射出来本地工具要连库还得暴露端口还要配置权限。对一个只想快速改两行代码、刷新页面看效果的前端或全栈来说Docker的链路确实偏重了。说白了本地开发工具的诉求跟生产环境是有本质区别的。生产环境追求的是稳定、隔离、可复现而本地环境追求的是快速启动、不占资源、按需切换。FlyEnv这类“本机进程级方案”就是站在这个交叉点上做文章不搞虚拟机级隔离而是在进程层面动态切换组件让Nginx按需启动不同版本的PHP-FPM进程。用生活类比来说Docker像开了几个独立的厨房设备不共享、油烟互不干扰而FlyEnv像一个标准厨房里的可换灶台你需要猛火就把大火力灶头推过来需要慢炖就换另一个灶头厨具碗筷仍然是同一套省空间、快、灵活。1.3 FlyEnv的定位和整体处理思路FlyEnv的定位说白了就是面向本机多项目开发的轻量级环境管理器。它不是一套“装完就能跑”的静态包而是一个带管理界面和服务编排能力的本地环境中心。它把软件组件拆成了原子模块PHP各版本、MySQL各版本、Nginx、Apache、Redis、Memcached等安装时按需选择运行中按项目绑定。这个思路的核心是一套“环境上下文”逻辑。工作流可以概括为几个步骤在FlyEnv里为每个项目创建一个站点或工作区记录项目路径。给项目指定要使用的PHP版本和API端口。FlyEnv根据配置启动或复用对应版本的服务进程。本机域名无需手动改hosts工具自动完成指向。从用户端感受来说这套逻辑最直观的好处是切换项目时不再需要“换个环境、重启服务”而是项目之间天然共存。Windows下不用再在系统环境变量里反复折腾PATHmacOS下也不用再担心用brew装了一堆PHP版本却互相打架。这也是为什么FlyEnv在常被吐槽“本地环境难搞”的Windows平台上反而好评更多因为它把原本需要手动处理的部分收敛成了一次界面点击。2. FlyEnv整体设计环境隔离与组件动态切换的核心机制2.1 “项目即配置”的目录式管理逻辑FlyEnv和传统集成环境最大的差异在于它不是以软件为中心而是以项目为中心。传统工具里你打开面板要做的是“启动Apache”、“启动MySQL”所有项目共用同一个根目录和同一个服务配置。FlyEnv的思路是你在每个站点配置里声明好这个项目要什么工具去满足它。我这边实际使用中的体会是这个项目配置文件把周围很重要的信息都收拢了例如项目根路径、伪静态规则、PHP版本、端口映射、SSL证书开关。类似下面这种结构不同版本界面可能略有出入Project: laravel-old-app Path: D:\www\laravel-old-app Domain: laravel-old-app.test PHP: 7.1.33 MySQL: 5.7.36 Nginx vhost: laravel-old-app.test.conf这个声明带来了一个很明显的优势配置可以随项目走。换电脑、拉新同事代码库的时候项目里的.flyenv配置如果跟着进仓库他装好FlyEnv后只需要导入项目环境要求一目了然跑起来就是一致的。这跟Docker Compose在团队协作里的价值很像但代价又比Docker轻得多因为它不需要分发镜像只要机器上装了对应版本的运行组件直接就能启。不过要提醒一句的是端口和域名这类跟机器相关的信息我通常不放进仓库避免团队里有人本机端口被占用时产生无意义的冲突。机器相关的写在本地忽略文件里项目相关的才提交共享这是一个值得从第一天就养成的习惯。2.2 PHP多版本共存与请求转发原理FlyEnv能让不同项目使用不同PHP版本底层其实还是站在Nginx的fastcgi机制上做的文章。传统部署里Nginx通过fastcgi_pass 127.0.0.1:9000把请求转发给后端的PHP-FPM进程。当多个PHP版本共存时只要让不同版本的PHP-FPM监听不同端口再让Nginx按站点转发到对应端口就能实现“同一个Nginx服务背后同时跑着PHP 7.1和PHP 8.2两个处理器”。举个例子# PHP 8.2 项目站点配置 server { listen 80; server_name new-app.test; root D:/www/new-app/public; index index.php index.html; location ~ \.php$ { fastcgi_pass 127.0.0.1:9082; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }另一个项目用的PHP版本是7.1站点配置里只需要把端口换成对应的比如9081Nginx收到请求后自己去找对应的处理进程互不干扰。FlyEnv在这个过程中做的事就是把“下载对应PHP版本、准备对应php.ini、启动FPM进程、生成Nginx站点配置”这几步自动化。当你给项目切换PHP版本的时候它本质上干的事是停掉对应站点的旧FPM关联、把站点请求转发到另一个版本对应的端口、然后告知服务配置已更新。这也解释了为什么在同一时刻两个项目能各自跑在不同PHP版本上。它们根本不共享同一个执行引擎。静态文件、PHP解析各自独立谁也不会把谁的全局变量搞乱。2.3 服务端口冲突的自动处理逻辑服务端口冲突是本地环境最常遇到的问题。原本跑得好好的Redis装了个新软件后突然把6379占了MySQL默认3306被另一个项目里的独立库占用更经典的是80端口被IIS或者其他服务站着Nginx怎么都启不来。FlyEnv在端口处理上做了一些自动化和半自动化的工作。安装组件时它会检测常用端口是否可用发现冲突后会提供几个选项一是自动切换到备用端口二是提示用户手动指定。启服务的时候它会记录端口占用情况有进程冲突不会硬启动而是直接给出冲突进程的具体PID和程序路径。我自己实测下来这个机制在Windows上特别有用。Windows下查端口占用是个比较烦的事通常要打开命令行敲netstat -ano看到PID后再去任务管理器里找对应进程运气不好还要去服务控制台停掉一些莫名奇妙的系统服务。有了工具提示这个排查环节至少缩短了大半。还有一个加分项是FlyEnv能识别出自己管理的服务进程二次启动的时候不会重复拉起旧进程可以平稳替换配合自动刷新Nginx配置基本能做到“改完即生效”。3. 完整实测从安装到解决一个“双项目版本冲突”的复现过程3.1 安装与初始配置要点先说安装环节。FlyEnv的安装包是图形化引导的Windows和macOS都有对应版本。安装时它会让你选择要预装的组件这里有一个值得注意的地方不要因为求全就一口气把所有组件都勾上。各个PHP版本几百MB、数据库动辄大几百MB全装下来硬盘配额吃紧而且很多版本你根本用不到。我个人建议第一轮只装最刚需的一个主力PHP版本比如当前新项目要用的8.2、一个兼容旧项目的PHP版本如果已知有老系统顺手装7.4或8.0、一个MySQL 8.0、一个Redis。后面有真实需要再从工具里补装。这样装得快环境树也干净。安装完成后会有初始化设置主要涉及站点根目录、下载镜像源、服务开机自启等选项。我的习惯是关闭所有服务的开机自启。本地开发工具按需使用即可不然每次开机后台都挂着一堆服务不仅拖慢启动速度也容易在带笔记本外出时白白耗电。站点根目录建议选一个空间大、路径短、没有中文和空格的目录例如Windows下的D:\www避免后续因为路径编码问题让某些老扩展加载失败。3.2 模拟冲突场景搭建两个互相打架的项目为了验证FlyEnv解决版本冲突的能力我专门搭了一个典型的冲突场景。项目A是一个维护了两年的ThinkPHP 5项目项目B是一个Laravel 11新项目。如果放在同一套PHP环境里这俩属于直接“互斥”的ThinkPHP 5在PHP 8.2下会大量触发deprecated警告而Laravel 11明确要求PHP 8.2以上。操作步骤如下准备两个项目目录分别放入对应的代码。在FlyEnv中新建站点项目A指向旧代码目录项目B指向新代码目录。给项目A绑定PHP 7.1.33项目B绑定PHP 8.2.12。两个站点都绑定.test结尾的本地域名工具自动写入hosts解析。启动Nginx服务和两个对应版本的PHP服务。这个流程里最直观的一个感受是没有被迫停掉任何一个项目。如果是以前手动管理的方式为了让两个项目使用不同PHP版本唯一的办法就是关掉全局环境再启动另一个版本然后改Nginx配置这一个来回至少10分钟。在FlyEnv里整个过程只需要在界面里创建站点和选择版本。为了确认请求真正落到了对应版本我在两个项目根目录各放了一个简易探针文件。访问项目A的域名时页面显示的PHP版本是7.1.33访问项目B时显示8.2.12。两个页面只要服务开着可以同时访问、同时处理请求互不干扰。项目A的MySQL连接、Redis缓存也同步正常——因为数据库服务同样是可多版本并存的我给项目A用了MySQL 5.7实例项目B单独跑了MySQL 8.0实例。我顺手做了一遍两个项目各自的完整基础流程项目A跑通了数据库迁移脚本和原有后台接口项目B跑通了composer install、php artisan migrate以及队列监听。折腾一圈下来最大的体感是以前切换环境那种“拆东墙补西墙”的紧绷感没了前后端联调的时候不用再担心切换版本导致服务掉线。3.3 实际切换版本时的配置细节和注意事项FlyEnv支持在同一个项目上一键切换PHP版本。这个功能我在开发中也会用到比如一个项目需要对比在不同PHP版本下的表现差异或者在升级框架之前先跑一遍兼容性测试。需要注意版本切换的先决条件目标PHP版本必须已安装并且在可选版本列表里。切换前最好停掉正在运行的调试会话不然IDE里的Xdebug连接会中断。切换完成后不要忘了清理一下PHP的OPcache缓存否则某些框架可能在旧缓存中取到不兼容的类定义产生非常迷的“改完代码没生效”现象。PHP版本之间还会涉及扩展的差异。比如项目A用到php_curl、php_mbstring、php_openssl这些常用扩展基本在主流版本里都是默认打开的。但老项目如果有用到php_mysql不带i的旧扩展PHP 7.0就已经淘汰了这种情况只能在更高版本里找替代方案。遇到类似问题解决方案不是让工具去兼容而是要把代码里的旧API调用升级成mysqli或PDO。还有一个经常被忽略的细节是php.ini里扩展路径的写法。在Windows上每个PHP版本解压后的目录结构不同扩展目录需要保证extension_dir指向正确。FlyEnv在安装时会自动为每个独立版本设置一份基础的php.ini但还是建议在第一次使用某个版本时手动打开配置确认一下时区、内存限制、上传文件大小这几个高频参数。不然等真线上遇到“本地传不了大文件”排查半天发现是ini里upload_max_filesize还是默认的2M那种感觉比环境冲突还憋屈。3.4 项目级服务编排MySQL、Redis等组件如何跟项目走除了PHP版本隔离数据库和缓存组件的按项目隔离同样重要。我实测的项目A和项目B在数据库上用了两个不同主版本的MySQL实例。FlyEnv在服务管理界面中把这类组件也做成了可配置的单元和PHP版本对应关系的绑定方式类似都是项目声明依赖组件按实例运行。这里有个值得展开说的点数据库实例的隔离层级。如果你只是希望两个项目连不同数据库名只需要一个MySQL 8.0实例里建两个database即可但如果一个项目是老业务的MySQL 5.7另一个项目想要用新版MySQL 8.0的JSON特性、窗口函数那就得跑两个不同主版本的实例。FlyEnv支持安装多版本数据库实例它们监听不同端口数据目录各自独立。默认情况下5.7和8.0都能各自绑定3306不行——同一台机器同一端口不能同时被两个实例占用。工具会自动为后启动的版本分配一个高位端口比如3307。实际项目里配置数据库连接时容易犯的一个错误是写死端口。为了做到“项目配置随环境走”我建议把端口和数据库名都抽象成环境变量写在项目的.env文件里。这样从项目A切到项目B应用代码不用改只要环境变量指向的端口跟随FlyEnv的项目上下文变化就行。关于Redis也多说一句。老项目用的Redis可能没有密码新项目开启了ACL权限校验。FlyEnv在分配Redis实例时默认配置各不相同如果两个项目共享一个Redis实例搞不好就会因为密码不匹配导致连接失败。按项目分配独立实例虽然多占一点内存但能免掉很多跨项目key污染和认证冲突的心智负担。在本地开发阶段这点资源开销跟省下的排查时间相比实在太划算了。4. 踩坑记录本地环境管理最容易翻车的几个细节4.1 Windows下PHP扩展加载失败版本对不上怪现象在Windows环境使用任何本地PHP工具都绕不开一个经典问题扩展加载失败。FlyEnv在Windows上跑的PHP版本扩展文件一般区分为ts线程安全和nts非线程安全两类与它组合的Web服务器方式Apache模块还是NginxFPM要求不一样。如果装的版本本身是NTS却放了TS的扩展DLLPHP启动时就会报找不到模块或加载失败。排查这类问题最直接的办法是在命令行里对对应版本执行php -m或者php --ini先看配置是否正确、再看扩展模块是否能正常列举出来。FlyEnv的图形界面有时不会把详细启动错误直接吐给你但日志中心能看到PHP进程的启动输出。我建议养成一个习惯每一个PHP版本跑通后先在终端执行一次php -v php -m确认版本正确、扩展齐全再开始配置项目站点。否则等配置好站点才发现某个函数不存在回来排查的链路会拉长很多。4.2 hosts和域名解析项目目录对了却访问不到FlyEnv处理本地域名一般是自动的它会让本地域名指向127.0.0.1。但Windows上有个特殊情况系统代理或安全软件可能拦截本地hosts解析。这看起来跟环境工具没半毛钱关系但真出问题时极其迷惑。我遇到过不止一次站点配置没问题、服务也都启动正常浏览器里访问项目域名却跳到了某个搜索引擎或代理错误页。这背后通常是系统代理上开了“代理所有协议”而忽略了本地地址例外。解决办法是在系统代理设置里把.test本地域名加入“不使用代理”列表。否则你访问本地开发站点的流量先被代理转发出去然后才尝试解析后果就是这个站点对外根本不存在返回错误。另一个与hosts相关的场景是切换网络环境从办公室有线切到Wi-Fi后本地解析突然失效。解决方案也比较粗暴断开再重连网络或者用ipconfig /flushdns刷新DNS缓存。这类问题不是FlyEnv本身的设计缺陷但确实会直接影响工具的使用体验提前了解会让排查更快一些。4.3 端口被Windows服务或进程占用的经典场景Windows上端口被占用很多时候真凶不是开发工具而是系统自带的组件。比如IIS互联网信息服务会把80端口占掉SQL Server Reporting Services会把80也抢走World Wide Web Publishing Service更是常把Nginx挤到无端口可用。FlyEnv启服务时如果发现端口占用会给出提示。我在第一次遇到这个问题时通过它给出的PID找到了占用的进程名发现是系统服务W3SVC。这类系统服务最好用管理员身份打开服务控制台设为手动启动或禁用避免每次开机就把80端口抢占。调完之后Nginx能正常起来了FlyEnv的站点映射也一并生效。再补充一个小技巧如果你需要为某个项目临时换端口可以在站点配置里修改端口映射。但要注意改了端口以后项目里所有硬编码的URL也要同步调整。前后端分离的项目尤其容易踩这个坑前端代码里写的API baseURL还是8080端口本地服务却已经换到了8081测了半天接口不通最后发现根本没连上本地后端。4.4 数据库权限和缓存导致的连库失败本地数据库服务切换实例后经常会出现一个现象用旧的连接串连不上提醒密码错误或不允许连接。FlyEnv在安装新的数据库实例时会和已有的实例用不同的数据目录所以root密码可能不一样。如果你之前在项目A的MySQL 5.7上设置了密码123456切到项目B的MySQL 8.0实例上可能默认账号就不是同一个密码或者插件从mysql_native_password变更为caching_sha2_password老客户端不认新插件。解决方案是打开对应实例的命令行主动重置一次密码和认证插件。比如ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY your_password; FLUSH PRIVILEGES;这里需要特别提醒的是生产环境中不要用mysql_native_password这是为了兼容老客户端才做的妥协。本地开发时怎么顺手怎么来但线上一定用更安全的认证方式。另外本地常用连接工具如果是老版本遇到MySQL 8.0认证插件报错时优先升级客户端工具而不是把数据库降级省得后续新特性用不上。4.5 小版本差异7.4跑得好不代表8.0没问题FlyEnv解决的是大版本共存的问题但同一主版本下的小版本差异依然存在。我遇到过一个场景本地PHP 8.0.2跑一个项目完全正常但另一个同事环境是8.0.30却复现了一个依赖行为差异导致的问题。后来定位到是某个第三方扩展对不同小版本的兼容性不一样。遇到这种问题建议在FlyEnv中多装一个同主版本的最新小版本用最新维护版本消除一些已知bug的影响。因为本地开发环境不像线上需要精确定版保持每个主版本下的小版本为最新补丁版是成本最低的稳定性策略。当然个别老项目可能因为用了非公开渠道下载的第三方扩展对PHP小版本特别挑剔。这类扩展维护是个历史债务你能做的是在项目文档里记好“此项目必须在PHP 8.0.2及以上、且扩展包版本为X.Y.Z时运行”不给后来的维护者留坑。5. 补充进阶FlyEnv、Composer与Node等工具的协同配合5.1 本地环境管理工具和Composer的版本联动FlyEnv负责管理PHP运行时PHP的项目依赖管理器Composer也要跟着使用正确的PHP版本。实践上有一个很常见的错位场景终端里全局的php命令指向的是FlyEnv默认版本但项目A要求PHP 7.1此时运行composer install很可能因为Composer本身要求高版本PHP而直接失败。解决思路是让项目里的命令调用跟随项目上下文。你现在可以在项目A的配置里把FlyEnv分配的PHP 7.1路径找出来然后在项目终端里执行时直接指定解释器D:/www/flyenv/php/7.1.33/php.exe composer.phar install这样做确实不优雅很多人用FlyEnv时感觉它跟Composer“不是一家人”就是卡在这个环节。更顺滑的方案是创建项目别名或者在终端里切到该项目的绑定环境确保命令解析到的是当前项目的PHP版本。FlyEnv本身也在提供环境集成能力让终端会话跟随当前激活的项目省去手工确认PHP版本的麻烦。一个实操心得在项目根目录里放一个.env.version或者开发文档写明当前项目要求的PHP、MySQL、Composer版本区间。不管是新人接手还是自己隔了半年回来看文档比依赖肌肉记忆靠谱。5.2 与Laravel Valet / Herd / Laragon等其他工具横向对比FlyEnv并不是唯一一个做这件事的工具。市面上存在一批同类本地环境工具包括Laravel生态内的Valet和Herd也包含传统集成环境升级形态的Laragon。横向对比下来选择哪个更多取决于你的使用平台和项目生态。如果你主要在macOS上写Laravel项目Valet和Herd都是优秀方案它们干净利落对Laravel的集成度高。但假如项目里同时有多个老版本PHP系统或者你用Windows作为主力机器这在不少公司还是常态这类偏macOS生态的工具施展起来就有限制了。Laragon在Windows上口碑也不错它在易用性和可扩展性方面做了很久界面逻辑跟FlyEnv有相似之处。FlyEnv则是把“项目配置”的概念做得更突出多版本组件的编排能力更明确比较适合项目环境差异大的用户。我的建议是不要单纯迷信哪款工具更火而是把项目目录拿过去试用一遍看看以下几点是否符合预期同时启动两个不同PHP版本的项目是否顺畅域名映射是否需要手工改hosts数据库多实例切换时数据是否完整隔离重装或迁移电脑时环境恢复成本高不高如果这四个问题的体验都过关那工具本身跟你的工作流是匹配的选哪个纯粹是界面偏好问题。5.3 团队协作中本地环境配置的标准化本地开发工具的个人体验升级只走了一半另一半在团队协作里。现在很多团队已经意识到“在我机器上是好的”不能作为验收标准但完全推Docker到每个成员桌面也不现实。折中方案是运行时层继续用本地环境工具项目层补齐一份开发环境说明文档。说明文档可以写这几块内容PHP版本、依赖扩展清单、MySQL版本和初始账号、Redis是否启用密码、Node版本要求如果项目有前端构建、以及启动站点后用于验证是否正常的探针URL。FlyEnv这类工具的价值在于它把个人机器上的“环境事实”以可配置的方式管理起来那么团队里的公共信息就是那份简明文档和绑定的组件版本列表而不是某个人在群里口头说“我这边是能跑的你们装个什么什么就行了”。落地时还有个细节不要把所有组件装齐再开工。让新人按项目文档只装A和B需要的组件不仅装得快也更能验证文档的完整性——如果缺了某个扩展正好说明文档需要补。这套流程跑顺了以后新同事入职第一天就能把本地环境跑通你的时间省下来比什么都强。6. 实践心得本地环境这件事很容易被当成“能用就行”的边缘事务。可它是每个开发者在每个工作日开门第一件要做的事体验好坏直接决定了一天工作的起步效率。我在这几周实测下来的感觉是FlyEnv最打动我的并不是某个单点的花哨功能而是它在“不引入过重机制的前提下把多项目隔离这件事做得足够顺手”。跟我之前手动管理环境变量和多个PHP目录的日子比起来现在最大的变化是心里没有那根弦了不用在切换项目前先回忆一遍环境有没有被动过也不会出现启动完项目发现PHP扩展少了一个、连数据库报密码错的连锁问题。它把环境配置沉淀成了一份可以查看、可以修改、可以随项目走的结构这份可预期性就是本地开发工具真正的价值所在。我保留的一个习惯是定期整理站点列表长期不维护的项目从工具里删掉或停用为环境保持清爽。毕竟工具能管理的组件越多堆积不用的“环境尸体”也越容易变多定期清理会让工具保持轻盈排查新问题时也更聚焦。最后补一个实用建议如果你目前在维护的项目同时跨越两个或以上的PHP大版本与其抱着一个全局XAMPP不放不如花一个傍晚把FlyEnv这类工具装起来把旧项目按配置迁进去。这个迁移成本大概率比你想象的低而每天省下来的切换时间则会持续回报你。
