在 JavaScript 的 ES 模塊系統中，export default 曾被許多開發者視為一種優雅的語法，它允許一個模塊導出一個“默認”的主要功能或值。我們都寫過這樣的代碼：

// MyComponent.js
export default function MyComponent() {
  // ...
}

// App.js
import MyAwesomeComponent from './MyComponent.js'; // 導入時可以任意命名

這種寫法看起來簡潔直觀。然而，隨著前端工程化的演進和項目規模的急劇擴張，越來越多的頂級前端團隊和開源項目（如 Google、Airbnb、Vant 等）開始在其代碼規范中明確禁止或不鼓勵使用 export default。

這并非無病呻吟的語法之爭，而是基于長期項目維護、團隊協作和工程效率的深思熟慮。

命名一致性：混亂的根源

export default 的最大問題在于它允許導入時隨意命名。

在一個大型項目中，同一個組件或函數在不同文件里有了五花八門的名字。

相比之下，具名導出從根本上解決了這個問題。

import { MyComponent } from './MyComponent.js'; // 名字是固定的
import { MyComponent as MyAwesomeComponent } from './MyComponent.js'; // 可以重命名，但是是有意為之，而非無意之舉

使用具名導出時，導入的名稱必須與導出的名稱完全匹配，這確保了在整個代碼庫中，MyComponent 始終是 MyComponent。這種強制的一致性對于團隊協作至關重要。

更好的 Tree-shaking 支持

Tree-shaking是現代前端打包工具用來移除未被使用代碼以減小打包體積的關鍵技術。

雖然現代打包工具對 export default 的 Tree-shaking 處理已經相當智能，但具名導出在靜態分析上具有天然優勢。因為具名導出的依賴關系更加明確和靜態，工具能更容易地分析出哪些代碼是 dead code，從而進行更可靠的優化。

簡化模塊的再導出

在構建組件庫或工具庫時，我們經常使用一個 index.js 文件來統一導出所有子模塊，這被稱為“Barrel File”模式。

使用具名導出，這項工作非常簡單：

export * from './Button';
export * from './Card';

但如果 Button, Card 等模塊使用的是 export default，事情就變得非常麻煩：

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

這種寫法既冗長又笨拙，完全失去了簡潔性。

如果一個文件真的、真的只有一個導出，并且其功能就是這個文件的全部意義所在（例如，一個配置文件），使用 export default 也是可以接受的。

技術選擇本質上是一種權衡。export default 提供了表面的便利，但在大型、長期的項目中，這種便利性被其帶來的命名不一致、重構困難、API 不清晰等問題所抵消。

擁抱具名導出，構建出一個更健壯、更清晰、對開發者和工具都更友好的代碼生態系統。