computed 不重要，await 是为了强调这是一个带副作用的操作，也是 useEffect 应该使用的场景。重点的变化是状态的变化，P 发生变化的时候 d1，w1 里直接让状态变化成 d2，触发 w2 时的状态是 d1、但执行的状态是 d2。

react 这边不管 e1 还是 e2，触发的时的状态是 d1，执行时的状态也是 d1。

把控件的更新过程看做一个周期的话，react 整个周期里 state 是一致的。useEffect 的应用场景是副作用，所以如果在 useEffect 里面更新了状态，是会触发重绘的。vue 在一个周期内，state 是不断变化的，所以流程不像 react 那么简单。

另外，useEffect 是在 dom 更新后执行，watcher 是在更新 dom 之前执行，这俩东西不论是原理还是触发时机都是不一样的。你前面偏偏要把 useEffect 弄成 watcher 的样子用，所以我不得不设置一些障碍避免对 setCounter 不合理的使用方式。

reducer 到底是要 d1、d2、d3 的结果也不重要，因为这是一个纯函数，给定确定的参数就能得到相同的结果。想要什么结果都是很容易写测试的，以后不管怎么改 useEffect 都不影响结果的正确性。vue 这边因为一个更新周期里 state 是不断变化的，computed 的计算变了，watcher 的逻辑变了甚至只是调整了一下 watchers 的顺序，bug 就又回来了。

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 还是没特别明白。。你这个例子里面computed很关键吗？await很关键吗？我不觉得这个例子里面“取得的d1的值是完全合理的选择”，因为就这个例子的逻辑而言，如果取得的是d1，那相当于w2把w1的效果给覆盖掉了，一般来说会是一个bug，和你下面react那里说的那个bug是一个道
: let prevD
: watch([C,D], ([c2,d2], [c1,d1]) => { // 同时 watch c 和 d
: ...................
--
修改:eGust FROM 101.98.83.*
FROM 101.98.83.*