MixPHP V3 主推 Swoole、WorkerMan 驱动，因为这两个平台性能强劲。然而大部分的 PHP 开发者都是开发 API, Web 的程序员，热更新可能是最大的刚性需要，因而我对 Vega 做了扩大，让 MixPHP 减少了 PHP-FPM、CLI-Server 的反对，开发环境能够应用这两种模式，线上部署时切换为性能更强劲的 Swoole、WorkerMan 驱动。

最近几年在 javascript、golang 生态中游走，发现很多 npm、go mod 的长处。最近回过头开发 MixPHP V3 ，发现 composer 其实始终都是一个十分优良的工具，然而 phper 们对 composer 的用法很多都不是很深刻，明天我就采纳 composer 手撸一个原生我的项目，帮忙大家了解现代化的原生 PHP 开发流程。

Vega 是 MixPHP V3+ 内置的最外围的组件 (可独立应用)，参考golang gin mux 开发，它蕴含 Web 利用解决的大量性能 (数据库解决除外)，包含：路由、渲染、参数获取、中间件、文件上传解决等；具备 CLI 模式下弱小的兼容性，同时反对 Swoole、WorkerMan, 并且反对 Swoole 的多种过程模型。

最近搞了一台 M1 的 Mac mini 筹备用这个开发 mixphp v3 版本，之前尝试了几次没有编译胜利，明天再次尝试装置胜利了，网络上很多人的文章存在问题（可能是零碎环境不同），特此分享让后续的人闭坑。

在之前的版本中可能有这样一种状况，在 WebSocket 服务器中无奈在 close 事件回调中辨别该 fd 是否为 WebSocket 连贯，例如以下代码：

macOS中pecl形式装置swoole报Enable openssl support, require openssl library谬误

环境应用 Docker：在 docker 中搭建 swoole 运行环境服务器端应用后面文章中的代码：在 Swoole 中应用 WebSocket 服务端和客户端测试程序代码： {代码…} 测试后果： {代码…}

Swoole装置问题官网文档　–　[链接]官网谬误问题 — [链接]一.装置问题：编译问题　　(1) 明天部署PHP多版本共存，遇到编译失败error，没有找到php-config，在编译装置swoole时，./configure须要一些参数，残缺如下： ./configure –with-php-config=/usr/local/php7/bin/php-config 后边门路请替换成本人的理论门路。…

swoole服务器运行过程中php文件是常驻内存运行，这样就能够防止反复的读取磁盘，反复的解释编译php，以便达到最高的性能，所以批改代码须要重启服务

这里为什么要减少这两个函数呢？有这样一种场景。应用Swoole\Server实现RPC服务，在EOF协定或长度协定通信形式下，一个包可能有3局部组成。