根本原因是Linux内核TTY层的输入缓冲区配置不当,需禁用icanon、设置min/time、关闭echo/icrnl,并在PHP中正确调用setReadInterval(0)和setReadChar(0),再循环read直至收全数据。
PHP 本身没有原生串口 API,实际依赖 system() 调用 stty + cat、或扩展如 php-serial、php-ext-serialport。但无论哪种方式,**Linux 内核 TTY 层的输入缓冲区(icanon 模式下的行缓冲、VMIN/VTIME 设置)才是决定能否收全长数据的关键**。PHP 层面只是读取者,不是缓冲区管理者。
常见现象:发 2KB 数据,PHP 只读到前 1024 字节;或等几秒才突然收到全部;或中间夹杂乱码——这基本是 icanon 开启、VMIN 设为 1、且设备未发换行符导致的阻塞/截断。
stty -icanon 是必须第一步stty -icanon min 0 time 1(非阻塞轮询)或 min 1024 time 0(等满 1024 字节再返回)stty -echo -icrnl,避免干扰原始二进制流
参数并禁用超时php-serial 是最常用的 PHP 串口封装,但它默认 read() 行为受内核 TTY 配置约束,且自身有内部缓冲逻辑。若不调整,$serial->read(8192) 可能立刻返回空或只返回几十字节。
关键操作顺序不能错:
立即学习“PHP免费学习笔记(深入)”;
stty 配置好端口(见上一节),例如:stty -F /dev/ttyUSB0 115200 -icanon min 0 time 1 -echo -icrnl
$serial->setReadInterval(0) 和 $serial->setReadChar(0)**,否则它会按字符或间隔等待,破坏大数据连续性read() 的参数不是“最多读多少”,而是“尝试读多少”,实际返回长度由内核缓冲区当前可用字节数决定。要收完一帧,得循环读直到满足长度或超时$expected_len = 4096;
$data = '';
while (strlen($data) < $expected_len) {
$chunk = $serial->read($expected_len - strlen($data));
if ($chunk === false || $chunk === '') break;
$data .= $chunk;
usleep(10000); // 避免空转占 CPU
}很多传感器或工控设备发的是自定义协议:比如 0xAA 0x55 LEN[2] PAYLOAD... CRC[2]。这时不能假设“一次 read(1024) 就拿到整帧”,因为内核缓冲区可能只攒了半帧,也可能跨帧粘连。
正确做法是维护一个接收缓冲区,持续 read 并拼接,然后在应用层解析:
read() 后追加到 $buffer 字符串末尾strpos($buffer, "\xAA\x55") 找帧头,再按协议解析 LEN 字段strlen($buffer) >= 帧头位置 + 2 + LEN + 2,则提取完整帧,substr() 截取,并 substr() 剩余部分继续缓存\x00,PHP 字符串可正常处理,但别用 strlen() 以外的函数(如 mb_strlen())误判长度Windows 上有人用 php_com_dotnet 调用 MSComm 或 SerialPort 类,但这套方案在大数据场景下极不稳定:COM 端口驱动缓冲区小、.NET 层事件触发延迟高、PHP COM 对象生命周期难控制,极易出现 0x8007000E(内存不足)或读取不全。
替代方案只有两个:
php-ext-serialport(需自行编译,支持 Windows,底层调用 Win32 API CreateFile + SetCommTimeouts,可精确控 ReadIntervalTimeout 和 ReadTotalTimeoutConstant)真正卡住的往往不是 PHP 语法,而是没意识到:串口通信里,stty 的配置权重远高于 fread() 的写法;而协议解析必须放在 PHP 层,不能指望驱动替你分帧。