写过 Vue 的 v-model，再回到 React，第一件不习惯的事就是：没有双向绑定。输入框的值不能直接绑到一个变量上，改数据要走 setState，改回来还得自己接事件。很多人一开始觉得这是「麻烦」，用久了才发现，这正是 React 最值钱的设计之一——单向数据流。

这篇讲清三件事：单向数据流到底是什么、它在 React 里长什么样、以及它到底好在哪。

一、什么是单向数据流

一句话：数据只有一条流动方向——从父组件流向子组件，子组件不能反向修改父组件的数据。

• 数据往下走：父组件通过 props 把数据传给子组件。子组件只能「读」，不能「改」。
• 事件往上走：子组件想改数据，不能自己动手，只能触发一个回调（也是通过 props 传下来的），请父组件去改。

于是形成一个闭环：state → props → 子组件 → 事件 → 改 state → 新 props → ...。数据永远顺着这个圈走，不会抄近路、不会绕回去。

用一张图概括：

   [父组件 state]
        │  props 向下
        ▼
   [子组件 UI]
        │  事件向上（回调）
        ▲
        └── 请父组件 setState

关键点：同一份数据，只有唯一一个「拥有者」（single source of truth）。别人想改，得回到拥有者那里改。

二、一个例子：双向绑定 vs 单向数据流

假设做一个「温度输入」的小组件。先看双向绑定（Vue 风格）的写法：

// 双向绑定：数据模型和视图互相同步
data() {
  return { temperature: 20 };
}

<input v-model="temperature" />

v-model 背后其实是两件事：视图变了改数据、数据变了改视图。数据流是双向的——temperature 能被输入框改，也能被代码改，输入框和变量互相牵着走。

再看 React 的单向写法：

function TemperatureInput({ value, onChange }) {
  return (
    <input
      value={value}
      onChange={(e) => onChange(e.target.value)}
    />
  );
}

这里能清楚看到两条线：

• value 是流进来的数据（父组件说了算）；
• onChange 是流出去的事件（告诉父组件「用户想改成这个值」）。

输入框自己不保存任何状态，它显示什么完全由 value 决定；用户敲键盘时，它只是把「新值是多少」上报出去。改不改、怎么改，是父组件的事：

function App() {
  const [temperature, setTemperature] = useState(20);
  return (
    <TemperatureInput
      value={temperature}
      onChange={setTemperature}
    />
  );
}

同一个 TemperatureInput，可以显示温度，也可以显示价格、库存、任何值——因为它不关心数据是谁的，只负责「展示 + 上报」。数据的归属和流向都无比清晰。

三、React 里数据怎么走：props 向下，事件向上

把上面的模式放大到组件树，就是 React 的核心约定：

function List({ items, onDelete }) {
  return (
    <ul>
      {items.map((item) => (
        <Item key={item.id} item={item} onDelete={onDelete} />
      ))}
    </ul>
  );
}

function Item({ item, onDelete }) {
  return (
    <li>
      {item.text}
      <button onClick={() => onDelete(item.id)}>删除</button>
    </li>
  );
}

• items 从 App → List → Item 一路往下传；
• 删除这个动作，从 Item → List → App 用回调一路往上抛，最后落到 App 的 setState。

Item 从头到尾都没有「删数据」的能力，它只会喊一声「用户点了删除，id 是这个」。真正的数据变更，集中发生在一个地方。

这就是社区常说的口诀："Props down, events up"（数据向下，事件向上）。

顺带澄清一个常见误解：单向数据流不等于「不能有本地状态」。输入框内部可以有 useState 管自己的临时状态（比如未提交的草稿）。单向数据流束缚的是组件之间的数据传递方向，不是禁止组件自己管自己。

四、单向数据流的优势

1. 可预测：数据变，一定是被显式改的

双向绑定里，一个变量可能被 UI 悄悄改掉——你搜遍代码也没找到赋值的地方，最后发现是某个 v-model 干的。单向数据流下，数据的每一次变化都必须经过一次显式的 setState。

一句 setState 调用，就是一次「数据变更点」。要找 bug，顺着变更点找就行，不用怀疑是不是哪个输入框偷偷改了数据。

2. 好调试：状态是快照，容易回溯

因为在 React 里数据是不可变的（改数据是生成新对象，不是原地修改），每个时刻的 state 都是一个独立快照。于是：

• 每次渲染对应一个确定的 state，输入相同、输出相同；
• 可以打日志、可以比较前后两次 state 的差异；
• 出现问题时，能明确回答「当时的 state 是什么」。

双向绑定里数据被持续地原地修改，你很难说清「某一刻它到底是多少」。

3. 易定位：数据来源唯一

同一个数据只有一个「拥有者」，出问题时有个明确的问题归属：这份数据不对，就去看它的拥有者组件。

想象一个 100 行的组件树，某个数字显示错了。单向数据流下你只需从「谁持有它」往上找一层 setState；双向绑定下，可能有五六个地方都能改它，排查范围立刻膨胀。

4. 组件解耦：UI 只管展示和上报

子组件不需要知道数据从哪来、改完会发生什么，它只接收 props、发 onXxx。这让它成为可复用、可测试的纯组件：

// 只依赖 props，与业务无关
function Button({ label, onClick }) {
  return <button onClick={onClick}>{label}</button>;
}

测试时给它传 props、断言渲染结果、模拟点击即可，不用启动整个应用或准备状态容器。

5. 变更可控：性能和副作用有抓手

因为数据变更被收敛到少数几个入口，优化也就有了着力点：知道哪些 state 变了、哪些组件会因此重渲染、能不能用 memo 拦住。双向绑定那种「数据随时在被改」的模型，很难判断到底是谁触发了重绘。

6. 和状态管理天然契合

Redux、Zustand、Jotai 这些库都建立在单向数据流之上：

action → reducer/更新函数 → 新 state → 视图 → 触发 action → ...

数据绕着一个可追踪的圈走，配合开发者工具还能回放每一步 action。这不是巧合——正因为 React 的模型是单向的，才能把「记录每一步变更」做得这么自然。

五、代价：单向数据流没有免费午餐

它也不是没成本，最典型的就是跨层级传数据麻烦。一个深层子组件要用根组件的数据，就得一路 props 往下传，中间的组件哪怕用不到也得转发（俗称 prop drilling）。

React 的应对手段是 Context、以及各种状态管理库——但注意，它们只是换了一种提供数据的方式，并没有破坏单向数据流：数据依然是「从上层来、变更集中在某处」，只是不必再手动一层层传而已。

双向绑定在单个表单里确实更省事，v-model 一行顶 React 好几行。但组件一多、状态一复杂，「省事」就会变成「谁都可能改，谁也不知道谁改的」。单向数据流是用一点样板代码，换来了整棵树的可预测性。

六、小结

是什么：数据从父组件经 props 往下流，子组件通过回调把「想做的变更」往上报，由数据拥有者统一 setState。

怎么用：记住四句话——props down, events up；数据只有一个拥有者；变更集中在一处；组件只读 props、只发事件。

好在哪：

一句话：双向绑定让写单个表单更爽，单向数据流让整个应用更可控。 当应用变大、参与的人变多时，后者省下的调试时间，远超过前者省下的那几行代码。