话说回来，

在上篇内容中，我们介绍了单例、工厂、观察者三种常用JS设计模式。聚焦于“对象创建”和“对象间通信”的主要场景。本篇将继续讲解对了三种高频设计模式——策略模式、装饰器模式、代理模式，它们分别解决“算法灵活切换”“功能动态 ”“对象访问控制”的问题。是JS开发中提高代码可维护性、可 性的关键技巧，尤其适配前端组件开发、业务逻辑封装等实际场景。

一、策略模式

使用者痛点：在业务需求频繁变更时往往会出现很多 if/else 或 switch 代码块，导致函数臃肿、可读性差且难以维护；新增或修改算法时必须改动调用方，违背了开闭原则。

. 主要思想

定义一系列算法。将每个算法封装成独立的对象，使它们可以相互替换，且算法的变化不会影响使用算法的客户端。主要是“分离算法的定义与使用”。避免大量 if‑else/switch‑case 判断，让代码更具灵活性和可维护性。

简单理解这方面，就像去餐厅吃饭，“支付”是一个主要行为。而“微信支付”“支付宝支付”“现金支付”就是不同的策略，可以根据需求切换支付策略，无需修改“支付”的主要原因。

. JS 实现

表单验证是前端高频场景。不同字段的验证规则不同，若用 if/else 判断会导致代码臃肿，用策略模式可解决问题。

// 定义策略对象
const validateStrategies = {
// 非空验证
required: => {
if ) return msg;},// 手机号验证
phone这方面。=> {
const reg = /^\d{11}$/;if ) return msg;},// 邮箱验证
email的观点是。=> {
const reg = /^+@+\.{2,}$/;if ) return msg;},// 密码长度验证
minLength: => {
if return msg;}
}，// 定义上下文
class Validator {
constructor {
this.strategies =;// 存储当前需要执行的策略
}
// 添加验证规则
add {
this.strategies.push => {
return validateStrategies;})，}
// 执行所有验证策略，返回第一个错误信息
validate {
for {
const err = fn;按理说，if return err;}
return null;}
}
// 实战使用
const validator = new Validator;// 给手机号添加验证规则
validator.add;validator.add;// 给密码添加验证规则
validator.add;老实说，validator.add;// 执行验证
const error = validator.validate;console.log，// 输出：手机号格式错误

. 使用场景

• 表单验证；
• 排序算法切换；
• 支付方式、登录方式切换；
• 前端主题切换。

. 优缺点

优点：算法可独立封装、灵活切换，避免冗余判断；代码 性强，新增策略无需修改原有逻辑；策略可复用，

缺点：策略数量过多时会增加维护成本；话说回来，客户端需要了解所有可用策略才能做出选择。

二、装饰器模式

使用者痛点：业务功能经常需要在已有模块上叠加新特性，如日志、权限校验或 UI 状态。怎么说呢，直接在原函数内部硬编码会导致代码耦合度升高。后期维护和测试困难，如果多处都需要相同功能，会出现代码复制粘贴的问题。

动态地给一个对象添加额外的职责，而不改变其原有结构和主要原因。装饰器是一种“包装器”，它包裹着原对象，在不破坏原对象的前提下 其功能。

再看简单理解。就像给手机贴钢化膜、戴手机壳——手机的主要功能不变，但新增了“防刮”“防摔”的额外功能；装饰器就是“手机壳”，

再看注意，JS 中的装饰器与传统装饰器模式原理一致。但语法更简洁，目前需通过 Babel 转译才能兼容低版本浏览器。

. 方法1：传统方式

// 原对象
class Coffee {
make {
console.log;return '纯咖啡';}
}
// 装饰器1：加牛奶
function addMilk {
const originalMake = coffee.make;怎么说呢，coffee.make = function {
const result = originalMake.call;不过，console.log;return `${result} + 牛奶`;}，说起来，return coffee;}
// 装饰器2：加糖浆
function addSyrup {
const originalMake = coffee.make;coffee.make = function {
const result = originalMake.call;console.log，return `${result} + 糖浆`;}，return coffee;
}
// 使用装饰器
let myCoffee = new Coffee;myCoffee = addMilk;myCoffee = addSyrup;myCoffee.make;// 输出：
// 制作一杯纯咖啡
// 添加牛奶
// 添加糖浆

. 方法2：ES7 装饰器

// 类装饰器 - 加牛奶
function addMilk {
const orig = target.prototype.make;target.prototype.make = function {
const res = orig.call;console.log，return `${res} + 牛奶`;}，}
// 带参装饰器 - 加糖浆
function addSyrup {
return function {
const orig = target.prototype.make;target.prototype.make = function {
const res = orig.call;console.log，return `${res} + ${type}糖浆`;}，};}
@addMilk // 无参装饰器先执行
@addSyrup // 有参装饰器
class Coffee {
make {
console.log;话说回来，return '纯咖啡';}
}
const myCoffee = new Coffee;myCoffee.make;// 输出：
// 制作一杯纯咖啡
// 添加草莓糖浆
// 添加牛奶

• 前端组件功能
• 日志打印、性能监控；
• 权限控制；
• React/Vue 中的高阶组件，本质即装饰器模式。

优点：不破坏原对象主要原因，动态 功能；装饰器可叠加使用，灵活性高；代码复用性强，

缺点：过多装饰器会增加代码复杂度，难以调试；按理说，ES7 装饰器仍需转译，存在兼容性问题。

三、代理模式

使用者痛点：#1 在大型项目里经常需要统一对接口进行缓存、防抖或权限校验，这些横切关注点如果散落在业务代码里会导致重复实现且难以统一管理。#2 对象直接暴露后一旦出现安全或性能问题，需要改动大量调用方。

Proxy 对象。它原生支持拦截，无需手动封装。

. 场景1：数据拦截

// 原对象
const user = { name: '张三',age: 20 };// 创建代理对象
const userProxy = new Proxy(user,{
get { // 拦截读取操作
console.log;话说回来，return target?，'默认值';},set { // 拦截写入操作
console.log;if {
console.error;return false;// 阻止非法写入
}
target = value;return true，// 表示写入成功
}
});话说回来，// 使用代理访问属性
console.log;// →读取日志 + 张三
userProxy.age = 25;// →修改日志
userProxy.age = '二十五';其实，// →错误提示并阻止修改

. 场景2：缓存代理

// 原函数 – 假设耗时计算
function calculate {
console.log;按理说，return num * num;// 简化示例
}
// 创建缓存代理
const calculateProxy = new Proxy(calculate。{
cache这方面，{},// 缓存容器
apply { // 拦截函数调用
const key = args.join;if { // 命中缓存
console.log;return this.cache;}
const result = Reflect.apply;老实说，this.cache = result;// 写入缓存
return result;}
})，// 调用演示
calculateProxy;// 执行耗时计算 → 返回25
calculateProxy;// 从缓存获取结果 → 返回25
calculateProxy;// 执行耗时计算 → 返回49
calculateProxy;// 从缓存获取结果 → 返回49

• 数据监听；
• 缓存代理；
• 权限控制；
• 远程代理；按理说，
• 防抖/节流代理。

优点：保护原对象，实现访问控制；可在不改动原对象前提下加入额外行为，如缓存或日志；解耦客户端与底层实现，提高可维护性。

缺点：C层增加了一层转发开销，在极端性能敏感场景需评估影响；复杂的拦截逻辑会增加调试难度。老实说，

四、三种模式对比与