不建议在子组件直接修改 Props，这是为保障单向数据流这一响应式系统运行基础；基本类型修改仅触发警告且不影响父组件，引用类型修改则导致静默污染；直接修改还会破坏组件可测试性、可复用性与封装性。
不建议在子组件直接修改 Props，核心是为了守住单向数据流这条“生命线”。它不是一条限制开发自由的规则，而是 Vue 保障状态可追踪、组件可复用、Bug 可定位的关键设计。
单向数据流不是约定，而是响应式系统的运行基础
Vue 的响应式更新依赖明确的数据所有权。父组件是 props 的唯一来源和权威，它的 data 或 computed 改变时，会触发重新渲染，并把新值“推”给子组件。如果子组件反向篡改 props，系统就无法判断：这个变化该不该触发父组件更新？该不该影响兄弟组件？该不该重置本地状态？这种不确定性会直接瓦解响应式链条。
尤其在嵌套较深的组件树中，一个被随意修改的 prop 可能同时被多个子组件读取——有的监听了，有的没监听；有的做了缓存，有的实时计算。一旦源头失守，整个视图一致性就会崩塌。
基本类型和引用类型的修改后果完全不同
看似都是“改 props”，但 JS 类型机制让实际影响天差地别：
-
基本类型（string/number/boolean）：子组件赋值操作（如
this.count = 5）会触发控制台警告，且只改了本地副本，父组件完全无感； -
引用类型（object/array）：直接改属性（如
this.user.name = '张三'）往往不报错，但父组件的原始对象已被污染，后续任何基于该对象的计算或渲染都可能出错，而且难以察觉。
后者更危险——它绕过了 Vue 的警告机制，却实实在在破坏了单向语义，属于“静默污染”。
直接修改会切断组件的可测试性与可复用性
一个健康的子组件应当像函数一样：输入确定，输出确定，无外部副作用。一旦它开始修改传入的 props，就等于悄悄改变了父级作用域的状态。这意味着：
- 同一个子组件，在不同父组件中行为可能不一致；
- 单元测试时，你必须模拟整个父组件上下文，而不能只喂数据测渲染；
- 组件文档里不敢写“本组件只读 props”，因为你不知道它暗地里动了什么。
封装性一旦被打破，组件就从“乐高积木”退化成“胶水补丁”，越用越重，越改越怕。
真正的保护机制：Vue 在开发模式下主动拦截 + 设计哲学约束
Vue 并非靠技术手段彻底禁止修改（比如 Object.freeze 所有 props），而是采取更务实的策略：
- 对基本类型 props 的直接赋值，通过 defineProperty 或 Proxy 拦截并抛出明确警告；
- 对引用类型内部属性的修改，虽不拦截，但通过文档、工具链（如 ESLint 插件）、TypeScript 类型提示反复强调其危害；
- 提供 v-model、.sync、defineModel 等语法糖，把“子改父”的意图显性化、标准化，让通信路径一目了然。
这套组合拳的目的不是束缚开发者，而是把“谁该负责什么”刻进协作契约里——父组件管状态，子组件管交互，边界清晰，责任落地。
