前端流式解析chunk数据相关面试题
-
在实现后端 chunk 分段返回、前端流式解析的处理链路时，后端需要遵循怎样的 HTTP 协议规范来实现 chunked 传输？请详细说明相关响应头字段的设置以及 chunk 数据的格式要求，同时举例说明一个完整的 chunked 响应数据结构是怎样的。
-
前端使用 Reader + Decoder 机制拼接 JSON 数据时，首先需要通过什么 API 获取到可读取的流对象？在创建 Reader 对象（如 ReadableStreamDefaultReader）后，调用 read () 方法获取数据块时，返回结果的结构包含哪些属性？这些属性分别代表什么含义？请结合代码示例说明从获取流到首次读取数据块的完整过程。
-
项目中提到遇到题目或图表时自动分段渲染，在流式解析 JSON 数据的场景下，如何判断当前读取到的 JSON 片段是否包含完整的题目或图表相关数据结构？需要考虑哪些 JSON 语法特性（如嵌套结构、字符串中的特殊字符等）来避免误判？请设计一个具体的判断逻辑方案，并说明其合理性。
-
在使用 Decoder（如 TextDecoder）对 Reader 读取到的二进制数据块进行解码时，可能会遇到数据块分割在多字节字符（如中文、特殊符号）中间的情况，导致解码后出现乱码。针对这种问题，TextDecoder 自身是否有应对机制？如果有，请详细说明其原理；如果没有，你会如何在代码中处理该问题，确保解码后的文本完整性？
-
假设在流式解析过程中，后端突然中断了 chunk 数据的传输（如网络异常、服务器错误），此时前端 Reader 的 read () 方法会触发什么状态？前端如何捕获这种异常情况并进行优雅处理（如提示用户、尝试重新连接、清理已解析的数据等）？请结合 Promise 的状态变化和错误处理机制进行说明，并给出关键代码片段。
-
当 JSON 数据被分段传输时，前端拼接 JSON 片段的过程中，可能会出现部分 JSON 结构不完整的情况（如缺少闭合括号、引号不匹配等）。在将拼接后的 JSON 字符串转换为 JavaScript 对象（如使用 JSON.parse ()）之前，如何提前校验当前拼接的字符串是否符合 JSON 语法规范的子集（至少能保证 parse () 不报错）？请对比不同校验方案（如正则表达式、轻量级 JSON 解析库、自定义语法分析器）的优缺点及适用场景。
-
项目中实现了 “遇到题目或图表时自动分段渲染”，请详细说明前端如何在流式解析 JSON 数据的过程中，识别出 “题目” 或 “图表” 对应的 JSON 节点？识别到目标节点后，是立即暂停流的读取进行渲染，还是继续读取后续数据同时进行渲染？两种处理方式分别会面临哪些性能或用户体验方面的问题，如何优化？
-
在不同的浏览器环境中，ReadableStream、TextDecoder 等 API 的支持情况存在差异（如部分低版本浏览器不支持）。为了保证项目的兼容性，你会采取哪些措施？请从降级方案设计（如不支持流式解析时采用传统的完整数据下载后解析）、Polyfill 选择（推荐合适的 Polyfill 库并说明选择理由）、浏览器版本检测逻辑等方面进行详细阐述。
-
假设后端返回的 chunk 数据中，除了 JSON 格式的业务数据外，还包含一些用于控制流式处理的元数据（如当前 chunk 的序号、总 chunk 数量、数据类型标识等），前端如何在解析过程中区分并提取这些元数据？请设计一种元数据与业务数据的封装格式，并说明前端对应的解析逻辑，确保元数据不干扰业务数据的拼接与渲染。
-
对比传统的 “后端返回完整 JSON 数据后前端一次性解析渲染” 与项目中采用的 “后端 chunk 分段返回 + 前端流式解析分段渲染” 两种方案，从网络传输效率（如首字节时间、数据传输中断后的重试成本）、前端内存占用（如处理大型 JSON 数据时的内存消耗差异）、用户体验（如页面渲染延迟、交互响应速度）三个维度进行详细分析，说明在什么业务场景下，项目采用的流式处理方案更具优势？
