V8流式解析仅对WebAssembly生效且需fetch响应体直接传入compileStreaming()。它要求application/wasm MIME类型、HTTP/2或preload优化，JS模块不支持原生流式加载，强行模拟反而低效。
V8 的脚本流式解析（Streaming Script Parsing）不是“开了就快”的开关，它只在满足特定条件时自动启用——核心前提是：脚本必须通过 fetch() 流式响应体传入，且调用 compileStreaming() 或 instantiateStreaming()，而非传统 eval、new Function 或同步 compile()。
为什么 fetch().then(r => r.text()) 会彻底禁用流式解析
调用 r.text() 会强制消费整个响应 body 并转为字符串，此时 V8 只能等到全部字节下载完成才开始解析，完全失去边下载边解析的机会。流式解析要求字节流持续、分块抵达 V8 的 parser，中间不能有缓冲或转换断点。
- 正确做法是直接将
Response对象传给WebAssembly.compileStreaming()或importScripts()（仅限 Worker）配合import.meta.url场景 - 对于 JS 模块，目前浏览器原生不支持
import()的流式加载；必须走WebAssembly.compileStreaming()+ 自定义 JS 解析器，或使用 Service Worker 拦截并转发流式响应 - Node.js 端不可用：V8 嵌入式 API 中的
ScriptCompiler::CompileUnboundScript不暴露流式接口，vm.Script也只接受完整字符串
compileStreaming() 只对 WebAssembly 生效，JS 模块需绕行
当前（Chrome 120+、Firefox 115+、Safari 17.4+）所有主流引擎中，compileStreaming() 的签名是 compileStreaming(response: Response): Promise<webassembly.module></webassembly.module>，它不接受 JS 字符串或 Blob，也不处理 application/javascript MIME 类型。
- 若想对大型 JS 文件启用类似机制，唯一可行路径是：Service Worker 拦截请求 → 用
stream.pipeThrough(new TransformStream(...))注入轻量解析逻辑（如提前提取export声明）→ 转发原始流给主线程 - 不能用
ReadableStream.getReader()手动读 chunk 后拼接字符串再传给eval：这等于自己实现低效 parser，且破坏 V8 内置的流式词法分析与语法树增量构建 - 模块图预编译（如 esbuild 的
--splitting+dynamicImport）比强行模拟流式更实际，尤其对首屏关键 JS
真正起效的流式场景：Worker 中加载大型 WASM + 初始化 JS 胶水代码
这是目前唯一能稳定触发 V8 流式解析并观测到性能提升的组合：WASM 模块体积越大，边下载边编译的收益越明显；JS 胶水代码则应保持极简，避免阻塞 WASM 实例化。
const wasmModule = await WebAssembly.compileStreaming(
fetch('/large-module.wasm')
);
const instance = await WebAssembly.instantiate(wasmModule, imports);
// 胶水代码里不要放 heavy init logic，留给 onRuntimeInitialized 回调
- WASM 文件必须以
application/wasm响应头返回，否则compileStreaming()会拒绝 - HTTP/2 Server Push 或
<link rel="preload" href="x.wasm" as="fetch">可进一步缩短首字节时间，放大流式优势 - 注意：
instantiateStreaming()是 compile + instantiate 一步完成，但无法复用 module，适合单次使用场景；重复实例化请拆成两步
流式解析的价值不在“让 JS 加载变快”，而在于把“网络延迟 + 编译耗时”的串行链路部分重叠。但 JS 引擎对源码的依赖远比 WASM 复杂——作用域分析、变量提升、eval 动态性都要求更完整的上下文。所以别试图把它套用到普通 JS 上，该分包分包，该预编译预编译。
