企业官网建设流程全解析

简介：这份PDF资料面向前端初学者与有一定经验的开发者，围绕面试高频考点做系统梳理，帮助读者补齐网络协议、性能优化与布局基础等知识短板。内容涵盖HTTP与HTTPS的差异及加密握手流程、TCP三次握手与四次挥手、粘包与缓存机制、页面加载全过程，以及DOM操作、CSS盒模型、BFC与Flex、Rem、百分比、浮动等布局方案，并延伸至跨域原理与常见解决方案。压缩包内仅1个PDF文件，体积约1020KB，篇幅紧凑、便于随查随用。目前已有686人学习下载，适合面试前集中复习或团队内部分享。读者可借此建立从网络通信到页面渲染的完整知识链条，理解各项技术的底层原因，在答题与实战中都能说得清、用得上。

1. 从「HTTPS 为什么安全」看这场面试的给分逻辑

面试官问「HTTPS 为什么安全」，很多人一句「因为加密了」就没了下文，追问「加密在哪一层、握手走了几步、为什么首屏会变慢」立刻卡壳。前端面试的八股文考的不是名词，是把一条链路讲圆的能力：HTTP 到 HTTPS 差一个 SSL 层，SSL 握手决定首屏时间，TCP 三次握手决定请求何时真正发出，响应回来后 DOM 与 CSS 还要走解析、布局、绘制。这份前端面试知识点汇总按协议、浏览器、运行时边界、页面结构四层拆，每层先给考点分布，再给高频问法和答题顺序，适合临考两周拿来对着练的人。只背定义能拿一半分，把链条讲顺才拿全。

2. 网络协议：HTTP/HTTPS 与 TCP 的必答链条

2.1 HTTP 与 HTTPS：六步握手和三个「慢」的理由

HTTP 是客户端和服务器之间请求与应答的标准，底层跑在 TCP 上，负责把超文本从服务器搬到本地浏览器，连接简单、无状态。HTTPS 则以安全为目标，在 HTTP 和 TCP 之间插了一层 SSL，让数据在离开浏览器之前先加密。这一层插入带来了三个直接后果：默认端口从 80 变成 443；传输内容从明文变成密文，中途被窃取、篡改的成本大幅上升；连接建立多了一次握手，页面加载时间可能延长 50%，耗电增加 10%~20%。最后这条数字很多人答不出来，但它是区分「背过」和「理解」的分水岭。

代价还不止这些。HTTPS 的缓存效率不如 HTTP，会增加数据开销；需要 CA 证书，功能越强的证书费用越高；SSL 证书要绑定域名，同一个 IP 上不能绑多个域名，IPv4 地址资源撑不住这种消耗。面试里被问「HTTPS 有什么缺点」，把这四条按「性能、缓存、成本、部署」的顺序说出来，比笼统讲「慢一点」要得分得多。

工作原理是六步，答题时按顺序讲，一步都别跳：

1. 客户端用 https 的 URL 访问服务器，要求 Web 服务器建立 SSL 链接；
2. 服务器收到请求后，把网站证书（证书里含公钥）发给客户端；
3. 双方协商 SSL 链接的安全等级，也就是加密等级；
4. 客户端按协商结果生成会话密钥，用服务器公钥加密这个会话密钥，再传给服务器；
5. 服务器用自己的私钥解密，拿到会话密钥；
6. 之后双方通信用会话密钥做对称加密。

提示：第 4、5 步是面试官最爱追问的地方，一定要补一句「非对称加密只用来传会话密钥，真正的业务数据走对称加密」。原因是非对称加密开销大，全程用会慢到没法用；而会话密钥是随机的、一次性的，即使被截获也只影响这一次会话。

可以准备一个 40 秒的答题模板：一句话定义，三个核心差异（加密层、端口、握手成本），两个代价（性能与证书成本），一个结论（对安全有要求的站点必须上，纯静态展示页可以权衡）。这套结构答完，面试官基本不会再在这个点上纠缠，而是转向 TCP。

2.2 三次握手与四次挥手：状态名是送分点

三次握手的过程要能画出时序，也要能报出状态名。第一次，客户端发送 SYN 包（syn=j），进入 SYN_SENT 状态，等待服务器确认；第二次，服务器收到 SYN 包并确认对方的 ack=j+1，同时发出自己的 SYN 包（syn=k），也就是 SYN+ACK 包，进入 SYN_RECV 状态；第三次，客户端收到 SYN+ACK 后发送确认包 ACK（ack=k+1），发送完毕双方进入 ESTABLISHED 状态，连接建立。握手过程中传送的包里不带业务数据，三次握手完成后才开始传数据。

为什么不是两次？这是高频追问。两次握手的话，一个在网络里滞留很久的旧 SYN 包突然到达服务器，服务器会直接认为连接建立并分配资源等待数据，而客户端根本不认这条连接，资源就白白占着。三次握手的第三次确认，本质上是让服务器确认「客户端确实收到了我的 SYN，并且此刻还想连」，把历史连接的残包挡在门外。

四次挥手同样按状态讲。客户端发 FIN 报文（FIN=1，seq=u），进入 FIN-WAIT-1；服务器回 ACK（ack=u+1，seq=v），进入 CLOSE-WAIT，此时是半关闭状态——客户端不再发数据，但仍能接收；客户端收到确认后进入 FIN-WAIT-2，等待服务器把剩余数据发完；服务器发完数据后发 FIN 报文（FIN=1，ack=u+1，seq=w），进入 LAST-ACK；客户端回 ACK（ack=w+1，seq=u+1），进入 TIME-WAIT，等 2MSL 后才进入 CLOSED；服务器收到这个 ACK 立刻进入 CLOSED。所以服务器的连接通常比客户端先结束。

TIME-WAIT 为什么要等 2MSL，两个理由必须都答：一是保证最后那个 ACK 能到达服务器，如果 ACK 丢了，服务器会重发 FIN，客户端还有机会再确认一次；二是让本次连接产生的所有报文在网络中消散，避免下一个用相同四元组建立的连接收到旧数据。

注意：不要说「客户端先关所以客户端更忙」。四次挥手里主动关闭的一方可能是客户端也可能是服务器，谁先调 close 谁就是主动方，状态名要跟着主动方走，别把方向说死。

2.3 可靠传输与粘包：TCP 和 UDP 的对比题

「TCP 怎么保证数据包有序可靠」是一道标准的五步题。第一，对字节流分段并编号；第二，发送方把已发出的数据包留在缓冲区；第三，为每个包启动超时定时器；第四，超时前收到应答（可以是本包的应答，也可以是对后续包的累计应答）就释放缓冲区，否则重传，直到收到应答或超过最大重传次数；第五，接收方收到包先做 CRC 校验，正确则交给上层，并回一个累计应答包，如果正好有数据要回，应答可以捎带在数据包里一起发。答题时把「编号、缓冲、定时器、重传、校验与累计应答」这五个关键词说全，基本就满分。

粘包是 TCP 独有的问题。TCP 是流式传输，没有消息边界，发送方发的若干包到接收方可能粘成一包，表现为后一包的头紧接着前一包的尾；UDP 有消息边界，不会出现。常见对策有三条，但每条都有短板，这一点恰恰是加分项：给发送方设置强制立即发送的指令，能避免发送方造成的粘包，但关掉了优化算法、降低发送效率，一般不推荐；接收方优化程序设计、精简工作量、提高优先级，只能减少概率，流量突发时仍然来不及收；接收方按结构字段人为分多次接收再合并，能避免粘包但效率低，实时场景不适合。比较周全的做法是接收方起一个预处理线程，把粘连的包拆开再交给业务，实测效率可行。

TCP 与 UDP 的对比可以整理成表，答题时挑三条说，别从头念到尾：

2.4 真题演练：三道网络题的标准答法

第一题：「HTTPS 就一定安全吗？」答题思路是先给结论——HTTPS 解决的是传输链路的机密性和完整性，不解決服务器本身是否可信。再讲机制：证书由 CA 签发，浏览器校验证书链，中间人拿不到域名对应的私钥就伪造不了证书；但如果用户手动信任了来源不明的根证书，或者站点本身就有漏洞，HTTPS 也挡不住。最后补一句实际工作里的做法：生产环境强制 HTTPS、开 HSTS、证书到期做监控告警。面试官想听的是你知道边界在哪，而不是把 HTTPS 吹成万能。

第二题：「服务端主动关闭连接，为什么还会出现大量 TIME-WAIT？」先纠正一个常见误解：TIME-WAIT 出现在主动关闭的一方，谁先发 FIN 谁进入这个状态，跟客户端服务器角色无关。再讲后果：每个 TIME-WAIT 占一个四元组，量大时端口耗尽，新连接建不起来。最后给方案：调整内核参数缩短等待时间、开启连接复用、让客户端主动关闭，但要注意每种方案都有副作用，不能上来就说「调小就行」。

第三题：「一个接口很慢，你怎么定位是网络还是服务端？」答题顺序是分层排除：先看浏览器 Network 面板的 Timing，区分是排队、DNS、TCP 连接、TTFB 还是内容下载；TTFB 长说明服务端处理慢或网络往返多，内容下载长说明包体大或带宽受限；再用命令行工具看连接建立耗时和重传情况。把「浏览器面板 → 命令行 → 抓包」这条排查链说出来，比背概念更像干过活的人。

3. 浏览器链路：从输入 URL 到渲染与 304 缓存

3.1 输入 URL 之后发生了什么：七个阶段按顺序说

第一阶段查缓存。浏览器先看浏览器缓存、系统缓存、路由缓存里有没有这个页面，命中就直接显示；DNS 记录也会被浏览器缓存一段时间，所以第一个解析 DNS 的地方其实是浏览器自己。第二阶段 DNS 解析：浏览器缓存没有就调操作系统，再没有就查路由器缓存，最后向 ISP 的 DNS 服务器发起请求，把域名换成 IP。DNS 主要基于 UDP，因为查询包小、要快。第三阶段建立 TCP 连接，用 IP 加默认端口和服务器握手。第四阶段发起 HTTP 请求，这个请求报文会作为三次握手的第三次数据一起发出去。第五阶段服务器响应，把 HTML 文件返回。第六阶段四次挥手释放连接（现代浏览器多用 keep-alive 复用，不一定立刻关）。第七阶段浏览器渲染。

渲染这一段要背得比网络还熟。解析 HTML 构建 DOM 树，根是 document 对象；解析 CSS 生成 CSS 规则树；两者结合成渲染树；布局阶段计算每个节点在屏幕上的位置；绘制阶段遍历渲染树，用 UI 后端把每个节点画出来。之后 JS 引擎介入：创建 window 全局执行环境，所有全局变量和函数都挂在 window 上，DOM 树也映射到 window.document；然后做语法与词法检查，进入预编译——找全局变量声明挂到 window 并赋 undefined，找全局函数声明挂到 window 并把函数体赋进去，匿名函数因为本质是变量，不参与函数提升；最后解释执行，边执行边赋值。ES6 之前变量提升是常态，ES6 用 let/const 解决了变量提升，但函数提升仍然存在。

被追问「JS 执行上下文和作用域链」时，用一句话收：函数执行时把函数环境压入环境栈，执行完弹出，控制权交还上一层，作用域链就是沿着这条执行流一层层往外找变量。这句话能把抽象的机制讲成可想象的画面。

3.2 强缓存与协商缓存：304 的判定顺序

浏览器每次发请求，先查本地有没有缓存结果和缓存标识；拿到响应后，再按响应头的缓存标识决定是否存。判断用不用缓存分两步：强缓存和协商缓存。

强缓存由 Expires 和 Cache-Control 控制，Cache-Control 优先级更高。Expires 是一个绝对时间，受本地时钟影响，用户把系统时间改了就失效；Cache-Control 的 max-age 是相对秒数，更可靠。强缓存命中时，状态码仍是 200，但浏览器会显示 from cache，不会真的向服务器要数据。

强缓存失效后进入协商缓存，浏览器带着标识去问服务器「这个资源还能用吗」。先看 ETag / If-None-Match：ETag 是资源唯一标识，资源一变 ETag 就变，服务器拿请求里的 If-None-Match 和当前 ETag 比对；再看 Last-Modified / If-Modified-Since：第一次请求时响应头带 Last-Modified 记录最后修改时间，再次请求时请求头带 If-Modified-Since，服务器按最后修改时间判断。ETag 的优先级高于 Last-Modified。命中返回 304，不命中返回 200 和新资源。

答题时把「先强缓存、后协商缓存、304 只是省了响应体但确实发了请求」这三句说清楚，基本不会丢分。很多人错在把 304 说成「没发请求」，这是硬伤。

3.3 重排与重绘：哪些操作贵，怎么少做

重排（回流）是元素的几何信息变化导致浏览器重新计算几何属性、重新布局；重绘是元素外观变了但布局没变，只重画外观。两者代价都高，会让 UI 显得迟缓，而重排更贵，所以无法避免时宁可选择重绘。关系是一句话：重绘不一定重排，重排必然引起重绘。

触发场景要能举例：增删改 DOM 节点、display:none 隐藏节点（重排加重绘）、visibility:hidden 隐藏节点（只重绘，因为没有几何变化）、移动节点或加动画、新增样式表改样式属性、用户改变窗口大小或字号、滚动。

避免手段按性价比排序：集中改样式，用 class 一次性切换而不是逐条改 style；不要把 DOM 属性读取放在循环里当循环变量，因为读 offsetTop 这类属性会强制刷新布局；动画元素用 fixed 或 absolute 脱离文档流，改它们的 CSS 不会触发整页重排；不用 table 布局，一个单元格的小改动可能引发整表重算；动画用 transform 和 3D 位移交给 GPU；用 will-change 把元素提升为合成层，合成层的位图由 GPU 合成比 CPU 快，重绘时只重绘自己不影响别的层，transform 和 opacity 变化不触发 layout 和 paint。

提示：被问「提升合成层有什么代价」，答内存。层多了显存占用上升，低端设备反而更卡，所以 will-change 只加在确实要动的元素上，动画结束考虑移除。

3.4 真题演练：缓存与渲染的三道问法

第一题：「样式改了上线，用户说没生效，怎么排查？」答题思路从缓存链路走：先确认文件名或 URL 有没有带 hash，没带 hash 的静态资源很容易被强缓存按住；再看响应头的 Cache-Control 和 ETag 是否符合预期；然后让用户强刷或看 DevTools 里是 from disk cache 还是 304；最后给工程化方案——静态资源带 contenthash、HTML 不缓存或短缓存、发布时刷新 CDN。答到「HTML 不缓存、资源带 hash」这一层，说明你处理过真实发布。

第二题：「重排和重绘哪个更耗性能，为什么？」结论先给：重排更贵。原因是重排要重新计算几何信息、重建布局树，可能牵连兄弟节点和父节点，重绘只是按现有布局重画像素。再补一个反直觉的点：读某些 DOM 属性也会触发重排，因为浏览器必须立刻计算最新布局才能返回准确值，这叫强制同步布局。

第三题：「script 标签放在 head 里会怎样？」答：会阻塞 DOM 解析和渲染，因为 JS 可能改 DOM，浏览器不敢先渲染。解法是放 body 底部、加 defer（下载不阻塞、按顺序在 DOMContentLoaded 前执行）、加 async（下载完立刻执行、不保证顺序）。CSS 会阻塞渲染但不阻塞解析，所以首屏样式要内联关键 CSS。这类题答的全是因果，不是结论堆砌。

4. 运行时边界：跨域五种解法、三种本地存储与 CSS 布局高频

4.1 同源策略与五种跨域解法

跨域的本质是浏览器的同源策略：协议、域名、端口三者有任何一项不同就是不同域，浏览器不允许页面脚本去读另一个域的响应。注意是「浏览器限制」，服务端之间的调用不受影响，这也是代理方案成立的前提。

JSONP 是最老的方案，利用 script 标签的 src 可以加载跨域脚本这个特性，让服务端不返回 JSON，而是返回一段调用某个函数的 JS 代码，在 src 里把函数名传过去，脚本一执行就完成了数据回传。

// 动态创建 script 标签，用全局函数名作为回调 var script = document.createElement('script'); // 回调函数必须挂在全局，服务端返回的代码会直接调用它 function getData(data) { console.log('拿到跨域数据', data); } // callback 参数名要和后端约定，值就是上面的函数名 script.src = 'http://localhost:3000/?callback=getData'; // 插入文档后请求才真正发出 document.body.appendChild(script);

这段代码的关键在三个参数：callback 是前后端约定的参数名，值是全局函数名；src 指向接口地址，接口必须返回 getData({...}) 这种可执行片段；appendChild 是触发点，不插入文档脚本不会执行。JSONP 的缺点同样要背：只支持 GET，因为 script 标签只能发 GET；需要后端配合返回指定格式；返回内容会被直接当脚本执行，等于把执行权交给对方，来源不可控时有风险。

其余四种方案按优先级说。document.domain 要求基础域名相同、子域名不同，把两边的 domain 都设成基础域名即可，现在用得少。window.name 利用同一个浏览器窗口内所有域名共享 window.name 的特性，在 iframe 之间传值，容量大但写法绕。CORS 是现在的主流：服务端设置 Access-Control-Allow-Origin 等响应头，浏览器看到头就放行，支持各种请求方法，复杂请求会先发 OPTIONS 预检。代理是最省心的工程方案：开发环境用 devServer 的 proxy，线上用反向代理转发，浏览器眼里始终是同源请求。window.postMessage 是 H5 新特性，用于页面与 iframe、窗口之间的消息传递，要校验 origin，不能收到消息就执行。

面试时给一个选择顺序：能改服务端就 CORS，不能改就代理，老系统兼容才考虑 JSONP，iframe 场景用 postMessage。

4.2 三种本地存储：4K 与 5M 的边界

Cookie、sessionStorage、localStorage 的共同点是都存储在客户端，区别在容量、生命周期和是否自动随请求发送。

答题时补两个实用点：localStorage 只能存字符串，存对象要先 JSON.stringify，取出来再 parse；cookie 每次请求都带，静态资源域名下不要放业务 cookie，否则白白增加请求头体积。这两个细节说出来，比单纯背容量数字更能体现工程感。

4.3 选择器权重、盒模型与 BFC

选择器优先级用四位数记忆更直观：

带 !important 的属性优先级最高；来源相同时，顺序是 !important > 行内样式 > ID > 类 > 标签 > 通配 > 继承 > 浏览器默认。被问「怎么让一个样式一定生效」，不要第一反应就是 !important，先说提高选择器权重或调整加载顺序，!important 只当最后手段。

盒模型分标准盒模型和 IE 盒模型。标准盒模型里 width 只算 content 的宽度，总宽度 = width + 左右 margin + 左右 padding + 左右 border；IE 盒模型里 width 已经包含 content、padding 和 border，总宽度 = width + 左右 margin。box-sizing 用来切换：content-box 是标准盒模型，border-box 是 IE 盒模型，inherit 继承父元素。工程里常用 border-box，因为设了宽度就不用再算 padding 和 border，布局不易翻车。

BFC 是块级格式化上下文，是一个独立的渲染区域，内部盒子怎么排有固定规则，且不影响外部。四条规则要背：内部盒子垂直方向一个接一个放置；同一个 BFC 里相邻盒子的 margin 会发生重叠；每个元素的 margin box 左边紧贴包含块的 border box 左边；BFC 区域不会与 float box 重叠；计算高度时浮动元素也参与。

创建方式记五个：根元素 html 本身；float 不为 none；position 为 absolute 或 fixed；display 为 inline-block、table-cell、table-caption；overflow 不为 visible。使用场景记四个：去除边距重叠、清除浮动让父元素包住浮动子元素、避免元素被浮动元素覆盖、避免多列布局因宽度四舍五入换行。

4.4 position、居中、隐藏与 CSS 三角

position 的几个值容易混，用表格对照最稳：

sticky 的细节常被追问：它先按普通文档流定位，越过特定阈值后表现得像 fixed，所以必须给 top/bottom 之类的阈值才生效，父容器 overflow:hidden 会让它失效。

居中方案按「元素宽高是否已知」分。水平居中：行内元素用 text-align:center；定宽块级用 margin:0 auto；宽度未知可以用 display:table 加 margin auto，或 inline-block 加 text-align，或绝对定位加 transform 位移自身 50%，或 flex 的 justify-content:center。垂直居中：纯文字用 line-height 等于高度；父相子绝加 margin 自适应；flex 里给子元素 margin:auto；父相子绝加 transform 位移；表格布局用 vertical-align:middle，前提是内联元素或 display 为 table-cell 的元素。

隐藏元素的三种方式差异是经典对比题。opacity:0 元素还在，布局不变，绑定的事件仍能触发；visibility:hidden 元素不可见，布局空间保留，但不触发绑定事件，只引发重绘；display:none 元素不渲染，空间不保留，引发重排加重绘。答的时候一定要把「事件是否可触发」和「是否引发重排」两个维度带出来。

CSS 画三角形靠的是边框交汇原理：

/* 宽高为 0，四边边框在中心交汇，只留一条边有色就是三角形 */ .triangle { position: absolute; width: 0; height: 0; border-top: 100px solid #ff0; border-right: 100px solid transparent; border-bottom: 100px solid transparent; border-left: 100px solid transparent; }

width 和 height 都设为 0 之后，四条边框会从中心向四周挤成四个梯形，把其中三条设成 transparent，剩下那条有颜色的边就呈现为三角形。border 的宽度决定三角形大小，哪条边有色决定三角形朝向，比如只给 border-bottom 颜色，得到的就是尖朝上的三角形。记忆口诀是「盒子宽高均为零，三面边框皆透明」。

4.5 真题演练：跨域、存储与布局三道

第一题：「CORS 下 POST 请求为什么先发一个 OPTIONS？」答题思路：先说是预检请求，浏览器在发非简单请求前先问服务器允不允许，避免请求已经发出去才发现被拒；再说触发条件——方法不是 GET/HEAD/POST，或 Content-Type 不是表单那三种，或带了自定义头；最后说服务端要正确响应 OPTIONS 并带上允许的方法和头，否则预检失败，业务请求根本发不出去。能说出「预检失败时控制台报的是 CORS 错误但根因在服务端配置」，说明真踩过。

第二题：「localStorage 直接存对象会怎样？」答：会变成 [object Object]，因为存储接口只接受字符串，读取时拿到的是这个字符串而不是对象。正确做法是存之前 JSON.stringify，取之后 JSON.parse，并处理解析异常，因为历史数据可能是坏的。再补一句容量和同步阻塞：5M 左右、读写是同步的，不要在主线程频繁读写大对象珠海。

第三题：「两个相邻 div 的 margin 为什么重叠，怎么解决？」先解释规则：同一个 BFC 内相邻块级盒子的垂直 margin 会合并，取较大值，这是 BFC 规则决定的，不是 bug。解法是让它们不在同一个 BFC 里，比如给其中一个套一个 overflow:hidden 的父元素，或者用 padding、border 隔开，或者改用 flex 布局（flex 子项不产生 margin 合并）。答到「换布局模型也能规避」这一层，比只说 overflow:hidden 更完整。

5. 易错点：五个让面试官皱眉的答法

5.1 错在把 HTTPS 说成「绝对安全」

错在哪：只答「加密了所以安全」，把传输安全和站点可信混为一谈。为什么错：HTTPS 保证的是链路机密性和完整性，证书校验的是域名归属，不保证服务器没有漏洞、不保证内容本身可信；用户手动信任异常根证书时，中间人照样能解密。怎么答对：先给边界，再讲机制（证书链校验、非对称换密钥、对称传数据），最后落到工程动作——强制 HTTPS、证书到期监控、敏感接口再做一层业务校验。面试官要的是你知道它能挡什么、不能挡什么。

5.2 错在把四次挥手说成「固定由客户端先关」

错在哪：把「客户端主动关闭」当成默认事实，状态名顺着背反了。为什么错：四次挥手的主动方取决于谁先调用关闭，服务器也可能主动关；TIME-WAIT 出现在主动关闭的一方，方向说反，后面 2MSL 的解释全跟着错。怎么答对：开头先声明「谁先发 FIN 谁就是主动关闭方」，再按 FIN-WAIT-1、CLOSE-WAIT、FIN-WAIT-2、LAST-ACK、TIME-WAIT 的顺序讲，最后补 TIME-WAIT 的两个作用。方向对了，状态名才不会乱。

5.3 错在把 304 说成「没有发请求」

错在哪：说「命中缓存就不请求服务器了」，把强缓存和协商缓存混成一句。为什么错：强缓存命中才是 200 from cache、不发请求；协商缓存一定发了请求，只是服务器判断资源没变，返回 304 且不带响应体。怎么答对：先分两层，强缓存看 Cache-Control 和 Expires，协商缓存看 ETag 和 Last-Modified；再说 304 省的是响应体带宽，不是请求本身；最后补优先级，Cache-Control 高于 Expires，ETag 高于 Last-Modified。这三句一说，层次立刻清楚。

5.4 错在把 display:none 和 visibility:hidden 当成一回事

错在哪：只说「都看不见」，不区分布局空间和事件。为什么错：display:none 不渲染、不占空间、引发重排加重绘、绑定事件不触发；visibility:hidden 保留空间、只重绘、事件也不触发；opacity:0 保留空间、不重排不重绘、事件还能触发。三者差异正好对应三个考点，混着答等于三个都没答。怎么答对：用「占不占空间、引不引发重排、事件能不能触发」三个维度列表对比，再各给一个使用场景，比如 loading 遮罩用 opacity、权限隐藏用 display、占位隐藏用 visibility。

5.5 错在跨域只会说 JSONP

错在哪：一被问跨域就背 JSONP 步骤，别的一概不提。为什么错：JSONP 只支持 GET、要后端配合、有脚本注入风险，早不是主流；面试官问跨域，实际想听的是你对同源策略和工程方案的理解。怎么答对：先一句话点出同源策略（协议、域名、端口任一不同），再按场景给方案——能改服务端用 CORS，开发用 proxy、线上用反向代理，老系统兼容才用 JSONP，iframe 通信用 postMessage，最后补 CORS 的预检请求。给出选择依据，比列出五个名词更像有经验。

6. 答题技巧：把八股文答成项目经验的三步法

八股题丢分，多数不是不会，是答得太散。我用一套三步法应对：一句话结论、两层机制、一个自己踩过的坑。

第一步，先给结论，别铺垫。问「重排重绘哪个贵」，第一句就是「重排更贵，因为它要重算几何信息重建布局」，面试官立刻知道你抓到点了。第二步，讲两层机制，一层是原理，一层是边界。原理讲「为什么会这样」，边界讲「什么情况下不成立」，比如讲 HTTPS 就补「它不保证服务器本身可信」，讲缓存就补「304 仍然发了请求」。第三步，落到一个具体场景，最好是排查经历，哪怕是模拟项目里的问题，也要说清现象、判断、动作、结果四要素。

不同题型可以套不同开场，下面这张表是我自己练的时候用的，照着念几遍就能形成条件反射：

还有一个练习方法：把每道题限时 90 秒，用手机录音，回放时只检查三件事——有没有结论、有没有机制、有没有场景。三样缺一样就重录。练二十道之后，你会发现自己的答案长度自动收敛，废话被挤掉了。

从那以后我每次进面试间，答任何一道八股题都强制走一遍「结论、机制、踩坑」这三步，哪怕题目再小也不省。这个习惯让我在真实项目复盘时也更清楚该讲什么。希望帮到你。

本文还有配套的精品资源，点击获取