fread()不能直接作Socket Buffer，因其阻塞式裸读、无缓冲管理、每次调用触发系统调用，且不保证读满协议帧，导致需手动拼包和维护复杂状态机；amphp/byte-stream通过内存Buffer游标操作提供read/peek/skip等原子能力，真正适配协议解析需求。
为什么不能直接用 fread() 做 Socket Buffer？
因为 fread() 是阻塞式、无缓冲区管理的裸读，每次调用都触发系统调用，小包频繁收发时性能断崖下跌；更麻烦的是它不保证读完完整协议帧（比如你期望读 4 字节长度头，它可能只返回 2 字节），导致上层必须手动拼包、状态机维护复杂度飙升。
真实场景里，比如实现一个 Redis 协议解析器或自定义二进制协议服务端，你需要：按需预分配内存、支持可变长度读取、能回退已读字节（比如 peek 检查 magic byte 后决定是否丢弃）、避免重复 memcpy。这些都不是 fread() 能扛住的。
- 别把
stream_set_read_buffer($socket, 8192)当真 —— 它只影响底层 OS socket buffer，PHP stream 层依然每次fread()都做 syscall - 别在循环里反复
substr($buf, $offset)截取 —— 每次都 copy 新字符串，内存和 CPU 双爆炸 - 协议头还没凑齐就急着
unpack()？会触发 warning 并返回 false，但错误不抛异常，容易静默失败
用 amphp/byte-stream 替代手写 Buffer 类
这个库不是玩具，是 Amp 生态里被 amphp/http-server 和 amphp/redis 实际压测验证过的流抽象层。它把 socket fd 封装成 ReadableStream，核心是内部维护一个 Buffer 对象（基于 SplFixedArray + 游标偏移），所有读操作都在内存 buffer 上做指针移动，只有 buffer 空了才真正调用 recv()。
关键点在于它提供 read()（阻塞直到指定字节数）、readAvailable()（当前 buffer 有多少就读多少）、peek()（只看不消费）、skip()（跳过若干字节）—— 这些才是协议解析需要的原子能力。
立即学习“PHP免费学习笔记（深入）”；
- 安装：
composer require amphp/byte-stream，不要装全量amphp/amp，仅流操作不需要事件循环 - 初始化：
$stream = new InputStream($socket);，其中$socket是socket_create()或stream_socket_server()返回的 resource - 读长度头示例：
$header = yield $stream->read(4);→ 返回 string，不是 int；若连接断开会 throwCancelledException，需捕获 - 注意：
yield不代表必须用协程 —— 该库也提供同步适配器SyncInputStream，但性能损失约 15%，仅调试用
reactphp/buffer 的边界与陷阱
ReactPHP 的 Buffer 更轻量，API 简单（append()、read()、shift()），但它默认不处理 partial read：当底层 recv() 只返回 1 字节，而你 $buffer->read(4) 时，它不会等待补满，而是直接返回 null。这意味着你必须自己轮询 + 判断 EOF，逻辑容易漏分支。
它适合做「粘包暂存」而非「协议解析」—— 比如 TCP 收到一堆乱序数据块，先 append() 进 buffer，再由上层按协议规则切分。但一旦涉及固定头+变长体结构（如 MQTT 的 remaining length 编码），就得额外写状态机来 hold 住未完成帧。
- 别依赖
$buffer->getSize()判断是否可读 —— 它返回总长度，但没告诉你有没有足够字节满足你的read()请求 -
$buffer->read(0)返回空字符串，不是 null，这点和amphp/byte-stream不一致，容易写错条件判断 - 它没有
peek()，想检查前 2 字节又不想消费？只能$slice = substr($buffer->toString(), 0, 2);—— 触发一次完整字符串 dump，大 buffer 时很伤
Buffer 大小设置不是越大越好
很多人一上来就设 8192 或 65536，以为越大吞吐越高。实际中，Buffer 容量直接影响内存碎片和 GC 压力：一个长期存活的 Buffer 对象如果预分配 64KB，而平均每次只处理 200 字节，剩余空间就成了内存黑洞；更糟的是，PHP 的字符串内存管理对大块连续内存敏感，频繁 resize 容易触发内存重分配。
建议按协议最大单帧长度设上限，再加 20% 冗余。例如 HTTP/1.1 header 通常 compact()（amphp/byte-stream 提供）或 clear()（reactphp/buffer 提供）在帧处理完后收缩。
- 别用
str_repeat("\0", $size)手动预分配 —— PHP 字符串是 copy-on-write，substr()之后原字符串仍驻留内存 - Unix domain socket 场景下，Buffer 大小建议 ≤ 4KB —— 本地通信延迟极低，大 buffer 反而增加单次 syscall 数据量，降低响应灵敏度
- 如果你用
socket_recv()自己轮询，记得检查返回值：0 表示对端 close，-1 表示 error（socket_last_error()查原因），这两者都不能当成“没数据”继续等
Buffer 管理真正的难点不在分配，而在生命周期控制：谁负责清空、谁决定扩容、断连时 buffer 里残留半帧怎么处置。选库只是起点，协议边界识别逻辑才是绕不开的硬茬。
