React中为何优先用state而非let/const/var？相关使用疑问

• React核心逻辑：状态驱动视图同步
  React的UI渲染完全依赖状态变化，当你通过setState更新state时，React会自动触发组件重渲染，让页面和最新状态保持一致。但let/const/var声明的普通变量不一样——哪怕你改了它的值，React根本感知不到变化，页面不会有任何更新，这在需要交互的场景里直接导致数据和UI脱节。
• setState的异步是性能优化，不是缺点
  你说setState是异步操作，这其实是React的批量更新策略：它会把多次setState调用合并成一次重渲染，避免频繁操作DOM造成性能浪费。如果要在状态更新后执行逻辑，要么用setState的第二个回调参数，要么在useEffect里监听对应状态就行。
• 状态的可管理性
  state的更新会被React纳入生命周期管控，状态变化是可预测、可追溯的。而普通变量的修改毫无约束，在复杂组件或多人协作时，很容易出现数据混乱、调试困难的问题。

这种做法合不合理，核心看变量是否需要影响UI渲染：

• 完全可以用let的场景
  如果变量只是组件内部的临时计算值、缓存数据，或者不需要同步到UI的状态（比如定时器ID、请求取消令牌），用let完全没问题，反而能避免不必要的重渲染。比如：

function TimerComponent() {
  let timerId; // 仅用于存定时器ID，不需要展示在UI上
  const start = () => {
    timerId = setInterval(() => console.log('tick'), 1000);
  };
  const stop = () => clearInterval(timerId);
  // ...
}

• 必须用state的场景
  如果变量的值要展示在页面上，或者会影响组件渲染逻辑（比如控制弹窗显隐、列表数据、用户输入内容），那用let就是错误的。React不会监测let的变化，会导致UI和数据不一致，后续维护会出现各种诡异bug——这时候必须用state，才能发挥React状态驱动的核心优势。
• 你的情况判断
  如果改用let后能正常运行，大概率这个变量属于不需要触发UI更新的临时变量，这种情况用let是合理的，不算浪费框架优势。但如果这个变量是要展示在页面上的状态，那得排查state用不了的原因——比如是不是你在setState异步更新前读取了旧值，或者状态更新时机不对，这时候该调整state的使用方式，而不是换let。

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