1. 为什么需要代理模式：从一个登录组件说起
做前端开发的朋友应该都遇到过这种场景：你给某后台系统写了一个上传头像的功能，用户每次点击头像区域，就要去后端拿一次用户的最新资料，然后重新渲染头像、昵称、等级这些信息。刚开始数据量小，一切风平浪静。等用户量上来，接口响应开始变慢，你会发现每次进页面都要白屏一会儿，原因是进入页面后同时触发了“拉取用户信息”和“拉取头像列表”两个请求，而头像列表的数据其实包含在用户信息里，等于同一份数据被重复获取了一次。
这个问题的本质，是“访问者”和“目标对象”之间缺少了一层缓冲和拦截。换一种说法：你直接访问了真实的对象，却没有机会在访问过程中插入缓存、权限判断、日志记录这些横切逻辑。代理模式解决的就是这个问题——在不修改原对象代码的前提下，通过引入一个代理对象来控制对原对象的访问。这个代理对象可以和原对象实现相同的接口，调用方感知不到差异，但内部却可以偷偷做很多事：缓存结果、过滤参数、延时加载、权限校验、埋点统计。
代理模式也是 JavaScript 里最容易被低估的模式之一。很多开发者日常写代码时其实已经在用 Proxy、事件委托、函数防抖节流这些与代理思想相关的东西，却没有意识到它们背后都是同一套逻辑。这篇文章我会把代理模式从概念到实战拆开讲清楚，包含几个可以直接抄作业的完整案例，也会聊一些在网上很难搜到的踩坑经验。适合已经熟悉 JavaScript 基础语法、想系统学习设计模式、或者正在写业务代码却觉得代码越来越难维护的朋友。
2. 代理模式核心概念与类型拆解
2.1 三个角色：客户、代理、真实对象
代理模式共有三个角色。第一个是目标对象（Real Subject），也就是真正干活的对象，比如上面例子里的 UserService，它负责从服务器拉取用户数据并渲染页面。第二个是代理对象（Proxy），它持有目标对象的引用，并且和 target 实现了相同的接口，所以对调用方（Client）完全透明。第三个是调用方（Client），它只和代理打交道，不直接接触真实对象。
用生活来类比：你在网上买了个手机，快递不会直接把手机扔到你手里，而是先送到小区快递柜，快递柜收到包裹后给你发短信取件码，你去取件时它还要核对你输入的取件码是否正确。这里的快递柜就是代理，手机是真实对象，你是调用方。快递柜的好处是：它可以在你不在家时替你签收（虚拟代理的延迟加载），可以校验取件码防止别人拿错包裹（保护代理），甚至可以把多个包裹合并通知你（聚合代理的批量处理）。
在代码层面，JavaScript 的代理模式有两种实现方式：一种是普通函数/类手动包装，另一种是 ES6 原生提供的 Proxy 对象。手动包装的好处是兼容性极好、逻辑完全可控；Proxy 的好处是可以拦截更多操作（属性读取、属性赋值、删除、枚举、函数调用等）。这两者不是替代关系，后面我会分别给出对应的使用场景。
2.2 静态代理与动态代理的本质区别
"静态代理"和"动态代理"这两个词经常被混着提，但它们的含义完全不同。静态代理指的是你在编译时（或者说代码编写时）就为每个目标类手动写一个代理类。比如你有一个 UserService，就得额外写一个 UserServiceProxy，里面每个方法都得手动转发一遍。这种方式的缺点是：如果目标类有 20 个方法，代理类就要写 20 个转发方法，而且每新增一个方法，代理类也要跟着改，维护成本相当高。
动态代理则是在运行时（或者说代码执行时）动态生成代理，不需要为每个目标类单独写代理类。JavaScript 的 Proxy 就是天然的动态代理——你只需要传一个 target 和 handler，就能拦截 target 上的任意属性操作，不需要预先知道 target 有哪些方法。这给代码复用带来了很大的便利：同一个缓存代理逻辑，可以轻松套在 UserService、OrderService、ArticleService 上，只要传入的 target 不同即可。
在真实项目里，我最常用的是动态代理，因为它的“透明性”最强——业务代码里几乎不需要感知代理的存在，只要把原来的 new UserService() 换成 new Proxy(new UserService(), handler) 就行。静态代理也不是完全没有用，比如当你需要针对单个方法定制完全不同的代理逻辑、且这些逻辑很难用通用 handler 表达时，手写静态代理反而更清晰。
2.3 四种高频的代理类型
代理模式在实际项目中高频出现的变体可以归为四类，理解它们的区别对后面实操非常关键。
缓存代理（Cache Proxy）是最常用的一类。它把第一次计算的结果缓存起来，后续相同参数的调用直接返回缓存值，常见于函数计算结果缓存、HTTP 请求结果缓存、大数据筛选结果缓存。这种代理适合“入参相同则输出一定相同且计算成本较高”的场景。
虚拟代理（Virtual Proxy）解决的是“创建昂贵对象时希望延迟到真正使用时才创建”的问题。比如页面里有一张很大的图片，图片本体可能几 MB，网页加载时不应该立刻下载它，而是先用一个轻量级的占位对象，等用户滚动到可视区域或点击放大时再触发真正的图片加载。
保护代理（Protection Proxy）在调用前加一道权限校验，只放行满足条件的请求。比如某些管理后台接口只有管理员角色才能调用，代理可以在前端层面先拦截非管理员用户的操作，减少无效请求、也避免前端暴露敏感数据。
日志代理（Logging Proxy）在方法调用前后追加日志、埋点、性能统计等行为，类似 AOP（面向切面编程）里的拦截器。它和上面的缓存代理常常组合使用：一个 handler 同时做参数校验、日志上报和结果缓存。
3. 从零实现一个完整的缓存代理案例
3.1 需求描述与接口设计
我们做一个真实的缓存代理案例。某内容管理后台有一个“获取文章列表”接口，入参是 page（页码）、pageSize（每页条数）、keyword（搜索关键词）。后端返回的数据结构是：
{ "code": 0, "data": { "list": [{ "id": 1, "title": "标题" }], "total": 132 } }现在的问题有两个：第一，用户在前端频繁切换页码、筛选条件和排序方式，每次切换都会发起新请求，很多请求的结果其实一模一样（比如从第 1 页切到第 2 页再切回第 1 页，第 1 页的数据完全没变，却重新请求了一次）；第二，接口响应本身不稳定，偶尔会超时，超时后用户再次触发相同查询，又要重新等上一个请求。
我们的目标是通过代理模式加一层客户端缓存：相同参数的请求在缓存有效期内直接返回上一次的结果，不发起网络请求；同时用 Promise+Map 的方式避免并发情况下重复请求。这个需求非常适合用缓存代理来做，而且实现完之后基本可以原样复用到任何接口上。
3.2 无代理的初始实现与痛点
先用不考虑代理的方式写一个最朴素的版本，方便等会儿对比效果。原始的 ArticleService 长这样：
class ArticleService { async fetchList(params) { const query = new URLSearchParams(params).toString(); const response = await fetch(`/api/articles?${query}`); const result = await response.json(); if (result.code !== 0) { throw new Error(`请求失败：${result.message}`); } return result.data; } }这段代码的问题一眼就能看出来：它对外暴露了 f 背的所有逻辑都写在业务代码里。假设有十个组件都在调用 fetchList，每个组件都不知道别人已经请求过同一份数据了，于是这个接口可能被重复调用十次。如果后端没有做请求合并或缓存，后端压力会成倍增加，用户也能明显感觉到切页时列表出现闪烁和等待。
有人可能会说，“那我在每个调用 fetchList 的地方手动加一个 Map 缓存不就行了？”确实可以，但如果调用点很多，你就要在每个地方复制粘贴相同逻辑，一旦缓存策略调整（比如加一个过期时间），就要改所有调用点，维护性极差。而代理模式的价值正在这里：缓存逻辑被收拢到一处，所有调用方无感知。
3.3 缓存代理实现与验证
接下来用 Proxy 实现动态缓存代理。核心思路是：传入原始 service，返回一个代理对象，对 fetchList 方法的调用被 handler 拦截，在缓存中寻找相同 key 的结果，找到就直接 resolve，找不到就走原方法并把 Promise 缓存进 Map。
function createCacheProxy(service, options = {}) { const cacheMap = new Map(); const pendingMap = new Map(); const DEFAULT_TTL = 60 * 1000; // 默认缓存 1 分钟 return new Proxy(service, { get(target, propKey) { const originalMethod = target[propKey]; if (typeof originalMethod !== 'function' || propKey !== 'fetchList') { return originalMethod; } return function cachedFetch(params = {}) { const cacheKey = buildCacheKey(params); const now = Date.now(); // 命中已完成的缓存，并且还没过期 const cached = cacheMap.get(cacheKey); if (cached && now - cached.timestamp < (options.ttl || DEFAULT_TTL)) { console.log(`[CacheProxy] 命中缓存: ${cacheKey}`); return Promise.resolve(cached.data); } // 相同参数的请求还在飞行中，直接复用同一个 Promise if (pendingMap.has(cacheKey)) { console.log(`[CacheProxy] 复用进行中的请求: ${cacheKey}`); return pendingMap.get(cacheKey); } const promise = Promise.resolve(originalMethod.call(target, params)) .then((data) => { cacheMap.set(cacheKey, { timestamp: Date.now(), data }); return data; }) .finally(() => { pendingMap.delete(cacheKey); }); pendingMap.set(cacheKey, promise); return promise; }; } }); } function buildCacheKey(params) { return Object.keys(params) .sort() .map((key) => `${key}=${params[key]}`) .join('&'); } const articleService = new ArticleService(); const proxyService = createCacheProxy(articleService, { ttl: 30 * 1000 }); // 业务代码里直接这样用： proxyService.fetchList({ page: 1, pageSize: 10, keyword: '设计模式' }) .then((data) => render(data));这段代码里有三个值得注意的细节。第一，pendingMap 的作用很关键，它保证并发调用相同参数时只发一个请求，这种场景在前端很常见：用户快速连点两次查询按钮，或者多个组件同时挂载。如果没有 pendingMap，两个请求同时发出，缓存写入顺序无法保证，还可能造成重复请求。第二，buildCacheKey 对参数做了排序，避免 { page: 1, pageSize: 10 } 和 { pageSize: 10, page: 1 } 被认为是两个不同 key。第三，我把 Promise 缓存进了 Map 而不是把最终结果缓存进 Map，配合 .finally 清理 pendingMap，确保在请求失败的情况下下次还能重新发起请求，而不是一直拿到一个 rejected 的 Promise。
验证方式也很简单：连续调用三次相同的 fetchList，观察控制台输出。第一次输出“未命中，发请求”，第二第三次都是“命中缓存”，并且 network 面板只会出现一次 /api/articles 请求。如果把 ttl 改成 500ms，等待 600ms 后再调用，你会发现缓存已经过期，会重新发请求，这证明过期机制是有效的。
4. 保护代理与虚拟代理实战：前端权限控制与图片懒加载
4.1 先说一个反模式：直接把权限判断写在业务里
我在某公司看到过这样一个例子：管理后台的“删除用户”按钮，业务代码里到处是 if (user.role !== 'admin') return alert('无权限') 这样的判断。这个写法有很严重的问题：第一，权限逻辑散落在各个组件和事件回调中，一旦权限规则变化（比如新增一个 super_admin 角色），就需要全局搜索替换；第二，如果调用方是一个内部工具函数而非 UI 组件，权限判断很可能被遗漏，造成越权操作；第三，业务代码里充满了与核心逻辑无关的 if 分支，可读性很差。
保护代理的思想是：核心业务逻辑（比如真正删除用户的 deleteUserById 方法）只关心“把 id 传给后端删除”，不关心“谁有权限执行删除”。权限校验全部放到代理层，业务对象保持纯净。这样做的好处是核心逻辑可以被放心复用在服务端、定时任务、命令行脚本等不同场景，因为那些场景不需要经过前端权限判断。
4.2 用保护代理统一管理权限校验
下面是一个最小可用的保护代理实现。假设我们有三个角色：guest（游客）、editor（编辑）、admin（管理员）。某个后台服务对象 adminService 上有两个操作，viewDashboard 和 deleteArticle，我们希望 guest 不能调用 viewDashboard，editor 不能调用 deleteArticle。
const rolePermissions = { guest: ['viewArticle'], editor: ['viewArticle', 'viewDashboard'], admin: ['viewArticle', 'viewDashboard', 'deleteArticle'] }; function createProtectedProxy(target, currentUser) { return new Proxy(target, { get(target, propKey) { const originalMethod = target[propKey]; if (typeof originalMethod !== 'function') return originalMethod; return function guardedMethod(...args) { const allowed = rolePermissions[currentUser.role] || []; if (!allowed.includes(propKey)) { console.warn(`[ProtectedProxy] ${currentUser.role} 无权调用 ${propKey}`); return Promise.reject(new Error('无权限执行此操作')); } return originalMethod.apply(target, args); }; } }); } const realService = { async viewArticle() { return '文章内容'; }, async viewDashboard() { return '仪表盘数据'; }, async deleteArticle(id) { return `已删除文章 ${id}`; } }; const adminProxy = createProtectedProxy(realService, { role: 'admin' }); const guestProxy = createProtectedProxy(realService, { role: 'guest' }); adminProxy.deleteArticle(1); // 正常，返回 "已删除文章 1" guestProxy.deleteArticle(1); // 拒绝，控制台出现无权操作警告这段代理的逻辑把“角色权限对照表”集中到了一处，未来新增角色只需要改 rolePermissions，不用去业务代码里翻改 if。如果权限校验还需要异步判断（比如从接口动态拉取角色），可以把 guardedMethod 改成 async，先 await 一个 checkPermission() 再决定是否放行。
有一点需要注意：前端代理的权限控制只是用户体验层面的拦截，真正可靠的安全管控必须由后端完成。前端做保护代理的价值是减少无效请求、隐藏敏感入口、提升用户体验，而不是把它当成安全边界。这一点在做系统设计时必须写进文档，否则容易被误用。
4.3 虚拟代理实现图片懒加载
再来看虚拟代理。场景是某博客文章页有几十张图片，如果页面加载时一次性全部请求，首屏会变得很慢，白白消耗流量。传统做法是监听 scroll 事件，判断图片是否进入视口再决定是否替换 src，代码逻辑分散而且容易写错。
虚拟代理的做法是：真正的图片对象（new Image()）被延迟到该图片即将进入视口时才创建并赋值。用代理对象占住原来的位置，视觉上先显示一个轻量的占位节点，比如灰色背景加 loading 文字。
class LazyImageProxy { constructor(realImageFactory) { this.realImage = null; this.realImageFactory = realImageFactory; this.isLoaded = false; } // 调用方视图里看到的节点 get node() { if (!this.realImage) { // 未进入视口前只显示占位节点 return createPlaceholder('图片加载中...'); } return this.realImage.node; } load() { if (this.isLoaded) return; this.isLoaded = true; this.realImage = this.realImageFactory(); this.realImage.load(); } }实际使用时，页面里的每张图都先创建一个 LazyImageProxy，滚动监听器检测到某个 proxy 的占位节点进入视口后，调用 proxy.load()。加载完成后 proxy.node 返回真实图片节点，调用方更新视图。
这个写法最妙的地方在于：业务组件不需要知道它拿到的是真实图片还是代理占位，因为两者都有相同的 node 属性和 load 方法。真实图片的创建成本被推迟到真正需要的那一刻，占位节点又是轻量级对象，创建几十上百个也不会有压力。如果你用的是现代前端框架，你会发现很多框架的 LazyImage 组件本质就是虚拟代理思想，只不过封装更完整、支持了更多配置项。
5. 经典场景应用分析：事件委托、数据响应式与模式对比
5.1 事件委托：你可能每天都在写代理
事件委托（Event Delegation）本质上也是一种代理模式。你并没有在每个子元素上绑定 click 监听器，而是把监听器绑定在父容器上，父容器作为代理统一接收事件，再根据 event.target 判断实际触发元素。这种做法的好处你肯定体会过：动态新增的子元素不需要额外绑定事件，代理天然能捕获到冒泡上来的事件。
举个典型例子：某后台的消息列表容器 ul 里可能有几百个 li，每个 li 的删除按钮都需要弹确认框。如果你给每个 li 单独绑事件，新增 li 时还要临时补绑定，性能瓶颈和维护成本都很难受。用事件委托，只需要在 ul 上挂一个监听器，判断 target 是否是 .delete-btn，然后开始后续逻辑。这个 ul 就是中转站，承担了“把事件分发给正确元素处理”的职责。
结合代理模式的理论，事件委托其实就是一个特殊的保护代理或日志代理：它在分发给目标元素之前，先做一次血统判断（保护逻辑），顺便也可以在这里做埋点统计（日志逻辑）。理解了这一点，你对事件委托的认知就不再是“一个技巧”，而是代理模式在 DOM 世界里的一次具体落地。
5.2 框架中的数据响应：Proxy 如何撑起响应式系统
说到 JavaScript 框架，就不得不提当前主流前端框架的响应式系统。其实你在 Vue 的源码里能看到的正是 Proxy 这种动态代理模式：组件里访问 data 对象的属性时，Proxy 的 get 拦截器会登记依赖（收集 effect），给属性赋值时，set 拦截器会触发更新。这就是一个典型的“代理 + 发布订阅”的组合拳。
对比旧版本的实现方式（比如 Object.defineProperty），Proxy 因为能拦截更多操作而显得更优雅：新增属性、删除属性、数组索引变化都能被捕获，不需要额外调用类似 Vue.set 的方法。这里我想说的是，理解代理模式能帮你读懂框架的响应式原理，而不只是停留在“哦，它用了 Proxy”这个层面。
你在写业务代码时也可以利用这个特性。比如某个复杂表单，你想在任意字段变化时自动做表单校验，同时记录修改日志，最简单的方式不是给每个 input 加事件，而是把表单数据包一层 Proxy，在 set 拦截器里统一处理校验和日志。只要把校验函数和日志函数传递给 handler，它们就都能在字段被赋值时自动触发，不侵入业务代码。
5.3 代理、装饰器、适配器与门面模式，到底有什么区别
很多初学者容易把代理模式和装饰器模式搞混，因为它们都涉及“包装一个对象”。区别在于：代理模式的核心目的是控制访问，它关心的是“什么时候访问、谁能访问、访问结果需不需要缓存”；装饰器模式的核心目的是扩展功能，它关心的是“如何为对象增加额外的职责”。通俗地说，代理通常负责“拦一拦，放不放行我说了算”，装饰器负责“补一补，功能少了点，我再加一个”。
适配器模式解决的是“接口不兼容”的问题：一个老模块的接口长得和新的调用方预期不一样，适配器负责翻译转换。代理模式则要求代理和目标具有相同的接口，不涉及接口形状的转换。门面模式更偏向“统一入口”，它把一堆子系统接口收拢成一个高层接口，而代理通常只包装一个对象。这几个模式在实际代码里经常一起出现，特别是大型框架里，一个对象外面可能同时套着代理、装饰器、适配器，所以搞清楚它们各自的关注点非常重要。
6. 常见问题与避坑清单：代理模式使用中容易翻车的点
6.1 this 指向丢失与对象身份陷阱
用 Proxy 写动态代理时，最常见的 bug 是 this 丢失。看一下这段代码：
const proxy = new Proxy(service, { get(target, propKey) { return target[propKey]; } });当业务代码里执行 proxy.fetchList() 时，JavaScript 会先读 proxy.fetchList 这个属性，get 拦截器返回了 target.fetchList 这个函数，但此时这个函数内的 this 已经绑定到了 proxy 而不是 target。如果 fetchList 内部用了 this 访问其他属性或方法，就会报错或者拿到 undefined。
解决办法是：get 拦截器里返回函数时，用 .bind(target) 或 .apply(target, args) 把 this 显式指回 target。这也是为什么前面例子里的 guardedMethod、cachedFetch 都特意用 originalMethod.apply(target, args) 的原因。写代理代码时务必要养成这个肌肉记忆。
另一个需要注意的坑是对象身份问题。代理对象和原对象是两个不同的对象，如果业务代码里用 === 判断对象身份，或者把原对象传给第三方库，代理会失去意义。比如 service 被赋值给 proxyService 后，又有代码直接读取原始 service，缓存代理就被绕过了。要在团队规范里明确：一旦决定使用代理，所有调用方都必须经过代理，不要把原始对象再暴露出去。
6.2 缓存代理的过期策略与内存泄漏
缓存代理虽然好用，但用不好会引入更严重的资源泄露。Map 里的缓存如果不设置过期时间，且缓存 key 持续增加（比如按照用户 ID 缓存），长时间运行下来内存占用会越来越大。另一种风险是缓存了包含敏感数据的响应结果，如果页面存在权限差异（A 用户能看到的数据 B 用户也能命中同一缓存），就会产生越权读到他人信息的严重事故。
针对这些坑，我有几条经验：第一，所有自定义缓存都要设计 TTL（过期时间），没有 TTL 的缓存只是在推迟问题；第二，缓存 key 必须包含和权限相关的因子，比如用户 ID、角色，或者干脆在权限代理之后再套缓存代理，这样缓存永远只能命中同权限用户的数据；第三，可以对 Map 增加一个最大容量限制，比如超过 100 条时按最久未使用策略清理。虽然这会让代码变复杂，但在用户量较大的系统里，这一步是必须的。
6.3 什么时候不该用代理模式
代理模式不是银弹，在某些场景下硬上反而会降低代码质量。最典型的情况是：目标对象的方法数量很少、调用频率低、且不需要横切逻辑，这时候引入代理就是明显的过度设计。另一个反面场景是高频率、超简单、纯数据的对象，比如一个几千条数据的配置表，你只是想读一读其中的字段，套上代理会带来不必要的性能损耗和调试困难。
还有一点我要特别提醒：代理层数不要叠太多。有的人写代码特别“有洁癖”，一层缓存代理、一层权限代理、一层日志代理、一层埋点代理叠起来，看起来很“架构”，但出 bug 时极难排查，因为堆栈信息会被层层包装搞得很模糊。我的习惯是：最多叠两层代理（比如权限在外层、缓存在内层），再复杂的场景就考虑把这些逻辑合并进一个 handler 或者拆成独立工具函数。设计模式的最终目的是让代码容易理解，而不是制造仪式感。
最后分享一个我踩过好几次坑之后的体会：代理模式真正的高频价值不在“炫技”，而在于把横切关注点从业务代码里抽离出来。你不需要记住所有模式，只需要在每次想把一段重复逻辑硬塞进业务函数时，想一想“能不能用代理挡在外面”，答案经常是肯定的。当你发现自己写的业务函数越来越短、每个函数只做一件事的时候，代理模式的收益就真正体现出来了。
