子组件修改Vue prop有何风险？是否存在版本兼容隐患？

首先说你关心的版本兼容问题：

• 未来Vue基本不可能直接禁止修改prop的操作。官方现在只把这个行为定义为不推荐的反模式，没有做语法层面的强制拦截，本质是单向数据流是架构设计约定，不是技术实现上的硬性限制。但你看到大家提到的“父组件重渲染会损坏数据”不是危言耸听，这是Vue从2到3一直存在的既定逻辑：只要父组件触发重渲染，就会用最新的prop值覆盖子组件里对prop做的所有修改。你现在觉得代码跑着没问题，只是还没碰到触发覆盖的场景而已，这类bug藏得极深，往往上线后遇到特殊操作路径才会爆，排查起来非常麻烦。
• 不存在“版本迭代只兼容规范写法”的刻意兼容问题，但如果你一直用反模式写法，后续Vue做内部逻辑优化的时候，这类依赖非约定行为的代码确实更容易出意料之外的问题，毕竟官方不会给反模式做兼容保障。

然后说深层属性修改要层层透传emit的痛点：

• 实际开发没人会硬写每层emit透传，大家都有更省事的落地方案：
  • 简单父子组件场景直接用双向绑定语法，Vue 3.4+用defineModel()，旧版本用v-model/.sync修饰符，不用写一堆冗余的事件监听代码。
  • 跨多层组件共享的状态直接上状态管理，Vue3用Pinia、Vue2用Vuex，把需要跨组件改的状态抽到全局store里，哪个组件要读要改直接操作store，完全不用顺着组件层级传值传事件。
  • 要是碰到不好改的老代码，至少在子组件里把传入的引用类型prop做一次深拷贝存到本地状态再改，等合适的时机再同步给父组件，别直接改prop原对象的属性，能避开大部分重渲染覆盖的坑。

最后说实际开发里直接改prop的情况有多普遍：

• 小项目、赶工期的老项目里这种写法真不算少见，毕竟直接改prop写起来最快，短期跑起来也没明显问题。但只要是维护周期超过半年的中大型项目，基本都会明确禁止直接改prop——这种写法会彻底打乱状态流向，后面出问题你根本找不到这个值到底是在哪一层组件被改掉的，维护成本会指数级上升。

官方提到的“强耦合父子组件可以例外”，指的是类似下拉框和下拉选项、表格和表格行这种从设计上就绑定在一起、拆开根本没法独立使用的组件，不是给普通业务组件直接改prop开绿灯。

如果你们团队现在已经有大量这类代码，不用急着停下来全量重构，下次迭代碰到对应模块的时候顺手调整成规范写法就行，新写的代码尽量别再直接改prop，慢慢把这部分技术债填上就行，省得后面赶版本的时候碰到莫名其妙的值被覆盖的bug，加班排查都找不到头。

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