在es6中，导出模块默认内容的最直接方式是使用export default。1. 它允许每个模块指定一个主要导出内容，导入时无需解构花括号，使语法更简洁；2. 可用于导出函数、类、对象、变量甚至原始值，常见于导出单一功能或组件；3. 与命名导出不同，一个模块只能有一个默认导出，强调模块的单一职责原则；4. 实际开发中提升代码组织性和可维护性，尤其适合框架如react中单文件单组件的模式；5. 使用时需注意避免匿名导出影响调试、不能直接导出变量声明、以及不可重复导出默认值等问题。
在ES6中，如果你想导出一个模块的默认内容，最直接的方式就是使用 export default 关键字。它允许每个模块指定一个“主”导出，这样在导入时就不需要使用花括号来解构，使得导入语句更加简洁直观，也更符合许多人对“一个文件一个主要功能”的直觉。
解决方案
使用 export default 来导出一个模块的默认内容非常灵活，你可以导出函数、类、对象、变量，甚至是原始值。
一个常见的场景是导出一个函数或类：
// myModule.JS export default function greet(name) { return `Hello, ${name}!`; } // 或者导出类 // export default class Greeter { // constructor(name) { // this.name = name; // } // greet() { // return `Hello, ${this.name}!`; // } // }
在另一个文件中导入时，你可以给它任意命名：
// anotherFile.js import myGreetFunction from './myModule.js'; // 这里的 myGreetFunction 就是 greet 函数 console.log(myGreetFunction('World')); // 输出: Hello, World! // 如果导出的是类 // import MyGreeter from './myModule.js'; // const greeter = new MyGreeter('Alice'); // console.log(greeter.greet()); // 输出: Hello, Alice!
你也可以直接导出一个对象字面量或者一个变量：
// config.js const appConfig = { version: '1.0.0', environment: 'development', apiBaseUrl: '/api' }; export default appConfig; // 或者直接导出匿名对象 // export default { // version: '1.0.0', // environment: 'development', // apiBaseUrl: '/api' // };
导入时：
// main.js import config from './config.js'; console.log(config.version); // 输出: 1.0.0
export default 与 export 有何不同？为何选择它？
在我看来，export default 和普通的命名导出（export）是ES6模块系统里两个互补的设计，理解它们的区别是掌握模块化的关键。简单来说，一个模块只能有一个 export default，但可以有任意多个命名导出。
export default 的核心优势在于它提供了一种“主入口”的概念。当你看到一个文件 MyComponent.js 里有 export default class MyComponent {…} 时，你几乎可以立刻知道，这个文件主要就是为了提供 MyComponent 这个类。导入时，import MyComponent from ‘./MyComponent.js’ 这种简洁的语法，也强化了这种“一对一”的对应关系。它就像是给模块贴了个最显眼的标签，告诉别人“我最主要的用途就是这个”。这种设计，我个人觉得，在很多框架，比如React中特别常见，一个文件通常就代表一个组件，用 export default 导出的就是这个组件本身，非常清晰。
而普通的命名导出（export const name = …; export function func() {…}）则更像是提供了一个工具箱。一个模块可以导出多个独立的工具或常量，导入时你需要明确指出你需要工具箱里的哪些具体工具，例如 import { name, func } from ‘./utils.js’。这种方式适合那些提供多个相关但又独立的辅助函数或常量的模块。
选择 export default 通常是因为你认为这个模块有一个明确的、主要的、唯一的职责。它鼓励模块的单一职责原则，让代码结构更易于理解和维护。如果一个模块需要提供多个并列的功能，或者是一些辅助性的常量和函数，那么命名导出可能更合适。有时候，我甚至会把一个模块的默认导出作为它的主要API，而命名导出则作为一些内部辅助但又需要暴露给其他模块使用的工具。
使用 export default 时有哪些常见的实践或需要注意的地方？
虽然 export default 用起来很方便，但也有一些值得注意的地方，避免踩到一些小坑，或者让代码更易读。
一个常见的“陷阱”是导出匿名函数或类：
// Bad practice (sometimes) export default function() { // ... } // Or // export default class { // // ... // }
这种写法在功能上没问题，但在调试时可能会遇到一点麻烦。如果你的代码报错了，堆栈信息中显示的函数名或类名可能是 anonymous，这会给定位问题带来不便。所以我个人更倾向于给默认导出的函数或类一个明确的名称，即使它只是一个内部名称：
// Good practice export default function myNamedFunction() { // ... } // Or // export default class MyNamedClass { // // ... // }
这样在堆栈跟踪中就能看到 myNamedFunction 或 MyNamedClass，大大提高了调试效率。
另一个细节是，你不能直接在 export default 后面跟着 const、let 或 var 声明一个变量：
// This will cause a syntax error! // export default const myVar = 123;
如果你想默认导出一个变量，你需要先声明它，然后再导出：
const myVar = 123; export default myVar; // 这是正确的做法
此外，一个模块只能有一个 export default。如果你尝试在同一个文件中使用多个 export default，编译器会直接报错。这再次强调了它作为模块“主入口”的定位。
最后，一个比较高级的用法是，你可以在同一个文件中同时使用 export default 和命名导出。这在一些需要提供一个主要功能，同时又有一些辅助功能或常量需要暴露的场景下非常有用。
// utils.js export const PI = 3.14159; // 命名导出 export function calculateCircumference(radius) { // 命名导出 return 2 * PI * radius; } export default function generateRandomId() { // 默认导出 return Math.random().toString(36).substring(2, 15); }
导入时：
import generateId, { PI, calculateCircumference } from './utils.js'; console.log(generateId()); console.log(PI); console.log(calculateCircumference(5));
这种混合使用的方式，在我日常开发中非常常见，它提供了一种既能突出模块核心功能，又能灵活暴露其他工具的机制。
在实际项目中，export default 如何提升代码组织和可维护性的？
在实际的大型或中型项目中，代码的组织和可维护性是至关重要的。export default 在这方面扮演了一个非常积极的角色，它不仅仅是语法上的简化，更是对模块设计理念的一种引导。
首先，它强制了模块的“单一主要职责”原则。当我打开一个名为 UserProfileCard.js 的文件时，如果我看到 export default class UserProfileCard {…}，我立刻就知道这个文件最主要的目的就是定义 UserProfileCard 这个组件。这种约定俗成的模式大大降低了理解新代码的认知负担。我不需要去猜测这个文件可能导出了什么其他东西，我直接就能找到它的核心功能。这对于团队协作来说尤其重要，大家都能快速理解文件的意图。
其次，它简化了模块间的依赖关系。当你只需要一个模块的主要功能时，import MyModule from ‘./MyModule.js’ 这种简洁的导入方式，让依赖图谱看起来更加清晰。想象一下，如果所有的导出都是命名导出，那么每个导入语句都得是 { MyModule }，虽然差别不大，但在成百上千个文件中，这种视觉上的统一性，能够让代码流看起来更顺畅。在我看来，这种“少即是多”的哲学，在大型项目中能有效减少视觉噪音。
再者，export default 有助于构建更清晰的 API 边界。一个模块的默认导出往往代表了它对外暴露的核心功能或接口。这使得模块的使用者能够更容易地理解如何与该模块交互。比如，一个工具库 mathUtils.js，如果它默认导出的是一个包含各种数学方法的对象，那么使用者就知道如何通过这个对象来调用各种工具。这就像是给你的模块提供了一个明确的“门牌号”，而不是一堆散落在地上的工具。
最后，它也为一些框架的设计提供了便利。比如在React、vue等前端框架中，组件通常就是通过 export default 导出的。这使得框架能够统一地处理组件的加载和渲染逻辑，因为它们总是知道每个文件都有一个“默认”的组件可以去加载。这种约定极大地简化了框架层面的设计和用户的开发体验。可以说，export default 不仅是语言特性，它更是一种编程范式，鼓励我们编写更具结构化、更易于理解和维护的代码。
