初学 Vue 的时候我最先看懂的语法是v-if、v-for这些模板指令但真正让我卡住的反而是每个.vue文件结尾那行export default。我记得当时自己试着把它删掉页面直接空白控制台刷了一屏报错把它改成export const又报了一堆莫名其妙的错。后来花了两周时间把 JavaScript 模块系统和 Vue 组件选项对象彻底过了一遍才算把这行代码看明白。其实export default一点都不玄乎它是 ES Module 里的默认导出语法而 Vue 单文件组件恰好用这种语法来声明“这个文件是一个组件”。这篇文章就从这行代码讲起把“为什么要这么写”“组件对象里到底能放什么”“实际工程中该怎么组织导入和导出”“遇到报错怎么排查”几块内容一次说完。适合刚接触 Vue 的前端新人也适合写了一阵子 Vue 但没抠过底层原理的同学。1. export default 到底是什么从 JavaScript 模块系统说起1.1 ES Module 的导入导出机制export default不是 Vue 自己发明的语法而是 JavaScript 原生模块系统ES Module的一部分。ES Module 的核心理念是一个 JavaScript 文件就是一个模块模块内部定义的变量、函数、类默认是私有的外部拿不到只有通过export关键字导出的内容才允许其他文件用import导入。导出分为两种命名导出和默认导出。命名导出要求导出内容有名字导入时必须用对应的名字来接并且要加大括号// utils.js export const formatTime (date) { ... }; export const formatNumber (num) { ... };// 使用时 import { formatTime, formatNumber } from ./utils.js;默认导出则不同它是整个模块的“主出口”导入时不需要写大括号名字可以任意起// utils.js export default function formatDate() { ... };// 使用时 import formatDate from ./utils.js; // 甚至可以换个名字 import dateFormatter from ./utils.js;这里要特别记住一条硬性规则一个模块只能有一个默认导出但可以同时有多个命名导出。这条规则在后面排查报错时非常有用——很多人写着写着忘了在同一个文件里写了两个export default直接报Multiple default exports。1.2 为什么 Vue 组件文件要用默认导出Vue 的单文件组件.vue文件通过构建工具处理本质上是一个需要被编译器解析的特殊模块。这个模块对外输出的核心内容是什么是组件选项对象——也就是包含data、methods、computed这些配置项的普通 JavaScript 对象。构建工具解析完.vue文件后会把里面的模板、样式、脚本片段组合起来最终变成类似下面这样的一段代码// 这是单文件组件编译后的简化版本 export default { name: MyComponent, data() { return { count: 0 }; }, methods: { increment() { this.count; } } };然后另一个组件里这样导入使用script import MyComponent from ./MyComponent.vue; export default { components: { MyComponent } }; /script看出规律了吗整个.vue文件对外只交出一件最核心的东西——组件配置对象。默认导出的语义恰好匹配这种“一个模块只干一件事”的设计。如果改成命名导出比如export const MyComponent { ... }虽然也能用但写起来别扭而且 Vue 的官方工具链、IDE 插件、路由懒加载等很多周边工具都约定“读取这个文件的默认导出”保持默认导出会让整个生态更顺滑。2. 组件选项对象的完整结构export default 导出的到底是什么2.1 组件选项对象里可以放哪些字段export default导出的对象在 Vue 里叫组件选项对象字段有固定的含义。做一个开发时经常见到的清单字段作用使用频率name给组件起名字用于递归组件、keep-alive、开发者工具显示建议写components注册本组件内部的子组件视情况props声明父组件传入的属性及其类型、默认值、校验规则常用data声明组件自身的数据状态必须是函数并返回对象必用computed定义基于响应式数据派生出来的计算属性常用methods定义组件内部的方法必用watch监听数据变化并执行异步或复杂操作视情况emits声明组件会向外派发的事件推荐写provide/inject跨层级组件传值偶尔用生命周期钩子beforeCreate、created、mounted等在特定时机执行逻辑常用每个字段分工明确props管外部输入data管内部状态computed管派生状态methods管行为。理解这个分工比死记字段名重要得多因为很多状态管理混乱的项目问题根源就是把这些字段的职责搞混了。我在实际项目中见过不少组件把本该写在computed里的逻辑直接塞进data或者把接口请求写在mounted里而忘了处理组件销毁后的状态覆盖。写组件之前先问自己一个问题这个值是我自己管理的还是由父组件传入的如果是父组件管理就应该放props如果是自己管理但不希望被外部随便改就放data如果依赖其他状态变化就应该放computed。2.2 data 为什么必须是函数而不是对象这是面试常问、写久了自然就懂的一个点。在组件选项对象里如果data写成一个普通对象export default { data: { count: 0, form: { name: , age: 18 } } };表面上没毛病但 Vue 组件是要被复用的。同一个组件被实例化两次时如果data是对象两个实例会共享同一个data对象引用改一个的count另一个也跟着变。显然组件实例之间的状态必须是相互隔离的。解决办法就是让data成为一个函数每次创建新实例时调用这个函数返回一份全新的数据副本export default { data() { return { count: 0, form: { name: , age: 18 } }; } };把这个规则理解成“每个人领一个全新的笔记本”而不是“全班共用一本教材”。这也是 Vue 在创建组件实例时主动调用data函数的原因。补充一个小细节如果你在某个文件里写的是真正的全局单例对象比如一个只读配置项用普通对象确实没关系但那不应该出现在组件选项对象里而应该作为独立的 JavaScript 模块导出。2.3 props、computed、methods、watch 各自的职责划分新手最容易纠结的是computed和methods的区别以及watch到底该什么时候用。简单记一下选择逻辑计算属性computed当一个值需要根据其他值计算得出且计算结果需要被缓存时用computed。比如购物车总价 商品单价 × 数量单价或数量变化才重新计算。直接把计算过程写成一个methods里的函数也可以但只要相关依赖没变就每次都要重新执行一遍性能上不友好。方法methods处理用户交互事件、提交表单、手动触发某段逻辑用methods。它强调的是“动作”而不是“状态”。监听器watch当某个数据变化后需要执行异步操作、或者和别的系统交互时用watch。典型场景是搜索关键词变化后做防抖请求。举个例子感受区别export default { props: { price: { type: Number, required: true } }, data() { return { count: 1, searchText: , searchResult: [] }; }, computed: { totalPrice() { return this.price * this.count; } }, methods: { addOne() { this.count; }, async fetchSearchResult() { // 模拟异步搜索 this.searchResult await new Promise(resolve { setTimeout(() resolve([this.searchText]), 500); }); } }, watch: { searchText() { this.fetchSearchResult(); } } };这里totalPrice只有在price或count变化时重算addOne是点击事件触发watch监听输入框内容变化后拉取数据各自分工清楚。3. 在工程中组织导入导出export default 和 import 的配合方式3.1 默认导入与命名导入的使用场景Vue 组件文件用默认导出但一个项目里并非所有文件都是组件。工具函数、常量配置、类型定义、mixin、组合式函数composables这些模块通常会混用命名导出和默认导出。我在工程里比较推荐的做法是纯工具库优先用命名导出因为这样在使用时能明确看到引入了哪些函数IDE 也方便做自动补全和后续的重构组件文件必须用默认导出这没什么可争的。一个文件同时存在命名导出和默认导出时导入可以这样写// 某个模块里 export const API_PREFIX /api/v1; export function request(url) { ... }; export default { /* 一些和组件强相关的配置 */ };// 导入混合写 import componentConfig, { API_PREFIX, request } from ./module.js;这里补充一个我踩过的坑命名导入的名字必须和导出时的名字一字不差否则构建时会提示export xxx (imported as xxx) was not found。而默认导入的名字是随意的你可以写import Foo from ./foo.vue或import Bar from ./foo.vue怎么执行都不报错。这既是灵活也容易让人误以为是同一套规则。搞清“命名导出的名字是约定、默认导出的名字是随便起的”这一点排错会快很多。3.2 什么时候该用命名导出我日常开发中的一个判断标准是如果一个文件只对外提供一个核心能力就用默认导出比如 Vue 组件、页面入口如果一个文件是一个能力集合比如一堆工具函数、一组枚举常量就用命名导出。原因很简单命名导出能保证使用者只加载自己需要的那部分配合构建工具的 tree-shaking 优化可以把没有被使用到的函数从最终产物中摇掉。如果你的项目里有一段业务代码希望被复用又不想新起一个 Vue 组件文件可以考虑抽成一个 composableVue 3或 mixinVue 2/3 兼容写法然后按需导出。举个例子一个处理列表分页的通用逻辑// composables/usePagination.js import { ref, computed } from vue; export function usePagination(items, pageSize) { const currentPage ref(1); const totalPages computed(() Math.max(1, Math.ceil(items.length / pageSize))); const pageItems computed(() items.slice((currentPage.value - 1) * pageSize, currentPage.value * pageSize)); function jumpToPage(page) { if (page 1 page totalPages.value) { currentPage.value page; } } return { currentPage, totalPages, pageItems, jumpToPage }; }这里没有用export default而是导出了一个命名函数。这样在业务组件里用起来非常通畅import { usePagination } from /composables/usePagination;从可维护性角度看默认导出适合“组件这种单一职责模块”命名导出适合“工具库这种多功能聚合模块”。只要全局统一这套约定项目结构就不会乱。3.3 模块导入顺序和循环依赖的坑export default和import是静态语法这一点和 CommonJS 的require很不一样。静态意味着 import 语句必须在文件的顶层不能写进条件判断里这也意味着模块之间的依赖关系在构建时就会被完整解析形成依赖图。工程中常见的坑是循环依赖。比如 A 组件导入了 B 组件的默认导出B 组件又反过来导入了 A 组件的默认导出如果处理不当执行时可能出现Cannot access A before initialization的报错。尤其是路由配置、全局状态这类模块入口文件之间很容易互相引用。我的建议是组件文件之间尽量避免循环依赖如果确实有互相引用的需求优先把共享部分抽到第三个模块里。比如 A 和 B 都要用到同一个格式化函数或同一个常量就放到utils/format.js或config/constants.js由两个组件分别导入。在实际项目里组件引用关系应该是相对清晰的树状结构而不是环形结构。每次在代码评审里看到循环依赖我都会建议先想一想模块划分是不是出了问题。4. 常见报错、配置陷阱与开发建议4.1 高频报错排查对照表整理几个我实际开发里遇到过的和export default直接相关的报错附上错误原因和解决办法报错提示常见原因解决办法Multiple default exports同一个文件里写了多个export default只保留一个默认导出其余改成命名导出Unexpected export在非模块环境没有配置typemodule或构建工具不支持下使用了 ES Module 语法检查工程配置确保文件被当作 ES Module 处理Cant resolve ./xxx.vue导入路径写错或文件不存在检查相对路径是否正确注意大小写export default (imported as Comp) was not found目标文件实际上没有默认导出或者导入时用了默认导入但导出的只有命名项查看目标文件是否写了export default没有的话改为命名导入data functions should return an objectdata函数返回了非对象类型比如返回了字符串或undefined确保data() { return { ... }; }格式正确且没有少写return[Vue warn]: Component is missing template or render function.vue文件解析失败或export default导出的对象没有模板也没有 render确认文件模板块存在组件默认导出的是正确的选项对象每次报错先看信息里提到的是哪个文件名再顺着 import 关系往回查通常比自己盲猜快得多。4.2 组件命名规范和选项对象书写建议export default对象里的name字段很多人不写但实际作用不小。它影响三类场景递归组件组件内部要调用自身时name不能缺。keep-alive的include/exclude按组件名做缓存匹配。Vue DevTools插件里能直接显示组件名称排查性能问题时少不了一眼看出是哪棵子树的渲染开销大。一个项目里组件命名最好统一风格。我常用的规范是组件文件名和name字段保持一致用大写开头的驼峰或多单词短横线都行但同一个项目里不要混着来。比如有个文件叫user-profile.vue如果方案是短横线命名name就写成UserProfile还是user-profile混用会让keep-alive匹配产生困惑。我的选择是文件名用短横线或驼峰name统一用大写驼峰全局只在components目录下注册其他地方按需导入。另外书写组件选项对象时我习惯用固定的字段顺序name→components→props→emits→data→computed→watch→methods→ 生命周期钩子。顺序不是强制性的但固定的顺序让团队 code review 时不用到处找某个字段也能避免同一类逻辑散落在对象的不同位置。4.3 Vue 3 中 export default 的变化script setup与编译器视角不少刚开始用 Vue 3 的开发者会问现在官方推荐的script setup写法里根本没有export default那这篇文章讲的还有用吗其实script setup只是一个语法糖编译后的结果仍然是导出组件选项对象。Vue 编译器会把script setup里的内容重新组织成一个包含setup()函数和__sfc__标志的组件选项对象然后再转成export default的形式。也就是说它绕开了手写选项对象但没有绕开组件原本的底层机制。看一个对照示例传统组合式 API 写法script import { ref, computed } from vue; export default { props: { title: String }, emits: [update], setup(props, { emit }) { const count ref(0); const double computed(() count.value * 2); function update() { emit(update, count.value); } return { count, double, update }; } }; /scriptscript setup写法script setup import { ref, computed } from vue; const props defineProps({ title: String }); const emit defineEmits([update]); const count ref(0); const double computed(() count.value * 2); function update() { emit(update, count.value); } /script两者最终编译结果非常接近。为什么 Vue 团队还要推script setup因为它确实更简洁省掉了setup(props)这种函数壳也避免了忘记 return 导致模板里拿不到变量的低级错误。但对理解 Vue 组件机制来说知道export default底层的逻辑依然关键——尤其是当你需要看编译产物、调试高阶用法或者去参与维护一个老项目时这些底层知识就是解决问题的底气。5. 从实际项目视角看 export default 的设计取舍5.1 为什么 Vue 不直接支持命名导出组件有些同学会问既然import Comp from ./Comp.vue也是写import { Comp } from ./Comp.vue也是写Vue 为什么非要绑定默认导出这其实和工具链生态以及编译器的约定有关。.vue文件不是一个标准 JavaScript 模块而是需要编译的“自定义模块”。编译器拿到一个.vue文件后必须确定“这个文件唯一对外提供的东西是什么”才能生成稳定的模块输出代码。如果允许一个.vue文件既有组件默认导出又有其他命名导出工具链就得处理复杂的多重导出解析潜在地引入歧义。采用“默认导出组件对象”的单一约定无论对于构建工具、IDE还是开发者都足够简单且不易出错。就像写论文时标题是唯一的摘要是唯一的正文围绕一个中心展开一个.vue文件也要求聚焦于“一个组件”。5.2 老项目迁移时最容易踩的导出坑如果你维护过 Vue 2 的项目又用 Vite 或 Webpack 迁移到 Vue 3大概率遇到过这个问题旧项目里某个 mixin 文件用了export default暴露一个混入对象组件里用mixins: [xxx]引入迁移后发现 mixin 的选项优先级变了或者data里的合并行为有差异。这类问题表面上是“导出方式不对”但根本原因是没弄懂 Vue 3 实例初始化时如何处理 mixin 合并选项。我的建议是迁移项目时不要盲目照搬原来的export default结构。先弄清每个模块的真实角色——是纯逻辑、状态还是组件配置本身。针对纯逻辑如果有条件直接用 Vue 3 的组合式函数替代 mixin针对组件配置保持默认导出的写法不变。这样迁移过程中的心智负担会小很多。5.3 团队协作中的导出约定项目越大导出口径越需要约定。我在团队里推动过一份简单的前端代码规范里面专门写了三条和模块导出相关的规则一个.vue文件原则上只导出一个组件不允许在组件的script块里导出一堆工具函数。通用逻辑统一放到utils或composables使用命名导出不使用export default。路由配置、插件安装脚本这类入口文件可以有一个默认导出但每个文件最多一个。这三条规则的目的是保持代码结构的可预测性。一个只见export default的文件读代码的人会默认它就是一个组件一个满屏export const的文件读代码的人会默认它是一组工具。如果两种风格混在一个文件里别人维护时就得先花时间搞清楚“这个文件到底是干嘛的”。6. 写在最后的个人经验export default这行代码看起来简单但它牵扯出的是 JS 模块机制、Vue 组件设计、构建工具解析、团队规范制定等一整套知识链路。我自己的体会是一开始不需要背零散的报错信息而是先在心里建立一个模型每个.vue文件是一个模块模块对外默认导出组件的选项对象别人拿到这个对象后就可以创建可复用的组件实例。这个模型一旦建立后面遇到import相关的报错、甚至遇到 Vue 3 的新语法都能迅速定位问题所在。我在实际开发里最常犯的错误反而是data里不小心返回了undefined导致组件渲染时拿不到字段或者是把工具函数写进了组件文件并顺手export了出去造成命名混淆。后来养成了习惯写组件时先看一眼export default花括号里面有哪些字段写工具模块时先确认自己是用export const还是export default。每次新建文件之前花十秒钟想清楚“这个文件的唯一出口是什么”代码的可读性和维护性都会明显上升。 
长河君 · 2026/10/14 14:46:01 · 阅读 1.2k Vue中export default的真正含义：组件导出与选项对象解析
初学 Vue 的时候我最先看懂的语法是v-if、v-for这些模板指令但真正让我卡住的反而是每个.vue文件结尾那行export default。我记得当时自己试着把它删掉页面直接空白控制台刷了一屏报错把它改成export const又报了一堆莫名其妙的错。后来花了两周时间把 JavaScript 模块系统和 Vue 组件选项对象彻底过了一遍才算把这行代码看明白。其实export default一点都不玄乎它是 ES Module 里的默认导出语法而 Vue 单文件组件恰好用这种语法来声明“这个文件是一个组件”。这篇文章就从这行代码讲起把“为什么要这么写”“组件对象里到底能放什么”“实际工程中该怎么组织导入和导出”“遇到报错怎么排查”几块内容一次说完。适合刚接触 Vue 的前端新人也适合写了一阵子 Vue 但没抠过底层原理的同学。1. export default 到底是什么从 JavaScript 模块系统说起1.1 ES Module 的导入导出机制export default不是 Vue 自己发明的语法而是 JavaScript 原生模块系统ES Module的一部分。ES Module 的核心理念是一个 JavaScript 文件就是一个模块模块内部定义的变量、函数、类默认是私有的外部拿不到只有通过export关键字导出的内容才允许其他文件用import导入。导出分为两种命名导出和默认导出。命名导出要求导出内容有名字导入时必须用对应的名字来接并且要加大括号// utils.js export const formatTime (date) { ... }; export const formatNumber (num) { ... };// 使用时 import { formatTime, formatNumber } from ./utils.js;默认导出则不同它是整个模块的“主出口”导入时不需要写大括号名字可以任意起// utils.js export default function formatDate() { ... };// 使用时 import formatDate from ./utils.js; // 甚至可以换个名字 import dateFormatter from ./utils.js;这里要特别记住一条硬性规则一个模块只能有一个默认导出但可以同时有多个命名导出。这条规则在后面排查报错时非常有用——很多人写着写着忘了在同一个文件里写了两个export default直接报Multiple default exports。1.2 为什么 Vue 组件文件要用默认导出Vue 的单文件组件.vue文件通过构建工具处理本质上是一个需要被编译器解析的特殊模块。这个模块对外输出的核心内容是什么是组件选项对象——也就是包含data、methods、computed这些配置项的普通 JavaScript 对象。构建工具解析完.vue文件后会把里面的模板、样式、脚本片段组合起来最终变成类似下面这样的一段代码// 这是单文件组件编译后的简化版本 export default { name: MyComponent, data() { return { count: 0 }; }, methods: { increment() { this.count; } } };然后另一个组件里这样导入使用script import MyComponent from ./MyComponent.vue; export default { components: { MyComponent } }; /script看出规律了吗整个.vue文件对外只交出一件最核心的东西——组件配置对象。默认导出的语义恰好匹配这种“一个模块只干一件事”的设计。如果改成命名导出比如export const MyComponent { ... }虽然也能用但写起来别扭而且 Vue 的官方工具链、IDE 插件、路由懒加载等很多周边工具都约定“读取这个文件的默认导出”保持默认导出会让整个生态更顺滑。2. 组件选项对象的完整结构export default 导出的到底是什么2.1 组件选项对象里可以放哪些字段export default导出的对象在 Vue 里叫组件选项对象字段有固定的含义。做一个开发时经常见到的清单字段作用使用频率name给组件起名字用于递归组件、keep-alive、开发者工具显示建议写components注册本组件内部的子组件视情况props声明父组件传入的属性及其类型、默认值、校验规则常用data声明组件自身的数据状态必须是函数并返回对象必用computed定义基于响应式数据派生出来的计算属性常用methods定义组件内部的方法必用watch监听数据变化并执行异步或复杂操作视情况emits声明组件会向外派发的事件推荐写provide/inject跨层级组件传值偶尔用生命周期钩子beforeCreate、created、mounted等在特定时机执行逻辑常用每个字段分工明确props管外部输入data管内部状态computed管派生状态methods管行为。理解这个分工比死记字段名重要得多因为很多状态管理混乱的项目问题根源就是把这些字段的职责搞混了。我在实际项目中见过不少组件把本该写在computed里的逻辑直接塞进data或者把接口请求写在mounted里而忘了处理组件销毁后的状态覆盖。写组件之前先问自己一个问题这个值是我自己管理的还是由父组件传入的如果是父组件管理就应该放props如果是自己管理但不希望被外部随便改就放data如果依赖其他状态变化就应该放computed。2.2 data 为什么必须是函数而不是对象这是面试常问、写久了自然就懂的一个点。在组件选项对象里如果data写成一个普通对象export default { data: { count: 0, form: { name: , age: 18 } } };表面上没毛病但 Vue 组件是要被复用的。同一个组件被实例化两次时如果data是对象两个实例会共享同一个data对象引用改一个的count另一个也跟着变。显然组件实例之间的状态必须是相互隔离的。解决办法就是让data成为一个函数每次创建新实例时调用这个函数返回一份全新的数据副本export default { data() { return { count: 0, form: { name: , age: 18 } }; } };把这个规则理解成“每个人领一个全新的笔记本”而不是“全班共用一本教材”。这也是 Vue 在创建组件实例时主动调用data函数的原因。补充一个小细节如果你在某个文件里写的是真正的全局单例对象比如一个只读配置项用普通对象确实没关系但那不应该出现在组件选项对象里而应该作为独立的 JavaScript 模块导出。2.3 props、computed、methods、watch 各自的职责划分新手最容易纠结的是computed和methods的区别以及watch到底该什么时候用。简单记一下选择逻辑计算属性computed当一个值需要根据其他值计算得出且计算结果需要被缓存时用computed。比如购物车总价 商品单价 × 数量单价或数量变化才重新计算。直接把计算过程写成一个methods里的函数也可以但只要相关依赖没变就每次都要重新执行一遍性能上不友好。方法methods处理用户交互事件、提交表单、手动触发某段逻辑用methods。它强调的是“动作”而不是“状态”。监听器watch当某个数据变化后需要执行异步操作、或者和别的系统交互时用watch。典型场景是搜索关键词变化后做防抖请求。举个例子感受区别export default { props: { price: { type: Number, required: true } }, data() { return { count: 1, searchText: , searchResult: [] }; }, computed: { totalPrice() { return this.price * this.count; } }, methods: { addOne() { this.count; }, async fetchSearchResult() { // 模拟异步搜索 this.searchResult await new Promise(resolve { setTimeout(() resolve([this.searchText]), 500); }); } }, watch: { searchText() { this.fetchSearchResult(); } } };这里totalPrice只有在price或count变化时重算addOne是点击事件触发watch监听输入框内容变化后拉取数据各自分工清楚。3. 在工程中组织导入导出export default 和 import 的配合方式3.1 默认导入与命名导入的使用场景Vue 组件文件用默认导出但一个项目里并非所有文件都是组件。工具函数、常量配置、类型定义、mixin、组合式函数composables这些模块通常会混用命名导出和默认导出。我在工程里比较推荐的做法是纯工具库优先用命名导出因为这样在使用时能明确看到引入了哪些函数IDE 也方便做自动补全和后续的重构组件文件必须用默认导出这没什么可争的。一个文件同时存在命名导出和默认导出时导入可以这样写// 某个模块里 export const API_PREFIX /api/v1; export function request(url) { ... }; export default { /* 一些和组件强相关的配置 */ };// 导入混合写 import componentConfig, { API_PREFIX, request } from ./module.js;这里补充一个我踩过的坑命名导入的名字必须和导出时的名字一字不差否则构建时会提示export xxx (imported as xxx) was not found。而默认导入的名字是随意的你可以写import Foo from ./foo.vue或import Bar from ./foo.vue怎么执行都不报错。这既是灵活也容易让人误以为是同一套规则。搞清“命名导出的名字是约定、默认导出的名字是随便起的”这一点排错会快很多。3.2 什么时候该用命名导出我日常开发中的一个判断标准是如果一个文件只对外提供一个核心能力就用默认导出比如 Vue 组件、页面入口如果一个文件是一个能力集合比如一堆工具函数、一组枚举常量就用命名导出。原因很简单命名导出能保证使用者只加载自己需要的那部分配合构建工具的 tree-shaking 优化可以把没有被使用到的函数从最终产物中摇掉。如果你的项目里有一段业务代码希望被复用又不想新起一个 Vue 组件文件可以考虑抽成一个 composableVue 3或 mixinVue 2/3 兼容写法然后按需导出。举个例子一个处理列表分页的通用逻辑// composables/usePagination.js import { ref, computed } from vue; export function usePagination(items, pageSize) { const currentPage ref(1); const totalPages computed(() Math.max(1, Math.ceil(items.length / pageSize))); const pageItems computed(() items.slice((currentPage.value - 1) * pageSize, currentPage.value * pageSize)); function jumpToPage(page) { if (page 1 page totalPages.value) { currentPage.value page; } } return { currentPage, totalPages, pageItems, jumpToPage }; }这里没有用export default而是导出了一个命名函数。这样在业务组件里用起来非常通畅import { usePagination } from /composables/usePagination;从可维护性角度看默认导出适合“组件这种单一职责模块”命名导出适合“工具库这种多功能聚合模块”。只要全局统一这套约定项目结构就不会乱。3.3 模块导入顺序和循环依赖的坑export default和import是静态语法这一点和 CommonJS 的require很不一样。静态意味着 import 语句必须在文件的顶层不能写进条件判断里这也意味着模块之间的依赖关系在构建时就会被完整解析形成依赖图。工程中常见的坑是循环依赖。比如 A 组件导入了 B 组件的默认导出B 组件又反过来导入了 A 组件的默认导出如果处理不当执行时可能出现Cannot access A before initialization的报错。尤其是路由配置、全局状态这类模块入口文件之间很容易互相引用。我的建议是组件文件之间尽量避免循环依赖如果确实有互相引用的需求优先把共享部分抽到第三个模块里。比如 A 和 B 都要用到同一个格式化函数或同一个常量就放到utils/format.js或config/constants.js由两个组件分别导入。在实际项目里组件引用关系应该是相对清晰的树状结构而不是环形结构。每次在代码评审里看到循环依赖我都会建议先想一想模块划分是不是出了问题。4. 常见报错、配置陷阱与开发建议4.1 高频报错排查对照表整理几个我实际开发里遇到过的和export default直接相关的报错附上错误原因和解决办法报错提示常见原因解决办法Multiple default exports同一个文件里写了多个export default只保留一个默认导出其余改成命名导出Unexpected export在非模块环境没有配置typemodule或构建工具不支持下使用了 ES Module 语法检查工程配置确保文件被当作 ES Module 处理Cant resolve ./xxx.vue导入路径写错或文件不存在检查相对路径是否正确注意大小写export default (imported as Comp) was not found目标文件实际上没有默认导出或者导入时用了默认导入但导出的只有命名项查看目标文件是否写了export default没有的话改为命名导入data functions should return an objectdata函数返回了非对象类型比如返回了字符串或undefined确保data() { return { ... }; }格式正确且没有少写return[Vue warn]: Component is missing template or render function.vue文件解析失败或export default导出的对象没有模板也没有 render确认文件模板块存在组件默认导出的是正确的选项对象每次报错先看信息里提到的是哪个文件名再顺着 import 关系往回查通常比自己盲猜快得多。4.2 组件命名规范和选项对象书写建议export default对象里的name字段很多人不写但实际作用不小。它影响三类场景递归组件组件内部要调用自身时name不能缺。keep-alive的include/exclude按组件名做缓存匹配。Vue DevTools插件里能直接显示组件名称排查性能问题时少不了一眼看出是哪棵子树的渲染开销大。一个项目里组件命名最好统一风格。我常用的规范是组件文件名和name字段保持一致用大写开头的驼峰或多单词短横线都行但同一个项目里不要混着来。比如有个文件叫user-profile.vue如果方案是短横线命名name就写成UserProfile还是user-profile混用会让keep-alive匹配产生困惑。我的选择是文件名用短横线或驼峰name统一用大写驼峰全局只在components目录下注册其他地方按需导入。另外书写组件选项对象时我习惯用固定的字段顺序name→components→props→emits→data→computed→watch→methods→ 生命周期钩子。顺序不是强制性的但固定的顺序让团队 code review 时不用到处找某个字段也能避免同一类逻辑散落在对象的不同位置。4.3 Vue 3 中 export default 的变化script setup与编译器视角不少刚开始用 Vue 3 的开发者会问现在官方推荐的script setup写法里根本没有export default那这篇文章讲的还有用吗其实script setup只是一个语法糖编译后的结果仍然是导出组件选项对象。Vue 编译器会把script setup里的内容重新组织成一个包含setup()函数和__sfc__标志的组件选项对象然后再转成export default的形式。也就是说它绕开了手写选项对象但没有绕开组件原本的底层机制。看一个对照示例传统组合式 API 写法script import { ref, computed } from vue; export default { props: { title: String }, emits: [update], setup(props, { emit }) { const count ref(0); const double computed(() count.value * 2); function update() { emit(update, count.value); } return { count, double, update }; } }; /scriptscript setup写法script setup import { ref, computed } from vue; const props defineProps({ title: String }); const emit defineEmits([update]); const count ref(0); const double computed(() count.value * 2); function update() { emit(update, count.value); } /script两者最终编译结果非常接近。为什么 Vue 团队还要推script setup因为它确实更简洁省掉了setup(props)这种函数壳也避免了忘记 return 导致模板里拿不到变量的低级错误。但对理解 Vue 组件机制来说知道export default底层的逻辑依然关键——尤其是当你需要看编译产物、调试高阶用法或者去参与维护一个老项目时这些底层知识就是解决问题的底气。5. 从实际项目视角看 export default 的设计取舍5.1 为什么 Vue 不直接支持命名导出组件有些同学会问既然import Comp from ./Comp.vue也是写import { Comp } from ./Comp.vue也是写Vue 为什么非要绑定默认导出这其实和工具链生态以及编译器的约定有关。.vue文件不是一个标准 JavaScript 模块而是需要编译的“自定义模块”。编译器拿到一个.vue文件后必须确定“这个文件唯一对外提供的东西是什么”才能生成稳定的模块输出代码。如果允许一个.vue文件既有组件默认导出又有其他命名导出工具链就得处理复杂的多重导出解析潜在地引入歧义。采用“默认导出组件对象”的单一约定无论对于构建工具、IDE还是开发者都足够简单且不易出错。就像写论文时标题是唯一的摘要是唯一的正文围绕一个中心展开一个.vue文件也要求聚焦于“一个组件”。5.2 老项目迁移时最容易踩的导出坑如果你维护过 Vue 2 的项目又用 Vite 或 Webpack 迁移到 Vue 3大概率遇到过这个问题旧项目里某个 mixin 文件用了export default暴露一个混入对象组件里用mixins: [xxx]引入迁移后发现 mixin 的选项优先级变了或者data里的合并行为有差异。这类问题表面上是“导出方式不对”但根本原因是没弄懂 Vue 3 实例初始化时如何处理 mixin 合并选项。我的建议是迁移项目时不要盲目照搬原来的export default结构。先弄清每个模块的真实角色——是纯逻辑、状态还是组件配置本身。针对纯逻辑如果有条件直接用 Vue 3 的组合式函数替代 mixin针对组件配置保持默认导出的写法不变。这样迁移过程中的心智负担会小很多。5.3 团队协作中的导出约定项目越大导出口径越需要约定。我在团队里推动过一份简单的前端代码规范里面专门写了三条和模块导出相关的规则一个.vue文件原则上只导出一个组件不允许在组件的script块里导出一堆工具函数。通用逻辑统一放到utils或composables使用命名导出不使用export default。路由配置、插件安装脚本这类入口文件可以有一个默认导出但每个文件最多一个。这三条规则的目的是保持代码结构的可预测性。一个只见export default的文件读代码的人会默认它就是一个组件一个满屏export const的文件读代码的人会默认它是一组工具。如果两种风格混在一个文件里别人维护时就得先花时间搞清楚“这个文件到底是干嘛的”。6. 写在最后的个人经验export default这行代码看起来简单但它牵扯出的是 JS 模块机制、Vue 组件设计、构建工具解析、团队规范制定等一整套知识链路。我自己的体会是一开始不需要背零散的报错信息而是先在心里建立一个模型每个.vue文件是一个模块模块对外默认导出组件的选项对象别人拿到这个对象后就可以创建可复用的组件实例。这个模型一旦建立后面遇到import相关的报错、甚至遇到 Vue 3 的新语法都能迅速定位问题所在。我在实际开发里最常犯的错误反而是data里不小心返回了undefined导致组件渲染时拿不到字段或者是把工具函数写进了组件文件并顺手export了出去造成命名混淆。后来养成了习惯写组件时先看一眼export default花括号里面有哪些字段写工具模块时先确认自己是用export const还是export default。每次新建文件之前花十秒钟想清楚“这个文件的唯一出口是什么”代码的可读性和维护性都会明显上升。