大型javascript项目中class应嵌入模块化与分层架构：一个类只解决一个职责，一个文件只导出一个主类，归属明确功能域；按业务域组织目录（如domain/user/），分层定位（展现层、领域层、应用层），统一命名导出，配合typescript强化接口、可见性与构造契约。
在大型 JavaScript 项目中，Class 不应孤立存在，而要嵌入模块化与分层架构中——核心原则是：**一个类只解决一个职责，一个文件只导出一个主类，且该类必须归属明确的功能域或抽象层**。
按领域职责划分类模块
避免把所有 Class 堆在 utils/ 或 models/ 下。应以业务域为边界组织目录，每个子目录聚焦一类问题：
-
domain/user/：含User、UserValidator、UserRepository等，封装用户生命周期逻辑 -
domain/transaction/：含Transaction、TransactionBuilder、FeeCalculator，不掺杂 UI 或网络细节 -
infrastructure/：存放适配器类，如LocalStorageAdapter、ViemContractClient，隔离外部依赖
分层设计中明确类的定位
类不是“万能工具箱”，它在架构中需有清晰层归属：
-
展现层：仅含轻量状态容器类（如
FormState），不含业务规则；用class封装 React 组件内部逻辑时，优先考虑 Hook 替代 -
领域层：核心业务类必须是纯逻辑、无副作用、可单元测试，例如
LoanCalculator接收参数返回结果，不调用 API 或修改 DOM -
应用层：用
Service类协调多个领域对象，如OnboardingService调用User和Wallet类完成注册流程
导出与命名保持一致性
每个 Class 文件严格遵循单一入口原则：
- 文件名与类名完全一致（
User.js→export class User { ... }） - 禁用默认导出（
export default class User），统一使用命名导出，便于 tree-shaking 和 IDE 自动导入 - 若需工厂或静态构造方法，放在同一文件内作为类的静态成员（
User.fromJSON()），而非另建UserFactory
配合 TypeScript 强化契约
纯 JavaScript 中类易失约束，TypeScript 是大型项目必备支撑：
- 为每个类定义明确接口（
interface IUser），类实现该接口，暴露契约而非实现 - 用
private/protected严格控制属性可见性，内部状态变更通过受控方法（如updateEmail()）而非直接赋值 - 构造函数只做必要初始化，复杂组装逻辑移至静态工厂方法或独立
Builder类
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
