React中可单次渲染却触发两次的原因？单渲染写法为何不被推荐？

Refs在这类场景下会很实用，但通常我们建议尽量少用。哪怕在演示案例中，这种命令式的写法也不够理想，因为会触发两次而非一次渲染。

你调整后的写法虽然在当前场景下实现了单次渲染，但存在三个核心问题，因此不被官方推荐：

• 逻辑强依赖React内部执行规则，稳定性极差
  你猜测的批量更新合并确实是当前场景下只触发一次渲染的原因，但React的批量更新规则不是全局通用的：在setTimeout、Promise回调、原生DOM事件回调等非React合成事件上下文里，setState会同步执行更新，此时父组件会先完成一次渲染，你再调用子组件实例方法修改子组件状态，又会触发第二次渲染，甚至会出现父子状态不同步的问题。而且React版本迭代时批量更新的实现逻辑可能调整，你的代码很容易在版本升级后直接出bug，排查成本极高。
• 违反单向数据流设计原则
  React的核心设计理念是状态自上而下通过props传递，子组件的状态变化应该完全由传入的props或者自身内部逻辑控制。你通过ref直接调用子组件实例方法修改其内部状态，相当于绕开了正常的数据流链路，子组件的状态来源变成了两个：父组件传入的props、父组件命令式调用修改的内部状态，后期维护时根本无法快速溯源子组件状态的变更来源，也完全破坏了组件的可预测性。
• 存在状态不一致风险
  你调整后的写法默认了父组件setState和子组件方法调用一定会同时成功，但如果父组件有shouldComponentUpdate拦截了本次selectedIndex的更新，或者setState执行过程中被错误边界捕获了异常，就会出现子组件状态已经更新、但父组件selectedIndex完全没变化的情况，父子状态完全错位，这种隐蔽的bug很难通过常规测试覆盖。

官方文档不推荐这类写法的核心是优先保证逻辑的可预测性和可维护性，而不是优先追求单次渲染的性能优化，除非你完全确定当前场景的边界条件，并且能接受后续维护的额外成本。

相关代码对比：

// 官方原写法（两次渲染，逻辑可预测）
handleChange = index => {
  this.setState({ selectedIndex: index }, () => {
    const selectedAccount = this.props.accounts[index];
    this.inputRef.current.resetEmailForNewUser(selectedAccount.email);
  });
};

// 优化后写法（单次渲染，逻辑脆弱）
handleChange = index => {
  this.setState({ selectedIndex: index }); // 设置父组件自身的state
  const selectedAccount = this.props.accounts[index];
  this.inputRef.current.resetEmailForNewUser(selectedAccount.email); // 设置子组件的state
};

内容的提问来源于stack exchange，提问作者Mohamed BEN KHOUYA