前端面试题手册

三个阶段的异步方案，层层递进：Callback：把后续操作作为回调函数传给异步操作。问题是回调地狱——多层嵌套横向增长，错误处理每个回调都得单独处理。Promise：把回调包装成对象，链式 .then() 解决横向嵌套，.catch() 统一处理错误。但长链仍不够直观，且 .then() 里不能直接用 try-catch。async/await：Promise 的语法糖。async 函数返回 Promise，await 暂停执行等结果。写法就是同步代码的样子，错误用 try-catch。本质还是 Promise——await 的值就是 .then() 回调的参数。// 三个方案的同一操作// CallbackgetData((err, data) => { if (err) return; process(data); });// PromisegetData().then(process).catch(handleError);// async/awaittry { const data = await getData(); process(data); } catch { handleError(); }追问async/await 怎么处理并发请求？Promise.all([fetch1, fetch2]) 配合 await。不要写成 await fetch1(); await fetch2()——这样是串行的，第二个请求等第一个完成才发。async 函数返回的 Promise 和普通 Promise 有区别吗？没有本质区别。async 函数内部抛错等于 reject，return 值等于 resolve。唯一注意的是：async 函数返回的 Promise 是原生 Promise，即使你 return 的是一个 thenable 对象，也会自动包裹成 Promise。

两对概念，一个在 CommonJS，一个在 ESModule。module.exports vs exports（CommonJS）：module.exports 是真正的导出对象。exports 只是 module.exports 的引用（const exports = module.exports）给 exports 赋新值会断开引用，导出失败；module.exports 赋新值可以安全做法：只添加属性用 exports.foo = bar，需要替换整个导出用 module.exports = foo// 正确module.exports = { a: 1 };exports.b = 2;// 错误 — exports 被重新赋值，断开引用exports = { a: 1 }; // module.exports 还是 {}export vs export default（ESModule）：export 是命名导出，可以有多个。导入时用 { name } 且名字必须匹配export default 是默认导出，每个模块只有一个。导入时可以取任意名字一个模块可以同时有命名导出和默认导出// 导入区别import { foo } from './a'; // 命名导出import foo from './a'; // 默认导出import foo, { bar } from './a'; // 两者都有追问为什么 export default 导入可以随意命名？因为默认导出本质上导出的是 { default: value } 这个特殊 key。import x from 就是取 default key 的值。因此也叫 default import。项目中应该优先用命名导出还是默认导出？命名导出更好——IDE 自动补全、refactor 改名时更安全、Tree-Shaking 友好。默认导出适合"这个模块只有一个主要导出"（如一个组件、一个工具函数）。但争议是社区级的，没有绝对的优劣。

核心思路：批量操作，减少重排次数。DocumentFragment：创建一个脱离文档流的容器，在内存中构建完所有 DOM 再一次性插入。Fragment 插入后自己会消失，只留下子节点。const fragment = document.createDocumentFragment();for (let i = 0; i < 500; i++) { const li = document.createElement('li'); li.textContent = i; fragment.appendChild(li);}ul.appendChild(fragment); // 一次 DOM 操作display: none：先把容器隐藏，批量改完再显示。隐藏期间的 DOM 操作不触发重排（元素不参与布局计算）。cloneNode：克隆节点，在克隆上做修改，改完后替换原节点。虚拟列表：不是优化 DOM 操作次数，而是减少 DOM 节点总数——几百次操作通常意味着在渲染大量数据。只渲染视口内可见的几十个元素，滚动时复用。追问DocumentFragment 和直接 appendChild 性能差多少？大量操作时差几个数量级。直接 appendChild 每次操作都触发一次重排（元素加入布局树）。Fragment 里的操作不触发重排，只最后 append 时触发一次。为什么不用 innerHTML 一次性拼接字符串？innerHTML 确实比逐个创建 DOM 快，但有 XSS 风险（用户输入会执行脚本）。纯服务端数据可以用 innerHTML，有用户数据用 createElement + textContent。

断点续传的本质是"客户端记住传到哪了，服务端知道从哪继续接"。核心流程：上传前计算文件 hash（MD5/SHA1），作为文件唯一标识发请求到服务端查"这个文件的哪些分片你有了"（返回已上传分片索引）客户端只上传缺失的分片服务端暂存每个分片全部分片上完后，服务端合并分片为完整文件Koa 侧关键点：用 @koa/multer 或直接读 stream 接收分片分片命名规则：{hash}-{index}，便于按 hash 查找和按 index 排序合并分片前校验每个分片的大小是否正确合并完后校验完整文件的 hash 是否和客户端一致追问分片大小怎么定？一般 1-5MB。太小请求次数多（HTTP 开销），太大断点续传意义不大了。网速好的用户可以用更大的分片。并发上传多个分片好还是串行好？并发上传更快，浏览器对同一域名的 HTTP/1.1 最大并发是 6 个（HTTP/2 不受限）。注意并发数不能太大——文件 I/O 是性能瓶颈，服务端同时写入大量分片会 IO 打满。合并完大文件后内存会炸吗？不会，用 fs.createWriteStream（流式写入）和 fs.createReadStream（流式读取）顺序追加。Koa 生态有 fs-extra 库做这些操作，底层是流式的不会一次性加载整个文件到内存。

三个维度的区别：作用域：var 是函数作用域，let/const 是块级作用域。{ } 内部用 let 声明的变量，括号外访问不到。变量提升：var 有提升且初始化为 undefined（声明前访问得到 undefined）。let/const 也有提升但存在暂时性死区（TDZ）——声明前访问直接 ReferenceError。重复声明：var 可重复声明（后覆盖前），let/const 在同一作用域不能重复声明。const 额外特性：声明时必须初始化，且不能重新赋值。但对象和数组的属性可以修改（const 锁的是绑定，不是值）。// var：函数作用域，讨厌的经典 bugfor (var i = 0; i < 3; i++) { setTimeout(() => console.log(i)); // 3 3 3}// let：块级作用域，每次迭代创建新绑定for (let i = 0; i < 3; i++) { setTimeout(() => console.log(i)); // 0 1 2}追问为什么 let 能解决 for 循环的回调/闭包问题？var 是整个 for 循环共享一个变量，循环结束后 i 是最终值。let 每次循环迭代都会创建一个新的绑定，每个 setTimeout 捕获的 i 是不同的绑定。即使循环结束后，这些绑定的值仍然保留着当时的 i。const 声明的对象属性为什么可以修改？const 锁定的是变量名到值的绑定关系——"这个变量名不能指向别的值"。对象属性是变量指向的内存地址内部的变更，不改变绑定关系。

核心区别就一条：Weak 版本的 key（或元素）是弱引用，不阻止垃圾回收。Set vs WeakSet：Set 元素可以是任何类型；WeakSet 元素只能是对象Set 可迭代（forEach、size、keys）；WeakSet 不可迭代Set 中对象被引用着，即使对象其他地方不再使用也不会被 GC；WeakSet 中对象没有其他引用时会被回收Map vs WeakMap：Map 的 key 可以是任何类型；WeakMap 的 key 只能是对象Map 可迭代；WeakMap 不可迭代WeakMap 条目会随 key 对象被 GC 而自动清除WeakMap 典型场景：Vue 3 的响应式依赖追踪、存储 DOM 节点的关联数据、为第三方对象附加元数据而不造成内存泄漏。WeakSet 用得少——需要标记"这个对象我见过"但不想阻止它被 GC 时用。追问为什么 WeakMap 没有 size 属性？因为 WeakMap 中条目可能随时被 GC 回收，size 值是瞬时的、不可靠的。如果 JS 引擎提供了 size，开发者的代码里依赖了这个值，但下一秒 GC 跑了一次值变了——这种不可预测性比没有 size 更糟糕。WeakMap 和 Map 在内存管理上有什么区别？Map 的 key 被引用着，即使这个 key 对象在别处都已不使用，Map 里的引用也会阻止 GC——内存泄漏风险。WeakMap 的 key 是弱引用，如果 key 对象没有其他强引用了，GC 可以回收，对应的 WeakMap 条目自动消失。

ES6 之后异步方案演进：回调函数：最原始的方式，问题是回调地狱（callback hell）——多层嵌套，错误处理困难。Promise：ES6 引入。把回调的嵌套转成 .then() 的链式调用，用 .catch() 统一处理错误。解决了回调地狱，但长链 .then() 仍然不够直观。Generator + co：通过 yield 暂停函数执行，配合自动执行器（如 co 库）实现类似同步的写法。现在基本被 async/await 取代。async/await：ES8（ES2017）正式引入。Promise 的语法糖——async 函数返回 Promise，await 暂停执行等待 Promise 完成。写法最像同步代码：async function getData() { const res = await fetch('/api'); const data = await res.json(); return data;}追问Promise.all、Promise.allSettled、Promise.race、Promise.any 的区别？all：全成功才成功，一个失败就失败allSettled：等全部完成（不管成败），返回结果数组含状态标记race：第一个完成的就返回（不管成败）any：第一个成功的就成功，全失败才失败（和 race 相反）async/await 的错误怎么处理？try-catch 包裹 await。或者用 .catch() 链在 async 函数的返回值上。也可以用 await promise.catch(() => fallbackValue) 的模式给错误设默认值。

React 的渲染分两个阶段：Render 阶段（协调 Reconciliation）：状态变化 → 创建新的 Virtual DOM 树 → 和旧的 Virtual DOM 做 diff → 标记需要更新的节点。这个阶段是纯计算，没有副作用，React 18 可以中断和恢复（并发模式）。Commit 阶段：把 diff 结果应用到真实 DOM。这个阶段不可中断，React 保证 DOM 更新的原子性。commit 结束后触发 useLayoutEffect 同步执行，然后浏览器重绘，最后异步执行 useEffect。React 18 之前 render 不可中断。18 的并发渲染（Concurrent Features）可以在 render 阶段暂停低优先级更新，优先处理用户交互等高优先级任务。追问什么情况下 React 会跳过组件的渲染？shouldComponentUpdate 返回 false（class 组件）React.memo 包裹的组件 props 没变（浅比较）state 没变化时（setState 传入相同值，React 用 Object.is 判断）Context value 没变时（但 Provider 下的所有 Consumer 会在 Provider render 时重新渲染，和 value 是否变化无关——这是常见性能陷阱）useLayoutEffect 和 useEffect 执行的时机有什么不同？useLayoutEffect 在 DOM 变更后、浏览器绘制前同步执行（阻塞渲染）。useEffect 在浏览器绘制后异步执行。需要读取 DOM 布局、同步更新防止闪烁的场景用 useLayoutEffect。React 18 并发模式的 "可中断渲染" 是怎么实现的？基于时间切片（Time Slicing）——Render 阶段被切成 5ms 的小段，每段结束后检查是否有更高优先级任务。如果有就暂停当前渲染，先处理高优任务。实现依赖的是 MessageChannel（而非 requestIdleCallback，因为后者在后台标签页可能被暂停）。

JSON 现在是默认的数据交换格式。XML 在上一个时代扮演过同样角色。最大的区别：JSON 是数据格式，XML 是标记语言。JSON 直接表达对象、数组、字符串，XML 用标签包裹数据，更侧重文档结构。// JSON{ "name": "张三", "age": 30 }<!-- XML --><person> <name>张三</name> <age>30</age></person>JSON 的优势：更轻量、解析更快（JSON.parse vs DOM/SAX 解析）、天然映射 JS 对象、Schema 更简单。XML 仍有用的场景：需要属性+值+命名空间（SOAP 协议）、需要 DTD/Schema 验证、大量文档处理时 XPath/XSLT 更灵活。追问为什么 JSON 取代了 XML 做 Web API 的数据格式？两点：JS 生态的爆炸式增长（JSON 是 JS 原生支持的，XML 需要额外解析）和移动端的带宽敏感（JSON 更紧凑）。REST API + JSON 几乎成了标配。JSON 有什么缺点？不支持注释（JSONC 是变体）不支持日期类型（需转换成字符串或时间戳）浮点数精度问题（0.1 + 0.2 !== 0.3 在不同 JSON 解析器中处理不一致）没有二进制支持（Base64 编码后体积膨胀）XML 现在还用在哪？银行、政府系统（SOAP 协议）Office 文档格式（docx、xlsx 本质上是 XML 的 ZIP 包）SVG 图像Android 布局文件RSS/Atom 订阅

TCP 三次握手建立连接：客户端 → SYN：客户端发 SYN=1，seq=x（随机初始序列号）。客户端进入 SYN-SENT 状态服务端 → SYN+ACK：服务端回 SYN=1，ACK=1，seq=y，ack=x+1。服务端进入 SYN-RCVD 状态客户端 → ACK：客户端发 ACK=1，seq=x+1，ack=y+1。双方进入 ESTABLISHED 状态为什么是三次不是两次？因为要防止已失效的连接请求到达服务端。如果只有两次，客户端发了一个 SYN 因为网络延迟没到，客户端超时重发了一个新的 SYN 建立了连接。之后旧的 SYN 到达服务端，服务端以为这是新连接，回 SYN+ACK 就建立了连接——但客户端根本不知道这个连接的存在。追问为什么不是四次握手？理论上四次（SYN → SYN+ACK → ACK → 服务端收到 ACK 确认）更稳妥。但第三步的 ACK 可以和服务端收到 ACK 合并——服务端只需要知道客户端收到了自己的 SYN+ACK 就够。额外的第四次是冗余的。SYN 泛洪攻击是什么？攻击者发送大量 SYN 但不回 ACK，导致服务端大量连接处于 SYN-RCVD 半连接状态，耗尽服务端资源。防御：SYN Cookie（服务端不分配资源，用 Cookie 验证客户端是真的）、减少 SYN-RCVD 超时时间。TCP 四次挥手为什么多一次？因为 TCP 是全双工的——每个方向都要独立关闭。客户端 FIN 表示"我说完了"，服务端 ACK 表示"知道了"，但如果服务端还有数据要发，发完后再 FIN。所以是 FIN → ACK → FIN → ACK 四步。