海康威视前端实习一面：AI 建站渲染链路与回读对账

《面试题目》

1. 自我介绍
2. AI 建站项目从用户输入到渲染的流程
3. AI 建站项目里客户端起到的作用
4. 这个渲染功能比较难的技术点是什么？
5. 项目在渲染过程中会存在性能问题吗？
6. 虚拟列表的实现方案
7. 在智能体平台中对结果不明的写入进行回读对账，哪些场景是「结果不明」？
8. 回读对账怎么实现的？
9. 旅行平台项目瀑布流卡片用的是 Flex 还是 Grid？它们的区别是什么？
10. HTTP 缓存和前端数据缓存的区别？
11. 界面上登录过一次，在页面刷新和页面切换时不会因为认证原因登出的实现方式？
12. 如果关闭浏览器，还能不能保存 token？
13. WebSocket 流式传输和 SSE 的区别？
14. 实习中遇到的最困难的事
15. 能否接受 Vue 作为主要技术栈？

《参考解析》

AI 建站这类「生成式 UI」的链路，可以按「输入 → 生成 → 校验 → 渲染」四段讲。 用户输入需求后，服务端调用模型产出结构化的页面描述（JSON Schema、DSL 或组件树，而不是直接产出 HTML，便于校验与二次编辑）；前端拿到后进行 schema 校验与降级（字段缺失、组件未注册、属性非法都要有兜底），再交给渲染器把描述映射成真实组件；渲染过程中要处理流式增量（模型还在输出时先渲染已完成部分）、占位与骨架屏、以及错误重试。客户端在其中的作用是「可信渲染 + 交互 + 状态管理」：把不可信的模型输出约束在可渲染的白名单组件内、处理用户对生成结果的编辑与局部重生成、并承担预览与保存/发布的状态同步。难点通常不在渲染本身，而在增量更新的稳定性（流式片段到达时避免整树重渲染与布局跳动）、schema 兼容（老版本页面在新渲染器上还能打开）、以及性能（复杂页面节点多、频繁更新导致掉帧）。

「结果不明的写入」指的是那些「请求发出去了，但客户端无法确定服务端有没有执行」的时刻。 典型场景：调用超时或连接中断（服务端可能已成功）、网络抖动导致响应丢失、用户主动取消但服务端已受理、以及服务端返回 5xx 但其实已落库。这类场景不能简单重试（会造成重复写入），所以要回读对账：为每次写入生成客户端幂等键（业务 id + 请求 id），超时或异常后先用只读接口按幂等键查询真实状态，确认未生效才重试，确认已生效就直接采用服务端结果；服务端侧同样要用唯一约束与幂等表把重复请求收敛到同一结果。实现要点：幂等键要持久化（刷新/重开页面后仍能查）、查询接口要能按幂等键精确定位、对账要有退避重试与「长时间未确认」的告警兜底，另外要把「我不确定」这个状态显式呈现给用户，而不是假装成功或失败。

瀑布流选型与缓存问题。 用 Flex 还是 Grid 取决于是否需要「定高」：Grid 适合等高、规则的卡片，能直接表达行列关系；不等高瀑布流通常用绝对定位 + JS 计算最短列（或 CSS 的 columns/grid-template-rows: masonry，后者兼容性有限），原因是布局需要知道每张卡片高度后再决定落到哪一列。RN 里没有 CSS Grid，所以用最短列算法是常见做法——代价是滚动时要做高度测量与重排，长列表要配合虚拟化与预计算。HTTP 缓存 vs 前端数据缓存：前者是浏览器对响应资源的缓存（强缓存 Cache-Control/Expires + 协商缓存 ETag/Last-Modified），管的是「这次请求要不要发出去」，作用在传输层；后者是把接口返回的数据存在内存/IndexedDB（SWR、React Query 等），管的是「这次渲染用不用旧数据、什么时候后台刷新」，作用在应用状态层。两者可以叠加：静态资源走 HTTP 缓存，接口数据走应用层缓存 + 失效策略。

登录态保持与 token 存储，是一道边界很清楚的题。 页面刷新或路由切换不掉线，说明凭证存在比内存更持久的地方：localStorage/sessionStorage/cookie 或 IndexedDB，配合应用启动时的静默刷新（refresh token 换 access token）。sessionStorage 的生命周期是标签页会话——页面刷新仍在，关闭标签页就清空；localStorage 关闭浏览器后依然保留（除非清除数据），所以「关闭浏览器还能不能保存 token」的答案是：localStorage 和持久化 cookie 能，sessionStorage 不能。安全取舍：localStorage 会被 XSS 读取，所以生产上更推荐 httpOnly + Secure + SameSite 的 cookie（JS 读不到，防 XSS 窃取）配合 CSRF 防护；无论存哪里，access token 都应短寿命 + 服务端可吊销（jti 黑名单或版本号），不能只依赖「存得隐蔽」。

WebSocket 与 SSE 的差异。 SSE 是单向的（服务端 → 客户端）、基于普通 HTTP 长连接、文本协议（text/event-stream）、浏览器原生自带断线重连与 Last-Event-ID 续传，非常适合大模型流式输出这类场景；缺点是只能服务端推、走 HTTP/1.1 时受同域连接数限制（HTTP/2 下可多路复用）。WebSocket 是全双工、需要一次握手升级协议（Upgrade: websocket），适合双向高频交互（聊天、协同编辑、游戏），代价是要自己做心跳保活、重连、鉴权（不能带自定义 header，通常用一次性 ticket 或首帧认证）和连接数管理。选型判据：只需要服务端推送用 SSE（更简单），需要双向实时用 WebSocket。用 SSE 做流式输出时要注意中间层（网关、CDN、Nginx）的缓冲与超时会切断连接，需要关闭缓冲并配置超时。