第一篇：React 组件通信的底层逻辑
今天面试一个两年经验的 React 开发，简历写着熟悉 hooks 与状态管理。我问 React 中兄弟组件怎么共享状态，他答 props 层层传或者用 context。我追问 props 传多层有什么问题，context 直接把状态放在 provider 里有什么陷阱，如何让 context 实现按需更新——他逐渐含糊，最后卡在如何避免无关组件重渲染上。这就是典型的知道多种方式，却不理解使用场景。
下面用四个层次把 React 组件通信的底层逻辑讲透。
本质一：props 与回调——最基础的父子通信
父传子靠 props，子传父靠回调，数据流单向可追踪。一旦跨越多层，中间组件被迫转发自身不需要的 props，造成"props 钻孔"，代码冗余耦合，严重时牵一发动全身。
本质二：context 解决跨层传递，但自带性能陷阱
context 让祖先直接向所有子孙提供数据，绕过中间组件。但直接把状态对象塞进 provider 会带来性能问题——只要 provider 的 value 引用变化，所有消费该 context 的组件都会重渲染，即使只用了其中一部分数据。
要做到按需更新，必须拆分 context，按领域分割或用 useMemo 稳定引用，并结合状态管理思想，让组件只订阅自己关心的字段。这正是面试官追问"怎么实现细粒度更新"的关键。
本质三：状态管理库——比 context 更专业的全局共享
context 有三个局限：无法跨非父子树共享（如跨路由）、与组件生命周期强绑定、大规模应用下调试困难、性能难以控制。
Zustand、Redux Toolkit 这类外部库，本质是在 React 之外创建独立的响应式存储，通过发布-订阅让组件精确订阅部分状态，从机制上避免无关渲染。它们不需要 provider，核心是选择器加不可变更新——改一个字段，只更新用到它的组件。
面试问"为什么 Zustand 不需要 provider"，考察的正是对 React 内外状态分离的理解。
本质四：其他通信配角
事件总线（如 mitt）适合极简单的跨组件通知，但在大型项目里难以追踪数据流，容易内存泄漏，已不推荐。ref 透传（forwardRef + useImperativeHandle）适合父组件主动调用子组件方法，但本质上仍是命令式，应少用。组合模式（render props / 插槽）可以把控制权反转，减少 props 钻孔，是设计层面的解法。
灵魂总结
下次面试官问 React 组件通信，你可以这样答：父子通信用 props 加回调，保证单向数据流；爷孙跨层级用 context，但必须配合拆分与 memo 控制渲染；全局状态用 Zustand 或 Redux Toolkit 实现精确订阅，摆脱 context 性能枷锁；透传与命令式场景用 ref 或事件总线，但要克制使用。达到这层，offer 自然到手。
第二篇：微前端 JS 隔离的完整答案
面试一个五年前端，简历写着主导过大型微前端架构落地，精通 JS 沙箱与隔离机制。我问 qiankun 到底是怎么做 JS 隔离的，他反应很快：主要靠快照沙箱和代理沙箱。快照沙箱是激活时记录 window 当前状态，失活时对比差异并恢复，适用于单实例场景；代理沙箱通过 Proxy 为每个子应用创建独立的全局对象代理，多实例也不会互相污染。
我点点头，继续追问——快照沙箱在遍历 window 所有可枚举属性时，如果属性数量很大，或者有不可枚举的原生属性没被记录，你怎么应对？快照的深拷贝开销会不会直接让应用切换掉帧？代理沙箱用 Proxy 拦截了全局变量的读写，但子应用如果绕过代理，比如直接调用 eval、用 Function 构造器执行代码，这些变量能落到沙箱对象上吗？
他开始调整坐姿——这就是 2026 年能把 JS 隔离说透的前端，脑子里必须铺好的三层体系。
第一层：快照与代理，解决全局变量污染
2026 年 qiankun 依旧会提供 SnapshotSandbox 和 ProxySandbox，但面试及格线不再是能说出名字，而是能指出各自的硬伤。
快照沙箱必须配套惰性遍历和属性变更记录，避免激活失活时全量遍历造成性能预算崩溃。代理沙箱要把原生全局对象拆成共享只读层和独立读写层，让 document、console 等公共设施稳定共享，window、global state 等完全隔离。
但光这一层只能拦截显式属性读写，防不住更底层的逃逸。
第二层：逃逸防御与副作用回收
任何沙箱，如果不处理 eval、new Function、setTimeout 字符串形式、事件绑定、MutationObserver，就等于开着后门。
2026 年的标准要求，必须对子应用代码做编译时包裹或运行时替换原生 API，把定时器和事件注册全部重定向到沙箱的上下文里，激活时注册，失活时自动回收，不依赖子应用自己清理。原型链污染要有兜底：快照失活时逐条对比恢复，必要时冻结原型方法。所有清理逻辑超过 10ms 就异步分片，保证切换不卡顿。
第三层：原生执行域隔离，彻底推翻重来
到了 2026 年，真正的隔离不再靠打补丁式的 Proxy，而是直接使用浏览器原生的 Shadow Realm API。Shadow Realm 给每个子应用提供完全独立的全局对象，独立的内建模块，变量逃逸、原型链污染、包泄漏从机制上就不可能发生。
qiankun 等微前端框架在这一层会把沙箱策略改为优先 Shadow Realm 隔离，降级为 Proxy 沙箱，用特性检测自动分流。即使是必须共享 DOM 的场景，也通过 API 传递最小化的操作能力，子应用无法触碰主应用的任何上下文。
总结
很多人遇到 JS 隔离的问题，只会说"做一个 Proxy 代理 window"。真正的大厂思维是，你要像设计多租户操作系统一样，把全局变量、执行域、副作用回收、执行性能监控全串成一条链路。用户切走应用的那一刻，所有副作用必须消失，像那个应用从没运行过一样。这才是 2026 年微前端 JS 隔离的完整答案。
第三篇：跨域携带 Cookie 的死胡同与新方案
面试一个候选人，题目是跨域携带 Cookie，他回答：前端设置 withCredentials，后端返回 Access-Control-Allow-Origin 不能用通配符，再加上 Access-Control-Allow-Credentials: true，这样 cookie 就能自动带过去。
面试官笑了一下："你把题听完。"题目里两个域名完全不一样，无法共享 cookie domain 配置。他慌了，说 SameSite 设为 None 再配上 Secure 就可以了。
面试官继续加压：就算你把 cookie 设为 SameSite=None; Secure，浏览器 cookie 的归属只看请求目标域名，不看你页面来自哪。更关键的是，在 2026 年，Chrome 已经彻底禁用第三方 cookie，Firefox、Safari 的完全分区 cookie 也进入强制执行阶段，这些方案全部失效。
本质一：先搞清楚 cookie 怎么才能被带走
浏览器是否在请求中携带某个 cookie，需要满足三个条件：cookie 归属的 domain 与请求 URL 的主机是否匹配；路径是否匹配；SameSite 策略是否允许跨站发送。这是同源策略的根基，不是配置能绕开的本质。
本质二：2026 年早就没有真正意义上的第三方 cookie
2024 年起，Chrome 开始逐步淘汰第三方 cookie，到 2026 年，所有主流浏览器默认禁止跨站上下文中的 cookie 发送，SameSite 的默认值强行变为 Lax。因此跨域请求里带另一个域的 cookie，从前端角度看已经是一条死胡同，必须改造凭据传递架构。
本质三：新方案落地——从靠浏览器自动带 cookie 转向应用层显式授权
2026 年实际可行的三条路径：
BFF 令牌中转模式：前端只与自身域名的 BFF 通信，后端以服务端身份把所有需要的 cookie 或 token 拼装进请求头，这是最稳定的工程方案，彻底绕开浏览器限制。
FedCM 联合身份认证：利用 Federated Credential Management API，在用户授权下完成身份凭证的跨站传递，前端将获得的 id token 显式注入后续请求头，这是 W3C 推荐的隐私保护替代标准。
Related Website Sets 分区 cookie：可以注册为关联网站集合，浏览器允许在集合内跨站共享，但仍然受分区绑定限制，不能被真正的外部站点读取。
本质四：代码之外的工程决策力
面试官听的绝不是你怎么用 withCredentials，而是看你有没有从浏览器自动行为升级到应用层凭据管理的架构视野。高分回答背后是四层判断：识别需求本质、判断可行性、选择替代方案、兜底安全设计（防止 CSRF、token 过期同步登出、清理全局状态）。跨域带 cookie 不是调 API，而是一次安全边界的设计。
第四篇：百万任务不卡顿的浏览器调度体系
面试一个五年前端，简历写着主导过千万级数据可视化项目，前端性能优化经验丰富。我开门见山：一个页面需要执行 100 万个任务，怎么保证浏览器不卡顿？
他答：用时间分片，把任务拆成小块，每执行一小段就让出主线程，用 requestIdleCallback 或 setTimeout 控制。思路没问题，但我继续追问：如果这 100 万个任务里有 30 万个必须操作 DOM，分片过程中用户还在疯狂滚动点击，怎么保证每次让出主线程后交互事件能立即得到响应？如果任务有三类优先级，时间分片怎么保证高优任务永远不被低优任务阻塞？分片时长怎么定？写死的阈值在低端机上照样卡，在高端机上又浪费……
这道题表面是在问分片技巧，本质考的是对浏览器调度机制的系统理解。
第一层：任务分片与优先级调度
不再依赖 setTimeout、requestIdleCallback 这种赌空闲的原始手段。2026 年的标准答案是使用浏览器原生调度 API scheduler.postTask()，把任务按用户阻塞、用户可见、后台三级优先级写入原生调度队列，浏览器会根据当前帧的剩余时间、用户是否正在交互自动安排执行顺序。高优任务不会被低优卡住，低优任务也不会无限期饿死，因为调度器内部已经内置了超时提升机制。
分片时长也不写死，而是配合 scheduler.isInputPending() 动态检测，一旦检测到用户有输入，立刻让渡控制权，保证交互零延迟。
第二层：渐进式 Worker 与职责分离
纯计算（排序、转换等）任务全部下沉到 Web Worker，且不会每来一个任务就新建一个 worker，而是封装成常驻 worker 线程池。对于必须操作 DOM 的环节，把计算逻辑留在 worker，把最终最小化的 DOM 更新指令传回主线程，在主线程里用 requestAnimationFrame 集中批量提交，确保每一帧只做最轻量的渲染变更。对于 canvas 图表这类重绘场景，全面迁移到 OffscreenCanvas，让 worker 直接绘制，主线程彻底解放。
第三层：自适应性能监控与防裂化
用 PerformanceObserver 长任务监控，一旦连续两个长任务超过 50ms 且伴随交互延迟，就自动降级：临时拉长分片间隔、降低单次任务执行数量、将部分低优任务直接退到后台线程。同时建立任务老化计数器，任何低优任务等待超过一定时长（如三秒）自动提升优先级。内存侧也要防止任务包和中间对象的指数级堆积，采用分批释放和复用对象的策略，保证内存曲线平稳。
总结
很多人遇到百万任务的问题，只会说"拆一下任务，让让主线程就好了"。但真正的大厂思维是，要像设计高速公路调控系统一样，把优先级、自适应降级、职责分离、原生调度能力全部串联起来。浏览器给你的每一帧只有 16ms，你要确保在这 16ms 里，最高优先级的任务一定是用户正在触摸的那个像素，而不是一行三个月没人看的日志。
第五篇：白屏排查的系统性诊断流程
面试一个自称对前端性能与稳定性有深度实践的三年前端工程师。我问：用户打开你们产品页面白屏了，可能的原因有哪些，你从哪几步入手排查？他回答可能是网络问题、JS 报错或者接口挂了，按下 F12 看控制台和网络面板，刷新一下看看。
我追问：如果控制台没报错、网络请求也都 200，页面依然白屏，怎么定位？如果白屏是偶发的，只在特定网络环境出现，你怎么复现？如果是服务端渲染的页面，服务端返回了 HTML 但浏览器什么都没渲染，排查路径有区别吗？他思路明显碎片化。
真正的白屏排查不是打开控制台看一眼，它是一套从网络链路到渲染完成的系统性诊断流程。
第一层：基础信息确认
检查页面是否完全空白还是有部分骨架或 loading；看控制台有没有红错、网络请求有无失败或 pending；确认 HTML 文档是否成功返回、文档标题是否正常显示；清缓存、禁用扩展、切换浏览器复现。但要注意 2026 年 Chrome 默认分区缓存、第三方 cookie 逐步淘汰，这些基础检查可能掩盖真实原因。
第二层：链路与资源诊断
DNS 与 CDN 层面：使用 DNS 预解析命中率检测，排查特定地区递归解析失败；检查 CDN 回源策略，边缘节点是否缓存了错误的空响应。请求与响应层面：关键 CSS/JS 是否被拦截或返回 204/304 但内容为空；检查 103 Early Hints 是否提前推送了错误资源；服务端返回的 HTML 中是否因内容安全策略导致所有脚本被阻断。资源加载时序：使用 Performance API 或现代 RUM 工具看 first paint、FCP 是否一直没触发，区分是 HTML 解析阻塞还是关键子资源加载超时。
第三层：渲染与脚本执行层
脚本执行异常：某个 JS 模块抛出未被捕获的 Promise 异常导致后续脚本停止；动态导入的 chunk 因 SRI 完整性校验失败而被拒绝执行；2026 年常见 Web Component 注册失败导致自定义元素不渲染但无显示报错。样式与布局问题：所有内容颜色与背景色相同；根元素被 CSS 强制 display:none 或 visibility:hidden；容器高度为零内部元素被裁剪。框架渲染边界：React 或 Vue 的根组件挂载点被移除或未找到；SSR 注水时内容不匹配，导致客户端丢弃服务端 HTML；流式渲染中断，部分区块永远停留在占位。
第四层：工程化与可观测性兜底
主动探测与告警：在页面关键生命周期埋点上报白屏事件，记录 DOMContentLoaded、load 事件是否触发，记录首次渲染时间戳，若超过阈值且无内容自动上报。真实用户监控（RUM）：区分白屏是由网络还是渲染引起。自动降级与恢复：检测到白屏后，自动尝试降级到纯静态备用版本，使用本地缓存渲染上一次成功的内容，同时异步重试，对关键模块做边缘 Worker 兜底。弱网与离线策略：利用 Navigation API 和网络信息 API 预判为 2G/3G 时直接走极简骨架，启用 stale-while-revalidate 策略优先展示缓存内容。
总结
这道题考的是从用户输入 URL 到像素渲染的全链路理解，考的是对网络、资源、脚本、样式、框架、监控的交叉诊断能力。只会按 F12 看红错的人只能解决 60% 的明显问题，能分层、能降级、能用现代可观测性工具定位偶发白屏的人，才是 2026 年真正合格的资深前端。
第六篇：健壮的并发请求方案设计
面试场景：页面需要同时请求用户画像、商品库存、广告位配置三个接口，用 Promise.all。如果广告位接口挂了，会导致整个 Promise.all 失败，用户画像和商品库存也出不来了。如何设计一个更健壮的并发请求方案？
很多人说用三个 try-catch 分别请求，这完全放弃了并发优势，性能倒退。高级的异步控制需要掌握以下工具和模式。
一、Promise.allSettled——ES2020 的答案
它等所有 Promise 都安顿（无论成功失败）后返回结果数组，让你能单独处理每个结果的状态（fulfilled 或 rejected）和值或原因。
二、手工实现软失败
用 Promise 包裹一层，对每个单独 Promise 的失败进行捕获，让单个 Promise 失败时返回一个约定的默认值或标记，然后在最终结果里过滤或补偿这些失败项，从而避免整体崩溃。
三、更精细的调度与超时控制
用 Promise.race 给每个请求加上超时限制，配合 AbortController 实现超时后主动中断；用异步池等模式控制并发数量，防止瞬间发起上百个请求；同时结合重试策略提升鲁棒性。
总结
这道题考的是对 Promise 并发模型缺陷的认知，以及利用语言新特性和设计模式解决问题的能力，是从功能实现到生产环境鲁棒性的思维跃迁。
第七篇：微应用跨应用通信容错的四层防线
面试一个两年前端，简历写着精通微应用架构与跨应用通信。我问微应用跨应用通信故障怎么做容错处理，他张口就来：加个重试，返回默认数据，隐藏报错模块就行。
我接着问：父子应用通信、兄弟应用通信、跨应用状态同步、跨应用 API 调用，分别怎么降级？基座故障、跨应用权限校验失败、弱网环境怎么兜底？批量通信失败怎么避免应用级崩溃？
跨应用通信容错根本不是加个重试就完事了，它是微应用架构稳定性的核心防线。
第一层：基础兜底（初级会）
通信失败基础重试、默认数据兜底返回、简单 try-catch 捕获通信异常、报错模块隐藏。但你知道微应用跨域通信失败时 error 事件不触发，该怎么处理吗？
第二层：分类降级（三年经验必懂）
父子应用通信降级：postMessage 备选通道，frame 直连兜底。兄弟应用通信降级：本地存储临时同步，基座中转降级。跨应用状态同步降级：快照恢复核心状态，本地缓存兜底。跨应用 API 调用降级：mock 静态数据，核心功能降级离线模式。
第三层：工程化兜底（真功夫）
基座故障：备用基座地址配置、重试策略加指数退避、静态基座降级。跨应用权限校验失败：降级匿名通信通道，核心功能权限豁免。批量通信失败：通信池资源管理、失败频次统计、自动熔断机制。路由级降级：通信故障直接跳转静态降级页，核心功能独立页面。
第四层：监控与体验（触及用户体验）
通信故障上报监控：通信延迟、成功率异常实时报警。基座健康度监测。弱网优化：自动切换轻量通信协议，非核心通信延迟执行，关键通信优先通道。用户无感知加载过渡状态，友好报错提示，核心功能骨架屏操作重试引导。
总结
同样一个跨应用通信故障，有人只会写基础重试，有人能做到全场景容错、监控自愈。这就是高级前端和普通开发的区别。
第八篇：useOptimistic 核心原理深度解析
今天面试一个三年 React 经验的开发者，简历写着熟练使用 React 19+ 新特性，掌握乐观更新原理。我问：为什么 useOptimistic 不能在非用户交互场景调用？
他表达：因为乐观更新需要用户交互触发，避免状态回滚混乱。这是官方文档的表层结论。我继续追问底层是怎么实现状态回滚机制的，状态回滚时是怎么精准匹配到对应的乐观更新的，React Fiber 架构下乐观状态和真实状态是分开存储的吗，依赖什么数据结构关联……他开始支支吾吾。
本质一：useOptimistic 的底层存储——状态栈加版本标记
很多人以为 useOptimistic 是简单的临时替换状态，这是错的。React 19 架构下，每个使用 useOptimistic 的函数组件，其 Fiber 节点上有两个关键属性：optimisticStateStack（乐观状态栈，存储每次乐观更新的预期状态、版本号和回滚回调）和 currentVersion（当前版本标记，关联真实状态与乐观状态的对应关系）。
真实状态仍存储在 Fiber 节点的 memoizedState 中，乐观状态栈仅维护临时预期状态。每个栈元素都绑定唯一版本号，与触发源（用户交互）强关联。
为什么用栈加版本号而不是单一变量？支持连续乐观更新（比如快速点击两次提交），栈结构能保证回滚顺序可逆，版本号可精准匹配触发原乐观状态回滚操作，避免多次更新冲突。非交互场景缺少稳定触发源，无法生成唯一版本号，导致栈元素无法精准对应。
本质二：为什么不能在非用户交互场景调用
React 底层实现乐观更新的核心逻辑，依赖触发源上下文与版本号的绑定，而非单纯的状态替换。
用户交互场景（点击、输入触发时）会创建交互上下文，生成唯一递增的版本号，将乐观状态、版本号、回滚回调一起压入栈，同时更新组件显示乐观状态。非用户交互场景（组件挂载、数据请求回调）无交互上下文，版本号复用或随机生成，压入栈的乐观状态缺少唯一标识。
回滚时，React 会通过交互上下文找到对应的版本号，从栈中弹出该版本的乐观状态，恢复到上一个版本的真实状态。若在非用户交互场景多次调用，会导致版本号重复，栈中乐观状态与真实状态的对应关系断裂，回滚时无法通过版本号找到正确的撤销节点，可能恢复到错误的历史状态或导致状态永久不一致。
本质三：进阶追问
自定义 hook 里封装 useOptimistic，能在组件卸载时调用回滚吗？不行。组件卸载时 Fiber 节点已被标记为过期，optimisticStateStack 开始被回收，此时调用回滚函数会操作一部分回收的状态栈，导致内存泄漏或状态污染。
React 19.5+ 新增的 useOptimisticResource 允许手动传入自定义触发源上下文，通过手动生成稳定版本号，支持数据请求回调、定时任务等场景。但本质仍依赖版本号加上下文绑定，并非真正的无限制调用，只是放开了触发源的类型限制。
灵魂总结
useOptimistic 的使用限制不是 React 故意约束，而是乐观更新的状态回滚机制对触发源上下文的依赖决定的。React 不靠状态值区分乐观状态与真实状态，而是靠版本号加触发源上下文绑定——非交互场景破坏了这种绑定关系，导致状态一致性无法保证。
第九篇：Vite 为什么比 Webpack 快
面试一个精通工程化构建的五年前端，没问几句全露馅了。我问：Vite 为什么能比 Webpack 启动快这么多？他答：Vite 是新一代构建工具，Webpack 太老了，而且 Vite 用了 ES 模块，不用像 Webpack 那样打包，所以更快。
这些都是百度第一行就能搜到的废话。Webpack 要全量打包依赖才能启动，你知道为什么要全量打包吗？Vite 不用全量打包，核心原因是什么？
我直接打断：不用再说了，连构建核心原理的区别都搞不懂，要好意思说精通工程化构建。
先戳破 Webpack 打包的三个致命缺陷
一、启动需全量递归打包，项目越大启动耗时越长；二、热更新需全量重构模块，小改动也会损耗性能；三、依赖处理无原生 ESM 适配，需额外做兼容转换。
Vite 的四个核心优势
一、依托浏览器原生 ESM，无需启动全量打包，启动极快。 Vite 直接使用浏览器原生 ES 模块加载，启动时无需递归打包合并模块，所有依赖只编译当前页面所需内容。而 Webpack 需要启动时全量递归打包，项目越大，启动耗时越久。
二、热更新按需编译，仅更新改动模块，性能损耗极低。 Vite 热更新是重新编译修改的单个模块，无需全量重构。Webpack 热更新需要重新构建关联模块链，哪怕小改动也会产生明显性能损耗。
三、依赖预构建缓存，二次启动无需重复处理依赖。 Vite 会对第三方依赖做预构建并缓存，二次启动直接复用。Webpack 每次启动都要重新解析处理依赖，重复消耗性能。
四、原生适配现代浏览器 ESM 规范，模块化转换冗余少，扩展性更强。 Webpack 需要兼容多种模块化规范，冗余逻辑多，进一步拉低性能。
总结
Vite 比 Webpack 更快，核心是为了解决 Webpack 打包构建的底层缺陷，满足大型项目极速开发、高效热更新的需求。这才是专业的回答。
第十篇：首屏加载 100ms 级优化的五个核心模块
面试一个高级前端，简历上写着负责核心项目性能优化，首屏加载提速 60%。我问：让你优化一个复杂中后台系统的首屏加载，首次加载资源体积超 2MB，LCP 4.8 秒，怎么落地？
他答：图片懒加载、JS/CSS 压缩、路由懒加载，再用 CDN 加速。思路对，但关键渲染路径里阻塞 DOM 解析的外部脚本怎么处理？关键 CSS 和非关键 CSS 怎么拆分、拆分后怎么避免 FOUC？预加载 preload 和预连接 preconnect 怎么合理使用，会不会造成资源浪费？
首屏加载优化考察的不是压缩、懒加载这些关键词，而是工程化落地能力。
本质一：关键渲染路径（CRP）优化——不是指压缩，是减阻塞、优顺序
关键渲染路径是浏览器从接收 HTML 到渲染出首屏的核心流程。优化核心是减少阻塞资源，调整资源加载顺序：先识别关键资源（HTML、关键 CSS、核心 JS），移除延迟非关键资源，优化关键资源加载优先级。
具体做法：关键 CSS 内联到 HTML，避免额外请求；非关键 CSS 异步加载无阻塞；新 JS 按依赖关系拆分，必要时用模块联邦解决跨应用依赖，避免重复打包。
本质二：首屏资源优先级——preload 与 preconnect 的精准控制
按首屏必须、首屏非必需、后续页面分级管理：首屏必须资源（核心 JS、关键 CSS）用 preload 强制优先加载；跨域资源（CDN、接口域名）用 preconnect 提前建立 TCP 连接，减少 DNS 查询加 TCP 握手耗时；后续页面资源（路由主键、非首屏图片）用 prefetch 空闲时加载，不抢占首屏带宽。
本质三：弱网降级与容错——服务端适配加前端兜底
服务端根据网络类型（2G/3G/4G/5G）返回不同资源包，弱网返回轻量版组件、低分辨率图片，接口降级返回核心字段，非必需字段延迟加载。前端资源加载超时重试三次，失败后显示降级 UI（骨架屏不消失，提供重试加载按钮）。本地缓存核心静态资源，断网时展示离线可用内容。2026 年标准：Early Hints 加 103 状态码提前推送核心 CSS，避免白屏等待。
本质四：进阶考点——性能监控与持续迭代
接入性能监控工具（Lighthouse 加自定义埋点），监控核心指标 LCP、FID、CLS，设置告警阈值。关键资源采用按需加载加预加载动态平衡，根据用户行为数据调整预加载资源（高频访问的二级页面资源提前 prefetch）。图片资源自适应 WebP/AVIF 格式，加响应式尺寸，根据设备像素比和网络状况动态切换。接口优化：并行请求、合并数据、预取缓存策略，减少首屏接口请求数。
灵魂总结
下次面试官问你首屏加载优化，不要只说懒加载加压缩，要分层讲：关键渲染路径（内联关键 CSS、拆分核心 JS、减少阻塞资源）；资源优先级（preload、preconnect、prefetch 精准使用，不浪费带宽）；弱网降级（服务端资源适配加前端加载容错，保障极端环境体验）；持续优化（性能监控加数据驱动，动态调整优化策略）。首屏加载优化考的不是关键词，是工程落地能力——减阻塞、优顺序、强容错、可迭代，一个都不能少。
第十一篇：Vue3 与 React18 响应式更新机制深度对比
面试一个七年前端，简历写着熟练掌握 Vue3 和 React18，有大型项目性能调优与架构迁移经验。我问：假设你现在要自己实现一套框架响应式系统，一个组件里的基础值、嵌套对象、集合类型分别发生变化，Vue3 和 React18 的更新机制会怎么处理，哪个更精准高效？
他答：Vue3 是 Proxy 劫持，React 是状态快照，具体细节不太确定。这个回答就是典型的会用框架，但不懂框架。
前置知识：为什么需要细粒度响应式
没有细粒度劫持的框架会采用组件级全量更新策略——仅修改最内层一个字段，也会判定整个数据对象变更，触发组件全量重渲染。有细粒度劫持的框架仅识别单个字段变更，只更新依赖该字段的视图片段，无多余渲染。
React18 的状态更新机制：组件级快照加 Fiber 调度
React 的更新策略核心是组件级对比状态——引用变化则标记组件待更新。对于复杂状态，核心是不可变数据加自动批处理：状态修改后生成全新状态快照，不直接修改原数据，通过快照对比判断是否需要更新。React 18 会合并同步/异步任务内的多次状态变更为一次批处理，减少重复渲染，依靠 Fiber 调度实现可中断、可插队、可恢复的渲染流程。
但 React 始终是组件级响应式，无法感知对象内部单个字段的细粒度变化。只要状态引用改变，就会触发对应组件的渲染。嵌套对象仅改一个属性，React 会标记整个组件待更新，需要依赖 memo/useMemo/useCallback 等缓存 API 减少冗余渲染。
React 团队认为，细粒度响应式会大幅提升依赖追踪复杂度与内存占用；在大型工程中，不可变数据加组件级更新的模式更易维护，配合 Fiber 调度足以平衡性能与开发体验。
Vue3 的响应式机制：全类型劫持加精准依赖追踪
Vue3 采用全场景 Proxy 代理方案，搭配依赖收集与精准触发机制，这也是 Vue3 更新性能普遍优于 Vue2 的核心原因。
通过 Proxy 劫持对象的取值、赋值、删除、遍历等行为：取值时收集依赖该数据的视图与副作用，赋值时只触发对应依赖更新。对嵌套对象、数组、Map、Set 都能实现原生深度劫持，无需像 Vue2 一样手动兼容特殊场景。嵌套对象仅修改单个属性，Vue3 只更新该属性对应的视图部分，其余内容完全不参与渲染。
为什么 Vue2 要彻底替换为 Proxy？
Vue2 的 defineProperty 无法监听对象新增/删除属性、数组下标修改、长度变更，必须重写数组方法手动调用兼容 API，且无法原生支持 Map、Set 等复杂结构。完整性与扩展性远不如 Proxy。
第十二篇：刷新就好，不刷新就异常——渲染缺失问题三层防御
今天面了个四年前端。我给了个真实线上场景：新上线一个活动页，用户反馈页面刚打开时关键内容不渲染，部分模块直接空白，但刷新一下马上恢复正常。排查发现所有接口都是 200，没有报错，业务逻辑也正常执行。这种刷新就好、不刷新就异常的问题，可能是什么原因？
他答：让我看 network，看看资源和接口的加载时序。我继续追问：如果我告诉你静态资源和接口都加载成功，而且执行顺序也没问题，但用户就是第一次打开异常，你怎么解释？如果这个问题只在部分用户、部分手机上出现，你本地完全复现不了，你怎么保证以后不会再发生？他开始沉默。
这种问题表面是渲染缺失，本质其实是资源加载时序紊乱加首屏渲染触发时机过早。
第一层：构建阶段——资源一致性保障
资源版本控制：所有静态资源必须带 hash，避免 HTML 与异步资源版本不匹配导致渲染依赖缺失。缓存策略设计：入口 HTML 不启用强缓存，异步资源用强缓存讲 hash，保证整套资源版本统一。首屏依赖前置：核心渲染依赖资源优先加载，避免页面提前触发渲染却缺少必要支撑。
第二层：运行时渲染时机控制
渲染触发控制：核心依赖未加载完成前，禁止提前执行页面渲染，避免基于缺失依赖计算布局。异步渲染约束：按需加载模块时，必须保证依赖资源就绪后再挂载，防止局部渲染空白。初始化逻辑规范：避免在资源未就绪时频繁读取页面渲染状态，防止触发异常渲染逻辑。
第三层：异常兜底与监控机制
渲染异常检测：页面加载后校验核心模块是否正常渲染，异常时自动触发重渲染或展示降级内容。加载态兜底：在依赖未就绪前展示统一加载状态，避免用户看到空白或异常页面。监控上报：采集用户设备、资源版本、加载时序数据，出现异常自动上报，快速定位复现场景。
总结
很多人遇到这种问题，只会说"刷新一下就好了"。但真正的工程思维是：用户第一次看到的页面就必须是对的。
第十三篇：大文件分片上传与断点续传
昨天跟一位阿里前端面试官吃饭，他吐槽：现在面试根本不考花里胡哨的，能把大文件分片上传与断点续传说清楚的，二面直接问；说不清楚的，哪怕 Promise 背得再溜，也直接 pass。
今天面了个四年经验的前端，自称精通网络与性能优化。我问：用户要上传一个 2GB 的视频，网络可能随时中断，你怎么设计前端上传方案？
他答：用 FormData 发请求，加个进度条，再加个重置按钮。我追问：用户上传到 90%，突然断网，你那个重置按钮一按，从头开始传？他开始破防……
一、为什么直接上传会出问题
单次请求体过大，网关、浏览器可能限制；网络中断后需重新传，浪费带宽和时间；无法提供可靠的进度和续传体验。
二、三层优化方案
简易方案：整体上传加重试。 缺点：断网后从头开始，体验极差。
核心方案：分片上传加断点续传（大厂必答）。 前端将文件切成固定大小分片（如 1MB），并发上传分片（控制并发数，避免占满带宽）；服务端记录已收到的分片索引；每次上传前先询问已上传分片列表，只传缺失的。
进阶优化： 使用 requestIdleCallback 或 Web Worker 计算文件 hash，用于秒传；动态调整分片大小（网络好时用大分片，差时用小分片）；失败分片自动重试，且不阻塞其他分片。
三、断点续传核心原理
通过 Blob.prototype.slice 进行文件切片；上传前发送检测请求，拿到已上传分片列表；并发上传缺失分片，每个分片带序号和文件唯一标识；所有分片完成后通知服务端合并。
四、手写简易实现思路
选择文件，计算唯一标识（文件名加大小加最后修改时间，或用 spark-md5 算 hash）；服务端提供接口 GET /check?hash=xxx，返回已上传分片序号；客户端过滤出未上传分片，用 Promise.all 控制并发（比如三个一组）；每个分片上传失败后重试最多三次；全部完成后调用合并接口。
总结
阿里要的不是会用百度的 Web Uploader，而是能从分片、续传、并发控制、秒传机制讲清楚全链路，这才是 P6 到 P7 级别的前端网络优化能力。
第十四篇：浏览器渲染性能与动画卡顿排查
面试官：用户点击导航菜单，页面出现卡顿的过渡动画，怎么排查？候选人：减少 DOM 操作，用 CSS 动画代替 JS。面试官继续：你知不知道浏览器一帧里有几个步骤？重排和重绘的区别是什么？什么是 layout thrashing？2026 年 Google 力推的 View Transitions 和滚动驱动动画，你了解吗？
浏览器渲染性能是 2026 年前端面试的深水区，面试官想听的不是你会背重排重绘，而是从真实渲染流水线、强制同步布局到 2026 年最新优化手段的完整体系。
第一阶段：真实渲染流水线——重排、重绘、合成分类
浏览器的目标是 60FPS，每帧 16.6ms，一帧的流水线：JS 执行 → style 计算 → layout（重排）→ paint（重绘）→ composite（合成）。
重排（最贵）：改变 width、height、margin、padding、position、font-size，添加/删除 DOM，改变窗口大小。会触发 layout + paint + composite。
重绘（中等）：改变 color、background-color、visibility、border-style。触发 paint + composite。
合成（最便宜）：改变 transform、opacity、提升合成层后的 filter。只触发 composite。
关键原则：动画能用 transform、opacity 实现，绝不动几何属性。
第二阶段：强制同步布局——动画卡顿的第一杀手
在 JS 里先修改了样式（写），然后立即读取几何属性（读），浏览器被迫立即执行 layout，打断正常流水线。布局抖动（layout thrashing）：动画的每一帧都反复读写，每帧触发多次 layout，浏览器崩溃。
解决方案：读写分离加 requestAnimationFrame 批量处理。将所有读取几何属性的操作集中在动画开始前完成，运行时只修改合成层属性（如 transform）。必须同时读写时，用 requestAnimationFrame 将写操作安排在下一帧，保证一帧只做一次 layout。动画优先用 CSS transition/animation，让浏览器在合成器线程处理，不占用主线程。
第三阶段：合成层加 2026 年新增优化武器
浏览器将页面分成多个图层，每个图层独立绘制，最后合成。改变合成层属性（transform、opacity）只触发合成步骤。
如何创建合成层：设置 transform: translateZ(0) 或 will-change: transform；position: fixed/sticky；video、canvas、iframe 等元素。注意滥用合成层会报内存，will-change 要用在即将变化的元素上，用完移除。
2026 年新增优化点：
- View Transitions：单页应用页面切换的原生过渡 API，浏览器自动创建伪元素动画，完全绕过 JS 手动 DOM 操作触发的重排。
- 滚动驱动动画（Scroll-driven Animations）：通过 scroll timeline 让动画与滚动进度绑定，动画逻辑运行在合成器线程，不阻塞主线程。
- content-visibility: auto：配合动画，确保离屏内容不参与渲染计算，减少渲染负担。
灵魂总结
下次面试官问你页面动画卡顿怎么优化，要分层讲：真实流水线（JS → style → layout → paint → composite，记住 16.6ms 红线）；重排几何属性最贵、重绘外观中等、合成 transform/opacity 最便宜；强制同步布局（动画中先写后读，触发布局抖动，读写分离加优先使用 CSS 动画/过渡，必须用 JS 动画时采用 requestAnimationFrame 批量更新加只改合成属性）；合成层与 2026 新武器（will-change、View Transitions、Scroll-driven Animations、content-visibility: auto）；最后用 Performance 面板定位瓶颈。
大厂要的不是会用 Chrome DevTools，而是能从真实渲染原理出发，结合 2026 年最新 API，系统化定位和解决动画性能问题。
第十五篇：Vue 封装 Web Component 实现跨框架复用
昨天面了个简历写着精通 Vue 足见设计，熟悉前端新趋势的四年前端。我问 Vue 如何封装原生 Web Component，实现跨框架无侵入复用。
他答：跨框架组件不就是把 Vue 组件打包好，别的项目直接引入使用吗？多大点事。我当场笑出声——单纯打包引入会出现样式污染、响应式失联、生命周期不兼容，你怎么保证在 React、原生页面里都能正常运行，还不侵入宿主环境？
这是 2026 年前端面试的核心新趋势——跨端聚合页面、微前端整合、多技术栈共存项目全在用。
一、Vue 跨框架组件的新趋势
组件标准化（环境无感化复用，跨站化）：不再局限于 Vue 技术栈内使用，更注重原生标准组件封装，跨框架无缝调用，兼顾样式隔离（完全隔绝）、数据响应、生命周期对齐，适配多技术栈共存、跨端页面、公共组件平台等复杂场景。
二、Web Component 跨框架封装满分解法
Vue2/Vue3 通用核心逻辑：原生标准封装 + 样式完全隔离 + 跨端数据同步 + 生命周期适配，不依赖宿主框架环境，高效实现任意页面引入即用，避免环境冲突与样式渗透。
核心方案： 借助 Vue 原生支持的自定义元素构建能力（defineCustomElement），直接将 Vue 组件编译为符合标准的原生自定义组件，自动适配外部框架的调用方式。关键细节：搭配原生 Shadow DOM 样式隔离能力，彻底避免样式渗透；同时配置数据同步通道与异常兜底，保证不同环境下稳定运行。
兼容方案： 通过适配层抹平不同宿主环境的差异，对不支持原生标准的低版本环境做降级处理，保留核心交互能力，兼容老旧项目场景。
优化细节： 组件缓存（对已加载的自定义组件做内存缓存，避免重复编译）；初始化异常处理（添加环境检测，运行异常自动降级机制，避免页面渲染异常）；按需引入（针对复杂组件拆分功能模块，实现按需加载，减少资源占用）。
第十六篇：跨域解决方案的体系化认知
面试一个三年前端，让他聊聊跨域问题的解决方案与落地细节。结果他列了五种方法——CORS、JSONP、代理转发、iframe、postMessage——说遇到跨域就选一个试试。最后连 CORS 预检请求的触发条件都没说清。
我追问：你们项目接口需要带 cookie 跨域，为什么配置了 CORS 还一直失败？JSONP 为什么不能用 POST 请求？代理转发在开发和生产环境配置有什么区别？iframe 跨域通信怎么防止 XSS 攻击？预检请求过多导致接口延迟怎么优化？他马上说"那就把 withCredentials 设为 true，不行就换 JSONP，再不行就用代理"——这就是典型的试试看思维。
第一层：跨域本质——吃透同源策略的核心
同源策略是浏览器的安全基石，协议、域名、端口三者必须一致才是同源。它限制的是脚本对跨域资源的读取权限，而非请求发送权限。理解了这一点，才能明白为什么表单提交、图片加载不跨域，而 AJAX 请求会被拦截。所有跨域方案的本质，都是在浏览器安全规则允许的范围内，建立合法的资源访问通道。
第二层：方案选型——按场景精准匹配，而非堆砌
CORS 是主流方案，但要区分简单请求和预检请求，明确哪些请求会触发 options 预检，避免不必要的性能消耗。JSONP 仅适用于 GET 请求，且存在 XSS 风险，只在兼容旧浏览器时使用。代理转发是开发和生产的优选——开发环境用框架代理，生产环境用 Nginx/网关转发，本质是绕开浏览器同源限制。postMessage 用于跨域页面通信，需严格校验目标源，避免信息泄露。iframe 仅适用于特殊嵌入场景，需配合 sandbox 属性限制权限。
记住铁律： 能用代理不用 CORS，能用 CORS 不用 JSONP，慎用 iframe 和 postMessage。
第三层：安全与性能——规避跨域陷阱
安全层面：JSONP 需过滤回调函数名、校验请求来源；postMessage 必须指定 targetOrigin，禁止设为 *；CORS 要限制 Access-Control-Allow-Origin 为具体域名，而非通配符。
性能层面：通过 Access-Control-Max-Age 缓存预检结果，减少不必要的跨域请求；合并接口减少 options 次数；避免 withCredentials 混用导致的额外开销。
第四层：工程落地——适配不同环境与框架
开发环境：Vue/React 框架自带代理配置，需正确映射目标接口，避免路径匹配错误。生产环境：用 Nginx 反向代理时需配置 add_header，暴露必要响应头；网关转发要处理跨域与认证的兼容。框架适配：Axios 需统一配置 withCredentials，避免局部配置冲突；跨域 cookie 共享需同步配置 cookie 的 SameSite 属性，解决第三方 cookie 拦截问题。
总结
这道题考察的是你将安全规则转化为稳健方案的系统能力。跨域不是随便选一种方法试试，而是对同源策略、浏览器机制、安全风险的精确把控。优秀的前端工程师设计的不只是跨域方案，更是可复用、高安全、高性能的资源访问体系。
第十七篇：JS 事件循环的 P7 级别理解
面试官：说说 JS 事件循环，宏任务和微任务分别有哪些？候选人：同步代码先执行，然后微任务，再宏任务，宏任务有定时器，微任务有 Promise。面试官继续追问：微任务为什么要在宏任务间隙全部清空？浏览器和 Node 的事件循环核心区别是什么？
这道事件循环题直接决定了你是 P6 还是 P7。
第一阶段：核心执行规则——理解单线程与任务调度
事件循环的本质是 JS 单线程设计，为了不阻塞主线程，将异步任务放入队列等待调度执行。执行栈中的同步代码优先执行完毕，随后会一次性清空微任务队列，再取出一个宏任务执行，不断循环。
宏任务由宿主环境发起，调度力度粗、间隔长；微任务由 JS 引擎发起，优先级更高，必须在宏任务切换前全部执行完毕。
第二阶段：任务类型细分——明确边界与优先级
常见宏任务：全局 script 代码、定时器、DOM 事件回调、网络请求回调。
常见微任务：Promise 回调、async/await 后续代码、MutationObserver、process.nextTick（Node 独有）。
关键点：process.nextTick 是 Node 独有的微任务级队列，优先级高于所有标准微任务，会优先执行。async 函数内 await 之前的代码同步执行，await 之后的逻辑等价于 Promise.then，属于微任务。
第三阶段：渲染与事件循环——掌握页面渲染时机
浏览器的重排重绘渲染操作执行时机：在微任务队列清空后、下一个宏任务执行前。
requestAnimationFrame 不属于标准宏/微任务，它跟随浏览器屏幕刷新频率执行，在渲染前触发，专门用于实现流畅动画。
MutationObserver 监听 DOM 变更并触发回调，设计为微任务，是为了保证 DOM 修改后能立即响应，不等待宏任务，避免状态不同步。
核心风险：微任务中执行大量耗时逻辑会阻塞渲染，导致页面卡顿白屏。
第四阶段：跨环境差异——区分浏览器与 Node 机制
浏览器事件循环：宏任务队列加单微任务队列，每次清空微任务队列后仅执行一个宏任务。
Node 事件循环（低于 v11 版本）：分为 timers、pending callbacks、check 等六个阶段，每个阶段批量执行对应宏任务，阶段切换时才清空微任务。
Node v11 及以后：对齐浏览器规则，逐个执行宏任务并清空微任务。核心差异：Node 早期为阶段式批量执行宏任务，跨环境代码不可依赖旧版 Node 调度规则。
第五阶段：实际问题优化
微任务堆积优化：大量连续微任务会霸占主线程阻塞渲染，通过定时器将长逻辑拆分为宏任务，主动让出主线程。动画流畅优化：摒弃定时器做动画，改用 requestAnimationFrame 配合浏览器渲染频率。
灵魂总结
下次面试官问你事件循环，不要只说同步、微任务、宏任务三句话。要分层讲：核心规则（JS 单线程、执行栈、清空微任务、执行宏任务、循环调度）；任务差异（宏任务宿主发起、微任务引擎发起、nextTick 优先级高于微任务）；渲染时机（微任务执行完毕后触发页面渲染，RAF 适配刷新频率）；环境区别（Node 旧版阶段式执行，新版对齐浏览器，跨环境需做兼容）；实战优化（避免微任务堆积，合理拆分异步任务，适配渲染机制）。
第十八篇：防抖节流的场景化深度理解
面试一个精通 JavaScript 性能优化，对防抖节流有深入研究的五年前端。我问两者的核心区别是什么，他几乎对答如流：防抖是多次触发只执行最后一次，节流是固定时间段内只执行一次，都是用来减少高频事件的执行次数，降低页面性能开销。
我马上抛出具体场景：页面滚动到底部加载下一页数据，以及搜索框输入实时联想。如果滚动加载用防抖，搜索联想用节流，会出现什么问题？他愣了——"好像都能用吧，效果应该差不多。"
我追问：滚动一直触发，防抖会让用户快速滑动页面时请求始终被延后，列表一直不加载；搜索框快速打字，节流会让关键词变了却不及时请求联想，结果滞后，严重影响体验。
本质一：防抖节流最大的价值是场景化控频，而非单纯延时
防抖节流的本质是对高频事件的执行管控，核心不是延迟执行，而是避免无效冗余的逻辑运行（请求、DOM 操作、计算），从根源上减少主线程阻塞与网络浪费。这才是设计初衷，而不是为了延时而延时。
本质二：性能优势的前提是用对场景
搜索输入、窗口 resize、按钮重复点击——适合防抖；滚动加载、鼠标移动、动画帧更新——适合节流。它保证了在复杂交互里，不用酌情优化每一处事件就能守住性能底线，避免开发者因疏忽写出严重卡顿的逻辑。
本质三：面试官想听的是实现原理与工程化优化
能说出：手写基础版防抖的定时器清空逻辑；节流的时间戳/定时器两种实现；立即执行方案（防抖前缘执行、节流严格定时）的区别；框架适配（Vue 中自定义指令、React 中用 useCallback 加 useRef 封装，避免包泄漏与重复创建定时器）；进阶优化（结合 requestAnimationFrame 做视觉流畅度优化，支持取消执行，适配组件卸载逻辑）。
灵魂总结
下次面试官问你防抖节流，别再只背定义说能优化性能。要说出它的本质是高频事件场景化控频，再讲清不同场景的选型逻辑、手写实现与工程优化，这才是大厂面试官想要的深度。
第十九篇：闭包的五个层面——从概念到 V8 底层
面试一个精通 JavaScript 的前端，问闭包，他流利背出"函数加词法环境的定义"。我接着问：如果我现在要你追踪一个变量从创建到销毁的完整生命周期，并且解释闭包在内存回收、模块模式、性能优化中的具体影响，你能说出多少种场景和底层机制？他愣住了。
第一层：基本概念（初中级都会）
闭包等于函数加能够访问外部函数作用域中变量的能力，常见用途：数据私有化、模块模式、回调函数。但你知道闭包捕获的变量是引用还是值？循环中使用闭包为什么常常翻车？
第二层：作用域链与内存（很多三年经验都模糊）
闭包如何维持外部函数的活动对象又不被销毁？多个闭包共享同一个外部变量时内存如何分配？手动解除闭包引用（将闭包函数置 null）真的能立刻回收吗？闭包导致内存泄漏的典型场景：DOM 事件回调、定时器、大量缓存数据。
第三层：闭包与执行上下文（真功夫）
闭包在调用栈中的表现：外部函数执行完后即执行上下文弹出，但词法环境还在堆内存中。不同闭包之间如何竞争同一个自由变量？闭包与 let 结合快级作用域，解决经典 for 循环问题，与 var 的区别本质。闭包返回值是函数，但函数内部的变量查找是运行时还是编译时决定？
第四层：现代模式与陷阱
闭包在 React hooks 的 useEffect 中的体现——为什么每次渲染都捕获当前 state？闭包在节流/防抖函数中的应用——如何保证定时器回调始终访问最新的参数？闭包与 WeakMap 配合实现私有属性，而不影响垃圾回收。闭包在模块化（ESM、CommonJS）中如何实现模块隔离？
第五层：性能与引擎优化（触及 V8 底层）
V8 如何优化闭包上下文（内联、逃逸分析），哪些闭包会被优化掉？大量使用闭包对堆内存和 GC 压力的量化影响（比如在列表中频繁创建闭包）。闭包与 new Function 的性能天壤之别。为什么在 Node.js 服务端使用闭包需要注意请求间数据隔离、内存增长监控？
总结
同样一个问题，有人只能背概念，有人能聊到渲染管线。这就是高级前端和普通开发者之间真正的分水岭。
第二十篇：Vue3 的 ref 与 reactive 深度原理
面试一个做了两年 Vue3 的前端，我问 ref 和 reactive 有什么区别，什么时候该用哪个？他答：ref 用于基本类型，reactive 用于对象。
我追问：如果一个对象层级很深，你用 reactive 包装后修改深层属性，视图会更新吗？为什么？如果用 reactive 包装了一个数组，直接给数组重新赋值，为什么视图不更新？ref 的 .value 到底做了什么？
第一层：响应式基础与两种 API 的设计初衷
ref 处理基本类型（如 string、number）的响应式，通过 .value 访问，因为基本类型在 JavaScript 中按值传递，需要包裹在对象中才能追踪变化。
reactive 处理对象的响应式，使用 Proxy 代理整个对象，递归地将所有属性转为响应式。
为什么需要两个？ref 可以包装任何类型的值（包括对象，内部会调用 reactive），而 reactive 只能用于对象。ref 提供了更统一的 API，尤其是在组合函数中返回多个值时。
第二层：响应式原理与依赖收集
Vue3 使用 Proxy 代理对象，拦截 get、set、deleteProperty 等操作。
依赖收集：在 effect 副作用中访问响应式数据时会触发 get，将当前 effect 收集为依赖。触发更新：修改响应式数据时触发 set，通知所有依赖进行更新。
第三层：性能优化与陷阱规避
避免超大 reactive 对象：递归代理耗时，且可能产生不必要的依赖追踪。浅层响应式：shallowRef 和 shallowReactive 只代理第一层，避免深层递归。
结构丢失响应式：使用 toRefs 将响应式对象转换为普通对象，但每个属性都是 ref，保持响应式。
响应式数据与原始数据：通过 toRaw 获取原始对象，用于性能关键场景（如大型不可变数据的处理）。
循环引用与内存泄漏：正确使用 markRaw 标记不需要响应式的对象，避免意外代理。
第四层：组合式函数（Composables）与响应式结合
自定义组合式函数：利用 ref 和 reactive 封装可复用的逻辑，返回响应式数据和方法。
异步状态管理：在组合式函数中处理异步操作，使用 ref 存储异步结果，配合 watch 和 onUnmounted 清理副作用。
与 TypeScript 集成：使用泛型为组合式函数提供类型推断，如 useFetch<T>。
总结
这道题考察的是你对 Vue3 核心响应式系统的理解深度，以及在实际项目中如何正确高效地使用它们。这是区分 Vue3 开发者是初级应用还是中级进阶的关键。