vue组件化开发中逻辑抽离应遵循“模板只管展示、js负责逻辑”原则，出现重复计算、业务规则复用、setup臃肿或共用交互行为时需及时抽离；优先采用composition api的usexxx组合函数，其次考虑ui组件抽离，慎用mixin和全局挂载。
Vue 组件化开发中，代码重用和逻辑抽离不是“要不要做”的选择题，而是“怎么做得干净、可测、可持续”的实践问题。核心原则就一条：让模板只管“长什么样”，让 JavaScript 层负责“怎么运作”。
什么时候该抽逻辑？看这四个信号
不用等项目变大才行动，以下情况出现一个，就该考虑抽离：
-
模板里出现重复计算：比如多个地方写
{{ price | currency }}或v-if="user.role === 'admin' && !isExpired()"—— 这类表达式不该散落在各处，应封装成函数或 computed - 同一段业务规则反复出现：例如“是否可编辑”“是否显示删除按钮”“订单状态文案映射”，这些判断逻辑应统一管理，避免改一处漏三处
-
setup 里堆了太多异步请求+响应式声明+副作用处理：一个
useXXX()函数能把数据获取、加载状态、错误重试、缓存策略全包进去，父组件只管调用和绑定 - 多个组件共用一套交互行为：比如防抖搜索、滚动懒加载、鼠标悬停坐标跟踪 —— 它们本质是独立的能力，不该绑定在某个 UI 组件里
抽到哪？优先 Composition API 组合函数
Vue 3 的 useXXX 函数是当前最推荐的抽离方式，比 Mixin 更清晰、比全局挂载更可控：
- 不污染组件命名空间：返回的变量/方法名由你定义，不会和组件自身 data 或 methods 冲突
-
天然支持类型推导：TypeScript 能准确识别
const { list, loading, load } = useProductList()中每个字段的类型 - 可单独测试：直接 import 这个函数，在单元测试里传入 mock 数据和依赖，验证逻辑是否正确
- 按需导入，无运行时开销：没用到的组合函数不会被打包进最终产物
示例：把商品列表加载逻辑抽成 useProductList()，内部用 ref 管理数据、computed 派生筛选结果、onMounted 触发请求、onUnmounted 清理定时器 —— 父组件只需解构使用，模板里只写 v-for="item in list"。
什么时候才用组件抽离？聚焦 UI + 行为边界
组件抽离解决的是“UI 结构复用”，不是“纯逻辑复用”。当满足以下任一条件，就该拆组件：
- 同一块 UI 在 2 个以上页面/模块出现：比如带搜索+分页+排序的表格，或带头像+昵称+状态徽标的用户卡片
-
某块区域逻辑虽简单但职责明确：如
PriceTag（含折扣标识、原价划线、会员价标签）、StatusBadge（根据 status 字段渲染不同颜色和文字） -
需要控制 props 接口来约束使用方式：比如只允许传入
status: 'success' | 'warning' | 'error'，比在模板里写一堆 if 判断更安全 - 内部有独立生命周期或复杂交互：如富文本编辑器封装、地图选点组件、文件上传队列管理器
注意：不要为了抽而抽。一个只有几行 v-if 和 v-for 的简单列表，没必要单独成组件；但若它开始承担过滤、排序、空状态、加载态、错误重试 —— 那就是组件该登场的时候了。
Mixin 和全局挂载？谨慎使用
Mixin 在 Vue 2 时代常用，但在 Vue 3 中已明显退居二线：
-
来源难追溯：模板里突然出现一个
formatDate方法，你得翻遍 mixins 数组才能定位定义位置 -
命名易冲突：两个 mixin 都定义了
loading，合并后行为不可控 - 无法类型提示：IDE 很难推断 mixin 注入的属性类型
全局挂载（如 app.config.globalProperties.$utils）适合极少数真正通用的工具方法（如深克隆、简单日期格式化），但绝不该用来塞业务逻辑。一旦挂载，所有组件都能访问，违背了“按需引入”的设计哲学，也增加了测试隔离难度。
逻辑抽离不是一步到位的工程，而是随着需求演进持续优化的习惯。从把一个内联表达式变成 computed，到把一组相关能力封装成 useXXX，再到把高频 UI 提炼为原子组件 —— 每一次小抽离，都在降低后续修改的成本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
