从 个 Hooks 到注册表模式：Vue 复杂详情页的架构演进与原则沉淀

一、 ：一个“拆分得很好”的组件，为什么还要重构？

先看一段代码结构:

taskDetail/ ├── index.vue ├── hooks/ │ ├── useRouteState.ts │ ├── useTaskFetch.ts │ ├── useBtnVisibility.ts │ ├── useTaskActions.ts │ └── useButtonRender.ts

乍一看。这已经是一个相当规范的 Vue Composition API 实践了：

• 组件本身几乎不包含业务逻辑，所有逻辑下沉到 个 hooks
• 每个 hook 职责明确：路由解析、数据请求、权限判断、操作管理、按钮渲染
• 弹窗统一管理、按钮动态渲染、Tab 懒加载策略——该考虑的都考虑了

团队在初次重构时也正是带着这样的自信交付的。老实说，只是随后的迭代暴露出一些令人不安的信号：

• 新增一个“转派”按钮，需要修改 个文件
• useTaskActions 的 submitForm 函数膨胀到 + 行。if/else 嵌套 层
• useTaskFetch 和 useButtonRender 之间出现了循环依赖，不得不用一个延迟绑定的工厂函数来“打补丁”
• 新加入的同事对着 个 hook 的参数传递链条发懵，改一个字段要追溯 层调用

问题出在哪里？

表面上看，代码已经“拆分”了。不过，但拆分的粒度、方向、还有模块间的依赖关系。决定了这套架构是真正降低了复杂度，还是仅仅把复杂度从一个文件转移到了另一个文件。

二、旧架构深度体检：五个隐蔽的结构性成本

让我们以一份真实的架构分析文档为样本，逐层解剖旧架构的问题。

Hooks 调用链的循环依赖

看 Hooks 之间的依赖关系：useRouteState → useTaskFetch → useBtnVisibility / useTaskActions ↓ useButtonRender ↓ getButtonHelpers ← useTaskFetch

说到注意最终一步，useTaskFetch 依赖 useButtonRender 产出的 getButtonHelpers而 useButtonRender 又依赖 useTaskFetch 产出的 detailData。这是一个典型的循环依赖。

旧架构的解法是引入一个延迟绑定的工厂函数：

// useTaskFetch.ts 中的“补丁”getButtonHelpers: => 这段代码的意思是：“我现在还不知道你要什么先给你一个回调，等你需要的时候再调用我”。它在功能上确实解了循环依赖的“死锁”，但也带来了两个问题：

1. 执行时机不确定调用方需要知道何时该调用这个工厂函数，何时不该
2. 调试成本高 :追踪一个按钮的渲染逻辑。需要在两个 hook 之间反复跳转，且调用栈被工厂函数打断

循环依赖的本质是模块边界的划分出了问题 。当 A 依赖 B，B 又依赖 A 时代表着它们本应属于同一个内聚单元，却被强行分开了。

八个弹窗的静态声明：模板臃肿与横向散点

打开 index.vue   的模板部分，你会看到这样的结构