Vue 中为什么不推荐滥用 mixin？组合式函数如何替代？

简化版

mixin 能复用组件选项，但容易产生命名冲突、来源不清、隐式依赖和合并规则复杂等问题。Vue3 更推荐组合式函数，把状态和方法通过普通函数显式返回，依赖更清楚，也更利于类型推导和测试。

详细版

mixin 示例：

export const pageMixin = {
  data() {
    return { page: 1 }
  },
  methods: {
    reload() {}
  }
}

组合式函数示例：

export function usePagination() {
  const page = ref(1)
  const reload = () => {}
  return { page, reload }
}

mixin 的问题是变量从哪里来不明显，多个 mixin 之间可能冲突，生命周期和方法合并也会增加理解成本。composable 通过函数调用显式引入逻辑，调用方能清楚看到返回了什么。

完整版教学

一、mixin 的初衷是复用 Options API 逻辑

在 Vue2 时代，组件逻辑分散在 data、methods、computed、watch、生命周期里。如果多个组件都要分页、权限、埋点，mixin 可以把这些选项合并进组件。这在小规模项目里确实方便。

export const trackMixin = {
  mounted() {
    console.log('page view')
  },
  methods: {
    trackClick(name) {
      console.log(name)
    }
  }
}

但方便的代价是隐式。组件使用 mixin 后，模板里突然能访问某个方法，读代码的人不一定知道它来自哪个 mixin。

二、命名冲突是 mixin 最常见的问题

如果组件自身和 mixin 都定义了同名方法或数据字段，就会发生覆盖或合并。多个 mixin 之间也可能互相冲突。项目越大，这种问题越难查。

const mixinA = {
  methods: { reload() {} }
}

const mixinB = {
  methods: { reload() {} }
}

问题	mixin 表现	composable 表现
名称来源	隐式注入	import 和调用可见
冲突处理	依赖选项合并规则	调用方自己命名
类型推导	较弱	函数返回值清晰
测试	依赖组件实例	可单独测试函数

如果一个组件混入 4 个 mixin，每个暴露 5 个字段，就有 20 个隐式成员。维护者需要在多个文件里来回跳，认知成本很高。

三、隐式依赖会让逻辑难以搬迁

mixin 里的代码可能依赖组件必须存在某个 data、prop 或 method。但这种依赖通常没有清晰声明。换一个组件使用同一个 mixin 时，运行时才发现缺字段。

export const listMixin = {
  mounted() {
    this.fetchList(this.page)
  }
}

上面要求组件必须有 fetchList 和 page。但从 mixin API 看不出来。这类隐式契约在多人协作中很容易踩坑。

四、组合式函数把依赖和返回值摆到台面上

composable 本质是普通函数。它接收明确参数，返回明确状态和方法。调用方可以重命名返回值，避免冲突。

export function usePagination(fetcher) {
  const page = ref(1)
  const loading = ref(false)

  async function reload() {
    loading.value = true
    try {
      await fetcher(page.value)
    } finally {
      loading.value = false
    }
  }

  return { page, loading, reload }
}

const {
  page: userPage,
  loading: userLoading,
  reload: reloadUsers
} = usePagination(fetchUsers)

这段代码把依赖 fetchUsers 和返回成员都写出来了。如果冲突，调用方可以直接重命名。

五、组合式函数更适合 TypeScript 和单元测试

因为 composable 是函数，TypeScript 可以推导参数和返回值。测试时也可以不挂载完整组件，直接调用函数验证行为。这比在组件实例上找混入方法更轻。

const { page, reload } = usePagination(async (p) => {
  expect(p).toBe(1)
})

如果分页逻辑有 5 个边界条件，composable 可以写 5 个函数级测试。 mixin 往往需要创建组件实例、合并选项，再触发生命周期，测试成本更高。

六、不是所有复用都要做成 composable

组合式函数适合复用状态逻辑、副作用逻辑和业务能力。如果复用的是 UI 结构，应提取组件。如果复用的是纯计算，应提取普通工具函数。不要把所有代码都塞进 useXxx。

复用 UI 结构 -> 组件
复用响应式逻辑 -> composable
复用纯函数计算 -> utils
复用样式规则 -> CSS class 或变量

记忆钩子：mixin 像暗中往组件塞东西，composable 像明面上拿一个工具箱。

面试时不需要把 mixin 说得一无是处。更准确的说法是：旧项目可以理解和维护，新逻辑优先用 composable。

七、常见误区与追问

误区：mixin 完全不能用。 老项目和简单复用仍可能存在 mixin，问题在于大规模滥用会导致隐式复杂度。
误区：composable 只是把 mixin 换个文件名。 composable 是显式函数调用，有参数和返回值，依赖边界更清晰。
误区：所有复用都应该写成 useXxx。 UI 结构提组件，纯计算提工具函数，响应式逻辑才适合 composable。
追问：mixin 的命名冲突怎么发生？ 多个 mixin 或组件自身定义同名 data、method、computed 时会产生覆盖或合并问题。
追问：组合式函数为什么利于测试？ 它可以像普通函数一样单独调用，不一定依赖完整组件实例。
追问：旧项目大量 mixin 怎么迁移？ 先按业务能力拆出 composable，保持调用行为不变，再逐步减少隐式成员。

八、加强记忆

这题按“隐式”和“显式”记。mixin 的复用靠选项合并，容易来源不清、命名冲突、隐式依赖；composable 靠函数调用，参数和返回值都可见，更适合 Vue3、TypeScript 和测试。最后补一句：复用 UI 用组件，复用响应式逻辑才用 composable。

简化版

详细版