利用export default与命名导出规范大型项目组件导出风格的实用技巧

在大型 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'）。