不推荐在新项目中使用 $parent 和 $refs。它们绕过响应式系统和封装边界，导致隐式依赖、难测试、维护成本高，且在 TypeScript 和 Composition API 下缺乏类型安全与可推导性。
能用，但不推荐在新项目中主动使用。$parent 和 $refs 属于 Vue 的“实例属性”，它们绕过了响应式系统和组件封装边界，容易导致隐式依赖、难以测试、维护成本高，尤其在 TypeScript 和组合式 API（Composition API）场景下缺乏类型安全和可推导性。
为什么 $parent 不再被鼓励
$parent 直接访问父组件实例，打破了父子组件间清晰的 props/events 接口约定：
- 父组件内部实现变更（如重命名方法、调整响应式结构）会静默导致子组件调用失败
- 无法通过模板或 setup() 函数明确看出“子组件依赖父组件哪些能力”，降低可读性
- 在递归组件或动态插槽场景下，$parent 指向可能不符合预期（比如指向父级插槽容器而非语义上的父组件）
- Vue 3 中 setup() 是函数式执行上下文，没有 this，$parent 需通过 getCurrentInstance() 获取，进一步增加间接性和脆弱性
$refs 的适用边界正在收窄
$refs 主要用于手动操作 DOM 或触发子组件方法，但它不是通信机制：
vue-admin-change-reviewer
下载
审查 Vue 管理后台的变更请求（Vue 2 + Element UI，Vue 3 + Element Plus）。重点关注最小化变更实现、上线风险检查以及回归检查清单生成。
- 仅适用于父组件主动调用子组件的命令式方法（如 focus()、play()、resetForm()），不适合状态同步或数据传递
- ref 值在 setup() 中是响应式引用，但子组件暴露的方法若未用 defineExpose 显式声明，在 TypeScript 下会报错或失去类型提示
- 多个 ref 同时存在时易引发竞态（如 v-for 中 ref 未正确绑定到数组项）
- SSR 场景下 $refs 为 null，需额外判断，增加条件分支
更健壮的替代方案
按通信方向和场景选择合适方式：
立即学习“前端免费学习笔记（深入）”；
- 父 → 子：始终优先用 props —— 包括响应式对象、计算属性、函数（作为回调传入）。配合 toRef / toRefs 保持响应性，避免解构丢失响应性
- 子 → 父：用 emits 定义事件 —— Vue 3 要求在 emits 选项中显式声明，支持类型推导；子组件通过 emit('update:modelValue', value) 实现 v-model 语法糖
- 跨层级（非祖孙强耦合）：用 provide / inject —— 适合主题、国际化、全局配置等“环境型”状态，避免层层透传；inject 支持默认值和类型断言
- 复杂状态共享：用 Pinia（推荐）或 useStore 组合式 store —— 解耦组件与状态，支持模块化、持久化、时间旅行调试，天然适配 TS
- 临时 DOM 交互：仍可用 $refs，但需加防御性检查 —— 如 inputRef.value?.focus()，并确保 ref 绑定在 onMounted 后执行
迁移建议：从 $parent/$refs 到显式契约
重构旧代码时，可逐步替换：
- 将 $parent.xxx() 调用，改为父组件通过 props 传入一个函数，子组件直接调用
- 将子组件通过 $parent 修改父数据，改为子组件 emit 事件，父组件监听后更新自身 state
- 将 $refs 调用子组件方法，改为子组件在 defineExpose 中暴露方法，并在父组件中用 ref 类型标注（如 const childRef = ref
| null>(null)） - 对深层嵌套通信，评估是否真需要穿透多层 —— 很多时候拆分子组件 + 提升状态到共同父级更清晰
