Vue Teleport 解决了什么问题？适合哪些场景？

简化版

Teleport 可以让组件逻辑仍写在当前位置，但把渲染出来的 DOM 挂到指定容器，比如 body。它适合弹窗、抽屉、通知、Tooltip 等需要脱离父级 DOM 层级和样式裁剪的 UI。

详细版

Teleport 解决的是“逻辑归属”和“DOM 位置”不一致的问题。弹窗从业务组件里触发，状态和事件应该留在业务组件附近；但弹窗 DOM 如果被父容器的 overflow: hidden、z-index、transform 限制，就可能显示异常。

<Teleport to="body">
  <div class="modal">确认删除？</div>
</Teleport>

它不会改变组件父子关系，也不会让状态失效，只是改变真实 DOM 挂载位置。面试中要强调：Teleport 不是状态管理，也不是路由跳转，而是渲染位置搬家。

完整版教学

一、弹窗问题常常不是组件问题，而是 DOM 层级问题

业务组件里写弹窗很自然，因为弹窗是否打开、确认后做什么，都和当前业务有关。但 DOM 层级会带来额外限制。如果父容器有 overflow: hidden，弹窗可能被裁掉；如果父级创建了新的层叠上下文，z-index: 9999 也未必压得过外部元素。

业务组件 Card
└─ div style="overflow:hidden"
   └─ Modal DOM 被裁剪

Teleport 后:
body
└─ Modal DOM 不再受 Card 裁剪

这就是 Teleport 的动机：状态和事件留在组件树里，真实 DOM 放到更合适的位置。它把“谁控制弹窗”和“弹窗挂在哪里”拆开了。

二、Teleport 只搬 DOM，不搬组件关系

很多人误以为 Teleport 会让子组件脱离父组件。实际上 Vue 的组件树关系仍然保持不变，props、emit、provide/inject、生命周期仍按原组件关系工作。改变的是渲染出的真实 DOM 节点插入到哪里。

<script setup>
import { ref } from 'vue'
const open = ref(false)
</script>

<template>
  <button @click="open = true">打开</button>
  <Teleport to="body">
    <div v-if="open" class="modal" @click="open = false">
      关闭
    </div>
  </Teleport>
</template>

上面 open 仍然是当前组件的状态。点击弹窗也能直接修改它。所以 Teleport 更像“渲染出口”，不是新的状态边界。

三、它最适合需要脱离布局流的浮层

常见浮层都容易被父元素影响：弹窗、抽屉、通知、右键菜单、日期选择器面板、Tooltip。这些 UI 视觉上覆盖全局，逻辑上却属于某个局部组件。 Teleport 正好处理这种错位。

场景	是否适合 Teleport	原因
Modal 弹窗	适合	需要覆盖全屏
Toast 通知	适合	通常统一挂到 body
Tooltip	常见适合	避免被 overflow 裁剪
普通 Card 内容	不适合	应保留在原文档流

例如一个表格有 30 行，每行都有“删除确认弹窗”。状态属于每一行操作，但弹窗 DOM 最好统一出现在 body 下，避免被表格容器裁剪。

四、to、disabled 和目标容器要认真处理

to 可以是 CSS 选择器或 DOM 元素。如果目标不存在，渲染会失败或出现警告。在 SSR 或微前端场景里，目标容器的存在时机尤其重要。

<body>
  <div id="app"></div>
  <div id="modal-root"></div>
</body>

<Teleport to="#modal-root" :disabled="isMobileInline">
  <ConfirmDialog />
</Teleport>

disabled 可以临时禁用传送，让内容在原位置渲染。这在调试、移动端局部展开、特殊布局降级时很有用。如果一个页面有 5 类浮层，建议统一规划挂载点，而不是每个组件临时写一个目标。

五、样式和事件仍有边界要注意

Teleport 后，DOM 不在原父元素下面了，所以依赖父选择器的 CSS 可能失效。例如 .card .modal { ... } 在传送到 body 后就匹配不到。更稳的做法是给浮层组件独立类名，或者通过 CSS 变量传主题。

.app-modal {
  position: fixed;
  inset: 0;
  z-index: 1000;
}

事件方面，Vue 组件事件仍按组件关系工作；原生 DOM 事件则按真实 DOM 冒泡。这两个层次要分开理解，否则容易误判点击外部关闭、遮罩阻止冒泡等逻辑。

六、SSR 和可访问性也要一起考虑

SSR 场景下 Teleport 需要服务端和客户端目标一致，否则可能出现 hydration 不匹配。同时弹窗不是只显示出来就完事。它还需要焦点管理、键盘 Escape 关闭、ARIA 语义、背景滚动锁定等配套逻辑。

打开弹窗流程:
保存当前焦点 -> 渲染到 body -> 聚焦弹窗
关闭弹窗流程:
卸载浮层 -> 解锁滚动 -> 焦点回到触发按钮

如果只会写 Teleport to="body"，在工程里仍可能做出难用的浮层。面试回答可以顺手补这些边界，体现你知道它在真实 UI 系统里的位置。

记忆钩子：Teleport 管 DOM 落点，不改组件亲缘；浮层看视觉层级，状态看业务归属。

七、常见误区与追问

误区：Teleport 会让组件状态丢失。 它只改变真实 DOM 挂载位置，组件实例和响应式状态仍属于原组件树。
误区：z-index 足够大就不需要 Teleport。 父级层叠上下文、裁剪和 transform 可能让 z-index 失效。
误区：所有弹出内容都应该传送到 body。 局部展开、普通下拉内容有时应保留在原布局，取决于视觉层级和交互需求。
追问：Teleport 的事件冒泡怎么理解？ 组件事件按 Vue 组件关系，原生 DOM 事件按真实 DOM 位置。
追问：SSR 使用 Teleport 要注意什么？ 目标容器要稳定存在，服务端和客户端结构要能匹配。
追问：弹窗只用 Teleport 就完整了吗？ 不完整，还要处理焦点、键盘、滚动锁定、ARIA 和关闭策略。

八、加强记忆

把 Teleport 记成“浮层出口”。弹窗逻辑仍在业务组件，DOM 却挂到 body 或统一容器。答题时依次说清楚：解决裁剪和层叠问题、只移动 DOM 不改变组件关系、适合浮层、不适合普通内容、SSR 和可访问性要补齐。

简化版

详细版