企业官网建设流程全解析

前阵子做个后台管理系统的订单弹窗，遇到一个特别诡异的样式问题：同一个el-table，单独放在页面里，height="400"严丝合缝；一旦放进el-dialog里，打开弹窗后表格就跟被人捏扁了似的，高度只剩一半，数据区底下空出一大块白，滚动条也悬在半空。当时第一反应是怀疑样式被什么全局 CSS 覆盖了，查了半小时命名冲突，完全没找到问题。后来才意识到，这事根本不是 CSS 的锅，而是el-table的高度计算时机和el-dialog的渲染方式撞到一起了。

这篇文章就把这个问题完整拆开讲一遍，从现象、根因到三种解法，再顺带聊聊el-tabs、弹窗拖拽这些同样会触发同类 bug 的场景。如果你是 Vue2 + Element UI 的项目维护者，或者正在用 Element Plus 踩类似的表格布局坑，这篇文章应该能帮你把这一类问题一次性收拾干净。

1. 先还原现场：什么样的弹窗表格会出现高度变小

1.1 典型复现步骤

这个问题要复现其实特别简单，不需要什么复杂的边界条件。你只需要在项目里放一个最普通的弹窗，弹窗里放一个设置了固定高度的表格就行。我这里给一个最小可复现的示例：

<template> <div> <el-button type="primary" @click="visible = true">打开弹窗</el-button> <el-dialog title="订单明细" :visible.sync="visible" width="600px"> <el-table ref="tableRef" :data="tableData" height="400" border > <el-table-column prop="name" label="商品名称" /> <el-table-column prop="price" label="价格" /> <el-table-column prop="count" label="数量" /> </el-table> </el-dialog> </div> </template> <script> export default { data() { return { visible: false, tableData: [ { name: '商品A', price: 100, count: 1 }, { name: '商品B', price: 200, count: 2 }, // 多来点数据，让表格出现滚动条 ] } } } </script>

复现步骤就三步：

1. 页面加载完成后，先不要打开弹窗，让弹窗内容以“隐藏状态”被渲染出来。
2. 点击按钮打开弹窗，过渡动画结束后观察表格。
3. 正常来说，你会看到表格的数据区高度明显小于 400px，底部留出空白，滚动条也变得很矮。

在这个例子里，el-dialog没有加destroy-on-close，也没有用v-if控制表格渲染，这是问题的关键前提。用 Vue Devtools 选中.el-table__body-wrapper元素，看它的实际高度，你会看到它和一个正常的 400px 高度差得非常多。有些版本里甚至会变成 0，表格只剩一个光秃秃的表头。

1.2 两个常见表现：数据区缩水与表头被压缩

很多人以为“高度变小”只有一种表现，实际项目里我至少见过两种形态，处理方式本质上一样，但排查时容易走弯路。

第一种是数据区缩水。表格外层看起来还在，表头也正常，但是下面的数据区域明显变矮了，滚动条只能滚到部分数据，最后几行怎么都滚不到，表格底部留出一大块空白区域。这种表现最容易让人误判为 CSS 高度冲突，因为表头和数据区是分开的，你很难第一眼就发现是布局计算问题。

第二种是表头被压缩或高度错乱。表格的数据区高度反而正常，但是表头区域的高度被算成 0，表头文字被裁剪、表头和数据重叠，看起来像是表格“吃掉了”头部。如果你还开了固定列，或者表头里用了自定义模板，还会出现右侧空白条、固定列遮挡错位的附加症状。

这两种表现，加上标题里说的“高度变小”，本质上都是同一个根因。理解了根因之后，不管它以什么形态出现，你都能用后文里的方法给它治回来。

2. 根因分析：el-table 的高度为什么会被“算错”

2.1 el-table 的 height 是如何生效的

要理解这个 bug，得先搞清楚el-table设置height="400"之后，内部到底发生了什么。

很多同学以为height="400"就是给表格外层元素加了一个css height: 400px，然后完事了。实际上没这么简单。Element UI 拿到 height 后，需要做一系列“减法”：

• 表格总高度 = 表头高度 + 数据区高度 + 表尾高度（如果有）
• 数据区真实可滚动高度 = 总高度 - 表头高度 - 表尾高度
• 框架会把这个计算出来的“数据区高度”直接赋给.el-table__body-wrapper，让它在内部产生滚动条

这一套流程依赖于一个前提：表格在初始化时，必须能拿到真实的表头高度和容器尺寸。如果拿不到，或者拿到的值本身就带误差，后面的减法全都会算错。

这里面最容易被忽略的是表头高度。表头不是简单地量一下文字高度就完事的，它涉及到th的padding、边框、自定义渲染内容的高度。框架需要等 DOM 渲染完成后，用offsetHeight这类 API 去实际测量。而offsetHeight这类 API 有一个致命特点：元素只要处于display: none的祖先容器里，测量值就是 0。

2.2 el-dialog 的显示机制：内容一直在，只是不可见

这里就要说到el-dialog的一个反直觉设计：它默认并不是“打开时才创建内容”，而是“初始化时就渲染，通过切换样式来控制显隐”。

具体来说，el-dialog内部用的是v-show那一套机制。弹窗内容对应的 DOM 从一开始就存在于页面里，visible参数只是在外层容器上切换display: none/display: block。这也意味着，弹窗里的el-table在页面加载那一刻就已经走完了完整的生命周期，包括mounted、初始化布局、计算高度。

注意，这是和el-drawer、原生Modal组件不太一样的地方。如果你把表格放在一个v-if控制的组件里，visible为 false 时组件根本不会创建，自然不会初始化布局。但el-dialog默认不是这样，它不等你打开弹窗，内容早早就渲染并测量过一轮了。

所以现在问题链条就很清楚了：

1. 页面加载时，el-dialog处于关闭状态，内容容器是display: none。
2. el-table在这个不可见的容器里执行初始化。
3. 表格去测量表头高度、容器高度，得到的值全是 0 或者极小值。
4. 框架按这套错误数据完成了布局计算，把数据区高度设成了一个错误值。
5. 你打开弹窗，容器变为可见，真实高度马上变了，但表格不会自动知道这件事，依然沿用老一套错误布局。

2.3 一次“隐藏状态初始化”带来的连锁反应

为什么打开弹窗后表格不会自动修复？因为 Element UI 判断尺寸变化，靠的是监听window.resize事件。而弹窗从display: none变成display: block，并不会触发window.resize，浏览器窗口尺寸没有变，表格自然觉得一切正常，不需要重算。

这也就是为什么网上有人会教你“打开弹窗后手动触发window.resize事件”来修复——本质上就是骗表格说浏览器窗口变了，让它重新走一遍布局流程。这个方法确实偶尔管用，但它比较暴力，有副作用，后面我们会聊到更精准的做法。

Element Plus 新版表格内部虽然改用了 ResizeObserver，比 Element UI 对容器尺寸变化更敏感，但当容器处于display: none时，ResizeObserver 拿到的尺寸依然是 0。弹窗打开后虽然容器实际高度变了，可 ResizeObserver 不一定能在过渡动画期间触发重算，所以这个 bug 在 Element Plus 里照样存在，只是版本间的表现细节略有差异。

我把这个根因讲清楚之后，后面所有解法的思路其实都指向同一件事：让表格在“容器真正可见、尺寸稳定”的时候重新计算一次，或者让它在“可见之后”才开始创建和初始化。

3. 解法一：在弹窗完全打开后，用 doLayout 强制重算

3.1 核心写法：opened 事件 + doLayout

这是改动最小、最直接的一个方案。既然表格是在隐藏状态下算错了，那我们就在弹窗动画结束、容器尺寸稳定之后，手动叫它“再算一次”。

<template> <el-dialog title="订单明细" :visible.sync="visible" width="600px" @opened="handleDialogOpened" > <el-table ref="tableRef" :data="tableData" height="400" border > <el-table-column prop="name" label="商品名称" /> <el-table-column prop="price" label="价格" /> <el-table-column prop="count" label="数量" /> </el-table> </el-dialog> </template> <script> export default { methods: { handleDialogOpened() { this.$nextTick(() => { this.$refs.tableRef.doLayout() }) } } } </script>

doLayout()是el-table官方暴露的实例方法，作用是重新收集当前的宽高数据，然后更新表格各区块的布局。你可以在控制台里试一下，打开弹窗后手动执行this.$refs.tableRef.doLayout()，表格高度瞬间就能恢复正常。

@opened这个事件比较关键。它是在弹窗过渡动画完全结束后才触发的，这个时候容器的宽高已经稳定下来，表格重新测量出来的数据才是真实可信的。如果你用@open（动画开始前触发），或者直接在点击按钮的回调里调用，偶尔也能生效，但稳定性不够，因为那一刻容器尺寸可能还在变化中。

3.2 为什么不要只依赖 nextTick

有些同学会问：为什么我用this.$nextTick()包了一层，有时候还是不生效？

原因是nextTick只能保证 DOM 更新完成，不代表弹窗的过渡动画已经结束。Element UI 的弹窗默认有 scale 和 opacity 两段过渡动画，动画过程中容器尺寸虽然基本到位，但部分浏览器在动画帧里测量布局会有偏差。我实测下来，如果你在@open事件里调用doLayout，大概有三分之一的概率还是错的，尤其当弹窗里还有图片、异步内容时，偏差更明显。

比较稳的写法是在opened之后做一次重算。如果项目里遇到特别顽固的版本，一个doLayout还不够，可以在opened回调里这样兜底：

handleDialogOpened() { this.$refs.tableRef.doLayout() setTimeout(() => { this.$refs.tableRef.doLayout() }, 200) }

第二次调用就相当于一个保险，因为第一次调用时动画结束、布局刚稳定，可能还有零星的图片资源在加载，把表格挤了一下，200 毫秒后再算一次基本不会有遗漏了。这个写法看起来有点笨，但我在几个数据量较大的弹窗场景里试过，效果比只写一次稳定很多。

3.3 这招的局限与使用前提

doLayout方案也有它的适用边界。它解决的是“表格已经渲染出来，但高度算错了”的问题。如果弹窗内容是用v-if控制的，表格在弹窗打开前根本没创建，那doLayout其实没必要，因为表格创建的那一刻容器已经是可见状态了，它自己就能算出正确高度。

另外，如果表格里有一些异步渲染的内容，比如自定义列里放了需要等待接口返回才能展示的标签、图片，你需要在数据到位之后再调用一次doLayout，否则表格可能因为内容变更改变了行高，布局又抖一下。这种情况不局限于弹窗场景，正常页面上也会遇到，属于el-table的一个通用注意事项。

4. 解法二：用 v-if / destroy-on-close 让表格重新渲染

4.1 v-if 配合 dialogVisible 的写法

既然问题出在“表格过早初始化”，那最釜底抽薪的办法就是别让表格在隐藏状态初始化。我们可以把表格用v-if控制起来，让它只在弹窗打开时才创建：

<el-dialog title="订单明细" :visible.sync="visible" width="600px" > <el-table v-if="visible" ref="tableRef" :data="tableData" height="400" border > <el-table-column prop="name" label="商品名称" /> <el-table-column prop="price" label="价格" /> <el-table-column prop="count" label="数量" /> </el-table> </el-dialog>

这里的v-if="visible"是关键。visible为 false 时，表格根本不渲染，也就不存在“隐藏状态下测量高度”的问题。当你点击按钮把visible变成 true 时，弹窗外层容器已经从display: none切换为可见状态，表格在挂载时能拿到真实的容器尺寸，初始布局自然就是对的。

但这里还有一个细节要注意：visible变为 true 的那一刻，弹窗的过渡动画刚开始，表格在动画早期创建，个别浏览器里可能还是会出现测量偏差。所以我的习惯是，v-if配合opened兜底一下：

<el-dialog title="订单明细" :visible.sync="visible" width="600px" @opened="handleDialogOpened" > <el-table v-if="visible" ref="tableRef" :data="tableData" height="400" border > <!-- 列配置 --> </el-table> </el-dialog> <script> export default { methods: { handleDialogOpened() { if (this.$refs.tableRef) { this.$refs.tableRef.doLayout() } } } } </script>

这样就算初始化时挨着过渡动画的边取到了一个轻微偏差值，动画结束后也能立刻纠正。

4.2 destroy-on-close 的优缺点取舍

Element UI 给el-dialog提供了一个现成的属性destroy-on-close，意思是弹窗关闭时销毁内部所有内容，下次打开重新渲染。它的写法比v-if更省事：

<el-dialog title="订单明细" :visible.sync="visible" width="600px" destroy-on-close > <el-table :data="tableData" height="400" border > <!-- 列配置 --> </el-table> </el-dialog>

加上这个属性之后，每次打开弹窗，表格都是全新创建的，创建时弹窗容器已经是可见状态，因此不会踩到隐藏态初始化的坑。这个方案对代码的侵入性极低，从使用者的视角看，似乎只是加了一个布尔属性。

但它有两个副作用你要掂量清楚。第一是内部状态会全部丢失：表格的排序状态、筛选条件、当前滚动条位置、以及弹窗内其他表单未提交的数据，关一次窗就全部重置。如果弹窗里放的是复杂表单加表格的组合，用户填到一半误关了弹窗，数据全没了，这种体验很糟糕。第二是性能开销：弹窗每打开一次，内部所有组件都要重新创建和销毁一次，数据量大的表格可能会有明显的渲染卡顿。

所以我的选型建议是：如果弹窗内只是纯粹的展示型表格，没有状态需要保留，destroy-on-close是首选，因为它最干净；如果弹窗里承载了用户的临时操作状态，那就用v-if控制表格本身，或者用opened+doLayout方案。

5. 解法三：放弃精确高度，改用 max-height 自适应

5.1 max-height 为什么天然规避这个问题

如果你看完上面两种解法还在纠结，那第三个思路可能更省心：干脆别用height，改用max-height。

<el-table :data="tableData" max-height="400" border > <!-- 列配置 --> </el-table>

height和max-height的区别，在表格场景下是本质性的。height要求表格必须知道一个精确的总高度，然后去减法算出数据区高度，这就依赖初始化时的准确测量；而max-height只是一个“上限”，表格的高度完全由内容撑起来，只有当内容高度超过 400px 时，数据区才出现滚动条。

你发现没有，max-height模式下，表格根本不需要在初始化时精确测量容器高度。哪怕它是在隐藏容器里渲染的，最多只是暂时拿不到准确尺寸，但它不会被强制“焊死”成一个错误高度。等弹窗打开、容器可见，内容自然撑开，滚动条该出现的出现，该消失的消失，不会出现那种“底部一大块空白”的假死状态。

这个方案的实际效果和产品期望之间有一个差异：表格不会严格铺满弹窗剩余高度，如果数据只有三五行，表格就只有三五行高，底下会显得空。如果你的产品经理允许这种表现，那max-height绝对是最省心的一招。

5.2 结合 flex 布局让弹窗内容填满高度

如果产品上要求“弹窗内容区必须撑满固定高度”，max-height也能配合 flex 布局做到，只是没那么直接。思路是：给弹窗内容包一层固定高度的容器，容器内部用 flex 布局，表格作为 flex 子项，设置height="100%"。

<el-dialog title="订单明细" :visible.sync="visible" width="600px"> <div class="dialog-body"> <el-table :data="tableData" height="100%" border > <!-- 列配置 --> </el-table> </div> </el-dialog> <style scoped> .dialog-body { display: flex; flex-direction: column; height: 420px; } .dialog-body .el-table { flex: 1; } </style>

这里要注意两个细节。

第一，height="100%"能不能生效，取决于父容器.dialog-body有没有一个明确的高度。如果父容器高度是auto，那100%会退化，表格高度可能变成 0。所以你需要给.dialog-body写死一个具体高度，或者用calc(100vh - 弹窗头部和底部的高度)这样的表达式算出来。

第二，Element UI 的表格有一层一层的结构包裹，flex: 1能不能让表格部分正确伸展，需要实际验证一下。稳妥的做法是给.el-table也设置一个width: 100%，避免 flex 布局下宽度异常。这个方案踩过坑的人应该懂，表格在 flex 容器里偶尔会出现宽度塌陷，需要配合width: 100%一起使用才稳定。

6. 同样的坑还会出现在这些地方

6.1 el-tabs 切换后的表格高度异常

弹窗场景搞明白之后，你会发现这个 bug 其实是个家族：只要“组件初始化时容器不可见”，就会出现类似问题。最常见的第二个案发现场是el-tabs。

el-tabs内部对非激活的 Tab 面板默认是display: none，但内容已经渲染了。如果你的表格放在第二个、第三个 Tab 里，页面初始化时表格就会在隐藏状态完成布局计算，等用户切过去时，高度同样变小。很多人第一次遇到会和弹窗场景一样，怀疑是样式问题。

最简单的解法是给el-tab-pane加上lazy属性：

<el-tabs v-model="activeTab"> <el-tab-pane label="基础信息" name="base">...</el-tab-pane> <el-tab-pane label="数据明细" name="detail" lazy> <el-table :data="tableData" height="400" border> <!-- 列配置 --> </el-table> </el-tab-pane> </el-tabs>

lazy属性表示该 Tab 面板在第一次被激活时才渲染内容，而不是初始化就渲染。这样表格创建时容器已经是可见状态，问题从源头消失。如果你的业务要求 Tab 内容提前渲染，不能加lazy，那就参考弹窗的解法：在 Tab 切换完成后调用doLayout。

6.2 弹窗尺寸变化后的表格不刷新

还有一种情况也经常被归到“高度变小”的坑里：弹窗本身支持拖拽调整大小，或者你在代码里动态修改了弹窗的宽度、高度，表格不会跟着刷新。

这个场景和初始化的关系不大，而是el-table对容器尺寸变化的响应机制太弱。前面讲了，Element UI 表格监听的是window.resize，弹窗内部拖拽改变尺寸并没有触发 window 层级的变化，表格自然不知道尺寸变了。

处理方式是在拖拽结束的回调里主动调用一次doLayout。如果你用的是网上常见的“拖动右上角调整弹窗大小”的自定义指令，在鼠标抬起的地方补一段：

this.$refs.tableRef.doLayout()

如果你只是想快速验证一下是不是这个问题，在控制台执行window.dispatchEvent(new Event('resize'))，表格也会重新布局。这个办法适合临时调试，正式代码里不要这么写，因为全局resize事件会触发很多其他组件重算，代价比较大。

6.3 一个通用原则和一键式决策清单

写到这里，我想把这一类问题的共通规律总结一下，后面再遇到任何类似的布局异常，你都能套用：

凡是需要在初始化时测量自身尺寸的组件，都不能在display: none的容器里做初始化。

这句话不仅适用于el-table，也适用于 ECharts 图表、虚拟滚动列表、某些自定义滚动容器等等。只要组件的初始化逻辑里出现了offsetWidth、offsetHeight、getBoundingClientRect、ResizeObserver 这类 API，它就会有这个底层隐患。

遇到问题时，可以先按下面这张表快速定位和处理：

排查时先确认一个关键事实：这个组件的初始化时机，是容器可见之前，还是容器可见之后。只要这个时机踩错了，问题就一定会以某种形态冒出来。找准时机，解决方案也就浮出水面了。

还是说回开头那个订单弹窗。我最后实际采用的是opened加doLayout的解法，改动最小，也没有引入状态丢失的问题。后来项目里凡是涉及弹窗、抽屉、Tab 隐藏容器的表格，我基本都会默认考虑要不要加lazy或者动态渲染，而不是等测试同事把 bug 单甩到我这里。一个很简单的经验：别让组件在看不见的时候，干需要“看”才能干好的活。