前端面试题手册

三个阶段的异步方案，层层递进：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 四步。

Chrome 是多进程架构，主要进程：Browser 进程（1 个）：主进程，管 UI（地址栏、书签）、网络请求、文件访问。协调其他进程。Renderer 进程（每个标签页一个）：渲染页面内容（HTML、CSS、JS）。沙箱隔离，一个页面崩不影响其他页面。GPU 进程（1 个）：处理 GPU 任务（CSS 3D 变换、WebGL、视频解码）。Plugin 进程（按需）：隔离运行的插件（Flash 等，现已很少）。Network 进程（1 个，较新版本）：独立的网络进程。Utility 进程（按需）：音频、扩展等。同一站点（same-site）的标签页可能共享 Renderer 进程以节省内存。具体数量取决于你开了多少标签页、多少扩展。追问为什么 Chrome 用多进程而不是多线程？稳定性和安全性。如果一个标签页崩溃或卡死，只影响那个 Renderer 进程，不会拖垮整个浏览器。沙箱机制也只限制单进程的权限。缺点是内存占用高，所以 Chrome 引入了进程共享（同一站点共享 Renderer 进程）。Renderer 进程里是什么？Renderer 进程包含：主线程（JS 执行、样式计算、布局）、合成线程（处理滚动、动画）、Raster 线程（将绘制命令转成位图）、Worker 线程等。主线程阻塞是页面卡顿的主要原因。内存不够时 Chrome 会怎么做？Chrome 会动态管理：冻结后台标签页的进程（节省内存）、优先杀掉非活动标签页的 Renderer 进程、同一站点合用一个 Renderer 进程。开大量标签页时内存压力还是很大。

同源策略是浏览器最核心的安全机制——限制一个源（协议+域名+端口都相同）的脚本去访问另一个源的资源。没有同源限制会怎样？你打开了 bank.com 登录了，另一个标签页打开了 evil.com。evil.com 的 JS 可以直接用 fetch 发请求到 bank.com/api/transfer——浏览器会自动带上你的登录 cookie，钱就转走了。同源策略阻止了这个。同源限制主要限制：1) AJAX 跨域请求；2) 跨 iframe/窗口的 DOM 操作；3) localStorage/Cookie 的跨域访问。跨域解决方案：CORS（服务端设 Access-Control-Allow-Origin）、JSONP（老方法，利用 script 标签不受同源限制）、代理（同源服务端转发）。追问为什么 script/img 标签不受同源限制？这是历史原因和功能需求——网页需要加载 CDN 上的脚本和图片。但 <script> 加载完会以当前域执行（所以有 XSS 风险），<img> 只能渲染不能读取像素数据（防止窃取）。资源加载的宽松和 API 访问的严格是两个层面的事。同源策略能防止 CSRF 吗？不完全能。CSRF 的请求能发出去（form 提交、img 加载都可以跨域），同源策略只阻止 JS 读响应。防止 CSRF 得靠 CSRF Token 或 SameSite Cookie。跨域请求发出去但响应被拦截，服务端收到请求了吗？收到了。浏览器是收到响应后发现没有 CORS 头才拦截的。所以服务端需要用 CORS 头来控制，不能用"浏览器会拦截"来保护服务端。

Vue 3 Composition API 中，setup 里没有 this。要获取组件实例相关的能力，用对应的 API 而不是拿整个实例：获取 DOM 元素：const el = ref(null) + ref="el" 绑定，通过 el.value 访问获取路由实例：const router = useRouter(); const route = useRoute()获取 store：const store = useStore()（Pinia 或 Vuex 4）需要组件内部数据：直接在 setup 里定义 ref/reactive 并 return，模板可直接访问需要父组件数据：defineProps + defineEmits如果非拿实例不可（极少场景），Vue 3 提供了 getCurrentInstance()：import { getCurrentInstance } from 'vue';const instance = getCurrentInstance();// instance.proxy 近似 Vue 2 的 this但官方不推荐依赖它，内部实现在版本间可能变化。追问Vue 3 为什么不给 this？Composition API 设计目标是函数式、可复用、类型推导友好。this 会绑定上下文，函数提取出去 this 就丢了。而 ref/reactive 是普通的 JS 值/对象，可以自由传递不丢失响应性。template ref 和 document.getElementById 怎么选？template ref 是 Vue 的方式——能保证在组件挂载后拿到元素，且不同组件实例互不干扰。document.getElementById 能拿到但可能拿到错误组件的元素（同页面多实例时），也不符合 Vue 的数据驱动理念。getCurrentInstance 在 setup 外能用吗？不能在 setup 外调用（如生命周期钩子的回调外）。它只在 setup 同步执行期间有效，异步回调里拿到的可能是 null。

双向绑定 = 数据变化自动更新视图 + 用户输入自动更新数据。最典型的场景就是 <input v-model="msg">——你修改 input 的值，msg 跟着变；JS 里改 msg，input 显示跟着变。Vue 2 用 Object.defineProperty 劫持对象属性的 getter/setter 实现数据 → 视图的响应式，用 v-model 监听 input 事件实现视图 → 数据的反向同步。Vue 3 换成了 Proxy，能拦截更多操作（属性增删、数组索引），不需要像 Vue 2 那样用 $set 手动处理新增属性。追问v-model 的本质是什么？v-model="msg" 是语法糖，等价于 :value="msg" + @input="msg = $event.target.value"。对于 checkbox 是 :checked + @change，对于 select 是 :value + @change。双向绑定和单向数据流矛盾吗？不矛盾。Vue 仍然是单向数据流（父 → 子通过 props，子 → 父通过 emit）。v-model 只是父子通信的一种语法糖，本质上还是 prop + event 的模式。什么场景不适合用双向绑定？需要在赋值前做复杂转换的（用 computed + emit 更清晰）多个输入源同时修改一个数据的（容易互相覆盖）需要中间确认操作的（如提交时才正式更新）

浅拷贝只复制对象的第一层属性，如果属性值是引用类型（对象、数组），拷贝的是引用地址——修改拷贝会影响原对象。深拷贝递归复制所有层级，新旧对象完全独立。// 浅拷贝const obj = { a: 1, b: { c: 2 } };const shallow = { ...obj }; // 或 Object.assign({}, obj)shallow.b.c = 3;console.log(obj.b.c); // 3 — 原对象被影响！// 深拷贝const deep = JSON.parse(JSON.stringify(obj)); // 最简单的方式... 展开和 Object.assign 都只做浅拷贝。JSON.parse(JSON.stringify(...)) 能做深拷贝但有局限：无法处理 undefined、函数、Date、RegExp、循环引用。追问JSON 方式深拷贝有哪些坑？undefined、函数、Symbol 直接被丢弃NaN 和 Infinity 变成 nullDate 变成字符串RegExp 变成空对象 {}循环引用直接报错原型链丢失生产环境怎么实现深拷贝？structuredClone()（浏览器原生 API，支持循环引用、Date、Map、Set 等，但不支持函数和 DOM 节点）lodash 的 cloneDeep自己实现递归拷贝 + WeakMap 处理循环引用（面试手写题常考这个）手写深拷贝时循环引用怎么处理？用 WeakMap 缓存已拷贝过的对象。每次拷贝前检查是否已经拷贝过，如果拷贝过直接返回缓存值。

localStorage 是浏览器提供的持久化键值存储，数据不随页面关闭而清除。API 一共就 5 个方法和 1 个属性：setItem(key, value)：存数据。key 和 value 都是字符串。存对象需要用 JSON.stringifygetItem(key)：取数据。key 不存在返回 nullremoveItem(key)：删单个 keyclear()：清空所有数据（注意：清的是当前域名下的所有 localStorage）key(index)：按索引获取 key 名，用于遍历length：只读属性，返回存储的条目数存储对象的正确姿势：localStorage.setItem('user', JSON.stringify({ name: 'John', age: 30 }));const user = JSON.parse(localStorage.getItem('user'));追问localStorage 和 sessionStorage 有什么区别？生命周期：localStorage 永久存储，sessionStorage 关闭标签页就清除作用域：两者都是按域名隔离，但 sessionStorage 额外按标签页隔离API 完全一致localStorage 有什么限制？容量 5-10MB（不同浏览器不同）只能存字符串同步 API，大容量读写会阻塞主线程不能存敏感信息（明文存储，XSS 可直接读取）不支持过期时间，需要自己实现Cookie 和 localStorage 怎么选？需要随 HTTP 请求自动发送（如身份认证）→ Cookie纯前端存储、不随请求发送 → localStorage需要服务端可读 → Cookie（设置 HttpOnly 防止 XSS 读取）容量超过 4KB → localStorage（Cookie 限制 4KB）

核心原因：事件监听器持有 DOM 元素的引用，导致 DOM 元素被移除后无法被 GC 回收。具体链路：button.addEventListener('click', handler) 时，浏览器内部建立了 DOM元素 → handler 的引用关系你用 button.remove() 从 DOM 树移除按钮，但事件系统仍然保留着 handler 对 button 的引用如果 handler 又是闭包，引用着外层变量 → 整个闭包链上的变量都无法 GC多次重复后，内存中堆满了"已从 DOM 移出但无法回收的元素和函数"，这就是内存泄漏解决办法：移除 DOM 元素前调用 removeEventListener。button.removeEventListener('click', handler);button.remove();或者在不需要关心个别元素时，用事件委托——把事件绑在父元素上。追问现代浏览器还会因为不移除事件导致泄漏吗？IE 时代这个问题最严重（IE 的 JS 引擎和 DOM 使用不同的 GC，循环引用是死穴）。现代浏览器的标记清除 GC 大部分循环引用能处理，但事件监听器 + 闭包的组合仍然会让本应被回收的对象变成"可达"——技术上不是传统意义的泄漏，但效果一样：内存释放不了。事件委托能解决这个问题吗？能。事件委托只绑一个监听器在父元素上，子元素增删都不需要管理事件。而且性能更好（减少监听器数量）。唯一注意：focus、blur、mouseenter、mouseleave 这些不冒泡的事件不能用委托。怎么在 DevTools 中排查内存泄漏？Performance 面板录一段操作，看 JS Heap 是否持续上升不回落 → Memory 面板取 Heap Snapshot，对比操作前后，看 Detached DOM 节点数量和 @ 引用关系。

setTimeout 和 setInterval 的执行时间不是精确的，根本原因就一条：JavaScript 是单线程的，定时器回调必须等主线程空闲才能执行。比如你设置 setTimeout(fn, 10)，但此时主线程有个耗时 100ms 的计算任务在执行——fn 最早也要等 100ms 后才能跑，10ms 只是"最早执行时间"，不是"准时执行时间"。其他影响因素：浏览器最小延迟：嵌套 5 次以上的 setTimeout 强制最小 4ms 间隔，后台标签页可能被降低到 1000ms事件循环优先级：微任务（Promise）比宏任务（定时器）优先执行GC 暂停：垃圾回收会短暂阻塞主线程追问需要精确计时怎么办？短时间精度：用 performance.now() 获取微秒级时间戳，自己在 requestAnimationFrame 里判断时间长时间精度：用 Web Worker（独立线程，不会被主线程阻塞），Worker 里用 setTimeout 相对更准音频场景：用 AudioContext.currentTime，这个不受主线程影响requestAnimationFrame 比 setInterval 更精确吗？rAF 本身也不是计时工具——它是"在浏览器下一次重绘前执行"，频率取决于刷新率（60Hz 约 16.67ms）。它的优势是自动与渲染同步，不会做无效的更新。但作为定时器，它也有偏差。

Object.defineProperty(obj, prop, descriptor) 让你精确控制对象属性的行为——是否可写、可枚举、可配置，还能定义 getter/setter。const obj = {};Object.defineProperty(obj, 'name', { value: '张三', writable: false, // 不可修改 enumerable: true, // for...in 可遍历 configurable: false // 不可删除、不可再次配置});核心价值在于拦截属性的读写。Vue 2 的响应式系统就是用 Object.defineProperty 劫持对象属性的 getter/setter，才能在数据变化时通知视图更新。追问defineProperty 和直接赋值有什么区别？直接赋值 obj.x = 1 创建的属性，writable、enumerable、configurable 默认都是 true，get/set 是 undefined。defineProperty 创建的属性，不显式指定的描述符默认都是 false。Vue 3 为什么换成 Proxy？defineProperty 有硬伤：无法检测属性的添加/删除（所以 Vue 2 需要 $set、$delete），对数组索引和 length 的拦截有坑。Proxy 能拦截 13 种操作，包括属性增删、in、delete、apply，不需要遍历对象属性递归劫持。什么场景下需要把属性设成不可枚举？给原型添加方法时（不想污染 for...in）框架内部属性（如 Vue 的 __ob__）任何不希望被 JSON.stringify 序列化或被 Object.keys 返回的属性

CSRF（跨站请求伪造）的攻击逻辑很简单：利用用户在其他网站已登录的身份，伪造请求执行非授权操作。典型场景：你登录了银行网站，cookie 还在。这时你打开了攻击者的网页，里面有一张隐藏的图片 <img src="https://bank.com/transfer?to=attacker&amount=10000">。浏览器加载这张"图片"时，自动带上了你的银行 cookie，银行收到请求以为是你的操作，转账就发生了。关键在于：浏览器发跨站请求会自动带上目标域名的 cookie——这是浏览器的默认行为。防御方式：Anti-CSRF Token：服务端生成随机 token，表单提交时带上，服务端验证。攻击者无法获取这个 tokenSameSite Cookie：Set-Cookie: SameSite=Strict，告诉浏览器跨站请求不要带这个 cookie。这是现代浏览器的标配方案Referer/Origin 检查：服务端验证请求来源，合法的请求才处理二次验证：关键操作（转账、改密码）要求重新输入密码或验证码追问CSRF 和 XSS 有什么区别？XSS 是在用户浏览器里执行恶意 JS（利用了网站对输入的信任），CSRF 是伪造用户的请求（利用了网站对浏览器身份的信任）。一句话：XSS 是"偷你的权限"，CSRF 是"借用你的身份"。SameSite 三个值分别什么意思？Strict：任何跨站请求都不带 cookie，最安全。但用户从外部链接点进来是未登录状态Lax：大部分跨站请求不带 cookie，但"安全"的 GET 请求（如 <a> 链接点击）会带。兼顾安全和体验None：和以前一样，跨站请求都带 cookie，但必须同时设置 Secure（仅 HTTPS）Anti-CSRF Token 怎么防止攻击者自己获取一个 token？token 绑定到用户 session，攻击者拿到的 token 是绑给他自己的 session 的，放到跨站请求里服务端一对不上就拒了。关键不是"token 不能被获取"，而是"token 和用户 session 绑定"。