香消码乱疑尤法，文照心开悟本根

doc 自有黄金屋，doc 自有颜如玉。遇到问题，翻翻文档总是没错的。——我

遥想当年，刚从  React  的怀抱转投  Vue，初见 Composition API 是欣喜的，简洁的语法，没有过多的心智负担，对 ts的友好支持。但人生若只如初见，这时间久了，曾经的心动，也难免被日常的鸡毛蒜皮给磨平。某天打开那个被加了十几遍需求的代码一看——这什么玩意？

本着程序员的优良传统——这一定不是我的问题。一方面肯定是产品的不对，另一方面那指定是 yyx 这个浓眉大眼的锅了。vue 的 template 语法，简单是简单，但问题，你一个文件只能写一个组件，一个大组件下来，要么一个  .vue  文件长得能当裹脚布（动辄几百行），要么就得拆成四五个文件来回跳转。总结下来就一个字——乱！再叠加上  Composition API  的“组合”特性，好家伙，这四五个组件文件，往往还得配四五个  useXxx  的组合函数文件。这下好了，直接升级成两个字——混乱！代码组织？不存在的，那叫“布朗运动”。

<script setup>
// 状态管理、文件操作、树结构、UI控制全搅在一起
const files = ref([])
const expandedPaths = ref({})
const selectedFile = ref(null)
const searchQuery = ref('')

// 200行混杂逻辑
const fetchFiles = async () => { /* ... */ }
const toggleExpand = (path) => { /* ... */ }
const handleSelect = (file) => { /* ... */ }
const filteredFiles = computed(() => { /* ... */ })
// ...还有十几个交叉引用的函数
<template>
  <!-- 裹脚布式模板 -->
</template>

吐槽归吐槽，问题还得解决，某天摸鱼（学习）翻文档的时候，翻到了这一个组合式 API 常见问答 这一看不要紧，看的我额头多了几滴冷汗。乖乖，难道我错怪 yyx 了，难道他的本意是好的，是我执行出了问题？

得了，书归正题，让我们看看文档是怎么写的，为什么要有组合式 API？文档给了两个核心理由： 1.更好的逻辑复用，2.更灵活的代码组织。

”更好的逻辑复用“， 这个可以理解，把那些能公用的逻辑抽成  useFunction  嘛。那灵活的代码组织呢，这也是目前我遇到的问题，文档给出的答案也很简单，还是组合式函数。我之前一直纠结的，把不共用的函数拿出去，造成的上下文污染，也找到了解决方案，很简单——写在一起，可以看一下尤大写的代码: https://github.com/vuejs-translations/docs-zh-cn/blob/main/assets/FileExplorer.vue。

<script setup>
  // 按业务能力拆解独立单元 const {(files, fetchFiles)} = useFileSystem(); //
  文件系统域 const {(expanded, toggle)} = useTreeTraversal(); // 树形结构域
  const {(selected, select)} = useSelection(); // 状态管理域 const{" "}
  {(query, filteredItems)} = useSearch(files); // 搜索域
</script>

仔细品品尤大那个  FileExplorer，组件本身的代码量没见少多少，但妙就妙在：通过组合式函数（即使是只服务于这个组件的）实现了清晰的“关注点分离”。文件操作归一组函数，树形结构归一组函数，状态管理归一组函数…… 各自为政，条理分明。这样一来，代码的可读性和可维护性（修改、调试时尤其明显）有了跨越式的提升。

原来，Composition API（以及  React Hooks）设计的底层哲学，正是在践行  DDD (领域驱动设计)  的精髓——按业务逻辑/能力边界组织代码，而非按技术细节（生命周期、Options 类型）强行分割。以前觉得“乱”，或许是没找到正确的“组织方式”，强行把“组合”用成了“拼凑”。

有道是: 组合妙法惹心欢 日久码乱生疑窦 尤公文档释玄机 方知己过非道偏。