1. 别急着写封装先想清楚封装到底在解决什么问题vue 的封装大概是每个前端er工作两三年后都会开始琢磨的事。尤其是接手过一个维护了四五年的老项目你会非常深刻地感受到一件事代码里真正的隐患往往不是“写得烂”而是“写得太重复”。同一个弹窗在不同页面里有三套实现逻辑同一个接口请求配了五种错误提示方式同一个表格组件被复制粘贴了十几份每份还互相改得不一样。这时候第一反应就是必须封装。但是我也见过太多人死在了“封装”这两个字上。有的封装是把一堆props堆成一座山有的封装是抽了一个叫 utils 的目录然后往里面扔了三十个互相引用的模块有的封装是新建了一个 components 目录结果里面的东西全部只有自己在用。封装本身不是目的封装的目的是让“变化的东西”集中到一个地方管理让“不变的东西”对上层保持稳定。如果你把这个逻辑搞反了封装出来的东西只会比不封装更痛苦。这篇文章我想把这些年做 vue 封装的一些思考整理出来包括组件封装、接口与 hooks 封装、第三方能力比如地图和企业微信 SDK 的集成封装以及路由和跨端场景的封装边界。内容偏向实战尽量把“我为什么这么封装”的动机说清楚而不只是贴一段代码让你抄。1.1 复制粘贴才是封装最原始的驱动力很多教程会告诉你封装是为了复用、为了解耦、为了可维护性。这些都对但对大多数项目来说最真实的驱动力就是你发现一个结构在好几个页面里重复出现了而且每次复制过来都要改几个字段名改完之后还容易漏改。我记得两年前接手的一个后台管理系统里面有个“导入Excel并回显解析结果”的功能块前后出现了四次。前两次是不同模块各写各的已经出现了样式偏差第三次是同事从第二个模块复制过来改的结果把上一个模块的校验规则也带过去了第四次是我自己重构的时候发现实在没法在原有代码上继续补丁了才下定决心抽成一个组件。抽完之后那个组件的代码量大概是原来四份代码总和的五分之一后续新增导入需求只改了配置项没有再动主体结构。所以我的观点非常朴素如果你在项目里第三次写下同一段结构就应该开始考虑封装了。第一次第二次是正常的探索期因为你很可能还没搞明白这段代码哪些部分是真正通用的、哪些部分是业务特有的。过早封装是过度设计过晚封装是重复积累第三次是个比较合理的提醒点。1.2 “变化点分离”是判断封装价值的尺子封装的核心不是代码复用是变化点分离。这句话怎么理解呢你可以把一段逻辑拆成两部分一部分是每个场景里都一样的部分另一部分是每个场景里都可能变化的部分。封装要做的事情就是把“一样的部分”固定下来把“可能变化的部分”暴露成参数或者插槽。举个例子一个“状态标签”组件。如果所有业务模块里的订单状态标签都是背景色加文字的展示形态那这就是“一样的部分”。但状态枚举值每个模块不一样——订单模块是待支付、已支付、已发货审批模块是草稿、审批中、已通过——这是“变化的点”。那封装这个组件的时候就绝对不要把具体的状态枚举和颜色映射写死在组件内部而是通过一个 options 或者 map 配置传进去。组件内部只负责根据配置渲染颜色和文本。很多人封装失败问题就出在把“变化的点”和“不变的点”搞混了。比如有的封装会把某个业务模块里特有的“已作废状态要显示红色感叹号图标”这种特殊逻辑直接写进组件本体结果下一个模块用的时候发现没有这个状态又不好去掉只能加一个 props 来控制是否显示组件开始变得越来越重。这时候你会发现组件的 props 数量呈膨胀趋势那基本就是变化点分离没做干净。1.3 三个反问测出一个封装该不该做动手封装之前我习惯先用三个问题快速验证一下这个封装有没有必要做、怎么做才合理。第一个问题这个封装有多少个调用方只有一处调用的东西不要封装。你自己觉得“以后一定会用到”但“以后”经常不会来封装完的东西就没有被验证过等真正要用的时候大概率要大改。真实使用场景至少要两个以上最好是三个同时期的真实需求。第二个问题调用方之间的差异是什么如果两个场景的代码差异很大只是长得有点像那强行抽到一个组件里反而会让组件内部充满 if else。这种情况正确的做法是它们不应该共用一个组件而应该共享一个更底层的子组件然后各自包装一层。第三个问题封装之后调用方的代码是变简单了还是只是变短了有些封装是把复杂度从调用方挪到了组件内部但调用方写起来依然要传一堆参数只是从“写逻辑”变成了“传参”。这种封装对你个人来说可能是“代码少了”但对使用你封装的那个同事来说他并没有体会到便利。真正的封装应该是让调用方的代码可读性提升、心智负担降低而不仅仅是行数减少。这三个问题我每次做封装之前都会在脑子里过一遍尤其是第三个问题非常能拦住那种“为了封装而封装”的冲动。2. 组件级封装props、事件、插槽和 v-model 的取舍逻辑如果你已经决定要封装一个组件那接下来要面对的核心问题就是组件协议的设计。组件协议说白了就是这个组件对外暴露什么样的属性、事件、插槽和方法。协议设计得好不好直接决定了这个组件未来是越用越顺还是越改越烂。我见过的很多组件的失败都是从 props 失控开始的。定义组件的时候觉得这个配置项应该有、那个配置项也可能有人需要于是全开放出来结果 props 定义了几十个字段。调用方传参的时候就像在填写一张问卷组件内部的逻辑也变成了一堆 if else 判断“这个参数传了没有那个参数是不是默认值”。组件协议的设计原则其实很简单对外暴露的信息要足够做出决策但不要暴露内部实现细节。这句话听上去像废话但实际操作中你需要把它落得很具体。2.1 一张组件协议决定了这个组件的命运拿一个很常见的东西举例弹窗组件。很多项目的基础组件库里都有 el-dialog 的二次封装但封装水平参差不齐。差的封装会把 dialog 的 visible 布尔值、标题、宽度、是否可拖拽、是否显示关闭按钮、是否点击遮罩关闭、关闭后是否销毁内容全部暴露成 props然后调用方写这么一大串template my-dialog :visibledialogVisible title新增用户 width600px :draggablefalse :show-closetrue :close-on-click-modalfalse :destroy-on-closetrue update:visibledialogVisible $event confirmhandleConfirm / /template思路是没错但你会发现调用方要做的事和直接用 el-dialog 几乎没有区别只是换了个组件名而已。这种封装的本质是“换皮”并没有把弹窗这个场景里真正重复的东西收敛掉。更好一点的做法是弹窗组件自己管理一个“关闭确认”的逻辑。很多系统里弹窗右上角叉号和“取消”按钮的行为是有业务约束的比如表单没填完要提示比如保存中不允许关闭。如果这些逻辑每次都由调用方去处理那就等于没有封装。你可以在组件内部把“是否可以关闭”的规则收敛成几个配置项比如 :close-confirm、:loading组件内部自行处理确认提示和禁点状态外部只需要关心它的业务数据。这就是“变化点分离”在组件协议上的具体体现弹窗的视觉结构、遮罩行为、关闭逻辑是“通用的不变部分”业务内容通过插槽塞进去弹窗级别的特殊约束通过少数配置项暴露出来。通用底座越厚调用方越轻。2.2 自定义 v-model 让封装真正“像原生标签一样用”Vue 3 里组件的 v-model 支持了多值绑定之后封装体验有了质的提升。以前在 Vue 2 里一个组件要支持两个“双向绑定”状态通常得写 :value 和 change 这种配对或者拆成两个 .sync 修饰符。Vue 3 里直接可以在组件上写 v-model:visible 和 v-model:keyword子组件用 defineModel 接收体验和原生表单控件非常接近。这一点对于封装复杂组件特别重要。还是拿弹窗或抽屉举例最理想的使用体验应该是调用方只写一个 v-modeldialogVisible组件内部自己维护状态变化。要做到这一点子组件里必须处理好几个内部状态维度外部传进来的 state、内部临时保存的 draft比如编辑表单的草稿、以及关闭时是否要回滚 draft。如果你把这些状态全部摊在调用方手里调用方每次都要写一堆事件处理函数那就很难受。我在实际项目里常用的模式是子组件内部维护一个“提交中”的 loading 状态对外只暴露 v-model 控制的开关状态业务数据用 props 传入业务结果用事件抛回。调用方的代码看起来就是很单纯的一块template user-edit-dialog v-modelvisible :user-idcurrentUserId savedrefreshList / /template注意这里 user-id 是编辑场景下外层列表页必须传给弹窗的saved 事件是保存成功后外层需要刷新列表用的而“弹窗打开后去拉取用户详情、表单校验、提交请求、loading 控制”这些全部收敛在组件内部。对调用方来说它只需要知道“打开弹窗、传用户 id、等保存成功刷新列表”这三件事。2.3 插槽和透传什么时候留洞什么时候封死组件协议里最容易被忽略的是插槽设计和属性透传。很多封装组件的时候把展示区域设计得特别死内容全靠 props 传字符串或者对象等遇到一个稍微特殊点的场景就傻眼了只能改组件源码或者再加一个 props 开关。我习惯在封每个组件的时候都问自己一个问题这个区域内容以后可能会不会被调用方替换成自定义结构如果可能就留插槽。尤其是表格的列、弹窗的底部按钮区、列表的空状态这些区域尽量不要封死。同时弹窗底部按钮很多人会直接渲染固定文案但实际业务中“确认”按钮常常要做成 loading 状态、或者带个图标过滤器所以我的习惯是底部按钮区必须开放插槽并且提供默认的“取消/确认”按钮内容。属性透传指的是组件根节点可以自动接收父级传入的 class、style 以及原生属性。Vue 3 里默认开启了 attribute fallthrough但如果你组件根节点不止一个或者你手动关闭了 inheritAttrs那就要小心了。我在封装按钮型组件的时候一定要确保调用方能够直接给这个组件传 disabled、type 这类原生 button 属性否则调用方又得多绕一层。这里还要提一个经验插槽别开太多太碎。有些组件会让你传什么 header-left、header-right、header-center、footer-left、footer-right……听上去很灵活实际上调用方维护十个插槽名比维护三个 props 还累。插槽的数量应该控制在“业务内容的自然分区”数量级一般是 1~3 个超过五个就要反思是不是组件颗粒度切错了。2.4 写在组件前面的话先观察两三个真实使用场景再动手我在 1.1 里说过第三次重复提醒你可以封装了这里再补一条实操上的规矩封一个通用组件之前先收集两三个真实使用场景而且尽量是来自不同业务模块的场景。只有单一场景撑出来的组件设计出来的协议一定是片面的因为你会不自觉地把你第一个使用场景里的业务别扭当成通用需求。我做过一个“字典翻译”组件的封装。第一个使用场景是订单状态只有两种状态我还专门为它设计了一个“状态带颜色点”的渲染模式。后来用户管理模块也要用它有四种状态而且状态和颜色对应的规则完全不一样。幸好当时我把状态映射抽成了 options 配置而不是写死在组件里才算没有翻车。如果当时只有订单一个场景就急着把“颜色点”做成 props 默认值后面一定会很尴尬。组件封装建议分三步走第一步先写一个不封装的实现把业务跑通第二步整理两份重复度高的代码抽出公共部分第三步再以这两份为依据设计协议同时多看一层未来的扩展空间。三步走完这个组件大概率是能用的而且不会过度设计。3. 接口与逻辑封装请求层、hooks 与“不过度设计”的平衡组件封装只是 vue 封装的一半另一半是逻辑封装。很多项目里组件长得挺清爽但页面里的 script 部分一大坨接口请求、状态管理、loading 判断、错误处理、数据映射全堆在一起。这类页面的可维护性其实比组件设计糟糕更致命因为逻辑是最容易产生隐藏 bug 的地方。逻辑封装一般分三层底层是请求层封装解决的是“怎么发请求”的统一问题中间层是接口定义解决的是“每个接口的入参出参类型”和“调用方式”的问题上层是业务 hooks解决的是“一个页面场景下的数据流转”问题。这三层一个都不能乱。3.1 请求封装的核心不是封装 axios而是定义错误处理协议很多人一提到接口封装第一反应就是封装 axios 实例设置 baseURL、拦截器、超时时间然后导出 get 和 post 方法。这当然是对的但如果你只是做到这一步那只能叫“配置 axios”离封装还有一段距离。真正要走封装你需要在拦截器层定义一套全项目统一的错误处理协议。这个协议至少包括三件事HTTP 层错误怎么处理、业务码层错误怎么处理、网络异常怎么处理。我见过的比较合理的做法是响应拦截器里统一做一次状态判断如果 HTTP 状态码不是 2xx 或者业务返回码不是约定的成功码拦截器统一弹一个轻提示并且把错误信息结构化之后 reject 出去。调用方只有在确实需要特殊处理某个错误时才在 catch 里做额外逻辑。不需要每个页面都写一遍错误提示也不需要每写一个请求就担心“这个接口失败了怎么办”。这里有个细节非常容易踩坑不要把所有错误都吞掉。有些团队为了省事在拦截器里把错误统一提示完之后直接 return 一个空对象导致调用方不知道自己拿到的数据是空数组还是请求失败。我建议在拦截器里对错误做分类标记比如自定义一个 ErrorCode调用方在 catch 里可以通过错误的 code 字段决定要不要做额外处理。默认弹提示、默认不崩溃但要给调用方留出“我知道失败了”的通道。3.2 业务 hooks把接口、状态、计算属性一起抽走到 Vue 3 组合式 API 的时代逻辑封装最舒服的单位不是 mixin也不是高阶组件而是函数——准确说是组合式函数也就是 hooks。hooks 的好处是它可以把接口请求、响应式状态、计算属性、事件处理全部打包成一个独立单元不同页面可以像装零件一样组合它们。一个很经典的 hooks 案例是分页列表的封装。如果你的项目里大量页面都是“表格加搜索条件加分页”的结构那差不多每个页面都要维护 page、pageSize、total、loading、list 这一组状态以及请求列表、重置查询、切换页码这一组方法。这些东西如果抽象成一个 usePageList hooks可以把页面 script 部分的几十行浓缩成几行const { list, total, loading, page, pageSize, search, reset, refresh } usePageList( fetchUserList, { status: active } );注意这里 fetchUserList 是一个入参它只是“返回 Promise 的普通函数”并不关心你内部用的什么请求方式。这就是 hooks 和请求层之间的正确关系hooks 不依赖请求封装它只要求你传一个 Promise 函数。hooks 封装的难点在于“度”的把握。分页列表是很标准的场景抽取成本低收益高。但如果你试图把一个表单页的整套逻辑也抽成一个巨型 hooks那反而会让复用变得困难因为每个表单页的校验规则和数据转换都不太一样。我的经验是优先抽“流程类”的 hooks比如表单提交前的校验流程、文件上传前的预处理流程、分页查询流程不要优先抽“状态类”的 hooks除非你确信这几个状态确实在多个页面间以完全相同的形态出现。3.3 用“编排”替代“继承”去复用请求流程接触过后端开发的读者应该对“继承”这个词很敏感。前端有一些写法本质上是想用继承的思路做复用比如搞一个 BasePage 基类组件里面写好 list 逻辑然后子页面 extends 它。这在 Vue 2 的选项式 API 时代还挺常见但到 Vue 3 里我基本上不推荐这种写法了因为它太脆。基类组件有一个很大的问题它把数据的获取逻辑封装在了子类看不到的地方子类想在某个环节插入额外处理往往得靠重写整个方法。一旦有个别业务需要“不走基类的列表逻辑”你就得绕很大一圈。hooks 的组合思维就不一样它更像是编排你把一个能力拆成多个小的 hooks然后在页面里按需调用。比如某个页面既要分页列表又要处理批量导入的进度那就分别调用 usePageList 和 useImportProgress谁都不影响谁。封装不再是一个从上到下的继承树而是一堆你按需拼装的积木。这种思维方式的转变是我觉得 Vue 3 时代封装最重要的变化之一。如果你还在用 mixins 或者继承式的写法复用逻辑我非常建议你试着把一个 mixin 拆成几个 hooks你会发现心智负担明显降下来。4. 集成型封装企业微信 SDK、地图与路由这类“全局外挂”怎么设计做 vue 项目久了你会发现真正让项目显得“稳”的封装往往不是业务组件而是那些和外部世界打交道的集成层封装。你可能会接到在 vue 项目里通过企业微信 JS-SDK 调起选择通讯录人员的需求也可能会遇到在后台系统里集成腾讯地图的需求还可能会遇到项目工程里需要按权限动态挂载路由表的需求。这些场景每一个都是整套项目里“牵一发动全身”的地方封装得好不好直接决定了后续迭代痛不痛。很多人在这个位置会犯的错误是把第三方 SDK 的能力直接放在业务页面里调用每个页面都要重新初始化一遍 SDK每个接入点都要处理一遍“SDK 未加载完成”的边界情况。这种代码能跑但你会反复写同样的初始化模板、同样的失败提示、同样的兼容判断。4.1 把第三方 SDK 包成“不换皮不换骨”的稳定接口以企业微信 JS-SDK 为例一个典型的接入流程是引入 SDK 脚本、通过 config 接口注入权限校验配置、在 ready 回调里调用具体 JS 接口、通过 error 回调处理鉴权失败。这套流程如果在每个页面里都写一遍你就会遇到很多问题config 是异步接口你无法保证调用具体接口时已经 ready 了同一用户在同一时间可能打开多个页面每个页面都重复注册一次 config权限签名过期后要不要自动重新注入这个问题每个页面各自处理的话很容易乱。我当时做这一类封装的思路是写一个模块单独负责 SDK 的加载和初始化内部维护一个 readyPromise。外部任何业务模块调用它提供的接口时模块内部先 await readyPromise再调原生的 SDK 方法。这样业务方永远不需要关心“SDK 到底初始化好了没有”这件事。如果 config 过期导致某个接口调用失败模块统一做一次重新初始化重试业务方拿到的结果始终是一个标准 Promise失败原因也统一用错误码表达。类似的思路也适用于地图类 SDK、音视频类 SDK。这类 SDK 的共同点是有异步加载过程、有环境限制需要域名白名单、需要鉴权、有原生事件回调。封装它们的时候核心工作不是“包一层好用的 API”而是把异步准备流程和鉴权流程收敛成一个幂等的初始化过程。封装第三方 SDK 时还有一个容易忽略的点版本变化。比如企业微信 JS-SDK 不同版本之间有些方法名和行为有差异我的习惯是在封装模块里用常量集中管理“当前依赖的 SDK 最低版本”和“SDK 内部接口映射表”这样升级 SDK 的时候只需要改一个文件的映射关系不需要到所有业务页面里找。4.2 路由层面的封装动态路由和权限不是一回事vue-router 的动态路由是另一个极容易做乱的封装点。很多项目从后端拿到菜单权限之后需要动态注册路由表。这个流程看起来简单但有几个细节很折磨人路由组件是 import.meta.glob 批量加载还是逐个 import404 路由怎么处理才不会因为动态添加路由导致匹配错乱刷新页面后已经 addRoute 的路由还在不在退出登录时怎么把动态加的路由全部移除掉。我在项目里的做法是维护一个路由配置生成的纯函数把静态路由和动态路由分开管理。静态路由包含登录页、404 页、无权限页这类固定入口动态路由由一个函数根据权限列表生成每个路由项的 component 字段通过 import.meta.glob 按路径映射到实际组件文件。这一层封装的价值在于权限数据和路由数据是两回事。路由是结构性的它有层级关系权限是集合性的它只是一个 key 列表。转换这份结构的过程集中在一个位置后续不管是调整权限菜单还是调整页面结构都不会牵动全局。这里还有一个容易踩的坑动态 addRoute 的路由在菜单刷新后不会自动恢复必须在应用启动阶段重新走一遍权限获取和动态注册流程。很多人封装路由时忽略了“刷新恢复”这个场景结果用户登录后一切正常一刷新页面就空白。我在封装时会把“initRouter”这个函数做得足够幂等无论在首次登录、页面刷新、还是切换账号后调用它都能保证把目标用户的路由表重置成正确形态。4.3 全局组件的边界注册简单管理难前面说的大部分是逻辑封装再说一个轻轻松松就会做过的全局组件封装。很多项目会在 main.js 里 app.component() 注册一批全局组件图省事。但全局组件一旦多了会带来两个问题一是首包的体积很难控制因为你一旦全局注册了所有页面都会带上它二是组件之间的隐式依赖增多你不知道某个页面用到的按钮组件是不是全局注册的那个版本。我的建议是全局注册只保留那些“几乎每个页面都会用到、且形态极其稳定”的组件比如基础图标按钮、空状态占位、页面容器。业务型组件哪怕用得很频繁也尽量改成按需导入或者按目录批量注册不要一股脑全 global。如果你用的是 uniapp 或者跨端框架这个原则更要重视因为跨端的全局组件注册往往会影响各端的 bundle 策略。另外一个容易忽略的是弹窗类组件的全局挂载方式。很多组件库会提供命令式调用比如 this.$modal.confirm()很多开发者会基于自己的业务场景再封装一层命令式弹窗。我的建议是命令式弹窗适合“提示、确认”这类轻交互不适合承载复杂表单。复杂表单建议还是用组件内使用插槽的方式因为命令式调用时外部很难通过插槽向弹窗内部传递复杂模板只能靠 h 函数拼写起来很痛苦。5. 封装里最容易踩的四个坑和我的补救方案讲了这么多封装的正向思路最后集中聊聊我在一线项目里踩过的坑。这些坑每一个都真实改变了我对封装的认知也直接让我形成了前面那些设计原则。5.1 过度抽象为了复用而复用反而没人敢动第一个坑是我自己亲手刨的。有一段时间我痴迷于“抽象”总觉得代码不够抽象就不够优雅。我曾经把一个“表单页”抽象成了三层底层是通用动态表单渲染组件、中间是表单 schema 约定、上层是具体业务页。听起来很漂亮但实际用起来非常痛苦。业务页为了满足某个特殊字段的校验不得不在 schema 里塞各种自定义 render 函数而这些 render 函数比直接写一个表单页面还难维护。最后那个项目维护成本居高不下新同事接手时根本不敢改动动态表单的核心渲染逻辑。这次经历让我彻底接受了“适度抽象”这个词。抽象的价值必须由真实使用场景来验证而不是靠设计美感来判断。如果一个抽象的收益在当下是模糊的就不要做。现在我的习惯是一个封装的调用方写起来的代码量如果比不封装时只减少 30% 不到这个封装就不值得做。5.2 为了传参而传参props 层层透传有多痛第二个坑是 props 的层层透传。封装了一个列表组件列表组件内部又拆了搜索区域组件、表格组件、分页组件然后业务层为了控制搜索区域的某个默认值就需要把 props 从业务层传到列表组件再从列表组件传到搜索区域组件。中途还要通过事件从搜索区域传回列表组件再传回业务层。这样一个流程下来你改一个搜索条件的中文 label 都要动三个文件。后来我的补救方案是把搜索区域和表格的分页状态放在同一个组合式函数里由 usePageList 这类 hooks 管理组件树里只留一层“数据入口”。搜索条件、分页信息、列表结果全部由这个 hooks 暴露出来子组件和父组件都从同一份状态读取谁需要谁拿。这样透传问题就自然消失了因为大家读的是同一个响应式状态而不是靠 props 层层传递。5.3 生命周期判断失误封装内部自己拿数据还是外部传第三个坑比较隐蔽是“数据到底由谁获取”的问题。很多组件封装的初衷是“我打开这个弹窗它自己就把详情数据拉好”。这种封装体验确实好调用方很省事。但等你遇到一个场景弹窗还没打开外层列表已经提前知道了详情数据、希望能直接传给弹窗省一个请求的时候矛盾就出现了。组件内部自己拉数据的方案不利于这种复用因为你没法跳过它的内部请求。后来我的做法是组件的数据获取逻辑统一抽象成“外部传入数据源函数 内部缓存策略”。组件暴露一个 fetch-detail 属性调用方传入一个返回 Promise 的函数组件内部在打开时调用这个函数去拉数据。如果调用方已经有现成数据它可以传一个直接把现有数据 resolve 的函数或者干脆通过 props 传 initial-data组件内部协调“已有数据优先函数拉取兜底”。这个方案比“组件内部写死请求地址”要灵活得多。封装最忌讳把数据来源写死因为你永远不知道下一个使用场景的数据长在哪里。5.4 跨端复用的误会uniapp、electron 和小程序的封装差别第四个坑是从 vue 项目走向跨端场景时的认知偏差。很多人觉得“我在 vue 里封装了组件uniapp 里也能差不多用”。实际不是这样。uniapp 里组件运行的宿主是多端的不同端对事件、样式、原生能力支持的差异比想象中大。一个 vue 项目里封装好的地图组件拿到 uniapp 里可能在小程序端表现正常、在 App 端样式错乱、在 H5 端又是另外一套行为。做跨端封装的时候你必须按“端”做条件编译分支封装的目标也变成“统一业务接口”而不是“统一实现细节”。类似的还有 electron 和 vue 的结合。electron 里有主进程和渲染进程主进程负责系统能力渲染进程负责 UI。你把 vue 页面里的逻辑直接搬到渲染进程没问题但如果有访问文件系统、调用系统对话框这类能力就需要通过 IPC 走主进程。封装的时候我通常会把“渲染进程调用主进程能力”再包一层统一的 ipc 接口层让业务页面不需要感知 ipc 通道的名称和参数结构。跨端场景下的封装真正要统一的不是“代码”而是“语义”。理解到这一层之后我就不会再拿着 vue web 项目的封装方案无脑套到 uniapp 或 electron 上了。最后再分享一个经验封装这件事永远不要想着一口气做到完美。所有好的封装几乎都是从一个临时实现里被逼出来的。先让它跑起来跑到第三遍重复的时候再动手抽抽的时候脚踏实地多看看真实调用方的代码你就会发现自己对“封装”的理解会越来越实在。
1. 别急着写封装先想清楚封装到底在解决什么问题vue 的封装大概是每个前端er工作两三年后都会开始琢磨的事。尤其是接手过一个维护了四五年的老项目你会非常深刻地感受到一件事代码里真正的隐患往往不是“写得烂”而是“写得太重复”。同一个弹窗在不同页面里有三套实现逻辑同一个接口请求配了五种错误提示方式同一个表格组件被复制粘贴了十几份每份还互相改得不一样。这时候第一反应就是必须封装。但是我也见过太多人死在了“封装”这两个字上。有的封装是把一堆props堆成一座山有的封装是抽了一个叫 utils 的目录然后往里面扔了三十个互相引用的模块有的封装是新建了一个 components 目录结果里面的东西全部只有自己在用。封装本身不是目的封装的目的是让“变化的东西”集中到一个地方管理让“不变的东西”对上层保持稳定。如果你把这个逻辑搞反了封装出来的东西只会比不封装更痛苦。这篇文章我想把这些年做 vue 封装的一些思考整理出来包括组件封装、接口与 hooks 封装、第三方能力比如地图和企业微信 SDK 的集成封装以及路由和跨端场景的封装边界。内容偏向实战尽量把“我为什么这么封装”的动机说清楚而不只是贴一段代码让你抄。1.1 复制粘贴才是封装最原始的驱动力很多教程会告诉你封装是为了复用、为了解耦、为了可维护性。这些都对但对大多数项目来说最真实的驱动力就是你发现一个结构在好几个页面里重复出现了而且每次复制过来都要改几个字段名改完之后还容易漏改。我记得两年前接手的一个后台管理系统里面有个“导入Excel并回显解析结果”的功能块前后出现了四次。前两次是不同模块各写各的已经出现了样式偏差第三次是同事从第二个模块复制过来改的结果把上一个模块的校验规则也带过去了第四次是我自己重构的时候发现实在没法在原有代码上继续补丁了才下定决心抽成一个组件。抽完之后那个组件的代码量大概是原来四份代码总和的五分之一后续新增导入需求只改了配置项没有再动主体结构。所以我的观点非常朴素如果你在项目里第三次写下同一段结构就应该开始考虑封装了。第一次第二次是正常的探索期因为你很可能还没搞明白这段代码哪些部分是真正通用的、哪些部分是业务特有的。过早封装是过度设计过晚封装是重复积累第三次是个比较合理的提醒点。1.2 “变化点分离”是判断封装价值的尺子封装的核心不是代码复用是变化点分离。这句话怎么理解呢你可以把一段逻辑拆成两部分一部分是每个场景里都一样的部分另一部分是每个场景里都可能变化的部分。封装要做的事情就是把“一样的部分”固定下来把“可能变化的部分”暴露成参数或者插槽。举个例子一个“状态标签”组件。如果所有业务模块里的订单状态标签都是背景色加文字的展示形态那这就是“一样的部分”。但状态枚举值每个模块不一样——订单模块是待支付、已支付、已发货审批模块是草稿、审批中、已通过——这是“变化的点”。那封装这个组件的时候就绝对不要把具体的状态枚举和颜色映射写死在组件内部而是通过一个 options 或者 map 配置传进去。组件内部只负责根据配置渲染颜色和文本。很多人封装失败问题就出在把“变化的点”和“不变的点”搞混了。比如有的封装会把某个业务模块里特有的“已作废状态要显示红色感叹号图标”这种特殊逻辑直接写进组件本体结果下一个模块用的时候发现没有这个状态又不好去掉只能加一个 props 来控制是否显示组件开始变得越来越重。这时候你会发现组件的 props 数量呈膨胀趋势那基本就是变化点分离没做干净。1.3 三个反问测出一个封装该不该做动手封装之前我习惯先用三个问题快速验证一下这个封装有没有必要做、怎么做才合理。第一个问题这个封装有多少个调用方只有一处调用的东西不要封装。你自己觉得“以后一定会用到”但“以后”经常不会来封装完的东西就没有被验证过等真正要用的时候大概率要大改。真实使用场景至少要两个以上最好是三个同时期的真实需求。第二个问题调用方之间的差异是什么如果两个场景的代码差异很大只是长得有点像那强行抽到一个组件里反而会让组件内部充满 if else。这种情况正确的做法是它们不应该共用一个组件而应该共享一个更底层的子组件然后各自包装一层。第三个问题封装之后调用方的代码是变简单了还是只是变短了有些封装是把复杂度从调用方挪到了组件内部但调用方写起来依然要传一堆参数只是从“写逻辑”变成了“传参”。这种封装对你个人来说可能是“代码少了”但对使用你封装的那个同事来说他并没有体会到便利。真正的封装应该是让调用方的代码可读性提升、心智负担降低而不仅仅是行数减少。这三个问题我每次做封装之前都会在脑子里过一遍尤其是第三个问题非常能拦住那种“为了封装而封装”的冲动。2. 组件级封装props、事件、插槽和 v-model 的取舍逻辑如果你已经决定要封装一个组件那接下来要面对的核心问题就是组件协议的设计。组件协议说白了就是这个组件对外暴露什么样的属性、事件、插槽和方法。协议设计得好不好直接决定了这个组件未来是越用越顺还是越改越烂。我见过的很多组件的失败都是从 props 失控开始的。定义组件的时候觉得这个配置项应该有、那个配置项也可能有人需要于是全开放出来结果 props 定义了几十个字段。调用方传参的时候就像在填写一张问卷组件内部的逻辑也变成了一堆 if else 判断“这个参数传了没有那个参数是不是默认值”。组件协议的设计原则其实很简单对外暴露的信息要足够做出决策但不要暴露内部实现细节。这句话听上去像废话但实际操作中你需要把它落得很具体。2.1 一张组件协议决定了这个组件的命运拿一个很常见的东西举例弹窗组件。很多项目的基础组件库里都有 el-dialog 的二次封装但封装水平参差不齐。差的封装会把 dialog 的 visible 布尔值、标题、宽度、是否可拖拽、是否显示关闭按钮、是否点击遮罩关闭、关闭后是否销毁内容全部暴露成 props然后调用方写这么一大串template my-dialog :visibledialogVisible title新增用户 width600px :draggablefalse :show-closetrue :close-on-click-modalfalse :destroy-on-closetrue update:visibledialogVisible $event confirmhandleConfirm / /template思路是没错但你会发现调用方要做的事和直接用 el-dialog 几乎没有区别只是换了个组件名而已。这种封装的本质是“换皮”并没有把弹窗这个场景里真正重复的东西收敛掉。更好一点的做法是弹窗组件自己管理一个“关闭确认”的逻辑。很多系统里弹窗右上角叉号和“取消”按钮的行为是有业务约束的比如表单没填完要提示比如保存中不允许关闭。如果这些逻辑每次都由调用方去处理那就等于没有封装。你可以在组件内部把“是否可以关闭”的规则收敛成几个配置项比如 :close-confirm、:loading组件内部自行处理确认提示和禁点状态外部只需要关心它的业务数据。这就是“变化点分离”在组件协议上的具体体现弹窗的视觉结构、遮罩行为、关闭逻辑是“通用的不变部分”业务内容通过插槽塞进去弹窗级别的特殊约束通过少数配置项暴露出来。通用底座越厚调用方越轻。2.2 自定义 v-model 让封装真正“像原生标签一样用”Vue 3 里组件的 v-model 支持了多值绑定之后封装体验有了质的提升。以前在 Vue 2 里一个组件要支持两个“双向绑定”状态通常得写 :value 和 change 这种配对或者拆成两个 .sync 修饰符。Vue 3 里直接可以在组件上写 v-model:visible 和 v-model:keyword子组件用 defineModel 接收体验和原生表单控件非常接近。这一点对于封装复杂组件特别重要。还是拿弹窗或抽屉举例最理想的使用体验应该是调用方只写一个 v-modeldialogVisible组件内部自己维护状态变化。要做到这一点子组件里必须处理好几个内部状态维度外部传进来的 state、内部临时保存的 draft比如编辑表单的草稿、以及关闭时是否要回滚 draft。如果你把这些状态全部摊在调用方手里调用方每次都要写一堆事件处理函数那就很难受。我在实际项目里常用的模式是子组件内部维护一个“提交中”的 loading 状态对外只暴露 v-model 控制的开关状态业务数据用 props 传入业务结果用事件抛回。调用方的代码看起来就是很单纯的一块template user-edit-dialog v-modelvisible :user-idcurrentUserId savedrefreshList / /template注意这里 user-id 是编辑场景下外层列表页必须传给弹窗的saved 事件是保存成功后外层需要刷新列表用的而“弹窗打开后去拉取用户详情、表单校验、提交请求、loading 控制”这些全部收敛在组件内部。对调用方来说它只需要知道“打开弹窗、传用户 id、等保存成功刷新列表”这三件事。2.3 插槽和透传什么时候留洞什么时候封死组件协议里最容易被忽略的是插槽设计和属性透传。很多封装组件的时候把展示区域设计得特别死内容全靠 props 传字符串或者对象等遇到一个稍微特殊点的场景就傻眼了只能改组件源码或者再加一个 props 开关。我习惯在封每个组件的时候都问自己一个问题这个区域内容以后可能会不会被调用方替换成自定义结构如果可能就留插槽。尤其是表格的列、弹窗的底部按钮区、列表的空状态这些区域尽量不要封死。同时弹窗底部按钮很多人会直接渲染固定文案但实际业务中“确认”按钮常常要做成 loading 状态、或者带个图标过滤器所以我的习惯是底部按钮区必须开放插槽并且提供默认的“取消/确认”按钮内容。属性透传指的是组件根节点可以自动接收父级传入的 class、style 以及原生属性。Vue 3 里默认开启了 attribute fallthrough但如果你组件根节点不止一个或者你手动关闭了 inheritAttrs那就要小心了。我在封装按钮型组件的时候一定要确保调用方能够直接给这个组件传 disabled、type 这类原生 button 属性否则调用方又得多绕一层。这里还要提一个经验插槽别开太多太碎。有些组件会让你传什么 header-left、header-right、header-center、footer-left、footer-right……听上去很灵活实际上调用方维护十个插槽名比维护三个 props 还累。插槽的数量应该控制在“业务内容的自然分区”数量级一般是 1~3 个超过五个就要反思是不是组件颗粒度切错了。2.4 写在组件前面的话先观察两三个真实使用场景再动手我在 1.1 里说过第三次重复提醒你可以封装了这里再补一条实操上的规矩封一个通用组件之前先收集两三个真实使用场景而且尽量是来自不同业务模块的场景。只有单一场景撑出来的组件设计出来的协议一定是片面的因为你会不自觉地把你第一个使用场景里的业务别扭当成通用需求。我做过一个“字典翻译”组件的封装。第一个使用场景是订单状态只有两种状态我还专门为它设计了一个“状态带颜色点”的渲染模式。后来用户管理模块也要用它有四种状态而且状态和颜色对应的规则完全不一样。幸好当时我把状态映射抽成了 options 配置而不是写死在组件里才算没有翻车。如果当时只有订单一个场景就急着把“颜色点”做成 props 默认值后面一定会很尴尬。组件封装建议分三步走第一步先写一个不封装的实现把业务跑通第二步整理两份重复度高的代码抽出公共部分第三步再以这两份为依据设计协议同时多看一层未来的扩展空间。三步走完这个组件大概率是能用的而且不会过度设计。3. 接口与逻辑封装请求层、hooks 与“不过度设计”的平衡组件封装只是 vue 封装的一半另一半是逻辑封装。很多项目里组件长得挺清爽但页面里的 script 部分一大坨接口请求、状态管理、loading 判断、错误处理、数据映射全堆在一起。这类页面的可维护性其实比组件设计糟糕更致命因为逻辑是最容易产生隐藏 bug 的地方。逻辑封装一般分三层底层是请求层封装解决的是“怎么发请求”的统一问题中间层是接口定义解决的是“每个接口的入参出参类型”和“调用方式”的问题上层是业务 hooks解决的是“一个页面场景下的数据流转”问题。这三层一个都不能乱。3.1 请求封装的核心不是封装 axios而是定义错误处理协议很多人一提到接口封装第一反应就是封装 axios 实例设置 baseURL、拦截器、超时时间然后导出 get 和 post 方法。这当然是对的但如果你只是做到这一步那只能叫“配置 axios”离封装还有一段距离。真正要走封装你需要在拦截器层定义一套全项目统一的错误处理协议。这个协议至少包括三件事HTTP 层错误怎么处理、业务码层错误怎么处理、网络异常怎么处理。我见过的比较合理的做法是响应拦截器里统一做一次状态判断如果 HTTP 状态码不是 2xx 或者业务返回码不是约定的成功码拦截器统一弹一个轻提示并且把错误信息结构化之后 reject 出去。调用方只有在确实需要特殊处理某个错误时才在 catch 里做额外逻辑。不需要每个页面都写一遍错误提示也不需要每写一个请求就担心“这个接口失败了怎么办”。这里有个细节非常容易踩坑不要把所有错误都吞掉。有些团队为了省事在拦截器里把错误统一提示完之后直接 return 一个空对象导致调用方不知道自己拿到的数据是空数组还是请求失败。我建议在拦截器里对错误做分类标记比如自定义一个 ErrorCode调用方在 catch 里可以通过错误的 code 字段决定要不要做额外处理。默认弹提示、默认不崩溃但要给调用方留出“我知道失败了”的通道。3.2 业务 hooks把接口、状态、计算属性一起抽走到 Vue 3 组合式 API 的时代逻辑封装最舒服的单位不是 mixin也不是高阶组件而是函数——准确说是组合式函数也就是 hooks。hooks 的好处是它可以把接口请求、响应式状态、计算属性、事件处理全部打包成一个独立单元不同页面可以像装零件一样组合它们。一个很经典的 hooks 案例是分页列表的封装。如果你的项目里大量页面都是“表格加搜索条件加分页”的结构那差不多每个页面都要维护 page、pageSize、total、loading、list 这一组状态以及请求列表、重置查询、切换页码这一组方法。这些东西如果抽象成一个 usePageList hooks可以把页面 script 部分的几十行浓缩成几行const { list, total, loading, page, pageSize, search, reset, refresh } usePageList( fetchUserList, { status: active } );注意这里 fetchUserList 是一个入参它只是“返回 Promise 的普通函数”并不关心你内部用的什么请求方式。这就是 hooks 和请求层之间的正确关系hooks 不依赖请求封装它只要求你传一个 Promise 函数。hooks 封装的难点在于“度”的把握。分页列表是很标准的场景抽取成本低收益高。但如果你试图把一个表单页的整套逻辑也抽成一个巨型 hooks那反而会让复用变得困难因为每个表单页的校验规则和数据转换都不太一样。我的经验是优先抽“流程类”的 hooks比如表单提交前的校验流程、文件上传前的预处理流程、分页查询流程不要优先抽“状态类”的 hooks除非你确信这几个状态确实在多个页面间以完全相同的形态出现。3.3 用“编排”替代“继承”去复用请求流程接触过后端开发的读者应该对“继承”这个词很敏感。前端有一些写法本质上是想用继承的思路做复用比如搞一个 BasePage 基类组件里面写好 list 逻辑然后子页面 extends 它。这在 Vue 2 的选项式 API 时代还挺常见但到 Vue 3 里我基本上不推荐这种写法了因为它太脆。基类组件有一个很大的问题它把数据的获取逻辑封装在了子类看不到的地方子类想在某个环节插入额外处理往往得靠重写整个方法。一旦有个别业务需要“不走基类的列表逻辑”你就得绕很大一圈。hooks 的组合思维就不一样它更像是编排你把一个能力拆成多个小的 hooks然后在页面里按需调用。比如某个页面既要分页列表又要处理批量导入的进度那就分别调用 usePageList 和 useImportProgress谁都不影响谁。封装不再是一个从上到下的继承树而是一堆你按需拼装的积木。这种思维方式的转变是我觉得 Vue 3 时代封装最重要的变化之一。如果你还在用 mixins 或者继承式的写法复用逻辑我非常建议你试着把一个 mixin 拆成几个 hooks你会发现心智负担明显降下来。4. 集成型封装企业微信 SDK、地图与路由这类“全局外挂”怎么设计做 vue 项目久了你会发现真正让项目显得“稳”的封装往往不是业务组件而是那些和外部世界打交道的集成层封装。你可能会接到在 vue 项目里通过企业微信 JS-SDK 调起选择通讯录人员的需求也可能会遇到在后台系统里集成腾讯地图的需求还可能会遇到项目工程里需要按权限动态挂载路由表的需求。这些场景每一个都是整套项目里“牵一发动全身”的地方封装得好不好直接决定了后续迭代痛不痛。很多人在这个位置会犯的错误是把第三方 SDK 的能力直接放在业务页面里调用每个页面都要重新初始化一遍 SDK每个接入点都要处理一遍“SDK 未加载完成”的边界情况。这种代码能跑但你会反复写同样的初始化模板、同样的失败提示、同样的兼容判断。4.1 把第三方 SDK 包成“不换皮不换骨”的稳定接口以企业微信 JS-SDK 为例一个典型的接入流程是引入 SDK 脚本、通过 config 接口注入权限校验配置、在 ready 回调里调用具体 JS 接口、通过 error 回调处理鉴权失败。这套流程如果在每个页面里都写一遍你就会遇到很多问题config 是异步接口你无法保证调用具体接口时已经 ready 了同一用户在同一时间可能打开多个页面每个页面都重复注册一次 config权限签名过期后要不要自动重新注入这个问题每个页面各自处理的话很容易乱。我当时做这一类封装的思路是写一个模块单独负责 SDK 的加载和初始化内部维护一个 readyPromise。外部任何业务模块调用它提供的接口时模块内部先 await readyPromise再调原生的 SDK 方法。这样业务方永远不需要关心“SDK 到底初始化好了没有”这件事。如果 config 过期导致某个接口调用失败模块统一做一次重新初始化重试业务方拿到的结果始终是一个标准 Promise失败原因也统一用错误码表达。类似的思路也适用于地图类 SDK、音视频类 SDK。这类 SDK 的共同点是有异步加载过程、有环境限制需要域名白名单、需要鉴权、有原生事件回调。封装它们的时候核心工作不是“包一层好用的 API”而是把异步准备流程和鉴权流程收敛成一个幂等的初始化过程。封装第三方 SDK 时还有一个容易忽略的点版本变化。比如企业微信 JS-SDK 不同版本之间有些方法名和行为有差异我的习惯是在封装模块里用常量集中管理“当前依赖的 SDK 最低版本”和“SDK 内部接口映射表”这样升级 SDK 的时候只需要改一个文件的映射关系不需要到所有业务页面里找。4.2 路由层面的封装动态路由和权限不是一回事vue-router 的动态路由是另一个极容易做乱的封装点。很多项目从后端拿到菜单权限之后需要动态注册路由表。这个流程看起来简单但有几个细节很折磨人路由组件是 import.meta.glob 批量加载还是逐个 import404 路由怎么处理才不会因为动态添加路由导致匹配错乱刷新页面后已经 addRoute 的路由还在不在退出登录时怎么把动态加的路由全部移除掉。我在项目里的做法是维护一个路由配置生成的纯函数把静态路由和动态路由分开管理。静态路由包含登录页、404 页、无权限页这类固定入口动态路由由一个函数根据权限列表生成每个路由项的 component 字段通过 import.meta.glob 按路径映射到实际组件文件。这一层封装的价值在于权限数据和路由数据是两回事。路由是结构性的它有层级关系权限是集合性的它只是一个 key 列表。转换这份结构的过程集中在一个位置后续不管是调整权限菜单还是调整页面结构都不会牵动全局。这里还有一个容易踩的坑动态 addRoute 的路由在菜单刷新后不会自动恢复必须在应用启动阶段重新走一遍权限获取和动态注册流程。很多人封装路由时忽略了“刷新恢复”这个场景结果用户登录后一切正常一刷新页面就空白。我在封装时会把“initRouter”这个函数做得足够幂等无论在首次登录、页面刷新、还是切换账号后调用它都能保证把目标用户的路由表重置成正确形态。4.3 全局组件的边界注册简单管理难前面说的大部分是逻辑封装再说一个轻轻松松就会做过的全局组件封装。很多项目会在 main.js 里 app.component() 注册一批全局组件图省事。但全局组件一旦多了会带来两个问题一是首包的体积很难控制因为你一旦全局注册了所有页面都会带上它二是组件之间的隐式依赖增多你不知道某个页面用到的按钮组件是不是全局注册的那个版本。我的建议是全局注册只保留那些“几乎每个页面都会用到、且形态极其稳定”的组件比如基础图标按钮、空状态占位、页面容器。业务型组件哪怕用得很频繁也尽量改成按需导入或者按目录批量注册不要一股脑全 global。如果你用的是 uniapp 或者跨端框架这个原则更要重视因为跨端的全局组件注册往往会影响各端的 bundle 策略。另外一个容易忽略的是弹窗类组件的全局挂载方式。很多组件库会提供命令式调用比如 this.$modal.confirm()很多开发者会基于自己的业务场景再封装一层命令式弹窗。我的建议是命令式弹窗适合“提示、确认”这类轻交互不适合承载复杂表单。复杂表单建议还是用组件内使用插槽的方式因为命令式调用时外部很难通过插槽向弹窗内部传递复杂模板只能靠 h 函数拼写起来很痛苦。5. 封装里最容易踩的四个坑和我的补救方案讲了这么多封装的正向思路最后集中聊聊我在一线项目里踩过的坑。这些坑每一个都真实改变了我对封装的认知也直接让我形成了前面那些设计原则。5.1 过度抽象为了复用而复用反而没人敢动第一个坑是我自己亲手刨的。有一段时间我痴迷于“抽象”总觉得代码不够抽象就不够优雅。我曾经把一个“表单页”抽象成了三层底层是通用动态表单渲染组件、中间是表单 schema 约定、上层是具体业务页。听起来很漂亮但实际用起来非常痛苦。业务页为了满足某个特殊字段的校验不得不在 schema 里塞各种自定义 render 函数而这些 render 函数比直接写一个表单页面还难维护。最后那个项目维护成本居高不下新同事接手时根本不敢改动动态表单的核心渲染逻辑。这次经历让我彻底接受了“适度抽象”这个词。抽象的价值必须由真实使用场景来验证而不是靠设计美感来判断。如果一个抽象的收益在当下是模糊的就不要做。现在我的习惯是一个封装的调用方写起来的代码量如果比不封装时只减少 30% 不到这个封装就不值得做。5.2 为了传参而传参props 层层透传有多痛第二个坑是 props 的层层透传。封装了一个列表组件列表组件内部又拆了搜索区域组件、表格组件、分页组件然后业务层为了控制搜索区域的某个默认值就需要把 props 从业务层传到列表组件再从列表组件传到搜索区域组件。中途还要通过事件从搜索区域传回列表组件再传回业务层。这样一个流程下来你改一个搜索条件的中文 label 都要动三个文件。后来我的补救方案是把搜索区域和表格的分页状态放在同一个组合式函数里由 usePageList 这类 hooks 管理组件树里只留一层“数据入口”。搜索条件、分页信息、列表结果全部由这个 hooks 暴露出来子组件和父组件都从同一份状态读取谁需要谁拿。这样透传问题就自然消失了因为大家读的是同一个响应式状态而不是靠 props 层层传递。5.3 生命周期判断失误封装内部自己拿数据还是外部传第三个坑比较隐蔽是“数据到底由谁获取”的问题。很多组件封装的初衷是“我打开这个弹窗它自己就把详情数据拉好”。这种封装体验确实好调用方很省事。但等你遇到一个场景弹窗还没打开外层列表已经提前知道了详情数据、希望能直接传给弹窗省一个请求的时候矛盾就出现了。组件内部自己拉数据的方案不利于这种复用因为你没法跳过它的内部请求。后来我的做法是组件的数据获取逻辑统一抽象成“外部传入数据源函数 内部缓存策略”。组件暴露一个 fetch-detail 属性调用方传入一个返回 Promise 的函数组件内部在打开时调用这个函数去拉数据。如果调用方已经有现成数据它可以传一个直接把现有数据 resolve 的函数或者干脆通过 props 传 initial-data组件内部协调“已有数据优先函数拉取兜底”。这个方案比“组件内部写死请求地址”要灵活得多。封装最忌讳把数据来源写死因为你永远不知道下一个使用场景的数据长在哪里。5.4 跨端复用的误会uniapp、electron 和小程序的封装差别第四个坑是从 vue 项目走向跨端场景时的认知偏差。很多人觉得“我在 vue 里封装了组件uniapp 里也能差不多用”。实际不是这样。uniapp 里组件运行的宿主是多端的不同端对事件、样式、原生能力支持的差异比想象中大。一个 vue 项目里封装好的地图组件拿到 uniapp 里可能在小程序端表现正常、在 App 端样式错乱、在 H5 端又是另外一套行为。做跨端封装的时候你必须按“端”做条件编译分支封装的目标也变成“统一业务接口”而不是“统一实现细节”。类似的还有 electron 和 vue 的结合。electron 里有主进程和渲染进程主进程负责系统能力渲染进程负责 UI。你把 vue 页面里的逻辑直接搬到渲染进程没问题但如果有访问文件系统、调用系统对话框这类能力就需要通过 IPC 走主进程。封装的时候我通常会把“渲染进程调用主进程能力”再包一层统一的 ipc 接口层让业务页面不需要感知 ipc 通道的名称和参数结构。跨端场景下的封装真正要统一的不是“代码”而是“语义”。理解到这一层之后我就不会再拿着 vue web 项目的封装方案无脑套到 uniapp 或 electron 上了。最后再分享一个经验封装这件事永远不要想着一口气做到完美。所有好的封装几乎都是从一个临时实现里被逼出来的。先让它跑起来跑到第三遍重复的时候再动手抽抽的时候脚踏实地多看看真实调用方的代码你就会发现自己对“封装”的理解会越来越实在。
