我之前给一个做跨境电商的朋友帮忙处理过一段让人特别心累的代码。当时系统里有各种各样的“数据导出”功能导出订单、导出库存、导出用户。我发现代码里全是重复的影子先查数据库再格式化数据最后生成文件。虽然导出的格式不同有的要 CSV有的要 Excel但头尾那 80% 的逻辑几乎一模一样。每次改个数据库连接池的配置我得把这三个导出函数全翻出来改一遍漏掉一个就是事故。我当时就跟同事复盘我们不应该在每个函数里都去重复那套“固定动作”。我们应该造一个“标准模具”把不变的流程焊死把会变的部分留出空位让不同的业务自己去填。这种定义一个算法的骨架而将一些步骤延迟到子类中实现的套路就是模板方法模式Template Method Pattern。为什么你的流程逻辑总是“改不动”先聊聊这个现象我们太习惯于写“一气呵成”的长函数了。你觉得写一个exportOrders很快写个exportUsers也不难。但换个角度想你其实是在不断地重复造轮子。说白了这种麻烦是因为你没有分清“流程”和“细节”。流程是稳定的比如校验 - 取数 - 转换 - 发送。细节是多变的比如怎么转换发给谁。如果你把这两者混在一起你的代码就会变得极其臃肿而且只要流程一变你就得去改几十个地方。点破真相真正的解耦是把“骨架”锁死把“血肉”交给具体业务去长。在 JS 里模板方法就是“高阶函数 钩子”在 Java 里你必须写个abstract class定一个final方法。但在 JavaScript 里我们有更灵动的玩法利用高阶函数或者带“钩子Hooks”的对象。咱们来看看怎么把那个乱成一团的“数据上传”流程理顺。// 0. 关键定义“标准模具”流程骨架// 这种写法最爽的地方在于流程是唯一的谁也别想乱改constbaseUploaderasync(config){const{validate,performUpload,notify}config;console.log(--- 启动标准上传流程 ---);// 1. 固定步骤校验每个上传都要做console.log(正在校验文件合法性...);if(!validate())returnconsole.log(❌ 校验失败);// 2. 变动步骤具体的上传动作// 换个角度想这里就是留给业务方的“填空题”awaitperformUpload();// 3. 固定步骤通知console.log(正在发送通知...);notify();console.log(--- 流程结束 ---);};// 1. 使用业务方只需要填空不需要管流程consts3Uploader()baseUploader({validate:()true,performUpload:async()console.log( 正在上传到 AWS S3...),notify:()console.log( 已发送邮件给管理员)});constlocalUploader()baseUploader({validate:()true,performUpload:async()console.log( 正在保存到本地硬盘...),notify:()console.log( 已弹出桌面通知)});// 2. 运行s3Uploader();换个角度想这种写法最舒服的地方在于…这种写法最爽的地方在于它建立了“秩序”。你想想如果你明天想在所有上传流程里加一个“压缩文件”的步骤。你只需要在baseUploader这个模具里加一行代码。所有的上传功能S3、本地、FTP都会瞬间自动获得这个能力。你完全不需要去动具体的业务逻辑。还有一个细节在现代前端框架里生命周期钩子如 Vue 的 mounted, React 的 useEffect本质上就是模板方法模式。框架定好了“组件渲染”的骨架它在特定的时刻喊你一下让你去填入自己的逻辑。两种写法的直观对比容易出问题的写法重复造轮子uploadToS3()和uploadToLocal()各自写一遍校验和通知。后果代码冗余严重。一旦流程要加个步骤你得满世界去找代码去改漏改一个就是坑。更稳健的模板方法写法baseProcess(specificSteps)后果核心流程被高度保护业务方想乱来都难。代码结构清晰得像流水线一眼就能看出哪些是共性的哪些是个性的。给你的 2 条行动建议识别“大同小异”的流程如果你发现两个函数的逻辑有 70% 以上是重合的只有中间一两行不一样别犹豫直接把那 70% 抽成模板。善用“默认钩子”在定义模板时可以给一些步骤提供默认实现。这样业务方如果没特殊需求连填空都不用填直接跑默认逻辑就行。我以前总觉得写个通用的模具有点费脑子不如直接复制粘贴快。后来才明白真正的专业是学会把“变动的细节”留给业务把“稳定的秩序”留给自己。模板方法模式就是给你的业务逻辑装上了一套“标准流水线”。