React子组件是否应持有自身状态？两种状态管理方案对比

场景说明 #

假设我们有父组件App，其包含一个子组件Search。
当前示例里，Search组件通过setState同步展示输入框中键入的文本，实现代码如下：

const Search = () => {
  const [searchTerm, setSearchTerm] = React.useState("");
  const handleChange = (event) => {
    setSearchTerm(event.target.value);
  };
  return (
    <div>
      <label htmlFor="search">Search: </label>
      <input id="search" type="text" onChange={handleChange} />
      <p>
        Searching for <strong>{searchTerm}</strong>.
      </p>
    </div>
  );
};

两种可选实现方案 #

• 方案1：子组件Search自行持有状态。也就是让Search组件内部调用useState()管理输入状态，这种写法算不算不良实践？
• 方案2：父组件App托管子组件状态。也就是把Search组件的输入值通过回调向上传给父组件App，由App调用setState()统一维护状态，再把更新后的值通过props回传给Search组件。

核心疑问：以上两种方案哪种更符合React开发的最佳实践？

提问补充 #

我不理解这个问题为什么会被标记为主观倾向性问题。我承认不同开发者在方案选择上会有分歧，但正确设计模式的选型本来就有公开的讨论标准，如果这类问题算主观问题，那Stack Overflow上所有设计模式选型、SQL数据库/表选型类问题，是不是都该被标记为主观问题？

解答 #

两种方案没有绝对的优劣，判断标准完全遵循React官方一贯推荐的状态就近、最小粒度原则：

• 如果searchTerm这个状态只在Search组件内部使用，父组件App、其他兄弟组件完全不需要感知这个值，那方案1就是标准的正确实践，根本不存在“不良”一说。把状态放在离实际使用位置最近的地方，能减少大量无意义的props透传，缩小状态变化触发的重渲染范围，后续维护代码的时候找状态逻辑也更方便。
• 如果searchTerm需要被父组件或者其他关联组件使用——比如父组件要拿到搜索词发接口请求、要和其他筛选组件做联动、要做全局的状态持久化，那就应该把状态提升到父组件管理，也就是用方案2，这也是官方文档里明确写的「状态提升」模式的标准适用场景。

刻意为了所谓的“状态统一管理”把所有组件的本地状态都往上堆到父组件甚至全局，才是违反React设计思路的不良实践，平白增加很多不必要的代码复杂度。

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