企业官网建设流程全解析

做后台项目的时候经常碰到这种画面：一张卡片分成左右两栏，左边是分类导航，右边是一大段说明文字。右边内容多，自然把卡片撑到七八百像素高；左边的导航只有三行字，背景色只铺了上面一小截，底下全是白的，看着像页面被切了一半。你顺手给左边那栏写上height: 100%，刷新，纹丝不动；加!important，还是纹丝不动；换成min-height: 100%，依旧纹丝不动。

问题从来不在子元素身上，而在“父元素高度 auto”这六个字。只要父元素的height是auto，也就是高度由内容撑开，子元素的百分比高度就失去了参照物，浏览器只能把它当auto处理——你写 100% 和你什么都不写，计算结果一模一样。这篇就围绕这件事展开：先把“为什么不生效”讲透，再给出两种能立刻落地的写法：父元素转弹性容器让子元素拉伸，以及绝对定位配 top/bottom 撑满，最后把两种方法的副作用边界、选型依据和排查手法一并摊开。适合已经会写 CSS、但被百分比高度反复绊住的人看，也适合刚接触布局、想少走两年弯路的新手。

1. 先把“为什么不生效”这件事讲透

1.1 百分比高度参照的不是父元素“看起来有多高”

很多人脑子里的模型是这样的：父元素渲染出来 800px 高，子元素height: 100%就是 800px。这个模型错在把“渲染结果”当成了“计算依据”。

CSS 里百分比高度的参照对象是包含块的高度属性值，不是包含块最终渲染出来的像素高度。这两者的差别在父元素高度确定时看不出来，一旦父元素是height: auto，差别就致命了：auto意味着“我的高度等我的孩子算完才知道”，而孩子又在说“我的高度等爹算完才知道”。互相等，循环依赖，浏览器必须打破这个环。

打破的方式很干脆：认输，把子元素的百分比高度算成auto。于是子元素的高度回到“由自己的内容决定”，你看到的就是背景色只铺了内容那一截。

我习惯用这个类比记它：两个人互相问“你多高”，谁都不肯先报数，那这场对话的唯一结局就是“跟你一样”，而“跟你一样”在没有任何一方先开口的前提下等于“未知”。百分比高度就是那个不肯先报数的人。

1.2 规范里那句话，值得抄在便签上

CSS 2.1 关于height的百分比值是这么规定的，大意是：

百分比基于包含块的高度计算。如果包含块的高度没有被显式指定（也就是它依赖内容高度），并且这个元素不是绝对定位的，那么该百分比的计算值按auto处理。

这句话里有三个关键词，每个都对应一类踩坑现场：

• 显式指定：height: 600px、height: 50vh、height: 30rem算显式；height: auto、height: fit-content、height: max-content不算。注意min-height和max-height也不等于height，它们是在height算完之后再做钳制的，不能拿来当参照物。
• 依赖内容高度：一个高度为auto但内部有文本的div，它的高度就是依赖内容的；哪怕它实际渲染出 800px，对子元素来说仍然是“不确定”。
• 不是绝对定位的：这句话给了绝对定位元素一个例外口子，也正是后面方法二能成立的根本原因。

实际写页面时，你几乎不会去翻规范，但只要你记住“百分比高度要一个确定的数当分母”，90% 的困惑当场就散了。

1.3 三个最常见的误判，先排掉

误判一：以为父元素写了height: 100%就算数。常见于“三层套娃”结构。你给中间层写了height: 100%，但那层的父层是height: auto，于是中间层自己也算成auto，链条在上面就断了。百分比高度是一条从根往下的链，任何一环是auto，下面全部作废。想靠这条路走通，最终得一路顶到html、body上给确定高度，非常笨重，而且一旦中间插入一个自适应高度的容器就又断了。

误判二：以为min-height能顶替height。给父元素写min-height: 600px，再把子元素设height: 100%，在不少场景里确实能看到“撑开了”，但这是巧合而不是规则。真正起作用的往往是父元素被min-height钳制后的实际高度被浏览器当成了可用参照，而不同引擎在这种边界上的处理并不完全一致。我自己不会把这种写法放进正式代码，只在临时调试时用。

误判三：在 flex 容器里看到“生效了”，就以为是height: 100%起了作用。这是最常见的一种自我欺骗。你给父元素加了display: flex，顺手保留着子元素的height: 100%，刷新一看好了，于是得出结论“flex 能让 100% 生效”。结论方向没错，但机制理解错了——真正干活的是align-items: stretch，height: 100%在旁边什么都没做。

下面这张表可以先存着，遇到“百分比高度不生效”时对着看：

2. 方法一：把父元素变成弹性容器，让拉伸机制干活

2.1 最小可用代码，五行搞定

假设就是那个左右分栏的卡片：

<div class="card"> <div class="card__side">分类一 / 分类二 / 分类三</div> <div class="card__main"> 右边是一大段说明文字，内容多到足以把卡片撑开…… </div> </div>

.card { display: flex; align-items: stretch; /* 默认值，显式写出来是为了防止被别处的样式覆盖 */ } .card__side { width: 220px; background: #f5f7fa; } .card__main { flex: 1 1 auto; padding: 16px; }

就这样，不需要给.card__side写任何高度。左边那栏的背景色会跟着右边内容的高度一路铺到底部，右边再长它也跟得上。

这里我特意没有写height: 100%。写不写视觉结果一样，但在 flex 里写它反而容易让人误判机制，后面维护的人会以为这一行是必要的。

2.2 为什么这样能成：auto 加上 stretch 正好凑成一对

这套机制的关键在于两个条件同时成立：

第一，弹性容器display: flex默认flex-direction: row，主轴是水平的，交叉轴是垂直的。子项在交叉轴上的尺寸由align-items控制，默认就是stretch。

第二，规范里对拉伸有个前置条件：只有当子项在交叉轴方向的尺寸属性计算值为auto，且align-self是stretch、交叉轴方向没有auto外边距时，才会执行拉伸。也就是说，一旦你给子项写死了高度，拉伸就不管它了。

而前面 1.2 讲过，父容器高度不确定时，子项上的height: 100%会被算成auto。这两个规则一相撞，结果就是：你写了height: 100%，它被算成auto，恰好满足拉伸条件，于是被拉到和所在行一样高。你看到的“生效”，是stretch接的盘，跟你那个 100% 没有因果关系。

反过来说，这也解释了一个非常经典的翻车场景：

.card { display: flex; align-items: center; /* 为了垂直居中，顺手改了 */ }

改完这一刻，.card__side的height: 100%立刻打回原形，背景色又缩回三行的高度。因为align-items: center关掉了拉伸，而那个 100% 从头到尾就是auto。这一条我在项目里见过不止一次，改的人还坚称“我记得之前是好的”。

2.3 四个必须知道的边界条件

边界一：方向变了，拉伸的轴也变了。如果你把容器改成flex-direction: column，交叉轴变成水平方向，stretch拉的是宽度，高度不再被自动撑开。这时候想让某个子项吃掉剩余高度，用的是flex-grow: 1或者flex: 1，不是height: 100%。这两件事经常被混为一谈。

边界二：flex-wrap: wrap之后，拉伸的目标是“行”，不是“容器”。一旦允许换行，容器可能被切成好几行。每个子项被拉到的只是自己所在那一行的高度。如果一行里只有一个子项，它会被拉到该行高度；如果行高由同一行最高的子项决定，矮的那个会跟上，但跨行之间不会互相对齐。做等高卡片网格时，这就是“为什么第一行三张卡等高了，第二行两张卡高度不一样”的根源。真要整行等高，得让每一行是个独立的 flex 容器，或者改用 grid 配grid-auto-rows: 1fr。

边界三：给 flex 子项加min-height: 0这件事，跟本文主题是两码事。网上很多文章把min-height: 0说成“flex 布局必加”，其实它解决的是子项内容溢出、滚动条出不来、文本把容器撑爆这类问题。它跟“百分比高度不生效”没有直接关系，别混着记，否则排查时会往错误方向找。

边界四：改父容器的display，影响半径是整个容器。把.card变成 flex 之后，它的所有子元素都变成 flex item：float全部失效，display: inline-block会被块级化，相邻兄弟之间的垂直外边距不再折叠，文本节点会变成匿名 flex item 参与布局，连::before、::after都会被当成独立的一项排进去。如果你的目标是“只让某一个子元素撑满”，而父容器里还有一堆别的元素需要保持原来的文档流行为，那方法一就不合适——这时候该看方法二。

2.4 顺手换个写法：单格子 grid 也能干同样的活

如果你的需求就是“一个容器里只有一两个元素，想让其中一个铺满高度”，display: grid比 flex 更省心，因为 grid 容器的子项默认也是stretch：

.card { display: grid; grid-template-columns: 220px 1fr; }

两行 CSS，左右分栏和等高同时解决，连子元素都不用写宽度。这是我在新项目里最常用的写法。它和 flex 方案的原理是同一个（都是交叉轴拉伸），区别在于 grid 更适合“明确的二维划分”，flex 更适合“一维排列 + 弹性伸缩”。两者都要求你别去动align-items，一改成center或start，拉伸同样立刻失效。

3. 方法二：绝对定位配 top/bottom，把高度“夹”出来

3.1 代码形态

还是那个卡片，这次不动父容器的display，只动定位：

.card { position: relative; } .card__side { position: absolute; top: 0; bottom: 0; left: 0; width: 220px; background: #f5f7fa; } .card__main { margin-left: 220px; /* 给绝对定位的兄弟让出位置 */ padding: 16px; }

现代写法可以用inset: 0一次写完四个方向，但如果你还要兼容较老的引擎，老老实实写top/right/bottom/left更稳。

3.2 为什么这套能稳定撑满

关键在于绝对定位元素的包含块变了。普通元素的包含块是父元素的内容盒，而绝对定位元素的包含块是最近的已定位祖先的内边距盒。这个切换带来两个后果：

其一，百分比高度不再受“包含块高度是否显式指定”那一条限制——规范里那句例外正是给绝对定位留的。所以理论上在绝对定位元素上写height: 100%是有机会生效的。

其二，更重要的是，当你同时给出top和bottom而把height留成auto时，浏览器会直接拿这两个约束把高度“夹”出来：高度 = 包含块高度 − top − bottom。这个计算不依赖任何百分比解析，走的是约束求解的路子，因此在各种引擎里表现都很稳。

这也是我个人的偏好：在绝对定位里我不写height: 100%，只写top: 0; bottom: 0。前者要靠百分比解析，后者靠约束求解，后者的确定性高一个档次。

3.3 高度只能从“别人”身上来

方法二有个绕不过去的前提：绝对定位元素脱离了文档流，它不占据空间，也不会把父元素撑高。所以父元素的高度必须由其他在流内的内容提供。

上面那段代码里，撑高.card的是.card__main那一大段文字。如果你把右边的内容删空，.card的高度瞬间变成 0，左边那栏跟着消失——不是被隐藏了，是高度真的没了。这个现象在“内容异步加载”的页面里特别容易撞上：骨架屏阶段看起来正常，数据一回来列表空了，整个侧边栏集体塌陷。

所以用方法二时，我会给父元素补一条最低保障：

.card { position: relative; min-height: 320px; }

或者干脆让另一个在流内的子元素承担撑高职责，并在结构上保证它不会为空（比如放一句兜底的提示文案）。

3.4 过度约束：top、height、bottom三个一起写会怎样

这是一个很隐蔽的坑。当你同时写了：

.card__side { position: absolute; top: 0; bottom: 0; height: 100%; /* 多余的一行 */ }

在垂直方向上就出现了三个约束，而包含块的高度是固定的，三者不可能同时满足。规范的处理方式是：对于这种“过度约束”的情况，忽略bottom，按top+height来定位。结果就是你写的height: 100%在父元素高度不确定时被算成auto——auto又回到“约束求解”，bottom被忽略，靠着top + auto + bottom碰巧又夹出来了，视觉上看起来没问题。但只要某天父元素的高度变得确定了（比如加了min-height或者内容变多触发重排），height: 100%就真的按数值解析，bottom彻底失效，元素可能超出容器底部。

排查这类问题时，我会打开开发者工具，把该元素的height、top、bottom三个计算值一起看。如果bottom显示的是那个被忽略的原始值而不是实际生效值，就说明踩到过度约束了。规矩就一条：要么用top + bottom，要么用top + height，别同时上三个。

3.5 副作用清单，用之前先过一遍

副作用一：脱流带来的空间消失。上面已经说过，父元素高度只能靠别人。同理，被绝对定位的那个子元素，它的外边距不再影响兄弟，也不再参与父元素的高度计算。

副作用二：内边距被“吃掉”。因为包含块是内边距盒，inset: 0的绝对定位子元素会盖住父元素padding占据的区域。父元素写了padding: 24px，你期望子元素在内容区里撑满，实际上它会贴着边框内沿。这个差异在做带内边距的卡片遮罩时特别明显，网上无数“遮罩层为什么要多写 24px”的帖子都源于此。

副作用三：层叠与点击。绝对定位元素默认会盖在同层的普通兄弟上面，如果父元素上没设pointer-events相关的东西，它不是“透明”，它会挡住底下内容的点击。做图片遮罩、加载态覆盖层时，要么给遮罩加pointer-events: none，要么确认它确实该拦截点击。

副作用四：兄弟要让位。绝对定位的子元素不占位，在流里的兄弟不会自动避让，必须手动给margin-left或padding-left。布局一改，两个地方的数值就得同步改，这是长期维护的隐患。我一般会把宽度抽成 CSS 变量：

.card { --side-w: 220px; position: relative; } .card__side { position: absolute; inset: 0 auto 0 0; width: var(--side-w); } .card__main { margin-left: var(--side-w); }

这样改宽度只动一个地方，省掉一类低级错误。

4. 两种方法怎么选，以及它们各自的影响半径

4.1 对照表：把差异摆在一张表里

4.2 五个真实场景，我分别会怎么选

场景一：后台卡片的左右分栏。选方法一（grid 写法优先）。两块内容都在流内，语义清晰，右侧内容增长时左侧自动跟随，不需要维护额外的宽度变量。

场景二：图片上的渐变遮罩、播放按钮覆盖层。选方法二。遮罩本身不参与文档流是最合理的行为，它不该影响图片的尺寸。图片用display: block; width: 100%，遮罩inset: 0，两行就完事。

场景三：列表里每张卡片要求等高，但卡片内部是纵向排列（标题、摘要、标签、按钮）。这种情况方法一和方法二都不该直接上，正确做法是把外层网格或弹性容器放在列表层：display: grid; grid-template-columns: repeat(3, 1fr);配grid-auto-rows: 1fr，让每一行等分，卡片内部再用flex-direction: column加margin-top: auto把按钮压到底部。先分清“谁和谁要等高”，比急着写height: 100%重要得多。

场景四：表单里输入框和按钮并排，想让它俩一样高。这属于交叉轴对齐问题，跟百分比高度无关。方法一里把align-items设成center或者干脆让输入框height: 40px，都比折腾百分比靠谱。不要为了对齐去打百分比高度的主意。

场景五：只有一个子元素，父元素高度也就是子元素高度。这种情况下height: 100%本来就是多余的，删掉即可。很多“百分比高度不生效”的疑问，追问到最后发现压根不需要它。

4.3 那些能凑合但别当主力的写法

display: table/table-cell。表格单元格天然等高，这是早期做等高布局的主流方案。缺点也很明显：会引入表格的固有行为，margin在表格单元格上不生效，响应式断点处理起来别扭。除非在维护十年前的老代码，我不建议新项目再用。

padding-top百分比做比例盒。百分比padding的参照是宽度，所以padding-top: 56.25%能做出 16:9 的固定比例容器。这是视频封面、轮播图的经典做法。但要注意：它做出来的是“高度由宽度决定”的盒子，跟你想要的“跟随兄弟内容撑高”完全是两个方向的需求。现在有aspect-ratio: 16 / 9，新项目直接用这个，可读性好得多。

用脚本量高度写 CSS 变量。用ResizeObserver监听父元素，把高度写到自定义属性上。这是兜底方案，能用，但会让布局依赖 JS 执行时机，首屏容易闪一下。我只有在“父元素高度由完全不可控的第三方内容决定”时才会考虑，比如嵌入的富文本或图表容器。

5. 常见问题与排查清单

5.1 速查表：症状对原因

5.2 三个我印象比较深的踩坑记录

坑一：删了一行“看起来没用”的align-items。某次改版需要把卡片内的文字垂直居中，我在容器上加了align-items: center。上线后左侧导航栏背景缩水，被反馈成“样式错乱”。排查半天才想起来，那个背景满高本来就是stretch撑出来的。最后的解法是把居中放到内层元素上，容器层的align-items保持默认。教训：容器上的对齐属性是给别人用的，改之前先想想有没有人靠它活着。

坑二：overflow: hidden把拉伸效果截断了。父容器加了overflow: hidden做圆角裁剪，结果子元素被拉伸到整行高之后，末尾一小截被裁掉——因为子元素本身带有margin-bottom，而拉伸算的是行高，不扣外边距。这种视觉偏差只有几像素，肉眼很难发现。处理方法是在子元素内部再包一层承载背景，让外层只负责尺寸。

坑三：异步数据把绝对定位方案打穿。一个详情页用方法二做了左侧信息栏的满高背景，本地测都好好的，因为测试数据里右侧内容够长。真实环境里筛选条件命中空列表，右侧变空，父元素高度归零，整个左侧栏连同背景消失。这个问题在接口正常的时候永远不会出现，特别阴。后来我在父元素上补了min-height，并在空状态组件里塞了一行占位文案。

5.3 三步定位法：以后遇到这类问题别瞎试

第一步，确认子元素自己的高度是不是被别的东西抢了。打开开发者工具，选中子元素，看 Computed 面板里的height。如果是auto，说明百分比压根没解析上；如果是具体数值但视觉不对，那问题在别处（box-sizing、父元素padding、overflow）。

第二步，往上逐层看height和display。从子元素的父级开始一路向上一层一层查：height是不是auto，display是不是 flex 或 grid，align-items有没有被设成非stretch。90% 的情况在这一步就能定位到。我习惯在调试时给每一层临时加outline: 1px solid red，比背景色更直观，因为它不占布局空间，也不会被overflow: hidden裁掉。

第三步，判断该改结构还是改样式。如果“谁和谁要等高”这件事本身就说不清楚，那说明结构有问题，别在样式层硬凑。我遇到过不少页面，为了一个视觉上等高的效果，在父容器上叠了四五个属性，最后既不敢删也不知道为什么能跑。这种代码比不生效更麻烦。

提示：临时排查时用outline代替background-color标盒子边界，它不参与盒模型计算，也不会被裁剪，看完直接删，不会留下视觉残留。

6. 一点个人经验

这块内容我前后带过几拨新人，发现大家卡住的往往不是“不知道怎么写”，而是“不知道该先问什么”。我现在给的建议只有一句：先问“父元素的高度，在布局计算的那一刻，是一个确定的数吗”。如果答案是“不确定”，那height: 100%这条路直接放弃，别浪费时间加!important；如果答案是“确定但被撑高了”，那说明你看的是渲染结果而不是属性值，回去看 Computed 面板。

具体到选型，我自己的默认顺序是：能用 grid 的两行代码解决就绝不上 flex，需要覆盖层这种“不该占地方”的东西就用绝对定位配inset，两边都不合适时才考虑脚本兜底。至于height: 100%这行代码，我在近三年的新代码里几乎没再写过——不是它不能用，是能替代它的方案都比它明确。

还有一个习惯值得养：任何一个让布局“从塌陷变成撑满”的属性，都顺手在注释里写一句它为什么在这儿。比如align-items: stretch; /* 左侧栏满高依赖此处的默认拉伸，勿改 */。半年后接手的人（很可能就是你自己）会感谢这一行注释。