主题
React + AI 应用开发
React AI 长文本和长列表如何优化性能？
AI 页面变慢往往不是模型慢，而是每个 token 都重解析长文档、维持过大的 DOM 和强制滚动。
面试官想考什么
- 长回答卡顿怎么定位？ 考察性能诊断顺序。
- 虚拟化消息列表有什么坑？ 考察滚动和动态高度。
- Markdown 和代码高亮放 Worker 吗？ 考察边界与通信成本。
- 自动滚动如何不打扰用户？ 考察交互细节。
一句话回答
text
先用性能面板定位是流式更新、解析、高亮、布局还是 DOM 数量问题，再采用 delta 批处理、已完成 block 缓存、虚拟化、Worker 和可见性策略；自动滚动只在用户接近底部时执行，并为长内容提供暂停和跳转。面试回答详解
1. 诊断路径
text
网络/TTFT -> React commit -> JS 长任务
-> Markdown/highlight -> layout/paint -> DOM/内存不要一上来就加 memo。先用 Performance、React DevTools、Long Tasks 和内存快照确认瓶颈。
2. 流式更新
按帧或时间窗口批量提交 delta；已完成段落缓存 AST，新增内容只处理当前 block。代码高亮在 code fence 完整后执行，超长代码只提供纯文本或按需高亮。
3. 列表虚拟化
历史消息很多时使用虚拟列表或分页。动态高度、图片加载、代码块展开会改变测量，需要 anchor 修正和滚动位置保护。正在生成的消息通常保持挂载，避免虚拟化频繁销毁 reader 关联的 UI。
4. Worker 与并发
Markdown AST、代码高亮、文件解析等 CPU 密集任务可放 Worker，但要考虑结构化克隆成本、取消和版本竞态。useTransition 可降低非紧急视图更新优先级，但不替代 Worker，也不减少数据量。
5. 滚动和可访问性
用户在底部时自动滚动；用户向上阅读时显示“跳到最新”而不是强行抢焦点。流式文本更新要保持可读顺序，使用 aria-live 时控制频率，避免屏幕阅读器逐 token 宣读。
可直接背诵的 30 秒回答
text
我先用 Performance 和 React Profiler 判断瓶颈，再优化。流式消息按帧批量更新，完成 block 和高亮结果缓存，长历史用虚拟列表，CPU 密集解析放 Worker。动态高度要维护滚动 anchor，自动滚动只在用户接近底部时发生，离开底部就显示跳转按钮，同时控制 aria-live 更新频率。扩展知识
content-visibility
对非可见长内容可考虑 content-visibility: auto，但它不是虚拟化替代品，仍需验证动态高度、可访问性和浏览器兼容。
面试官追问链
追问一：为什么 memo 没解决卡顿？
- 考察点：定位能力。
- 回答方向：可能是父组件 props 引用变化、单个消息自身重算、Markdown 或布局成本过高；需要 profiler 指向具体阶段。
追问二：Worker 一定更快吗？
- 考察点：成本意识。
- 回答方向：小文本可能因序列化和调度更慢；只把 CPU 密集、可异步和可取消的任务移出主线程。
追问三：虚拟列表能否渲染流式消息？
- 考察点：生命周期。
- 回答方向：可以，但生成状态要在列表外部持有，避免卸载丢状态；对当前消息可采用固定挂载或特殊 overscan。