企业官网建设流程全解析

1. 从"图片弹窗跑偏"说起：一个几乎人人都能遇到的表格图片预览问题

如果你用 element-plus 开发过后台管理系统，大概率在 el-table 里放过图片列。最常见的做法就是在表格列中塞一个 el-image，配上preview-teleported开启点击预览，弹窗一开，大图浏览、缩放、旋转都有了，体验很完整。

但问题也出在这：当你把 el-table 放在页面中间、图片列位于表格右侧、又或者表格外层有滚动容器时，点击小图弹出的预览大图经常跑偏——弹窗没有出现在屏幕正中央，而是错位到了表格所在的位置，甚至在滚动了页面或表格之后，弹出的图片位置完全乱掉。更诡异的是，桌面端 Chrome 下一切正常，换成某个特定版本浏览器或者在某些弹窗嵌套场景下，错位现象又复现了。

这个问题的本质，不是 el-image 组件坏了，而是 element-plus 的弹层机制（popper 机制）在 el-table 特定布局下的position: relative定位上下文里发生了错位。网上中文资料里对这个问题的讨论很零散，多数帖子都是片段式的提问，回答也含混，很多人绕了一大圈改成自定义 lightbox 组件或者直接放弃预览功能。

这篇文章不打算只给一句"加个 teleported 就好"的结论。我会把 el-image 预览弹窗定位机制拆开讲清楚，再带你复现整个排查链路，最后给出几套经过实测的修复方案和防御策略。文章面向用过 element-plus 但没深究过弹层机制的前端开发者，也适合正在被这个 bug 折磨、想直接抄方案的同学。

2. 错位重灾区：这三个场景最容易踩雷

先明确一下，不是所有 el-table 里的 el-image 都会错位。我复盘了自己项目里踩过坑的案例，以及社区里高频出现的反馈，发现场景高度集中在以下三类。如果你还没遇到这个 bug，先对照一下自己的页面结构，大概率能提前避开。

2.1 表格外层存在滚动容器（最常见）

页面结构往往是这样的：el-table 被一个.content-area这样的 div 包裹，这个 div 设置了overflow: auto或者overflow-y: scroll，例如常见的后台管理页布局：

<div class="page-wrapper"> <div class="filter-bar">...</div> <div class="table-wrapper" style="height: calc(100vh - 180px); overflow: auto;"> <el-table :data="tableData"> <el-table-column label="图片"> <template #default="{ row }"> <el-image :src="row.imgUrl" preview-src-list="previewList" /> </template> </el-table-column> </el-table> </div> </div>

这种结构下，点击预览时弹窗定位基准会变得非常不可控。原因很简单：popper 的定位需要依赖参照元素的矩形位置，而滚动容器的存在，让这个"位置"在滚动前后产生漂移。再加上如果 el-table 自身也有纵向滚动条，表格内部的内容区实际上是在一个overflow: hidden的环境里渲染的，el-image 所在的单元格元素在滚动时offset 值会变，popper 计算出的 left/top 就是旧值。

我实测过的一组复现数据：当页面不滚动时，弹窗位置正常；把表格滚动条往下拖 200px 再点击预览，弹窗会整体上移约 200px（有时候是上移半个屏幕）。这就是典型的"弹窗定位没有随内容滚动而重新计算"的表现，尤其当position: fixed的定位元素没有放在 body 下时，甚至会出现弹窗跟随被滚动"留白"的情况。

2.2 el-table 列宽较大且带固定列（fixed）

el-table 的 fixed 列实现原理是把固定列拷贝一份渲染到独立的层里，原列则通过 transform 进行位移模拟滚动。这一套机制本身很强大，但它制造了一个"双重元素"的现实：同一个图片单元格，在 DOM 里可能存在两份（原列一份、fixed 层复制一份）。

一旦你把 el-image 放进固定列（比如常见的左侧缩略图列），点击图片预览时 el-image 内部会用它的根元素作为定位参照。由于 fixed 列存在克隆元素，popper 拿到的参照元素可能是被 transform 位移后的克隆节点，计算出的 left 值自然偏了。具体表现是：预览弹窗出现在表格差不多位置，但水平方向总是差一截，滚动表格时还会跳。

2.3 自定义弹窗/Dialog 内嵌表格再嵌套 image

多级弹层嵌套是另一个重灾区。我见过不少项目，点击按钮打开一个 el-dialog，对话框里放表格，表格里又有图片列。这种场景下，el-image 预览弹窗的层级和定位基准都比较混乱，因为 el-dialog 默认渲染在 body 下，但它内部元素的定位上下文和 z-index 环境被 dialog 的 overlay 和 popper 机制双重影响。

实际表现往往有两种：一种是预览图出现在 dialog 背后，完全看不见（z-index 低于遮罩）；另一种是弹窗出现在 dialog 内部的相对位置而不是屏幕中心。两者的根因都是"弹窗最终被挂载到了非预期容器"或者"定位计算参照了非预期元素"导致的。

提示：如果你在真实项目里跑一下，会发现这三种场景往往交叉出现——外层滚动容器 + 固定列 + 弹窗内表格，三者叠加时 bug 概率几乎 100%。这也是为什么网上很多人反馈"同一个项目里有的页面有这个 bug，有的页面没有"，本质上就是页面结构不同导致的定位上下文差异。

3. 错位的底层机制：preview-teleported 为什么救不了你

在给出方案之前，必须把 el-image 预览弹窗的定位原理吃透。不然你就算今天照着改好了，明天换个布局结构又会炸。

3.1 谁在负责弹窗定位

Element Plus 的弹层类组件绝大多数复用了一个内部工具，官方文档里通常叫 popper。它的核心逻辑是：弹层要挂载到某个容器（默认是 body），然后根据**触发元素（reference）**在视口里的位置，计算出弹层应该出现的坐标，通常用绝对定位（或者 transform）来摆放。

el-image 的预览功能本质上就是套了一层 popper 机制：内部维护了一个预览弹层状态，点击预览时，把预览内容挂到某个容器上，再用 el-image 根元素的位置去计算预览弹层的 left/top（通常是让预览弹层在屏幕居中）。这个"居中"不是简单的left: 50%; top: 50%; transform: translate(-50%, -50%)，而是通过 JS 实时计算，因为在预览图片前，弹层是display: none的，无法用纯 CSS 保证居中。

这里就有一个关键参数：referenceEl。它决定了"以哪个元素的位置作为鼠标点击时的定位基准"。在 el-image 内部，这个 referenceEl 通常是 el-image 组件的根 DOM 元素，即包裹 img 的那个 div。而问题恰恰就出在：这个根元素坐落在 el-table 内。el-table 的 DOM 结构相当复杂，内部滚动区、固定层、遮罩层一应俱全，根元素的位置会受到这些层的影响。

3.2 teleported 做了什么事

再看preview-teleported这个属性。它的作用是控制预览弹层是否通过 Teleport 挂载到 body 下。preview-teleported为 true 时，预览弹层的 DOM 挂载到 body 下，脱离 el-table 的层级约束，z-index 层级关系也会更干净；为 false 时，弹层可能直接被放在 el-table 内部，导致溢出容器被裁剪或出现层级错乱。

但注意：teleported 只解决了"弹层挂在哪里"，并没有解决"定位坐标怎么算"。如果内部使用的 referenceEl 本身定位不准（比如它被固定列 transform 位移过，或者外层滚动容器的滚动偏移没算进去），即便挂到 body 下，弹层最终显示的坐标还是错的。

这也就解释了为什么网上大量回答说"加 preview-teleported 就好了"，但在固定列、多级弹窗场景下依然无效——因为治标不治本，只是提升了层级优先级，没有修正坐标计算。

3.3 为什么同一个问题在表格里特别明显

放一张图对比：页面上普通的按钮、卡片内图片，点击预览，referenceEl 就是一个静态的、无 transform 的 div，定位简单可靠；但在 el-table 里，referenceEl 同时受三股力量影响：

这三者叠加，就导致了五花八门的"错位"表象。

4. 先别急着改代码：5 分钟复现与自检流程

很多人在 stack overflow 和中文社区里问"为什么我的不行"，其实连复现步骤都没描述清楚。我建议你先花 5 分钟做一个最小复现，确认错位属于哪一类，再决定用下面哪套方案。盲目改代码往往会越改越乱。

4.1 最小复现模板

你可以在一个干净的 vue 页面里直接贴这个模板：

<template> <div class="demo-page"> <div class="scroll-area" style="height: 300px; overflow: auto;"> <el-table :data="tableData" style="width: 800px; margin-top: 200px;"> <el-table-column label="图片" width="120"> <template #default="{ row }"> <el-image style="width: 60px; height: 60px" :src="row.url" :preview-src-list="previewList" preview-teleported /> </template> </el-table-column> </el-table> </div> </div> </template> <script setup> import { ref } from 'vue' const tableData = [ { url: 'https://example.com/1.jpg' }, { url: 'https://example.com/2.jpg' }, ] const previewList = tableData.map(item => item.url) </script>

这个模板把最典型的"外层滚动容器"场景复现出来了。如果你的错位在这个模板里就能稳定复现，说明是 popper 定位计算与外层滚动容器冲突；如果这个模板正常，再加 fixed 列、再套 dialog 逐步复现。

4.2 判断错位类型的三个特征

1. 弹窗和图片错位差距等于滚动距离：这类错位最有规律，说明是滚动偏移未参与计算，优先启用"重建弹窗"方案（见第 5 节）。

2. 弹窗位置忽左忽右，且只有固定列图片会错：典型 fixed 列克隆引用问题，优先加"定位基准重设"方案。

3. 弹窗看不见或者被遮罩盖住：优先排查挂载容器和 z-index，启用"手动挂载 + 层级控制"方案。

按这三个特征归类后，再对症下药，效率高很多。我在实际项目里见过太多人一上来就全项目搜索"popper"配置，改了 N 处都不对症。

5. 实测有效的四个解决方案（按推荐顺序）

下面进入正题。我给每个方案都标了适用场景、改动量、风险等级，方便你对号入座。

5.1 方案一：直接禁用内置预览，手写一个"看似一样"的预览弹窗

适用场景：所有错位问题；改动量：中；风险：低。这是最推荐的做法，但也是网上几乎没人系统讲过的一条路。很多人一听说"手写预览弹窗"就退缩，其实 el-image 的预览核心功能就是看大图、缩放、旋转、切换，这些用 element-plus 现成的组件完全可以拼出来。

思路很简单：el-table 里只放一个小图（el-image 不带 preview 属性），点击时自己维护一个全屏遮罩层，遮罩层里放一个大的 el-image（或者直接用 img 标签），外加自己写的切换按钮。因为遮罩层、大图都是你自己控制的，可以轻松放在<Teleport to="body">里，定位就是最简单的position: fixed; inset: 0;，和 element-plus 的 popper 机制完全脱钩，根本不存在错位问题。

我给个可以直接抄的精简实现：

<template> <div> <el-table :data="tableData"> <el-table-column label="图片"> <template #default="{ row }"> <el-image style="width: 60px; height: 60px" :src="row.url" @click="openPreview(row.url)" /> </template> </el-table-column> </el-table> <Teleport to="body"> <div v-if="previewVisible" class="my-preview-overlay" @click.self="previewVisible = false" > <el-image :src="currentPreviewUrl" fit="contain" style="width: 80%; height: 80%" /> <button class="my-preview-close" @click="previewVisible = false">关闭</button> </div> </Teleport> </div> </template> <script setup> import { ref } from 'vue' const previewVisible = ref(false) const currentPreviewUrl = ref('') const openPreview = (url) => { currentPreviewUrl.value = url previewVisible.value = true } </script> <style scoped> .my-preview-overlay { position: fixed; inset: 0; background: rgba(0, 0, 0, 0.7); display: flex; align-items: center; justify-content: center; z-index: 3000; } .my-preview-close { position: absolute; top: 20px; right: 30px; background: rgba(255, 255, 255, 0.2); color: #fff; border: none; border-radius: 4px; padding: 8px 16px; cursor: pointer; } </style>

这样就把定位基础从"计算坐标"变成了"相对视口铺满全屏"，还兼容任何滚动容器、固定列、多级弹窗。如果你想要 hot key（左右切换上一张下一张），自己绑定键盘事件也简单。

为什么我把它列为第一推荐？因为 element-plus 的 el-image 内置预览本质上是给页面中"独立、无复杂布局"的图片用的，拿到表格这种复杂 DOM 环境里本身就有点水土不服。绕开它，所有不确定性都没了。代价是你要自己实现一点交互细节，但这点成本换来的稳定性非常划算。

5.2 方案二：利用预览弹层的实例，弹窗打开后主动"校准坐标"

适用场景：不想改动 el-image 使用方式，必须保留内置预览交互（缩放、旋转、切换）；改动量：低；风险：中。

这个方案的核心是：在弹窗打开之后，手动获取元素位置并强制修正 left/top。因为 preview-teleported 只负责挂载位置，不负责坐标修正，所以我们得自己动手。

一个可行思路是监听 el-image 的点击，然后延时（等弹层渲染完成后）通过 DOM 查询找到预览弹层容器，重新设置它的样式。打开预览时，有一个暴露的 show 方法或者@click事件，但在 el-image 组件上，并没有官方文档级别的"预览打开后回调"，不过可以通过 hack：监听 el-image 组件的 DOM 结构变化，或者用一个延迟 setTimeout 在点击后捕获预览层。

更稳妥的做法是：自己控制图片点击，调用 el-image 内部的showPreview方法（这是一个在组件内部存在的方法，未被文档公开，但在社区里已被广泛验证可调），然后在nextTick后再拿弹层 DOM 手动居中。

实际代码大致长这样：

<template> <el-image ref="imgRef" :src="row.url" :preview-src-list="previewList" @click="handlePreview" /> </template> <script setup> import { nextTick, ref } from 'vue' const imgRef = ref() const handlePreview = async () => { // 触发内置预览打开 imgRef.value?.showPreview?.() // 等预览层渲染进 DOM await nextTick() // 找到预览层容器（需要通过调试工具确认挂载位置和类名，通常在 body 下） const previewEl = document.querySelector('.el-image-viewer__wrapper') if (previewEl) { // 强制复位为视口居中 previewEl.style.left = '0px' previewEl.style.top = '0px' previewEl.style.transform = 'none' // 如果你需要水平垂直居中，可以自行用 flex 或算坐标 } } </script>

这个 hack 有一个不稳定点：Element Plus 内部类名在版本迭代中可能变化，比如.el-image-viewer__wrapper这个类名在 2.x 不同小版本里基本一致，但未来不保证。另外，showPreview 是内部方法，官方可能调整签名。

所以这个方案更适合"我没办法大改组件，但有时间做一个针对性兼容"的项目。我在自己的一个老项目里就用过它，配合内部类名稳定，效果还行。但如果你的项目预算允许，我还是更建议你走方案一。

5.3 方案三：给预览弹层指定一个"干净的挂载容器"并配置位置偏移

适用场景：错位的直接原因是挂载容器层级混乱，而非坐标计算；改动量：低；风险：中低。

Element Plus 的很多弹层组件支持通过append-to-body或者 popper 配置指定挂载节点。el-image 的预览虽然不像 el-tooltip 那样暴露一个明确的popper-class、append-to属性，但我们可以从"挂载位置"入手兜底。

做法：在项目的全局样式中，强制给预览弹层加上：

.el-image-viewer__wrapper { position: fixed !important; top: 0 !important; left: 0 !important; right: 0 !important; bottom: 0 !important; }

这是最暴力的一个方法，但实测对大量"预览层挂到了奇怪的容器"导致的错位有奇效。它把预览层从"绝对定位按坐标摆放"变成"固定铺满视口"。这和方案一类似，却保留了内置的预览交互，因为预览层内部的图片展示、切换、旋转按钮还是 element-plus 自己的。

不过，这条 CSS 有个前提：预览层必须已经挂载到了 body 或者一个不随页面滚动的容器下，否则position: fixed依然会被祖先的 transform 或filter破坏。如果你的预览层还挂在表格内部，这条 CSS 很可能无效，需要配合preview-teleported把挂载点改到 body。

所以这个方案的完整版是：

<el-image :src="row.url" :preview-src-list="previewList" preview-teleported />

加一条全局样式：

.el-image-viewer__wrapper { position: fixed !important; top: 0 !important; left: 0 !important; right: 0 !important; bottom: 0 !important; }

这个方案非常省事，我建议作为"快速止血"手段。如果你的项目是组件库、低代码平台，不方便在业务代码里大改，全局样式的方式很合适。风险点在于：Element Plus 预览层内部如果有计算偏移的逻辑，可能与fixed叠加产生额外间隙，需要实测微调；另外如果改了内部样式，升级 Element Plus 版本时要回归测试。

5.4 方案四：避免在表格里直接放 el-image，改用"单元格内小图 + 弹窗展示大图"结构

适用场景：布局无法大改，但希望最小侵入，且你不想写手写弹窗全套交互；改动量：低；风险：低。

这个方案的思路是利用"分离触发元素和预览内容"来绕开定位问题。表格里只放一个不能预览的小图，在表格旁边或页面上方的固定区域放一个专门用于预览大图的容器。点击小图，把大图传过去，再由这个固定容器负责展示。这本质上还是方案一的变体，但更贴合"表格展示 + 预览区分离"的场景。

它可以有两种落地形式：

1. 表格上方固定一块"当前选中图片预览区"，点击行内缩略图，大图出现在上方区域，不覆盖表格。
2. 在页面级做一个右侧抽屉（el-drawer），点击缩略图后抽屉里显示大图和详情信息。

这种做法在后台管理场景里意外地好用——因为很多表格图片本质上是产品图、物料图、用户头像，点击后往往还要看关联信息或处理业务操作。用一个预览抽屉不仅解决了错位 bug，还给了业务操作更多空间。缺点是交互上不再是"覆盖全屏的大图预览"，如果你产品设计上坚持要全屏看大图，可以结合方案一。

<template> <div> <el-table :data="tableData" @row-click="selectRow"> <el-table-column label="图片"> <template #default="{ row }"> <el-image style="width: 60px; height: 60px" :src="row.url" fit="cover" /> </template> </el-table-column> </el-table> <el-drawer v-model="drawerVisible" title="图片预览" size="360px"> <el-image v-if="selectedRow" :src="selectedRow.url" fit="contain" style="width: 100%; height: 400px" /> </el-drawer> </div> </template> <script setup> import { ref } from 'vue' const drawerVisible = ref(false) const selectedRow = ref(null) const selectRow = (row) => { selectedRow.value = row drawerVisible.value = true } </script>

这种方法我经常在一些中后台项目里推荐，因为它的扩展性特别强——预览区还能放"下载原图"、"查看审核记录"等按钮，产品功能会变得丰富很多。

6. 高级排错技巧：如果这四套方案都不生效，问题可能不在 el-image

总有一部分项目比较"个性"：四个方案全试了，弹窗还是错位。这时候别在 el-image 上钻牛角尖了，大概率是你的项目里有更底层的样式或结构干扰了所有 fixed/absolute 定位。我把这类情况单独列一节，因为这些根因最隐蔽。

6.1 毒瘤一：祖先元素上的 transform / filter / perspective

这是最出名的一类"fixed 失效"因素。position: fixed相对于视口定位，但如果某个祖先元素设置了transform（哪怕transform: translateZ(0)）、filter、perspective、contain: paint等属性，fixed 的定位基准就会从视口变成这个祖先元素，弹窗自然就"错位"了。

你可以在浏览器 DevTools 里选中预览层元素，查看它的所有祖先节点有没有 transform 相关样式。常见来源包括：CSS 动画库（anime.js、gsap）给父容器加了 transform、毛玻璃效果的 filter、某个 UI 组件内部的 transform 优化写法等。

项目里如果有类似的全局样式，方案一（手写遮罩）也会中招，因为你的遮罩层虽然用position: fixed，但它在 Teleport 到 body 之前，若 Teleport 目标不是 body，而是某个 transform 容器内部，照样错位。所以排查时一定要确认 Teleport 最终挂到的是 body。

6.2 毒瘤二：全屏弹窗/抽屉内部的滚动容器导致弹层坐标计算延迟

另外一类隐蔽问题：预览弹层展示时，页面上存在 CSS 动画（弹窗过渡动画、loading 动画等），这些动画会改变元素的位置信息，但 popper 的坐标计算是在动画开始前捕获的。打开预览时，某些浏览器尚未完成 layout 更新，获取到的坐标是旧值。

这种情况表现很随机，时好时坏，和机器性能还有关系。兜底手段是方案二里的"nextTick 延时修正"，或者把打开预览的动画关掉（在 el-image 预览层上可以设置hide-on-click-modal之类的属性，但坐标延迟不是这个属性解决的）。更粗暴一点的技巧：点击后强制window.dispatchEvent(new Event('resize'))，强制浏览器重新计算布局，有时候能唤醒 popper 的 update 逻辑。

6.3 毒瘤三：Element Plus 版本差异

Element Plus 从 2.0 到现在的 2.x 系列，el-image 预览层内部实现其实经历了若干次调整。早期版本预览层挂在body下时行为一致，但后续版本引入了append-to统一逻辑，部分版本对preview-teleported默认值也做了变化。如果你项目里锁定了一个比较老的 2.x 小版本，且升级困难，某些 bug 在官方后续版本已修复，但你的版本里还存在。

遇到这种情况，建议看看你项目锁定的 element-plus 版本，再用一个干净项目装最新版跑同一段代码对比。如果最新版正常，老版本异常，直接升级 element-plus 是省心方案。当然，升级本身会引入其他变更，需要回归测试，但总比一直扛着 bug 强。

7. 从根上防御：写一个业务级TableImagePreview组件，一劳永逸

如果你所在的项目里大量页面都要用"表格图片预览"，与其每个页面都修一遍，不如封装一个业务组件，把方案一和方案四的代码固化下来。这是我自己在多个中后台项目里的最终归宿，也是治本之策。

封装思路如下：

<template> <div class="table-image-preview" @click.stop> <el-image :src="src" :style="imageStyle" fit="cover" class="table-image-preview__thumb" @click="openPreview" /> <Teleport to="body"> <div v-if="previewVisible" class="table-image-preview__overlay" @click.self="closePreview" > <el-image :src="src" fit="contain" class="table-image-preview__large" /> <div class="table-image-preview__actions"> <button @click="prev" :disabled="isFirst">上一张</button> <span>{{ currentIndex + 1 }} / {{ previewList.length }}</span> <button @click="next" :disabled="isLast">下一张</button> </div> <button class="table-image-preview__close" @click="closePreview">×</button> </div> </Teleport> </div> </template> <script setup> import { computed, ref } from 'vue' const props = defineProps({ src: { type: String, required: true }, previewList: { type: Array, default: () => [] }, width: { type: String, default: '60px' }, height: { type: String, default: '60px' }, }) const previewVisible = ref(false) const currentIndex = ref(0) const imageStyle = computed(() => ({ width: props.width, height: props.height, cursor: 'zoom-in', })) const currentSrc = computed(() => props.previewList[currentIndex.value] || props.src) const isFirst = computed(() => currentIndex.value === 0) const isLast = computed(() => currentIndex.value === props.previewList.length - 1) const openPreview = () => { currentIndex.value = props.previewList.findIndex(item => item === props.src) if (currentIndex.value === -1) currentIndex.value = 0 previewVisible.value = true } const closePreview = () => { previewVisible.value = false } const prev = () => { if (isFirst.value) return currentIndex.value -= 1 } const next = () => { if (isLast.value) return currentIndex.value += 1 } </script> <style scoped> .table-image-preview__overlay { position: fixed; top: 0; left: 0; right: 0; bottom: 0; background: rgba(0, 0, 0, 0.7); display: flex; align-items: center; justify-content: center; z-index: 4000; } .table-image-preview__large { width: 80%; height: 80%; } .table-image-preview__actions { position: absolute; bottom: 30px; left: 50%; transform: translateX(-50%); display: flex; gap: 16px; align-items: center; color: #fff; background: rgba(0, 0, 0, 0.4); padding: 8px 16px; border-radius: 20px; } .table-image-preview__close { position: absolute; top: 20px; right: 30px; background: rgba(0, 0, 0, 0.3); color: #fff; border: none; font-size: 24px; width: 40px; height: 40px; border-radius: 50%; cursor: pointer; } </style>

使用的时候，只要在 el-table 列模板里写：

<template #default="{ row }"> <TableImagePreview :src="row.imgUrl" :preview-list="row.previewImageList" width="60px" height="60px" /> </template>

这个组件带了一个面向业务的关键改进：支持多图预览和上下切换。日常项目里，"表格里一张图，点击看大图"往往背后还有多图场景（比如商品主图和详情图），内置的 el-image 预览 list 机制可以用preview-src-list传入一组图，我们在业务组件里也保留了这一能力，并且是纯自研逻辑，完全不受 popper 机制影响。

组件里还要注意一个细节：把@click.stop加在最外层容器上，否则表格的行点击事件（比如常见的 row-click 编辑逻辑）会被误触发。另外，点击遮罩空白处关闭是业务里最常见的交互，我直接绑在了 overlay 的 self 上，避免点到大图时触发关闭。

这个组件基本是我现在新项目的标准配置了。从 element-plus 自带的图片预览切到这个自研组件之后，整个项目表格里的图片预览就再没出过一次错位问题，零维护成本，值得抄作业。

8. 附一份我排错时常用的自查清单

走到最后，我把自己每次排查这类弹层错位问题的检查顺序列出来。下次再遇到，你可以按这个顺序来，大概率能快速定位到点子上。

第一步：确定错位类型

• 打开控制台，手动滚动页面/表格，再点击预览，观察错位方向是否有规律。
• 如果是固定列图片错，其他列正常，优先怀疑固定列克隆元素干扰。

第二步：检查挂载位置

• 在浏览器 Elements 面板里选中预览层元素，确认它的父节点是不是 body。
• 不是 body 就手动加preview-teleported或检查是否有意外挂载容器。

第三步：审查祖先样式

• 从预览层元素往上逐个检查祖先节点是否包含transform、filter、perspective、will-change。
• 有的话，尝试在祖先元素上临时注释这些样式验证是否与错位相关。

第四步：Minimal Repo 对比

• 在 CodeSandbox 或本地新建一个干净项目，只引入 element-plus，只写最小的表格 + 图片预览，复现同样错位。
• 如果最小项目正常，那么错位多半来自项目内部的样式/结构干扰；如果最小项目也错，考虑 element-plus 自身版本 bug，升级或绕过。
• 如果最小项目正常、原项目错，那就用"二分法"：逐步注释掉项目里非必需的全局样式，尤其是 reset CSS、动画库初始化代码，观察何时错位消失。

第五步：决定方案

• 不介意写一点交互 → 方案一/业务组件，最稳。
• 只想快速止血 → 方案三的全局 CSS。
• 不能改组件结构 → 方案二的 showPreview 校正 hack。

这条链路我基本已经固化成肌肉记忆了。每次遇到这种"组件在某种布局下行为诡异"的问题，最重要的不是第一时间找魔法属性，而是搞清楚组件内部定位机制和你的页面结构之间的冲突点。组件没有错，布局也没有错，错的是它们默认的协作方式被打破了——你只需要找到那个被打破的环节，然后决定是"修组件用法"还是"绕开组件机制"。