企业官网建设流程全解析

CSS 里这三个知识点——居中、背景图引入、显示隐藏——我敢说绝大多数前端都查过无数遍，但每次遇到具体场景还是容易翻车。居中不再是简单的text-align和line-height，背景图的引入方式直接关系到加载性能，而显示隐藏的三种方案（display、visibility、opacity）看起来都能让元素“消失”，实际行为却天差地别。这篇东西我会把实战中最常用的方案全都拆开讲，配合代码、适用场景和踩坑经验，初级读者可以当字典查，有经验的也能从对比细节里找到以前没注意到的问题。

1. 居中的完整解决方案

我一直觉得“居中”是CSS里最具有迷惑性的基础知识点。它看起来简单，但每一种方法都有自己的适用前提，搞不清楚条件就会莫名其妙失效。

1.1 水平居中的基础玩法

先说最基础的场景：让一段文字、一张图片、一个按钮在父容器里水平居中。

对于行内元素（span、a、img、纯文本等），直接在父容器上写text-align: center就行。它的原理是让容器内的行内内容按中心对齐，这个属性是继承的，所以就算子元素嵌套了好几层，只要中间没有被覆盖掉，文字照样居中。总有人问为什么给子元素设置margin: 0 auto却不起作用，因为img这种替换元素虽然可以设置宽高，但它默认是行内级元素，margin: auto的水平自动外边距只在块级元素的水平方向生效。想让行内元素用margin居中，先把它display: block再说。

对于块级元素（div、p、section等），最经典的是margin: 0 auto。它的生效条件很明确：元素必须设置了宽度（或者宽度不是自动撑满的），同时不能有float、position: absolute这类脱离文档流的影响。当左右外边距都是auto时，浏览器会自动分配剩余空间，而且平均分到两侧，元素自然就居中了。如果没有设宽度，块级元素默认占满整行，剩余空间是 0，margin: auto也就没有任何挤压力度。

还有一个常见场景是让多个块级元素水平居中排列。我自己常用的是两种思路：一是给父容器加display: flex; justify-content: center，简单粗暴；二是把子元素变成inline-block，再配合text-align: center。后者在兼容老旧项目、又不想引入 flex 布局时很好使，但要注意inline-block元素之间会出现大约 4px 的空白间隙，因为代码换行在 HTML 里会被解析成空格。这个间隙常让视觉效果偏那么一点，真正的强迫症要么把标签写成一排，要么给父容器设font-size: 0再在子元素单独设置字体大小。

1.2 垂直居中的经典做法

垂直居中比水平居中麻烦得多，尤其是父容器高度不固定或者内容高度不明确时，很多方案会直接失效。

最简单的场景是单行文本在固定高度容器里垂直居中，设置line-height等于容器高度就行。原理是行高会把行框撑起来，文本在行框内的基线位置经过计算后变成视觉上的垂直居中。这个方法只对单行文本有效，多行或换行时行高会让文本溢出，所以使用场景非常受限。同样只适用于单行场景的还有vertical-align: middle，但它作用于行内元素或表格单元格，用来对齐同一行内的不同元素（比如图标和文字）。注意vertical-align并不直接作用于块级元素，对div设置它是无效的，很多人刚学到这里就会踩坑。

对于块级元素垂直居中，旧项目里最常用的是display: table-cell+vertical-align: middle。这个方案相当于让元素模拟表格单元格的行为，父容器设display: table，子元素设display: table-cell，垂直居中就自然成立了。它的优点是内容高度变化时也能保持居中，不需要知道具体高度，缺点是table-cell的宽度分配行为比较诡异，有时候要额外处理width百分比，布局上的自由度不如 flex。现在还在用这种方法的场景，基本上是维护老代码或者遇到 flex 兼容性限制的情况。

1.3 水平垂直居中的五种主流方案

这是面试高频区，也是实际开发中需求最多的一类。我挑五个能打的方案，按推荐程度排列并逐一解释原理。

第一种是绝对定位 + 负外边距。父容器position: relative，子元素position: absolute，设top: 50%; left: 50%，这时子元素的左上角正好落在父容器中心点，再通过margin-left: -width/2和margin-top: -height/2把元素向左上方拉回一半，就能做到视觉上的完整居中。这个方案的缺点是必须知道子元素的准确宽高，因为负外边距的数值依赖尺寸。动态内容、响应式布局里宽高不固定时，这个方案就无法用了。

第二种是绝对定位 +margin: auto。子元素设置position: absolute，四个方向都设为0，再加上margin: auto。当绝对定位元素的上、左、下、右同时有确定值（这里都是 0）且对应方向的外边距为auto时，浏览器会把剩余空间平均分配给外边距，从而同时实现水平和垂直居中。这个方案不需要知道宽高，因为绝对定位元素的尺寸可以由内容撑开（前提是没有设置明确宽高），所以比负 margin 更实用。要注意父容器必须设置position: relative，否则定位基准会变成最近的已定位祖先，甚至视口。

第三种是绝对定位 +transform: translate(-50%, -50%)。子元素设置top: 50%; left: 50%，然后用translate(-50%, -50%)把元素自身往上、往左各移动自身宽度和高度的一半。transform的百分比是相对于元素自身尺寸计算的，所以不需要知道宽高。最大的坑在于transform会创建新的层叠上下文和包含块，如果子元素里有一个position: fixed的后代，这个后代的定位基准可能因此改变。另外，个别浏览器对transform的渲染会带来轻微模糊（尤其是同时对元素做缩放动画时），虽然现代浏览器已经基本解决，但做动画时要注意。

第四种是 flex 方案，也是我日常的首选。父容器设置display: flex; align-items: center; justify-content: center，两个属性分别控制交叉轴和主轴方向上的居中。flex 方案几乎不需要考虑子元素的宽高，内容变化也能自动保持居中，代码量最少且语义清晰。要说缺点，就是父容器使用了 flex 布局后会改变子元素的排列和尺寸表现，比如flex-shrink默认开启，内容较多时子元素可能被压缩，需要留意这一点。

第五种是 grid 方案。父容器设置display: grid; place-items: center，一句代码搞定水平和垂直居中。place-items是align-items和justify-items的简写，而justify-items: center与通常理解的justify-content行为不一样，它作用于网格项目在网格区域内的对齐。这个方案非常现代，代码极简，主要局限性是网格布局本身的兼容性虽然已经很好，但团队老项目里还没大面积铺开 grid 的话，容易造成风格不统一。我个人在较新的项目或组件库内部偶尔会用，常规页面还是 flex 为主。

实际开发中，我建议优先 flex，遇到需要避免 flex 影响的场景（比如布局内部嵌套复杂）时，用绝对定位 +transform或margin: auto兜底。从来没有“万能居中方案”，每一项选择都是取舍。

2. 背景图引入的细节与实战选择

背景图看起来只是background-image: url(...)一行代码，但路径解析、属性组合、与img标签的取舍，每一样背后都有值得掰开揉碎讲的逻辑。

2.1 背景图的基础写法与路径问题

background-image的基本书写格式是background-image: url("图片地址")。地址可以是相对路径、绝对路径，也可以是不带引号的 URL。很多人以为带不带引号无所谓，确实在 HTML/CSS 解析层面大部分浏览器都能接受，但代码规范性和压缩工具的解析处理上，统一带引号是更安全的选择，遇到路径里包含特殊字符时不带引号很容易出解析问题。

相对路径是最容易翻车的地方。CSS 里的相对路径是相对于样式表文件的所在目录，而不是页面 HTML 文件所在目录。很多新手把 CSS 放在css/style.css，图片放在项目的根目录images/logo.png，然后在 CSS 里写url(images/logo.png)，结果图片永远加载不出来。局部刷新页面试了无数次，最后发现路径少了../前缀。判断方法很简单：从当前 CSS 文件位置出发，一级一级向上或向下找到目标图片。如果 CSS 在css/目录，图片在根目录的images/下，就要写url(../images/logo.png)。

还有一种场景是 CSS 被构建工具处理过（打包、压缩、CDN 化）。构建工具会自动改写url()路径以适配新的资源地址，但前提是图片确实被打包进了构建产物，而且相关配置正确。我自己遇到过一个诡异问题：本地开发时背景图正常，部署到线上就 404。排查结果是构建工具把 CSS 里的相对路径计算成了域名根目录下的路径，而图片实际部署在带子路径的 CDN 目录下。这些情况里，背景图路径并不是随便写写就完事的，要理解“最后谁在消费这个 CSS 文件”再决定路径策略。

背景图也能实现多背景叠加，用逗号分隔多个url()，先写的图层在上层。比如一个盒子里既要一张主体图，又要一层半透明纹理，就可以写两个url()外加一个渐变。这种多背景在实现光晕、遮罩、纹理叠加时很有用，不用额外加空 div 作图层。

2.2 background 系列属性的协同逻辑

光有background-image还不够，图片的平铺方式、位置、大小都由配套属性决定。

background-repeat控制背景图是否平铺，默认是repeat，也就是横向纵向都会重复铺满整个容器。很多人不设置这个属性，结果小图标背景变成了满屏的重复方格。实际使用中，图标类背景一般设no-repeat，需要纹理平铺才用repeat，或者用repeat-x/repeat-y只在一个方向平铺。round和space这两个值也很少有人用，前者会让图片缩放为整数次铺满，后者会在图片之间留出相等间距，适用于按钮材质、格子纹理等特殊需求，调试时可以用，日常确实用得少。

background-position决定背景图在盒子里的位置，适合与no-repeat配合。它的值可以是像素、百分比、关键词。关键词center top、right bottom这类组合很好理解，但百分比定位是个容易绕晕的点：background-position: 50% 50%指的是图片的 50% 位置点与容器 50% 位置点对齐，并非把图片左上角放在容器 50% 处。所以 50% 50% 就能实现背景图水平和垂直居中，这是初学阶段很多人忽略的细节。像素定位则是图片左上角相对容器左上角的偏移，负值可以把超出左上角的区域露出来，用于雪碧图定位非常常用。

background-size是控制图片尺寸的关键，主要是cover和contain两个值。cover会让背景图等比缩放并完全覆盖容器，图片超出容器的部分被裁掉，所以容器比例和图片比例不一致时，图片必然会有部分不可见。contain则是图片完整放进容器，如果比例不一致，容器会留下空白区域。选cover还是contain取决于需求：全屏 Banner、头部背景，用cover保证铺满不露空；产品图、Logo，用contain保证完整展示。也可以直接写像素或百分比，比如background-size: 100px 100px或者background-size: 50% 50%，百分比是相对容器宽度和高度的，不是相对图片自身尺寸。

简写属性background允许把所有背景相关属性写在一行，但顺序有讲究。一般建议习惯写background: color url(...) no-repeat center / cover，其中position和size用斜杠连接，斜杠前后的值不能写反。简写一旦写了没声明的属性就会被重置为默认值，比如只写了background: url(...)，其他没写到的background-repeat、background-position、background-color全部重置。这导致一个问题：如果在此之前单独设了背景色，后面用简写覆盖背景图时背景色会被清掉，很多人遇到背景色消失就是这个原因。

2.3 背景图与 img 标签的使用选择

什么时候用背景图，什么时候用img，是很多前端纠结过的问题。我总结出了自己的一套判断标准：如果图片是页面内容的一部分（文章配图、商品图、新闻封面），必须用img，因为它对搜索引擎和读屏软件可见，还能设置alt描述文字；如果图片是纯粹的装饰（按钮背景、卡片纹理、渐变遮罩），则用 CSS 背景图，因为装饰性图片对内容和可访问性没有实际信息贡献，没必要额外增加 DOM 节点。

还有一个常被忽略的差异是懒加载和请求优先级。img标签可以直接用现代浏览器的loading="lazy"实现图片延迟加载，对首屏性能和流量优化非常有效。CSS 背景图目前没有标准的懒加载属性，需要通过IntersectionObserver动态给元素加类名，再在类名作用范围内设置背景图，操作上比img复杂不少。所以首屏以下的大图，我倾向于用img + loading="lazy"。

另一个差异是打印表现。浏览器打印页面时，默认情况下img标签的图片会出现在打印内容里，而 CSS 背景图在大多数浏览器的默认设置下不会被打印。如果一个按钮上的图标需要出现在打印文档中，用img更可靠。还有一种画面清晰度的问题：同一张图片，img可以通过srcset或picture元素提供多分辨率版本，CSS 背景图要适配不同屏幕密度只能用image-set()，写法支持度不如srcset广泛。凡是要做响应式切图的图片，我几乎都优先用img。

2.4 背景图的进阶玩法：渐变与雪碧图

背景图不只是图片文件，CSS 渐变也被归类到背景图像里。background-image: linear-gradient(red, blue)就是一行背景图语法，渐变可以和其他url()背景图共存。线性渐变方向可以用角度，比如135deg是左下到右上；也可以用关键词to top、to right bottom。写虚线纹理、进度条底色、按钮悬停态高光，渐变都能直接完成，比切图省事得多。径向渐变radial-gradient还能做圆形高光、模拟光照效果，多用于层次感较强的按钮和卡片背景。

雪碧图（CSS Sprites）是把多张小图标合成一张大图，用background-position定位显示其中一块的技术。它本身是为了减少 HTTP 请求数，虽然现在 HTTP/2 的并发能力大大提升，小体积图片合并成雪碧图的意义不如十年前那么大，但在小图标资源特别多的场景（比如导航栏十几个图标）依然能减少请求压力并让图标整体加载更一致。维护雪碧图需要格外小心坐标系，我之前给一个项目添加新图标时，因为在线生成工具的输出位置偏移算错，导致多个按钮的图标全部错位。强烈建议使用工具自动生成雪碧图和对应的 CSS 类，而不是手动数像素。

3. 显示隐藏的三兄弟深度对比

display: none、visibility: hidden、opacity: 0都能让元素“看不见”，但它们对布局、事件、动画的影响完全不同。用错了不只是风格问题，性能和行为表现都会有明显差异。

3.1 display: none 的雷厉风行

设置display: none后，元素会完全从渲染树中移除，不占据任何空间，相当于页面里从来没有过这个元素。它也不响应任何鼠标事件，因为视觉上已经不存在，点击、悬停、焦点都无从触发。它的子元素同样全部被移除，不管子元素自身设置了什么样的显示属性都没有机会呈现。

这个特性决定了它最适合的场景是彻底的显隐切换：折叠面板、模态框的未打开状态、条件渲染的组件。因为不占空间，切换显示时会引起页面回流（layout），尤其是大量元素同时切换时，性能代价会偏大。如果是频繁切换动画效果，比如希望元素隐藏时有淡入淡出过渡，display本身不能参与 CSS transition，因为它不是可过渡属性，写transition: display不会产生任何渐变效果。所以只要遇到“要动画的隐藏显示”，就别用display。

实践中另一个容易踩坑的情况是，隐藏组件里如果有定时器、异步请求或播放器实例，display: none并不会自动暂停它们。比如用一个隐藏的 iframe 或 video 播放音频，即使容器display: none，媒体可能仍在播放。因此做隐藏时要额外手动处理这些副作用，不能指望浏览器的渲染优化自动帮你停掉背后的逻辑。

3.2 visibility: hidden 的占位与继承特性

visibility: hidden同样让元素不可见，但它不会移除元素占用的空间，元素还在文档流里，只是看不见而已。这意味着它不会引起回流，只会导致重绘（repaint），性能代价通常比display: none小。元素仍然不响应鼠标事件，因为人眼已经看不到它了，点击处的命中测试无法命中这个元素。

这个属性有一个特殊之处：它支持继承和覆盖。父元素设为visibility: hidden后，子元素默认也是隐藏的，但如果子元素显式设置visibility: visible，子元素就能重新可见。这个特性在某些悬浮层设计中很好用：父容器隐藏整个分组，但某个子组件需要特殊显示时，可以在子组件上单独打开可见性。display: none就没有这个可能性，因为元素整体被移除了，子元素再做设置也无济于事。opacity也没有这个特性，因为opacity不是可继承属性，它作用于元素自身图层。

visibility是可以被 CSS transition 过渡的属性，它的值可以从hidden过渡到visible。但这里有个细节：visibility的过渡默认是离散切换的，要配合transition-timing-function使用，隐藏时通常会延迟到动画结束时才完全隐藏（为了避免元素仍然处于可见状态挡住点击），显示时则希望立刻可见。最常见的是把visibility和opacity放在一起做淡入淡出：元素初始opacity: 0; visibility: hidden，过渡效果让opacity渐变，visibility负责延迟隐藏，这样既能播放动画，动画结束后又不会挡住其他元素的事件。

3.3 opacity: 0 的透明陷阱

opacity: 0让元素完全透明，但元素仍然占据空间，也仍然响应鼠标事件。这个区别是很多交互问题的根源：你以为“看不见就等于不存在”，但用户鼠标在透明元素的位置依然会触发点击、悬停和光标样式。我在实际项目里踩过这个坑——用一个全屏opacity: 0的遮罩层做点击拦截，结果整个页面被透明层挡住，按钮全部点不到，就是因为透明层还参与命中测试。

如果想要透明后不响应事件，需要手动加pointer-events: none。但加了之后又要注意：如果透明元素里还有需要交互的子元素，父级设置pointer-events: none会导致所有后代的事件也全部失效，除非子元素单独重新设置pointer-events: auto。这个组合拳在实现复杂悬浮卡片时很常用：卡片透明隐藏时完全不拦截事件，显示时恢复事件响应。

opacity是 CSS 中少数性能表现优异的可过渡属性。改变opacity只触发合成（composite），不触发布局和重绘（元素自身图层不变的情况下），非常适合做动画。但它也会带来一个副作用：当元素设置了opacity小于 1 时（包括 0），元素会创建一个新的层叠上下文。这个层叠上下文会影响固定定位后代、影响 z-index 比较、甚至影响某些浏览器对mix-blend-mode的渲染。所以依赖position: fixed的下拉菜单、Dialog 组件的祖先链上如果有opacity: 0.99之类的透明设置，固定元素的定位基准可能和预期不一致。

3.4 三种隐藏方式的选择策略

选择时可以先问两个问题：需不需要动画？隐藏后还能不能允许和元素产生交互？不需要动画且直接删除布局空间的场景用display: none；需要动画、且动画结束后不希望它挡事件的场景用opacity+visibility组合；保留空间但只是暂时不显示、后续可能快速恢复的场景用visibility: hidden会相对省性能。opacity: 0单独使用则要非常小心事件问题，适合纯视觉隐藏且不影响交互的情景，比如降低视觉注意力但保持可点击的内容。

还要考虑可访问性。display: none和visibility: hidden在大多数浏览器里都不会被读屏软件朗读；而opacity: 0的元素由于仍然存在于可访问性树中，读屏器可能会朗读它。如果隐藏的是一段不重要但存在的内容，比如装饰文字，用opacity可能导致视障用户听到莫名其妙的朗读内容。这个场景我要优先避免用opacity。

4. 综合实战：做一个带背景图和显隐动画的居中卡片

把这些知识点串起来，我分享一个真实的综合小案例：一个商品卡片组件的构建过程，需要实现整体在容器居中、按钮背景用渐变和图片底纹、描述信息在 hover 时淡入淡出显隐动画。

4.1 卡片居中的代码实现

卡片作为整体居中，用 flex 容器最省事。外层容器设置以下结构：

.container { display: flex; align-items: center; justify-content: center; height: 100vh; } .card { width: 320px; padding: 24px; border-radius: 12px; background-color: #ffffff; box-shadow: 0 8px 24px rgba(0, 0, 0, 0.1); }

这里有个隐藏细节：外层容器如果不需要占满全屏，就不要随便给它设height: 100vh。很多人在局部区域内想居中，却把高度撑满整个视口，结果页面多出了大片空白。如果容器是某个区块内的居中，应该用min-height或由内容撑开的高度。

卡片内部的标题和图片信息怎么居中？标题用text-align: center就够了，因为它是文本内容；图片展示方面如果图片是商品主图，我选择img标签，因为它对 SEO 有意义，还能设置 alt 描述。卡片里的图标按钮如果只是装饰，就使用背景图方式引入。

4.2 按钮背景图的叠加实现

再来做一个带小幅纹理底纹和渐变叠加的按钮。需求是：按钮默认渐变背景，hover 时背景亮度略微变化。

.btn-primary { background-image: linear-gradient(135deg, #4f8ef7, #2d6cf0), url("../img/btn-texture.png"); background-repeat: no-repeat, repeat; background-position: center, center; background-size: cover, auto; color: #fff; padding: 10px 24px; border: none; border-radius: 6px; cursor: pointer; transition: filter 0.2s; } .btn-primary:hover { filter: brightness(1.1); }

这里渐变写在第一个url之前，它会作为最上层背景，底纹图片在下一层。background-repeat用逗号分别给渐变层和图片层赋值，如果不写两组值，所有背景图层都会共用最后一个值，这个细节是很多人做多背景时控制不住平铺的根因。background-size同样对两层分别设置：渐变层用cover覆盖整个按钮，底纹图片层用auto保持原始纹理尺寸平铺。

有人会问为什么 hover 不用background-image换颜色，而用filter: brightness(1.1)。因为换背景图意味着浏览器要重新加载新图片，或者手写两套背景图并切换，不仅代码冗余，过渡动画也不好做。filter: brightness直接基于当前渐变结果做亮度变化，性能更好，视觉也统一。

4.3 描述信息的淡入淡出与事件管理

卡片下方有一段描述信息，默认隐藏，hover 时显示，要求有淡入淡出动画，且隐藏状态下不能遮挡卡片本身的点击区域。我直接用opacity+visibility的组合方案：

.card-desc { opacity: 0; visibility: hidden; transform: translateY(8px); transition: opacity 0.3s ease, visibility 0s linear 0.3s, transform 0.3s ease; } .card:hover .card-desc { opacity: 1; visibility: visible; transition-delay: 0s; transform: translateY(0); }

这段代码的关键是 transition 的延迟写法。隐藏时visibility过渡延迟 0.3s，正好和opacity的淡出时间对齐：淡出动画结束后元素才真正变成hidden，从而保证动画过程结束前不会突然消失，也不会在完全透明后还拦截事件。显示时transition-delay: 0s表示没有延迟，鼠标一移入，描述信息先立刻从隐藏变为可见（虽然此时透明度还是 0），再通过opacity渐变显示。这就是为什么可以用visibility做“延迟隐藏”而不是一开始就用display。

用display: none的替代方案我会这么写：

.card-desc { display: none; } .card:hover .card-desc { display: block; }

但这样写没有动画，显示和高亮都是瞬时切换，视觉生硬。所以只要需要过渡动画，就不要用display控制显隐状态。还要提醒一句：这类 hover 显隐只适合鼠标交互场景，移动端触摸不存在 hover，常态隐藏的内容在触屏上根本无法展示，需要额外通过点击事件或媒体查询做交互适配。

4.4 完整页面效果验证

我在本地用一份简单 HTML 文件验证了上面的组合。页面结构是外层 flex 容器、中间卡片、卡片内有标题、一张商品图、一个按钮和一段隐藏的描述信息。鼠标悬停卡片时，描述信息在 0.3 秒内淡入并向上位移，隐藏时同样在 0.3 秒内淡出并复位。按钮底纹、渐变、文字在 hover 时整体提亮，没有出现背景图重新加载的闪烁。

验证过程中我还专门用开发者工具的性能面板录制了动画过程，淡入淡出阶段没有触发布局计算，只有合成层的变化，帧率稳定在 60fps。这验证了opacity+transform做动画的优越性。如果用display: none切换，每次切换都会触发布局计算，卡片位置和尺寸如果依赖内容撑开，还会引发连锁布局变动，得不偿失。

5. 常见问题与排查技巧实录

下面的问题全部来自我实际开发中踩过或帮别人排查过的场景，可以直接当成排查手册用。

5.1 为什么 margin: 0 auto 老是不居中

最常见的两个原因：一是目标元素没有设置宽度，块级元素默认宽度是auto占满整行，左右没有剩余空间，auto自然不起作用；二是元素使用了浮动或绝对定位，它们会脱离常规文档流，margin: 0 auto对脱离流的元素水平居中无效。排查时先看元素有没有宽度，再看有没有float或position。给元素加一个背景色临时看盒子模型，问题往往一眼就能看出来。

5.2 背景图不显示，到底哪里出了问题

背景图不显示时，我按顺序排查：先打开浏览器控制台网络选项卡，看图片请求是否发出、返回状态码是多少。404 说明路径错了，按 CSS 文件所在目录重新计算相对路径；如果请求没发，检查 CSS 属性是否拼写错误、是否是简写覆盖导致旧值失效。还有一种隐蔽情况：背景图存在但颜色不对，检查是否被外层容器的背景色遮盖，或者元素本身尺寸是 0（没有内容也没有宽高，背景图没有显示区域）。给元素临时设置width: 200px; height: 200px往往能快速验证。

5.3 隐藏元素后页面仍有滚动条或留白

元素设置visibility: hidden或opacity: 0但保留占位时，页面自然会有滚动条或留白，这是正常现象。如果不想留白，就要用display: none，但那样又会丢失过渡动画。折中方案是结合元素尺寸动画：显隐切换时同时修改max-height或padding，让布局空间也跟着变化。如果只是移动端侧滑菜单想要不占空间又带动画，可以考虑position: absolute移出可视区再控制opacity，但这种方法对交互细节要求高，不建议新手一上来就模仿。

5.4 为什么 hover 显示的子元素一瞬间消失

用opacity做显隐时，如果只写opacity: 0，显示时改成opacity: 1，鼠标往子元素方向移动时发现子元素在半透明状态闪了一下甚至消失，这通常是父容器与子元素之间出现了事件断层。因为opacity: 0的元素仍然响应事件，但它和父容器之间存在一定的间隔，鼠标经过间隔区域时，元素透明度本来就是 0，你感觉它消失了。解决方法是把显隐逻辑写在同一个交互触发链上，让父容器 hover 时子元素才出现，并且尽量避免让显示出来的元素与触发区域之间有空白鸿沟。

5.5 显示隐藏的动画结束后，元素还挡着后面的按钮

如果元素是用opacity: 0隐藏的，它一定会挡住后面的点击，因为透明不等于不存在。要解决这个问题，就要在动画结束后让元素不再响应事件。用visibility: hidden加transition-delay的思路正好能实现：opacity先过渡到 0，visibility等到动画结束时才切换成hidden，之后元素不再拦截事件。

6. 这些基础知识为什么值得反复精读

这三个知识点看起来都很简单，但一次把所有细节梳理完，我才真正意识到它们其实是 CSS 渲染机制的缩影。居中方案背后是文档流、定位和盒模型的理解；背景图引入背后是资源加载路径和布局占位策略的权衡；显示隐藏背后是重排、重绘、合成和事件命中机制的博弈。你越是实战多年，越会发现项目里遇到的很多所谓“奇奇怪怪的 bug”，最后都能回归到这些最基础的知识点上。每次排查显隐动画卡顿、背景图路径错误、居中失效，我都是在心里默默把这张知识地图重新走一遍。

我的习惯是每过一段时间就重新整理一遍这类基础知识点，并且强制自己用“为什么”去推演每种方案成立的原理，而不是死记硬背代码模板。只要原理吃透了，代码怎么写都是顺理成章的事。这篇内容如果你能从头读到尾，并亲手把代码跑一遍，我相信这三大知识点基本不会再坑到你了。CSS 不是玄学，它的每一个表现背后都有确切的原因，我们要做的是先理解原因，再选择方案，而不是遇到问题就复制粘贴查来的代码。这些话听起来基础，却是很多年前端后我最有价值的体会。