简历追问：低代码执行状态实时同步

关联：全栈工程师简历 > 低代码工作流引擎、15分钟：低代码平台。

对应简历描述

在 NestJS 中实现了 SSE / WebSocket 实时通信机制，支持长耗时业务节点的执行状态实时监控与日志流式推送，优化了开发者的调试体验。

面试官真正想确认

你是否处理过长任务状态、日志流、断线恢复和多订阅者，而不是只会“WebSocket 推一下”。

连续追问链

1. 通信选择

• 为什么同时提 SSE / WebSocket？各自适合什么场景？
• 如果只是服务端推执行日志，为什么不用轮询？轮询的成本或体验问题在哪里？
• 连接鉴权、租户隔离和执行实例权限怎么做？

2. 事件模型

• 事件类型有哪些：execution_started、node_started、log、progress、node_finished、node_failed？
• 日志是全量推送还是增量推送？客户端如何排序和去重？
• 节点状态和日志是否来自同一个通道？如果不是，如何保持一致？

3. 可靠性

• 浏览器刷新或网络断开后，如何从 last event id 继续？
• 服务端是否持久化最近日志和节点状态，还是只在内存里广播？
• 日志量很大时如何限流、采样、折叠或分页，避免拖垮浏览器？
• 多个用户同时看同一个执行实例，是否每人一份任务还是广播订阅？

4. 调试体验

• 开发者如何从 UI 定位哪个节点卡住、哪个变量解析失败？
• 长耗时 HTTP / 批处理节点有没有 heartbeat？没有事件时 UI 怎么判断还活着？
• 节点失败后是否能从某个节点重跑？重跑时日志如何区分 execution attempt？

场景推演题

一个批量导入节点运行 10 分钟，每秒产生日志。用户在第 6 分钟刷新页面，网络还断了 30 秒。请说明服务端、客户端和日志存储如何保证恢复后还能看到正确进度。

继续追：如果日志暴涨到每秒 1000 条，前端怎么不被刷爆？

准备证据

• SSE / WebSocket 事件 schema。
• reconnect 与 last-event-id 处理流程。
• 日志限流/分页策略。
• execution attempt 状态设计。

容易露馅的回答

• “用 ws 实时推就行。”
• “断线了重新执行任务。”
• “日志直接 append 到页面。”
• “开发者刷新页面以后看不到之前日志也没关系。”