lazy、Suspense 与数据请求是什么关系？
先理解原理和示例，再练习完整口述与追问。
回答要点
lazy 延后加载组件代码，Suspense 对支持挂起的依赖显示 fallback；普通 useEffect 请求不会自动激活 Suspense。采用框架或支持的集成，分别处理加载中、请求失败和代码加载失败。
原理拆解
lazy 延迟加载组件模块，Suspense 在其支持的挂起机制尚未准备好时展示 fallback；它们不自动把任意 useEffect 请求转成可挂起的数据源。代码、数据、错误和重试应分别建模，框架若提供支持 Suspense 的数据获取机制，再按该机制使用。
示例与推演
路由图表代码首次下载时由 Suspense 显示骨架；组件挂载后普通 fetch 的等待仍需自身 loading 状态。若 chunk 下载失败，通常由错误边界展示错误；若 API 返回业务失败，则显示具体业务提示。将边界放在面板级可以保留已可用内容，不必因一个慢面板替换整页。
易错点
不要在 render 中随意新建每次身份不同的 Promise 来“实现 Suspense”。直接请求模式应依赖成熟框架或清楚的缓存协议，并定义服务端行为。
参考回答可直接练习口述
lazy 让 React 按需加载组件代码，Suspense 在子树遇到支持挂起的依赖时展示 fallback。它不是通用的 Promise 监听器，普通 Effect 内请求不会自动触发挂起。业务中可用框架支持的数据获取机制，把加载态放在合适边界；网络失败和 lazy 加载拒绝还要有相应错误处理。
面试官可能继续问追问与完整解答展开收起
追问
边界放在哪里更合理？为什么不能给任意 Promise 外面包一层 Suspense 就认为完成数据加载设计？React 官方 Suspense
追问回答
边界应按用户可独立等待的区域组织，太高会让整页退回 loading，太碎会让体验零散。随意在 render 创建新 Promise 会产生重复请求和不稳定挂起；需要支持 Suspense 的缓存与集成，不能只包一个组件名就认为完成。