在 JavaScript 的 ES6 模块系统中，export default 提供了一种快速导出一个模块“主要”功能的方式。很多开发者一开始会觉得它很方便。比如我们可能都写过这样的代码：

// MyComponent.js
export default function MyComponent() {
  // 组件内容
}

// App.js
import MyAwesomeComponent from './MyComponent.js';

这种方式看起来简单，导入时还可以随意起名字。但随着项目越来越大，协作的人越来越多，很多成熟的前端团队（比如 Google、Airbnb 和一些大型开源项目）开始明确不建议甚至禁止使用 export default。

这不是对语法的斤斤计较，而是从实际项目维护和团队协作中得出的经验。

保持命名一致，减少混乱

使用 export default 最大的问题是，它在导入时允许任意命名。在一个大型项目中，你可能在不同文件中看到同一个组件被命名为五花八门的名字：比如 MyComponent、MainComponent、Component 等等。这给阅读和重构代码带来了不必要的麻烦。

而使用具名导出（Named Exports）就可以避免这个问题：

// 导入时名字必须一致
import { MyComponent } from './MyComponent.js';

// 如果真的需要重命名，也是有意识的
import { MyComponent as MainUI } from './MyComponent.js';

这样做的好处是，在整个代码库中，同一个组件始终使用同一个名字。无论是新成员阅读代码，还是将来做全局重构，都会轻松很多。

更有利于 Tree-shaking 优化

Tree-shaking 指的是打包工具移除那些没有被实际使用的代码，以减小最终打包体积。虽然现在像 webpack 和 Rollup 这类工具已经能够处理 export default，但具名导出仍然更具优势。

因为具名导出在语法上是显式的、静态的，工具更容易准确分析出哪些导出被使用、哪些没有被使用。尤其是在跨模块重构和代码梳理时，具名导出的依赖关系更加清晰可靠。

简化代码的批量再导出

在编写组件库或工具库时，我们经常会用一个入口文件（比如 index.js）集中导出所有模块。这种做法也称为 “Barrel Export”。

如果使用具名导出，批量再导出非常简洁：

// index.js
export * from './Button';
export * from './Card';
export * from './Header';

但如果这些模块用的是 export default，写法就会变得冗余：

// index.js
export { default as Button } from './Button';
export { default as Card } from './Card';
export { default as Header } from './Header';

不仅写起来麻烦，看起来也重复累赘。

什么时候仍可以考虑用 default export？

并不是所有情况都一定要禁止默认导出。如果一个模块确实只提供一个主要功能，并且基本不会被改名导入——比如项目的配置模块、一个单一的工具函数，那么使用 export default 也无可厚非。

关键在于：你要清楚这样做的利弊。在需要长期维护、多人参与的项目中，保持一致性往往比个人习惯更重要。

总结

export default 在语法上并没有错，但它可能带来维护上的隐患，尤其不利于命名一致性、代码重构和依赖优化。相反，具名导出强制了一种更加规范的结构，让代码更容易被开发者和构建工具理解。

如果你正在一个逐渐扩张的项目中工作，不妨尝试统一使用具名导出。这可能会在日后为你和团队省去不少麻烦。

本文内容仅供个人学习/研究/参考使用，不构成任何决策建议或专业指导。分享/转载时请标明原文来源，同时请勿将内容用于商业售卖、虚假宣传等非学习用途哦～感谢您的理解与支持！

链接: https://fly63.com/article/detial/12900