用途：在评审、设计、实现或重构 React 组件与自定义 Hook 时，判断是否真的需要抽出一个自定义 Hook，避免把依赖和副作用藏进 Hook 造成职责过多与内部紧耦合。
主要原则：创建或建议 Hook 前先问：这段逻辑能否不用 React Hook，以普通函数或模块表达；该 Hook 的单一职责能否一句话说清；这些依赖是否本就应由调用方持有；若删除并内联回调用方，代码是否更清晰。创建、建议或重构时需自然说明为何必须是 Hook。
优先替代：计算、数据转换、校验、API 调用优先用普通函数/模块；单个组件的事件处理或小组装逻辑保留在组件本地；UI 职责过大或状态与控制流难懂，应视为组件重设计信号。若结构调整在范围内，按 Tidy First 先做结构调整，否则另提重构。不允许的理由包括组件太长、存在重复代码、调用点更干净、更易测试等。
合理 Hook：以 React 状态及其转换为核心职责，如 useDisclosure 这类拥有一个状态机、无隐藏外部依赖的 Hook；或以 React 生命周期/副作用为核心职责，如 useOnClickOutside 这类必须依赖渲染、订阅、清理、ref 或 DOM 集成的逻辑。
应避免：与 React 无关的计算（如把购物车总价写成 Hook，应改为普通函数）；仅重命名现有依赖的薄包装（如 useUserProfileQuery 包装 useQuery）。业务逻辑 Hook 需按职责是否清晰、是否隐藏调用方应知的依赖、是否把逻辑困在 Hook 内导致组件无法控制流程来判断。坏味道如一个 useUserProfile 同时隐藏数据获取、选项卡状态、路由、表单状态与提交、通知等依赖；应把这些依赖保留在组件内可见。
Controller Pattern Hook：属于项目特定策略，仅在项目已使用该模式时允许，与某个组件一一对应、同目录、名称体现 controller、不供复用、只承担目标组件可承担的职责；被多个组件复用即为失败信号。若需拆分，问题在组件/分层设计。常见错误包括命名过宽、因重复代码而共享、因组件过长而创建、隐藏调用方应控制的依赖、把组件不该拥有的职责困在 Hook 中。
最终规则：自定义 Hook 不是缩短代码的工具，只有当状态、副作用、生命周期、订阅、清理或 ref 等 React 依赖对单一职责必不可少时才使用；已有违规代码应先考虑移回普通函数、普通模块或组件本地逻辑，必要时作为独立重构提出。
限制：本技能不禁止自定义 Hook，也不改代码；资料未提供安装命令、收费、平台或效果信息。