核心结论
抽象语法树插件链增长后，需要分别定位构建阶段成本和产物运行成本。只统计整个 Babel 任务耗时，无法判断瓶颈来自解析、插件遍历、代码生成、源码映射还是缓存失效。应按文件和插件采集阶段耗时、节点访问量、实际改写率、输出字节增量、峰值内存和缓存命中率，再结合单插件禁用实验、顺序调整及最终产物差异确定责任节点。
底层机制
典型处理流程包含 parse、transform 和 generate。@babel/parser 将源码构造成抽象语法树，插件借助 @babel/traverse 和访问器遍历节点，通过 NodePath、作用域与插件状态完成改写，最后由 `@babel/g
