面试题手册

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 更清晰）多个输入源同时修改一个数据的（容易互相覆盖）需要中间确认操作的（如提交时才正式更新）

Flexbox（弹性盒布局）是一维布局模型，控制元素在一条轴（主轴或交叉轴）上的排列和对齐。设 display: flex 后，容器变成弹性容器，子元素变成弹性项目。核心概念：主轴（flex-direction 决定方向）和交叉轴容器属性：justify-content（主轴对齐）、align-items（交叉轴对齐）、flex-wrap（换行）、gap（间距）项目属性：flex-grow（放大比例）、flex-shrink（缩小比例）、flex-basis（基础大小）、align-self（单独对齐）最常用的三件套：display: flex; justify-content: center; align-items: center; —— 一行代码实现水平垂直居中。追问flex: 1 是什么意思？flex: 1 = flex-grow: 1; flex-shrink: 1; flex-basis: 0%。表示元素按比例瓜分剩余空间，常用于等分布局。flex: auto 不同在于 flex-basis: auto（先看元素自身尺寸再瓜分剩余空间）。Flexbox 和 Grid 什么时候用哪个？Flexbox 是一维的，适合组件内部排列（导航栏、按钮组、表单行）。Grid 是二维的，适合页面级布局（一行多列、复杂网格）。实际项目混用居多：Grid 做页面骨架，Flexbox 做组件内部。为什么 flex 子元素设置 width 有时不生效？flex-shrink 默认是 1，空间不够时项目会被压缩。加上 flex-shrink: 0 或 min-width: <你的宽度> 阻止收缩即可。

浅拷贝只复制对象的第一层属性，如果属性值是引用类型（对象、数组），拷贝的是引用地址——修改拷贝会影响原对象。深拷贝递归复制所有层级，新旧对象完全独立。// 浅拷贝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 绑定"。

XSS（跨站脚本攻击）的本质是攻击者把自己的 JS 代码注入到你的网页里，在真实用户的浏览器上执行。能做的坏事包括：偷 cookie、篡改页面内容、劫持用户操作。三种类型：存储型：恶意脚本存到了服务器（数据库、评论、留言），用户访问页面时被返回执行。危害最大，不需要诱导点击。反射型：恶意脚本放在 URL 参数里，服务器直接拼到响应页面中。需要诱导用户点击构造好的链接。DOM 型：纯客户端问题——前端 JS 把 URL 参数或用户输入直接用 innerHTML 插到 DOM 里，没有经过后端。防御三件套：输出转义：所有用户输入在输出到 HTML 前做转义（< → < 等），不信任任何用户数据CSP（内容安全策略）：HTTP 头告诉浏览器只允许执行特定来源的脚本HttpOnly Cookie：关键 cookie 标记 HttpOnly，JS 读不到，即使被 XSS 也偷不走追问XSS 和 CSRF 有什么区别？XSS 是在受害者浏览器里执行恶意 JS，利用的是对网站的信任。CSRF 是诱导受害者发请求到已登录的网站，利用的是网站对浏览器的信任。CSP 怎么配置？Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-xxx'。核心思想：白名单机制，不在白名单里的脚本一律不执行。但 CSP 配置需要充分测试，容易把正常功能挡掉。富文本编辑器怎么防 XSS？不能用简单的转义（会把格式也干掉）。正确做法：白名单过滤标签和属性（如 DOMPurify），只允许 <b>、<i>、<a> 等安全的标签，移除 onclick、onerror 等事件处理器和 javascript: 协议。