React中自定义钩子同时返回JSX和状态的模式存在哪些隐藏问题？

这种写法在极简Demo中确实能正常运行，但本质上违反了React的组件设计原则，存在大量隐藏缺陷，几乎无法应用在复杂度稍高的项目中：

核心缺陷 #

• Hook调用规则限制极强，极易报错
  你封装的button、input本质是自定义Hook，必须严格遵守React Hook的调用规则：不能在条件判断、循环、嵌套函数中调用，否则会因为Hook调用顺序不一致直接导致状态错乱、控制台抛出规则错误。看似简洁的写法，实际上给后续的需求迭代加上了极强的限制。
• 状态归属错位，调试维护成本极高
  正常组件的内部状态归属于组件自身，在React DevTools中可以直接对应到组件查看。但这个写法里所有按钮、输入框的状态都挂载在调用它们的父组件上，一旦调用次数多了，父组件下会挂载数十个无明确标识的状态，出问题时根本无法快速定位状态和UI的对应关系。
• 无独立组件实例，能力严重受限
  返回的JSX没有独立的组件实例，无法使用React.memo做渲染性能优化，父组件每次重渲染都会重新生成所有元素对象，额外产生大量不必要的计算和DOM diff开销，复杂页面下会出现明显卡顿。同时也无法独立配置Context、错误边界等组件级能力，扩展空间极低。
• 状态与渲染生命周期解绑，易泄漏或串状态
  如果你把返回的JSX作为属性传递给其他组件渲染，状态的生命周期还是和调用Hook的父组件绑定：渲染节点卸载了，父组件里的状态还会留存造成内存泄漏；如果同一个返回的JSX被多次渲染，所有节点会共用同一份状态，出现预期外的联动。
• 封装灵活性差
  如果需要给按钮加样式、自定义事件、额外属性，都需要手动在自定义Hook里做参数透传，远不如正规组件传参方便，也缺少TypeScript类型提示的天然支持，容易漏传参数。

会触发Bug的典型场景 #

• 在条件分支中调用button()/input()，比如if (visible) [b1, n1] = button()，直接违反Hook顺序规则
• 在列表循环中调用，比如list.map(() => button())，列表增删、排序后所有的状态会完全串位
• 把返回的JSX传递给其他组件渲染、或者复用同一个返回值渲染多次，出现状态泄漏或异常联动
• 父组件渲染压力大的场景，比如频繁更新的表格、可视化页面，会出现明显的性能卡顿

如果想要实现类似「状态+UI」统一封装的能力，更稳妥的做法是封装为正规组件，需要共享状态时用状态提升、或者单独用自定义Hook封装状态逻辑，UI部分放在组件内部渲染，既保留封装性，也符合React的设计原则。

内容的提问来源于stack exchange，提问作者Luke Miles