引用更新：STM32侧文档合并后，根因引用改指链路延迟测试说明.md §7.3

README.md

@@ -169,7 +169,7 @@ AA 03 00 04 00 00 00 00 00
 
 **现象**：拉取一帧 LCDMEM（3209B）原本中位 **68.8ms**，其中约 52ms 卡在帧尾那 137B 小段上。
 
-**根因**（已在 DTU 侧台架确证，见 STM32F4-Base 仓库 `docs/测试说明/链路时延实测数据分析.md` §3.3）：
+**根因**（已在 DTU 侧台架确证，见 STM32F4-Base 仓库 `docs/测试说明/链路延迟测试说明.md` §7.3）：
 DTU 侧 CH395F 的 MSS=1024、发送 FIFO=1024B，因此每次 1024B 写恰好是**满 MSS 段**（立即发送）；
 而 3209B = 3×1024 + **137B**，最后这段是**次 MSS 段** → 芯片按 Nagle 规则扣住它，等前一数据被 ACK。
 Windows 默认**延迟确认**把该 ACK 推迟 40~200ms，整帧因此被拖住。

remo_disp_server.py

@@ -206,7 +206,7 @@ def _send(cmd: int, data: bytes = b"") -> bool:
 # 延迟确认（Delayed ACK）抑制：LCDMEM 整帧被拖慢 40~200ms 的根因与解法
 # =============================================================================
 # 机理（2026-09-22 台架实测确证，见 STM32F4-Base 仓库
-#   docs/测试说明/链路时延实测数据分析.md §3.3）：
+#   docs/测试说明/链路延迟测试说明.md §7.3）：
 #   CH395F 的 MSS=1024、发送 FIFO=1024B，因此 MCU 每次 1024B 写恰好是一个
 #   “满 MSS 段”（Nagle 允许立即发送）；而 LCDMEM 应答 3209B = 3×1024 + 137B，
 #   最后 137B 是“次 MSS 段” → 芯片按 Nagle 规则把它扣住，等前一数据被 ACK。