前端工程师接触设计模式这事，我一直觉得挺拧巴的：面试题里被问到，心里发怵；日常撸业务代码，又觉得它派不上用场。很多前端把设计模式当成 Java/C++ 后端的传统技艺，跟自己写组件、调接口、配状态没多大关系。但真实情况恰恰相反，前端可能是最需要设计模式的领域之一——因为前端的代码天生是事件驱动、状态驱动、充满了异步和交互，代码腐烂的速度远超大多数后端服务。这篇文章不是要你背下 23 种模式的八股定义，而是想从前端实际开发的视角，挑出真正高频、真正能救命的那些模式，聊聊它们背后解决的问题、落地的代码长什么样，以及我踩过哪些抽象过度的坑。

1. 前端代码腐烂的信号与设计模式的用武之地

1.1 那类"没人敢动"的前端代码长什么样

我接手过一个中后台项目，功能不复杂，就是组织架构树加人员列表再加批量操作。但代码文件动辄三千行，核心逻辑全堆在几个巨型组件里。需求改动永远牵一发动全身：加一个筛选项，要同时改三四个方法；改一个接口字段，全局搜出来十几处赋值；想复用点逻辑，只能复制粘贴，越粘越乱。这类代码最典型的特点就是——if-else 层层嵌套，函数动辄几十行，父子组件通过一堆 props 和事件传参，数据流混乱到没法追溯。

这种腐烂不是没救，但靠的不是加班和小心谨慎，而是结构化思维。设计模式说白了就是经过无数次实战验证的、针对特定问题的代码结构模板。你不需要发明解决方案，只需要识别出"哦，我这里是典型的策略模式应用场景"或"这个跨层通信应该用发布订阅"，然后套上对应的结构，问题立刻清晰一半。

1.2 为什么前端的模式需求比后端更迫切

后端服务的代码结构通常以接口为界，一个接口对应一个完整的业务链路，内部层次分明。但前端代码的复杂度不按模块均匀分布，它集中在状态流转、用户交互、视图同步这三件事上。用户点一个按钮，背后可能触发了接口请求、表单校验、权限判断、路由跳转、状态更新、局部渲染，这一整个链路里任何一环出现耦合，后续维护都是灾难。

打个比方：后端写一个月度报表接口，逻辑写得乱，但接口对外还是那一份 JSON，调用方感受不到内部波澜。前端不行——前端代码直接长在界面上，每个分支、每个状态、每个条件渲染都是用户看得见摸得着的。组件之间一旦耦合，改一处崩三处是家常便饭。设计模式在前端的价值，就在于给你一套"解耦"的通用工具，让组件、逻辑、数据各归各位，改起来有底气。

1.3 别把设计模式当成考试科目，它是工程语言

我见过不少前端把设计模式当成"知识点"来学，背定义、背类图、背优缺点，转头回到项目里照样怎么写都行。这其实完全用错了方向。设计模式不是让你去"背"的，而是让你在写代码时像条件反射一样识别场景的工具。当你写到一个充斥着 if-else 的校验函数时，脑子里要浮现的是"策略模式"；当你在纠结怎么跨三个组件层级传递回调时，脑子里要浮现的是"观察者模式"。

换句话说，设计模式是工程师之间的"通用语言"。你跟同事说"这里我用了策略模式"，对方立刻明白你的意图和结构；你说"我把校验逻辑写成了一个策略表"，对方马上知道该怎么扩展。这种沟通效率的提升，比代码本身更值钱。

2. 前端日常开发里真正高频的七个模式（带实战拆解）

2.1 策略模式：消灭看着就头疼的 if-else 链

策略模式的核心思想是：定义一族算法，把每个算法封装起来，使它们可以互相替换。我之前说得通俗点就是——把一段段做判断的逻辑从"中心化的 if-else"里拆出来，变成一个个独立的小模块，每个模块负责一个具体规则。

前端最常见的应用场景就是表单校验。新手写法是这样的：

function validateForm(formData) { if (!formData.username) return '用户名不能为空'; if (formData.username.length < 4) return '用户名至少4位'; if (!formData.email) return '邮箱不能为空'; if (!/^[^@]+@[^@]+$/.test(formData.email)) return '邮箱格式不正确'; if (!formData.phone) return '手机号不能为空'; if (!/^1[3-9]\d{9}$/.test(formData.phone)) return '手机号格式不正确'; return ''; }

这段代码的问题不是可读性差，而是扩展性差：每加一个字段、每加一条规则，你都得回到这个函数里去改。而且这些规则之间彼此独立却挤在同一个函数体里，删改任何一条都要担心误伤其他规则。

策略模式的做法是把规则变成一张"策略表"：

const validators = { required: (value) => (value !== '' && value != null) || '该项必填', minLength: (value, len) => value.length >= len || `长度至少${len}位`, pattern: (value, reg) => reg.test(value) || '格式不正确', }; // 配置驱动的表单校验 const fieldConfigs = [ { name: 'username', rules: ['required', { type: 'minLength', param: 4 }] }, { name: 'email', rules: ['required', { type: 'pattern', param: /^[^@]+@[^@]+$/ }] }, ]; function validateField(name, value, rules) { for (const rule of rules) { if (typeof rule === 'string') { const result = validators[rule](value); if (result !== true) return result; } else { const result = validators[rule.type](value, rule.param); if (result !== true) return result; } } return ''; }

以后加一条规则，只需往validators里加一个方法，完全不用碰validateField的逻辑。这就是策略模式带来的最直观的收益：规则和规则的使用方式解耦，要加新规则或调整规则组合，改配置即可。它的本质是把"怎么校验"和"校验什么"分开，而这两件事混在一起正是代码变差的元凶。

策略模式很实用，但不是所有 if-else 都值得拆。我的经验是：如果条件分支超过三个，并且未来极可能有新分支加进来，果断上策略；如果只是两种情况的简单判断，硬套策略反而显得绕。

2.2 观察者模式与发布订阅：让组件之间"不直接喊话"

观察者模式在概念上很简单：一个对象（被观察者）状态变化时，通知所有依赖它的对象（观察者）。但前端里我们更多用的是它的变体——发布订阅模式。它俩的差别在于：观察者模式中观察者直接挂在被观察者身上，而发布订阅模式中发布者和订阅者互不认识，中间隔着一个"事件中心"。

前端为什么需要这东西？因为组件通信太难了。父传子用 props，子传父用事件回调，这都还好。但跨三级、四级组件的通信，或者两个不相干的兄弟组件要同步状态，你再一层层传 props、层层转发事件，代码会变成一团乱麻。发布订阅模式提供一个事件总线，谁需要数据就订阅，谁产生了数据就发布，两边都不需要知道对方存在。

// 极简事件总线实现 class EventBus { constructor() { this.events = {}; } on(eventName, handler) { if (!this.events[eventName]) this.events[eventName] = []; this.events[eventName].push(handler); } off(eventName, handler) { const handlers = this.events[eventName] || []; this.events[eventName] = handlers.filter((h) => h !== handler); } emit(eventName, payload) { (this.events[eventName] || []).forEach((handler) => handler(payload)); } } export const eventBus = new EventBus();

现在两个组件可以这样通信：

// 监听方 eventBus.on('user:login', (user) => { this.updateUserInfo(user); }); // 触发方 eventBus.emit('user:login', { id: 1, name: '张三' });

这里我得提醒一句踩坑经验：事件总线用起来非常爽，但滥用起来也非常痛。一旦事件流散落在各个组件里，你很难追踪一个事件到底被谁监听了。我见过一个项目全局事件总线里挂了几十个事件名，同名事件被监听三次、触发两次，调试时人直接崩溃。所以我的建议是：跨三层以上组件且中间组件不想当"传话筒"时，才用事件总线；普通的父子通信，老老实实用 props 和回调。Vue 的 provide/inject、React 的 Context 能解决大部分跨层问题，事件总线是最后的选择。

2.3 工厂模式：按需"生产"组件和实例

工厂模式解决的核心问题是：创建对象的逻辑复杂，客户端不想关心"怎么造"，只想拿"造好的东西"。前端里最常见的应用，就是根据配置或类型动态创建不同的组件/实例。

比如我们做一个报表系统，用户选了图表类型后，要渲染对应的图表实例：

// 没有工厂时，调用方得自己 new let chart; if (type === 'line') { chart = new LineChart(options); } else if (type === 'bar') { chart = new BarChart(options); } else if (type === 'pie') { chart = new PieChart(options); } // 用工厂函数之后 function createChart(type, options) { const chartMap = { line: () => new LineChart(options), bar: () => new BarChart(options), pie: () => new PieChart(options), }; return chartMap[type]() || new BaseChart(options); } const chart = createChart('line', options);

你不用在业务代码里关心到底有哪些图表类型，只需要一个type字符串，工厂帮你搞定实例化逻辑。新加一种图表时，改动只在createChart内部，业务调用方完全无感。

工厂模式在前端的另一个重头应用是异步组件工厂，结合动态import()做按需加载：

const componentFactory = { modal: () => import('./components/Modal.vue'), drawer: () => import('./components/Drawer.vue'), notification: () => import('./components/Notification.vue'), }; async function mountComponent(type, container, props) { const loader = componentFactory[type]; if (!loader) throw new Error(`Unknown component type: ${type}`); const module = await loader(); createApp(module.default, props).mount(container); }

这样按需加载不仅让首屏更快，而且把"创建什么组件"的决策权和"怎么创建"的实现细节分开了。调用方只负责告诉工厂"我要什么"，工厂负责"怎么变出来"，这就是工厂模式的精髓。

说一下这个模式的使用心得：工厂模式的代价在于多了一层间接。小项目、少量类型时，直接 new 反而更清晰。一般我是在"类型要多、调用方拷贝不了"的时候才用工厂。如果是内部工具库、组件库、SDK，工厂几乎是标配，因为你的下游用户不受你控制，接口越稳定越好。

2.4 单例模式：全局只有一份气儿

单例模式可能是前端最有争议的模式——后端觉得它是反模式，前端却离不开它。它的定义很简单：确保一个类只有一个实例，并提供全局访问点。前端的全局状态、请求客户端、日志上报器，天然需要只有一个实例。

实际开发中很多语言层面已经帮你实现了单例。ES Module 的模块系统本身就有缓存机制，一个模块第一次被 import 后，后续所有 import 拿到的都是同一个引用。也就是说：

// http.ts 被导出一次 export const http = new HttpClient({ baseURL: '/api' }); // 任何地方导入，拿到的都是同一个实例 import { http } from './http';

拿到同一个实例意味着什么？意味着你在一个模块里给http配置的拦截器，全局都能生效；你全局设置的 token，所有请求都能带上。这种"一份配置全局生效"的特性，正是身份认证、埋点上报、全局弹窗这类功能必须的。

单例模式要注意的坑是别把单例变成全局垃圾场。单例虽然是唯一的，但它不该是"随便什么东西都往里塞"的全局变量盆。我见过有人把用户信息、页面状态、临时缓存、配置项全部堆在一个globalStore里，最终结果就是谁都能改、谁都改不清楚。单例模式的正确用法是：明确的职责 + 收敛的访问入口。比如http只负责请求，logger只负责日志，store只负责状态，各自职责单一，互不污染。

2.5 代理模式：给真实对象加一层"安检"

代理模式的思想是：不直接操作目标对象，而是通过一个代理对象间接操作。代理可以在不改变目标对象源码的情况下，附加额外逻辑——比如防抖、节流、权限校验、缓存、日志。

前端的防抖和节流，本质就是一个"代理"：

function debounce(fn, delay) { let timer = null; return function (...args) { if (timer) clearTimeout(timer); timer = setTimeout(() => { fn.apply(this, args); }, delay); }; } // 把原本直接绑定的提交逻辑，交给防抖代理 input.addEventListener('input', debounce(handleInput, 300));

防抖函数返回的新函数，替代了原函数成为了事件回调。原函数不需要做任何改动，却获得了"延迟执行"的额外能力。这就是代理模式的强大之处：你不需要动真实逻辑，就能在外围加一层控制。

前端还有一个特别经典的代理场景：图片懒加载。真实图片加载成本高，先用占位图替代，等真正需要显示时才请求真实图片。这就是虚拟代理。路由守卫的本质也是代理——在跳转到真实页面之前，先经过一个代理层做权限检查：

router.beforeEach((to, from, next) => { if (to.meta.requiresAuth && !isLoggedIn()) { next('/login'); } else { next(); } });

代理模式的扩展性极佳，但它也有代价：代理层会把调用链拉长，而且代理代码和真实逻辑之间的"胶水"写得不干净，反而更难读。我的原则是——只对"经常需要加逻辑"的边界使用代理，比如请求层、事件层、路由层。业务内部的方法互相代理，那属于绕圈圈，不推荐。

2.6 装饰器模式：在不修改原函数的基础上增强行为

装饰器模式跟代理模式很像，但侧重点不同：代理强调的是"控制访问"，装饰器强调的是"附加功能"。前端最常见的装饰器场景是埋点上报、性能统计、权限校验，而且是给已有的方法动态增加这些能力。

// 统计函数执行耗时，不改原函数 function withTiming(fn) { return function (...args) { const start = performance.now(); const result = fn.apply(this, args); console.log(`${fn.name} 耗时 ${performance.now() - start}ms`); return result; }; } function fetchUserList() { // 原有的请求逻辑 } fetchUserList = withTiming(fetchUserList);

装饰器模式还有一个更"正"的姿势，是用装饰器语法：

function report(target, name, descriptor) { const original = descriptor.value; descriptor.value = function (...args) { // 埋点上报 track(`${name} 被调用`); return original.apply(this, args); }; return descriptor; } class UserService { @report getUser(id) { // 真实逻辑 } }

装饰器模式的精髓在于叠加：功能 A 装饰功能 B 装饰功能 C，每个装饰器只关心自己那件事。登录后既要做埋点又要校验权限，两个装饰器互相独立，可以自由组合。这一点比在业务代码里手写两段嵌套逻辑清晰得多。

前端开发中还有一种"隐形装饰器"是 Vue 2 的 mixin、React 的高阶组件（HOC）。它们本质都在做"给已有组件附加新能力"的事。但后来基本被 Hooks 和组合式函数取代了，原因后面会讲。

2.7 适配器模式：处理"接口不兼容"的万能胶水

适配器模式解决的是接口不匹配问题：客户端期待一个格式，实际拿到的却是另一个格式，这时需要一个适配器来做转换。前端最典型的就是后端接口数据结构适配。

后端返回的字段命名风格是 snake_case（下划线），前端组件期待 camelCase（驼峰）；或者后端分页接口返回的 total、list，前端需要的却是 count、records。你不可能让后端随前端口味随时改接口，也不可能让前端每个组件都各自做字段转换。这时候用一个统一的适配层：

// 适配器：把后端返回值转换成前端页面模型 function adaptUserApiResponse(apiData) { return { id: apiData.user_id, name: apiData.user_name, email: apiData.email_address, role: apiData.role_code, createdAt: apiData.created_at, }; } // 在请求层统一使用适配器 const user = adaptUserApiResponse(await http.get(`/users/${id}`));

这样一来，视图层和后端接口的结构变化互不影响：后端字段改了，只需改适配器；前端组件要加字段，也只动适配器。

适配器模式在第三方库封装上也特别常见。如果项目里接了一个第三方地图 SDK，而这个 SDK 的 API 很难用、跟公司其他业务代码风格迥异，你应该封装一层自己的MapService，内部调用 SDK，对外提供自己的接口。以后换 SDK，只需要换适配层，业务代码零改动。

说实话，前端的适配器有时不需要做成类，一个普通函数就够了。它的核心思想（做夹层转换）远比形式重要。适配器什么时候该用？当你在代码里看到"这个字段和那个字段明明是一回事，但命名不同、结构不同"时，就是你该做适配的时候。

3. 从组件库和 SDK 的源码里看到设计模式的落地

3.1 组件库中的策略模式、代理模式和适配器模式

如果你觉得前面这些模式都是"业务代码里的小打小闹"，那可以去看看成熟的前端组件库是怎么用的。比如一个比较完善的表单组件库，几乎每个复杂组件都能看到模式的影子。

表单校验规则用的是策略模式，每个内置校验规则（required、minLength、email、custom）都是策略，用户自定义规则就是在策略表里加新条目。弹窗类组件的归属其实暗含了工厂模式，JS 调用的modal.confirm()这类命令式 API，内部就是帮你 new 了一个实例再 mount 进 body。组件库的发布订阅藏在一些全局状态同步里，比如主题切换、语言切换，这些不需要每个组件单独传参，而是通过全局事件广播。适配器就更明显了，组件库要适配不同的浏览器兼容性、不同的数据格式，内部肯定有一堆 normalize 函数。

有一次我为了调一个表格组件性能问题，深入看了它的虚拟滚动实现，越看越觉得熟悉——这不就是代理模式吗？它先算出一个可视区域，然后再渲染真实数据，用一薄层占位容器"代理"了真正的列表，用户滚动时动态替换真实内容。设计模式不是只在后端 EJB 里，也不只是理论书里的类图，它就躺在前端最流行的组件库代码里，只是你们天天用没注意而已。

3.2 SDK 对外 API 中的"边界模式"

如果你有机会写前端 SDK（比如埋点 SDK、IM SDK、直播 SDK），你会立刻理解设计模式在"接口设计"里的价值。对外发布的 API 必须稳定，但内部实现会频繁迭代——这种矛盾只有靠模式解决。

最常见的例子是 SDK 里的单例模式：埋点 SDK 只允许一个实例，所有页面共享同一个实例，上报队列、用户身份、配置信息都收敛在这个单例上。这个单例不能暴露全部内部方法，而要封装成发布订阅的模式：业务方on('event')订阅特定事件，SDK 内部有事件时emit出去。

SDK 对外发布版本时，经常要用到适配器模式来兼容老版本。老版本 API 不能删，新版本代码要重写，那就保留一层适配器，把新实现映射回老接口。这种场景写在文档里叫"兼容层""迁移层"，本质上就是适配器模式。理解了设计模式，你读 SDK 源码时不会再一头雾水，因为你能识别出里面的通用骨架。

3.3 组件库按需引入背后的工厂与动态加载

组件库的按需引入是个老话题。它的实现方式往往是：在入口文件中用工厂模式维护一个组件注册表，业务代码 import 到哪个组件，工厂才执行对应的 loader 去动态加载对应模块。表面上你在components.d.ts里声明了一堆组件，实际上每个组件的创建都走工厂。

从组件库的日常使用角度来说，工厂模式的意义不只是按需加载，还在于减少业务方的心智负担。比如表格分页、多选操作这些需求，业务方只需传入配置项（pagination、selection），组件内部用一个工厂函数根据配置"组装"出对应的功能模块。你用的时候只管传配置，复杂组装逻辑都被工厂消化掉了。这就是好的组件设计——把复杂留给内部，把简单留给外部，而设计模式正是帮组件库做到这件事的核心骨架。

4. 框架时代的设计模式新形态：从 HOC 到 Hooks 的演进

4.1 组合式函数/Hooks 本质上是"组合模式"的胜出

React 的 Hooks、Vue 3 的组合式函数（Composition API），本质上都在解决一件事：如何把可复用的逻辑从组件里拆出来，再自由组合回去。这个东西往设计模式上靠，就是组合模式和装饰器模式的融合版。

老的 React 里复用逻辑靠 HOC（高阶组件）和 render props，本质是给组件加装饰器。HOC 的问题在于：组件层级嵌套太深，查问题时要一层层剥洋葱，"包装地狱"名不虚传。Hooks 出现后，逻辑复用变成了平铺的组合式函数调用：

// 把"鼠标位置追踪"封装成 Hook function useMousePosition() { const [position, setPosition] = useState({ x: 0, y: 0 }); useEffect(() => { const handler = (e) => { setPosition({ x: e.clientX, y: e.clientY }); }; window.addEventListener('mousemove', handler); return () => window.removeEventListener('mousemove', handler); }, []); return position; } // 组件里直接用，逻辑可自由组合 function App() { const { x, y } = useMousePosition(); const [count, setCount] = useState(0); // ...业务逻辑 }

Hooks 的每个 Hook 都是独立单元，组件使用时自由组合，互不侵犯。这跟"抽象工厂""组合模式"的设计理念一脉相承：面向接口编程、组装优先于继承。前端框架从"继承式复用"（类组件）转向"组合式复用"（函数组件 + Hooks），本质上是把设计模式的组合思想发挥到了极致。

4.2 容器组件与展示组件：职责分离的模式化表达

还有一个前端特有的"模式"，叫容器组件/展示组件分离。容器组件负责数据获取、状态管理、业务逻辑；展示组件只负责渲染 UI，通过 props 接收数据、通过回调抛出事件。这其实是策略模式 + 适配器模式的组合在组件架构层面的落地。

比如一个用户信息卡片，展示组件长这样：

function UserCard({ user, onFollow, onMsg }) { return ( <div className="user-card"> <h3>{user.name}</h3> <p>{user.bio}</p> <button onClick={onFollow}>关注</button> <button onClick={onMsg}>私信</button> </div> ); }

它完全不知道怎么拿数据、不知道关注怎么调接口、不知道私信怎么开聊天窗口。容器组件负责接线：

function UserCardContainer({ userId }) { const [user, setUser] = useState(null); useEffect(() => { fetchUser(userId).then(setUser); }, [userId]); const handleFollow = useCallback(() => api.follow(userId), [userId]); return <UserCard user={user} onFollow={handleFollow} onMsg={() => openChat(userId)} />; }

职责一拆，展示组件就能在 Storybook 里独立开发调试，容器组件也能单独测试逻辑。这套思路放到 Vue 里同样成立：组件更复杂的逻辑可以抽到组合式函数里，模板只做数据展示事件绑定，两者解耦清晰。

4.3 现代框架依然保留着观察者模式的内核

Vue 的响应式系统、React 的状态更新机制，底层都离不开观察者模式。Vue 的ref、reactive就是被观察者，组件的渲染函数就是观察者，数据一变，依赖它的视图自动重新渲染。React 的useState的set触发重新渲染，本质也是观察者模式的应用。

理解这层联系的价值在于：别人使用框架停留在语法层面，你理解到观察者模式层面，遇到性能问题、渲染异常时，你分析问题的高度完全不同。比如 Vue 里经常遇到"数据变了但视图没更新"的问题，如果你的认知停在语法层，只会去查文档、找经验；如果你知道响应式系统是观察者机制，就会立刻想到"是不是新属性没被依赖收集"或者"是不是用到了不被代理的对象"，排查路径自然清晰起来。

5. 过度设计的代价：我不建议你用设计模式的场景们

5.1 为了模式而模式的典型翻车现场

我见过一个同事把简单的商品列表页写出了"抽象工厂 + 单例 + 观察者 + 代理"四层架构。他那套代码性能不差，但看起来极难维护：每个文件夹里都有index.ts做出口，每个组件创建都要经过工厂，每次渲染都要走代理。改一个小功能，先捋一遍调用链路，再找到对应的抽象层，最后才动手。抽象成本掩盖了实现成本，代码变得像个俄罗斯套娃——不仅仅是难懂，是即便懂了也极难改动。

别忘了，维护代码的成本大多数发生在改动时，而不是阅读时。过度抽象会让每一次改动都要跨越更多层，导致修改成本指数级上升。设计模式是解决问题的工具，不是炫技的勋章。如果你引入一个模式需要解释半天为什么这么写，那大概率是过度设计了。

5.2 判断一个模式是否该引入的三个问题

我实操中经常自问这三个问题，回答不上来就说明还没到引入模式的时候：

第一个问题：这个变化点是否真实存在？如果当前只有一个具体业务、未来也不清楚会不会有新形态，那这时候抽象就是空中楼阁。比如你的表单校验只有两个规则，如果硬套策略模式，多增加的策略表反而比直接写 if-else 更啰嗦。第二个问题：抽象后的接口是否稳定？策略表的 key 会不会经常变？工厂的类型参数是否足够收敛？如果抽象后的接口本身都在频繁变化，那你只是在移动复杂度而不是减少复杂度。第三个问题：团队里的人能否轻易理解？模式的价值之一是沟通效率，如果一个团队不熟悉观察者模式，你引入了事件总线，后续维护的人可能直接绕开它自己写 props 传参，那反而制造了"两个系统并行"的混乱。

我的态度是：模式是重构的结果，不是重构的起点。先写出简单清晰的代码，等功能确实出现了"变化点"，再重构引入模式。没有真实变化点时瞎套模式，就像给一岁的孩子买十年后才穿得下的衣服，既占地方，又自欺欺人。

5.3 三次法则：什么时候才值得提炼

我个人的经验是：同一个逻辑或结构出现第三次时，才值得提炼。第一次写是特定实现，第二次出现是巧合，第三次出现时，你基本能看清它的变异规律了，这时候抽象出来的东西才站得住脚。很多开发者的误区是第二次出现就急着抽象，结果抽象出来的"通用"结构跟第一个场景深度绑定，到了第三个场景时完全不通用，反而要推翻重来。

前端业务代码尤其要克制：业务变化频繁，你的抽象如果太早，很可能在未来版本里被淘汰。与其急着上设计模式，不如先保持代码简单、命名清楚、职责单一，等变化点自己浮出水面后再动手也不迟。

那是不是说前端不用学设计模式了？恰恰相反：正因为后端模式烂大街，前端在"怎么把模式用得恰到好处"上有更多探索空间。我的建议是——先理解每个模式的核心思想（它解决什么、代价是什么），再在组件库/SDK 或你熟悉的成熟代码里找到对应落地实例，最后才在自己的业务代码里谨慎使用。这样理论与实践相互印证，你才能真的做到"该用时信手拈来，不该用时克制得住"。

6. 面试官问设计模式，实际上是在问这四件事

6.1 面试官不关心你会背多少个模式

前端面试里问设计模式，最常见的场景是："说说你了解哪些设计模式？"或者"你在项目里用过设计模式吗？"很多候选人以为面试官在考记忆力，于是罗列十几个模式名，每个背一句定义，然后就没有然后了——这种回答基本拿不到分。

面试官真正想知道的其实是四件事：第一，你有没有识别代码结构问题的能力？面对一段混乱的业务逻辑，你能不能指出问题根源是"职责不清"、"条件过度耦合"这些结构性问题，而不是只抱怨"需求变太快"。第二，你有没有重构的勇气和方法？当一段代码刚出现坏味道，你是选择硬填逻辑继续堆，还是能明确提出用某个模式重构。第三，你选择的模式是不是真的恰当？业务场景和模式的匹配度，比模式本身的数量重要得多。第四，你是不是只会生搬硬套？面试官怕招进来一个把"策略模式"挂在嘴边的同事，写出来的代码却是用策略模式包装了一个三行函数的啰嗦怪。

6.2 一个让面试官眼前一亮的回答套路

我在面试别人时，比较吃一套回答结构：问题场景 → 失败方案 → 模式方案 → 代价反思。比如问"你怎么理解策略模式"，有经验的人会这样回答：

"我在做表单校验时碰到过一个问题。一开始我写了一个巨长的 validate 函数，里面全是 if-else，每个字段、每个规则都堆在一起。后来要加的新规则越来越多，每次改动都可能误伤已有规则，这是典型的变化点没有隔离。后来我把每个校验规则封装成独立函数，维护在一个策略表里，业务层只配规则名称和参数，新增规则时只需加一个策略，不用碰校验主流程。这其实就是策略模式。但我也清楚它的代价：如果规则只有两三条，直接 if-else 其实更清晰，策略表会显得小题大做。"

这段话为什么好？因为它完整呈现了一个工程师从发现问题到解决问题再到评估成本的完整思维链。面试官听到的不是记忆背诵，而是经过消化后的实战经验。背模式名谁都会，能把模式和真实业务对接、能说清代价边界的人，才值钱。

6.3 应对场景题的通用思路

现在前端面试还爱出场景设计题，比如"设计一个支持多种登录方式的表单"、"做一个支持多种图表类型的复杂组件"、"说下跨组件状态怎么设计"——这些题背后基本都是模式思维。

遇到这类题，建议你按这个思路回答：先问清楚需求规模和变化趋势（是固定两种类型还是可能无限扩展），再提出分层结构（具体类、工厂/策略层、业务调用层），然后分析模式的代价和替代方案。比如设计多种登录方式，你可以说：登录方式的差异点集中在"获取用户输入"和"调用不同接口"上，所以我会先定义统一的登录接口，每种方式一个实现类，用一个工厂根据登录类型创建对应的实现，这样新增一种登录方式时不需要改动登录主流程——这就是策略模式 + 工厂模式。同时也要说明：如果登录方式不超过两种且未来不会新增，那直接用 switch-case 更简单，没必要建那么多类。

这样回答既能展示你的设计能力，也体现你做决策的克制感。面试官最怕的不是你答错，而是你拿到一个问题就条件反射地堆设计模式，不问场景、不谈代价。