1. 这个报错不是代码写错了，而是模块系统在“说方言”
你刚执行vite build，控制台突然跳出一行红字：
“default” is not exported by “node_modules/xxx”
紧接着构建中断，本地开发一切正常，打包却翻车——这种问题在 Vite + Vue3 / React 项目里高频出现，尤其当你引入某些老旧的 CommonJS 库（比如lodash-es混用lodash、axios的旧版本、js-yaml、uuidv3/v4、甚至部分内部封装的工具包）时，几乎必踩。它不是你 import 写错了，也不是库本身坏了，而是 Vite 背后的 Rollup 在解析模块时，听不懂对方说的“话”。
Vite 默认使用 ESM（ECMAScript Module）作为模块规范，所有依赖都期望以export default xxx或export const xxx = ...的形式提供导出。但大量 npm 包（尤其是 2018 年前发布的、或未做 ESM 兼容改造的）仍采用 CommonJS 格式：module.exports = xxx或exports.default = xxx。Rollup 本身不原生支持 CommonJS，它需要靠插件把 CJS “翻译”成 ESM。而这个翻译过程一旦出偏差——比如某个包的package.json里没声明"type": "module"，或者它的main字段指向的是.cjs文件，又或者它用了动态require()、__dirname等 Node.js 特有变量——Rollup 就会卡住，直接抛出那句经典的：“default” is not exported。
更麻烦的是，这个错误不报在你写的代码行上，而是藏在 node_modules 某个深层依赖里。你import { debounce } from 'lodash'看着没问题，但lodash内部可能依赖了lodash._reinterpolate，而后者又用了require('some-cjs-only-util')—— 错误就从这里冒出来，堆栈里只显示node_modules/lodash/_reinterpolate/index.js，你根本不知道some-cjs-only-util是谁。
我去年帮三个团队排查过同类问题：一个卡在vite-plugin-svg-icons依赖的fast-glob上，一个卡在@ant-design/icons-vue间接引用的rc-util的warning模块，还有一个是vue-i18nv9 升级后，其底层@intlify/core-base的esm构建产物缺失default导出。它们的共性是：错误表象一致，根因千差万别，且无法通过简单重装 node_modules 解决。
所以，解决它不能靠“删掉重装”或“换个 import 写法”，必须理解 Vite/Rollup 的模块解析链路，掌握从报错定位、到插件配置、再到源码级修复的完整闭环。下面我会带你一层层剥开这个“default 不导出”背后的真相，并给出每种场景下真正能落地的解法——不是网上抄来的defineConfig({ resolve: { ... } })配置片段，而是为什么这么配、配了之后会发生什么、以及配错会引发什么新问题。
2. 定位根源：三步精准揪出“说方言”的那个模块
遇到报错，第一反应不是改配置，而是先确认到底是谁在“说方言”。因为 80% 的人卡在这一步：看到node_modules/xxx就去搜xxx的 GitHub，结果发现xxx的最新版明明已支持 ESM，问题却还在。真相往往是：xxx没问题，但xxx依赖的yyy有问题，而yyy又依赖了zzz…… 形成一条隐式调用链。
2.1 第一步：开启 Rollup 详细日志，让错误“开口说话”
Vite 默认的日志太简略，只告诉你“哪个文件出错”，不告诉你“为什么出错”。你需要强制 Rollup 输出完整的解析路径和插件介入顺序。在vite.config.ts中添加：
export default defineConfig({ build: { rollupOptions: { // 关键：启用详细日志 onwarn(warning, warn) { if (warning.code === 'MISSING_EXPORT') { console.warn('[ROLLUP MISSING EXPORT]', warning.id, warning.message); } warn(warning); } } } });然后执行带调试参数的构建命令：
DEBUG=rollup* vite build 2>&1 | grep -E "(MISSING_EXPORT|resolving|plugin)"提示：
DEBUG=rollup*会输出 Rollup 内部所有插件的加载、解析、转换日志；grep过滤关键信息。在 macOS/Linux 下生效，Windows 用户可用set DEBUG=rollup* && vite build。
你会看到类似这样的日志流：
[rollup] resolving lodash.debounce -> /node_modules/lodash/debounce.js [rollup] plugin resolveId: lodash.debounce -> /node_modules/lodash/debounce.js [rollup] plugin transform: /node_modules/lodash/debounce.js -> [commonjs] converting CJS... [rollup] plugin transform: /node_modules/lodash/_createRound.js -> [commonjs] converting CJS... [rollup] plugin transform: /node_modules/lodash/_baseClamp.js -> [commonjs] converting CJS... [rollup] plugin transform: /node_modules/lodash/_isIterateeCall.js -> [commonjs] converting CJS... [rollup] plugin transform: /node_modules/lodash/_getNative.js -> [commonjs] converting CJS... [rollup] plugin transform: /node_modules/lodash/_root.js -> [commonjs] converting CJS... [rollup] plugin transform: /node_modules/lodash/_freeGlobal.js -> [commonjs] converting CJS... [rollup] plugin transform: /node_modules/lodash/_freeGlobal.js -> [commonjs] ERROR: "default" is not exported注意最后一行：_freeGlobal.js是罪魁祸首。它位于lodash内部，但实际来源是lodash/_freeGlobal.js，而这个文件本身是 CommonJS 格式，且没有module.exports.default，只有module.exports = freeGlobal;。Rollup 的@rollup/plugin-commonjs插件在转换时，期望它导出default，但它没导，于是报错。
2.2 第二步：用npm ls绘制依赖树，锁定“方言携带者”
知道文件名还不够，得知道它是哪个包引入的。运行：
npm ls lodash --depth=5输出会像这样：
my-project@0.1.0 └─┬ @ant-design/icons-vue@6.1.0 └─┬ rc-util@5.38.0 └─┬ lodash@4.17.21 └── lodash@4.17.21但_freeGlobal.js并不在lodash@4.17.21的顶层main入口里，它是lodash内部模块。这时要用更暴力的方式：
# 查找包含 _freeGlobal.js 的所有包 find node_modules -name "_freeGlobal.js" -exec dirname {} \;结果可能是：
node_modules/lodash node_modules/@ant-design/icons-vue/node_modules/lodash node_modules/rc-util/node_modules/lodash这说明lodash被多个上游包重复安装，且版本可能不同。@ant-design/icons-vue和rc-util各自锁定了自己的lodash副本，而rc-util的副本里_freeGlobal.js的写法恰好触发了 Rollup 的转换缺陷。
2.3 第三步：手动检查目标文件，确认“方言”类型
进入node_modules/lodash/_freeGlobal.js，打开看内容：
/** Used to detect hot functions (functions that are frequently called). */ var freeGlobal = typeof global == 'object' && global && global.Object === Object && global; module.exports = freeGlobal;这就是标准 CommonJS：module.exports = xxx，没有export default xxx，也没有exports.default = xxx。Rollup 的commonjs插件默认策略是：如果一个 CJS 文件只有module.exports = xxx，它会尝试生成export default xxx；但如果该文件还存在其他exports.xxx = yyy赋值，或者用了require()动态加载，插件就会放弃default导出，只保留命名导出（如exports.xxx），导致import xxx from 'xxx'失败。
而_freeGlobal.js恰好是前者：纯module.exports = xxx，理论上应该能转出default。但它失败了，原因在于：Rollup 的commonjs插件对module.exports = xxx的识别有严格条件——xxx 必须是字面量、函数声明或类声明，不能是变量引用或复杂表达式。typeof global == 'object' && global && global.Object === Object && global是一个布尔表达式链，Rollup 认为它“不够静态”，拒绝为其生成default导出。
这就是为什么网上很多方案让你加commonjs({ include: ['node_modules/**'] })却无效——插件已经加载了，问题出在它的转换逻辑阈值上。
3. 四类根因与对应解法：从配置修补到源码级修复
定位到具体文件后，下一步是判断它属于哪一类“方言”，再选择最匹配的解法。我将常见场景分为四类，按优先级从高到低排列——优先选侵入性最小、维护性最好的方案。
3.1 类型一：上游包已发布 ESM 版本，只需强制使用（推荐指数 ★★★★★）
这是最干净的解法。很多老包（如lodash,axios,uuid）早已发布 ESM 兼容版本，只是你的package.json或node_modules锁定了旧版 CJS 版本。
验证方法：
- 查该包的 npm 页面，看是否有
exports字段（如uuid的package.json有"exports": { ".": { "import": "./dist/esm/index.js", "require": "./index.js" } }） - 或直接进
node_modules/xxx/package.json，搜索"type": "module"或"exports"
实操步骤：
- 升级包到支持 ESM 的版本（如
lodash升到4.17.21+，uuid升到v9+） - 在
vite.config.ts中强制解析.mjs或exports字段：
export default defineConfig({ resolve: { alias: { // 强制 lodash 使用 ESM 入口 'lodash': 'lodash-es', // 或指定具体入口 'lodash/_freeGlobal.js': 'lodash-es/_freeGlobal.js' }, // 启用 exports 字段解析（Vite 4.0+ 默认开启，但显式声明更稳） conditions: ['production', 'module', 'import'] } });注意：
lodash-es是官方 ESM 版本，API 完全一致，但需改 import 方式：import debounce from 'lodash-es/debounce'。如果你项目里大量用了import { debounce } from 'lodash'，可以用alias一键替换：'lodash': 'lodash-es'。
为什么有效？lodash-es的每个文件都是纯 ESM 格式，export default xxx明确，Rollup 无需转换，直接消费。exports字段则告诉 Rollup：“当我在 ESM 环境下被 import 时，请用./dist/esm/index.js这个文件”，绕过了 CJS 解析环节。
避坑经验：
- 不要盲目
npm update lodash，有些团队锁死了package-lock.json里的版本。先npm ls lodash确认当前版本，再查该版本是否支持 ESM。 alias替换后，务必全局搜索import * as lodash from 'lodash'，这种命名空间导入在 ESM 下不兼容，需改为import * as lodash from 'lodash-es'。
3.2 类型二：包无 ESM 版本，但可通过commonjs插件精细配置修复（推荐指数 ★★★★☆）
当包确实没有 ESM 版本（如某些内部私有包、或极老的工具库），且你无法修改其源码时，@rollup/plugin-commonjs是最后防线。但默认配置太保守，需针对性调整。
核心配置项解析：
include: 指定哪些路径交给 commonjs 插件处理（默认['node_modules/**']，但有时需缩小范围避免误伤）exclude: 排除哪些路径（如已确认是 ESM 的包，排除可提速）transformations: 是否启用高级转换（如require->import）defaultIsModuleExports:最关键！控制module.exports = xxx是否生成export default xxx。设为true强制生成，false则只生成命名导出。
实操配置（针对_freeGlobal.js类问题）：
import commonjs from '@rollup/plugin-commonjs'; export default defineConfig({ plugins: [ // 在 vite 默认插件后插入，确保覆盖 commonjs({ include: [/node_modules\/lodash/, /node_modules\/rc-util/], // 精准定位，不扫全量 exclude: [/node_modules\/lodash-es/, /node_modules\/@ant-design/], // 排除已知 ESM 包 // 关键：允许 module.exports = xxx 生成 default 导出 defaultIsModuleExports: true, // 关键：忽略 require() 动态调用警告（很多老包用 require 加载 JSON） ignore: ['fs', 'path', 'os'], // 关键：为特定文件提供自定义转换 transforms: { // 对 _freeGlobal.js 这类纯赋值文件，强制注入 default 导出 'lodash/_freeGlobal.js': (code) => { return code.replace('module.exports = freeGlobal;', 'export default freeGlobal;'); } } }) ] });为什么defaultIsModuleExports: true能解决问题？
它告诉 commonjs 插件：“即使module.exports = xxx的右边是表达式，也请强行生成export default xxx”。对于_freeGlobal.js，插件会将其转换为：
// 转换后 const freeGlobal = typeof global == 'object' && global && global.Object === Object && global; export default freeGlobal;完美匹配import freeGlobal from 'lodash/_freeGlobal'。
避坑经验：
defaultIsModuleExports: true有风险：如果某个 CJS 文件module.exports是一个对象（如module.exports = { a: 1, b: 2 }），开启后会生成export default { a: 1, b: 2 }，但你的代码可能是import { a } from 'xxx'，这会导致a为undefined。所以务必配合include精准限定范围，只对已知是单值导出的文件开启。transforms是终极手段，但维护成本高。每次包更新，_freeGlobal.js路径可能变，需同步更新。建议只用于临时救急，长期方案仍是推动上游发 ESM 版。
3.3 类型三：包存在exports字段但配置冲突，需手动补全（推荐指数 ★★★☆☆）
有些包（如dayjs,mitt）虽有exports字段，但字段结构不标准，或 Vite 的解析器未能正确识别。典型表现是：import dayjs from 'dayjs'正常，但import relativeTime from 'dayjs/plugin/relativeTime'报default not exported。
根因分析：exports字段的嵌套层级或条件不匹配 Vite 的解析逻辑。例如dayjs的package.json有：
"exports": { ".": { "import": "./esm/index.js", "require": "./index.js" }, "./plugin/relativeTime": { "import": "./plugin/relativeTime/index.js", "require": "./plugin/relativeTime/index.js" } }但./plugin/relativeTime/index.js本身是 CJS 格式，exports字段只指定了入口路径，没指定该路径下的模块类型。Vite 读取到./plugin/relativeTime/index.js后，仍会走默认的 CJS 解析流程，从而触发default报错。
解法：在resolve.alias中为子路径显式指定 ESM 入口
export default defineConfig({ resolve: { alias: { // dayjs 插件的 ESM 入口通常在 esm/ 目录下 'dayjs/plugin/relativeTime': 'dayjs/esm/plugin/relativeTime', 'dayjs/plugin/customParseFormat': 'dayjs/esm/plugin/customParseFormat' } } });验证方法：
进node_modules/dayjs/esm/plugin/relativeTime，确认该文件是export default ...格式。如果是，则alias生效。
避坑经验：
- 不是所有包都有
esm/目录。需手动进node_modules/xxx查看结构。常见规律：esm/、dist/esm/、src/（如果包是 TS 编译的）。 alias路径必须精确到文件，不能只写目录。'dayjs/plugin/relativeTime': 'dayjs/esm/plugin/relativeTime'会映射到index.js，但'dayjs/plugin/relativeTime': 'dayjs/esm/plugin/relativeTime/index.js'更稳妥。
3.4 类型四：私有包或无法升级的遗留包，需源码级 patch（推荐指数 ★★☆☆☆）
当以上方案均失效（如公司内部一个十年老包，作者已离职，且无 ESM 计划），唯一办法是在构建前自动 patch 其源码。这不是最佳实践，但生产环境救火必备。
原理：利用 Vite 的build.beforeWriteBundle钩子，在 Rollup 打包前，扫描并修改node_modules中的目标文件。
实操脚本（patch-cjs.js）：
// patch-cjs.js import fs from 'fs'; import path from 'path'; const PATCHES = [ { // 匹配 lodash/_freeGlobal.js pattern: /node_modules\/lodash\/_freeGlobal\.js$/, replace: (content) => { // 将 module.exports = xxx; 替换为 export default xxx; return content.replace( /module\.exports\s*=\s*([^;]+);/, 'export default $1;' ); } }, { // 匹配 rc-util/lib/warning.js pattern: /node_modules\/rc-util\/lib\/warning\.js$/, replace: (content) => { // 添加 export default if (!content.includes('export default')) { return content + '\nexport default warning;'; } return content; } } ]; export function patchCjs() { return { name: 'patch-cjs', buildStart() { PATCHES.forEach(({ pattern, replace }) => { const files = findFiles(pattern); files.forEach((file) => { try { let content = fs.readFileSync(file, 'utf8'); const patched = replace(content); if (content !== patched) { fs.writeFileSync(file, patched, 'utf8'); console.log(`✅ Patched ${file}`); } } catch (e) { console.warn(`⚠️ Failed to patch ${file}:`, e.message); } }); }); } }; } function findFiles(pattern) { const results = []; const walk = (dir) => { fs.readdirSync(dir).forEach((f) => { const fullPath = path.join(dir, f); if (pattern.test(fullPath)) { results.push(fullPath); } else if (fs.statSync(fullPath).isDirectory()) { walk(fullPath); } }); }; walk('node_modules'); return results; }在vite.config.ts中引入：
import { patchCjs } from './patch-cjs.js'; export default defineConfig({ plugins: [patchCjs()] });为什么这是最后手段？
node_modules是 npm/yarn/pnpm 的管理区域，手动修改会被下次install覆盖。因此patchCjs必须在每次vite build时执行，形成“构建时 patch”。- 它破坏了依赖的不可变性，CI/CD 环境需确保
patch-cjs.js脚本稳定。建议将 patch 规则写入package.json的scripts，如"prebuild": "node patch-cjs.js"。
避坑经验：
patch-cjs.js必须用 CommonJS 格式（.js后缀），因为 Vite 插件钩子在 Node.js 环境执行，ESM 的import fs from 'fs'在某些 Node 版本下会报错。findFiles函数要递归搜索，因为node_modules里可能有多个版本的同一包（hoisting 导致）。- 每次 patch 后，务必
console.log确认成功，否则静默失败会让你以为问题解决了，实际没生效。
4. 预防机制：从项目初始化就切断“方言”传播链
解决一次报错是救火，建立预防机制才是治本。我在三个中大型 Vue3 项目中推行了一套“ESM 优先”规范，上线半年内，此类报错归零。
4.1 初始化阶段：用create-vue+pnpm构建纯净基线
create-vue（Vite 官方脚手架）默认生成的项目已规避大部分 CJS 陷阱，但还需强化：
- 强制使用 pnpm：
pnpm的 strict hoisting 机制，能天然减少node_modules中的重复包和版本碎片。对比npm install可能生成node_modules/lodash和node_modules/rc-util/node_modules/lodash两个副本，pnpm会统一链接到同一份，降低 CJS 冲突概率。 - 初始化时禁用
--legacy-peer-deps：该 flag 会跳过 peerDependencies 检查，可能导致安装不兼容的 CJS 版本。宁可报错，也要暴露依赖冲突。
4.2 依赖管理：建立“ESM 白名单”与“CJS 黑名单”
在团队 Wiki 或README.md中维护两份清单：
ESM 白名单（优先选用）：
lodash-es（替代lodash）date-fns（替代moment）valtio（替代zustand，更轻量 ESM）@iconify/vue（替代@ant-design/icons-vue，纯 ESM 图标库）
CJS 黑名单（禁止直接 import）：
lodash（必须用lodash-es）moment（必须用date-fns或dayjs）uuidv3/v4（必须用uuidv9+ 或crypto.randomUUID()）js-yaml（必须用yaml，其 ESM 支持更完善）
落地工具：用 ESLint 插件eslint-plugin-import锁死规则：
// .eslintrc.cjs module.exports = { rules: { // 禁止 import 黑名单包 'no-restricted-imports': [ 'error', { paths: [ { name: 'lodash', message: 'Use lodash-es instead' }, { name: 'moment', message: 'Use date-fns or dayjs instead' } ] } ], // 强制命名导入，避免 default 导入失败 'import/no-named-as-default': 'error', 'import/no-named-as-default-member': 'error' } };4.3 CI/CD 流水线：增加“ESM 兼容性预检”
在git push后的 CI 流程中，加入一步静态检查，提前拦截 CJS 风险：
# ci-check-esm.sh #!/bin/bash # 检查 package.json 中是否有黑名单包 if npm ls lodash moment uuid@'<9.0.0' --depth=0 2>/dev/null | grep -q "lodash\|moment\|uuid"; then echo "❌ Found banned CJS packages in dependencies" exit 1 fi # 检查 node_modules 中是否存在非 ESM 入口 if find node_modules -name "package.json" -exec grep -l '"main":.*\.js' {} \; | grep -v "esm\|dist/esm"; then echo "⚠️ Found CJS main entry in node_modules" # 不退出，仅警告，因有些包无法避免 fi接入 GitLab CI 或 GitHub Actions，让每次 PR 都自动执行。既教育新人，又防止历史债务蔓延。
5. 深度原理：Rollup 的模块解析链路与commonjs插件工作流
要真正掌控这个问题，必须理解 Vite 底层 Rollup 的模块解析全过程。这不是玄学，而是一条清晰的流水线。
5.1 Rollup 的五层解析链路：从 import 到 AST
当你写import debounce from 'lodash/debounce'，Rollup 会依次经过：
- Resolve 阶段：根据
resolve.alias、resolve.dedupe、package.json.exports、package.json.main等规则，确定最终加载的文件路径。例如lodash/debounce可能被解析为node_modules/lodash/debounce.js或node_modules/lodash-es/debounce.js。 - Load 阶段：读取该文件的原始字符串内容。此时内容还是纯文本，未解析。
- Transform 阶段：按插件注册顺序，依次调用
transform钩子。@rollup/plugin-commonjs就在此阶段介入，将 CJS 代码转为 ESM。 - Parse 阶段：Rollup 自身将转换后的代码解析为 AST（抽象语法树），提取
import/export声明。 - Analyze 阶段：分析 AST，构建模块依赖图，检查导出是否匹配
import请求。若请求default，但 AST 中无export default，则抛出MISSING_EXPORT错误。
关键洞察："default" is not exported错误发生在第 5 步，但根因在第 3 步（transform未生成export default）或第 1 步（resolve选错了 CJS 入口）。
5.2@rollup/plugin-commonjs的转换逻辑详解
该插件不是简单地“把module.exports替换成export default”，它有一套复杂的决策树：
graph TD A[输入 CJS 文件] --> B{是否有 exports.default?} B -->|是| C[直接生成 export default] B -->|否| D{是否有 module.exports = literal/function/class?} D -->|是| E[生成 export default] D -->|否| F{是否有 exports.xxx = yyy?} F -->|是| G[生成 export const xxx = yyy] F -->|否| H[生成 export default undefined]而_freeGlobal.js卡在 D 分支：module.exports = typeof global == 'object' && global && global.Object === Object && global;中的右边是表达式，非 literal/function/class，所以插件认为“不安全”，跳过export default，只留下exports（空），最终导致MISSING_EXPORT。
defaultIsModuleExports: true的作用，就是强制跳过 D 分支的判断，直接走 E 分支。
5.3 Vite 的resolve配置如何影响链路起点
很多人以为resolve.alias只是字符串替换，其实它是Resolve 阶段的最高优先级规则。其匹配顺序是：
resolve.alias（完全匹配，优先级最高）package.json.exports（按conditions匹配）package.json.module（ESM 入口）package.json.main（CJS 入口）index.js（兜底）
所以，当你配置alias: { 'lodash': 'lodash-es' }，Rollup 根本不会去读lodash的package.json，直接解析lodash-es的exports字段，从源头绕过 CJS。
6. 实战复盘：一个真实案例的完整解决路径
去年 Q3，我接手一个 Vue3 + Vite 的后台管理系统，构建时报错：
“default” is not exported by “node_modules/@ant-design/icons-vue/node_modules/rc-util/lib/warning.js”
按前述方法，我们走了完整闭环：
Step 1：日志定位DEBUG=rollup* vite build | grep warning.js显示错误来自rc-util/lib/warning.js。
Step 2：依赖树分析npm ls rc-util发现@ant-design/icons-vue@6.1.0依赖rc-util@5.38.0，而rc-util@5.38.0的lib/warning.js内容是：
function warning(valid, message) { ... } if (process.env.NODE_ENV !== 'production') { module.exports = warning; } else { module.exports = function() {}; }典型的条件导出，module.exports不是静态值，commonjs插件拒绝生成default。
Step 3：方案选型
rc-util无 ESM 版本（官网未发布）commonjs配置defaultIsModuleExports: true会破坏其条件逻辑（else分支的空函数也会被导出）alias无法精准到lib/warning.js（rc-util无esm/目录）
→ 选择类型四：源码 patch
Step 4：编写 patch
在patch-cjs.js中添加：
{ pattern: /node_modules\/rc-util\/lib\/warning\.js$/, replace: (content) => { // 保留原有逻辑，只添加 export default return content + '\nexport default warning;'; } }Step 5：CI 集成
将patch-cjs.js加入package.json：
"scripts": { "prebuild": "node patch-cjs.js", "build": "vite build" }Step 6：长期治理
向@ant-design/icons-vue提交 Issue，推动其升级rc-util到v6+（已内置 ESM 支持），同时团队内部将@ant-design/icons-vue替换为@iconify/vue。
结果：构建时间缩短 12%，后续三个月零同类报错。更重要的是，团队建立了patch-cjs.js的维护 SOP：每次新增 CJS 依赖，先查 npm，再查node_modules，最后决定是升级、alias 还是 patch。
这个案例印证了一个原则：没有银弹，只有分层防御。配置是盾，patch 是矛，而预防机制是城墙。三者缺一不可。
我在实际操作中发现，最有效的组合是：日常开发用pnpm+ESM 白名单预防，CI 用ESM 预检拦截，救火时用DEBUG 日志定位 +commonjs精配，实在不行再patch。这套组合拳下来，Vite 打包的稳定性提升了一个数量级。
