构建阶段自定义转译插件预估异步代码性能

说实话，想在构建阶段直接估算出 async 函数的真实性能，这件事本身就不太现实。构建工具本质上是做静态分析和代码转换的，它并不真正“运行”代码。而 async 函数的性能高低，几乎完全取决于运行时环境——网络延迟、I/O 负载、CPU 争抢，这些都不是构建时能够模拟出来的。

那静态分析能做什么呢？实际上可以提取一些“信号”：比如函数里有多少个 await 表达式、嵌套深度如何、调用的资源路径是否看起来是远程的、有没有没被 try/catch 包裹的 fetch 调用。把这些信号提取出来，基于一些启发式规则打个分，这就算得上是静态估算的极限了。

为什么不能在构建阶段直接估算 async 函数的性能

构建工具（如 Webpack、Vite）本身不执行代码，只做静态分析和转换。而 async 的实际耗时高度依赖运行时环境（网络延迟、I/O 负载、CPU 竞争），静态插件无法真正“运行”它。所谓“预估”，本质是提取可量化的信号——比如 await 表达式的数量、嵌套深度、调用的资源路径特征、是否包含未标记的 fetch 或 setTimeout——再结合启发式规则进行打分。

如何用 Rollup 插件提取异步结构并打分

Rollup 的 transform 钩子配合 Acorn 解析 AST 是最直接的做法。关键不在于模拟执行，而是识别出那些影响调度节奏的关键节点：

• 匹配所有 await 表达式，统计其父级 FunctionDeclaration 或 ArrowFunctionExpression 的层级深度
• 检测 await 右侧是否为字面量 URL（如 await fetch("/api/user")），标记为“高不确定性”
• 跳过已被 try/catch 包裹的 await（视为有容错设计，风险权重降低 30%）
• 对包含多个并行 await（如 Promise.all([a(), b()])）的函数额外加权，但上限设为单个串行链的 1.2 倍（避免高估并发收益）

来看一个具体的打分逻辑片段（Rollup 插件内）：

function estimateAsyncCost(node) {
  if (node.type === 'AwaitExpression') {
    const score = 1;
    const parentFn = findParent(node, ['FunctionDeclaration', 'ArrowFunctionExpression']);
    const depth = getNestingDepth(parentFn);
    return score * Math.min(depth, 3); // 深度 >3 视为失控风险
  }
  return 0;
}

Vite 插件中注入构建警告而非修改代码

比起在插件里强行插桩、改写业务逻辑，更务实的做法是：在构建收尾阶段（buildEnd）做一次汇总，然后把那些评分异常的函数找出来，带上源码位置直接输出警告。Vite 的 configResolved 和 buildEnd 钩子能拿到完整的模块图，用来做跨文件聚合非常合适：

• 用 esbuild 的 analyzeDeps 提前捕获动态 import() 目标，计入 IO 风险分
• 对评分 ≥ 5 的函数，通过 console.warn 输出：文件路径 + 行号 + “疑似长链异步（await 深度=3，含未包裹 fetch）”
• 不自动插入 console.time，因为那会污染生产包；如需实测，应由开发者手动加 /* @perf */ 注释触发

容易被忽略的边界：Top-level await 和条件 await

构建时静态分析极易漏掉两类情况：

• if (flag) await apiCall()：AST 中 AwaitExpression 存在，但执行概率未知 → 统一按 50% 权重计入总分
• 模块顶层的 await（如 const data = await import("./data.json")）：它阻塞整个模块初始化，但不在函数体内 → 单独归类为“模块级阻塞分”，阈值更低（≥2 即告警）

真正难处理的从来不是语法，而是那些没有写进 AST 的隐式依赖：比如 await db.query(...) 底层走的是 WebSocket 还是本地 IndexedDB，构建阶段根本无从得知。这类情况只能靠约定（例如强制在函数名中包含 Remote 或 Local）辅助识别。