在大型 Vue 或 TypeScript 项目中，模块导出风格若不统一，极易引发一系列问题：模块引用混乱、重构困难、命名冲突频繁，甚至埋下运行时错误的隐患。问题的关键不在于“能不能用”，而在于“如何规范使用以提升项目稳定性”。一条清晰的核心原则是：让默认导出聚焦模块的主干功能，而命名导出承载可扩展、可组合的辅助能力。两者分工明确、边界清晰，项目的可维护性自然显著提升。
按模块职责决定导出类型
一个文件究竟该用 export default 还是 export，实际上取决于它对外扮演的“角色”：
- 组件主体（例如
ProductList.vue）—— 如果该文件的核心职责单一，仅需提供一个被频繁单独引入的组件，那么使用export default最为合适。 - 工具集合（例如
utils/date.ts）—— 如果文件内包含多个彼此独立的函数、常量或类型，那么全部采用命名导出是更佳选择：export const formatDate = ...、export function parseISO() {...}。 - 配置对象（例如
config/api.ts）—— 当文件只包含一个主要配置对象时，可使用默认导出。但如果同时还需要导出环境变量、校验规则等辅助项，采用默认导出与命名导出混合的方式会更清晰。
命名导出优先用于可组合能力
当模块需要支持“按需导入”或类型定义本身即是一种契约时，命名导出往往更加可靠：
- 导出类型定义（如
interface Product、type ApiError）必须使用命名导出。否则，在通过import type进行精确引用时会遇到麻烦。 - 导出Hook函数（如
useCart、useAuth）建议使用命名导出。这便于在测试文件中单独导入，也能避免默认导出可能带来的命名歧义。 - 导出多个同构组件（例如
ButtonPrimary、ButtonSecondary）应避免使用默认导出。改用命名导出并配合统一前缀，语义会更加直接明了。
混合导出要显式分层，禁用隐式默认
允许一个文件同时存在默认导出和命名导出，但结构必须清晰可辨：
- 将默认导出放在文件的最上方或最下方，且确保仅有一处。所有命名导出应集中声明，避免穿插在复杂的业务逻辑中间。
- 严格禁止在默认导出的对象内部“偷偷”挂载命名成员（例如
export default { ... , helpers: { foo() {} } }）。这种做法会导致 helper 函数无法被 tree-shaking 优化，也不利于 TypeScript 的类型推导。 - 如果需要转发其他模块的能力，应使用重新导出语法（
export { Foo } from './foo'），而不是在默认导出的对象里复制引用。
导入端保持语义化命名，不依赖默认别名惯性
即便使用了 export default，在导入时也应当赋予其有意义的变量名：
- 避免使用
import Comp from './Comp.vue'这类信息量不足的命名。更佳写法是import ProductCard from './ProductCard.vue'。 - 对于同一模块的命名导出，坚持使用原始名称，或通过
as进行显式重命名（例如import { createAPI as createProductAPI } from './api'），不要依赖记忆去猜测含义。 - 团队内部可约定：所有通过默认导出引入的组件，其导入名必须与文件名或组件的
name选项保持一致（例如Modal.vue对应import Modal from './Modal.vue'）。
