docs(即时同步): 订正延迟排查结论 —— 不是 nginx 缓冲, 瓶颈在客户端应用/渲染段

上一版文档把 ~14s 延迟归因于 nginx 未关闭 proxy_buffering, 实测推翻了该判断:
- 已为 iboard.honor3.com 配置 proxy_buffering off / proxy_read_timeout 1h 并热重载,
  nginx -T 确认生效, 但端到端延迟无任何改善;
- powersync 服务日志 (docker logs -t): 改库与服务端 checkpoint_complete 几乎同一秒
  (13:46:53.738), 另一次约 6s —— 服务端推送很快;
- 同步流是长连接 (stream_ms 达 42 分钟, close_reason: client closing stream), 非频繁重连;
- 临时把 db 挂到 window.__psdb 轮询: 数据确实已写入客户端本地库, 但 DOM 更新明显滞后。

结论修正为: 瓶颈在客户端「同步数据应用 → db.watch 通知 → React 渲染」这一段,
延迟 15~30s 且波动 (1s/6s/17s/27s), 更像排队或重试退避。文档补充了下一步排查方向。

nginx 那组配置未回滚: 对长连接流式接口属合理配置, 且已验证不影响其它站点。

docs/V0.2/离线编辑模块/即时同步方案.md

@@ -234,36 +234,39 @@ useDbSignal(TASK_LIST_SIGNAL_SQL, [projectId, projectId, projectId, projectId, p
 
 ## 7. 已知边界与后续
 
-### 7.0 实测：UI 已自动刷新，但传输层延迟约 14s（待修）
+### 7.0 实测：UI 已自动刷新，但端到端延迟仍有 15~30s（未解决）
 
-P0 落地后实测（真实 Windows 外壳 + 服务端直接改库）：
+P0 落地后实测（真实 Windows 外壳 + 服务端直接改库模拟另一端）：
 
 | 项 | 结果 |
 | --- | --- |
 | 是否还需要切页面 | **不需要** —— 服务端改完标题，页面在无任何操作的情况下自动更新 ✅ |
-| 端到端延迟 | **约 13~14s**（三次复测一致），远超 ≤1s 目标 ❌ |
+| 端到端延迟 | 反复测量为 **15~30s 且波动**，远超 ≤1s 目标 ❌ |
 
-排查结论：**延迟不在 UI 层**。用 CDP Network 观察客户端，发现：
+**排查过程与结论（注意：初版猜测"nginx 缓冲"是错的，已撤回）**
 
-- **没有任何 WebSocket 连接**；
+| 步骤 | 证据 | 结论 |
-- 只有两次 `https://iboard.honor3.com/sync/stream` 请求。
+| --- | --- | --- |
+| 客户端是否建立 WebSocket | CDP Network：**无 WebSocket**，只有 `POST /sync/stream` | PowerSync 走 HTTP 流式，属正常 |
+| 是否 nginx 缓冲导致 | 为 `iboard.honor3.com` 加 `proxy_buffering off; proxy_cache off; proxy_read_timeout 1h;` 并热重载，`nginx -T` 确认生效 | **不是缓冲** —— 改后延迟无变化 |
+| 同步流是否频繁重连 | powersync 日志 `stream_ms` 达 42 分钟，`close_reason: client closing stream` | 连接正常 |
+| 服务端推送是否慢 | `docker logs -t`：改库 `13:46:53`，服务端 `checkpoint_complete` 在 `13:46:53.738`（另一次约 6s） | **服务端推送很快**（亚秒~数秒） |
+| 客户端本地库何时更新 | 临时把 db 挂到 `window.__psdb` 轮询 | 数据确实到达客户端本地库 |
+| 界面何时更新 | 同一轮询里 DOM 更新明显晚于数据到达 | **瓶颈在客户端「应用→通知→渲染」这段** |
 
-而 NPM（baishe 上的 `nginx-app-1`，配置 `/data/nginx/proxy_host/5.conf`）对
+即：**服务端推得快、数据也确实进了客户端本地库，但 `db.watch` 的通知 / React 渲染要等 15~30s**，
-`iboard.honor3.com` 只设置了 `Upgrade` / `Connection` / `proxy_http_version 1.1`，
+且波动很大（1s / 6s / 17s / 27s 都出现过），更像排队或重试退避，而非固定轮询间隔。
-**没有关闭 `proxy_buffering`**（nginx 默认开启）。PowerSync 的 `/sync/stream`
-是长连接流式（NDJSON）响应，被 nginx 缓冲后按批下发 —— 与观测到的固定 ~14s 批次延迟吻合。
 
-**待办（运维，非代码）**：为 `iboard.honor3.com` 的 `/sync` 增加
+**已做的运维改动（保留）**：`iboard.honor3.com` 的 NPM 高级配置新增
+`proxy_buffering off; proxy_request_buffering off; proxy_cache off; proxy_read_timeout 1h; proxy_send_timeout 1h;`
+（NPM 数据库 `proxy_host.advanced_config` 与当前生效 conf 均已更新，零停机热重载）。
+它没能解决本问题，但对长连接流式接口属合理配置，故保留。
 
-```nginx
+**下一步（未做）**：
-proxy_buffering off;
+1. 给 `useDbSignal` 临时加时间戳日志，区分「watch 回调延迟」与「`load()` 之后渲染延迟」；
-proxy_cache off;
+2. 若 watch 回调本身滞后，改用 `useQuery`（`@powersync/react` 的 watched query）；
-proxy_read_timeout 1h;      # 避免长连接被掐断
+3. 对比 Android 端（无 SharedWorker、走独立 worker）的同一测量，判断是否与 worker 拓扑相关；
-chunked_transfer_encoding on;
+4. 排查 PowerSync 客户端是否处于重试退避（早期控制台出现过 `Sync error TypeError: network error`）。
-```
-
-改完需重载 nginx，并复测延迟。注意该 NPM 实例同时承载 gitea / homepage 等站点，
-改动应只作用于该 proxy_host，避免影响其它服务。
 
 
 | 项 | 说明 |