惯性思维
一开始看到vue说是双向绑定的，就自动认为数据流向也是双向的，后来发现我错了。
以前的想法是：我给你，你给我，这就是双向绑定，同时也是双向流动，但是vue不是这么干的。那么vue是怎么做的呢？
抛物线的单向数据流
为了便于说明，画个图先：
步骤：
- 在父组件里面定义一个 info
- 在子组件里面定义一个 props 接收
- 子组件内部使用 emit “修改”props
- 模板重新渲染
看表面效果：
- 父组件修改info，父组件、子组件同时响应。
- 在子组件修改info(props)，父组件和子组件也是同时响应
这不就是双向流动吗？
但是实际情况并不是这样的。
实际情况
表面上看，emit 是在子组件写的，但是具体的赋值操作并不是在子组件里执行的。
看上图里面的1,2,3，特意调整了字号和颜色，应该很明显吧。这是一个“抛物线”，兜了一个圈子才实现了修改。
缘由
那么为啥要这么折腾呢？大概是因为响应性吧。
以前有个段子，不能给邮箱设置“自动回复”功能，如果设置了可能会这样：
比如我给你发了一个邮件，你的邮箱服务会自动给我发送一个“已收到”的反馈。
然后我的邮箱服务收到你的反馈后，认为是收到了新邮件，于是又给你的邮箱发了一个“已收到”的反馈。
于是开始了无限循环。
那么vue是否也有类似的麻烦呢？不太清楚。
但是从设定来看，大概是为了避免这样的问题吧。
直接修改，又是咋回事？
不是规定子组件不能直接修改props吗？怎么还来个直接修改，违规了！
经常看到这样的说法，其实并不是这样的。
这里特指vue3，vue2没研究过。
在 vue3 里面 vuex 的状态是 proxy 的。
子组件的 props 也是 proxy 的，并且把第一层属性设置为只读，这样在子组件里面就无法直接修改第一层属性。
但是留了个“缺口”，没有限制第二层属性也是只读，这样的话我们就可以利用这个漏洞做点骚操作。
比如 info 定义为：
const dialog = reactive({
visible: false,
width: '80%'
})
子组件的 props 定义为这样，然后可以这样操作：
const props = defineProps({
moduleId: [Number, String],
dialog: Object
})
const dialogs = props.dialog
熟悉 el-dialog 的话，就会发现我想做什么了吧。
<el-dialog
:title="'添加模块：' + props.moduleId"
v-model="dialogs.visible"
:width="dialogs.width"
>
我喜欢在父组件里面放一个按钮，然后把 el-dialog 放到一个子组件里面，这样父组件的代码不容易乱，单击父组件的按钮，可以打开 el-dialog。
但是问题来了，是否显示是通过 v-model 来设置的，而子组件的 v-model 不允许直接写 props。
一般的做法是写一个 computed ，设置 get 和 set，
get 获取 props 的属性，set 里面用 emit 来提交。
但是这样做很麻烦有没有。
于是我“直接”修改了，我觉得代码就应该直接一点。（emit 内部代码比较复杂，我没看懂，断点跟踪都没跟下去）
可能有人就不乐意了，你这是瞎干，违规了！
看看上面的图，proxy 会拦截 set 操作，然后实际修改值的操作在哪里呢？肯定不在子组件。
既然不是在子组件里修改的，那么这么做也没有违规，和使用 emit 是一样的原理。
使用emit是合规的吧。
补充，proxy 的 set 到底在哪里？
按F12看一下源码，可以找到 proxy 的 set 的位置，在一个单独的js文件里面，那么怎么算呢？应该看js文件是在哪个组件里面引入的。
看看代码，是不是在父组件写的import { reactive } from 'vue'，所以修改操作实际发生在父组件，和emit是一样的原理。
不解
props 本身就是一个 proxy ，拦截一下就可以在父组件进行修改，那么为啥还非得使用 emit 绕圈圈呢？（不会又是为了向下兼容吧）
如果你想说，这样无法跟踪，不知道哪个子组件修改了，的话，那么可以看看上一篇：
使用proxy 给状态加一个跟踪功能： https://www.jianshu.com/p/c8b0d5c8ef42
