先说个结论这个报错里真正值得你研究的不是default这个词而是by和imported by后面跟着的那两串路径。之前有朋友发来一段报错截图项目用的是 Uni-app页面白屏报错原文是default is not exported by ...他翻遍了网上答案也没头绪。其实这类报错本质非常统一某个导入语句想要拿到一个叫default的导出但目标模块压根没提供这个导出。在 Uni-app 项目里尤其从 Vue2 升级到 Vue3、或者开始使用 Vite 构建链路的项目这个报错会特别常见。这篇文章我会带你拆开报错信息、理解底层机制、给出一套能直接落地的排查和修复方案最后附上我最近一次完整的实测记录。不管你是刚把 HBuilderX 项目从 Vue2 切到 Vue3还是正在封装自用工具库这篇都很值得花五分钟读完。1. 报错原文里藏着三个关键信息别只盯着default1.1 一个典型报错长什么样先看一个我在实际项目里遇到的报错原文Error: default is not exported by node_modules/mockjs/dist/mock.js (imported by pages/index/index.vue)在 Uni-app 项目里这个报错出现在两个环节。运行到浏览器H5端时Vite 在启动阶段或热更新时就会抛出来页面直接白屏运行到小程序或 App 端时报错发生在编译构建阶段编译会直接失败小程序开发者工具里根本加载不到代码。HBuilderX 用户一般会在底部输出面板看到红色报错信息CLI 项目则是在终端里看到带时间戳和 Vite 插件前缀的报错。表现形式有差异但背后指向的是同一个问题。1.2 拆解报错信息的三个信息块这个报错可以拆成三块信息块含义本例子中的值default导入方想拿到的导出名称默认导出名 defaultis not exported by node_modules/mockjs/dist/mock.js被导入的模块文件路径mock.js 的压缩产物imported by pages/index/index.vue发起导入的调用方文件路径首页 index.vue很多人的第一反应是去搜export default然后把整个项目翻个底朝天。这是方向性错误。真正高效的流程是先把by后面那个文件路径复制出来直接在编辑里打开它确认它到底导出了啥再回头看imported by后面的调用方写了什么导入语句。1.3 两个容易混淆的报错变体同类问题还有两个常见变体我一起列出来Error: foo is not exported by src/utils/foo.js (imported by pages/index/index.vue)这不是 default 的问题而是导入方想要一个名为foo的具名导出但模块里没有。机制完全一样只是导出名不同。处理方式也类似重点看by后面那个文件。还有一个是 webpack 时代的等价报错在老版 Uni-app Vue2 项目里经常出现ERROR in ./src/utils/auth.js Module Error (from ./node_modules/...): export default (imported as auth) was not found in ./utils/auth (possible exports: loginByPhone, isLoggedIn)看到这种报错不要慌它其实把可能存在的导出都列出来了照着改成对应具名导入就好。2. Uni-app 的构建链路为什么比浏览器更早把问题抓出来2.1 默认导入到底在等什么要理解这个报错得先搞明白 ES Module 的默认导入机制。默认导入import x from ./module等价于我要./module这个文件导出的default成员。打个比方你宿舍楼里快递员送来两个包裹一个写着袜子一个写着鞋子但你非要去前台领一个写着套装的包裹。前台查了一圈说没有套装你说这能怪前台吗模块也是这样export default和export const是两种完全不同的出口没有就是没有。举个例子// exporter.js export const a 1 export const b 2// importer.js import x from ./exporter // 报错exporter 没有 default import * as m from ./exporter // 正常m 是 { a, b } import { a } from ./exporter // 正常2.2 为什么同样代码在浏览器控制台能跑进构建器就报原生 ES Module 浏览器在遇到缺 default 的情况时理论上也会在运行时抛SyntaxError: The requested module ... does not provide an export named default。但实际开发中很多人说我在浏览器里直接跑没问题这是因为在浏览器里走的是 Babel 转译后的脚本或者某些全局变量方案绕过了 ES Module 的严格检查。而 Vite 底层用 Rollup 做静态分析它在构建期扫描所有 import 和 export 语句一旦发现不匹配直接抛错根本不会放过任何可疑代码。这也是它比浏览器更严格的地方。还有一个让很多人困惑的点同样代码在 Vue2 的老项目里没事搬到 Uni-app Vue3 项目就报错。原因是老版本的 webpack 构建链路对 CommonJS 和 ES Module 互操作做了一层兼容包装_interopRequireDefault这个函数会把没有 default 导出的模块包一层让module.default可用。Vite 的互操作策略更保守如果找不到 default就直接宣告失败。所以在 Vue3 Vite 时代这类报错明显变多了。3. 定位问题模块的三板斧按顺序做真的能省半小时3.1 第一板斧反向锁定by后面的文件路径报错信息里最有价值的不是default而是is not exported by后面这个路径。拿到报错后第一步就是复制这个路径别急着全项目搜export default。根据路径前缀可以快速判断问题来源node_modules/xxx第三方 npm 包src/xxx或根目录下的xxx自己项目里的代码uni_modules/xxx通过 uni_modules 安装的插件内部模块注意vite 在输出很长的时候报错可能混在一堆日志里。HBuilderX 的输出面板搜索关键词not exported byCLI 终端可以直接 CtrlF 搜索很快就能锁定关键行。3.2 第二板斧打开目标文件确认导出清单拿到路径后在编辑器里打开这个文件直接搜索两类关键词export default有没有默认导出export const/export function有哪些具名导出如果打开的文件是压缩过的 dist 产物比如mock.js这种一整行代码密密麻麻直接看同目录下的package.json。重点看这几个字段{ main: dist/index.js, module: es/index.js, exports: { import: ./es/index.js, require: ./dist/index.js } }main指向 CommonJS 构建产物module指向 ES Module 源码exports里的import条件专门给 ES Module 环境用。Vite 会优先按module或exports.import去解析然后静态分析那个文件。这时候最稳妥的办法是直接打开module指向的文件搜索export default。如果搜不到就说明这个包确实没有默认导出。3.3 第三板斧回看导入语句对号入座明确目标模块的导出情况后回头打开imported by指向的调用方文件检查自己的 import 语句属于哪一种import x from ./module // 默认导入等号左边是 default 导出 import { x } from ./module // 具名导入需要模块里有同名 export import * as x from ./module // 命名空间导入拿整个模块对象我整理了一张对照表可以快速判断谁是罪魁祸首模块导出情况import x from ...import { x } from ...只有export default foo正常报错没有名为 x 的具名导出只有export const foo报错没有 default正常export default和export const都有都正常都正常很多人看到default报错就急着给模块补export default这个做法只在源码可控、且改动影响面可控时才成立。源码不可控node_modules 里的包时就得换方案了。4. 解决方案按场景挑别拿一把钥匙开所有锁4.1 场景一自己项目里的源码文件这个场景最轻松代码完全可控。我的建议是优先改导入语句而不是补export default。比如/utils/auth/index.js里只有export const loginByWeixin () {} export const loginByPhone () {} export const isLoggedIn () {}而页面里写的是import auth from /utils/auth/index.js改成import { loginByPhone, isLoggedIn } from /utils/auth/index.js这么做的好处是 tree-shaking 友好打包时只保留真正用到的函数语义也清晰。小项目里改导入语句成本很低但要是工具模块导出很多函数、调用点散布在十几个页面一个个改确实烦。这时可以用命名空间导入import * as auth from /utils/auth/index.js auth.loginByPhone()这样一次就能把整个模块导入进来不用逐个函数列名字。缺点是 tree-shaking 会失效模块里所有导出的函数都会被包含进构建产物。如果这个工具模块本身就很大不建议长期这么干后续有空还是应拆成按需导入。4.2 场景二第三方 npm 包第三方包分两种情况一种只有具名导出没有 default另一种是 CommonJS 导出module.exportsVite 在互操作转换后依然找不到 default。处理顺序我一般是这样先试命名空间导入import * as lib from some-lib lib.doSomething()如果调用点太多不想每个文件都改可以写一个桥接文件把命名空间对象包装成 default 导出// src/libs/bridge.js import * as lib from some-lib export default lib之后业务代码统一走桥接import lib from /libs/bridge.js lib.doSomething()这样只需要在一个文件里维护引用关系其他调用点不用动。桥接方案适合调用点多、不想大范围改代码的过渡期但要注意如果原模块本身有default比如同时存在export default和具名导出命名空间导入后拿到的对象里也会包含default属性包装时需要小心处理避免后续用lib.default.xxx造成二次混淆。还有一种更偏兜底的做法就是在vite.config.js里配置 CommonJS 转换import { defineConfig } from vite export default defineConfig({ commonjsOptions: { include: [/node_modules/, /src/] }, optimizeDeps: { include: [some-lib] } })这个配置适合第三方包是以 CommonJS 方式导出的情况。加了配置后 Vite 会尝试做预构建转换某些场景下能解决 default 缺失的问题。但我要提醒一句如果包本身生成的就是纯 ES Module 且确实没有 default 导出这个配置不会生效还是得走前面两种导入方案。HBuilderX 的 Vue3 项目识别根目录下的vite.config.jsCLI 模板项目本身就有这个文件。改完配置记得重启 dev 服务optimizeDeps的变化需要清缓存才生效。4.3 场景三uni_modules 插件的内部模块uni_modules 插件的情况比较特殊。插件里的 Vue 组件因为单文件组件机制天然带 default 导出一般不会触发这个报错。真正容易触发报错的是插件内部的辅助 JS 工具模块比如某个插件自带tools.js里面全是export const而你的业务代码手动 import 了它import tools from /uni_modules/xxx/js/tools.js这种情况我建议不要在uni_modules目录里直接改源码。插件更新后你的改动会被覆盖到时候问题悄悄复发排查起来更痛苦。稳妥做法是在业务代码里建一个桥接模块参照 4.2 的桥接方案把插件的具名导出包装成你需要的形式。如果确实需要给插件作者反馈或提 PR可以顺便看看该插件在插件市场是不是有 issue 渠道。但项目进度不等人桥接方案是先跑起来的最优解。4.4 改完之后的验证清单修复后别急着收工按这个清单过一遍重新运行到对应平台确认编译阶段不再报错在页面里实际调用一下导入的函数或组件确认功能真的可用搜索整个项目看看是否还有其他文件以同样方式导入了这个模块避免漏网之鱼如果 HBuilderX 还报错先执行一遍清除缓存并重新编译再不行删掉项目根目录的unpackage文件夹浏览器端如果开了 service worker 缓存做一次强刷避免旧资源干扰判断5. 一次完整实战复盘从报错到验证的全程记录5.1 案发现场最近做一个多端登录功能我把微信登录、手机号登录、登录状态判断抽到了/utils/auth/index.jsexport const loginByWeixin () {} export const loginByPhone () {} export const isLoggedIn () {}然后在登录页pages/login/index.vue里这样用import auth from /utils/auth/index.js if (auth.isLoggedIn()) { uni.switchTab({ url: /pages/home/index }) } else { auth.loginByPhone(phone, code) }运行到浏览器页面白屏。HBuilderX 输出面板里看到09:43:12.123 [vite]: error default is not exported by src/utils/auth/index.js (imported by pages/login/index.vue)5.2 逐步排查的实际过程我先复制了by后面的路径src/utils/auth/index.js打开文件搜索export default结果是没有全是export const。再回头打开imported by指向的pages/login/index.vue看到import auth from /utils/auth/index.js问题基本定位默认导入了没有 default 导出的模块。排查过程中我走过一次弯路。一开始怀疑是不是 vite.config.js 配置有问题还特地新建了一个测试页面只写一行import auth from /utils/auth/index.js结果照样报错。这个最小复现实验帮我排除了业务代码干扰确认问题纯粹是导入语句和模块导出清单不匹配。5.3 修复与验证修复很简单登录页改成具名导入import { loginByPhone, isLoggedIn } from /utils/auth/index.js同时我全局搜索了一遍utils/auth发现pages/profile/profile.vue里也有一处import auth from /utils/auth一并改成了具名导入。重新运行到浏览器编译通过登录页正常渲染调用loginByPhone后网络请求正常发出。这里补一个细节这个项目里src/utils/auth/index.js和src/utils/auth.js同时存在会导致模块解析歧义吗实测下来 Vite 优先解析带扩展名的精确匹配我的两个命名入口没有冲突但如果你的项目里同名目录和同名文件并存建议统一命名别给后续维护埋雷。5.4 如果这次是 node_modules 里的包我在排查过程中顺手模拟了第三方包场景把auth模块换成一个假想的 npm 包报错路径会变成node_modules/xxx/dist/index.js。此时定位思路一样先看by后面路径再查package.json的module、main字段确认包的真实导出形式。如果是压缩产物就直接搜索module.exports或export default。区别只在于修复动作。第三方包不能直接改源码我一般用命名空间导入或桥接方案。如果是 CommonJS 产物再叠加commonjsOptions配置。这类问题的修复路径非常固定摸摸规律之后处理速度会快很多。6. 经验沉淀让这类报错在项目里绝迹6.1 给团队的一条硬约定在 Uni-app Vue3 项目里我建议定一条约定业务工具模块一律具名导出、具名导入只有在需要作为单例、插件入口或全局挂载时才用 default 导出。Vue 组件文件保持默认导出是没问题的因为单文件组件的export default是组件标准写法跟这个报错无关。这条约定能让 Vite 的静态分析发挥最大作用也能显著减少这个模块到底有没有 default的来回确认成本。实际操作中我给项目加的 ESLint 规则里就有一项禁止从不含export default的模块中使用默认导入可惜 ESLint 原生规则管不了这个写个自定义规则成本又高最后还是靠 Code Review 提醒。6.2 遇到新包先看 package.json再写 import这是我想重点分享的习惯。引入一个新 npm 包之前先花两分钟做这几件事在node_modules里找到这个包打开package.json看module、main、exports三个字段确定入口文件打开入口文件搜索export default和export const根据导出形式决定用默认导入还是具名导入这个习惯能让 80% 的类似报错在写代码之前就消失。就算忘了检查真报错了再回过头来查也不晚至少知道去哪一步找答案。6.3 报错不代表框架坏了先做减法这个报错出现的时候第一反应不要是Vite 有 bug或uni-app 插件有问题。我处理过十几次类似报错全是代码层面的导入导出不匹配没有一次是构建器坏了。做减法是最快的验证方式把有问题的模块单独抽出来写个最小 demo如果还会报错那问题就在模块本身如果不报了说明问题出在调用链路上。最后再分享一个小技巧。如果你要封装一个自己的基础库给项目用建议库入口文件里同时保留默认导出和具名导出// 库入口 index.js export const isLoggedIn () {} const auth { isLoggedIn } export default auth这样既能满足import auth from xxx的调用方也能满足import { isLoggedIn } from xxx的调用方两种导入风格都不会踩这个报错。即使团队里有人习惯不同也不会成为白屏的导火索。我按这个规范做了半年这个报错在项目里几乎绝迹了。
先说个结论这个报错里真正值得你研究的不是default这个词而是by和imported by后面跟着的那两串路径。之前有朋友发来一段报错截图项目用的是 Uni-app页面白屏报错原文是default is not exported by ...他翻遍了网上答案也没头绪。其实这类报错本质非常统一某个导入语句想要拿到一个叫default的导出但目标模块压根没提供这个导出。在 Uni-app 项目里尤其从 Vue2 升级到 Vue3、或者开始使用 Vite 构建链路的项目这个报错会特别常见。这篇文章我会带你拆开报错信息、理解底层机制、给出一套能直接落地的排查和修复方案最后附上我最近一次完整的实测记录。不管你是刚把 HBuilderX 项目从 Vue2 切到 Vue3还是正在封装自用工具库这篇都很值得花五分钟读完。1. 报错原文里藏着三个关键信息别只盯着default1.1 一个典型报错长什么样先看一个我在实际项目里遇到的报错原文Error: default is not exported by node_modules/mockjs/dist/mock.js (imported by pages/index/index.vue)在 Uni-app 项目里这个报错出现在两个环节。运行到浏览器H5端时Vite 在启动阶段或热更新时就会抛出来页面直接白屏运行到小程序或 App 端时报错发生在编译构建阶段编译会直接失败小程序开发者工具里根本加载不到代码。HBuilderX 用户一般会在底部输出面板看到红色报错信息CLI 项目则是在终端里看到带时间戳和 Vite 插件前缀的报错。表现形式有差异但背后指向的是同一个问题。1.2 拆解报错信息的三个信息块这个报错可以拆成三块信息块含义本例子中的值default导入方想拿到的导出名称默认导出名 defaultis not exported by node_modules/mockjs/dist/mock.js被导入的模块文件路径mock.js 的压缩产物imported by pages/index/index.vue发起导入的调用方文件路径首页 index.vue很多人的第一反应是去搜export default然后把整个项目翻个底朝天。这是方向性错误。真正高效的流程是先把by后面那个文件路径复制出来直接在编辑里打开它确认它到底导出了啥再回头看imported by后面的调用方写了什么导入语句。1.3 两个容易混淆的报错变体同类问题还有两个常见变体我一起列出来Error: foo is not exported by src/utils/foo.js (imported by pages/index/index.vue)这不是 default 的问题而是导入方想要一个名为foo的具名导出但模块里没有。机制完全一样只是导出名不同。处理方式也类似重点看by后面那个文件。还有一个是 webpack 时代的等价报错在老版 Uni-app Vue2 项目里经常出现ERROR in ./src/utils/auth.js Module Error (from ./node_modules/...): export default (imported as auth) was not found in ./utils/auth (possible exports: loginByPhone, isLoggedIn)看到这种报错不要慌它其实把可能存在的导出都列出来了照着改成对应具名导入就好。2. Uni-app 的构建链路为什么比浏览器更早把问题抓出来2.1 默认导入到底在等什么要理解这个报错得先搞明白 ES Module 的默认导入机制。默认导入import x from ./module等价于我要./module这个文件导出的default成员。打个比方你宿舍楼里快递员送来两个包裹一个写着袜子一个写着鞋子但你非要去前台领一个写着套装的包裹。前台查了一圈说没有套装你说这能怪前台吗模块也是这样export default和export const是两种完全不同的出口没有就是没有。举个例子// exporter.js export const a 1 export const b 2// importer.js import x from ./exporter // 报错exporter 没有 default import * as m from ./exporter // 正常m 是 { a, b } import { a } from ./exporter // 正常2.2 为什么同样代码在浏览器控制台能跑进构建器就报原生 ES Module 浏览器在遇到缺 default 的情况时理论上也会在运行时抛SyntaxError: The requested module ... does not provide an export named default。但实际开发中很多人说我在浏览器里直接跑没问题这是因为在浏览器里走的是 Babel 转译后的脚本或者某些全局变量方案绕过了 ES Module 的严格检查。而 Vite 底层用 Rollup 做静态分析它在构建期扫描所有 import 和 export 语句一旦发现不匹配直接抛错根本不会放过任何可疑代码。这也是它比浏览器更严格的地方。还有一个让很多人困惑的点同样代码在 Vue2 的老项目里没事搬到 Uni-app Vue3 项目就报错。原因是老版本的 webpack 构建链路对 CommonJS 和 ES Module 互操作做了一层兼容包装_interopRequireDefault这个函数会把没有 default 导出的模块包一层让module.default可用。Vite 的互操作策略更保守如果找不到 default就直接宣告失败。所以在 Vue3 Vite 时代这类报错明显变多了。3. 定位问题模块的三板斧按顺序做真的能省半小时3.1 第一板斧反向锁定by后面的文件路径报错信息里最有价值的不是default而是is not exported by后面这个路径。拿到报错后第一步就是复制这个路径别急着全项目搜export default。根据路径前缀可以快速判断问题来源node_modules/xxx第三方 npm 包src/xxx或根目录下的xxx自己项目里的代码uni_modules/xxx通过 uni_modules 安装的插件内部模块注意vite 在输出很长的时候报错可能混在一堆日志里。HBuilderX 的输出面板搜索关键词not exported byCLI 终端可以直接 CtrlF 搜索很快就能锁定关键行。3.2 第二板斧打开目标文件确认导出清单拿到路径后在编辑器里打开这个文件直接搜索两类关键词export default有没有默认导出export const/export function有哪些具名导出如果打开的文件是压缩过的 dist 产物比如mock.js这种一整行代码密密麻麻直接看同目录下的package.json。重点看这几个字段{ main: dist/index.js, module: es/index.js, exports: { import: ./es/index.js, require: ./dist/index.js } }main指向 CommonJS 构建产物module指向 ES Module 源码exports里的import条件专门给 ES Module 环境用。Vite 会优先按module或exports.import去解析然后静态分析那个文件。这时候最稳妥的办法是直接打开module指向的文件搜索export default。如果搜不到就说明这个包确实没有默认导出。3.3 第三板斧回看导入语句对号入座明确目标模块的导出情况后回头打开imported by指向的调用方文件检查自己的 import 语句属于哪一种import x from ./module // 默认导入等号左边是 default 导出 import { x } from ./module // 具名导入需要模块里有同名 export import * as x from ./module // 命名空间导入拿整个模块对象我整理了一张对照表可以快速判断谁是罪魁祸首模块导出情况import x from ...import { x } from ...只有export default foo正常报错没有名为 x 的具名导出只有export const foo报错没有 default正常export default和export const都有都正常都正常很多人看到default报错就急着给模块补export default这个做法只在源码可控、且改动影响面可控时才成立。源码不可控node_modules 里的包时就得换方案了。4. 解决方案按场景挑别拿一把钥匙开所有锁4.1 场景一自己项目里的源码文件这个场景最轻松代码完全可控。我的建议是优先改导入语句而不是补export default。比如/utils/auth/index.js里只有export const loginByWeixin () {} export const loginByPhone () {} export const isLoggedIn () {}而页面里写的是import auth from /utils/auth/index.js改成import { loginByPhone, isLoggedIn } from /utils/auth/index.js这么做的好处是 tree-shaking 友好打包时只保留真正用到的函数语义也清晰。小项目里改导入语句成本很低但要是工具模块导出很多函数、调用点散布在十几个页面一个个改确实烦。这时可以用命名空间导入import * as auth from /utils/auth/index.js auth.loginByPhone()这样一次就能把整个模块导入进来不用逐个函数列名字。缺点是 tree-shaking 会失效模块里所有导出的函数都会被包含进构建产物。如果这个工具模块本身就很大不建议长期这么干后续有空还是应拆成按需导入。4.2 场景二第三方 npm 包第三方包分两种情况一种只有具名导出没有 default另一种是 CommonJS 导出module.exportsVite 在互操作转换后依然找不到 default。处理顺序我一般是这样先试命名空间导入import * as lib from some-lib lib.doSomething()如果调用点太多不想每个文件都改可以写一个桥接文件把命名空间对象包装成 default 导出// src/libs/bridge.js import * as lib from some-lib export default lib之后业务代码统一走桥接import lib from /libs/bridge.js lib.doSomething()这样只需要在一个文件里维护引用关系其他调用点不用动。桥接方案适合调用点多、不想大范围改代码的过渡期但要注意如果原模块本身有default比如同时存在export default和具名导出命名空间导入后拿到的对象里也会包含default属性包装时需要小心处理避免后续用lib.default.xxx造成二次混淆。还有一种更偏兜底的做法就是在vite.config.js里配置 CommonJS 转换import { defineConfig } from vite export default defineConfig({ commonjsOptions: { include: [/node_modules/, /src/] }, optimizeDeps: { include: [some-lib] } })这个配置适合第三方包是以 CommonJS 方式导出的情况。加了配置后 Vite 会尝试做预构建转换某些场景下能解决 default 缺失的问题。但我要提醒一句如果包本身生成的就是纯 ES Module 且确实没有 default 导出这个配置不会生效还是得走前面两种导入方案。HBuilderX 的 Vue3 项目识别根目录下的vite.config.jsCLI 模板项目本身就有这个文件。改完配置记得重启 dev 服务optimizeDeps的变化需要清缓存才生效。4.3 场景三uni_modules 插件的内部模块uni_modules 插件的情况比较特殊。插件里的 Vue 组件因为单文件组件机制天然带 default 导出一般不会触发这个报错。真正容易触发报错的是插件内部的辅助 JS 工具模块比如某个插件自带tools.js里面全是export const而你的业务代码手动 import 了它import tools from /uni_modules/xxx/js/tools.js这种情况我建议不要在uni_modules目录里直接改源码。插件更新后你的改动会被覆盖到时候问题悄悄复发排查起来更痛苦。稳妥做法是在业务代码里建一个桥接模块参照 4.2 的桥接方案把插件的具名导出包装成你需要的形式。如果确实需要给插件作者反馈或提 PR可以顺便看看该插件在插件市场是不是有 issue 渠道。但项目进度不等人桥接方案是先跑起来的最优解。4.4 改完之后的验证清单修复后别急着收工按这个清单过一遍重新运行到对应平台确认编译阶段不再报错在页面里实际调用一下导入的函数或组件确认功能真的可用搜索整个项目看看是否还有其他文件以同样方式导入了这个模块避免漏网之鱼如果 HBuilderX 还报错先执行一遍清除缓存并重新编译再不行删掉项目根目录的unpackage文件夹浏览器端如果开了 service worker 缓存做一次强刷避免旧资源干扰判断5. 一次完整实战复盘从报错到验证的全程记录5.1 案发现场最近做一个多端登录功能我把微信登录、手机号登录、登录状态判断抽到了/utils/auth/index.jsexport const loginByWeixin () {} export const loginByPhone () {} export const isLoggedIn () {}然后在登录页pages/login/index.vue里这样用import auth from /utils/auth/index.js if (auth.isLoggedIn()) { uni.switchTab({ url: /pages/home/index }) } else { auth.loginByPhone(phone, code) }运行到浏览器页面白屏。HBuilderX 输出面板里看到09:43:12.123 [vite]: error default is not exported by src/utils/auth/index.js (imported by pages/login/index.vue)5.2 逐步排查的实际过程我先复制了by后面的路径src/utils/auth/index.js打开文件搜索export default结果是没有全是export const。再回头打开imported by指向的pages/login/index.vue看到import auth from /utils/auth/index.js问题基本定位默认导入了没有 default 导出的模块。排查过程中我走过一次弯路。一开始怀疑是不是 vite.config.js 配置有问题还特地新建了一个测试页面只写一行import auth from /utils/auth/index.js结果照样报错。这个最小复现实验帮我排除了业务代码干扰确认问题纯粹是导入语句和模块导出清单不匹配。5.3 修复与验证修复很简单登录页改成具名导入import { loginByPhone, isLoggedIn } from /utils/auth/index.js同时我全局搜索了一遍utils/auth发现pages/profile/profile.vue里也有一处import auth from /utils/auth一并改成了具名导入。重新运行到浏览器编译通过登录页正常渲染调用loginByPhone后网络请求正常发出。这里补一个细节这个项目里src/utils/auth/index.js和src/utils/auth.js同时存在会导致模块解析歧义吗实测下来 Vite 优先解析带扩展名的精确匹配我的两个命名入口没有冲突但如果你的项目里同名目录和同名文件并存建议统一命名别给后续维护埋雷。5.4 如果这次是 node_modules 里的包我在排查过程中顺手模拟了第三方包场景把auth模块换成一个假想的 npm 包报错路径会变成node_modules/xxx/dist/index.js。此时定位思路一样先看by后面路径再查package.json的module、main字段确认包的真实导出形式。如果是压缩产物就直接搜索module.exports或export default。区别只在于修复动作。第三方包不能直接改源码我一般用命名空间导入或桥接方案。如果是 CommonJS 产物再叠加commonjsOptions配置。这类问题的修复路径非常固定摸摸规律之后处理速度会快很多。6. 经验沉淀让这类报错在项目里绝迹6.1 给团队的一条硬约定在 Uni-app Vue3 项目里我建议定一条约定业务工具模块一律具名导出、具名导入只有在需要作为单例、插件入口或全局挂载时才用 default 导出。Vue 组件文件保持默认导出是没问题的因为单文件组件的export default是组件标准写法跟这个报错无关。这条约定能让 Vite 的静态分析发挥最大作用也能显著减少这个模块到底有没有 default的来回确认成本。实际操作中我给项目加的 ESLint 规则里就有一项禁止从不含export default的模块中使用默认导入可惜 ESLint 原生规则管不了这个写个自定义规则成本又高最后还是靠 Code Review 提醒。6.2 遇到新包先看 package.json再写 import这是我想重点分享的习惯。引入一个新 npm 包之前先花两分钟做这几件事在node_modules里找到这个包打开package.json看module、main、exports三个字段确定入口文件打开入口文件搜索export default和export const根据导出形式决定用默认导入还是具名导入这个习惯能让 80% 的类似报错在写代码之前就消失。就算忘了检查真报错了再回过头来查也不晚至少知道去哪一步找答案。6.3 报错不代表框架坏了先做减法这个报错出现的时候第一反应不要是Vite 有 bug或uni-app 插件有问题。我处理过十几次类似报错全是代码层面的导入导出不匹配没有一次是构建器坏了。做减法是最快的验证方式把有问题的模块单独抽出来写个最小 demo如果还会报错那问题就在模块本身如果不报了说明问题出在调用链路上。最后再分享一个小技巧。如果你要封装一个自己的基础库给项目用建议库入口文件里同时保留默认导出和具名导出// 库入口 index.js export const isLoggedIn () {} const auth { isLoggedIn } export default auth这样既能满足import auth from xxx的调用方也能满足import { isLoggedIn } from xxx的调用方两种导入风格都不会踩这个报错。即使团队里有人习惯不同也不会成为白屏的导火索。我按这个规范做了半年这个报错在项目里几乎绝迹了。
