javascript中常用设计模式包括单例模式和工厂模式：单例确保类仅有一个实例，用于配置管理等场景；工厂封装对象创建逻辑，解决条件化实例化问题，二者可组合使用但适用场景不同。
JavaScript 中常用的设计模式包括单例模式、工厂模式、观察者模式、发布-订阅模式、代理模式、装饰器模式、策略模式、适配器模式、命令模式、状态模式等。其中，单例模式和工厂模式是入门级但高频使用的两种，它们分别解决“唯一实例管理”和“对象创建解耦”问题。
单例模式：确保一个类只有一个实例
核心思想是：第一次调用时创建实例，之后每次都返回同一个引用。常用于配置管理、全局状态、日志器、弹窗管理器等场景。
实现关键点：
- 用闭包或静态属性缓存实例
- 构造函数内部判断是否已存在实例，有则直接返回
- 避免通过 new 多次创建新对象
基础实现（ES5/ES6 兼容）：
立即学习“Java免费学习笔记（深入）”；
class Singleton {
constructor() {
if (Singleton.instance) {
return Singleton.instance;
}
this.data = Math.random();
Singleton.instance = this;
}
}
// 使用
const a = new Singleton();
const b = new Singleton();
console.log(a === b); // true
更推荐的写法（不依赖 new，更安全）：
动态WEB网站中的PHP和MySQL：直观的QuickPro指南第2版
下载
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
const Singleton = (function () {
let instance;
function createInstance() {
return { data: Math.random() };
}
return {
getInstance() {
if (!instance) {
instance = createInstance();
}
return instance;
}
};
})();
// 使用
const a = Singleton.getInstance();
const b = Singleton.getInstance();
console.log(a === b); // true
工厂模式：把对象创建逻辑集中封装
适用于需要根据条件生成不同对象类型，且创建过程较复杂的情况。它把 new 操作从调用方抽离，提升可维护性和扩展性。
常见分类：
- 简单工厂：一个函数或类，接收参数并返回具体实例（非严格设计模式，但实用）
- 工厂方法：定义创建接口，子类决定实例化哪个类（需结合继承）
- 抽象工厂：创建产品族，适合多维度变化（JS 中较少用，因无接口/抽象类原生支持）
简单工厂示例（处理不同类型的表单校验器）：
class EmailValidator {
validate(value) {
return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
}
}
class PhoneValidator {
validate(value) {
return /^1[3-9]\d{9}$/.test(value);
}
}
class ValidatorFactory {
static create(type) {
switch (type) {
case 'email': return new EmailValidator();
case 'phone': return new PhoneValidator();
default: throw new Error(`Unknown validator type: ${type}`);
}
}
}
// 使用
const emailV = ValidatorFactory.create('email');
const phoneV = ValidatorFactory.create('phone');
单例 vs 工厂：使用场景辨析
两者解决的问题不同，不互斥，甚至可以组合使用：
- 单例关注“多少个”——只允许一个；工厂关注“怎么造”——统一创建入口
- 可以写一个单例工厂：比如全局唯一的 ValidatorFactory 实例
- 避免滥用单例：过度使用会导致隐式依赖、难以测试；工厂若无实际分支逻辑，可能画蛇添足
判断是否该用单例：这个对象是否天然具有全局唯一性？是否所有模块都应共享同一份状态？
判断是否该用工厂：创建逻辑是否分散、重复？是否未来会新增多种类型？是否希望调用方不关心具体构造细节？
