如何通过自定义代码转译插件实现在构建阶段对异步代码性能预估

构建工具无法直接估算async函数性能，因其仅静态分析而async耗时依赖运行时环境；Rollup插件通过AST提取await数量、嵌套深度、URL字面量等信号打分；Vite插件在buildEnd汇总高分函数并输出带定位的警告。

为什么不能直接在构建阶段估算 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）辅助识别。