应将 watch 与副作用整体封装为 useXxx 组合函数，如 useFormValidation、useSearchSuggestion；优先用 watchEffect 自动追踪依赖；按业务域限定监听边界，避免跨域耦合；内部配合 onBeforeUnmount 自动清理，确保内存安全。

watch 逻辑本身不适合直接抽离成独立函数，但可以通过封装响应式副作用行为、结合事件总线或状态管理边界，把“监听 + 副作用处理”这一整套流程封装进组合函数中，实现高内聚、可复用、易测试的业务模块。

把 watch 和副作用打包进 useXxx 函数

不要只抽离 watch，而是把“监听什么、何时触发、执行什么副作用”全部收拢。比如表单校验场景：

• 定义一个 useFormValidation 组合函数，内部创建 ref 表单值、定义校验规则、用 watch 监听变化并更新错误信息
• 返回 { errors, validate, reset } 等接口，外部只关心调用，不暴露 watch 实现细节
• 这样组件里只需 const { errors } = useFormValidation(formState)，校验逻辑完全隔离

用计算属性 + watchEffect 替代硬编码 watch

watchEffect 更适合抽离：它自动追踪依赖，无需手动指定 source，语义更清晰，也更容易封装。

• 例如搜索建议模块：监听输入关键词，自动发起请求并缓存结果
• 在 useSearchSuggestion 中用 watchEffect 包裹 fetch + cache 逻辑，所有副作用闭环在函数内部
• 外部传入关键词 ref 即可，不需要知道是否用了 watch 或 watchEffect

按业务域划分监听边界，避免跨域耦合

watch 抽离失败的常见原因是监听了不该管的数据，比如在订单模块里监听用户登录状态——这属于权限域，应由 useAuth 提供 ready 状态，而非订单自己 watch user。

• 每个组合函数只监听自己职责范围内的响应式数据（如 useOrderDetail 只 watch orderId）
• 跨域通信通过显式参数传递（如 useOrderDetail({ authReady })），而不是隐式 watch 全局状态
• 这样模块间解耦，测试时可轻松 mock 输入，不依赖真实 store 或全局实例

配合 onBeforeUnmount 清理副作用

watch 和 watchEffect 都会持续运行，必须清理。抽离时要把销毁逻辑一并封装。

• 在组合函数内部调用 watchEffect，保存其返回的 stop 函数
• 使用 onBeforeUnmount 自动调用 stop，避免内存泄漏
• 用户无需手动管理生命周期，封装后天然安全