现象
人工硬件测试（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 只是减轻，未根治。
待做验证实验（用户暂缓，改完后补做）
- 勾选「保存原始数据」（raw tap 在分帧前，是 OS 交付字节的地面真值）
- 115200 + 2560B + 250ms 跑 60 秒
- 对比三个数字：发送字节数 / 接收字节数 / `~/Documents/SerialLogs/` 最新 raw 文件大小；并观察有无发送失败 toast
判读：
- raw = 发送 → 后端零丢失，问题纯在显示层（1000 条裁剪 / 轮询渲染落后）
- raw < 发送 → 实锤驱动层丢失，读线程被锁饿死
方向（无论实验结果如何都应做）
关联
现象
人工硬件测试（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 只是减轻，未根治。
待做验证实验（用户暂缓，改完后补做）
判读：
方向（无论实验结果如何都应做）
关联