大型项目组件导出规范：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'）。