我还是举一个例子吧，比如我们有这么一类 form 控件
props: { target: Object, name: String, ... }
computed: { value: { get() { return this.target[this.name] }, set ... } }

父控件把 data 中的对象和名称传给子控件，<child :target="foo" name="bar" />，子控件使用 v-model="value"，然后在 set 里做比较，决定要不要放入待传回的数据中。上周同事问了我一个问题，为什么明明我在父控件里 this.foo.bar = baz，结果这个字段却没出现？他期待子控件 computed.value.set 会被调用……

如果用 react，父控件不得不再传一个调用 setState 的方法进去，更新之后的 target 也是一个全新的对象，你觉得还能问出来这种问题么？

react 故意设计成所有的对象都应该 immutable，想有属性变化就得重新生成一个，这样你不得不去关注数据的流向。vue 的做法的确是 gc 压力小了，上 proxy 之后效率比生成新对象高更多了。但是双向数据绑定的弊病也出来了：多个源都可以去更新同一个对象，数据的流向变得难以追踪。

还是老话，对于使用者来说，并不在意内部实现是怎样的。vue 比 react 加载快了多少，内存少占用多少，复杂的页面能多画几帧，并不是那么重要。跟正确性相比，代码写得更费劲、效率低了，都不是大的问题。java 跟 c++ 比起来，不光跑得慢，还更啰嗦（不造轮子的话），但是人家不容易啰嗦错啊。

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 我觉得咱俩说的东西本质是一样的。
: react为什么走functional单向数据流路线？不是因为它的props和state技术上无法被直接赋值修改，本质原因是因为它的reactivity机制是检测不到直接赋值的，所以必须走setState（）之类的显式触发，整体重新生成vdom然后diff。
: vue的data为什么不需要setData（）？因为用了proxy/setter呗，所以也就没有必要非要使用单项数据流了。
: ...................
--
修改:eGust FROM 125.238.192.*
FROM 125.238.192.*