JavaScript中Class作为模块导出的最佳实践是什么？

推荐使用命名导出（named export）方式导出 Class，如 export class Greeter { ... }，以提升重构安全性、编辑器自动补全与重命名联动能力，并支持同一模块导出多个成员，避免默认导出带来的命名歧义与维护隐患。

推荐用命名导出（named export）方式导出 Class，避免使用默认导出（export default）。这能提升重构安全性、编辑器支持度和代码可读性。

优先使用命名导出

直接在 Class 声明前加 export 关键字：

export class Greeter {  constructor(name) {    this.name = name;  }  greet() {    return `Hello, ${this.name}!`;  }}

导入时明确指定名称，语义清晰：

import { Greeter } from './greeter.js';

• 编辑器能准确提供自动补全和重命名联动（改类名，所有 import 处同步更新）
• 支持同一模块导出多个 Class 或其他成员（如工具函数、常量），无需额外封装
• 避免因默认导出导致的命名歧义（比如 import Foo from './foo.js' 中 Foo 是谁？无法推断）

不推荐默认导出 Class

虽然语法合法，但存在明显隐患：

立即学习“Java免费学习笔记（深入）”；

export default class Greeter { /* ... */ }

• 重构困难：重命名 Class 后，所有 import X from './greeter' 中的 X 不会自动更新
• 丢失类型线索：导入时名称完全自由（import Whatever from './greeter'），破坏可读性与协作一致性
• 无法与同模块其他命名导出共存（默认导出 + 命名导出虽允许，但混合使用易混乱）

配合模块职责单一化

一个文件尽量只导出一个核心 Class，保持模块聚焦：

• 若需配套工具方法，可用具名导出并统一命名空间，例如：export function createGreeter(...)
• 避免在 Class 文件中执行副作用（如请求、解析大 JSON），这些应放在调用时或单独初始化函数中
• 私有逻辑用闭包或私有字段（#privateField）封装，不暴露 setter/getter，改用显式方法（setConfig()、getState()）

导入策略按需选择

少量使用时直接解构导入：

import { Greeter, Logger } from './utils.js';

若一个模块导出大量相关 Class（如 UI 组件库），可用命名空间导入：

import * as UI from './ui-components.js';const btn = new UI.PrimaryButton();

• 命名空间建议简短、大写、反映用途（如 UI、API、DOM）
• 避免 import * as x from '...' 后又手动解构（如 const { A } = x），失去命名空间优势