用Babel插件为代码自动补全import依赖：AST分析与工程实践

先说一个我自己的经历。前年接了一个维护中的中后台项目，路由文件里密密麻麻全是 const UserManage = () => import('@/views/user/UserManage') 这种写法，新增一个页面要手动加四五处代码。后来另一个模块更夸张，业务代码里到处直接写 Message.success()、Modal.confirm()，但文件顶部一个 import 都没有——因为之前是全局挂载的，重构拆模块之后全量报错。当时我就在想：这种“用到了但没引入”的问题，能不能让构建工具自动帮我补上？答案是肯定的，而且思路远比你想的简单：用 Babel 去读代码、分析 AST、找出“被使用但没被引入”的标识符，然后在语法树里把 import 插回去。这就是“用 Babel 为代码自动引入依赖”的底层逻辑，也是本文要完整展开的内容。

这篇内容适合三类人：一是被重复 import 折磨的业务开发者，二是想入门 Babel 插件开发的前端工程师，三是准备在团队里做工程化基建的工具链维护者。不需要你有多深的编译原理基础，只要写过 JavaScript、见过 Babel 配置文件，就能跟着一步步实现一个可用的自动补依赖插件。

1. 先搞清楚：哪些场景值得写一个“自动引入依赖”的 Babel 插件

1.1 三种最典型的真实需求

先说结论：不是所有“缺 import”的场面都适合用 Babel 自动补。我梳理了三个最典型、也是团队里被验证过真正能落地的场景。

场景一：按需引入 UI 组件库或工具函数库。

这是最经典的需求。组件库动辄几百个组件，全量引入会让打包体积爆炸，手动按需引入要么写一长串 import { Button } from 'antd'，要么用官方提供的 babel-plugin-import 之类的插件做样式和模块的按需加载。其实这种需求的核心也是“自动引入依赖”——你在 JSX 里写了 <Button>，插件帮你从组件库里引入这个组件，并顺带处理样式。

场景二：旧项目从全局变量迁移到模块化时的批量修复。

开头说的那个项目就属于这类。以前很多人图省事，用 Vue.use(Message) 或者直接把工具函数挂到 window 上，代码里直接用 Message.success()。后来要拆模块、做 SSR、做 Tree Shaking，这些全局变量就不能用了。你当然可以手动一个文件一个文件地加 import，但几十个文件、每个文件缺十几个依赖的时候，手工操作的效率和正确性都很成问题。这时候写一个临时的一次性 Babel 插件，自动把用到的全局标识符替换成从正确模块导入，会快得多。

场景三：基于约定的框架式开发，自动补全本应存在的导入。

比如某些业务框架约定，页面组件都放在某个目录下，只要在 JSX 里写了 <UserCard />，就自动从 @/components/UserCard 引入。这种“约定优于配置”的思路在内部脚手架里很常见。维护一个 Babel 插件比让每个人都记住手动 import 的规则可靠得多。

1.2 什么情况下不值得用 Babel 硬凑

有几种情况我不建议用 Babel 自动引入，容易把简单问题复杂化。

• 只缺一两个 import 的小文件：直接手动补上，收益不高，还亏了插件维护成本。
• 模块路径需要复杂计算才能确定：比如动态拼接路径、依赖运行时信息，Babel 是静态分析，做不了。
• 和现有的 ESLint、TS 检查规则冲突：自动引入的代码如果和团队 lint 规则不一致（比如 import 顺序、空行规范），反而会引入一堆新的 lint 报错。
• 需要读取文件系统内容才能判断：Babel 插件本身可以借助 Node.js API 读写文件，但这会显著拖慢编译速度，且缓存失效问题不好处理。能通过 AST 和静态约定解决的问题，不要拉到文件系统层。

把这些边界确认清楚，再决定是否值得动手。这里有一个判断标准：如果“缺依赖”的问题是系统性的、大范围的、有明确规律的，Babel 方案就值得做；如果只是偶发的小修小补，别折腾。

2. 写插件前必懂的 Babel 工作拆解：AST 三阶段与 Visitor 模型

2.1 代码从文本到 AST 再变回文本的完整旅程

很多人用 Babel 只用过预设和插件，比如 @babel/preset-env，平时不太关心它内部是怎么工作的。但写自定义插件，必须理解 Babel 处理代码的三个阶段：解析（Parse）、遍历（Traverse）、生成（Generate）。

解析阶段把源代码字符串变成一棵 AST（抽象语法树）。可以把 AST 理解成代码的“解剖图”：一个 const a = 1 不再是字符串，而是一个 VariableDeclaration 节点，它里面挂着 VariableDeclarator、Identifier（变量名 a）、NumericLiteral（数字 1）。遍历阶段会从上到下、从左到右访问这棵树里的每一个节点，你的插件代码就是在这个阶段被调用的。生成阶段再把修改后的 AST 重新变成代码字符串。

我常用一个生活类比：AST 就像是菜谱的分步清单，而不是“把菜名念一遍”。Babel 要做的，是在这张清单上找到某一行的“番茄”，把它改成“圣女果”，然后再把整张清单重新誊写一遍。修改的是清单本身，而不是文字替换。

为什么要基于 AST 而不是字符串替换？因为 AST 能精准区分“这是变量声明里的名字”和“这是使用处的名字”。同样是 Message，可能是变量名、对象的属性、导入的标识符，字符串硬替换很容易误伤。AST 不会，它知道每个节点的身份。比如 foo.Message.success() 里的 Message 是属性，不是独立的标识符，字符串替换会把 Message.success 错改成别的名称，但 AST 可以精准限定只处理 MemberExpression 里没被其他对象承接的属性访问。

2.2 Visitor 机制：为什么你不能只写一个 UnaryExpression 就覆盖所有情况

Babel 遍历 AST 时采用“访问者模式”（Visitor）。你的插件定义要监听哪些节点类型，Babel 在遍历到对应节点时会调用你注册的回调函数。

javascript复制module.exports = function ({ types: t }) {
  return {
    visitor: {
      Identifier(path) {
        // 每遇到一个标识符节点就会进来
      },
      JSXOpeningElement(path) {
        // 每遇到一个 JSX 开始标签就会进来
      }
    }
  };
};

每个节点类型都对应一种访问器。关键在于，Identifier 是一个非常笼统的类型，const a = 1 里的 a 是 Identifier，a + 1 里的 a 也是 Identifier，甚至 import { a } from 'x' 里的 a 还是 Identifier。如果你在 Identifier 里无脑收集名字，会把所有的声明、属性、关键字都收进来，然后就会把根本不缺的变量也当成“需要自动引入”的目标。

所以在做自动引入时，通常要结合几道判断。第一道，判断这个 Identifier 是否是被引用的标识符，可以用 path.isReferencedIdentifier() 排除声明和属性。第二道，判断它是否在某个我们已经处理过的节点中（比如已经处理过的 JSX 标签名字），需要配合父路径判断。第三道，判断它的作用域里是不是已经有绑定了，这其实就是“是否已经引入或声明”的依据。

这也是为什么写自动引入依赖的插件，核心不是“找到 Identifier”，而是“精确地判断出哪些 Identifier 是真正需要被补 import 的使用点”。判断条件越宽松，误伤面越大。

3. 核心实现：识别使用点、查重、补 import 的完整套路

3.1 插件骨架与入口设计

先给出一个标准插件的骨架：

javascript复制const PLUGIN_NAME = 'babel-plugin-auto-import';

module.exports = function ({ types: t }) {
  const pendingImports = []; // 暂存需要补充的 import

  return {
    name: PLUGIN_NAME,
    visitor: {
      Program: {
        enter(path, state) {
          pendingImports.length = 0;
        },
        exit(path, state) {
          // 所有使用点分析完成后，统一插入 import
          insertPendingImports(path, state);
        }
      },
      Identifier(path, state) {
        collectIdentifierUse(path, state, pendingImports);
      }
    }
  };
};

我习惯把待插入的 import 先收集到一个数组里，而不是在遍历过程中立刻插入。这样可以避免“边遍历边改树结构”导致 Babel 遍历器索引错乱的问题，也方便统一去重。

3.2 识别“谁需要被自动引入”

假设我们的需求是：只要代码里用了某个来自 @utils 的工具函数（比如 formatDate），但当前文件没有引入它，就自动补 import { formatDate } from '@utils'。

实现大致如下：

javascript复制const AUTO_MODULE_SOURCE = '@utils';
const AUTO_IMPORT_NAMES = ['formatDate', 'debounce', 'throttle'];

function collectIdentifierUse(path, state, pendingImports) {
  const node = path.node;
  if (!path.isReferencedIdentifier()) return;
  if (!AUTO_IMPORT_NAMES.includes(node.name)) return;
  // 如果当前作用域里已经存在同名绑定，说明已经引入或声明过了
  if (path.scope.hasBinding(node.name)) return;

  pendingImports.push({
    local: node.name,
    imported: node.name
  });
}

这里有几个关键点。

path.isReferencedIdentifier() 用来过滤掉“声明处”和“属性名”。import { formatDate } from '@utils' 里的 formatDate 是一个标识符，但它出现在 import 声明里，不是“使用”。const obj = { formatDate: 1 } 里的也是属性名，不需要处理。这个方法能帮我们排除大多数误报。

path.scope.hasBinding(node.name) 是自动引入逻辑的“隔离墙”。它沿着当前标识符所在的作用域链向上查找，看是否存在名为 formatDate 的绑定。如果存在，就说明这个文件里已经声明过或者从别的模块引入过这个变量，不需要再补。如果不存在，才认为它“无依无靠”，需要自动引入。

3.3 用作用域信息判断是否已引入，避免重复

上面的 hasBinding 判断能挡住大部分“已引入”的情况，但它有一个盲区：如果 formatDate 在 @utils 之外的其他模块里也被引入过呢？假设场景 A 里你自动引入了 import { formatDate } from '@utils'，后来你又在文件里手动写了 import { formatDate } from 'date-helper'，这时候 hasBinding 会认为已有绑定不再处理，但两个来源却不是同一个。还会导致一个问题：重复自动引入。第一次分析时发现没有绑定，给你补了一个，第二次插件又跑一遍时，hasBinding 已经能查到绑定就不会重复，这只是表面逻辑。但如果你在一个 Program.exit 里同时收集到多个使用点，不做去重，就会插入多行一模一样的 import。

所以收集阶段的去重很重要。我用一个 Map 或者 Set 来记：已经收集过 @utils 的 formatDate，再遇到就直接跳过。

javascript复制const collected = new Map(); // key: localName, value: true

function pushPendingImport(localName, importedName, source) {
  const key = `${source}:${importedName}:${localName}`;
  if (collected.has(key)) {
    return;
  }
  collected.set(key, true);
  pendingImports.push({ localName, importedName, source });
}

同时，在 Program.exit 阶段，我会扫描已有的顶层 ImportDeclaration，把已经引入过的模块记录成一张表，再过滤掉 pendingImports 里的重复项。这样无论用户在文件里写过什么 import，都不会被重复插入。

3.4 在 Program 入口统一补写 ImportDeclaration

在 Program.exit 阶段做插入，是最稳妥的做法。此时整棵 AST 已经遍历完，你可以放心地修改它的子节点。

javascript复制function insertPendingImports(programPath, pendingImports) {
  if (!pendingImports.length) return;

  // 找到已存在的 import 语句，用于去重
  const existingImports = new Set();
  for (const stmt of programPath.node.body) {
    if (t.isImportDeclaration(stmt)) {
      existingImports.add(stmt.source.value);
    }
  }

  const importsToAdd = pendingImports.filter(
    (item) => !existingImports.has(item.source)
  );

  if (!importsToAdd.length) return;

  // 按模块源分组，结构化为 ImportDeclaration 节点
  const grouped = groupBySource(importsToAdd);
  const importNodes = Object.keys(grouped).map((source) =>
    t.importDeclaration(
      grouped[source].map((item) =>
        t.importSpecifier(
          t.identifier(item.local),
          t.identifier(item.imported)
        )
      ),
      t.stringLiteral(source)
    )
  );

  // 插入到 import 区之后、其他语句之前
  programPath.unshiftContainer('body', importNodes);
}

补充说明一下为什么用 unshiftContainer 而不是直接把节点塞进 body 数组。unshiftContainer 是 Babel 提供的作用域安全方法，它不仅会把节点插到 body 数组开头，还会处理 parent 指针、作用域注册等内部信息。如果你手动 push 进 body，节点没有正确的 parent 关系，后续的 Babel 插件可能无法正常工作。

插入位置放在最前面是符合规范的。ES Module 的 import 声明虽然不一定强制要求出现在首位，但绝大多数 lint 规则都约定 import 语句放在文件顶部，所以我们也按这个约定来。

3.5 完整代码示例与产物对比

把上面的逻辑拼起来，一个基础版自动引入插件的完整代码类似这样：

javascript复制const MODULE_SOURCE = '@utils';
const AUTO_IMPORT_NAMES = ['formatDate', 'debounce', 'throttle'];

function buildPlugin({ types: t }) {
  const pendingImports = new Map();
  const collectedKeys = new Set();

  return {
    name: 'babel-plugin-auto-import-utils',
    visitor: {
      Program: {
        enter() {
          pendingImports.clear();
          collectedKeys.clear();
        },
        exit(path) {
          if (!pendingImports.size) return;

          const existingSources = new Set();
          path.node.body.forEach((stmt) => {
            if (t.isImportDeclaration(stmt)) {
              existingSources.add(stmt.source.value);
            }
          });

          if (!existingSources.has(MODULE_SOURCE)) {
            const specifiers = Array.from(pendingImports.values()).map((name) =>
              t.importSpecifier(t.identifier(name), t.identifier(name))
            );
            const importDecl = t.importDeclaration(
              specifiers,
              t.stringLiteral(MODULE_SOURCE)
            );
            path.unshiftContainer('body', [importDecl]);
          }
        }
      },
      Identifier(path) {
        const name = path.node.name;
        if (!AUTO_IMPORT_NAMES.includes(name)) return;
        if (!path.isReferencedIdentifier()) return;
        if (path.scope.hasBinding(name)) return;

        const key = `${MODULE_SOURCE}:${name}`;
        if (!collectedKeys.has(key)) {
          collectedKeys.add(key);
          pendingImports.set(name, name);
        }
      }
    }
  };
}

module.exports = buildPlugin;

拿一个示例文件跑一下，输入：

javascript复制export function main() {
  return formatDate(new Date()) + debounce(fn, 200);
}

产物是：

javascript复制import { formatDate, debounce } from '@utils';

export function main() {
  return formatDate(new Date()) + debounce(fn, 200);
}

这个例子虽然简单，但已经覆盖了“收集使用点 - 查重 - 插入”的完整链路。

4. 实战案例：自动为 JSX 里用到的组件补全 import

4.1 需求描述与约定

再上一个更贴近真实业务的实战案例。假设团队内部有一个统一的基础组件目录 src/components/base，里面有 Button、Input、Modal、Toast 等组件。为了省去手写 import 的麻烦，我们约定：只要 JSX 里写了 <Button>，就自动从 @/components/base/Button 引入这个组件。命名上要求首字母大写，与普通 HTML 标签区分。

这个例子相比上一节，要从 Identifier 换成 JSXOpeningElement，还需要解析组件名。

4.2 具体实现

javascript复制const BASE_COMPONENT_DIR = '@/components/base';

function buildPlugin({ types: t }) {
  const pendingComponents = new Map();

  return {
    name: 'babel-plugin-auto-import-base-components',
    visitor: {
      Program: {
        enter() {
          pendingComponents.clear();
        },
        exit(path) {
          if (!pendingComponents.size) return;

          const existingSources = new Set();
          path.node.body.forEach((stmt) => {
            if (t.isImportDeclaration(stmt)) {
              existingSources.add(stmt.source.value);
            }
          });

          const importNodes = [];
          pendingComponents.forEach((componentName) => {
            const source = `${BASE_COMPONENT_DIR}/${componentName}`;
            if (existingSources.has(source)) return;
            const importDecl = t.importDeclaration(
              [t.importDefaultSpecifier(t.identifier(componentName))],
              t.stringLiteral(source)
            );
            importNodes.push(importDecl);
            existingSources.add(source);
          });

          if (importNodes.length) {
            path.unshiftContainer('body', importNodes);
          }
        }
      },
      JSXOpeningElement(path) {
        const node = path.node;
        const tagName = node.name;
        if (!t.isJSXIdentifier(tagName)) return;

        const componentName = tagName.name;
        // 约定：首字母大写结尾的视为基础组件
        if (!/^[A-Z]/.test(componentName)) return;
        if (path.scope.hasBinding(componentName)) return;

        pendingComponents.set(componentName, componentName);
      }
    }
  };
}

module.exports = buildPlugin;

这里有几个细节需要注意。

JSX 的标签名不一定是简单的标识符，可能是 Foo.Bar 这种成员表达式。所以在 path.node.name 上先判断一下 isJSXIdentifier，把复合类型的标签名排除掉，否则直接取 name.name 会拿到 undefined 甚至报错。

首字母大写的判断用来过滤掉 HTML 原生标签（div、span 等）。虽然 HTML 标签不会通过 path.scope.hasBinding 判断，但真实项目中往往有自定义的小写组件，比如工厂函数生成的局部组件。加一层大小写判断更安全。

4.3 测试与验证

我按这个插件写了一个测试文件，用 @babel/core 直接跑转换：

javascript复制const babel = require('@babel/core');

const code = `
function App() {
  return (
    <div className="page">
      <Button type="primary">点击</Button>
      <Input placeholder="请输入" />
    </div>
  );
}
`;

const result = babel.transformSync(code, {
  plugins: [autoImportBaseComponents]
});

console.log(result.code);

输出结果是：

javascript复制import Button from '@/components/base/Button';
import Input from '@/components/base/Input';

function App() {
  return (
    <div className="page">
      <Button type="primary">点击</Button>
      <Input placeholder="请输入" />
    </div>
  );
}

注意，div 没有被自动引入，因为它不以大写字母开头，被过滤掉了。这里的实现没有把“同名局部变量”的场景覆盖得很细，但在组件约定的前提下，大多数情况是够用的。如果你想做更严格的处理，需要继续判断这个组件名是否被当前作用域的某个 import 声明占用，以及占用后来源是否和约定目录一致，这个逻辑就属于进阶版去重了。

5. 最容易踩的坑：从重复引入到 main.js 报错

5.1 重复插入与插入顺序错乱

这是新手最容易遇到的问题。如果你在遍历过程中直接往 Program 里插入 import 节点，而不是收集后统一插入，很可能会出现两个问题。

第一，同一个使用点被访问多次，导致插入多行一模一样的内容。比如 JSX 里写了三次 <Button>，JSXOpeningElement 访问器就会触发三次，每次触发都插入一次 import。第二，边遍历边插入会影响 Babel 对后续节点的遍历顺序，可能出现插入后的新节点也被再次访问，导致无限循环或者节点丢失。

解决办法就是前面代码里展示的：先收集到一个 Map/Set 里，在 Program.exit 统一处理。这不仅是代码风格问题，更是稳定性的保障。

5.2 作用域误判导致的静默失败

path.scope.hasBinding 是一个作用域链的查询，但它返回 true 的情况不一定代表“这个标识符已经被正确引入”。比如你在模块顶部 const formatDate = () => {} 自己定义了一个同名函数，然后用了 formatDate()，此时 hasBinding 返回 true，插件不会自动填充 @utils 的 formatDate。这个行为其实是正确的——本地有定义，不该自动引入。

但反过来有个陷阱：如果某个变量在文件里被函数参数占用了，比如 function foo(formatDate) { return formatDate(); }，这里的 formatDate 已经有了函数参数绑定，插件同样不会自动引入。可这个函数的本意可能是想调用工具函数，只是参数名撞了。这种情况下插件“静默失败”——既不报错也不补依赖，结果就是运行时行为和你预期不符。所以自动引入插件的识别规则必须保守，宁可漏掉也不要误改。强行自动修改参数名会引入更隐蔽的 bug。

5.3 命名冲突：同名变量与自动重命名

上面提到参数名冲突属于“不该自动补”的场景。还有一种情况是“确实需要自动补，但补进去之后和已有变量冲突”。例如：

javascript复制import { Modal as AppModal } from './app-modal';

const Modal = () => <div>local</div>;

export default function Demo() {
  return <Modal />;
}

这里 Modal 已经有一个本地定义了，但它来自一个局部变量，而按你的约定，Modal 应该从 base/Modal 组件目录引入。如果插件强行插入 import，就会出现重复声明，直接编译报错：Identifier 'Modal' has already been declared。

处理这类冲突有两种策略。策略一：自动重命名新加入的组件为 BaseModal，并把模板里 JSX 对应的名字也替换掉。策略二：跳过该使用点，只对没有冲突的组件自动引入。我个人建议先采用策略二，稳字当头。自动重命名会把改动扩散到 JSX 里，如果模板里还有字符串形式引用的组件名，会漏改，产生运行时找不到组件的错误。

5.4 与 TypeScript 场景相关的坑

TypeScript 项目里，自动引入还要考虑类型导入的问题。如果在 .ts 或 .tsx 文件里要用 import type { Foo } 而不是普通 import，Babel 生成的 ImportDeclaration 默认是值导入。如果目标模块只导出了类型，那么转换后的代码在类型检查时不一定报错，但在某些开启了 isolatedModules 的构建配置下会报错。

处理方式是在插件里判断当前文件是否处于 TS 环境，以及目标符号是否可能只是类型。你可以给插件增加配置项，要求使用方显式声明哪些模块应该用 import type 生成。或者，更简单的方式：插件只处理值导出的模块，类型导入交给 IDE 的自动导入功能去做。Babel 是一个代码转换工具，不是类型检查器，不要试图把类型系统的判断也塞进来。

5.5 实际项目中“babel 报错”的排查思路

聊到“自动引入依赖”，就绕不开实际项目中 Babel 本身报错的问题。特别是很多人在 main.js（Vue 项目入口）或者 main.tsx（React 项目入口）里配置插件后，突然发现编译过不去了。

排查这类问题，我的经验是按下面这个顺序来：

1. 看报错堆栈指向的是“解析错误”还是“转换错误”。解析错误多半是你的代码有语法问题，或者 Babel 版本与语法特性不匹配；转换错误才是插件的问题。
2. 确认插件在 Babel 配置中的顺序。插件是从前往后执行的，预设是先于插件执行的（确切地说预设会先执行，但插件转换顺序与配置顺序有关，这里的关键是：如果你的自动引入插件依赖其他插件处理后的 AST，就必须放后面；反之如果它会改变 AST 结构，就必须放前面）。
3. 不要忽略缓存。Babel 有缓存机制，改完插件配置后不生效，十有八九是缓存没清掉。Webpack 场景下删掉 node_modules/.cache，Vite 场景下删掉 node_modules/.vite。
4. 最小化复现。单独建一个 .js 文件，用 @babel/core 的 transformSync 跑一遍，定位问题是在插件逻辑还是构建工具集成。

排查原则跟技术本身无关，就是缩小范围、减少变量。

6. 最后的经验：如何让这种插件在团队里真正落地

6.1 从局部场景开始，别一上来就全量

我见过不少团队做工程化插件，上来就全量铺开，结果出问题影响面太大，最后回滚。自动引入依赖这种插件，建议先挑一个目录或一条业务线试点。比如先在 src/pages/demo 目录跑一个月，看看生成的 import 是否符合预期、有没有误伤的案例、lint 和类型检查是否通过，再决定是否扩大到整个应用。

6.2 写好报错提示与降级策略

另外一个很重要的点是：插件是给人用的，报错信息一定要友好。在你无法判断某个标识符该不该自动引入时，宁可跳过也不要强行引入，但可以输出一个 process.env.NODE_ENV !== 'production' 时才打印的警告，说明某个文件里出现了无法识别的同名变量。这样使用者能知道是插件“主动放过”了，而不是代码出了问题。

保险起见，你可以给插件加一个开关配置：

javascript复制{
  plugins: [
    [autoImport, { enable: true, warnOnly: true }]
  ]
}

warnOnly 为 true 时，插件只输出警告但不做任何转换。这在发布后的紧急排查阶段非常有用，可以做到“带着问题跑但别直接挂掉”。

6.3 相关方向与扩展思路

自动引入依赖只是 Babel 能做的事情里的一个小分支。基于同样的能力，还可以做自动清理未使用的 import、自动按需引入 polyfill、自动注入 CSS 样式引入等。

我实际用下来最有获得感的是：给项目维护一个“模块使用地图”，凡是组件库、工具函数库这种有清晰导出边界的模块，都可以用这套思路做自动引入。不过也要提醒一句：这类插件适合“减少重复劳动”，不适合“把不能跑通的代码变成能跑通的代码”。如果团队里已经到处是坏代码、循环依赖、命名冲突，别指望一个 Babel 插件能救场，先把架构和数据流理清楚才是根本。

最后分享一个我写这类插件时的小窍门：调试阶段不要急着接入构建配置，直接用 @babel/core 的 transformSync 加一个超简单的测试用例。用例越简单越好，比如只写一行 const x = formatDate()，看产物是不是预期。确认基础逻辑没问题，再扩展到 JSX、作用域、命名冲突这些复杂场景。每一步都留一个可运行的最小测试，能省掉后面绝大多数的排查时间。