外观
网络、性能与安全
1. 响应式开发中，如何避免窗口大小监听导致的重排抖动？
答案：
不要在 resize 回调里直接读写布局或频繁 setState。可用 requestAnimationFrame 合并同一帧更新，并对事件做节流；先读取尺寸，再统一写入样式，避免读写交错触发强制同步布局。若只关心容器尺寸，优先使用 ResizeObserver；回调中仍应批量更新，组件卸载时取消监听。
2. 说说流式输出的原理及其应用场景
答案：
流式输出把完整响应拆成连续数据块，由服务端边生成边发送，客户端通过 ReadableStream、SSE 或 WebSocket 逐块读取、解码并渲染。它降低首字节后的等待感，适合大模型回答、日志、长列表和文件传输。实现时要处理分片边界、UTF-8 解码、顺序、背压、超时、断线和结束标记。
3. canvas 有什么优化渲染性能的方案
答案：
减少绘制量是核心：按脏区域重绘，避免每帧整画布清空；静态内容预渲染到离屏 canvas 或位图，动态层单独绘制；合并绘制路径，减少 fill、stroke 和状态切换，并用 requestAnimationFrame 驱动。大场景可分块、视口裁剪、降低分辨率或使用 WebGL；同时控制对象数量，避免频繁创建临时对象和同步读取像素。
4. 如果发现JWT Token泄露，如何快速响应？
答案：
先按安全事件处理：若只是某个 JWT 泄露，应立即撤销对应会话和 refresh token，通过黑名单、tokenVersion 或账户状态让访问令牌失效，必要时强制该用户重新登录；只有签名密钥也泄露时，才需要轮换密钥并使所有受影响令牌失效。随后保留审计日志、确认影响范围，排查日志、URL、前端存储及第三方渠道并修复泄露源。后续使用短期访问令牌、可撤销的刷新令牌和 HttpOnly、Secure、SameSite Cookie，避免把令牌写入日志或 query。
5. 在前端开发中，你了解哪些与安全性相关的内容？（提示：除了 HTTP 和 HTTPS）
答案：
重点包括 XSS 防护、CSRF 防护、点击劫持防护、CSP、输入校验与输出编码、Cookie 的 HttpOnly、Secure、SameSite 属性，以及依赖和供应链安全。还要防止开放重定向、敏感信息泄露、原型污染和不安全的 postMessage；严格校验 origin，使用 HTTPS、权限最小化、SRI 和安全响应头。安全措施应由服务端最终兜底，不能只依赖前端校验。
6. 在 DOM 结构比较复杂的情况下，为什么操作虚拟 DOM 的性能比操作真实 DOM 好？
答案：
虚拟 DOM 并非单次操作一定更快，优势在于把多次状态变化合并，在内存中比较新旧树，只把必要的最小变更提交给真实 DOM，减少昂贵的布局、绘制和跨引擎调用。复杂页面中批量更新尤其有效。但 diff 本身也有成本；若更新很少、节点很少或选择器操作已很精准，直接操作 DOM 可能更快，关键要看实际测量。
7. 如何取消重复请求？
答案：
先定义请求唯一键，例如方法、规范化 URL、参数和用户上下文的组合，用 Map 保存进行中的 Promise；相同键直接复用已有 Promise，请求完成后删除。若需求是取消旧请求，可用 AbortController，在发起新请求前 abort 旧请求，并在 catch 中区分取消与真正失败。搜索联想还应配合防抖、序列号校验和缓存，防止旧响应覆盖新结果。
8. 如何实现WebSocket的断线重连机制？
答案：
连接关闭或心跳超时后，先清理旧连接、定时器和事件监听，再按指数退避加随机抖动重试，例如 1、2、4、8 秒并设置上限。重连成功后恢复鉴权、订阅和未确认消息；发送队列要限制大小，避免重复发送。服务端主动关闭、网络切换、页面隐藏和用户登出应区别处理，连续失败达到阈值时停止并提示用户。
9. 如何避免JavaScript代码对浏览器渲染的阻塞？
答案：
将非关键脚本标记为 defer 或动态按需加载，第三方脚本使用 async 并控制数量；拆分代码，懒加载路由和组件，利用 tree-shaking、压缩和缓存。把长任务拆成小块，在 requestIdleCallback 或 setTimeout 中让出主线程，避免同步循环和频繁布局读写。事件采用委托，计算密集任务可放入 Web Worker；关键 CSS 和首屏脚本应优先，持续用 Performance 面板验证。
10. 在 html 页面渲染过程中，哪些因素可能会影响页面的渲染性能？如何优化？
答案：
影响因素包括 HTML 解析与 DOM 规模、CSS 选择器和样式计算、脚本阻塞、同步布局、图片字体等资源加载、布局抖动及绘制合成。优化上应减少节点和 CSS 复杂度，关键脚本 defer，CSS 和字体按需加载，图片压缩并懒加载，固定媒体尺寸避免 CLS；批量读写 DOM，使用虚拟列表和合成层，并通过瀑布图、LCP、INP 等指标定位瓶颈。
11. 使用第三方库可能带来哪些安全风险？
答案：
风险包括恶意或被篡改的依赖、维护者账号被攻破、传递依赖漏洞、安装脚本执行任意代码、许可证不合规，以及体积过大导致性能问题。应锁定 lockfile 和版本，优先可信维护者，定期使用审计工具和 Dependabot 扫描，审查变更与发布包，启用 SRI、CSP 和最小权限。对不再维护或功能过大的库及时替换，并对高风险 API 做封装隔离。
12. 如何优化音频和视频的加载性能？
答案：
先按设备、网络和内容选择合适格式与码率，使用 MP4/WebM、现代音频编码和响应式 source；设置 poster、尺寸和预加载策略，首屏通常 metadata 或 none，非首屏懒加载。视频可分片并用 HLS/DASH 自适应码率，音频按需加载，静态资源走 CDN 和缓存。避免自动播放大媒体，合理使用 preload，必要时用 MediaSource、Range 请求和服务端转码。
13. CORS 是如何实现跨域的？
答案：
CORS 由浏览器执行同源策略的例外规则，服务端通过响应头声明允许的来源、方法、请求头和凭据，例如 Access-Control-Allow-Origin。简单请求直接发送并检查响应；非简单请求先发 OPTIONS 预检，服务端允许后浏览器才发送实际请求。带凭据时不能使用通配符来源，服务端还需配合 Access-Control-Allow-Credentials；CORS 不能绕过服务端鉴权。
14. JSONP 是如何实现跨域的?
答案：
JSONP 利用 script 标签不受同源策略限制的特点，把回调函数名作为 query 参数请求跨域接口；服务端返回形如 callback(data) 的 JavaScript，浏览器加载后直接执行回调。它只支持 GET，无法可靠处理错误、取消和复杂请求头，并存在脚本注入风险。现代应用应优先使用 CORS；若必须使用 JSONP，要限制可信域名、严格校验回调名并避免敏感数据。
15. ajax如何获取下载进度?
答案：
用 XMLHttpRequest 的 progress 事件读取 loaded 和 total：当 total 可用时，进度为 loaded / total * 100；设置 xhr.responseType 获取二进制数据，监听 onload、onerror 和 onabort。服务端必须返回准确的 Content-Length，分块传输或压缩场景 total 可能未知，此时只能显示已接收字节或不确定进度。Fetch 也可通过 response.body.getReader() 逐块读取并自行累计。
16. 网络模型分层大概有哪些层级？
答案：
常见 OSI 七层从下到上是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层；实际工程常合并为 TCP/IP 四层：链路层、网际层、传输层、应用层。HTTP、DNS 属于应用层，TCP、UDP 属于传输层，IP 属于网际层，以太网和 Wi-Fi 属于链路层。分层便于职责隔离、协议组合和故障定位，不代表每个协议只对应一层。
17. TCP 传输过程？
答案：
TCP 建连先进行三次握手：客户端发送 SYN，服务端回复 SYN+ACK，客户端再回 ACK，双方协商序号并确认可通信。传输中把字节流分段，依靠序号、确认、校验和、超时重传保证可靠有序，并通过滑动窗口、流量控制和拥塞控制调节发送速率。关闭通常是四次挥手，双方分别发送 FIN 和 ACK；RST 用于异常复位。
18. HTTP建立连接的过程?
答案：
浏览器先解析 URL，查询 DNS 得到 IP；随后与服务器建立 TCP 连接，HTTPS 还要进行 TLS 握手并验证证书、协商密钥。HTTP/1.1 通常通过 Host 和 Keep-Alive 复用连接，HTTP/2 或 HTTP/3 会协商对应协议。连接建立后发送请求并接收响应，浏览器依据状态码、缓存头和内容类型处理资源，最后由连接复用、超时或关闭策略决定是否释放连接。
19. 请简述 HTTP 请求的过程
答案：
客户端构造请求行、请求头和可选请求体，通过 DNS、TCP 或 QUIC 到达服务器；HTTPS 场景还包含 TLS 握手。服务器解析路由、鉴权和参数，执行业务逻辑后返回状态码、响应头和响应体。浏览器校验缓存策略、解压和解析内容，并可能继续请求依赖资源。连接可通过 Keep-Alive、HTTP/2 多路复用或 HTTP/3 复用，失败时按超时、重试和幂等性处理。
20. 以用户为中心的前端性能指标有哪些？
答案：
常看 Core Web Vitals：LCP 衡量最大内容何时呈现，目标通常不超过 2.5 秒；INP 衡量交互响应延迟，良好值不超过 200 毫秒；CLS 衡量视觉稳定性，良好值不超过 0.1。还可关注 FCP、TTFB、TBT、首屏可用时间和资源错误率。应结合真实用户数据与实验室数据，按 p75、设备和网络分组分析，而不是只看单次平均值。
21. 一个 tcp 连接能发几个 http 请求？
答案：
没有固定上限。HTTP/1.1 的持久 TCP 连接可以连续承载多个请求，通常请求响应依次处理；若使用管线化会受队头阻塞影响，浏览器也可能建立多个连接。HTTP/2 在同一 TCP 连接上用多个独立流并行承载请求，HTTP/3 则在一个 QUIC 连接上复用多个流。因此实际数量受协议、服务器配置、窗口、连接生命周期和应用请求量限制。
22. HTTPS 中的 SSL/TLS 是什么？
答案：
SSL/TLS 是运行在传输层之上的安全协议，HTTPS 就是 HTTP 通过 TLS 传输。它提供机密性、完整性和身份认证：握手阶段验证服务器证书，协商协议版本和密码套件，并通过密钥交换建立会话密钥；之后用对称加密保护应用数据，用认证标签或 MAC 检测篡改。实际应使用 TLS 1.2 或更高版本，禁用过时协议和弱算法。
23. HTTPS 加密算法和加解密过程是啥？
答案：
HTTPS 采用非对称密码完成身份认证和密钥协商，采用对称密码加密大量业务数据，并用哈希或 AEAD 标签保证完整性。客户端先验证证书链、域名和有效期，再通过 ECDHE 等方式协商共享密钥；服务端用证书私钥证明身份，双方派生会话密钥。握手完成后，请求和响应通常用 AES-GCM 或 ChaCha20-Poly1305 对称加密，私钥不直接加密全部正文。
24. 浏览器缓存中 Memory Cache 和 Disk Cache，有什么区别？
答案：
Memory Cache 位于内存中，读取快，适合当前页面或近期使用的脚本、样式和图片，但容量有限，页面关闭或内存压力下容易失效。Disk Cache 位于磁盘，跨页面和重启更持久，容量较大，但读写更慢。二者由浏览器自动依据资源类型、大小、缓存头和当前内存状态选择，不能简单认为所有资源都固定走其中一种；最终仍需按 Cache-Control、ETag 等规则校验。
25. Service Worker 是如何缓存 http 请求资源的？
答案：
页面注册并激活 Service Worker 后，浏览器把匹配请求交给其 fetch 事件。代码可用 Cache Storage 按请求键保存 Response，在安装阶段预缓存静态资源，在 fetch 阶段采用 cache-first、network-first 或 stale-while-revalidate 策略，再通过 caches.open、match、put 管理缓存。更新由新 worker 安装、等待并接管；要注意版本清理、请求不可缓存、跨域响应、离线回退和缓存一致性。
26. 前端如何防止加载外域脚本？
答案：
使用 CSP 的 script-src 白名单限制脚本来源，生产环境优先 nonce 或 hash，配合 strict-dynamic；同时配置 SRI 校验 CDN 脚本内容，并避免内联脚本、动态拼接 script src 和不可信第三方。通过构建工具锁定依赖、审查供应链，必要时用沙箱 iframe 隔离不可信内容。防护应在响应头由服务端下发，不能仅依赖前端代码判断来源。
27. 介绍下如何实现 token 加密？
答案：
要先区分加密与签名。JWT 常用 JWS 签名保证完整性和来源，内容通常只是 Base64URL 编码，不具备保密性；若必须隐藏内容，应使用 JWE 或在服务端保存敏感数据。更稳妥的设计是短期 access token、可轮换的 refresh token、服务端撤销和最小权限，并通过 HTTPS 传输。浏览器侧优先 HttpOnly、Secure、SameSite Cookie，避免把 token 放在 URL 或日志中。
28. HTTP协议的不同版本的主要特点有哪些？
答案：
HTTP/1.0 默认短连接，功能较基础；HTTP/1.1 默认持久连接，增加 Host、分块传输、缓存控制和管线化，但文本协议与队头阻塞仍限制性能。HTTP/2 使用二进制分帧、同一连接多路复用、头部压缩和流优先级，减少连接开销，但 TCP 丢包会影响所有流。HTTP/3 基于 QUIC/UDP，具备独立流、快速握手和连接迁移，并用 TLS 1.3 提供安全。
29. http1.1 的持久连接和 http2 的多路复用有什么区别？
答案：
HTTP/1.1 持久连接只是复用同一条 TCP 连接，通常一个请求响应完成后再处理下一个；并行需求往往依赖多个 TCP 连接，且可能有应用层队头阻塞。HTTP/2 把连接划分为多个带独立编号的流，用二进制帧交错传输多个请求和响应，并支持头部压缩，因此减少连接数量和握手开销。HTTP/2 仍受单条 TCP 丢包导致整体阻塞的影响。
30. http3 中的 QUIC 是什么协议？
答案：
QUIC 是基于 UDP 的可靠传输协议，也是 HTTP/3 的底层传输。它在用户态实现连接建立、可靠有序的字节流、拥塞控制和多路复用，并把多个流相互隔离，单个流丢包不会阻塞其他流。QUIC 集成 TLS 1.3，支持 0-RTT（需防重放风险）和连接迁移，可在网络切换时保留连接。UDP 只提供承载，可靠性和安全性由 QUIC 实现。
31. HTTP/3 是基于 UDP 的协议， 那么他是如何保障安全性的？
答案：
HTTP/3 虽使用 UDP，但并未把安全交给 UDP；QUIC 强制集成 TLS 1.3。握手阶段完成服务器身份认证、密钥协商和参数协商，之后每个 QUIC 包都经过加密与完整性校验，攻击者不能读取或篡改 HTTP 内容。QUIC 还对包头部分字段做保护，并通过连接 ID 支持迁移。0-RTT 可减少延迟，但可能被重放，因此只适合幂等请求并需服务端防护。
32. https 的证书验证过程是什么样的
答案：
客户端收到服务器证书链后，先检查证书是否在信任根下、签名是否有效、当前时间是否在有效期内，以及目标域名是否匹配 SAN；还会依据密钥用途、撤销状态和安全策略检查。验证通过后客户端生成或协商密钥，并用证书公钥验证握手签名，证明对端持有私钥。失败时浏览器阻止或警告连接。证书验证只证明身份与握手安全，不代表业务接口本身可信。
33. 说说你对 Server-sent events(SSE，服务端推送) 的了解
答案：
SSE 是基于 HTTP 的服务端到客户端单向推送机制：客户端用 EventSource 发起长连接，服务端以 text/event-stream 持续发送 data、event、id 等字段。浏览器会自动重连并可用 Last-Event-ID 续传。它实现简单、天然适合通知和流式文本；若需要双向通信、二进制或更强控制，应选 WebSocket。
34. cookie 构成部分有哪些
答案：
Cookie 由名称和值组成，并可带属性：Expires/Max-Age 控制过期，Domain 和 Path 限定作用域，Secure 要求 HTTPS，HttpOnly 禁止 JavaScript 读取，SameSite 控制跨站发送（Strict、Lax、None）。实际使用还要考虑大小限制、作用域覆盖和敏感信息不要直接明文存储。
35. canvas 性能为何会比 html/css 好？
答案：
canvas 并非必然比 HTML/CSS 快。它把大量图形合并到一个位图表面，避免为每个图形维护 DOM、样式匹配和布局，适合高频绘制、粒子和大数据可视化。代价是重绘区域通常由应用自行管理，文本、可访问性和局部更新较弱；少量结构化内容用 DOM 反而更合适。
36. dom 渲染能使用 GPU 加速吗？
答案：
可以，但不是把所有 DOM 自动交给 GPU。浏览器会将 transform、opacity 等合成友好的图层交给合成线程或 GPU，减少主线程重排；will-change 可提示但不能滥用，否则会增加显存和合成开销。布局、样式计算及大多数绘制仍可能在 CPU 完成，需用性能面板验证。
37. CSR、SSR、SSG、NSR、ESR、ISR 都是什么？
答案：
CSR 在浏览器渲染页面；SSR 在服务器生成每次请求的 HTML，随后 hydration；SSG 在构建时生成静态 HTML；NSR 通常指导航时服务端渲染；ESR 指边缘节点渲染；ISR 是静态页面按需或定时重新生成。它们可组合，选择取决于首屏、SEO、数据实时性和部署成本。
38. script 预加载方式有哪些，这些加载方式有何区别？
答案：
普通 <script> 会下载并执行后阻塞 HTML 解析；defer 并行下载，文档解析完后按顺序执行；async 并行下载，下载完立即执行，顺序不保证，可能打断解析；模块脚本默认 defer。还可用 preload 预加载脚本资源，但它只改变下载时机，不决定执行时机。
39. 如何防止 CSS 阻塞渲染？
答案：
CSS 默认会阻塞首次渲染，因此应压缩并拆分 CSS，内联首屏关键 CSS，非关键样式用 preload 后切换为 stylesheet 或按需加载，并移除未使用规则。通过媒体查询标记非当前设备所需样式可降低阻塞影响。不能简单把主样式异步化，否则会出现无样式闪烁。
40. 如何优化大规模 dom 操作的场景？
答案：
先减少节点和更新次数：列表使用虚拟滚动、分页或增量渲染，批量创建节点后一次性挂载，使用文档片段和事件委托；避免循环中反复读写布局，集中读取后集中写入。复杂计算移到 Web Worker，动画使用 requestAnimationFrame，并通过 Performance 面板定位重排、重绘和长任务。
41. DNS 协议了解多少?
答案：
DNS 把域名解析为 IP，常见记录有 A/AAAA、CNAME、NS、MX、TXT。解析通常先查浏览器、系统和路由器缓存，再递归请求本地 DNS，由根、顶级域和权威服务器逐级查询；响应受 TTL 缓存。DNS 多数基于 UDP 53，响应过大或区域传送等场景可用 TCP，DoH/DoT 可加密传输。
42. TCP/IP 是如何保证数据包传输有序可靠的？
答案：
TCP 通过序列号标识字节位置，接收端按序确认并缓存乱序数据；校验和发现损坏，累计 ACK、超时重传和快速重传处理丢包。滑动窗口控制发送量，接收窗口防止接收端溢出，拥塞窗口配合慢启动、拥塞避免和快速恢复适应网络容量。因此 TCP 在字节流层提供可靠、有序、无重复交付。
43. 说说对数字证书的了解
答案：
数字证书是 CA 对公钥及主体身份信息的签名声明，通常采用 X.509 格式，包含主体、颁发者、公钥、有效期、序列号、用途和 CA 签名。浏览器沿信任链验证根 CA、签名、域名、时间和撤销状态，从而确认连接的公钥属于目标站点。证书本身不加密所有数据，HTTPS 的数据加密由后续会话密钥完成。
44. 如何优化 DOM 树解析过程？
答案：
优化 DOM 树解析要控制文档规模和解析阻塞：减少嵌套、无意义节点及重复样式，服务端输出语义清晰的最小 HTML；将脚本放在合适位置并使用 defer/模块，避免同步脚本打断解析；按路由或组件延迟非首屏内容。还要避免一次性插入超大树，必要时分批生成和渲染。
45. HTTP Header 中有哪些信息？
答案：
HTTP Header 是请求或响应的元数据。请求头常见 Host、Method 相关信息、Accept、Authorization、Cookie、Origin；响应头常见 Content-Type、Content-Length、Cache-Control、ETag、Set-Cookie、Location、CORS 和安全策略头。它们分别描述协商、身份、缓存、内容、跳转及安全约束，具体字段取决于场景。
46. 304 状态码用于什么场景， 好处和坏处分别是什么？
答案：
客户端带 If-None-Match 或 If-Modified-Since 再请求缓存资源，服务器确认未变化时返回 304，浏览器继续使用本地副本，不返回响应体。好处是节省带宽和传输时间；代价是仍需一次请求、连接和服务器校验，网络延迟高时收益有限。资源指纹化配合长缓存可进一步减少验证请求。
47. TCP 粘包（TCP packet sticking）是什么？
答案：
TCP 是无消息边界的可靠字节流。应用连续写入的多条消息可能合并成一次读取（粘包），一条消息也可能被拆成多次读取（拆包）；这不是 TCP 错误。协议层必须自行定义边界，例如固定长度、长度前缀、分隔符或自描述格式，并在接收缓冲区中循环解析，保留不完整数据。
48. 衡量页面性能的指标有哪些？
答案：
常用指标包括导航与网络阶段的 DNS、TCP、TLS、TTFB，加载阶段的 FCP、LCP，交互稳定性的 INP，以及布局稳定性的 CLS；还可关注资源大小、请求数、长任务、JS 执行时间和错误率。指标要结合真实用户分位数（如 P75）与实验室数据，不能只看单次总加载时间。
49. 怎么统计页面的性能指标？
答案：
浏览器端可用 PerformanceNavigationTiming 读取 DNS、连接、请求和 DOM 时间，用 PerformanceObserver 监听 FCP、LCP、INP、CLS、资源和长任务；用 performance.mark/measure 记录业务阶段。生产环境应采集真实用户数据并按设备、网络、页面版本聚合，结合 Lighthouse、DevTools 做实验室诊断，注意采样、跨域 TAO 和指标生命周期。
50. SPA首屏加载速度慢的怎么解决
答案：
SPA 首屏慢应分阶段定位：减小首屏 JS，路由和组件懒加载、Tree Shaking、压缩并拆包；服务端开启 Brotli、HTTP/2 或 HTTP/3，静态资源走 CDN 和长期缓存；关键 CSS/字体/图片优先加载，非关键资源延后；必要时采用 SSR/SSG 或预渲染。最后用 LCP、FCP、长任务和网络瀑布验证，而不是只看包体积。
51. 将静态资源缓存在本地的方式有哪些？
答案：
浏览器缓存可分为 HTTP 缓存（Cache-Control、ETag、Last-Modified）、内存缓存和磁盘缓存；Service Worker 可用 Cache Storage 实现离线和精细缓存；少量配置或数据可放 IndexedDB，简单键值可用 localStorage。静态文件通常采用内容哈希文件名加长 max-age，敏感或易变数据不能仅依赖本地缓存。
52. 为何现在市面上做表格渲染可视化技术的，大多数都是 canvas ， 而很少用 svg 的？
答案：
表格通常有大量单元格、滚动和频繁更新。canvas 只维护一个绘图表面，避免大量 SVG 节点的创建、样式计算和布局，批量绘制吞吐量更高；SVG 的优势是矢量缩放、事件绑定、文本可访问和局部 DOM 更新。数据量小、交互和无障碍要求高时应选 SVG 或 HTML，不能简单认为 canvas 永远更快。
53. HTTP/2 的多路复用（Multiplexing），对比 HTTP/1.1 的长连接优化，它是如何解决队头阻塞的？
答案：
HTTP/1.1 keep-alive 复用同一 TCP 连接，但请求响应通常按顺序处理，前一个响应慢会阻塞后续请求；浏览器只能开多个连接缓解。HTTP/2 将连接拆成带 stream ID 的帧，多路交错传输，单个应用流的等待不会阻塞其他流，并用 HPACK 压缩头部。它仍受 TCP 丢包影响，连接级队头阻塞并未消失。
54. 为什么 http2 能非常快速的过渡到 HTTP3 ？
答案：
HTTP/3 延续 HTTP/2 的语义、方法、状态码和多路复用模型，主要把传输层从 TCP 换成基于 UDP 的 QUIC，因此应用协议和服务器框架更易迁移。QUIC 在用户态实现可靠传输、独立流、TLS 1.3 握手、连接迁移和 0-RTT，减少 TCP 队头阻塞与握手成本；但部署仍需客户端、服务器和网络设备支持。
55. http1.1 的 keep-alive 和 http2 的多路复用有什么区别？
答案：
HTTP/1.1 keep-alive 只复用 TCP 连接，HTTP 请求在连接上通常按序发送和响应，容易发生应用层队头阻塞，并需要多连接并行。HTTP/2 多路复用把请求拆为独立 stream 的二进制帧，在一条连接上交错传输，头部也可压缩；但底层仍是 TCP，丢包会造成整个连接等待。
56. 说说 jwt 中的 token，是怎么进行身份验证的？
答案：
JWT 通常由 Base64URL 编码的 Header、Payload 和签名组成，客户端在登录后携带 Authorization: Bearer <token>。服务端按声明选择算法并用密钥验证签名、检查过期时间、签发者、受众和权限，验证通过才建立本次请求的身份。JWT 是签名防篡改而非加密；应设置短过期时间、妥善存储并设计撤销或刷新机制，不能盲信 Payload。
57. 在域名 A 的网站上，跨域请求域名 B 上的接口，怎么在跨域请求中携带域名 B 的 Cookie 呢？
答案：
前端请求域名 B 时使用 fetch(url, { credentials: 'include' }) 或 XHR 的 withCredentials = true。B 的响应必须返回精确的 Access-Control-Allow-Origin: A 和 Access-Control-Allow-Credentials: true，不能把 Origin 写成 *；Cookie 还要满足 Domain、Path、Secure 及 SameSite=None（跨站时）的条件，并处理预检请求。
58. OAuth2.0 是什么，是怎么实现授权第三方应用登录的？
答案：
OAuth 2.0 是授权框架，让第三方应用在不取得用户密码的情况下获得有限资源访问权。推荐授权码流程并配合 PKCE：客户端把用户导向授权服务器，用户登录并同意后得到一次性 code，客户端用 code 和 verifier 换 access token；资源服务器验证 token 后提供资源。授权服务器、资源服务器和客户端职责分离，必须校验 redirect URI、state、scope，并避免把 token 放进 URL。
59. 如何禁止他人使用控制台调试前端页面代码?
答案：
无法可靠禁止用户打开浏览器控制台；前端代码已下发到用户设备，就能被查看、调试或修改。禁用右键、检测 DevTools、死循环等方式容易误伤用户，也不能形成安全边界。真正的保护应放在服务端：鉴权、权限校验、输入校验、限流和敏感数据最小化，生产构建开启压缩并按需去除 source map，但这只是降低暴露，不是保密措施。
60. HTTP是一个无状态的协议，那么Web应用是怎么保持用户的登录态的呢？
答案：
HTTP 无状态，但应用可用 Cookie 保存会话标识：登录成功后服务端生成随机 session ID 写入 HttpOnly、Secure、合适 SameSite 的 Cookie，后续请求自动携带，服务端在 Session/Redis 中查用户状态。也可使用签名 JWT 让服务端无状态校验。前者便于撤销，后者便于横向扩展；两者都要防 CSRF、XSS、会话固定和窃取。
61. 想要实现页面加载速度提升（性能优化），可以从哪些方向来尝试？
答案：
先用真实用户数据和网络瀑布定位，再从四方面优化：网络上使用 CDN、HTTP/2/3、Brotli、缓存和连接复用；资源上压缩拆包、懒加载、预加载关键资源；渲染上内联关键 CSS、延迟脚本、减少重排和长任务；体验上优化图片字体、SSR/SSG 与骨架屏。以 LCP、INP、CLS、TTFB 和错误率设目标，逐项验证收益。
62. 后端一次性返回树形结构数据，数据量非常大, 前端该如何处理？
答案：
先评估是否真的需要一次性返回：优先分页、按层级懒加载、服务端过滤和字段裁剪。必须接收时可用流式 JSON/分页接口，前端避免递归深拷贝和一次性挂载，采用迭代解析、分批入库、requestIdleCallback 或分帧渲染；树展示使用虚拟列表，只生成可视节点。必要时把解析和转换放入 Web Worker，并限制深度、节点数和异常输入。
63. 如果想在图片这块做性能优化，你有哪些思路？
答案：
按场景做图片优化：选择 AVIF/WebP 等合适格式并压缩质量，按展示尺寸生成响应式资源，使用 srcset/sizes；首屏关键图预加载，非首屏用原生懒加载和占位尺寸，避免 CLS；通过 CDN 做裁剪、格式协商和缓存，使用精灵或图标字体要权衡请求与体积。还要处理解码开销、LCP 图片优先级和超大原图上传限制。
64. JS 的加载是否会阻塞浏览器渲染？
答案：
会，具体取决于脚本类型和位置。经典同步脚本下载、执行时会暂停 HTML 解析，执行期间也无法继续渲染；defer 脚本并行下载，解析结束后按顺序执行，之后再进入后续流程；async 下载完成即执行，可能打断解析；模块脚本默认 defer。脚本执行还可能触发样式计算、布局和长任务，延迟首屏绘制。
65. 请求 Header 中的 Content-Type ，有哪些常见的值?
答案：
常见值包括 text/plain（纯文本）、text/html（HTML）、application/json（JSON）、application/x-www-form-urlencoded（表单键值对）、multipart/form-data（文件及表单混合上传）、application/xml，以及图片、音视频等 image/*、audio/*、video/* 类型。它描述的是请求或响应正文的媒体类型，必要时还可带 charset=utf-8 等参数。
66. 你知道哪些常见的网络协议？
答案：
常见网络协议可按层次理解：应用层有 HTTP/HTTPS、DNS、WebSocket、FTP、SMTP；传输层有 TCP、UDP、QUIC；网际层有 IP、ICMP、ARP（常归入链路相关协议）。其中 HTTP 负责 Web 语义，TCP 提供可靠字节流，UDP 提供无连接数据报，DNS 负责域名解析，HTTPS 则是在 HTTP 上加入 TLS。
67. http 协议中的 CSP 是什么？
答案：
CSP（Content Security Policy）是浏览器执行的内容安全策略，通常通过响应头 Content-Security-Policy 或 meta 设置资源来源白名单，例如 default-src 'self'; script-src 'self'。它能限制脚本、样式、图片、连接、iframe 等加载来源，并可禁止或约束内联脚本，从而降低 XSS、恶意资源注入和数据外带风险；策略应配合 nonce/hash，不能替代输入转义。
68. 说说你对 http 协议中 HSTS 的理解
答案：
HSTS（HTTP Strict Transport Security）由服务端通过 HTTPS 响应头 Strict-Transport-Security 声明，要求浏览器在指定时间内把该站点的 HTTP 请求自动升级为 HTTPS，并阻止用户绕过证书错误继续访问。includeSubDomains 可覆盖子域，preload 可申请加入浏览器预加载列表。首次收到策略前仍可能被降级攻击，因此生产站点应配合预加载并确保所有子域支持 HTTPS。
69. CORS 请求中，什么情况下会触发预检请求？
答案：
跨源请求不是“简单请求”时会先发 OPTIONS 预检。典型情况是方法不是 GET、HEAD、POST，或请求头包含非 CORS safelisted 请求头；POST 的 Content-Type 不是 application/x-www-form-urlencoded、multipart/form-data、text/plain 也会触发。预检会询问目标源、方法和请求头，服务端用 Access-Control-Allow-* 明确许可后，浏览器才发送实际请求；带凭据时还需满足凭据规则。
70. 浏览器对“队头阻塞”有什么优化？
答案：
优化要分层看：HTTP/1.1 中浏览器通过连接复用、并发连接、缓存和资源拆分缓解请求排队，但同一 TCP 连接仍可能队头阻塞；HTTP/2 用单连接多路复用、二进制分帧和优先级减少应用层阻塞，却仍受 TCP 丢包影响；HTTP/3 基于 QUIC，把不同请求放在独立流中，单个流丢包通常不阻塞其他流。实际还应减少请求、压缩资源并合理设置缓存。
71. cookie 可以实现在不同域名下共享吗？
答案：
不能跨任意域名共享 Cookie。Cookie 的 Domain 只能设置为当前主机或其父域，例如 a.example.com 可设置 .example.com，供同一注册域下符合路径的子域携带；不能设置为无关的 b.com，浏览器也会拒绝公共后缀域名。不同顶级域之间应使用后端会话交换、OAuth/SSO 或显式跨源通信，不能靠 Cookie 直接共享。
72. 浏览器有同源策略，但是为什么我们可以将静态资源放到 CDN 上，使用不同的域名访问，这不会有跨域限制吗？
答案：
同源策略主要限制脚本读取跨源响应和操作跨源 DOM，并不禁止页面请求所有跨源资源。img、script、link、字体、媒体等资源通常允许嵌入，因此静态文件可以放在 CDN 域名；但脚本是否能读取响应、字体是否被允许使用，以及 fetch/XHR 是否可访问，仍受 CORS、CSP 和资源自身策略约束。需要跨源读取时，CDN 应返回正确的 Access-Control-Allow-Origin。
73. 在 JS 中， 如何解决递归导致栈溢出问题？
答案：
优先把递归改写为显式栈或队列的迭代算法，避免调用栈随深度增长；树遍历可用数组模拟 DFS/BFS，且要记录访问状态防止循环。若只是少量递归，可拆分任务用 setTimeout 或 queueMicrotask 让出主线程，但这不能解决算法空间复杂度。尾递归优化不能依赖，主流浏览器通常不保证 proper tail calls；同时应检查异常深度和输入环。
74. 有些框架不用虚拟dom，但是他们的性能也不错是为什么？
答案：
虚拟 DOM 不是高性能的必要条件。部分框架在编译期分析模板，把动态节点、依赖关系和更新指令直接生成出来，运行时只追踪发生变化的状态并精确更新真实 DOM；也有框架使用细粒度响应式、静态提升和批量调度。这样省去了通用 diff 的成本。最终性能取决于更新粒度、DOM 操作数量、编译优化、调度和应用写法，而不是是否使用虚拟 DOM。
75. 如果某个页面有几百个函数需要执行，可以怎么优化页面的性能？
答案：
先用 Performance 面板定位耗时函数、长任务和重复工作，再按依赖关系处理：合并或删除无效调用，缓存纯函数结果，降低计算复杂度；非关键任务延后到空闲期，按批次执行并在批次间让出主线程；需要持续计算时放入 Web Worker；渲染相关更新用批量提交或 requestAnimationFrame。同时避免循环触发强制布局，并用指标验证首屏、交互延迟和总耗时是否改善。
76. 如何禁止别人调试自己的前端代码？
答案：
前端代码一旦下发到用户设备，就无法真正禁止调试；禁用右键、拦截 F12、混淆代码或插入 debugger 都能被绕过，还会损害可访问性和排障体验。正确做法是把密钥、权限判断和核心业务规则放在服务端，接口做认证、授权、限流和审计；前端最多用压缩混淆、移除 source map、CSP 等增加逆向成本，不能把它们当作安全边界。
77. Blob，ArrayBuffer，Base64 分别有哪些使用场景？
答案：
Blob 适合表示文件或媒体这类不可变二进制数据，可用于上传、下载、预览和 URL.createObjectURL；ArrayBuffer 适合需要按字节、整数或浮点读取和修改的原始缓冲区，如二进制协议、加密和 Worker 通信；Base64 是把二进制编码成文本，适合 JSON、Data URL 或只支持文本的传输，但体积约增加三分之一，不适合大文件或高频传输。
78. Blob，ArrayBuffer，Base64 有什么区别？
答案：
Blob 是面向文件语义的不可变二进制对象，带有 size、type，可切片和转为流；ArrayBuffer 是固定长度的原始内存，需通过 TypedArray 或 DataView 读写字节；二者都是二进制对象，可相互转换。Base64 不是对象而是编码后的 ASCII 字符串，便于文本传输或嵌入，但会增加约 33% 体积并产生编码解码开销，不能提供二进制随机访问。
79. Http 3.0 是基于 udp 的，那么它是如何保证传输可靠性的?
答案：
HTTP/3 使用的 QUIC 虽基于不可靠的 UDP，但可靠性由 QUIC 在用户态实现：数据按流传输并带递增 Packet Number，接收端发送 ACK，丢失数据通过超时或快速确认检测后重传；每个流和整个连接都有流量控制，并结合拥塞控制调节发送速率。QUIC 还集成 TLS 1.3 提供加密和握手，流之间相互独立，因此一个流丢包不会阻塞其他流。
80. 讲一下png8、png16、png32的区别，并简单讲讲 png 的压缩原理
答案：
“PNG8/16/32”多是工程上的简称，并非三种严格独立的 PNG 标准：PNG8 通常指 8 位调色板，最多 256 个索引色，可另带 1 位透明；PNG16 可能指灰度或每通道 16 位，具体需看颜色类型；PNG32 通常指 RGBA 四通道各 8 位，共 32 位。PNG 先对每行使用预测滤波，再用无损 DEFLATE 压缩，因此解码后像素完全一致，文件大小取决于图像内容和颜色类型。
81. https是如何保证安全的，又是如何保证不被中间人攻击的？
答案：
HTTPS 是 HTTP over TLS：TLS 通过证书链验证服务端域名和公钥，用非对称密码完成密钥协商，再用对称加密保护正文的机密性，用 MAC 或 AEAD 保证完整性和防篡改。中间人若想冒充服务端，必须拿到受信 CA 签发的匹配证书或攻破客户端信任链；浏览器会校验证书域名、有效期和签发链。证书校验、HSTS 和安全更新共同降低中间人风险。
82. websocket 中的 Handshaking 是什么？
答案：
WebSocket 握手从 HTTP 请求开始。客户端发送 GET，带 Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Key 和 Sec-WebSocket-Version 等头；服务端校验后返回 101 Switching Protocols，并用该 Key 计算 Sec-WebSocket-Accept。握手成功后连接从 HTTP 升级为 WebSocket，双方通过同一 TCP 连接交换帧；跨源场景还应校验 Origin，生产环境使用 wss。
83. 说下 websocket 的连接原理
答案：
浏览器先通过 HTTP Upgrade 请求与服务端建立 WebSocket 握手，服务端返回 101 后，连接进入持久的全双工通信状态。协议以帧承载文本、二进制、Ping/Pong 和 Close；客户端发送的帧必须掩码，服务端通常不需要。连接建立在 TCP 上，断开由任一方发起，实际应用要处理心跳、超时、自动重连、重复消息和服务端扩容后的会话路由。
84. CSP（Content Security Policy）可以解决什么问题?
答案：
CSP 主要限制浏览器能从哪里加载和执行资源，以及页面能向哪里发起连接。它可阻断未授权脚本、内联脚本和 eval，限制图片、样式、字体、iframe、Worker、XHR/fetch 等来源，降低 XSS、恶意资源注入、点击劫持和数据外带风险。可先用 Content-Security-Policy-Report-Only 收集违规报告，再使用 nonce/hash 放行必要内联代码；CSP 不能替代服务端输入校验和输出转义。
85. webSocket 有哪些安全问题，应该如何应对？
答案：
WebSocket 常见风险包括跨站 WebSocket 劫持、未授权连接、消息注入、XSS、拒绝服务和明文窃听。应使用 wss，服务端严格校验 Origin，并用 Cookie 之外的会话校验或 CSRF 防护确认身份；按用户和消息类型做授权、大小限制、速率限制和超时，校验并编码消息内容，限制连接数，处理 Ping/Pong 与重连，日志中避免记录令牌和敏感数据。
86. cookie 怎么设置只在 https 时携带？
答案：
在服务端设置 Cookie 属性 Secure，例如 Set-Cookie: sid=...; Secure，浏览器就只会在 HTTPS 请求中携带它，HTTP 请求不会发送。通常还应同时设置 HttpOnly 防止脚本读取，并按跨站需求设置 SameSite=Lax/Strict；若必须跨站携带，则使用 SameSite=None; Secure。Secure 只限制传输通道，不能代替会话过期、轮换和服务端鉴权。
87. script标签放在header里和放在body底部里有什么区别？
答案：
脚本放在 head 且无 async/defer 时，HTML 解析会暂停，脚本下载并执行后才继续，可能阻塞首屏；放在 body 底部通常已解析出主要 DOM，脚本执行不会阻塞前面的页面构建，但仍会阻塞收尾解析。现代页面更推荐在 head 使用 defer：并行下载、按文档顺序执行且在解析完成后执行；独立脚本可用 async，但执行顺序不保证。
88. 怎么进行站点内的图片性能优化？
答案：
先按内容选择格式：照片优先 AVIF/WebP，需无损或透明可用 WebP/PNG，图标尽量 SVG；用响应式图片 srcset、sizes 和 <picture> 提供合适尺寸，避免下载后再缩放。首屏关键图预加载并设置正确宽高，非首屏使用懒加载；压缩元数据、合理调质量，配合 CDN、长缓存和指纹文件名。还要注意避免过多大图、布局位移和重复解码。
89. POST请求的 Content-Type 常见的有哪几种？
答案：
常见的 POST 类型有三种：application/x-www-form-urlencoded，字段按键值对编码，适合普通表单；multipart/form-data，按 boundary 分段，适合文件和文本混合上传；application/json，正文是 JSON，适合接口传递结构化数据。此外还有 text/plain、application/xml 等。类型必须与实际正文格式一致；跨源 POST 使用非简单类型时通常会触发 CORS 预检。
90. 说说你对前端鉴权的理解
答案：
前端鉴权包括认证“你是谁”和授权“你能做什么”。登录后服务端创建会话或签发访问令牌，前端通过安全 Cookie 或合适的 Authorization 机制携带，服务端每次请求校验身份、过期时间、权限和资源归属；前端路由守卫只负责体验，不能作为安全边界。优先使用 HttpOnly、Secure、合适的 SameSite，短期访问令牌配合刷新机制，并处理退出、轮换、撤销和 CSRF/XSS 风险。
91. 跨域时怎么处理 cookie？
答案：
跨源请求要同时满足客户端和服务端条件：客户端 fetch/XHR 设置 credentials: 'include'，服务端返回具体的 Access-Control-Allow-Origin（不能是 *）和 Access-Control-Allow-Credentials: true；预检请求也必须正确响应。Cookie 自身还要满足 Domain、Path、Secure 和 SameSite，跨站场景通常要求 SameSite=None; Secure。CORS 只影响浏览器脚本访问，不会改变 Cookie 的域和发送规则。
92. HTTP1.0，HTTP1.1，HTTP2.0之间有什么区别？
答案：
HTTP/1.0 通常每次请求新建连接，缓存和连接管理能力较弱；HTTP/1.1 默认持久连接，支持 Host、分块传输和更完善缓存，但同一连接的请求响应仍可能队头阻塞。HTTP/2 使用二进制分帧、单连接多路复用、HPACK 头部压缩和流优先级，降低重复连接与头部开销，但 TCP 丢包仍会影响整个连接。HTTP/3 改用 QUIC/UDP，把可靠传输和 TLS 1.3 集成，并减少跨流队头阻塞。
93. 说说对 HTTP3 的了解
答案：
HTTP/3 是运行在 QUIC 之上的 HTTP，QUIC 基于 UDP，但在用户态实现可靠传输、拥塞控制、流量控制和 TLS 1.3。它以独立流承载请求，减少 TCP 层队头阻塞；通过 Connection ID 支持网络切换时连接迁移，握手支持 1-RTT，已有会话在满足条件时可 0-RTT 发送数据。代价是 UDP 可能被网络设备限制，0-RTT 数据还需防重放，不能无条件使用。
94. 说说WebSocket和HTTP的区别
答案：
HTTP 是请求-响应模型，通常一次请求对应一次响应，虽可用 Keep-Alive、HTTP/2 多路复用或长轮询复用连接，但服务端主动推送能力有限；WebSocket 先通过 HTTP Upgrade 握手，随后在持久连接上双向、全双工交换帧。HTTP 更适合资源获取、缓存、幂等接口和普通 CRUD；WebSocket 更适合聊天、协同、行情等高频实时通信，但要自行处理心跳、重连、鉴权和扩容。
95. 你知道哪些应用层协议？
答案：
应用层协议包括 Web 使用的 HTTP/HTTPS、实时通信使用的 WebSocket；域名解析使用 DNS，自动获取网络配置使用 DHCP；文件传输有 FTP、SFTP；邮件收发有 SMTP、POP3、IMAP；远程登录常见 SSH；时间同步有 NTP；物联网和消息系统还常见 MQTT、AMQP。它们直接面向具体应用语义，通常建立在 TCP、UDP 或 QUIC 等传输协议之上。
96. TCP是怎么判断丢包的？
答案：
TCP 主要通过 ACK 和序列号判断数据是否到达：发送方在超时时间内未收到确认，会进行超时重传；若连续收到多个重复 ACK，通常说明中间序号的数据段缺失，会快速重传。接收方也会用序列号发现乱序和重复，并重复确认已连续收到的范围。超时时间依据 RTT 动态估算，拥塞控制会在丢包后降低发送速率；注意 ACK 丢失和数据丢失都可能触发重传。
97. TCP和HTTP请求之间有什么关系？
答案：
HTTP 是应用层协议，通常运行在 TCP 连接之上：先完成 TCP 建连，再传输 HTTP 请求和响应。一个持久 TCP 连接可以承载多个 HTTP 请求；HTTP/1.1 通常按序处理，浏览器会为同一主机建立多个连接。HTTP/2 在单个 TCP 连接中用流和帧实现多路复用；HTTP/3 则改用 QUIC。连接复用能减少握手开销，但仍受协议版本、浏览器连接池、超时和服务器配置影响。
98. 说说 https 的握手过程
答案：
HTTPS = HTTP over TLS。通常先完成 DNS、TCP 三次握手，再进行 TLS 握手：客户端发送支持的版本、随机数和密码套件；服务端选择参数并发送证书，客户端校验证书链、域名和有效期；双方通过 ECDHE 等算法协商共享密钥，并校验握手摘要。之后使用对称加密传输 HTTP 数据。TLS 1.3 已合并并简化流程，恢复会话时还可进一步减少往返。
99. HTTP2中，多路复用的原理是什么？
答案：
HTTP/2 把请求和响应拆成带长度、类型、流 ID 的二进制帧；同一连接里可同时存在多个相互独立的双向流，帧按需交错传输，再按流 ID 重组为完整消息。因此一个慢请求不会阻塞其他 HTTP 流，减少了 HTTP/1.1 的应用层队头阻塞和多连接开销。它仍受底层 TCP 丢包重传影响，TCP 层的队头阻塞并未消失。
100. 从存储位置看，浏览器缓存分为哪几种？
答案：
从浏览器实现看，常见位置包括 Service Worker 的 Cache Storage、内存缓存和磁盘缓存；HTTP/2 早期还定义过 Push Cache，但服务端推送已逐渐被弃用，不能当作通用必经层级。Service Worker 可由代码决定缓存策略；内存缓存快但生命周期短，磁盘缓存持久性和容量更好。localStorage、IndexedDB 属于业务存储，不是 HTTP 缓存。具体命中顺序由浏览器和请求模式决定。
101. Cache-Control 有哪些常见配置值？
答案：
常见值有：max-age=N 指定秒数内可直接复用；s-maxage 专用于共享缓存；no-cache 不是不缓存，而是使用前必须向源站验证；no-store 禁止存储；public 允许共享缓存，private 仅允许用户缓存；must-revalidate 要求过期后不可擅自使用；immutable 表示新鲜期内内容不变。请求侧还常见 max-age=0、no-cache，用于促使重新验证。
102. 说说对TCP/IP协议的了解
答案：
TCP/IP 不是单一协议，而是一组分层协议：应用层包含 HTTP、DNS、TLS 等；传输层主要有 TCP 和 UDP；网际层负责 IP 寻址与路由；链路层负责局域网帧和介质访问。分层让各层通过约定接口协作，也便于替换实现。一次网页访问通常经过 DNS 解析、IP 路由、TCP 或 QUIC 建连、TLS 协商，最后由 HTTP 传输业务数据。
103. 说说你对“三次握手”、“四次挥手”的理解
答案：
TCP 三次握手是客户端发送 SYN，服务端回复 SYN+ACK，客户端再 ACK，用来确认双方收发能力并同步初始序列号，第三次确认后连接建立。四次挥手通常是主动方发送 FIN，另一方 ACK；另一方数据发完后发送 FIN，主动方再 ACK，因为 TCP 两个方向可独立关闭。主动关闭方进入 TIME_WAIT，以确保旧报文失效并让对端收到最终确认；异常断开可能通过 RST。
104. 前端性能优化指标有哪些？怎么进行性能检测？
答案：
核心指标包括加载性能的 LCP、FCP、TTFB、Speed Index，交互性能的 INP，稳定性的 CLS，以及错误率、资源体积和长任务。检测时用 Lighthouse、Chrome DevTools、Performance 面板和 Web Vitals 采集真实用户数据；结合 PerformanceNavigationTiming、ResourceTiming、Paint 和 Long Tasks 定位瓶颈。要区分实验室与真实用户、冷缓存与热缓存，并按设备、网络和页面阶段分析，不能只看单一平均值。
105. 为什么推荐将静态资源放到cdn上？
答案：
CDN 在靠近用户的边缘节点缓存和分发静态资源，可缩短网络 RTT，降低源站带宽与并发压力，并利用节点扩容提升可用性。资源请求还可与主站建立不同连接，改善队头等待。部署时要设置合理的 Cache-Control，用内容哈希保证版本更新，配置回源、压缩、HTTPS、跨域和失效策略。CDN 不能自动解决动态接口慢、缓存误配或源站故障，缓存命中率也受 URL 和请求头设计影响。
106. 介绍下304过程
答案：
浏览器已有新鲜度缓存但需要验证时，会发送条件请求：若缓存带 ETag，请求携带 If-None-Match；若有修改时间，则携带 If-Modified-Since。服务器比较后发现资源未变化，返回 304 Not Modified，不带响应体，浏览器继续使用本地缓存并更新相关缓存元数据；有变化则返回 200 和新内容。304 只表示验证成功，不是资源本身的业务状态码。
107. 什么是DNS劫持？
答案：
DNS 劫持是域名解析结果被恶意或错误地改写，使用户访问到攻击者页面、广告页或错误服务器，常发生在本机、路由器、运营商递归 DNS 或权威 DNS 环节。防护包括使用可信递归解析、DNSSEC、HTTPS 证书校验和 HSTS；应用侧不能只相信解析出的 IP。若已进入 HTTPS，伪造站点通常会因无法提供匹配域名的有效证书而被浏览器拦截，但证书签发或终端被攻破仍需额外防范。
108. 301、302、303、307、308 这些状态码有什么区别？
答案：
301 和 308 表示永久重定向，302 和 307 表示临时重定向。301/302 在历史客户端中可能把 POST 改成 GET；307/308 要求保留原请求方法和请求体，更适合不能改变语义的重试。301/308 可被长期缓存并影响搜索引擎，302/307 通常不表示永久迁移。303 特意要求客户端用 GET 获取另一个资源，常用于 POST 成功后的 PRG（Post/Redirect/Get）流程。
109. 浏览器为什么要请求并发数限制？
答案：
浏览器限制同一主机的并发连接，主要是避免单个页面耗尽客户端、代理和服务器资源，也防止大量连接造成拥塞、上下文切换和不公平占用。HTTP/1.1 下并发连接还能绕开单连接的队头阻塞，但连接数不是固定标准，受浏览器、协议版本、代理和网络状态影响。HTTP/2/3 通常通过一个连接复用多个流，限制更多体现为并发流、优先级、带宽及服务器 SETTINGS，而不是简单的 TCP 连接数。
110. TLS 1.3 做了哪些改进？
答案：
TLS 1.3 删除了脆弱或过时的密码套件和静态 RSA、静态 DH 密钥交换，默认使用具备前向保密的 ECDHE，并只保留 AEAD 加密。握手消息更少，完整握手通常从两次往返降为一次，恢复会话可 0-RTT 发送早期数据。它还强化了握手加密、版本协商和密钥派生。0-RTT 可能被重放，因此只能用于幂等请求，且双方仍需处理兼容、证书和会话票据安全。
111. TLS1.2 握手的过程是怎样的？
答案：
TLS 1.2 通常先完成 TCP 建连。客户端发送 ClientHello，包含版本、随机数和密码套件；服务端以 ServerHello 选择参数，发送证书，使用 ECDHE 时还发送密钥交换参数并签名，随后结束服务端握手。客户端验证证书和签名，发送自己的密钥交换参数，双方据此计算预主密钥并派生会话密钥；再通过 ChangeCipherSpec 和 Finished 校验握手摘要。校验成功后使用对称 AEAD 加密应用数据。
112. 如何理解 HTTP 代理？
答案：
HTTP 代理是客户端与目标服务器之间的中间转发方：客户端把请求交给代理，代理再代为访问并返回响应。正向代理服务客户端，可用于统一出口、缓存、审计或访问控制；反向代理位于服务端前，可做负载均衡、TLS 终止、缓存和路由。HTTP 明文请求可直接转发；HTTPS 通常使用 CONNECT host:port 建立隧道，代理看到目标和流量元数据但不能读取内容，除非部署受控的 TLS 中间人证书。
113. 说说你对cookie的理解
答案：
Cookie 是浏览器按域、路径等范围保存并在匹配请求中自动发送的小型键值数据，常用于会话标识、偏好和登录状态。服务端通过 Set-Cookie 设置，常见属性有 Expires/Max-Age、Domain、Path、Secure、HttpOnly 和 SameSite。它会随请求发送，不能存放大量数据；应避免保存敏感明文，并防范 XSS、CSRF、固定会话和过期失控。Cookie 的自动携带也会增加请求体积。
114. HTTP1.1 中如何解决 HTTP 的队头阻塞问题？
答案：
HTTP/1.1 的单连接串行响应会产生应用层队头阻塞。常见缓解方式是浏览器为同一主机建立多个 TCP 连接，把请求分散到不同连接上；也可以使用管线化，但因代理兼容性和响应必须按序返回，实际很少启用。资源域名拆分曾用于增加连接数，不过会增加 DNS、TCP 和 TLS 成本。真正的多路复用由 HTTP/2 的帧和流提供；HTTP/1.1 无法彻底消除该问题。
115. HTTP 中如何处理表单数据的提交？
答案：
表单提交由 method 和 enctype 决定。GET 通常把字段编码到 URL 的 query 中，适合幂等查询；POST 默认使用 application/x-www-form-urlencoded，字段经过百分号编码后放在请求体。上传文件应使用 multipart/form-data，浏览器负责生成 boundary；纯文本或 JSON 接口常用 application/json，需客户端手动序列化。服务端应校验 Content-Type、大小、字段和 CSRF，不能把客户端校验当作安全边界。
116. 对于定长和不定长的数据，HTTP 是怎么传输的？
答案：
HTTP 报文体长度明确时，通常用 Content-Length 表示字节数，接收方读满后结束；HTTP/1.1 动态生成或长度未知时可用 Transfer-Encoding: chunked，按“十六进制长度 + 数据”分块，最后发送长度为 0 的块。HTTP/2/3 不使用这套 chunked 编码，而由帧长度和流结束标志界定数据。若响应采用压缩，长度语义要结合实际传输编码，不能把字符数当字节数。
117. HTTP 报文结构是怎样的？
答案：
HTTP/1.x 报文由起始行、首部、空行和可选消息体组成。请求起始行是“方法 + 目标路径/查询 + 版本”，如 GET /a HTTP/1.1；响应起始行是“版本 + 状态码 + 原因短语”。首部按 字段名: 字段值 组织，字段名大小写不敏感；空行标志首部结束。消息体是否存在及其边界由 Content-Length、传输编码、状态码和请求方法共同决定。HTTP/2/3 则把这些语义映射到二进制帧。
118. 为什么说HTTP是无状态的协议？
答案：
HTTP 无状态，指协议本身不会自动记住前一次请求的业务上下文；每个请求都应携带服务器处理它所需的信息。这样服务器易于横向扩展、连接可复用，故障恢复也更简单，但登录态、购物车等连续业务需要额外机制。常见做法是 Cookie 携带会话 ID、Authorization 携带令牌，或由服务端保存状态。无状态不等于 TCP 无连接，也不妨碍应用显式维护状态。
119. 如果一个列表有 100000 个数据，这个该怎么进行展示？
答案：
不能把 100000 条全部一次性渲染到 DOM。优先让服务端分页或游标加载，结合搜索和筛选减少数据量；前端列表使用虚拟滚动，只保留视口附近节点，并为项目预留稳定高度。滚动和测量用 requestAnimationFrame 合并，图片懒加载，避免频繁布局和长任务。若必须处理全量数据，可分片调度或交给 Web Worker。还要处理键盘可访问性、快速滚动白屏、动态高度、排序和滚动位置保持。
120. 如何确定页面的可用性时间，什么是 Performance API？
答案：
页面可用性不能只看 load，应结合导航时序、首屏绘制和交互就绪。现代做法使用 performance.getEntriesByType('navigation')[0] 的 startTime、domContentLoadedEventEnd、loadEventEnd，再结合 Paint、LCP、INP 和资源时序；loadEventEnd 之前的页面加载耗时可近似为 loadEventEnd - startTime，事件未发生时不要把 0 当成真实耗时。Performance API 提供高精度时间、资源、标记和测量能力，实际监控还需上报真实用户数据。
121. get 和 post 请求在缓存方面有什么区别？
答案：
GET 按 HTTP 语义是安全且幂等的，响应通常适合被浏览器、代理和 CDN 缓存；是否命中仍取决于响应的 Cache-Control、Vary、验证器和请求条件。POST 可能改变服务端状态，默认不应被通用缓存直接复用，但规范允许在明确新鲜度和缓存规则时缓存，且部分缓存实现支持受控 POST。真正的区别不是“GET 必缓存、POST 绝不缓存”，而是方法语义和缓存实现的默认策略。
122. get 请求是否限制了传参长度？
答案：
HTTP 规范没有规定 GET 参数的统一最大长度；限制通常来自浏览器、服务器、反向代理、WAF 和 URI 解析器。GET 参数位于 URL 中，过长可能触发 414、日志截断、缓存键过大或代理不兼容，因此不要依赖某个浏览器的经验上限，也不能简单用 POST 规避所有限制。应按接口和部署链路设置合理上限；需要传递大量结构化数据时使用 POST 请求体，并在服务端校验大小。
123. 什么是点击劫持？如何防范点击劫持？
答案：
点击劫持是攻击者把真实站点放进透明或伪装的 iframe，再用视觉诱导让用户点击真实按钮，从而执行转账、授权等操作。防护首选响应头 Content-Security-Policy: frame-ancestors 'self' 或指定可信来源；兼容旧浏览器可设置 X-Frame-Options: DENY/SAMEORIGIN。同时应配合 CSRF 防护、关键操作确认和合理的界面提示，因为这些头主要限制嵌入，不能单独防止所有诱导点击。
124. 什么是 Samesite Cookie 属性？
答案：
SameSite 是 Cookie 属性，用来限制跨站请求是否自动携带 Cookie，从而降低 CSRF 和跨站追踪风险。Strict 最严格，跨站场景基本不发送；Lax 允许部分安全的顶层导航 GET，通常是现代浏览器默认策略；None 允许跨站发送，但必须同时设置 Secure。它按“站点”而非简单按“源”判断，跨子域通常仍属同站；跨站业务需明确配置，并结合 CSRF Token，不能把 SameSite 当作唯一防线。
125. Cookie 的 SameSite 属性有什么作用？
答案：
SameSite 控制 Cookie 在跨站请求中的发送范围：Strict 几乎只在同站请求发送，安全性高但从外部链接进入站点时可能没有登录态；Lax 通常允许顶层导航的安全方法 GET，兼顾体验与防护；None 允许跨站携带，但必须配合 Secure。它能降低 CSRF 风险，也减少第三方追踪，但不能替代服务端校验、CSRF Token、Origin/Referer 检查；不同浏览器的默认值和兼容性也要验证。
126. cookie中的 HttpOnly 属性有什么用途？
答案：
设置 HttpOnly 后，脚本不能通过 document.cookie 读取或修改该 Cookie，但浏览器在满足域、路径、安全策略的请求中仍会自动携带它。它特别适合会话标识，可降低 XSS 直接窃取 Cookie 的风险。不过 HttpOnly 不能阻止 XSS 代表用户发起请求，也不能防御 CSRF、会话固定或服务端漏洞，因此应同时使用 CSP、输出编码、SameSite、CSRF Token 和安全的会话轮换策略。
127. TCP 和 UDP的区别是什么？
答案：
TCP 面向连接，提供按序、可靠、无重复的字节流，并通过确认、重传、流量控制和拥塞控制适应网络变化，代价是握手和状态维护开销较大。UDP 无连接、无序且不保证到达，只提供数据报边界，开销和延迟更低；可靠性、排序、拥塞控制要由应用补足。文件传输等偏好 TCP；实时音视频、DNS 或自定义协议常用 UDP，但具体选择应看可靠性、延迟和部署环境。
128. 协商缓存中，有了 Last-Modified，为什么还会出现 ETag？
答案：
Last-Modified 只能按服务器提供的修改时间判断，通常精度为秒，存在时间未更新、秒内多次修改或时间改变但内容未变等问题。ETag 是资源版本标识，可由内容哈希或服务器版本生成，客户端用 If-None-Match 做更精确的条件验证，也能区分内容实际版本。两者可同时发送，服务器通常优先比较 ETag；生成 ETag 时还要避免把用户私有内容错误地共享缓存。
129. 虚拟DOM一定更快吗？
答案：
不一定。虚拟 DOM 用 JS 对象描述界面，通过差异比较和批量提交减少不必要的 DOM 操作，通常有利于复杂状态更新和可维护性；但它也有创建对象、比较和调度的成本。简单页面、局部精确更新或高频动画中，直接操作 DOM 可能更快，最终应以真实场景测量为准。
130. Nginx支持哪些负载均衡调度算法？
答案：
常见有加权轮询（默认，按 weight 分配流量）、ip_hash（按客户端 IP 固定后端，适合有会话黏性的场景）、least_conn（优先发给连接数较少的服务器）和 hash（按 key，如 URI 分配）。fair 会参考响应时间，但通常需第三方模块；算法选择还要结合健康检查、会话共享和故障转移。
131. 什么是负载均衡？
答案：
负载均衡是把客户端请求按规则分发到多个后端实例，并在故障时摘除不可用节点，从而提升吞吐、可用性和扩展能力。它可以由硬件设备或 Nginx、LVS、云负载均衡等软件实现。常见策略有轮询、加权、最少连接和一致性哈希，实际还需配合健康检查与会话方案。
132. 正向代理和反向代理分别是什么？
答案：
正向代理代理客户端：客户端明确目标服务器，先把请求交给代理，目标服务器通常只看到代理地址，可用于访问控制、缓存或隐藏客户端。反向代理代理服务端：客户端只访问代理域名，由代理转发到后端集群，客户端无需感知后端，可用于负载均衡、TLS 终止、缓存和内网隔离。
133. nginx是什么？
答案：
Nginx 是高性能、事件驱动的 Web 服务器和反向代理，也能充当静态资源服务器、负载均衡器及邮件代理。它用少量工作进程处理大量并发连接，适合 TLS 终止、静态文件、缓存和网关转发；业务逻辑通常仍交给 Node.js、Java 等上游服务。
134. 简单说下你对 HTTP2 的理解
答案：
HTTP/2 在 HTTP 语义不变的基础上引入二进制分帧和多路复用，多个请求可共享一条 TCP 连接，配合 HPACK/QPACK 类似的首部压缩、流量控制、优先级和 RST_STREAM，减少连接及首部开销。它仍受 TCP 丢包导致的连接级队头阻塞影响；服务端推送已逐渐不推荐，HTTP/3 则基于 QUIC。
135. HTTPS 为什么是安全的？
答案：
HTTPS 是 HTTP over TLS，安全性来自三点：证书链和域名校验确认服务端身份，防止中间人冒充；握手用非对称密码协商会话密钥，之后用高效的对称加密保护内容；TLS 还通过认证加密或 MAC 检测篡改。它不能保证服务端业务逻辑安全，也不能防止端点被攻破或用户主动泄露数据。
136. 强缓存和协商缓存分别是什么？
答案：
强缓存命中时浏览器不发请求，直接使用本地副本，主要由 Cache-Control 的 max-age 控制，Expires 是旧版绝对时间。过期后进入协商缓存，浏览器携带 If-None-Match/If-Modified-Since，服务端未变化返回 304，变化则返回 200 新内容。ETag 通常比时间戳更可靠，Cache-Control 优先于 Expires。
137. 什么是对象存储OSS？
答案：
对象存储 OSS 是以 object 为基本单位、通过 HTTP API 管理数据的海量存储服务。对象通常包含内容、唯一 key 和元数据，放在 bucket 中，由服务商负责分布式持久化、扩容和冗余。它适合图片、视频、备份和静态资源，但不适合频繁随机修改；权限、签名 URL、生命周期和 CDN 需要单独设计。
138. 什么是CDN？
答案：
CDN 是分布在各地的边缘节点网络，用户请求先被调度到较近或较合适的节点；节点命中缓存就直接返回，未命中再回源获取并缓存。它能降低源站带宽和延迟、吸收突发流量，常用于静态资源和可缓存接口。缓存键、TTL、失效策略、回源保护和动态请求绕过必须配置正确。
139. 请说说cookie与session有什么区别？
答案：
Cookie 由浏览器保存并按域、路径等规则自动随请求发送，容量小，适合保存会话标识；应配合 Secure、HttpOnly、SameSite 和合适的过期时间。Session 是服务端保存的会话状态，客户端通常只持有 session id，数据不直接暴露，但需要存储、过期和集群共享方案。Cookie 不是 Session 的替代品，常二者配合使用。
140. 如何用webpack来优化前端性能
答案：
Webpack 优化可从构建和交付两端做：用 production 模式、压缩与 tree-shaking，按路由或组件动态 import 拆包，合理设置 splitChunks，避免重复依赖；图片和字体按需压缩，利用长期缓存文件名；开启 gzip/Brotli、CDN，并分析 bundle 体积。还要注意不要过度拆包，需结合网络请求数和运行时性能验证。
141. 即时通讯的实现：短轮询、长轮询、SSE 和 WebSocket 间的区别？
答案：
短轮询是客户端定时请求，简单但请求开销和延迟较大；长轮询是请求保持到有数据或超时后再重连，实时性更好但占用连接。SSE 基于 HTTP，服务端向客户端单向持续推送，支持事件类型和自动重连；WebSocket 在握手后升级为全双工长连接，适合双向低延迟通信。选择取决于方向、实时性、代理兼容性和连接规模。
142. 介绍下WebSocket
答案：
WebSocket 先通过 HTTP/1.1 Upgrade 握手，成功后建立持久的全双工连接，客户端和服务端都能主动发送消息，适合聊天、协同编辑和行情推送。它不是自动可靠的业务协议，应用层仍需定义消息格式、心跳、重连、鉴权、幂等和断线补偿；生产环境通常使用 wss，并在网关配置 Upgrade 转发。
143. DNS协议介绍
答案：
DNS 将域名解析为 IP，采用分层命名和递归/迭代查询：客户端先查浏览器、系统及本地缓存，再由递归解析器向根、顶级域和权威服务器查询。常见记录有 A/AAAA、CNAME、NS、MX 和 TXT；TTL 决定缓存时间。DNS 通常使用 UDP 53，响应过大或区域传送等场景可用 TCP，DoH/DoT 还能加密传输。
144. HTTP状态码
答案：
HTTP 状态码分五类：1xx 表示处理中或协议提示；2xx 表示成功，如 200、201、204；3xx 表示重定向或缓存，如 301、302、304；4xx 表示请求方错误，如 400、401、403、404、429；5xx 表示服务端或上游错误，如 500、502、503、504。状态码只描述 HTTP 层结果，业务错误仍应有清晰的响应体。
145. HTTP协议的优点和缺点
答案：
HTTP 的优点是简单、无状态、跨平台、可扩展，资源和方法语义清晰，易于缓存、代理和调试；缺点是明文传输会被窃听或篡改，无状态使会话需额外维护，传统 HTTP/1.1 存在连接及队头阻塞、首部重复等开销。HTTPS 用 TLS 补足传输安全，HTTP/2/3 改善传输效率，但不解决所有业务安全问题。
146. HTTP 1.1和 HTTP 2.0 的区别
答案：
HTTP/1.1 主要以文本报文和请求/响应为单位，连接可复用但仍有队头阻塞，首部重复且并发常依赖多连接。HTTP/2 改为二进制分帧，在单 TCP 连接上多路复用多个 stream，并支持首部压缩、流量控制和流重置。HTTP/2 的多路复用不等于完全消除队头阻塞，TCP 丢包仍会影响同一连接中的流。
147. HTTP 1.0和 HTTP 1.1 之间有哪些区别？
答案：
HTTP/1.1 相比 HTTP/1.0 增加了默认持久连接（Connection: keep-alive）、管线化规范、Host 请求头、分块传输编码和更丰富的缓存控制，并支持范围请求等。Host 使一台服务器可承载多个域名；持久连接减少重复 TCP 握手。管线化实际支持有限，不能把它等同于 HTTP/2 的多路复用。
148. options请求方法及使用场景
答案：
OPTIONS 用于查询目标资源支持的通信选项，服务器可通过 Allow 返回允许的方法；浏览器跨域请求时还会发送 CORS 预检，携带 Origin、Access-Control-Request-Method 和相关首部，服务端用 Access-Control-Allow-* 表明是否放行。简单跨域请求通常不触发预检。OPTIONS 本身一般不改变资源状态，服务端应正确处理缓存和鉴权。
149. 常见的HTTP请求方法
<p></p>
答案：
常见方法包括：GET 获取资源，应安全且幂等；POST 创建资源或执行非幂等操作；PUT 按完整表示替换资源，幂等；PATCH 局部修改，是否幂等取决于设计；DELETE 删除资源，语义上幂等；HEAD 只取与 GET 相同的响应头而不返回正文；OPTIONS 查询能力或进行 CORS 预检。是否幂等描述重复执行的最终效果，不代表一定成功。
150. GET和POST的请求的区别
答案：
GET 用于获取资源，参数通常在 URL 查询串中，便于缓存、分享和收藏，语义上安全且幂等；POST 通常把数据放在请求体中，用于创建或提交处理，默认不幂等。两者都可传请求体，但服务器和中间件对 GET body 支持不一致；GET 参数会进入历史、日志和 Referer，因此不能把“POST 更安全”当作保密手段，敏感数据应使用 HTTPS。
151. HTTP Request Header和Response Header里面分别都有哪些比较重要的字段
答案：
常见 Request Header 有 Host、Authorization、Content-Type、Content-Length、Accept、Cookie、Origin/Referer、User-Agent、Cache-Control、If-None-Match 和 If-Modified-Since。Response Header 常见有 Content-Type、Content-Length、Cache-Control、ETag、Last-Modified、Set-Cookie、Location、Access-Control-Allow-Origin、Content-Encoding、Vary 和安全头。具体字段取决于请求方法、缓存、跨域与鉴权场景。
152. HTTP的长连接和短连接分别是什么？keep-alive是干什么的
答案：
短连接是一次请求响应后关闭 TCP 连接，下次请求需重新建立；长连接则在多个请求响应间复用连接，减少握手和慢启动开销。HTTP/1.1 默认倾向持久连接，HTTP/2 通常在一条连接中复用多个流。keep-alive 表示保持连接及可选的超时、最大请求数；它不等于 TCP 永不关闭，也不能代替心跳、连接池和超时控制。
153. HTTP和HTTPS的区别
答案：
HTTP 是应用层明文协议，默认端口 80，内容可能被窃听、篡改和冒充；HTTPS 是 HTTP 经 TLS 加密，通常使用 443。TLS 通过证书验证身份、握手协商会话密钥，并提供机密性、完整性和抗中间人能力。HTTPS 会增加握手和加解密成本，但可通过连接复用、会话恢复等降低影响；它不负责业务权限校验。
154. 点击劫持
答案：
点击劫持是攻击者用透明或伪装的 iframe 覆盖诱导界面，让用户以为点击正常按钮，实际操作了目标站点。防护应在服务端设置 Content-Security-Policy 的 frame-ancestors，兼容旧浏览器可设置 X-Frame-Options: DENY 或 SAMEORIGIN；同时对敏感操作做二次确认和 CSRF 防护。仅靠前端判断无法可靠阻止。
155. 说说常规的前端性能优化手段
答案：
先测量再优化：网络侧减少不必要请求，使用 HTTP/2/3、CDN、压缩和合理缓存；构建侧压缩、tree-shaking、代码分割和懒加载；渲染侧减少长任务、批量 DOM 更新、避免强制同步布局，图片按尺寸和格式优化；交互侧延迟非关键工作。用 Lighthouse、Performance、Web Vitals 和真实用户数据验证，避免只看单次本地分数。
156. CSRF攻击及防护
答案：
CSRF 利用浏览器会自动携带目标站点 Cookie 的特点，诱导已登录用户向目标站点发起非本人意愿的状态变更请求。防护首选服务端校验不可预测的 CSRF token，并设置 SameSite Cookie；再结合 Origin/Referer 校验、合理使用 POST 和敏感操作二次确认。CORS 只控制跨域读取，不能单独防止 CSRF；GET 不应执行状态变更。
157. Http 缓存策略，有什么区别，分别解决了什么问题
<p style="text-align:start;text-indent:2em;"></p>
答案：
HTTP 缓存分两层：强缓存命中时无需请求服务器，Cache-Control: max-age 是首选，Expires 仅作兼容；协商缓存需要请求服务器验证，客户端带 If-None-Match 或 If-Modified-Since，资源未变返回 304，变更则返回 200。强缓存减少请求和响应体，协商缓存主要节省响应体。发布带内容指纹的静态资源可长期缓存，HTML 通常设置较短缓存并需重新验证。
158. 前端的常规安全策略
答案：
常规策略包括：输入校验与输出编码，防 XSS、CSRF 和注入；敏感数据全程 HTTPS，Cookie 设置 Secure、HttpOnly、SameSite；配置 CSP、X-Content-Type-Options、frame-ancestors/X-Frame-Options 等安全头；依赖锁版本并做漏洞扫描，代码审查和 CI 安全检查；最小权限、服务端鉴权、日志告警和定期渗透测试。前端校验只能改善体验，不能替代服务端校验。
159. 前端数据安全
答案：
前端不能把密钥或真正的机密放进源码、LocalStorage 或可被脚本读取的页面数据；敏感凭证应由服务端保管，短期令牌配合过期、轮换和最小权限。传输使用 HTTPS，Cookie 视场景设置 HttpOnly、Secure、SameSite，避免 XSS 窃取。接口要在服务端鉴权、限流和审计，数据展示还可采用字体映射、图片或异步接口等手段降低批量抓取，但不能声称绝对防爬。
160. sql 注入
答案：
SQL 注入是把未可信输入拼进 SQL，使数据库执行攻击者构造的条件、联合查询或其他语句，可能导致越权读取、修改甚至接管。核心防护是参数化查询或 ORM 绑定参数，让数据与 SQL 语法分离；同时做服务端类型校验、最小数据库权限、错误信息收敛和审计。黑名单过滤不能作为主要防线，前端过滤更不能替代后端防护。
161. 中间人攻击是什么？
答案：
中间人攻击（MITM）是攻击者插入通信双方之间，转发、窃听甚至篡改数据，而双方仍以为在直接通信。常见方式包括伪造 Wi-Fi、ARP 欺骗和伪造证书。防护重点是全程使用正确校验证书的 HTTPS/TLS、启用 HSTS、避免未知网络并及时更新系统和浏览器；VPN 只能保护到 VPN 出口，不能替代端到端身份校验。
162. 网络劫持
<p></p>
答案：
网络劫持是通信路径或解析结果被第三方控制、修改或重定向。DNS 劫持通常表现为域名解析到恶意地址；HTTP 劫持则利用明文传输篡改响应，例如插入广告或脚本。核心防护是全站 HTTPS，并正确配置证书、HSTS 和严格的 DNS 管理；HTTPS 可防止传输途中被任意读取或修改，但无法阻止服务器本身或终端被攻陷。
163. 静态资源完整性校验
答案：
静态资源完整性校验通常指子资源完整性（SRI）：发布方对脚本或样式文件计算 SHA-256、SHA-384 等摘要，并将 Base64 编码结果写入标签的 integrity 属性。浏览器下载资源后会重新计算摘要，匹配才执行或应用，不匹配则阻止加载。它能降低 CDN 被篡改的风险，但必须通过 HTTPS 防止标签本身被替换，并在资源版本更新时同步更新哈希。
164. HTTPS 有哪些优点？
<p></p>
答案：
HTTPS 是 HTTP over TLS，主要优点是：通过证书和域名校验确认服务器身份；通过加密保护传输机密性；通过消息认证和校验保证数据完整性，降低窃听、篡改和伪造风险。它不能保证业务逻辑、服务器或用户终端绝对安全，证书信任链或私钥失守也会带来风险。启用 HTTPS 还可使用 HTTP/2 等能力，但会增加握手和证书运维成本。
165. iframe 安全
<p></p>
答案：
iframe 的风险主要是点击劫持、嵌入不可信页面、跨域通信误用以及被利用发起请求。加载外部内容应限制来源，必要时使用 sandbox 限权；跨域通信只用 postMessage，并严格校验 event.origin 和消息格式，不能使用通配符盲目信任。页面若不允许被嵌入，应配置 CSP 的 frame-ancestors（兼容场景可配 X-Frame-Options）；涉及身份凭证时还要结合 SameSite Cookie 和 CSRF 防护。
166. 说说你对 XSS 的了解
答案：
XSS 是把不可信输入当作 HTML、脚本或事件执行，从而读取页面数据、冒充用户或篡改界面。反射型来自请求参数即时回显，存储型先进入数据库再影响访问者，DOM 型则由前端代码把 URL 等数据写入危险 DOM 接口。防护应按输出上下文进行编码，优先使用 textContent 和框架默认转义；确需富文本时使用可信清洗库，并配置 CSP、HttpOnly/Secure Cookie，不能只依赖前端过滤。
167. TCP链接为什么会采用三次握手，而不是两次或者四次呢？
答案：
TCP 三次握手分别是客户端发送 SYN，服务端返回 SYN+ACK，客户端再发送 ACK。它既确认客户端能发、服务端能收，也确认服务端能发、客户端能收，并让双方同步初始序列号。两次握手无法让服务端确认客户端已收到自己的响应，延迟到达的旧 SYN 可能造成错误建连和资源占用。四次握手不会显著增加这种确认价值，因此三次已足够。
168. URI、URL、URN分别是什么？
答案：
URI（统一资源标识符）是标识资源的统称，强调“是谁”；URL（统一资源定位符）是 URI 的一种，除了标识资源，还描述通过何种协议和位置访问它，例如 https://example.com/a；URN（统一资源名称）也是 URI 的一种，强调在命名空间中的持久名称，例如 urn:isbn:...，不描述访问位置。关系可以概括为：URL 和 URN 都属于 URI。