doc 自有黄金屋，doc 自有颜如玉。遇到问题，翻翻文档总是没错的。------我
遥想当年，刚从 React 的怀抱转投 Vue，初见 Composition API 是欣喜的，简洁的语法，没有过多的心智负担，对 ts的友好支持。但人生若只如初见，这时间久了，曾经的心动，也难免被日常的鸡毛蒜皮给磨平。某天打开那个被加了十几遍需求的代码一看------这什么玩意？
本着程序员的优良传统------这一定不是我的问题。一方面肯定是产品的不对，另一方面那指定是 yyx 这个浓眉大眼的锅了。vue 的 template 语法，简单是简单，但问题，你一个文件只能写一个组件，一个大组件下来，要么一个 .vue 文件长得能当裹脚布（动辄几百行），要么就得拆成四五个文件来回跳转。总结下来就一个字------乱 ！再叠加上 Composition API 的"组合"特性，好家伙，这四五个组件文件，往往还得配四五个 useXxx 的组合函数文件。这下好了，直接升级成两个字------混乱！代码组织？不存在的，那叫"布朗运动"。
javascript
<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 嘛。那灵活的代码组织呢，这也是目前我遇到的问题，文档给出的答案也很简单，还是组合式函数。我之前一直纠结的，把不共用的函数拿出去，造成的上下文污染，也找到了解决方案，很简单------写在一起，可以看一下尤大写的代码: github.com/vuejs-trans...
javascript
<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类型）强行分割。以前觉得"乱"，或许是没找到正确的"组织方式"，强行把"组合"用成了"拼凑"。
有道是: 组合妙法惹心欢 日久码乱生疑窦 尤公文档释玄机 方知己过非道偏。