构造函数应仅负责必要状态初始化，明确必填字段并校验，重逻辑抽离至独立方法或工厂函数，共享行为挂载原型以避免内存浪费。
用构造函数初始化复杂业务对象，关键不是堆逻辑，而是把“谁该负责什么”理清楚。构造函数只管创建时的必要状态，其余交给协作机制。
明确必填字段，拒绝半成品对象
业务对象常依赖核心参数才能成立。比如订单必须有用户ID和商品列表，缺一不可：
- 在构造函数开头做参数校验，不合法直接抛错或返回错误（尤其配合工厂函数时）
- 避免设默认值掩盖问题，如
this.status = "draft"可能掩盖流程漏洞；更稳妥的是if (!options.status) throw new Error("status required") - 对数组、对象类参数做浅校验，例如
Array.isArray(options.items) && options.items.length > 0
把重逻辑抽出去，构造函数只做“连线”
初始化中涉及 API 调用、格式转换、权限检查等，都不该出现在构造函数体里：
- 定义
init()、loadDependencies()等方法，由调用方显式触发，控制执行时机 - 构造函数内只做属性赋值和简单计算，例如
this.createdAt = new Date()或this.id = generateId() - 若必须异步加载（如拉取用户配置），构造函数返回一个未就绪实例，配套提供
.ready()方法返回 Promise
用工厂函数封装复杂创建路径
当初始化分支多（如根据 type 字段走不同流程）、或需复用校验/转换逻辑时，构造函数本身不宜膨胀：
立即学习“Java免费学习笔记（深入）”；
- 写一个
createOrder(options)工厂函数，内部统一处理参数归一化、类型映射、错误分类 - 工厂里再调用
new Order(cleanedOptions)，保持构造函数轻量且可单独测试 - 支持从 JSON、表单数据、URL 参数等多种来源创建，都收敛到工厂入口
原型上放共享行为，别在实例里重复造轮子
每个实例都带一份方法会浪费内存，也违背单一职责：
- 验证逻辑、格式化方法、事件触发器等，统一挂到
Order.prototype上 - 构造函数里只存数据：ID、items、customer、timestamps 等纯状态字段
- 需要访问外部服务的方法（如
submitToPayment()），确保它不隐式修改 this，也不产生副作用
