老实说自从 Vue3 发布以来我见过太多所谓的“升级”项目了。打开代码一kan，好家伙，除了把 datamethodsmounted 这些配置项里的代码一股脑儿塞进 setup 函数里其他的几乎没什么变化。这哪里是升级？这简直就是给老房子刷了一层新漆，承重结构还是那个摇摇欲坠的样子。

hen多开发者朋友跟我抱怨，说用了 Composition API 之后代码不仅没变简洁，反而因为少了选项的隔离，变得像一锅乱炖的意大利面几千行的 .vue 文件比比皆是。其实这真不是 Vue3 的锅，而是我们还没真正跳出 Options API 的思维定势。今天咱们就抛开那些枯燥的官方文档，从一个真实的业务场景出发，聊聊如何通过三步，真正把 Setup 用出“人样”来。

在 Vue2 的旧时光里我们习惯了被框架“安排”得明明白白。你要定义数据？去 data 里。你要写方法？去 methods 里。你要初始化请求？去 mounted 里。这种“按类型组织”的方式，在项目初期确实hen清晰，但随着业务逻辑的膨胀，一个功Neng的代码会被拆散到文件的各个角落，维护的时候你得在 data 和 methods 之间反复横跳，简直让人抓狂。

到了 Vue3，setup 给了我们自由，但hen多人却把这自由用歪了。他们依然在 setup 里模拟 Options API 的写法。比如下面这段代码，是不是hen眼熟？

setup {
  const route = useRoute
  const detail = ref
  const queryDetailLoading = ref
  const user = ref
  const confirmLoading = ref
  async function queryDetail {
    queryDetailLoading.value = true
    detail.value = await api.getDetail
    queryDetailLoading.value = false
  }
  async function queryUser {
    user.value = await api.getUser
  }
  async function confirm {
    confirmLoading.value = true
    await api.confirm
    confirmLoadingLoading.value = false
  }
  onMounted => {
    queryDetail
    queryUser
  })
  return {
    detail,
    queryDetailLoading,
    user,
    confirmLoading,
    confirm
  }
}

乍一kan，这代码挺整洁，变量声明、方法定义、生命周期调用，井井有条。但Ru果你仔细琢磨，这其实就是把 Options API 的“换皮”。所有的逻辑dou混杂在一起，一旦这个页面再加个“评论模块”或者“日志模块”，这个函数还得继续膨胀，直到你完全kan不懂它为止。

真正的 Composition API，应该是按功Neng模块组织代码。想象一下Ru果我们把属于“详情”的代码放在一起，属于“用户”的代码放在一起，代码的可读性会不会发生质的飞跃？

setup {
  const route = useRoute
  // ===== 详情模块 =====
  const detail = ref
  const queryDetailLoading = ref
  async function queryDetail {
    queryDetailLoading.value = true
    detail.value = await api.getDetail
    queryDetailLoading.value = false
  }
  onMounted => {
    queryDetail
  })
  // ===== 用户模块 =====
  const user = ref
  async function queryUser {
    user.value = await api.getUser
  }
  onMounted => {
    queryUser
  })
  // ===== confirm 模块 =====
  const confirmLoading = ref
  async function confirm {
    confirmLoading.value = true
    await api.confirm
    confirmLoading.value = false
  }
  return {
    detail,
    queryDetailLoading,
    user,
    confirmLoading,
    confirm
  }
}

kan到区别了吗？这里我们打破了“只Neng有一个 onMounted”的迷信。在 Vue3 中，生命周期钩子Ke以调用多次每个功Neng块douKe以拥有自己的初始化逻辑。这种写法让代码的逻辑内聚性大大增强，你读代码的时候，目光是垂直移动的，而不是像以前那样需要到处跳跃。

完成了第一步，代码虽然清晰了但dou堆在 setup 里依然显得臃肿。这时候，Composition API 的杀手锏——组合式函数就该登场了。

既然我们Yi经把代码按功Neng分块了那么把这些块抽离成独立的函数就是顺水推舟的事。比如上面的“详情模块”，我们Ke以把它提取成一个 useDetail。

这里有个非常关键的原则，大家一定要记住了：组合式函数的抽象边界应该围绕“数据输入输出”，而不是围绕“框架Neng力”。

什么意思呢？比如我们在写 useDetail 时它的输入应该是一个明确的 id，输出是 detail 和 queryDetailLoading。千万不要为了省事，把 const route = useRoute 直接扔进 useDetail 里。这样Zuo会让你的函数变得难以复用，而且充满了副作用，单元测试也没法写。

function useDetail {
  const detail = ref
  const queryDetailLoading = ref
  async function queryDetail {
    queryDetailLoading.value = true
    detail.value = await api.getDetail
    queryDetailLoading.value = false
  }
  onMounted => queryDetail)
  return {
    detail,
    queryDetailLoading
  }
}

kan，这就是一个纯净的函数。它不关心你是从路由里拿的 ID，还是从父组件传来的 ID，它只负责根据 ID 拿数据。这样，setup 函数就变成了一个轻量级的“指挥官”，负责调度这些功Neng块：

setup {
  const route = useRoute
  // ===== 详情模块 =====
  const { detail, queryDetailLoading } = useDetail
  // ===== 用户模块 =====
  const { user } = useUser
  // ===== confirm 模块 =====
  const { confirm, confirmLoading } = useConfirm
  return {
    detail,
    queryDetailLoading,
    user,
    confirmLoading,
    confirm
  }
}

这一刻，setup 不再是一个堆满杂物的“大仓库”，而是一个清晰的“功Neng组合器”。各个 composition 各司其职，setup 只负责把视图层需要的数据聚合起来暴露给模板。你再也不会写出那种流水账式的代码了。

到了这一步，代码结构Yi经hen棒了但还有一个geng高级的思维转变等着我们。hen多同学在迁移 Vue3 时依然保留着 Vue2 的“生命周期思维”。比如当路由参数变化时需要重新请求数据，大家的第一反应往往是去监听路由变化，或者写一堆复杂的逻辑。

其实setup 不应该围绕生命周期组织，而应该围绕数据变化组织。这才是响应式编程的精髓。

试想一下useDetail 的本质是什么？不就是“当 ID 变化时重新获取 Detail”吗？我们完全Ke以用 watch 来替代 onMounted，从而统一处理初始化和geng新。

function useDetail {
  const detail = ref
  const queryDetailLoading = ref
  async function queryDetail {
    queryDetailLoading.value = true
    detail.value = await api.getDetail
    queryDetailLoading.value = false
  }
  // 监听 id 的变化，自动触发请求，immediate: true 保证了初始化也会执行
  watch => toValue,  => queryDetail), { immediate: true })
  return {
    detail,
    queryDetailLoading
  }
}

这样一来无论是组件刚挂载，还是路由参数发生了变化，useDetail douNeng自动应对。我们在 setup 里调用它时甚至Ke以传一个 getter 函数，实现geng加灵活的响应式绑定：

setup {
  const route = useRoute
  // ===== 详情模块 =====
  // 传入一个函数，当 route.params.id 变化时useDetail 内部会自动感知
  const { detail, queryDetailLoading } = useDetail => route.params.id)
  // ...其他模块
  return {
    detail,
    queryDetailLoading,
    // ...
  }
}

Ru果你使用了 Vue Router 的 props 模式将路由参数作为 props 传递，代码还Nenggeng纯粹，完全脱离对 useRoute 的依赖：

setup {
  // ===== 详情模块 =====
  const { detail, queryDetailLoading } = useDetail => props.id)
  // ===== 用户模块 =====
  const { user } = useUser => props.id)
  // ===== confirm 模块 =====
  const { confirm, confirmLoading } = useConfirm
  return {
    detail,
    queryDetailLoading,
    user,
    confirmLoading,
    confirm
  }
}

这种写法，把“副作用”完全交给了响应式系统去管理。我们只需要描述“数据之间的关系”，剩下的脏活累活框架dou帮我们干了。这才是 Composition API 赋予我们的真正力量。

当然有些追求极致的同学可Neng会说：“每次dou要写 refloadingwatch，这也太繁琐了吧？有没有geng懒的方法？”

必须有！既然这些模式dou是固定的，我们完全Ke以把它们封装成geng高级的工具库。比如我自己就写了一个 vue-asyncx，专门用来解决这种异步数据获取的问题。

用了它之后上面的代码Ke以简化成这样：

import { useAsyncData, useAsync } from 'vue-asyncx'
setup {
  // ===== 详情模块 =====
  const {
    detail,
    queryDetailLoading
  } = useAsyncData => api.getDetail, {
    watch:  => props.id, immediate: true
  })
  // ===== 用户模块 =====
  const { user } = useAsyncData => api.getUser, {
    watch:  => props.id, immediate: true
  })
  // ===== confirm 模块 =====
  const { confirm, confirmLoading } = useAsync => api.confirm)
  return {
    detail,
    queryDetailLoading,
    user,
    confirmLoading,
    confirm
  }
}

数一数行数，核心逻辑从原来的 19 行直接减少到了 10 行，代码量砍掉了一半，但语义化和组织性一点dou没丢。这种把模式固化下来的Zuo法，Neng让我们从繁琐的样板代码中解脱出来geng专注于业务本身。

Zui后让我们回过头来kankan Vue 官网那张经典的对比图。以前hen多人kan不懂，觉得只是代码位置的移动。现在你应该明白了：

Options API 是按类型组织，强迫我们把逻辑拆散； Composition API 是按功Neng组织，允许我们把逻辑聚合。

想要复用逻辑只Neng靠 mixin，但 mixin 是通过在 this 上动态添加属性实现的，导致类型推导极其困难，数据来源也是个谜，极度依赖对实现细节的了解。而 Composition API 通过函数调用，让数据的输入输出变得一目了然。

所以别再写那种“换皮”的 Options 代码了。试着按照这三步走： 1. 在 setup 里把同一职责的代码写在一起； 2. 把这些功Neng块拆分成独立的组合式函数； 3. 用数据驱动的思维去管理副作用。

你会发现，Vue3 的世界真的不一样了。这不仅仅是语法的升级，geng是代码组织方式的革命。它的真正价值，不在于 setup 本身，而在于它允许我们按“业务模型”组织代码，而不是按“框架结构”组织代码。这才是我们作为开发者，应该追求的“代码自由”。