Vite 热更新（HMR）时，若子组件在 setup 阶段直接触发 emit 通知父组件更新响应式数据，会导致父组件重渲染 → 子组件重新挂载 → 再次 emit → 无限递归更新，最终抛出 “Maximum recursive updates exceeded” 警告。
vite 热更新（hmr）时，若子组件在 setup 阶段直接触发 emit 通知父组件更新响应式数据，会导致父组件重渲染 → 子组件重新挂载 → 再次 emit → 无限递归更新，最终抛出 “maximum recursive updates exceeded” 警告。
该问题本质是副作用执行时机不当引发的响应式循环依赖，而非 Vue 或 Vite 的 Bug。在你提供的示例中，Child1.vue 在 <script setup></script> 同步执行 emits('list-change', [...])，而 App.vue 中 list 是响应式引用（ref），一旦被修改就会触发视图更新；由于 Child2 依赖 list，整个 <template></template> 会重渲染，进而导致 Child1 组件实例被销毁并重建 —— 重建后又立刻再次执行 setup 中的 emit，形成闭环。
✅ 正确做法是：将事件触发逻辑从同步初始化移出，延迟至合适的生命周期或用户交互时机。
✅ 推荐解决方案
方案一：使用 onMounted（最常用且语义清晰）
确保事件仅在组件挂载完成、DOM 可用后触发一次，避免与父组件初始渲染耦合：
<!-- Child1.vue -->
<script setup lang="ts">
import { onMounted } from 'vue'
const emits = defineEmits(['list-change'])
onMounted(() => {
console.log('Child1 mounted → emitting list-change')
emits('list-change', ['a', 'b', 'c'])
})
</script>⚠️ 注意：
onMounted仅在客户端有效；若项目启用 SSR，请配合onActivated或条件判断if (typeof window !== 'undefined')。
vue-component-analyzer下载递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
立即学习“前端免费学习笔记（深入）”；
方案二：封装为事件处理器（适合用户触发场景）
当业务逻辑本就应由用户操作驱动（如点击按钮加载数据），显式绑定到 DOM 事件更合理、更可控：
<!-- Child1.vue -->
<script setup lang="ts">
const emits = defineEmits(['list-change'])
const triggerUpdate = () => {
console.log('User triggered list update')
emits('list-change', ['a', 'b', 'c', 'k', 'o'])
}
</script>
<template>
<button @click="triggerUpdate">Refresh List</button>
</template>❌ 错误写法（务必避免）
// ❌ 危险！setup 同步执行，HMR 保存即触发，引发无限循环
emits('list-change', ['a', 'b', 'c'])? 补充说明：为什么 HMR 会放大这个问题？
Vite 的 HMR 在文件保存时会局部卸载并重载组件模块，但不会重置父组件的响应式状态。因此：
- 初始加载：App → Child1（emit）→ App 更新 list → Child2 重渲染 → Child1 重建（此时未 HMR）✅
- 首次保存 Child1.vue：HMR 强制重载 Child1 模块 → 新 setup 执行 → 再次 emit → App 再次更新 → 循环重启
- 控制台出现大量重复日志（如 101 次）正是 HMR 不断介入该循环的直观表现。
✅ 最佳实践总结
- ? 响应式数据变更应由明确的触发源（用户操作、定时器、生命周期钩子）驱动，而非模块初始化；
- ? 避免在
defineProps/defineEmits后直接执行有副作用的响应式写入或事件派发； - ? 使用
onMounted、onActivated或事件绑定替代同步副作用； - ? 开发阶段留意控制台警告 —— “Maximum recursive updates exceeded” 是典型的响应式死循环信号，需立即排查
watch、computed、emit和ref赋值链路。
通过规范副作用执行时机，即可彻底规避该问题，同时提升组件的可预测性与可维护性。
