twosee

这个……你应该去Google官方仓库提吧

protobuffer部分用的是官方的, 是指经客户端接收的数据出现了错误吗?

### 删除异步客户端 它们的存在严重的导致了协程生态的混乱, 你不可能在协程中混用它们, 协程可以100%甚至更好的实现异步, 你可以用轻松地用协程写出异步的效果(你只要使用go创建一个协程, 把代码帖进去, 它就是异步的了), 但异步却无法拥有协程强大的调度能力. - swoole_mysql_client - swoole_redis_client - swoole_http_client 暂不考虑删除timer, 异步写文件等, 在很多场景下它们都很有用, 如异步写日志等, 你无需过多思考或者创建新的协程.

### 删除一些无用的异步回调 - onBufferEmpty - onBufferFull 这两个水位线回调只是在异步时代为了在缓冲区快满时避免发送失败, 增加了大量的心智负担, 你有了协程以后再也不用理会它了, 协程会帮你自动调度.

### 删除同步阻塞TCP客户端 只应用于fpm模式下, 而且底层为此加入了一些环境判断.

### 删除`Runtime配置方法`和`enable_coroutine`选项并强制开启 我们要拥抱一个纯协程的生态, 我们就不再需要它们, 就像go语言那样简单纯粹, 既然你使用了Swoole协程, 那么你就要**全面启用**它, 你的代码里就不应该存在同步阻塞, 否则你写出来的程序将毫无意义. 因此, 协程化将强制开启, 各种[事件回调](https://wiki.swoole.com/wiki/page/949.html)中都会是协程的环境, 而PHP中曾经同步阻塞的一系列IO方法也会变成协程的, 你将不会有太多顾虑, 尽管书写你的协程代码: - `phpredis`扩展 - 使用`mysqlnd`模式的`pdo`、`mysqli`扩展，如果未启用`mysqlnd`将不支持协程化 (PHP默认就是mysqlnd) - [`soap`](http://php.net/manual/zh/book.soap.php)扩展 - `file_get_contents`、`fopen`等一系列[文件函数](http://php.net/manual/zh/ref.filesystem.php) - `stream_socket_client` (和所有基于它实现的库, 如[`predis`](https://github.com/nrk/predis)) - `stream_socket_server`(和所有基于它实现的库)...

### 删除不必要的协程环境自动识别 现在的Swoole中, 如果你使用了coroutine_hook, 或是开启了`Runtime::enableCoroutine`, 在hook同步函数转为协程调度的时候, 底层会判断当前是否为协程环境, 如不是则退化为同步模式, 这一判断兼容完全没有必要, 而且增加了检查开销, 一旦你使用了协程化, 你就应该只在协程中使用它, 否则你的程序会立即退化为同步模式.

### 最大程度地禁止同步阻塞的方法 目前的`Runtime::enableStrictMode`是一个比较鸡肋的方法, 而且会和`Runtime::enableCoroutine`冲突, 如实行了上一个提案内容, 那么严格模式也有了用武之地, Swoole内核将会强制开启严格模式, 禁止所有协程之外的阻塞IO操作, 一旦你在不小心使用了阻塞IO, 你的程序将会立即退化为同步模式, 损失大量的性能, 协程也将失去意义. 所以底层将会在开发者使用了协程的时候, 阻止开发者错误地使用阻塞方法, 并在此时抛出一个致命的错误警告.

### 删除Process模式(有争议的内容) 根据Swoole创始人Rango的意见, Process是一个不那么必要的设计, Process模式最大的作用是在worker进程异常退出的时候Master能够保持长连接不断开. 但是Process模式增加了两次IPC开销, 不支持一些高级功能, 其性能相比于Base模式相差巨大(Base简单高效, 能快速承载海量连接), 并且开发者时常在各种投递模式(dispatch_mode)中作无谓的纠结, 且由于Proces模式的复杂性, 它可能会更容易出错. Process模式完全可以被nginx等专业的代理替代, 并且在对外的生产环境中, nginx总是必须的, 如http服务, swoole只实现了基本的应用服务器级别的协议解析支持, 而nginx则是拥有最为完备的协议解析支持. 就算没有Process模式, Base模式也支持异步安全重启特性和`max_request`等特性

### 删除Swoole\Serialize 此功能与PHP内核各种设计和数据结构强依赖, 而PHP内核每个版本都有很大变动, 已经无法继续兼容维护各个版本, 且该功能在一些场景下稳定性无法保证, php的serialize十分稳定且能满足绝大部分开发者的需求, 无需为了节省一些小小的内存而去使用`Swoole\Serialize`.