CH395F 硬件测试完毕

docs/CH395F_Trap_Records.md

@@ -395,3 +395,39 @@ MobaXterm 上传文件时 CH395F 收到数据（`s1 int=0x04` RECV_OK 持续触
 ### 注意事项
 - CH395F 接收缓冲区默认 socket 0: 4096B, socket 1: 4096B。读空后客户端继续发数据，recv_len 重新递增——正常
 - 清理中断状态后 `handle_timeout_event` 中的 `ch395f_close_socket` 必须显式调用，确保下次 `open_socket` 成功
+
+---
+
+## Trap 14：close 后 DISCONNECT 滞后锁存，污染下次会话首次中断读取
+
+### 现象
+`close_socket` → 轮询 `GET_SOCKET_STATUS` 已确认 CLOSED 后，紧接的下一会话（重新 open + connect）在第一次读 `GET_INT_STATUS_SN` 时读到**上一会话遗留的 DISCONNECT 事件**（0ms 即命中），导致负向判定/状态机误判。实测：TC-202 三轮重连后立即跑 TC-203，PC 端握手实际成功（连接被接受），固件却因陈旧 DISCONNECT 抢先判"未连接"。
+
+### 根因
+- `wait-CLOSED` 轮询用的 `GET_SOCKET_STATUS` 是**纯查询，不清中断**；
+- TCP 拆除过程中断（DISCONNECT）可能在与 CLOSED 状态达成几乎同时、甚至之后才锁存；
+- 该事件无人消费，跨会话存活到下一次 `open_socket` 之后。
+
+### 解决
+1. **预清**：新会话 OPEN 前读一次 `GET_GLOB_INT_STATUS_ALL` + `GET_INT_STATUS_SN` 丢弃陈旧事件；
+2. **反核实**：依据中断做结论前，用 `GET_SOCKET_STATUS` 验证实际状态一致（如"负向事件 vs ESTABLISHED"矛盾时以状态为准）。
+
+### 参考
+`test/ch395f_test_task.c: phase2_tc203()`（双保险实现）；同类思路见 Phase 1 入口的 PHY_CHANGE 预清。
+
+---
+
+## Trap 15：DHCP 成功后 IP 寄存器提交滞后
+
+### 现象
+`GET_DHCP_STATUS` 已置 0x00 后立即 `GET_IP_INF`，回读到的仍是**旧静态配置**（如 192.168.1.100），而芯片实际已按新租约（192.168.1.77）正常收发——串口打印与 Socket6 广播宣告均带出过期 IP。2026-08-24 上板实测：固件各检查全 PASS（6/6），但 PC 侧 HELLO 发往租约地址才得到应答，三方数据矛盾构成假阳性。
+
+### 根因
+DHCP 状态位仅代表协商流程完成；IP/MASK/GW 寄存器的提交与状态置位是异步的，存在数百毫秒级窗口（实测 ~1s 内完成翻转）。
+
+### 解决
+1. **稳定轮询**：连续 3 次读 `GET_IP_INF`（间隔 300ms，上限 8s）结果一致且非零才采信；
+2. **交叉比对**：PC 端将收到的宣告 IP 与所分配租约比对，不一致即报错兜底。
+
+### 参考
+`test/ch395f_test_task.c: phase4_run()`；`docs/CH395F_Test_Guide.md` 阶段 4 风险表 #4。