bug(serial): 高负载持续接收时驱动层疑似丢字节（读线程被轮询克隆饿死） #9

现象

人工硬件测试（FTDI FT232R 环回，/dev/cu.usbserial-A5069RR4）：115200 8N1，2560 字节 / 250ms 周期发送（10.24 KB/s，线路容量 89%），接收数据不全。同速率在 2M 波特率（13% 负载）下正常。

嫌疑机制（代码分析，未实测）

前端每 100ms 轮询 `get_logs`，其实现在持锁状态下克隆整个日志缓冲（`serial_manager.rs:425`）。连续无分隔符数据流在 RFC #3 Step 2 后按 64 KiB 硬切块成帧，1000 条上限意味着单次克隆可达数十 MB memcpy。读线程 `emit_frame → add_log` 需要同一把锁（`:505`），读循环被卡住时 macOS FTDI 驱动 RX 缓冲（有限）在 11.5 KB/s 持续灌入下溢出，字节在驱动层被静默丢弃。

Step 2 之前帧大小无界，问题更严重；Step 2 只是减轻，未根治。

待做验证实验（用户暂缓，改完后补做）

1. 勾选「保存原始数据」（raw tap 在分帧前，是 OS 交付字节的地面真值）
2. 115200 + 2560B + 250ms 跑 60 秒
3. 对比三个数字：发送字节数 / 接收字节数 / `~/Documents/SerialLogs/` 最新 raw 文件大小；并观察有无发送失败 toast

判读：

• raw = 发送 → 后端零丢失，问题纯在显示层（1000 条裁剪 / 轮询渲染落后）
• raw < 发送 → 实锤驱动层丢失，读线程被锁饿死

方向（无论实验结果如何都应做）

• RFC RFC: 串口核心深化重构 —— 订阅式帧通道替代轮询，面向 Agent 可编程控制 #3 Step 4：事件推送替代轮询，`get_logs` 全量克隆路径退出热循环
• 日志缓冲与渲染解耦：读线程只 append 轻量结构 / 环形缓冲，显示层按需取窗口
• 临时缓解（可选）：降低轮询频率、限制单帧 display_text 长度

关联

• RFC RFC: 串口核心深化重构 —— 订阅式帧通道替代轮询，面向 Agent 可编程控制 #3（RFC: 串口核心深化重构 —— 订阅式帧通道替代轮询，面向 Agent 可编程控制 #3），TX 侧队列 feat(serial): TX write-behind 发送队列 + 背压与失败上报 #7