Swoole加密扩展：别急着上，加密先想清楚你的扩展场景

我见过太多团队把Swoole加密扩展当成万能钥匙，装上就以为数据安全了。加密结果呢？扩展性能掉一半，业务代码乱成一团。加密这玩意儿压根不是扩展给你所有接口用的。

Swoole加密扩展本质上是加密把OpenSSL的加解密能力搬进了Swoole的协程环境里。它最大的扩展卖点是不阻塞进程——你用`openssl_encrypt`的时候，PHP得等CPU算完，加密但Swoole的扩展加密扩展能让你在协程里发请求、查数据库的加密同时，让底层的扩展OpenSSL去跑AES或RSA。这思路挺聪明，加密但很多人忽略了它的扩展适用边界。

拿我们之前一个支付回调项目举例。加密对方要求所有响应体必须用AES-256-GCM加密，而且得在50毫秒内返回。最开始用原生PHP，单次加密耗时约2毫秒，并发一高CPU就飙到90%。换成Swoole加密扩展后，单次加密降到0.4毫秒，但前提是我把加密操作扔进了一个独立的协程池里，而不是直接在主协程里调。这里头有个坑——如果你直接在主协程里调用`Swoole\Encryption::encrypt()`，效果跟原生函数没区别，照样阻塞，因为协程切换的前提是你主动让出CPU，但CPU密集型的加密计算根本不会主动让出。

真正好用的场景是配合`Swoole\Coroutine\Channel`做异步任务分发。比如你有100个请求需要加密，每个加密耗时0.5毫秒，如果串行跑就得50毫秒。但你开10个协程，每个负责10个加密任务，它们之间通过Channel通信，总耗时能压到5毫秒左右。这玩意儿本质上是把单线程的加密计算拆成了多协程并发，但别指望它能帮你突破CPU的物理上限——如果机器只有2核，你开100个协程也没用。

还要注意版本兼容问题。Swoole 4.8和5.0的加密API有差异，4.8里用`Swoole\Encryption`，5.0直接改成了`Swoole\Crypto`。去年我们升级时踩过坑，老代码里用了`Swoole\Encryption::setKey()`，结果在5.0里直接报方法不存在。这种坑最烦人，官方文档写得含糊，只提了“新版本改进了性能”，但具体改了什么全靠自己试。

我的建议是：如果你的项目只是偶尔做几次加密，比如登录token生成，压根没必要上这个扩展，原生`openssl_encrypt`就够了。但如果你在写网关、消息队列消费者这类高并发且加密频繁的服务，那它确实能帮你把CPU利用率拉满。不过别指望它能解决业务设计问题——比如你本来就不该在响应体里带太多敏感数据，那加密再快也是白搭。

最后说个细节：Swoole加密扩展支持硬件加速，比如Intel的AES-NI指令集。但默认编译参数里没开，你得在编译时加`--enable-crypto-hardware`。我们当时没注意，后来看`php --ri swoole`才发现输出里没有AES-NI支持。开了之后，AES-128加密速度能再提30%。这种隐藏配置，官方文档里就一行小字，不翻源码根本发现不了。

说白了，这扩展是给懂协程、懂CPU调度的工程师准备的。你要是刚接触Swoole，先老老实实把原生加密用好，等真遇到性能瓶颈了，再回来研究它也不迟。