构建工具无法直接估算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）辅助识别。
