javascript闭包怎样实现代理模式

闭包实现代理模式的核心是通过工厂函数创建代理对象，该代理利用闭包捕获并持有对真实对象及私有状态（如缓存）的引用，从而在不修改原对象的前提下，对其方法调用进行拦截和增强。1. 工厂函数接收真实对象作为参数；2. 内部定义私有状态（如cache）和代理方法；3. 返回的新对象方法通过闭包访问真实对象和私有状态，在调用前后添加额外逻辑（如缓存、日志、权限校验等）；4. 每个代理实例拥有独立且持久的状态，互不干扰；5. 实现方式轻量、直观，适用于方法级别的增强，如缓存、日志、参数校验、权限控制、懒加载和重试机制；6. 与es6 proxy相比，闭包代理为方法级拦截，无法代理所有对象操作，但更简单直接，适合特定方法的非侵入式增强。因此，闭包代理模式是一种基于函数作用域和闭包机制的轻量级代理实现方案，广泛应用于性能优化和行为扩展场景。

JavaScript中，利用闭包实现代理模式，核心在于创建一个函数，这个函数返回一个新的对象（代理），而这个新对象的方法能够访问并操作原始对象（被代理对象），同时在访问前后加入额外的逻辑。简单来说，闭包在这里提供了一个私有作用域，让代理能够“记住”它所代理的真实对象，并对其行为进行拦截或增强。

解决方案

要用闭包实现代理模式，我们通常会创建一个工厂函数。这个函数接收一个“真实”的服务或对象实例作为参数，然后返回一个“代理”对象。代理对象内部的方法，通过闭包捕获了对真实实例的引用，因此可以在调用真实实例的方法之前或之后，执行额外的操作。

举个例子，假设我们有一个处理用户数据的服务

UserService

UserService

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

// 真实的 UserService，它可能很“重”或者涉及到网络请求
class UserService {
    constructor() {
        console.log("UserService: 实例被创建了。");
    }

    getUserInfo(userId) {
        console.log(`UserService: 正在从数据库获取用户 ${userId} 的信息...`);
        // 模拟异步操作，比如数据库查询
        return new Promise(resolve => {
            setTimeout(() => {
                resolve({ id: userId, name: `用户-${userId}`, email: `user${userId}@example.com` });
            }, 500);
        });
    }

    updateUserInfo(userId, data) {
        console.log(`UserService: 正在更新用户 ${userId} 的信息:`, data);
        // 模拟异步操作
        return new Promise(resolve => {
            setTimeout(() => {
                console.log(`UserService: 用户 ${userId} 信息更新成功。`);
                resolve({ success: true, updatedId: userId });
            }, 300);
        });
    }
}

// 使用闭包创建 UserService 的代理
function createUserProxy(realUserService) {
    const cache = {}; // 缓存，通过闭包保持其状态
    console.log("Proxy: 代理实例被创建了。");

    return {
        getUserInfo: async function(userId) {
            if (cache[userId]) {
                console.log(`Proxy: 从缓存中获取用户 ${userId} 的信息。`);
                return cache[userId];
            }
            console.log(`Proxy: 缓存未命中，调用真实服务获取用户 ${userId} 的信息。`);
            const userInfo = await realUserService.getUserInfo(userId);
            cache[userId] = userInfo; // 缓存结果
            console.log(`Proxy: 用户 ${userId} 信息已存入缓存。`);
            return userInfo;
        },

        updateUserInfo: async function(userId, data) {
            console.log(`Proxy: 准备更新用户 ${userId} 的信息，执行前置日志记录...`);
            // 在更新前清除缓存，确保数据一致性
            if (cache[userId]) {
                delete cache[userId];
                console.log(`Proxy: 已清除用户 ${userId} 的旧缓存。`);
            }
            const result = await realUserService.updateUserInfo(userId, data);
            console.log(`Proxy: 用户 ${userId} 信息更新完成，执行后置日志记录...`);
            return result;
        }
    };
}

// 使用示例
const realService = new UserService();
const userServiceProxy = createUserProxy(realService);

// 第一次获取，会走真实服务并缓存
userServiceProxy.getUserInfo(101).then(data => console.log("获取到用户:", data));

// 再次获取，会走缓存
setTimeout(() => {
    userServiceProxy.getUserInfo(101).then(data => console.log("再次获取到用户:", data));
}, 700);

// 更新信息，会清除缓存并走真实服务
setTimeout(() => {
    userServiceProxy.updateUserInfo(101, { name: "新名字", email: "new@example.com" })
        .then(result => console.log("更新结果:", result));
}, 1500);

// 更新后再次获取，又会走真实服务
setTimeout(() => {
    userServiceProxy.getUserInfo(101).then(data => console.log("更新后再次获取用户:", data));
}, 2000);

在这个例子里，

createUserProxy

cache

{ getUserInfo, updateUserInfo }

getUserInfo

updateUserInfo

cache

realUserService

createUserProxy

为什么选择闭包实现代理模式？

我觉得，用闭包来搞定代理模式，这事儿挺有意思的，而且在某些场景下，它确实是个非常自然的选择。在我看来，主要有几个点：

首先，封装性特别好。当你在

createUserProxy

cache

realUserService

其次，状态持久化和独立性。闭包最核心的特性之一就是它能让内部函数记住并访问外部函数的变量，即使外部函数已经执行完了。对于代理模式来说，这意味着每个代理实例可以拥有自己独立的、持久的状态。比如上面例子中的

cache

userServiceProxy

再者，实现起来相对直观和轻量。对于一些相对简单的拦截需求，比如只是在方法调用前后加点日志、做个缓存，或者做个简单的权限校验，用闭包实现代理模式，代码结构非常清晰，也很好理解。你不需要引入新的语法或者复杂的API（比如ES6的

Proxy

最后，可以无侵入地增强现有对象。你不需要修改

UserService

当然，它也有它的局限性，比如只能代理你明确定义的方法，无法像ES6

Proxy

闭包代理模式与ES6 Proxy API有何不同？

说实话，这俩都是实现代理模式的利器，但它们的哲学和能力范围还是挺不一样的。理解它们之间的差异，能帮助你更好地选择在什么场景下用哪种。

迷你天猫商城

迷你天猫商城是一个基于Spring Boot的综合性B2C电商平台，需求设计主要参考天猫商城的购物流程：用户从注册开始，到完成登录，浏览商品，加入购物车，进行下单，确认收货，评价等一系列操作。 作为迷你天猫商城的核心组成部分之一，天猫数据管理后台包含商品管理，订单管理，类别管理，用户管理和交易额统计等模块，实现了对整个商城的一站式管理和维护。所有页面均兼容IE10及以上现代浏览器。部署方式1、项目

下载

ES6 Proxy API，我觉得它更像是一个“元编程”级别的工具。它提供了一个拦截所有对象操作的能力，包括属性的读取 (

get

set

apply

construct

in

delete

trap

而闭包代理模式，它更像是“方法级别”的代理。你通过闭包创建的代理，通常是针对目标对象上的某个或某几个特定方法进行拦截和增强。比如上面的

getUserInfo

updateUserInfo

UserService

userService.someProperty

new UserService()

简单来说：

• 拦截粒度： ES6 Proxy 是对象级别的，能拦截所有低层操作；闭包代理是方法级别的，只能拦截你显式包装的方法。
• 实现复杂性： ES6 Proxy 提供了更强大的能力，但也意味着你需要理解更多的“陷阱”概念，相对而言学习曲线稍陡峭一些。闭包代理则基于JavaScript最基础的函数和作用域概念，对于简单场景来说更直观。
• 适用场景：
  • ES6 Proxy 更适合需要对对象进行全面监控、修改其底层行为，或者构建通用框架和库的场景，比如实现响应式数据、数据绑定、虚拟化对象等。
  • 闭包代理 更适合对特定方法进行功能增强、性能优化（如缓存）、日志记录、权限控制等，当你只关心少数几个方法的行为时，它显得更轻量、更直接。
• 性能： 对于非常频繁的底层操作，ES6 Proxy 可能会引入一些额外的开销，因为它需要通过内部机制来处理所有的陷阱。但对于大多数应用来说，这种开销通常可以忽略不计。闭包代理由于其针对性强，如果实现得当，性能损耗可能非常小。

所以，选择哪个，真的要看你的具体需求。如果只是想给某个函数加个缓存或日志，闭包代理可能更简单直接；如果想实现一个像Vue那样的数据响应系统，那ES6 Proxy就是不二之选。

闭包代理模式在实际开发中的应用场景

在我日常的开发实践中，闭包代理模式虽然不像ES6 Proxy那样“包罗万象”，但在很多特定、常见的场景下，它依然是我的首选，因为它足够简单、直接，而且有效。

1. 方法缓存 (Caching)：这大概是最经典也最常用的场景了，就像上面示例中展示的那样。当某个函数的计算成本很高，或者涉及到频繁的网络请求时，你可以用闭包创建一个代理，在第一次调用时执行实际操作并将结果存储在一个闭包变量（比如

   Map

   或普通对象）中，后续调用时直接从缓存返回，大大提升性能。这对于一些数据不经常变动，但查询频繁的接口特别有用。

2. 日志记录与性能监控 (Logging & Performance Monitoring)：想象一下，你想要知道某个关键业务逻辑函数被调用了多少次，每次调用花费了多长时间，或者它的输入输出是什么。你完全可以用闭包代理来包装这个函数。在代理内部，你可以记录函数开始执行的时间，调用原始函数，然后记录结束时间，计算耗时，并将这些信息发送到你的日志系统或监控平台。这样，你既不侵入原始业务逻辑，又能获得宝贵的运行数据。

3. 参数校验与预处理 (Validation & Pre-processing)：在调用一个核心业务逻辑函数之前，你可能需要对传入的参数进行严格的校验，或者进行一些格式转换。比如，确保某个ID是数字，某个字符串不是空的，或者将日期字符串转换为

   Date

   对象。通过闭包代理，你可以在调用原始函数之前，先执行这些校验和预处理逻辑。如果校验失败，可以直接抛出错误，避免无效数据进入核心逻辑；如果成功，则传递处理后的参数。

4. 权限控制与安全检查 (Access Control & Security)：假设你的应用中有些操作只有特定角色或权限的用户才能执行。你可以创建一个代理，在调用这些敏感操作之前，先检查当前用户的权限。如果权限不足，直接拒绝操作并返回错误信息，而不是让请求触达真实的服务。这在前端需要进行一些预校验时非常实用，当然，最终的权限校验还是要在后端进行。

5. 延迟加载/懒加载 (Lazy Loading)：对于一些初始化成本很高，但并非立即需要的对象，你可以用闭包代理来“延迟”它们的创建。代理对象在被创建时并不立即实例化真实的重量级对象，而是在其某个方法被第一次调用时，才去创建并初始化真实对象。这样可以加快应用的启动速度，并节省不必要的资源消耗。

6. 错误处理与重试机制 (Error Handling & Retry)：当某个操作（尤其是网络请求）可能因为临时性问题而失败时，你可以用闭包代理来包装它，在代理内部实现一个简单的重试逻辑。如果原始操作失败，代理可以尝试再次调用几次，直到成功或达到最大重试次数。同时，你也可以在这里捕获并统一处理错误，例如向用户展示友好的错误信息，而不是直接抛出未经处理的异常。

这些场景都体现了闭包代理的“非侵入性增强”能力。它就像一个“中间人”，在不改动被代理对象代码的前提下，为其添加了新的行为或控制了访问方式，这在构建模块化、可维护的应用时显得尤为重要。