企业官网建设流程全解析

CSS这套东西，说难真的不难，说简单，等你把字体、盒子、flex、定位这四块混在一起用的时候，又会发现哪哪儿都不对劲。我刚入行那会儿也是这样，网上教程东看一篇西看一篇，属性全认识，真到写页面布局的时候，脑子还是一团浆糊。后来咬牙把这几块硬骨头系统地啃了一遍，把笔记整理成了自己的“排错手册”，才算是真正从“会用”变成了“能用明白”。

这篇笔记就是把我在实际开发中反复用到的核心知识点串了一遍，包括字体样式的继承与覆盖、盒子模型的宽度计算、flex布局的伸缩规则、定位的包含块逻辑，每一节都会顺带讲一些我踩过的坑和实测有效的排查套路。不管你是刚学完HTML标签、准备攻CSS的新手，还是已经写了一阵子但总觉得布局控制不住的同学，这份笔记应该都能帮你省下不少瞎折腾的时间。

1. 字体样式：看似简单，坑却不少

1.1 字体栈的书写顺序与中文显示逻辑

很多人写font-family就是随便放一个"微软雅黑"或者"PingFang SC"，结果换台设备就发现字体完全不对。其实font-family是一个字体栈，浏览器会从左到右依次查找系统中存在的字体，找到哪个用哪个。关键点在于英文和中文字体的搭配顺序——英文字体通常要放在前面，中文字体放在后面，最后一定要留一个通用字体族兜底。

我常用的写法是：

body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif; }

这样写的好处是：英文字符优先用系统最合适的西文字体（比如Segoe UI或SF Pro），中文字符则会落到后面的PingFang SC或微软雅黑，最后sans-serif保证在任何系统上都有字体可用，不至于出现乱码方块。

还有一个容易被忽视的点：font-family是可以继承的，但如果你给某个元素单独设置了font-family，它连继承的资格都没有了，会完全覆盖父级的设置。所以如果只是想让某个段落用不同的字体，记得把这一个元素的字体栈写完整，不要只写一个字体名。

1.2 font-size、line-height与继承陷阱

font-size的取值单位五花八门，px、em、rem、vw各有各的应用场景。我个人的习惯是：根元素的字体大小用px固定，正文和标题用rem，需要跟父元素字体大小联动的局部场景才用em。rem的核心优势在于它只跟根元素绑定，不受祖先元素字体大小影响，这一点在维护大型项目时非常重要。

html { font-size: 16px; } h1 { font-size: 2rem; /* 32px */ } .small-notes { font-size: 0.875rem; /* 14px */ }

line-height这里有个非常经典的坑：如果你给line-height设置了固定像素值，比如24px，而子元素字体调大之后，行高不会跟着变，就会出现文字互相重叠的问题。正确做法是给line-height设一个无单位数值，比如1.5或1.6，它代表的是当前字体大小的倍数，子元素字体变化时行高会自动等比缩放。

我的避坑建议是全局先设一行基础样式：

body { font-size: 16px; line-height: 1.6; }

这样所有元素如果没有单独设置行高，都会继承这个倍数关系，排版就稳定多了。

1.3 文本样式：对齐、装饰与溢出的实用组合

text-align处理水平对齐，常见的left、center、right、justify四个值里，justify两端对齐容易在中文段落里产生难看的空隙，慎用。垂直对齐相对复杂一些，如果只是在单行文字里让文字在容器里垂直居中，直接让line-height等于容器高度即可，但多行文本和未知高度的容器要另想办法，后面flex章节会给出更优雅的方案。

text-decoration用的最多的是underline下划线和line-through删除线，但有一个细节是：text-decoration默认会继承，父元素加了删除线，子元素如果没有显式设置text-decoration: none，是去不掉的。这个在写商品促销价（原价带删除线、现价不带）的时候特别容易踩到。

text-overflow配合white-space和overflow可以实现文本溢出的省略号效果，单行省略号三件套是：

.ellipsis-single { white-space: nowrap; overflow: hidden; text-overflow: ellipsis; }

两行省略号需要使用-webkit-line-clamp，这是一个非标准属性但在现代浏览器中支持已经很稳定了：

.ellipsis-multi { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; overflow: hidden; }

这两段代码在各个项目里复用率极高，建议直接存进自己的代码片段库。

2. 盒子模型：布局的地基，算不清就全乱套

2.1 content-box与border-box：宽度到底怎么算

CSS里每个元素都可以看作一个盒子，从内到外依次是内容区（content）、内边距（padding）、边框（border）和外边距（margin）。这里最核心的问题是：你设置width: 200px时，这个200px到底是内容区的宽，还是包含padding和border之后的宽？

答案是：取决于box-sizing。

默认的content-box下，width只表示内容区宽度，最终元素在页面上占据的水平总宽度是width + padding-left + padding-right + border-left + border-right。也就是说如果你给一个宽度为50%的列再加20px的padding，它实际会超出父容器的50%，很可能导致两列布局直接换行。

我最早写响应式布局时就是因为没搞清楚这个，两个width: 50%的div加上border和padding之后死活排不到一行，最后只能靠计算器手动减像素，痛苦得不行。

后来项目里统一启用了border-box，整个世界清净了：

*, *::before, *::after { box-sizing: border-box; }

在border-box模式下，width表示的是包含padding和border在内的总宽度，内容区会被压缩。这意味着width: 50%加上padding: 20px，元素依然稳稳地占据父容器的一半宽度。做栅格系统、两栏布局、卡片列表时，省心程度翻倍。

2.2 标准盒模型与怪异盒模型的兼容演进

业内讲的“标准盒模型”就是content-box，而“怪异盒模型”就是IE盒模型，也就是border-box。早期IE对盒模型的解析与W3C标准不一致，导致同一份代码在IE和其他浏览器里渲染出完全不同的布局，这是很长一段时间的兼容噩梦。

现在回头看，border-box的思路其实更符合直觉：我告诉浏览器这个元素总共占多宽，你内部怎么分配我不管。所以现代CSS重置样式表里普遍把box-sizing: border-box设为全局默认，本质是在向“怪异盒模型”靠拢，只是现在它是标准化的选择，不再是兼容性bug。

如果你是初学者，我的建议是：项目一开始就全局设置border-box，不要去记content-box下的那些像素加减计算，等以后真的遇到某些第三方组件内部使用了content-box导致宽度对不齐时，再针对性处理。日常开发中border-box就是最省心智的模式。

2.3 外边距合并与塌陷：新手最懵的垂直间距问题

垂直方向的margin有个特别反直觉的规则——相邻两个元素的margin-bottom和margin-top不会相加，而是取较大值，小的那个被合并掉了，这个现象叫外边距合并。假设上面元素margin-bottom: 30px，下面元素margin-top: 20px，最终两个元素的间距是30px而不是50px。

还有一种更隐蔽的情况是父子元素的margin塌陷：子元素设置的margin-top不会把子元素往下推，反而会带动父元素整体下移。比如父元素里第一个子元素设置margin-top: 40px，你希望看到的是子元素和父容器顶部之间出现40px空隙，结果往往是整个父元素往下移动了40px，子元素依然贴在父元素顶部。

我处理这个问题的三板斧：

• 给父元素加padding-top替代子元素的margin-top，但要注意盒子总宽变化
• 给父元素加overflow: hidden，这能创建一个BFC，阻止子元素margin溢出
• 给父元素加border-top，哪怕透明边框也行，效果同上

后面两个方式本质上都是让父元素成为一个独立的块级格式化上下文（BFC），BFC内部的margin不会与外部的margin发生合并或渗透。理解这一点之后，间距问题就不再靠试错解决了。

3. flex布局：从“会用它”到“想清楚再用它”

3.1 容器属性与项目属性全览

flex布局是目前最主流的单维布局方案，解决了块级元素默认垂直堆叠、无法方便地水平排列的问题。它的核心思想是给父容器设置display: flex后，子项目（直接子元素）会自动沿着主轴排列。

容器上常用的属性有六个：

• flex-direction：决定主轴方向，row是水平从左到右，column是垂直从上到下
• justify-content：控制项目在主轴上的对齐方式，center居中、space-between两端对齐、space-around环绕分布
• align-items：控制项目在交叉轴上的对齐方式，控制单行内的垂直居中一般用这个
• flex-wrap：默认nowrap会让所有项目挤在一行，wrap允许换行
• align-content：多行时控制行与行的对齐方式
• gap：项目之间的间距，比单独设margin省事得多

项目自身也有一些关键属性，最常用的是：

• flex-grow：剩余空间怎么分配给项目，默认0不分配
• flex-shrink：空间不足时项目是否压缩，默认1
• flex-basis：项目在主轴上的基准尺寸，优先级高于width

这里最容易搞混的是flex-basis和width的优先级问题。在flex布局中，只要flex-basis不是auto，它就会覆盖主轴方向上的宽度设置。比如一个项目设置了width: 100px，但flex-basis: 200px，实际占据的主轴空间是200px。这个知识点我见过不少工作两三年的前端都会弄错，值得特别记一笔。

3.2 经典布局案例：垂直居中、两栏与等分布局

flex解决“垂直居中”是它最出圈的能力。以前用line-height只能处理单行文本，用绝对定位加transform虽然可行但要写好几行，flex一行搞定：

.center-container { display: flex; justify-content: center; align-items: center; }

高度不确定、内容数量不确定、多行文本，统统可以垂直水平居中，这就是flex比老的居中方案更强大的地方。

两栏自适应布局也很常见，比如左侧固定宽度200px的侧边栏，右侧占满剩余空间：

.layout { display: flex; } .sidebar { flex: 0 0 200px; /* 不放大、不缩小、基准宽度200px */ background: #f0f0f0; } .main { flex: 1 1 auto; /* 放大占满剩余空间 */ background: #fff; }

这里的flex: 0 0 200px其实是flex-grow: 0; flex-shrink: 0; flex-basis: 200px的简写，表示侧边栏固定宽度不可缩放。右侧flex: 1表示将父容器剩余的空间全部吸过来，从而实现自适应宽度。

我之前做过的移动端个人中心页面里，几乎每个模块都用了等分布局，比如底部的三个操作按钮、顶部的四个统计数字，实现方式非常简单：

.btn-group { display: flex; } .btn-group .item { flex: 1; text-align: center; }

每个item的宽度自动相等，不需要手动计算百分比，新增按钮也不需要调整别的项目宽度，维护成本很低。

3.3 flex布局的几个隐藏陷阱与排查思路

flex布局看着爽，但实际开发中也有几个典型的坑，这里把我踩过的都列出来。

第一个坑是子元素内容撑破容器。给一个flex容器里的项目设置了flex: 1，但项目内部有一长串的文本或宽图片，结果项目宽度还是被内容撑开，并没有按预期平分空间。原因往往是项目的内容默认min-width: auto，也就是说项目的最小宽度不能小于内容的固有宽度。解决办法是给项目加上min-width: 0，允许它在必要时收缩到比内容更窄，配合overflow: hidden或text-overflow就能正常显示省略号了。

第二个坑是flex容器里的最后一个元素底部对齐不起作用。如果你想让某个项目吸底显示，可以给该项目设置margin-top: auto，这个技巧比挨个计算高度方便得多。例如消息列表里，每条消息的发送时间要固定在底部右侧，用margin-top: auto直接推到底部，代码简洁且不需要知道父容器高度。

第三个坑是百分比高度不生效。flex布局里子元素设置height: 100%有时无效，因为父元素的高度是由内容撑开的，没有明确的height值，子元素的百分比找不到参照。解决办法是让父元素也设置为flex容器，并通过align-items: stretch让子元素默认拉伸填满，从而避免直接依赖百分比高度。

还有一点要注意：flex属性简写与长写的细节差异。比如flex: 1是flex: 1 1 0%的简写，而flex: auto是flex: 1 1 auto的简写，两者的flex-basis基准值不同，前者是从0开始平均分配，后者是从内容尺寸开始分配。这个差异在做等宽分列时会直接影响表现，建议还是自己明确写全flex-grow flex-shrink flex-basis三个值，别依赖简写默认值。

4. 定位：四个值背后的完整逻辑

4.1 relative、absolute与包含块机制

CSS的定位属性position有五个值：static、relative、absolute、fixed、sticky。其中static是默认值，也就是正常文档流的位置，这个不多说。重点在于后四个值的定位参照逻辑。

relative相对定位是相对于元素自身原本应该出现的位置进行偏移。设置top: 20px; left: 20px后，元素会从原来的位置向下向右移动20px，但它原来占的空间依然保留，不挤占别的元素。所以relative常用于微调图标位置、给absolute子元素当包含块，以及配合z-index调整层级。

absolute绝对定位是定位体系里最特殊的一个：它完全脱离文档流，不再占据空间，它的定位参照物是“最近的、设置了定位属性的祖先元素”。如果一直向上找到祖先都没有非static的定位元素，就相对于根元素（html）定位。这也就是所谓的包含块机制。

这引出了一个极其重要的知识点：想让某个子元素相对于父元素定位，父元素一定不能是默认position: static，必须设置position: relative（或absolute/fixed，但通常用relative更安全，因为它不会脱流）。这个套路在做“右上角角标”“图片上的遮罩层”“卡片内的悬浮按钮”时几乎天天用：

.card { position: relative; } .card .badge { position: absolute; top: 8px; right: 8px; }

现实里很多人写了absolute子元素但没给父元素设relative，结果角标跑到页面角落去了，就是包含块没锁定导致的。

4.2 fixed与sticky：滚动场景下的定位选择

fixed固定定位是相对于浏览器视口（viewport）定位的，元素滚动页面时它纹丝不动。导航栏吸顶、右下角回到顶部按钮、侧边悬浮客服入口，这些场景都是用fixed实现的。

但需要注意一个特性：fixed定位的元素在父元素设置了transform、perspective、filter等属性时，会不再相对视口定位，而是相对该祖先元素定位。这在做动画时特别容易踩坑——弹窗组件里加了动画，内部的一个fixed元素就乱跑了，原理是这些属性创建了一个新的包含块，fixed被迫降级为类似absolute的行为。

sticky粘性定位是CSS后来新增的一个比较灵活的值。它的行为介于relative和fixed之间：当元素在屏幕上还没滚出指定阈值前，它表现为相对定位；一旦滚到阈值，它就“粘”在那里变成类似固定定位的效果。典型的应用就是表格表头吸顶、分类列表的标题吸顶。

sticky有个生效前提非常关键：它的父容器高度必须大于元素本身高度，而且父容器不能有overflow: hidden或overflow: auto，因为这会破坏粘性定位的作用范围。我遇到过不少粘性失效的bug，最后查下来都是父级带了overflow: hidden导致。

4.3 z-index层级与堆叠上下文

z-index控制的是定位元素（非static元素）在垂直方向上的堆叠顺序，数值大的在上层。新手容易以为只要z-index设得足够大（比如99999）就能压住一切，但实际上不是这么回事——z-index是受堆叠上下文约束的。

堆叠上下文是个比较抽象的概念，简单理解就是一个独立的“层级小世界”。在这个小世界里，子元素的z-index再高，也只能在小世界内部比较高低，无法跨越父级去压住外面的元素。触发堆叠上下文的条件很多，常见的有：

• position定位且z-index不是auto
• opacity小于1
• transform不是none
• filter不是none
• flex容器的子项目且z-index不是auto

有一个最典型的案例：A是一个定位元素，z-index: 100，它内部有一个子元素A1，z-index: 999；B是另一个定位元素，z-index: 50。虽然A1数值上比B大很多，但它始终无法显示在B上方，因为A1的z-index只是A内部层级世界里的数值，对外它代表的是A这个整体（z-index 100）。这就解释了为什么有时把z-index调得很大也没效果——不是数字不够大，而是层级世界不对。

我排查这类问题的套路是：如果发现垂直堆叠不对，先检查元素是否都被同一个父容器包着，再逐层查看有没有transform、opacity、filter等属性，把它们临时去掉或改成不影响层级的方式，问题基本就定位了。

4.4 定位实战技巧：居中的三重境界与吸底布局

绝对定位最常用的一个技巧是结合transform实现不依赖元素自身尺寸的居中：

.overlay { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); }

这段代码的意义在于：top: 50%和left: 50%让元素左上角定位到父元素中心，translate(-50%, -50%)再沿着自身尺寸往回拉一半，最终实现元素中心点与父元素中心点完全重合。这种方案不要求元素有固定宽高，不管是文字、图片还是动态加载的数据，都能稳妥居中。我在做弹窗遮罩、Loading加载动画、图片预览浮层时都是这么写的，代码简单且不易受内容变化影响。

另一个常见场景是底部操作栏。移动端详情页底部经常有一个固定的“加入购物车”和“立即购买”操作条，用fixed实现很简单，但要注意给页面主体加一个与操作条等高的底部padding，避免页面底部内容被遮挡：

.bottom-bar { position: fixed; left: 0; right: 0; bottom: 0; height: 56px; background: #fff; border-top: 1px solid #eee; display: flex; align-items: center; justify-content: space-around; } .page-body { padding-bottom: 56px; /* 跟操作条高度保持一致 */ }

这段代码里left: 0; right: 0; bottom: 0其实等价于width: 100%; top: auto;的效果，在很多场景下比手动设置宽度更稳妥，因为它不需要关心父容器的宽度计算，直接贴住视口的左右边缘。

5. CSS学习与调试的几个关键建议

5.1 用最小复现法定位问题

CSS的麻烦之处在于，一个问题往往是多个因素叠加导致的。比如一个元素没对齐，可能是父容器没设flex，可能是子元素的margin干扰，也可能是某个祖先元素创建了额外的包含块关系。我实战中排查CSS问题时，最有效的方法就是做“最小复现”——把出问题的元素复制到一个独立的新页面或CodePen里，删掉所有无关的样式和结构，只看这一小段代码的表现。

这个方法的逻辑是：如果你复现不出来，说明问题出在外部环境与某个样式组合的特殊化学反应；如果复现出来了，就把代码继续精简，直到只剩问题本身。到达那一步时，原因基本上自己就跳出来了。比如之前排查过一个按钮点击区域过小的问题，最后最小复现出来是因为font-size: 0的类名被不小心覆盖到了按钮上，导致文字和行内元素尺寸全部归零。

5.2 别背属性，掌握MDN的阅读方法

CSS属性和值是有限的，但组合方式是无限的。与其强迫自己背下一整套规范，不如学会高效查官方文档。MDN上每个CSS属性页面都有三块我反复使用的内容：语法定义区、形式化定义区（哪些属性可能影响它）、浏览器兼容性表格。遇到不熟悉的属性，先扫一眼“是否可以继承”，再看“初始值”，这两个信息能帮你快速判断它是不是某类问题的元凶。

比如text-align可以继承，而vertical-align不能继承；line-height可以继承（但继承的是倍数而不是具体像素值）；position不能继承，而visibility可以继承。这些知识不需要背，只要看MDN就能立刻获知，关键是养成“用之前查一下”的习惯。

5.3 高效利用浏览器开发者工具的CSS面板

不管用Chrome还是Edge，开发者工具里的Styles面板都是排查CSS的最强利器。平时我调试布局会重点看三个位置：一是计算样式（Computed）一栏里元素的盒子模型图，它把margin、border、padding、content的尺寸直接画出来了，盒子的哪一部分异常一目了然；二是元素上被划掉的样式，这些是被覆盖或无效的属性，能帮你快速定位优先级冲突；三是“切换到伪类状态”的功能，比如排查:hover样式时不用一直把鼠标悬停上去，直接强制激活该状态再做检查。

还有一个很实用的功能是点击Computed面板里的属性值，浏览器会直接跳转到Styles面板里对应的声明位置，并标注出具体是哪个选择器生效。对样式来源有疑问时，这个跳转能节省大量翻代码的时间。

收个尾，说点实在的

CSS学到后面会发现，真正的瓶颈不是记不住属性，而是没有建立一套“从现象反推原因”的排查逻辑。写这篇文章时，我脑海里反复出现这些年帮同事排查布局问题的场景，很多bug最终都不是什么高深知识，而是盒子模型、定位包含块、flex收缩这几个基础机制在特定场景下的组合反应。把这几个根扎牢了，CSS基本就算练到家了。

最后再分享一个小习惯：每次遇到奇怪的CSS现象，我会在问题解决之后顺手写一个20行以内的最小复现demo，存进一个专门的目录。时间长了，这个目录就是我的私房排错手册，比任何教程都管用。现在你做笔记，也可以按这个思路来积累，别只记“怎么用”，多记“出过什么问题、怎么查出来的”，这才是真正能沉淀下来的开发经验。