Front-end Developer Interview Questions 保加利亚语版本：前端面试题库与多语言站点的本地化构建实践
2026/9/30 2:34:07
我见过太多人学 web 前端 的第一步，是打开浏览器按 F12，或者从网上找一段现成的 HTML 模板复制过来——那段模板的第一行永远是<!DOCTYPE html>，第二行是<html lang="zh-cn">，<head>里塞着<meta charset="utf-8">和一堆<meta name="viewport" ...>。很多人复制了几十遍，改过标题、换过图片、调过颜色，却从没停下来想过：这几行到底在干什么，删了会怎样。
真删掉DOCTYPE，页面在大多数情况下居然还能正常显示——这就是它最容易被忽略的原因。但它在默默决定浏览器用哪种模式解析你的 HTML、CSS 盒模型按哪套规则计算、某些老式属性怎么写才生效。HTML 和 CSS 的基础里，那些"看起来没用的行"，恰恰是后面所有布局错位、兼容异常、玄学问题的源头。
这篇东西是我把 HTML 和 CSS 这两块基础重新捋一遍的记录，不打算写成手册，查文档比看手册快得多。我更想讲清楚的是：每一行代码为什么这么写、不这么写会出什么事、以及在实际做页面时哪些写法值得固定下来当习惯。刚接触 HTML+CSS 的同学可以顺着看，写过小半年、能拼出页面但总觉得是在"试出来"而不是"写出来"的人，也可以对着查漏。零基础能看懂，有基础的能捡到细节。
1. 从 说起：文档骨架里每一行的实际作用
1.1 DOCTYPE 不是标签，它是给浏览器看的渲染模式开关
先说一个反直觉的事实：<!DOCTYPE html>不是 HTML 元素，它是一份"声明"。它没有闭合标签，写错了也不会报错，浏览器只会根据它的存在与否做一件事——决定进入标准模式（standards mode）还是怪异模式（quirks mode）。
完整写了<!DOCTYPE html>，浏览器走标准模式；完全不写，或者把它写在一个注释后面，浏览器就会掉进怪异模式。怪异模式最直接的后果是盒模型的计算方式变了：在老式规则里，width会包含padding和border，而标准模式里width只是内容区宽度。这意味着同一段 CSS，在两种模式下渲染出来的盒子大小完全不同。这也是为什么有人抱怨"我照着教程写的宽度，怎么溢出了"，回头一看，DOCTYPE 被某个编辑器格式化插件给挪位置了。
从历史看，早期 HTML 4.01 的声明长得吓人，要写一长串带PUBLIC标识的字符串，还得附上 DTD 地址，浏览器靠这些字符串来区分 HTML 4.01 Strict、Transitional 等不同模式。HTML5 把这件事简化成了一行<!DOCTYPE html>，大小写不敏感。所以现在你看到的所有声明都一样，这不是偷懒，是规范主动砍掉了历史包袱。
注意：DOCTYPE 必须写在文件最顶部。理论上允许前面有空白字符，但一旦前面出现注释、XML 声明或者任何可见字符，部分浏览器会直接判定为"缺失"，掉进怪异模式，而且不会有任何提示。
1.2
与 各自管什么很多人写lang="zh-cn"是照着抄的，其实这个属性有实际作用，而且不止一个。
它首先影响的是屏幕阅读器。读屏软件需要知道页面用的哪种语言，才能调用正确的发音规则。一个中文页面被标成lang="en"，读屏软件会用英语音素去念中文，结果是灾难性的。其次它影响浏览器的翻译提示——Chrome 判断要不要弹出"是否翻译此页"，很大一部分依据就是lang和实际内容语言是否一致。再往下，它还影响字体的回退顺序和拼写检查的语言选择。中文页面按规范写zh-CN（语言码大小写不敏感，zh-cn也能用），大陆简体场景下不建议写zh-TW。
<meta charset="utf-8">管的是字符编码。浏览器是先拿字节、再按某种编码表翻译成字符的，如果这个"翻译表"用错了，中文就会变成乱码方块。这条 meta 有个硬性约束：必须出现在<head>开始后的前 1024 字节内。浏览器拿到 HTML 文件时会先嗅探前 1024 字节，看到编码声明就用声明的编码解析全文；如果没在这个范围内找到，就只能靠猜测，或者退回操作系统默认编码。
我踩过的最典型的一次乱码，是文件本身存成了 GBK，但 meta 写的是 utf-8。原因是编辑器保存时用了系统默认编码，写代码的人完全没注意。排查这种问题不用猜，打开开发者工具的 Console，或者看 Network 里这个 HTML 请求的 Content-Type 响应头，对比一下就能定位。习惯上我把 VSCode 的全局配置里"files.encoding": "utf8"固定下来，从此再没遇到过。
<meta name="viewport">则是移动端适配的开关。不写它，手机浏览器会默认按 980px 的虚拟宽度渲染再整体缩放，你写的响应式媒体查询全部会失效。标准写法是：
<meta name="viewport" content="width=device-width, initial-scale=1.0">width=device-width表示布局宽度等于设备物理宽度，initial-scale=1.0表示初始不缩放。做移动端页面时这两项是底线，user-scalable=no这类禁止缩放的写法现在不建议加，会伤害可访问性。
1.3 语义化标签该用在哪，div什么时候才够用
骨架里剩下的就是<head>和<body>的分工：<head>装的是给浏览器和搜索引擎看的元信息，<body>装的才是用户能看见的内容。<title>是唯一一个"在 head 里但用户看得到"的元素，它决定标签页文字、收藏夹名称和搜索结果标题，做每个页面都该单独写。
<body>里的标签，我建议一开始就养成语义化的习惯，而不是全程div堆到底。原因是这些标签自带默认行为，用对了能省掉一堆 CSS，也更利于可访问性。几个常用的：
<header>/<footer>：页头页脚，一个页面可以有多个（比如每篇文章内部各有一个）<nav>：导航区域，读屏软件会识别成导航并允许快速跳转<main>：主体内容，规范要求一个页面只出现一次<article>/<section>：前者表示能独立成篇的内容，后者是主题性的分区<h1>到<h6>：标题层级，不要为了字体大小去跳级，字号该用 CSS 调<button>：可点击的动作。用div加onclick虽然也能跑，但键盘无法聚焦、回车无法触发，还需要手动加tabindex和role，纯属自找麻烦<ul>/<ol>/<li>：并列的列表结构，别用一堆div并排来假装列表
反过来，纯粹的布局包裹层就用div。给每个布局容器都强行套语义标签，反而会让大纲结构变得混乱，读屏软件读出来的层级也会很怪。判断标准很简单：这块内容有没有独立的语义、能不能被单独理解，有就用语义标签，没有就用div。
2. CSS 的引入方式与选择器：先搞清楚样式从哪来、谁压过谁
2.1 行内样式、style 标签、外部文件各自的适用场面
CSS 一共有三种接入方式，每一种都有明确的适用边界，用错地方会给自己挖坑。
行内样式写在元素的style属性里，优先级最高，但它把结构和表现又绑回了一起，改一次样式要翻整页 HTML。它唯一合理的场景是动态样式：比如某个进度条宽度要根据 JS 计算的结果实时变化，写成style="width: 73%"比生成对应类名更直接。除此之外都不建议用。
<style>标签适合单文件的小页面、演示代码、或者需要随首屏同步渲染的关键样式。它的缺点是没法被浏览器缓存，页面多了以后每个 HTML 都要重复一遍样式，改一处得改十处。
外部样式表用<link rel="stylesheet" href="xxx.css">引入，是正式项目里的默认选择。它可缓存、可复用、便于分工。
这里要单独说一下@import。它在 CSS 里也能引入别的样式表，但和<link>有本质区别：<link>是 HTML 解析阶段的并行请求，@import必须等父样式表下载并解析完，才发现还有个子文件要下载，形成串行链路。CSS 是阻塞渲染的资源，串行下载直接把首屏时间拉长。所以除了极少数按条件加载的场景，一律用<link>。
顺带提一个真实项目里会遇到的细节：多个<link>引用的样式文件，覆盖顺序取决于引入顺序，后引入的在后。当权重相同时，谁写在后面谁的规则生效。有些旧项目里样式分散在七八个文件中，改一个按钮颜色不生效，找半天发现是另一个文件里有一条更靠后、权重相同的规则把它盖掉了。新项目里把样式按"重置层—基础层—组件层—页面层"排好顺序，能省掉大量这类排查。
2.2 权重计算：为什么你的样式"明明写了却不生效"
CSS 里有一个权重的概念，理解它之后，绝大多数"样式不生效"的问题都能自己定位。规则可以用一个四位数的近似值来记：
| 来源 | 近似权重 | 例子 |
|---|---|---|
!important | 最高 | color: red !important; |
| 行内样式 | 1000 | style="color: red" |
| ID 选择器 | 100 | #header |
| 类、属性、伪类 | 10 | .btn、[type="text"]、:hover |
| 标签、伪元素 | 1 | div、p、::before |
| 通配符、继承 | 0 | *、父元素继承下来的样式 |
权重不是按单个选择器的值相加，而是按四位分别比较：先比 ID 位，相同再比类位，再比标签位。所以.a .b .c .d .e .f .g .h .i .j这样的十个类名加起来也就 100，和单个#id打平——这也是为什么养成"少用 ID 写样式"的习惯会舒服很多，ID 一动就是 100 起步，后期想覆盖只能上!important。
我自己总结的几条实操原则：
- 样式只用类选择器写，ID 留给 JS 找元素或锚点跳转
- 选择器不要超过三层嵌套，
.page .list .item .title .text这种又长又脆，改一个结构就断 !important当成报警器，只有当你发现某条第三方库的样式用正常手段盖不住时才用，用了就在旁边写一行注释说明原因，否则半年后自己都不记得为什么加
另外还有一个容易被忽略的点：继承。color、font-family、font-size、line-height、text-align这类文本属性会被子元素继承，而margin、padding、border、background、width不会。所以你在父容器上写color: #333，里面所有文字都会变灰，但你在父容器上写padding: 20px，子元素不会跟着有内边距。理解这一点，能解释掉很大一部分"为什么这个属性传到下面去了"的困惑。
2.3 通配符 * 能不能用
初学者最常看到的重置写法是这两行：
* { margin: 0; padding: 0; }它的优点是粗暴有效，所有元素的内外边距一次清干净。缺点有三个层次。
第一是性能。通配符会匹配文档中每一个元素，包括<head>里的、伪元素之外的、以及未来动态插入的元素。现代浏览器对这种匹配有优化，页面上万级元素时差异才明显，日常小页面感觉不到。真正的代价是第二条。
第二是误伤。margin: 0会把<ul>的默认缩进、<p>的段落间距、<table>的单元格间距全部清掉。清掉本身不是问题，问题是你后面得一条一条加回来。更麻烦的是表单元素，input、button、select在很多浏览器里本来不继承字体设置，通配符也管不了它们的字体，你会得到一堆字体和其他文字不一致的控件。
第三是破坏浏览器默认的可访问性。默认的标题字号层级、列表缩进、段落间距是有意义的，一刀切清零之后，如果新项目忘了补回来，页面会变成一坨没有层次的文字。
我现在的习惯是用更精确的写法代替通配符：
body, h1, h2, h3, h4, h5, h6, p, figure, blockquote, dl, dd { margin: 0; } ul, ol { margin: 0; padding: 0; list-style: none; } img, svg, video { display: block; max-width: 100%; } button, input, select, textarea { font: inherit; }至于box-sizing，我在项目里仍然会写*，因为它确实需要覆盖所有元素，而且不涉及布局间距：
*, *::before, *::after { box-sizing: border-box; }注意这里加上了::before和::after，伪元素的盒模型同样要管，漏掉的话用伪元素画的装饰元素宽度会算错。
3. 盒模型：布局中九成的"对不齐"都出在这里
3.1 用一组数字把 content-box 和 border-box 算清楚
盒模型说的是：一个元素占据的空间由内容区（content）、内边距（padding）、边框（border）、**外边距（margin）**四层组成。关键分歧在于width到底量的是哪一层。
默认的box-sizing: content-box下，width只等于内容区宽度。写一个盒子：
.box { width: 200px; padding: 20px; border: 5px solid #ccc; margin: 10px; }它实际占据的宽度是200 + 20×2 + 5×2 = 250px，再加上左右外边距，在父容器里总共占250 + 10×2 = 270px。很多人写的两列布局加起来明明是 100%，结果换行，就是因为没把 padding 和 border 算进去。
改成box-sizing: border-box之后，width: 200px就是含 padding 和 border 的总宽，内容区自动被压缩成200 - 40 - 10 = 150px。这个模式在写栅格、写卡片、写表单时顺手太多：你只要定好总宽，内部怎么加 padding 都不会撑破。
margin在两种模式下都不算进width，它是盒子外面的空间，永远单独计算。这一点常被混淆。
3.2 margin 塌陷：父子穿透和兄弟合并两种情况的复现与修法
外边距合并（margin collapse）是盒模型里最反直觉的规则，只发生在垂直方向，水平方向的 margin 从不合并。它有两种形态。
第一种是相邻兄弟合并。上下两个块级元素，上面的margin-bottom: 30px，下面的margin-top: 20px，它们之间的实际间距不是 50，而是取较大值 30。这条规则其实挺好用，写列表时不用担心中间项间距翻倍。但如果你期望的是 50，就得改成给父元素加gap（flex 布局下）或者手动调数值。
第二种是父子穿透，也是真正会让人卡住的那种。父元素没有padding-top、没有border-top、没有触发块级格式化上下文（BFC），第一个子元素的margin-top会"穿透"父元素，作用到父元素外面去，表现为整个父容器跟着往下移动，而不是子元素在父容器内往下留白。复现代码：
<div class="parent"> <div class="child">内容</div> </div> <style> .parent { background: #eef; } .child { margin-top: 40px; background: #fdd; } </style>你会看到浅蓝的父容器顶部没有留白，整块往下移了 40px。修法有好几种，选哪种看场景：
| 方案 | 写法 | 副作用 |
|---|---|---|
| 给父元素加 padding | padding-top: 40px | 改变了父元素实际高度 |
| 给父元素加边框 | border-top: 1px solid transparent | 多一个像素的高度 |
| 触发 BFC | overflow: hidden | 可能裁掉溢出内容 |
| 触发 BFC | display: flow-root | 无副作用，但需要较新浏览器 |
| 用 flex 布局 | display: flex; flex-direction: column | 子元素变成 flex item，间距规则改变 |
我现在的首选是display: flow-root，它是专门为"创建一个干净的 BFC 而不引入任何其他副作用"设计的。只有在需要兼容很老的浏览器时才退回overflow: hidden。至于触发 BFC 到底意味着什么——简单说就是让这个元素内部形成一个独立的布局环境，内部元素的 margin 不再和外部合并、浮动元素会被包含进去、也不会和外部浮动元素重叠。理解这一个概念，能顺带解决掉浮动高度塌陷的问题。
3.3 居中方案对照表：不要每次都伸手去拿同一种
居中是新手问得最多的需求，也是被问得最没有必要的需求，因为方案早就成熟了。关键是分场景选：
| 场景 | 推荐写法 | 备注 |
|---|---|---|
| 单行文本水平居中 | text-align: center | 只对行内内容有效 |
| 单行文本垂直居中 | line-height等于容器高度 | 内容超过一行时会溢出，慎用 |
| 块级元素水平居中 | margin: 0 auto | 元素必须有确定宽度，且不能是浮动或绝对定位 |
table水平居中 | margin: 0 auto | table本身有确定宽度，加margin即可，不需要display: block |
| 任意内容水平垂直居中 | 父元素display: flex; justify-content: center; align-items: center | 目前最通用，首选 |
| 需要精确定位 | position: absolute; left: 50%; top: 50%; transform: translate(-50%, -50%) | 不受内容尺寸影响 |
| 网格布局 | 父元素display: grid; place-items: center | 一行搞定，语义上是二维居中 |
单独说说几个高频小问题。input里的文字居中用text-align: center就够了；让input这个控件自己在容器里居中，要分两步：给它一个确定宽度和display: block，然后margin: 0 auto，或者直接放一个用了 flex 居中的父容器里。很多人的写法是给input加text-align: center之后发现控件本身没动，就是因为混淆了"文字居中"和"元素居中"这两件事。
table的居中还有一个坑：<table>的display默认是table，不是block，margin: 0 auto在它身上是有效的，但如果给它的父元素加了text-align: center，表格会整体居中但单元格里的文字也全跟着居中了，得在单元格里再改回来。
line-height做垂直居中虽然简单，但有个隐患：它靠的是行高撑开容器，一旦文字换行成两行，整个盒子会变高，布局就崩了。所以我只在确定是单行的场景下用它，比如按钮上的文字。
4. 文本与字体：出现频率最高、也最容易被做丑的部分
4.1 字体栈、字重与中英文混排的实际处理
font-family写的是一个字体栈，从左到右找，找到哪个用哪个。中英文混排的页面推荐长这样：
body { font-family: -apple-system, BlinkMacSystemFont, "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", "Helvetica Neue", Arial, sans-serif; }顺序的意思是：优先用系统原生字体（Mac 上用苹方、Windows 上用微软雅黑），保证渲染质量，避免网络字体加载带来的白屏和闪烁。sans-serif放在最后作为兜底。字体名里有空格的必须加引号，例如"Microsoft YaHei"，不加引号虽然部分浏览器也认，但不规范，遇到某些名字会解析失败。
单位的选择值得说清楚。px是绝对值，简单直观；em相对于父元素字号，嵌套时容易层层放大，一个1.2em套三层就变成 1.7 倍了；rem相对根元素<html>的字号，不受嵌套影响，做整站缩放最方便。我的做法是：字号和间距用rem，边框、圆角这种不需要随字号缩放的用px。如果要做移动端适配，把html的font-size设成一个根据屏幕宽度计算的值（比如用calc()配合vw），全站尺寸就能等比变化。
line-height强烈建议写无单位数值，比如line-height: 1.6，而不是line-height: 24px或line-height: 1.6em。无单位值的含义是"当前元素字号的倍数"，子元素会重新按自己的字号计算；而带单位的值会被子元素直接继承成固定值，子元素字号变了行高不变，行间距就乱套了。中文正文行高在 1.6 到 1.8 之间读起来最舒服，标题可以压到 1.2 到 1.4。
字重有个容易被忽略的问题：font-weight: 600如果系统里没装对应字重的字体文件，浏览器会做"合成加粗"，也就是把正常字重拉伸模拟出来，结果笔画发虚、边缘毛糙。中文尤其明显。所以自定义字体时，一定要把用到的每个字重都给出对应的字体文件，或者干脆只用400和700这两个系统一定有的字重。
4.2 删除线、分割线、渐变字、描边字的写法
删除线有两条路。语义上表示"被删除的内容"用<del>，表示"不再准确但保留"用<s>，它们的默认样式就是删除线。纯粹的视觉需要则用 CSS：text-decoration: line-through。可以控制颜色和线型：
.old-price { text-decoration: line-through; text-decoration-color: #999; text-decoration-thickness: 1px; }要注意text-decoration写在父元素上，删除线会画到所有后代行内元素上，而且没法用子元素单独取消。这种情况改用伪元素画线更可控：
.old-price { position: relative; } .old-price::after { content: ""; position: absolute; left: 0; top: 50%; width: 100%; height: 1px; background: #999; }段落分割线最省事的做法是给元素加border-bottom，比如border-bottom: 1px solid #eee。但边界情况是：最后一段不该有分割线，而这个"最后一段"往往由数据决定，样式层面不知道。两种处理，一是用相邻兄弟选择器反向排除：
.item + .item { border-top: 1px solid #eee; }这样线永远画在除第一个之外的所有元素的上边，天然不会出现"最后多一条"。二是用:not(:last-child)：
.item:not(:last-child) { border-bottom: 1px solid #eee; }我更推荐第一种，因为它不依赖"最后一个是谁"这个前提，插入、删除、排序之后都不用改。
渐变文字的做法是把背景裁到文字上：
.gradient-text { background: linear-gradient(90deg, #ff6b6b, #4ecdc4); -webkit-background-clip: text; background-clip: text; color: transparent; -webkit-text-fill-color: transparent; }两个transparent都写是有原因的：color: transparent是标准写法，-webkit-text-fill-color是 WebKit 内核的私有属性，它能覆盖color的渲染。只写前者，在某些基于 WebKit 的浏览器里文字会直接消失或显示成黑块。这个属性组合我实际用下来覆盖范围最好。
字体外描边最稳妥的是text-shadow四方向叠加：
.stroke-text { color: #fff; text-shadow: 1px 1px 0 #333, -1px 1px 0 #333, 1px -1px 0 #333, -1px -1px 0 #333; }-webkit-text-stroke看起来更直接，但它是居中描边，一半在字外一半在字内，笔画细的字体会被吃掉笔画，行书体或者笔画密集的汉字尤其明显。所以它更适合做纯装饰性的空心字标题，正文类内容还是用text-shadow叠加。
4.3 单行与多行文本溢出省略的完整写法
单行省略是三件套，缺一不可：
.ellipsis { white-space: nowrap; overflow: hidden; text-overflow: ellipsis; }white-space: nowrap禁止换行，overflow: hidden把超出部分裁掉，text-overflow: ellipsis才把裁掉的位置换成省略号。很多人只写最后一条，发现没反应，就是因为前面两条没补上。另外要注意，这三条只在块级或行内块元素上生效，而且元素必须有确定宽度；如果元素在 flex 容器里，还得加上min-width: 0，否则 flex item 的默认最小宽度是内容宽度，根本不会被压缩。
多行省略目前最通用的是 WebKit 的方案：
.ellipsis-2 { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; overflow: hidden; }-webkit-line-clamp只认行数，不认高度，超过两行就在第二行末尾加省略号。它最初是私有属性，现在主流浏览器都实现了，可以放心用，但一定要把overflow: hidden写上，不然会被撑开。有一个限制是它和display: flex冲突，因为display被占用了。如果某个卡片既要 flex 布局又要多行省略，就把省略那层单独包一个元素出来。
希望在所有浏览器里都精确可控的话，标准方案是line-clamp配合max-height和text-overflow: ellipsis，但它的兼容性还不如上面这个老方案，实际项目里暂时还是 WebKit 那套更省心。
5. hover、tab 与动效：用 CSS 做交互的边界在哪里
5.1 :hover 在桌面端和移动端的差别，以及 @media (hover) 的必要性
:hover在桌面端毫无问题，在触屏设备上却是个麻烦。手机上没有"悬停"这个动作，点击之后的悬停状态可能会被"粘住"——点一下按钮，样式进入 hover 态，手指拿开之后还留在那里，直到点别的地方才恢复。这种"卡住的悬停"在移动端的导航、卡片、按钮上都会出现。
解决办法是把 hover 样式包在媒体查询里：
@media (hover: hover) and (pointer: fine) { .card:hover { transform: translateY(-4px); box-shadow: 0 8px 20px rgba(0, 0, 0, 0.1); } }hover: hover表示设备支持真正的悬停，pointer: fine表示指针是精确的（鼠标、触控笔），两个条件同时满足才应用。这样触屏设备根本不会拿到 hover 样式，卡住的问题从源头消失。
同时也要分清:hover和 JS 的mouseenter。前者是 CSS 状态，只影响样式，不会触发任何逻辑；后者是 JS 事件，只在进入元素的那一瞬间触发一次，元素内部的子元素之间移动不会重复触发。而mouseover会冒泡，鼠标在元素内部移动都可能反复触发，写交互逻辑时优先用mouseenter。还有一个:focus-visible，它是给键盘 Tab 聚焦用的，现在做按钮样式时应该同时处理:hover和:focus-visible，不然键盘用户看不到焦点在哪。
5.2 纯 CSS 手写一个 tab 切换控件
tab 控件的经典纯 CSS 实现靠的是单选按钮加:checked选择器。原理是：一组同名的radio天然互斥，同一时刻只有一个能处于选中态，而 CSS 的:checked伪类能感知这个状态，再去控制相邻的面板显示。
<div class="tabs"> <input type="radio" name="tab" id="tab1" checked> <input type="radio" name="tab" id="tab2"> <div class="tab-nav"> <label for="tab1">第一个</label> <label for="tab2">第二个</label> </div> <div class="tab-panel panel1">内容一</div> <div class="tab-panel panel2">内容二</div> </div>.tabs > input { display: none; } .tab-nav label { display: inline-block; padding: 8px 16px; cursor: pointer; border-bottom: 2px solid transparent; } #tab1:checked ~ .tab-nav label[for="tab1"], #tab2:checked ~ .tab-nav label[for="tab2"] { border-bottom-color: #4ecdc4; color: #4ecdc4; } .tab-panel { display: none; padding: 16px 0; } #tab1:checked ~ .panel1, #tab2:checked ~ .panel2 { display: block; }这里的关键是~这个通用兄弟选择器：input必须放在结构上和目标元素同级且靠前的位置，才能用~选中后面的兄弟。所以把input统一提到最前面，是为了让选择器成立，不是为了语义。
这个方案的优点很明显：不写一行 JS，键盘可以直接用方向键切换，读屏软件也能正确读出"选项卡"的角色和选中状态。缺点是 tab 数量固定时 CSS 要按数量写，动态增删不方便。所以如果是后端渲染的固定几个 tab，纯 CSS 完全够用；如果 tab 数量是运行时决定的，老老实实用 JS 控制一个active类更省事。
5.3 涟漪扩散与一键回到顶部的实现细节
涟漪光圈扩散指的是点击时从触点向外扩散的一圈动效。纯 CSS 版本做不了"从点击位置扩散"，但做成从元素中心扩散效果已经够好了：
.ripple { position: relative; overflow: hidden; } .ripple::after { content: ""; position: absolute; left: 50%; top: 50%; width: 10px; height: 10px; border-radius: 50%; background: rgba(255, 255, 255, 0.6); transform: translate(-50%, -50%) scale(0); opacity: 0; pointer-events: none; } .ripple:active::after { animation: ripple 0.6s ease-out; } @keyframes ripple { 0% { transform: translate(-50%, -50%) scale(0); opacity: 0.8; } 100% { transform: translate(-50%, -50%) scale(14); opacity: 0; } }三个细节值得留意。pointer-events: none必须加，否则伪元素会挡住按钮本身的点击事件。overflow: hidden也必须加，不然涟漪会扩散到容器外面。动画用spread和opacity配合，结束时透明，避免残留一层白斑。想让涟漪真的从点击坐标开始，就得用 JS 去读event.offsetX和offsetY，再动态设置伪元素的left和top，本质上还是靠 CSS 做动画，JS 只负责定位。
一键回到顶部最省事的写法是锚点加平滑滚动：
<a href="#top" class="back-to-top">回到顶部</a>html { scroll-behavior: smooth; }配合页面顶部放一个id="top"的元素，点击之后浏览器会平滑滚到那里。scroll-behavior写在html上会对整个页面生效，注意如果页面内部还有独立滚动的容器，那个容器也要单独写一遍。
一个常见的错误是把href写成href="#"。这不叫回到顶部，这叫跳到文档开头，它在 URL 后面留下一个孤立的#，而且在有<base>标签或者用了前端路由的页面里，可能触发路由跳转，把页面刷成空白。要么用#top配合目标元素，要么用 JS：
document.querySelector('.back-to-top').addEventListener('click', () => { window.scrollTo({ top: 0, behavior: 'smooth' }); });window.scrollTo的behavior: 'smooth'和 CSS 的scroll-behavior效果一样，但它是按次生效的，不会影响页面里其他滚动行为，控制粒度更细。另外这个按钮通常会配合"滚动超过一屏才显示"的逻辑，那部分用IntersectionObserver比监听scroll事件更省性能。
6. 从 VSCode 到开发者工具：把写-看-改的循环缩短
6.1 VSCode 里值得一开始就配好的几样东西
写前端用 VSCode，稍有配置和完全不配置的效率差距很大。几个我认为最值得一开始就装好的插件：
- Live Server：右键 HTML 文件选择用 Live Server 打开，本地起一个服务，保存时浏览器自动刷新。这比手动 F5 强太多，尤其是连续调样式的时候，改一下看一眼，节奏非常顺。
- Prettier：格式化工具。配合
"editor.formatOnSave": true，保存时自动把缩进、引号、分号统一。团队协作时最省事的做法是版本库里放一个.prettierrc，所有人的格式化规则一致，diff 里就不会出现大量无意义的格式变动。 - Auto Rename Tag：改开头标签，结尾标签自动跟着改。手写 HTML 时能省掉一类低级错误。
- HTML CSS Support：在 HTML 里写
class时给出 CSS 里已存在类名的补全提示，避免打错类名却发现"样式不生效"。 - Color Highlight或者类似的取色插件：把 CSS 里的颜色值用对应色块标出来，调色的时候一眼就能看出哪个是哪个。
还有Emmet，它内置在 VSCode 里不用装。写div.card>h3.title+p.desc然后按 Tab，直接展开成嵌套结构；写ul>li*5生成五个列表项。这个缩写练熟之后，HTML 的书写速度能翻倍。
编辑器的全局配置里我固定会加两条："files.encoding": "utf8"防止编码乱码，"files.eol": "\n"统一换行符防止不同系统之间的 diff 噪音。
6.2 用开发者工具读懂一个页面的构成
按 F12 打开开发者工具，Elements（或者叫"元素"）面板里看到的是浏览器当前真实的 DOM 树，不是 HTML 源码。这两者会不一样：JS 动态插入的元素会出现在 DOM 里，但源码里没有；某些标签不闭合时，浏览器会自动补全<tbody>、把<p>提前闭合，所以你在 DOM 里看到的嵌套关系可能和你写的不同。
读懂一个页面，我一般按这个顺序下手：
- 选中最上面的元素，看 Computed 里的盒模型示意图。这个示意图会标出 content、padding、border、margin 四层的实际像素值，是排查"对不齐"最直接的工具。鼠标在示意图上悬停，页面上对应的区域会高亮，一眼就能看出多出来的间距在哪一层。
- 看 Styles 面板里被划掉的属性和带删除线的值。划掉说明这条被更高权重的规则覆盖了，顺着看下面哪一条生效、来自哪个文件，很多"为什么不生效"的问题五秒钟就能定位。
- 看 Sources 面板里的样式文件。这里能看到实际加载的 CSS 及其顺序，验证一下是不是某个后加载的文件把前面的覆盖了。
- 切换设备模拟。工具栏左上角那个手机图标，可以切到不同尺寸和 DPR 的模拟视图，配合响应式模式拖动宽度，能看到媒体查询在哪个断点触发。
看别人做的页面时，Elements 面板可以临时改样式，改了之后页面上立刻生效，但不会影响服务器上的文件，刷新就恢复。这是学习别人布局思路最好的方式：看到喜欢的按钮，选中它，把它的 CSS 复制出来，改一改，看效果怎么变。这里要提醒一句，读别人的实现是为了学思路，直接整套复制、包含人家的图片和字体文件，会涉及版权问题，自己练手没问题，正式项目里要留意。
6.3 新手阶段最容易反复踩的坑清单
最后把这些年看到过、自己也踩过的高频问题整理成一张表，遇到问题按图索骥：
| 现象 | 常见原因 | 排查动作 |
|---|---|---|
| 中文显示成乱码方块 | 文件编码与 meta 声明不一致，或声明不在前 1024 字节 | 查编辑器编码和 Network 里的响应头 |
| 样式写了完全没反应 | 类名拼错、选择器路径不对、被更高权重覆盖 | 看 Styles 面板里是不是被划掉 |
| 改了 CSS 页面没变化 | 浏览器缓存了旧文件 | 强制刷新，或者开 Network 的禁用缓存 |
| 两个块之间的间距比预期大 | 垂直 margin 合并，取了较大值 | 看 Computed 盒模型图 |
| 子元素的 margin-top 把父元素推下去了 | 父子 margin 穿透 | 给父元素加display: flow-root |
| 浮动之后父元素高度是 0 | 父元素没形成 BFC | 父元素加overflow: hidden或flow-root |
| 图片底部多出几像素空白 | img是行内元素，基线对齐留了空隙 | 给img加display: block |
| 两栏布局加起来 100% 却换行 | content-box下 padding 和 border 额外占宽 | 统一设box-sizing: border-box |
| 单行省略不生效 | 缺white-space: nowrap或min-width: 0 | 补齐三件套，flex 里加min-width: 0 |
| 移动端 hover 状态卡住 | 触屏设备没有真正的悬停 | 用@media (hover: hover)包裹 |
这张表里最想强调的还是第一条和第九条。编码问题一旦发生，很容易让人以为是自己代码写错了，实际跟 CSS 一点关系都没有；而省略号三件套缺一不可这件事，几乎每个刚学 CSS 的人都只写一条然后困惑半天。
如果你手头正在做课程设计或者期末大作业，我的建议是先把 HTML 骨架和 CSS 重置这两块固定成一个模板，之后每个页面都从它开始，不要在骨架层面反复折腾。真正花时间的是布局和细节，把基础写对，后面省下来的时间比什么都值。
我自己现在写新页面，第一步还是老老实实敲那条 DOCTYPE，写lang="zh-CN"，把charset和viewport放好，然后把box-sizing和一套精简重置贴上。这套动作已经变成肌肉记忆，用得越久越觉得，前端基础里没有哪一行是废话，只是它在出问题之前一直很安静。至于那些看起来高级的动效和控件，拆开来也还是盒模型、选择器、伪元素这几样东西的组合——把这些嚼透了，看到任何页面都不会心虚。