Options API 中 mixins 不适合封装工具函数，应将校验、请求等逻辑写成独立纯函数并导入使用；mixins 仅负责状态管理或生命周期粘合，命名需加语义前缀防冲突；老项目宜渐进迁移至组合式函数。
在 Options API 中，mixins 本身不直接支持“独立工具函数”的封装方式——它本质是选项对象的合并机制，不是函数作用域。想复用常见业务逻辑，关键不是把工具函数塞进 mixins，而是让这些函数保持独立、可导入、可测试，并在组件中按需调用。
工具函数必须脱离 mixins 单独定义
把校验、请求、格式化等逻辑写成纯函数（无 this、不依赖 Vue 实例），放在 utils/ 或 composables/ 目录下：
-
不要这样写（混入里塞工具函数）：
export default { methods: { formatDate(date) { return new Date(date).toLocaleString() } } } -
应该这样写（独立导出）：
export function formatDate(date) { return new Date(date).toLocaleString() }
然后在组件中 import { formatDate } from '@/utils/date'
mixins 只负责“粘合”，不负责“实现”
mixins 的合理角色是组织调用链、统一生命周期响应或注入通用状态字段，而不是承载业务逻辑本身：
- 比如封装一个 loading 状态管理 mixin：
data() { return { apiLoading: false } }
methods: { startLoading() { this.apiLoading = true }, endLoading() { this.apiLoading = false } } - 但实际请求逻辑仍由外部函数承担：
import { apiRequest } from '@/api'
methods: { async fetchData() { this.startLoading(); try { this.data = await apiRequest('/user') } finally { this.endLoading() } } }
避免命名污染，用语义前缀明确归属
如果确实要在 mixin 中暴露方法（如统一错误处理），必须加业务或模块前缀，防止和组件或其他 mixin 冲突：
- ❌ 不要定义 handleError() —— 太泛，极易覆盖
- ✅ 定义 formHandleError(error) 或 apiHandleNetworkError(error)
- 调用时清晰可知来源：
this.formHandleError(e)
Vue 2 项目中更推荐逐步迁移路径
对于已有大量 mixins 的老项目，不建议强行重构，但新功能可采用渐进策略：
- 新增逻辑优先写成独立函数，再通过 methods 显式调用
- 对高频复用逻辑（如表单校验），抽成 validateForm(schema, data)，而非混入 validate 方法
- 用 @vue/composition-api 插件引入 useApi、useForm 等组合式函数，在 Options 组件中 setup() 调用，兼顾类型安全与逻辑隔离
