前端全栈契约、性能与安全高频追问

本册面向 Vue3（前端框架）、React（前端框架）、Nuxt3（Vue 服务端渲染框架）与 TypeScript（类型脚本）的高级全栈追问，统一使用“业务不变量、竞争假设、前后端证据、止血、修复、灰度、业务验收”闭环。机制入口见前端全栈正文，项目事实与表达边界见项目组合事实卡。

1. 类型边界、接口契约与状态竞态

1.1 从静态类型到运行时业务一致性

热门面试题

1. 问题（基础题）：TypeScript（类型脚本）已经定义响应类型，为什么页面仍会因脏数据崩溃？

   • 考点：编译期类型、运行时校验、可选字段与契约边界。
   • 回答思路：区分开发期假设和网络输入事实，再说明入口校验与安全默认值。
   • 详细答案：TypeScript（类型脚本）只约束被编译代码中的静态使用方式，服务端、缓存、旧版本客户端和第三方返回都可能偏离声明。前端必须在 API（应用程序接口）入口做运行时结构校验，对金额、币种、状态枚举和分页游标采用拒绝、隔离或显式降级，不能用类型断言掩盖异常。支付确认等高风险页面还要显示服务端权威状态，而不是从缺失字段猜测成功。
   • 进阶追问：所有响应都做深度校验会不会太慢？
   • 进阶回答：按风险分级；支付、履约提交和导出交付做严格校验，低风险展示字段做轻量守卫，并通过采样记录契约偏差。

2. 问题（原理题）：Vue3（前端框架）与 React（前端框架）中如何避免搜索、切页和提交产生状态竞态？

   • 考点：请求代次、取消、闭包快照、状态机和最后到达不等于最新意图。
   • 回答思路：先定义用户意图序号，再解释旧响应丢弃与提交幂等。
   • 详细答案：每次查询生成单调代次并捕获参数快照，响应只在代次仍为当前时提交状态；可取消的读请求使用 AbortController（请求取消控制器），但仍保留代次判断，因为取消可能晚于响应。写请求不靠取消保证正确性，而是生成稳定业务键、禁用重复触发并由服务端幂等约束兜底。Vue3（前端框架）的监听清理与 React（前端框架）的副作用清理都只能减少陈旧工作，不能代替业务状态机。
   • 进阶追问：为什么“最后一个响应覆盖页面”仍可能错？
   • 进阶回答：最后到达的可能是最早发出的慢请求；应比较意图代次或参数摘要，而不是比较网络到达顺序。

3. 问题（项目题）：支付按钮防连点为何不能只在前端禁用？

   • 考点：多标签页、刷新、重试、稳定幂等键和服务端唯一约束。
   • 回答思路：说明界面防抖改善体验，服务端幂等保护资金副作用。
   • 详细答案：按钮禁用只能约束当前组件实例，用户刷新、双标签页、网络代理重试或移动端重复触发仍会产生多个请求。正确做法是前端首次点击生成稳定请求号并持久化到当前支付意图，重试复用同一号码和请求摘要；服务端以商户、支付意图、请求号建立唯一约束，同键不同金额直接冲突。前端遇到超时展示处理中并按原号查单，不生成新号盲目重扣。
   • 进阶追问：按钮什么时候可以重新启用？
   • 进阶回答：只有服务端明确失败且允许重试，或原支付意图已被安全关闭时；未知态应提供查单和退出入口，而不是重新扣款入口。

sequenceDiagram
    participant U as 用户
    participant V as Vue或React页面
    participant G as 契约守卫
    participant S as 服务端
    U->>V: 连续搜索A、B并点击支付
    V->>S: 查询A，代次1
    V->>S: 查询B，代次2
    S-->>V: B先返回
    V->>G: 校验结构并确认代次2
    G-->>V: 提交B状态
    S-->>V: A后返回
    V-->>V: 丢弃陈旧代次1
    V->>S: 支付，稳定请求号P7
    S-->>V: 响应超时
    V->>S: 按P7查单
    S-->>V: 返回权威终态

图解读： 查询链路以用户意图代次解决读竞态，支付链路以稳定业务键和查单解决写入未知态；两者不能混用“最后响应覆盖”策略。

数据演绎 1：搜索竞态与支付防重。 用户在 0 毫秒发起查询 A，在 80 毫秒发起查询 B；B 用时 120 毫秒先于用时 500 毫秒的 A 返回。若按到达顺序覆盖，页面在 500 毫秒后倒退到 A；加入代次后只接受 B。支付请求 P7 连点 3 次且代理重试 1 次，服务端唯一键都相同，最终只有 1 次资金副作用，重复命中数为 3。排查顺序是复现操作序列、比对代次与摘要、核对服务端唯一键、最后验证页面和资金终态一致。

2. 服务端渲染、静态生成与水合一致性

2.1 Nuxt3（Vue 服务端渲染框架）水合边界与个性化数据

热门面试题

1. 问题（基础题）：SSR（服务端渲染）、SSG（静态站点生成）和浏览器渲染如何选择？

   • 考点：首屏、缓存、实时性、个性化、安全和运行成本。
   • 回答思路：按内容稳定度与用户身份分层，而不是整站选择一种模式。
   • 详细答案：公开且变化慢的帮助页适合 SSG（静态站点生成），可由 CDN（内容分发网络）长期缓存；需要搜索可见性且随请求变化的详情页适合 SSR（服务端渲染）；高度交互、登录后个性化工作台可在稳定外壳后由浏览器取数。Nuxt3（Vue 服务端渲染框架）应按路由和数据源混合使用，支付结果、权限和库存不能被公共静态缓存，也不能把服务端密钥序列化到页面。
   • 进阶追问：支付结果页能不能做 SSR（服务端渲染）？
   • 进阶回答：可以服务端读取当前用户的权威结果，但必须私有缓存或禁用共享缓存，并在浏览器端继续订阅状态变化。

2. 问题（原理题）：水合不一致通常从哪里来，如何定位？

   • 考点：双端首帧确定性、时间随机数、浏览器专属对象、时区和异步数据。
   • 回答思路：先比较服务端标记与浏览器首次渲染输入，再逐项消除非确定性。
   • 详细答案：水合要求浏览器首次虚拟树与服务端输出结构一致。当前时间、随机数、客户端时区、窗口尺寸、浏览器存储、权限分支和两端不同的数据水位都会造成偏差。定位时保存路由、发布版本、服务端数据摘要和浏览器首帧状态，查看水合告警并做最小化复现。修复方式是把确定数据随载荷传递、把浏览器专属逻辑移到挂载后，并用占位骨架保持首帧结构稳定。
   • 进阶追问：直接关闭水合告警是否可行？
   • 进阶回答：不可作为修复；告警背后可能是交互绑定错位、闪烁或权限内容短暂泄露，只能在证明差异无害后局部处理。

3. 问题（项目题）：履约详情页如何同时兼顾首屏速度和实时轨迹？

   • 考点：服务端快照、客户端增量、版本水位、乱序和降级。
   • 回答思路：服务端交付可审计快照，浏览器从该水位继续更新。
   • 详细答案：服务端按订单权限读取履约快照，输出轨迹版本和发生时间；浏览器水合后以该版本为起点建立轮询、SSE（服务器发送事件）或 WebSocket（全双工通信协议）增量通道。新事件按版本与业务状态偏序推进，迟到事件只留原始记录，不让签收倒退。实时通道失败时降级为带抖动的查询，页面明确显示最后更新时间，不能伪装为实时。
   • 进阶追问：服务端快照与增量事件之间有空窗怎么办？
   • 进阶回答：增量订阅携带快照水位并支持重叠窗口，客户端按事件键去重；无法续传时重新拉权威快照。

flowchart LR
    R[路由请求] --> A{内容是否公开且稳定}
    A -- 是 --> S[静态生成并缓存]
    A -- 否 --> B{是否需要首屏可索引}
    B -- 是 --> C[服务端按身份生成快照]
    B -- 否 --> D[浏览器加载工作台外壳]
    C --> H[携带数据摘要与版本水位]
    S --> H
    D --> E[浏览器请求私有数据]
    H --> F{首帧输入是否一致}
    F -- 是 --> G[完成水合并订阅增量]
    F -- 否 --> X[隔离差异并降级重拉]
    G --> Y[按版本单调更新]

图解读： 渲染模式按路由和数据敏感度选择，水合成功依赖同一首帧输入；实时更新必须从已知水位继续，而不是覆盖服务端快照。

数据演绎 2：水合差异定位。 某履约页服务端在上海时区输出“07 月 15 日”，浏览器按伦敦时区首次渲染为“07 月 14 日”，1000 次访问中有 86 次出现水合告警，其中 82 次集中在跨日窗口。将服务端原始时间戳与时区一并传递，首帧统一使用服务器格式，挂载后再切换用户时区，告警降为 0。排查流程依次固定路由和版本、保存服务端标记、导出首帧状态、比较结构差异、验证交互绑定和敏感内容未泄露。

3. 性能观测与大数据可视化

3.1 从用户体验指标到 ECharts（图表库）渲染预算

热门面试题

1. 问题（基础题）：前端性能为什么不能只看接口耗时？

   • 考点：网络、主线程、渲染、交互、资源加载和用户分位数。
   • 回答思路：沿一次页面导航拆解等待，并强调真实用户分布。
   • 详细答案：接口快只表示服务端一段链路正常，页面还可能被大脚本解析、主线程长任务、图片、样式计算和图表绘制阻塞。应同时观察 TTFB（首字节时间）、LCP（最大内容绘制）、INP（交互到下一次绘制）和 CLS（累计布局偏移），按路由、设备、网络、发布版本和分位数切片，再关联后端 Trace（链路追踪） ID（标识）与业务成功率。
   • 进阶追问：平均值看起来很好为何用户仍投诉？
   • 进阶回答：平均值会掩盖长尾与低端设备，应看高分位、样本量和受影响人群，并回到具体会话证据。

2. 问题（原理题）：ECharts（图表库）一次渲染十万点为什么会卡，怎么优化？

   • 考点：数据转换、主线程、绘制复杂度、增量渲染、抽样和工作线程。
   • 回答思路：先减少无效数据和对象分配，再分片计算与渲染。
   • 详细答案：瓶颈可能同时发生在 JSON（结构化数据格式）解析、数据映射、坐标计算、图元创建和交互命中测试。先根据屏幕像素和业务目的聚合或抽样，关闭无必要动画、标签和阴影，再使用 ECharts（图表库）的大数据模式、渐进式渲染与数据追加。重计算可放入 Web（万维网） Worker（工作线程），但传输成本也要测量；缩放后再按可视窗口请求细粒度数据。
   • 进阶追问：抽样会不会掩盖支付峰值异常？
   • 进阶回答：监控曲线应使用保极值的桶聚合，并允许下钻原始明细；不能用简单均值抽样消掉尖峰。

3. 问题（故障题）：异步导出页接口正常但页面越来越卡，如何排查？

   • 考点：轮询泄漏、列表增长、闭包引用、长任务、内存和资源交付。
   • 回答思路：先按版本与会话定界，再从定时器、网络、主线程和堆快照取证。
   • 详细答案：检查路由切换后轮询是否清理、同一任务是否重复注册监听、任务列表是否无界追加、下载地址是否反复刷新以及大对象是否被闭包引用。通过性能时间线定位长任务，通过内存快照比较保留对象，通过网络面板核对轮询频率。止血可暂停非关键刷新、限制可见列表和延长退避；修复后验证离开页面无活动定时器、内存回落且导出结果仍可交付。
   • 进阶追问：为什么不能直接把轮询间隔改大？
   • 进阶回答：它只能减缓问题，若监听和对象持续累积仍会泄漏；还可能降低关键状态反馈，需要找到生命周期根因。

flowchart TB
    U[真实用户会话] --> M[采集导航与交互指标]
    M --> D{按路由版本设备切片}
    D --> N[网络与服务端等待]
    D --> J[脚本解析与长任务]
    D --> C[样式布局与图表绘制]
    N --> T[关联链路标识]
    J --> P[定位任务和内存保留]
    C --> E[检查数据量与绘制预算]
    T --> R[建立竞争假设]
    P --> R
    E --> R
    R --> F[止血并小流量修复]
    F --> V[验证体验与业务成功率]

图解读： 性能证据必须从真实用户会话向网络、主线程和绘制三条支路展开；出口同时验证体验指标与支付、履约、导出成功率。

数据演绎 3：十万点图表优化。 原始 100000 点传输 4.8 兆字节，解析 180 毫秒，数据映射 260 毫秒，首次绘制 740 毫秒，合计主线程阻塞约 1180 毫秒。按 1200 像素宽度做每像素两桶且保留极值后得到 2400 点，传输降至 150 千字节，映射 24 毫秒，绘制 65 毫秒；用户缩放后再请求局部原始数据。排查流程是固定同一数据集、分别测量传输解析转换绘制、关闭动画对照、检查内存与交互命中，最后以高分位交互耗时和异常峰值不丢失验收。

4. 浏览器安全、认证与授权

4.1 XSS（跨站脚本攻击）、CSRF（跨站请求伪造）与身份边界

热门面试题

1. 问题（基础题）：XSS（跨站脚本攻击）和 CSRF（跨站请求伪造）的攻击目标与防线有什么不同？

   • 考点：不可信内容执行、浏览器自动携带凭证、输出编码和请求来源证明。
   • 回答思路：分别回答攻击者能执行什么，以及能借用户身份做什么。
   • 详细答案：XSS（跨站脚本攻击）让不可信内容进入脚本执行上下文，可窃取页面数据或代用户操作，核心防线是上下文输出编码、可信模板、富文本净化和 CSP（内容安全策略）。CSRF（跨站请求伪造）利用浏览器自动携带 Cookie（浏览器会话凭证）发起跨站写请求，核心防线是 SameSite（同站策略）、随机令牌、来源校验和敏感操作再确认。二者都必须配合服务端授权，不能把前端隐藏按钮当权限。
   • 进阶追问：使用令牌认证是否自然免疫 CSRF（跨站请求伪造）？
   • 进阶回答：若令牌仍由浏览器自动携带就不免疫；若脚本读取令牌，又要重点防 XSS（跨站脚本攻击）和泄漏，必须按存储与发送方式判断。

2. 问题（原理题）：认证成功后为什么每个 API（应用程序接口）仍要独立授权？

   • 考点：身份与权限分离、对象级授权、租户边界和最小权限。
   • 回答思路：用“你是谁”与“你能操作哪条资源”区分。
   • 详细答案：认证只证明当前主体身份，授权还要判断角色、租户、资源归属、动作和当前业务状态。前端路由守卫与按钮隐藏只能减少误操作，攻击者可以直接构造请求。服务端必须在每个支付、履约、导出读取和下载接口检查对象级权限；异步导出的下载地址还要短时有效、绑定用户或租户并记录审计，避免拿到链接后越权传播。
   • 进阶追问：管理员是否可以跳过对象级授权？
   • 进阶回答：管理员也应受明确权限、作用域、审批和审计约束；高风险资金或批量导出不宜存在无限制万能角色。

3. 问题（故障题）：发现支付备注可注入脚本，如何止血和恢复？

   • 考点：存量污染、展示入口、会话风险、证据保全和分层修复。
   • 回答思路：先阻断渲染和新增污染，再清点影响与轮换凭证。
   • 详细答案：立即关闭危险富文本能力或按纯文本输出，部署 CSP（内容安全策略）报告与阻断策略，保留原始载荷、访问日志和受影响版本。清点所有展示备注的页面、邮件和导出模板，不能只修一个组件；对可能暴露的会话与令牌执行失效或风险分级轮换。修复使用上下文编码和经过验证的净化库，补恶意样本回归，最后验证存量记录也无法执行并审查是否发生越权操作。
   • 进阶追问：直接删除恶意备注可以吗？
   • 进阶回答：止血可隔离展示，但应保留受控取证副本和操作审计；仅删除会丢失影响分析依据，也不能证明其他入口已修复。

flowchart LR
    I[用户输入或第三方内容] --> V{内容是否可信}
    V -- 否 --> S[按输出上下文编码或净化]
    S --> C[CSP限制可执行来源]
    C --> P[页面展示]
    B[浏览器携带身份凭证] --> R{是否写操作}
    R -- 是 --> T[校验同站策略令牌与来源]
    R -- 否 --> A[检查资源读取权限]
    T --> Z[服务端对象级授权]
    A --> Z
    Z --> O{租户资源动作均允许}
    O -- 是 --> E[执行并记录审计]
    O -- 否 --> D[拒绝且不泄露资源存在性]

图解读： 内容安全与请求身份是两条独立防线，最终都必须经过服务端对象级授权；任何一条前端控制都不是权限裁决点。

数据演绎 4：存量脚本污染处置。 安全告警命中 12 条恶意备注，查询发现它们被 3 个页面、1 个邮件模板和 1 个导出模板消费，过去 24 小时共有 420 次展示。第一阶段关闭富文本并使 860 个活跃会话失效；第二阶段对 5 个入口统一编码与净化，回放 30 组恶意样本均不执行；第三阶段核对审计日志，确认没有退款、履约取消或越权导出。排查顺序是封入口、保原文、列消费面、查会话与敏感动作、统一修复、存量回放和观察告警。

5. 错误降级、灰度兼容与发布回退

5.1 从局部异常到跨版本可恢复交付

热门面试题

1. 问题（基础题）：前端错误边界能解决什么，不能解决什么？

   • 考点：渲染异常隔离、事件与异步错误、业务失败和降级出口。
   • 回答思路：先限定捕获范围，再说明统一上报和局部恢复。
   • 详细答案：React（前端框架）的错误边界可隔离子树渲染与生命周期异常，Vue3（前端框架）可通过应用和组件错误处理链集中上报；它们不能自动处理事件回调、网络失败、异步任务拒绝或服务端业务错误。关键页面应按支付摘要、履约轨迹、图表和辅助区域划分故障域，局部失败展示可重试或只读降级，保留订单号、发布版本和关联标识，不能整页白屏或把未知结果显示为失败。
   • 进阶追问：捕获错误后直接刷新页面好吗？
   • 进阶回答：刷新可能形成循环并丢失现场，应先隔离组件、保留证据和用户输入，仅在确认资源版本不一致时提供受控刷新。

2. 问题（原理题）：前后端灰度发布怎样保证契约兼容？

   • 考点：加法演进、能力协商、容忍旧字段、双读验证和回退窗口。
   • 回答思路：按旧前端对新后端、新前端对旧后端两个方向验证。
   • 详细答案：契约优先采用新增可选字段和新枚举兜底，避免直接删除或改变语义；前端对未知枚举进入安全状态并上报，后端在兼容窗口继续接受旧请求。高风险变更使用版本头或能力协商，灰度期间按前端构建版本切片观察错误。发布顺序通常先部署兼容后端，再放新前端，最后在活跃旧版本低于门槛且回退窗口结束后清理旧分支。
   • 进阶追问：数据库字段已改名如何零停机迁移？
   • 进阶回答：服务端经历双读或双写、回填和校验阶段，对外契约先保持稳定；确认所有消费者迁移后再停止旧字段。

3. 问题（项目题）：新支付状态灰度后旧页面显示“失败”，怎么处置？

   • 考点：未知枚举、资金安全、版本切片、开关回退和契约测试。
   • 回答思路：先停止错误引导，再从服务端权威状态恢复展示。
   • 详细答案：立即关闭新状态的下发开关或把新状态映射为旧页面可理解的“处理中”，禁止用户因错误失败提示再次支付。按前端版本、渠道和订单样本核对服务端状态与页面分支，保存响应和构建版本。修复旧客户端的未知枚举兜底并补消费者驱动契约测试；恢复时逐档开启，验证重复支付入口为零、查单正常、错误率和业务状态偏差收敛。
   • 进阶追问：为何不能把未知状态统一当成功？
   • 进阶回答：成功会触发履约、记账或用户承诺，风险更大；安全默认应是处理中或不可操作，并请求权威状态。

flowchart TB
    C[契约或前端新版本] --> K[兼容后端先上线]
    K --> G[小比例灰度]
    G --> O{技术与业务信号正常吗}
    O -- 是 --> N[扩大到下一档]
    N --> O
    O -- 否 --> F[关闭功能开关或回退资源]
    F --> I[按构建版本与契约版本定界]
    I --> H{旧客户端是否受影响}
    H -- 是 --> A[启用兼容映射并延长窗口]
    H -- 否 --> B[修复新版本局部分支]
    A --> V[回放支付履约导出用例]
    B --> V
    V --> G

图解读： 灰度不是只看脚本错误率，而是每档都验证业务信号；任何不兼容先通过开关和兼容映射止血，再回到小比例验证。

数据演绎 5：灰度状态不兼容。 新状态先向 5% 流量开放，共 20000 个会话；其中旧构建版本占 30%，有 180 个支付页把未知状态误判为失败，偏差率为 180 / 6000 = 3%。立即关闭开关后偏差停止增长，服务端增加“旧构建映射为处理中”，前端补未知分支。重新按 1%、5%、20%、50%、100% 放量，每档观察 30 分钟，状态偏差、重复支付入口和白屏均为 0 才继续。排查链路从构建版本、契约版本、响应样本到服务端支付事实逐层核对。

6. 支付、履约与异步导出的前端闭环

6.1 从用户动作到可观测业务终态

热门面试题

1. 问题（项目题）：支付超时页面应该如何设计，既不误导又不重复扣款？

   • 考点：未知态、稳定请求号、查单、可恢复交互和业务观测。
   • 回答思路：把网络超时与支付失败分离，并提供权威查证路径。
   • 详细答案：页面保留支付意图和请求号，超时后进入处理中，禁用新支付动作但允许安全退出；后台按退避查单，也接收服务端推送。明确成功后展示交易号并进入履约，明确失败才恢复支付入口，长期未知给出人工查询渠道。埋点关联订单、支付单、请求号、前端版本和服务端链路，但不得记录完整卡号或密钥。机制可回看支付项目串讲。
   • 进阶追问：用户关闭页面后怎么继续收敛？
   • 进阶回答：服务端状态机与回调查单独立运行，用户再次进入时按支付意图读取权威状态，前端不是一致性的唯一执行者。

2. 问题（项目题）：履约轨迹出现乱序、重复和实时通道中断，页面怎样处理？

   • 考点：原始事件、双时间、状态偏序、水位续传和轮询降级。
   • 回答思路：先保存服务端权威序列，再构建可重建展示投影。
   • 详细答案：页面以事件标识去重，显示发生时间而非接收顺序，并按服务端版本与状态偏序推进；签收不能被迟到的运输中覆盖。实时通道断开后携带最后水位重连，失败则退避轮询并展示最后更新时间。冲突事件保留在详情或诊断信息中，不在浏览器自行猜测终态。完整业务边界见履约异常恢复串讲。
   • 进阶追问：客户端能否自己给事件排序并作为最终结果？
   • 进阶回答：只能做展示排序，最终投影应由服务端基于渠道规则与完整证据裁决，否则不同客户端会得到不同终态。

3. 问题（项目题）：异步导出如何设计前端任务生命周期和结果交付？

   • 考点：任务幂等、快照、轮询退避、过期下载、权限和失败重试。
   • 回答思路：从创建任务、观察状态、下载授权到过期重建讲闭环。
   • 详细答案：创建时提交筛选摘要与稳定请求号，服务端返回任务标识和数据快照水位；页面按可见性和状态退避轮询，离开路由清理定时器。完成后展示文件摘要、生成时间、过期时间和受控下载入口；下载必须再次鉴权，链接短时有效。失败区分可重试与参数错误，重试复用业务意图或显式创建新版本，不能把旧文件冒充新结果。详见异步导出串讲。
   • 进阶追问：为什么导出完成后仍可能下载失败？
   • 进阶回答：文件可能过期、对象存储不可用、权限变化或签名失效；任务完成与结果可交付要分别观测并支持重新签发。

sequenceDiagram
    participant U as 用户
    participant F as 前端状态机
    participant B as 业务服务
    participant X as 外部支付仓储或文件服务
    U->>F: 发起支付履约查询或导出
    F->>B: 稳定业务键与契约版本
    B->>X: 执行业务动作
    alt 明确成功
        X-->>B: 权威结果与版本
        B-->>F: 成功终态
    else 明确失败
        X-->>B: 可分类失败
        B-->>F: 失败与可重试边界
    else 超时或通道中断
        F-->>U: 展示处理中与最后更新时间
        B->>X: 按原键查单或续传
        B-->>F: 收敛后的权威状态
    end
    F-->>U: 展示可验证结果或安全降级

图解读： 三类项目共享“稳定业务键、显式未知态、权威查证、可验证交付”，但不可逆副作用与恢复证据不同，前端只能呈现和触发，不能自行裁决业务成功。

数据演绎 6：三链路联合排查。 发布后 10 分钟内，支付未知态从 20 增至 140，履约实时断线率从 1% 升至 18%，导出轮询请求每秒从 60 升至 420。按构建版本切片发现 92% 异常来自新版本，其重连代码把所有任务注册到同一立即重试循环。关闭功能开关后请求每秒降至 70，支付查单资源恢复，未知态以每分钟 15 单下降，履约改为退避轮询，导出离开页面后定时器归零。验收不是只看请求下降，还要核对支付终态、轨迹水位和文件交付均收敛。

10. 高频面试题与追问

1. 问题（综合题）：Vue3（前端框架）与 React（前端框架）如何选型，你会比较哪些工程边界？

   • 考点：团队能力、状态模型、生态、服务端渲染、迁移成本和可观测性。
   • 回答思路：从业务约束出发，对比心智模型、交付链和长期治理。
   • 详细答案：两者都能完成复杂工作台，选型关键不是语法偏好，而是团队经验、现有资产、渲染模式、状态复杂度、测试发布和维护成本。
   • 进阶追问：你会用性能跑分直接决定吗？
   • 进阶回答：不会；必须使用真实页面、真实设备和团队交付数据，框架微基准不能代表业务长尾。
   • 口述答案：我不会先问哪个框架更快，而是先固定业务约束。支付和履约工作台要求状态可追踪、表单复杂、错误能局部隔离；公开物流页又需要服务端首屏和搜索可见性；团队还要承担测试、灰度与长期升级。Vue3（前端框架）的响应式模型、组合式能力和 Nuxt3（Vue 服务端渲染框架）对现有团队可能更顺手，React（前端框架）的组件生态、并发渲染模型和跨端资产也可能更匹配，结论取决于现状而不是流行度。我会选支付详情、十万点图表、异步导出三个真实切片做验证，测开发周期、包体、低端设备交互、错误恢复和服务端渲染成本，同时检查类型、测试、监控与组件库是否成熟。状态层不把服务端数据和本地交互混成一个全局仓库，写操作使用显式状态机和稳定业务键，读请求用代次消除竞态。迁移时采用路由或业务域分段，保持 API（应用程序接口）契约稳定，不做全量重写。上线按构建版本灰度，比较技术指标和支付、履约、导出成功率。最后我会形成选型记录，写清适用边界、放弃方案、升级责任和退出策略，这样选型才是可验证的工程决策，而不是个人偏好。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：两个框架能否在同一系统长期共存？
   • 直答1：可以按路由隔离，但要承担重复运行时、组件体系、监控和人才成本，应有迁移终点。
   • 追问2：状态管理库怎么选？
   • 直答2：先区分服务端缓存、表单状态和跨组件业务状态，再按复杂度选择，不能为了统一而全部全局化。
   • 追问3：如何证明选型成功？
   • 直答3：用交付周期、缺陷率、体验高分位、升级成本和关键业务成功率持续复盘。
   • Vue3（前端框架）与 React（前端框架）机制正文

2. 问题（综合题）：如何建立 TypeScript（类型脚本）与运行时 API（应用程序接口）契约治理？

   • 考点：静态类型、运行时校验、契约生成、兼容演进和偏差观测。
   • 回答思路：从单一契约源、入口守卫、生成链路和发布门禁回答。
   • 详细答案：类型声明不能证明网络数据真实，必须配合运行时校验、兼容规则、契约测试和生产偏差采样。
   • 进阶追问：前后端共用类型包是否足够？
   • 进阶回答：不够；共享包可能版本漂移，也不能约束外部系统和历史数据，运行时边界仍需校验。
   • 口述答案：我会把契约治理分成设计、生成、运行时和演进四层。设计层明确字段语义、必填性、金额精度、时间时区、状态枚举、错误分类和分页规则，避免只有一个数据结构没有业务约束。生成层尽量从同一机器可读描述生成 TypeScript（类型脚本）类型、服务端模型和测试样本，但生成物必须固定版本并进入代码评审。运行时层在 API（应用程序接口）入口校验高风险响应，支付金额、币种、状态和下载权限不符合契约时拒绝推进并展示安全降级，普通展示字段可以轻量校验和采样上报。请求端同样保存契约版本与参数摘要，服务端拒绝同一幂等键携带不同业务内容。演进层坚持新增可选字段、未知枚举兜底和兼容窗口，先部署兼容服务端，再灰度新前端，最后依据活跃旧版本清理旧字段。流水线包含消费者驱动契约测试、典型旧版本回放和破坏性变更检查。生产监控按构建版本统计解析失败、默认值命中和状态偏差，并把样本关联到后端链路。遇到偏差先关闭危险新字段，再保存原响应和版本定位，不能用类型断言把问题压掉。这样静态类型提升开发效率，运行时守卫保护真实边界，灰度与证据链负责长期演进。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：严格校验失败后页面怎么展示？
   • 直答1：高风险动作阻断并显示可恢复状态，低风险区域局部占位，同时上报脱敏样本。
   • 追问2：未知枚举应该映射成什么？
   • 直答2：映射到处理中或不可操作等安全状态，并请求权威数据，不能猜成成功或失败。
   • 追问3：契约测试通过为何生产仍会偏差？
   • 直答3：可能存在缓存旧数据、第三方响应、独立发布和历史客户端，所以还要运行时观测。
   • 接口状态与项目落地正文

3. 问题（综合题）：API（应用程序接口）需要升级时，怎样做到灰度兼容和可回退？

   • 考点：双向兼容、能力协商、版本切片、开关和业务验收。
   • 回答思路：覆盖旧前端对新服务端、新前端对旧服务端两个组合。
   • 详细答案：先保持旧语义，再通过可选字段或能力协商扩展，灰度观察所有版本组合，最后才清理旧契约。
   • 进阶追问：能不能直接在地址中发布第二版？
   • 进阶回答：可以，但版本地址不能代替迁移、监控和下线治理；同一业务事实仍要保持一致。
   • 口述答案：我先建立兼容矩阵，而不是只测新前端和新服务端。矩阵至少覆盖旧前端配新服务端、新前端配旧服务端、缓存中的旧静态资源和移动端长时间不刷新的页面。契约变更优先采用新增可选字段、保留旧枚举语义和服务端默认值；真正无法兼容的能力通过版本头或能力协商显式启用。发布顺序一般是兼容服务端先上线，确认旧客户端没有参数拒绝，再灰度新前端；功能开关把新字段下发与代码部署解耦。灰度按构建版本、租户、渠道和业务场景切片，同时观察解析错误、未知枚举、接口失败和支付重复提交、履约状态偏差、导出下载失败等业务信号。出现异常先关闭能力开关或恢复旧响应映射，静态资源使用带内容摘要的文件名和版本清单回退，避免新入口引用已经删除的旧资源。数据模型迁移采用双读、回填、校验、切读、停旧写和删除的分阶段流程，对外接口在内部迁移期间保持稳定。兼容窗口结束必须有证据，包括旧构建活跃度、缓存最长寿命和关键消费者确认。回退演练也要验证新数据是否还能被旧代码读取。这样发布不是一次切换，而是一套可停止、可回退、可度量的状态机。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：版本号放在地址还是请求头？
   • 直答1：取决于缓存、网关和客户端治理；关键是语义清楚、可观测并有下线策略。
   • 追问2：旧版本长期不消失怎么办？
   • 直答2：延长只读兼容、提示升级或按风险限制能力，不能无证据直接删除关键契约。
   • 追问3：灰度只看错误率够吗？
   • 直答3：不够，兼容错误可能返回成功码却产生错误业务状态，必须核对业务不变量。
   • 工程化发布与兼容正文

4. 问题（综合题）：设计支付提交页时，如何处理连点、超时、回调与查单竞态？

   • 考点：幂等、未知态、终态单调、前后端证据和用户交互。
   • 回答思路：围绕同一支付意图只确认一次说明完整状态机。
   • 详细答案：前端改善交互，服务端保证唯一副作用，超时后保持未知并按原号查证，回调和查单竞争通过条件迁移收敛。
   • 进阶追问：是否可以在前端本地生成最终支付结果？
   • 进阶回答：不可以；最终结果必须来自服务端与渠道权威事实，前端缓存只用于展示连续性。
   • 口述答案：我先定义不变量：同一支付意图只能确认一次，金额和币种不能漂移，成功终态不能被迟到失败覆盖。用户首次点击时，前端生成或领取稳定请求号，保存订单、金额、币种和请求摘要，按钮进入提交中；后续刷新、重试和多标签页都复用同一支付意图。服务端以商户、支付意图和请求号建立唯一约束，同键不同摘要直接冲突。同步调用超时只说明响应未知，页面切换到处理中，停止生成新号，按退避查询原支付单并允许用户安全离开。渠道回调先由服务端验签、防重放和幂等入库，再通过前置状态与版本推进；主动查单和回调同时到达时只有第一次合法迁移生效。前端收到任何结果都重新读取权威支付状态，不从单次接口异常猜测失败。观测上关联订单号、支付单、请求号、渠道、构建版本和链路标识，日志不保存敏感卡数据。故障时先关闭重新支付入口并保住查单能力，核对渠道、本地支付、账务和订单四方事实。修复后重放重复点击、响应丢失、回调乱序和查单超时，确认只产生一次资金副作用，再按版本灰度恢复。用户体验可以柔和，但资金结论必须保守且可审计。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：处理中状态最长保留多久？
   • 直答1：由渠道查询能力和业务风险决定，超过自动预算进入人工裁决，不能自动判失败。
   • 追问2：多标签页如何同步按钮状态？
   • 直答2：可用浏览器通信改善展示，但最终仍以服务端支付意图状态为准。
   • 追问3：失败后重试要不要换请求号？
   • 直答3：明确失败并关闭原意图后可创建新尝试；通信未知时绝不能换号重扣。
   • 支付未知态与项目串讲

5. 问题（综合题）：请解释 Nuxt3（Vue 服务端渲染框架）水合不一致，并给出系统化排查路径。

   • 考点：双端确定性、数据载荷、环境差异、证据保存和安全风险。
   • 回答思路：先说水合前提，再按输入、结构、交互和版本逐层定位。
   • 详细答案：浏览器首帧虚拟树必须与服务端标记一致，任何非确定输入、数据水位或版本差异都可能破坏这一前提。
   • 进阶追问：局部改成只在浏览器渲染是不是最佳解？
   • 进阶回答：只适合确实依赖浏览器环境的区域；滥用会损失首屏、搜索可见性并掩盖数据边界问题。
   • 口述答案：Nuxt3（Vue 服务端渲染框架）水合的本质是浏览器用同一份组件逻辑接管服务端已经输出的结构，所以浏览器第一次渲染必须和服务端标记一致。常见偏差包括当前时间、随机数、时区、语言、窗口尺寸、浏览器存储、权限分支、服务端与浏览器读取不同数据水位，以及新旧静态资源混用。我排查时先按路由、构建版本、服务端版本和用户环境定界，保存服务端返回标记、序列化数据摘要、浏览器首帧状态与水合告警；然后从第一处结构差异向上找输入，不直接把整页改成仅浏览器渲染。修复原则是让首帧确定：时间和随机值由服务端生成并随载荷传递，浏览器专属逻辑移到挂载后，权限与支付状态由服务端权威读取，异步区域使用结构稳定的占位。还要检查缓存是否把甲用户的私有载荷交给乙用户，因为水合告警可能同时提示安全泄漏。发布时确保页面清单与带内容摘要的资源原子对应，旧资源保留到缓存窗口结束。验证覆盖不同时区、登录态、慢网络和灰度版本，既看告警归零，也检查按钮绑定、焦点、表单和敏感内容。服务端渲染不是为了消灭浏览器取数，而是提供可信首帧，再从明确水位继续更新。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：只比较页面文本够吗？
   • 直答1：不够，还要比较节点结构、属性、事件绑定和序列化状态，否则交互仍可能错位。
   • 追问2：时区怎么处理最稳？
   • 直答2：首帧使用明确时区和时间戳，挂载后再按用户偏好转换，并保持结构不变。
   • 追问3：水合告警会影响搜索可见性吗？
   • 直答3：可能导致闪烁、重渲染和内容不一致，应结合抓取结果与真实页面一起验证。
   • Nuxt3（Vue 服务端渲染框架）渲染与水合正文

6. 问题（综合题）：Nuxt3（Vue 服务端渲染框架）项目中如何设计缓存，避免个性化数据串用？

   • 考点：公共与私有缓存、缓存键、身份、失效和敏感数据。
   • 回答思路：按页面外壳、公共数据、用户数据和业务实时性分层。
   • 详细答案：缓存必须绑定数据敏感度与新鲜度，公共内容可共享，支付、权限和订单数据必须私有化或不缓存。
   • 进阶追问：只把用户标识加入缓存键就安全吗？
   • 进阶回答：仍要防止标识缺失、租户混淆和中间层忽略缓存键，并设置正确响应头与自动化验证。
   • 口述答案：我会先做数据分级，再谈缓存。帮助文档、公共规则和静态资源可以由 CDN（内容分发网络）共享缓存；商品公共信息可以短缓存并通过版本失效；登录后的支付结果、履约详情、权限与导出列表属于私有数据，默认不进入共享缓存。Nuxt3（Vue 服务端渲染框架）服务端取数时必须把租户、用户、语言、币种和必要查询条件纳入缓存身份，任何身份缺失都走不缓存的安全分支，不能把匿名默认值当成公共键。响应头明确公共、私有或禁止存储，中间层配置与应用语义一起测试。服务端渲染载荷只包含页面所需字段，访问令牌、密钥和内部权限不序列化到浏览器。支付状态和库存这类实时事实即使短缓存，也要显示更新时间并支持按原业务键重新查证；用户执行写操作后只失效相关实体，避免全站缓存风暴。故障演练会构造两个租户、两个账号和相同订单尾号，验证缓存命中时绝不串数据；还会检查注销、权限回收、退款和文件过期后旧页面是否仍可访问。监控按路由统计命中率、回源率、年龄、身份缺失和私有响应误缓存告警。发现串用立即绕过共享缓存、使相关会话与对象失效、保留缓存键和响应样本，再评估敏感信息暴露。恢复必须经过跨账号回归和访问审计，不能只看命中率恢复。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：缓存命中率越高越好吗？
   • 直答1：不是，正确性和隔离优先；私有数据的高共享命中反而可能是风险信号。
   • 追问2：写操作后如何失效？
   • 直答2：按实体和版本精准失效，并让关键页面支持权威重拉，避免无界全量清除。
   • 追问3：静态页面能展示实时库存吗？
   • 直答3：静态外壳可以，实时库存应在浏览器按区域与身份重新请求，并标明新鲜度。
   • 浏览器网络缓存与安全正文

7. 问题（综合题）：页面打开快但点击卡顿，你如何建立前端性能证据链？

   • 考点：真实用户指标、主线程长任务、分位数、版本切片和后端关联。
   • 回答思路：从用户动作还原时间线，再区分网络、脚本、渲染与内存。
   • 详细答案：首屏快不代表交互快，必须围绕具体点击收集输入、任务、绘制和业务完成时间。
   • 进阶追问：实验室性能工具能代替线上数据吗？
   • 进阶回答：不能，实验室适合稳定复现，线上真实用户数据负责发现设备、网络和长尾分布。
   • 口述答案：我会先把“卡顿”还原成具体用户动作，例如点击支付确认后按钮多久响应、展开十万点图表时是否掉帧、导出页运行半小时后是否恶化。线上采集 INP（交互到下一次绘制）、长任务、页面可见性、构建版本、设备、网络和路由，并使用会话标识关联前后端 Trace（链路追踪） ID（标识）与业务完成结果。分析时看高分位而不是平均值，先判断延迟发生在等待网络、脚本执行、状态更新、样式布局、绘制还是垃圾回收。对异常会话在实验环境使用同一数据和设备档位复现，通过性能时间线拆解事件处理、任务和下一次绘制；再用内存快照检查监听器、定时器和大对象是否持续保留。止血可以关闭非关键动画、限制图表数据、暂停后台轮询或回退新包，但不能把支付未知态改成失败。修复后建立性能预算，包括路由脚本体积、单次主线程任务、图表点数和后台刷新频率，并进入流水线回归。灰度时同时看体验指标与支付确认率、履约操作成功率、导出可交付率，防止为了指标停止关键工作。最终报告给出受影响版本、人群、根因证据、优化前后分布和业务结果，而不是一句“接口慢”或“浏览器卡”。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：为什么强调高分位？
   • 直答1：低端设备和特定数据量通常集中在长尾，平均值会稀释最需要修复的用户群。
   • 追问2：如何区分接口慢和主线程忙？
   • 直答2：比较网络完成时间、回调实际执行时间和下一次绘制时间，主线程忙会让已返回响应延迟处理。
   • 追问3：性能预算越严越好吗？
   • 直答3：预算要与业务价值和设备分布匹配，过严会阻碍交付，过松则失去门禁意义。
   • 浏览器渲染与性能正文

8. 问题（综合题）：ECharts（图表库）展示十万点支付数据时，怎样兼顾性能与异常真实性？

   • 考点：数据聚合、保极值、渐进渲染、工作线程、下钻和性能预算。
   • 回答思路：按传输、转换、绘制、交互四阶段优化，并保护尖峰。
   • 详细答案：先根据屏幕和分析目标减少无效点，再分片计算与绘制，保留异常极值及原始下钻能力。
   • 进阶追问：把所有点放到工作线程就解决了吗？
   • 进阶回答：不会，线程间复制和最终绘制仍有成本，必须测量数据传输、聚合和主线程提交。
   • 口述答案：我会先明确图表要回答的问题。如果运营只看一天内支付成功率趋势，屏幕宽度只有一千多像素，传输十万点并为每点创建交互图元没有价值；但简单平均又会抹掉短时失败峰值。因此服务端或浏览器按时间桶聚合，至少保留计数、均值、最小、最大和异常数，首屏点数与像素预算匹配，用户缩放或框选后再请求局部原始数据。链路分四段测量：网络传输和 JSON（结构化数据格式）解析、数据转换、ECharts（图表库）布局绘制、鼠标命中与提示。关闭无必要动画、标签、阴影和逐点符号，使用大数据模式、渐进式渲染和数据追加；复杂聚合可放 Web（万维网） Worker（工作线程），但要记录复制与序列化成本。状态更新不能每到一条数据就重建全部配置，应批量合并并控制刷新节奏。内存上限制历史窗口，离开路由释放图表实例和监听。降级时优先保留总量、异常峰值和表格下载，明确提示数据粒度，不用空白图冒充无数据。验证使用固定十万点数据集和包含尖峰的样本，比较解析、绘制、交互高分位与峰值位置，再到线上按设备和版本观察。最终目标不是画出最多点，而是让用户快速、准确地发现支付异常并可下钻证据。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：聚合放服务端还是浏览器？
   • 直答1：大数据和多用户复用优先服务端，临时局部变换可放浏览器，选择依据是传输与计算总成本。
   • 追问2：图表降级成表格是否合理？
   • 直答2：合理，关键数值和异常明细可访问时，表格是比卡死页面更可靠的降级出口。
   • 追问3：如何验证峰值未丢失？
   • 直答3：用已知尖峰样本比较聚合前后最大值、时间桶和异常计数，并支持回查原始明细。
   • ECharts（图表库）与项目落地正文

9. 问题（综合题）：异步导出页面运行越久越卡，你会怎样定位并修复？

   • 考点：轮询生命周期、内存泄漏、列表增长、文件交付和权限。
   • 回答思路：先定界增长源，再验证清理、退避和业务交付不受损。
   • 详细答案：常见根因是重复定时器、未清理订阅、无界任务列表和闭包保留，修复必须覆盖页面生命周期与结果交付。
   • 进阶追问：页面刷新后卡顿消失能证明是前端问题吗？
   • 进阶回答：只能提高怀疑，仍需定时器、监听器、堆快照和网络证据证明，服务端积压也可能同时存在。
   • 口述答案：我先用同一账号和任务规模复现，记录进入页面、创建任务、切换路由、返回页面和持续运行各阶段的内存、请求数、定时器与监听器。常见问题是每次进入都注册新轮询，任务完成后仍刷新，路由离开未清理，列表把每次状态快照都追加，或下载大对象被闭包长期引用。我会在网络面板看同一任务是否出现成倍请求，在性能时间线找长任务，在多次堆快照中比较保留对象和引用路径，并按构建版本确认是否由发布引入。止血先通过功能开关暂停非关键自动刷新，限制可见任务数量，轮询采用指数退避和页面不可见暂停，但仍保留用户主动刷新与结果通知。修复时让一个任务只有一个观察器，以任务终态、路由卸载和账号切换为明确清理点；任务状态按标识更新而不是无界追加，文件下载使用流式或受控地址，不把大文件驻留内存。服务端返回任务快照水位、过期时间和下载权限，前端区分任务完成与文件可交付。验证要重复进出页面几十次，确认定时器归零、内存回落、请求频率稳定，同时检查导出结果、摘要、权限和过期重签仍正确。最后把生命周期测试和长时间稳定性样本加入回归。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
   • 追问1：轮询间隔应该固定吗？
   • 直答1：不应固定高频，按任务阶段退避并加入抖动，用户可见时才保持必要更新。
   • 追问2：任务完成后为何还要观察交付？
   • 直答2：文件可能尚未可读、签名失败或权限变化，完成与可下载是两个状态。
   • 追问3：列表虚拟化能解决泄漏吗？
   • 直答3：只能减少节点渲染，不能清除后台定时器、订阅和数据对象，仍要修根因。
   • 异步导出任务项目串讲

10. 问题（综合题）：如何系统防御 XSS（跨站脚本攻击），而不是只在一个组件转义？

• 考点：上下文编码、富文本净化、CSP（内容安全策略）、存量污染和供应链。
• 回答思路：从输入传播图、输出上下文、浏览器策略和事故处置回答。
• 详细答案：防御必须覆盖所有展示出口、可信组件与第三方资源，发生污染时还要处理存量数据和会话风险。
• 进阶追问：输入时过滤是否能代替输出编码？
• 进阶回答：不能，不同输出上下文规则不同，输入过滤易被绕过；输入约束与输出编码应分工。
• 口述答案：我会先绘制不可信内容传播图，来源包括用户备注、第三方物流轨迹、支付渠道描述、配置和历史数据库，出口包括页面文本、属性、链接、富文本、邮件和导出文件。普通文本由模板默认编码，禁止字符串拼接进入脚本或样式上下文；确需富文本时采用允许列表净化，限制标签、属性、协议和地址，并固定净化库版本。浏览器侧部署 CSP（内容安全策略），先报告再逐步阻断，减少内联脚本和不受控第三方源，同时使用完整性与依赖审计降低供应链风险。身份凭证不放在容易被脚本读取的长期存储，敏感操作仍需服务端授权与再确认，因为 XSS（跨站脚本攻击）可能直接代用户操作。测试包含事件属性、危险协议、嵌套标记、编码绕过和不同浏览器样本。发现生产污染时，先把危险内容按纯文本展示或关闭入口，保存原始载荷、版本和访问日志，清点所有消费面，评估会话、支付、退款和导出是否被滥用；必要时使会话失效。修复不能只改触发告警的组件，还要统一安全输出组件并回放存量数据。恢复以所有出口不执行、CSP（内容安全策略）告警收敛、敏感动作审计无异常为准。这样才能从单点补丁升级为内容供应链治理。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
• 追问1：CSP（内容安全策略）能完全阻止 XSS（跨站脚本攻击）吗？
• 直答1：不能，它是纵深防线；错误白名单、可信脚本漏洞和业务注入仍可能绕过。
• 追问2：富文本净化后是否可以永久保存净化结果？
• 直答2：应保留受控原文与净化版本，净化规则升级时可重算，但访问原文必须严格授权。
• 追问3：导出文件也要防脚本吗？
• 直答3：要按文件格式处理公式注入、链接和嵌入内容，不能只保护浏览器页面。
• 浏览器安全与存储正文

11. 问题（综合题）：Cookie（浏览器会话凭证）登录体系如何防御 CSRF（跨站请求伪造）并兼顾支付体验？

• 考点：自动携带凭证、同站策略、随机令牌、来源校验和敏感操作确认。
• 回答思路：先解释攻击成立条件，再按浏览器、应用与业务三层设防。
• 详细答案：防御不能依赖一个请求头，要组合 Cookie（浏览器会话凭证）属性、随机令牌、来源校验、对象授权和高风险业务确认。
• 进阶追问：只允许 POST（提交方法）请求是否足够？
• 进阶回答：不够，攻击者同样能构造跨站表单提交，关键是证明请求来自可信会话中的真实操作。
• 口述答案：CSRF（跨站请求伪造）成立的关键是浏览器会自动携带 Cookie（浏览器会话凭证），攻击页面不必读取响应，也可能借用户身份发起退款、取消履约等写操作。我会先保证查询接口没有副作用，写接口只接受明确方法和内容类型；会话凭证设置 Secure（仅安全传输）、HttpOnly（禁止脚本读取）和合适的 SameSite（同站策略），但考虑第三方支付跳转与跨站登录时不能机械设成最严格值。应用层为写请求校验与会话绑定的随机令牌，并检查 Origin（来源）或 Referer（来源页），缺失与异常都进入审计。服务端仍要执行租户、资源、动作和状态授权，退款、改收款账户、大额导出等操作增加密码、动态验证或双人审批，因为防跨站请求不等于防账号被盗。支付回跳只携带一次性关联信息，浏览器展示处理中，再由服务端按支付单查权威结果，不能用地址参数直接改成功。测试覆盖同站、跨站表单、旧浏览器、令牌重放、多标签页和支付渠道回跳。发生异常先关闭高风险入口或提升再确认，保留来源、会话、业务键和操作结果，核对是否已有资金或履约副作用。修复后验证合法支付流程不被误伤、跨站写请求全部拒绝、重复令牌不可复用，并观察拒绝率与客服反馈。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
• 追问1：SameSite（同站策略）设为严格是否最好？
• 直答1：安全性强但可能破坏支付回跳与联合登录，应按真实流程选择并由令牌和来源校验补强。
• 追问2：随机令牌放在哪里？
• 直答2：由可信页面取得并随写请求显式提交，服务端校验与会话绑定、时效和不可预测性。
• 追问3：跨站请求被拒绝要返回详细原因吗？
• 直答3：给用户可操作提示即可，内部记录分类，避免向攻击者暴露防线细节。
• 浏览器安全与网络边界正文

12. 问题（综合题）：认证、前端路由权限和服务端授权如何分工，怎样防止越权导出？

• 考点：身份、角色、租户、对象级授权、短时下载和审计。
• 回答思路：用“是谁、能做什么、能操作哪条数据、当前能否做”四层回答。
• 详细答案：前端权限只改善导航与误操作，服务端必须逐请求验证主体、租户、资源归属、动作和状态。
• 进阶追问：拿到导出任务标识是否可以直接下载？
• 进阶回答：不可以，下载时必须重新鉴权并核对任务归属、文件版本、有效期和当前权限。
• 口述答案：我会把认证与授权明确分开。认证证明当前主体是谁，前端据此生成菜单、路由和按钮，减少误操作并提供一致体验；但这些控制都运行在用户设备上，可以被修改或绕过，所以绝不是安全边界。服务端每个 API（应用程序接口）都要校验主体、租户、角色、资源归属、动作和业务状态，例如能查看订单不代表能退款，能创建导出不代表能下载另一个租户的文件。对象标识采用不可预测值只能降低枚举风险，不能代替对象级授权。异步导出创建时保存申请人、租户、筛选摘要、权限快照和审计信息；执行阶段按服务端权限裁剪数据；下载阶段再次校验当前权限、任务归属、文件摘要和过期时间，再签发短时地址。权限被回收、账号注销或文件过期后，旧地址应失效。管理员同样受作用域、审批、时效和审计约束，高风险资金与批量数据不设置永久万能权限。测试使用两个租户、同角色不同资源和权限变更中的任务，尝试横向与纵向越权。监控记录拒绝原因、主体、资源类型和构建版本，但不在日志泄露敏感数据。若发现越权，先撤销相关地址与会话，暂停批量导出，保存访问记录并评估数据暴露；修复后重跑权限矩阵、检查历史文件和通知受影响方，不能只隐藏前端按钮。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
• 追问1：权限快照和当前权限冲突时听谁的？
• 直答1：执行与下载应按业务风险重新校验当前权限，快照用于审计，不能让已撤销权限继续生效。
• 追问2：服务端每次授权会不会太慢？
• 直答2：可缓存稳定策略，但资源归属和撤权需要可及时失效，性能不能成为省略授权的理由。
• 追问3：拒绝时返回资源不存在还是无权限？
• 直答3：对外避免泄露资源存在性，内部保留准确分类和审计证据。
• 异步导出架构与安全方案

13. 问题（综合题）：关键页面局部报错时，如何设计错误边界、降级与恢复验证？

• 考点：故障域、未知态、用户输入保留、监控关联和业务验收。
• 回答思路：按隔离范围、证据、降级能力、修复和退出条件展开。
• 详细答案：错误边界只负责隔离部分运行时异常，网络与业务失败还需显式状态机，降级不能伪造成功。
• 进阶追问：整页刷新为什么不是通用恢复方案？
• 进阶回答：可能形成刷新循环、丢失用户输入和事故证据，也无法解决服务端未知态或契约错误。
• 口述答案：我会先按业务价值划分故障域，而不是用一个全局捕获把所有错误变成同一白屏。支付摘要、确认动作、履约轨迹、图表和辅助推荐分别隔离；辅助区域失败可以隐藏或显示占位，支付与退款动作失败必须保留订单、请求号和当前权威状态，绝不能从异常推断业务失败。React（前端框架）错误边界或 Vue3（前端框架）错误处理链负责捕获渲染与生命周期异常，事件回调、异步拒绝、网络超时和服务端业务错误由各自状态机处理。错误上报携带路由、构建版本、组件、用户操作序列、契约版本和 Trace（链路追踪） ID（标识），同时脱敏用户数据。界面给出与风险匹配的出口：只读摘要、保存草稿、重试读取、转人工或安全退出，不提供可能重复支付或重复履约的盲重试。发现错误率上升先按版本和路由定界，通过功能开关关闭非关键模块或回退资源，保住查单和订单查询。修复后用原始响应与操作序列回放，覆盖慢网、旧缓存、未知枚举和组件异常，再按小流量恢复。验收同时看白屏率、错误复发、输入保留和支付、履约、导出业务状态是否一致。复盘要把缺失的边界、回退开关、契约测试和用户恢复路径变成明确任务，而不是简单增加捕获语句。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
• 追问1：错误降级可以展示缓存旧数据吗？
• 直答1：可以用于只读参考，但必须标明时间和可能过期，写操作前重新读取权威状态。
• 追问2：同一错误如何避免重复上报风暴？
• 直答2：按错误指纹、版本和时间窗聚合采样，同时保留受影响会话与业务数量。
• 追问3：恢复后只观察半分钟够吗？
• 直答3：不够，应覆盖缓存刷新、后台轮询和一个完整业务窗口，并设置明确回退阈值。
• 前端全栈排障与综合题正文

14. 问题（综合题）：履约轨迹页面如何处理重复、乱序、断线和灰度版本差异？

• 考点：原始事件、版本水位、状态偏序、实时降级和兼容枚举。
• 回答思路：从权威快照到增量续传，再讲冲突、断线与发布。
• 详细答案：服务端裁决权威轨迹，客户端从快照水位增量展示，重复去重、终态不倒退、断线可重拉。
• 进阶追问：客户端收到更晚的发生时间是否一定覆盖？
• 进阶回答：不一定，还要看渠道序列、事件类型和状态偏序，时间可能缺失、回拨或被修正。
• 口述答案：我会把履约页面建模为“权威快照加增量事件”，而不是让最后到达的消息直接覆盖当前状态。首次加载由服务端按订单权限返回包裹、当前状态、轨迹列表、版本水位和更新时间；浏览器从该水位建立 SSE（服务器发送事件）或 WebSocket（全双工通信协议）连接。每个事件包含稳定标识、发生时间、接收时间、渠道码和版本，客户端先按标识去重，再按服务端给出的状态偏序展示，签收或退回完成不能被迟到的运输中事件倒退。客户端排序只是展示，最终冲突由服务端结合承运商规则和原始报文裁决。实时连接断开时保存最后水位，使用带抖动的退避重连；超过预算降级为条件轮询，并明确显示最后更新时间，不能伪装实时。若水位已过期或服务端无法续传，重新获取完整快照并原子替换。契约灰度时，新事件枚举对旧前端映射为“处理中”并保留原始描述，避免误显示失败或签收。观测按渠道、构建版本统计断线、重连、重复、迟到拒绝和快照重拉，同时关联履约业务终态。事故止血先关闭有问题的实时实现，保留只读查询；修复后回放重复、乱序、断线和新旧枚举样本，确认终态单调、通知不重复、多个客户端结果一致。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
• 追问1：断线后是否立即全量拉取？
• 直答1：优先按水位续传，水位失效才全量快照，避免每次抖动都制造回源洪峰。
• 追问2：重复事件是否可以直接丢弃？
• 直答2：展示可去重，但服务端应保留必要原始证据和重复计数，便于审计渠道异常。
• 追问3：旧前端不认识签收新状态怎么办？
• 直答3：兼容层映射到不破坏终态的旧语义，并推动升级，不能让未知枚举倒退。
• 履约面单轨迹项目串讲

15. 问题（综合题）：一次前端灰度导致支付未知态、履约断线和导出请求风暴，你如何指挥处置？

• 考点：事故定界、功能开关、资源竞争、证据链、分档恢复和复盘。
• 回答思路：按现象、假设、止血、查证、修复、验证和复盘讲完整闭环。
• 详细答案：先阻止影响扩大并保护查单等关键能力，再以版本和资源证据确认共同根因，恢复必须通过业务不变量。
• 进阶追问：三个业务同时异常是否能直接判定前端发布是根因？
• 进阶回答：不能，只能作为高优先级假设，还要用版本切片、资源水位、链路样本和回退效果证明。
• 口述答案：我会先建立统一时间线和事故指挥，按构建版本、租户、路由和开始时间统计支付未知态、履约实时断线、导出请求率与后端线程连接水位，避免三个团队分别宣布结论。第一步止血是关闭新前端的自动重连与轮询开关，回退版本清单，限制异常构建请求；支付页禁止换号重试并保留原号查单，履约降级为低频权威查询，导出暂停后台自动刷新但保留人工查询。第二步建立竞争假设：新代码立即重试、服务端容量下降、共享网关故障或外部依赖变慢。通过异常会话的操作序列、网络瀑布、Trace（链路追踪） ID（标识）、发布记录和资源池证据逐一验证。若确认重连循环把所有任务注册到共享定时器，就修复生命周期清理、指数退避、随机抖动、单页面并发和全局重试预算，同时让三类业务分舱，避免导出耗尽支付查单资源。验证先在隔离环境回放断线、超时和路由切换，再按 1%、5%、20%、50%、100% 灰度，每档观察请求斜率、错误和高分位交互。业务出口更重要：支付渠道、本地单与账务一致，履约水位连续且终态不倒退，导出任务和文件可交付。观察完整业务窗口后才解除保护。复盘补充发布门禁、故障注入、重试预算、开关所有者和再次演练日期，并清楚区分事实、推断和演练数据。前端问题的验收不能只看页面是否恢复，还要把构建版本、契约版本、用户动作、服务端响应和业务结果串起来；我会用小流量复演证明止血、回退、兼容和降级都有效，再把边界写进发布门禁，避免下次靠人工经验临场判断。同时保留原始样本。
• 追问1：为什么不先扩容服务端？
• 直答1：无界重试会吞掉新增容量并放大下游压力，先切断放大器，再评估是否需要容量支持。
• 追问2：回退前端后异常未消失怎么办？
• 直答2：检查旧页面残留、缓存资源、服务端积压和外部故障，不能把相关性当成完整因果。
• 追问3：什么时候可以宣布恢复？
• 直答3：技术信号稳定、积压净下降，并且支付、履约、导出业务不变量在观察窗内全部通过。
• 追问4：如何避免复盘变成“加强监控”？
• 直答4：把根因对应到可验收门禁、预算、开关、测试和负责人，并安排失败场景复演。
• 支付履约外部依赖故障追问

11. 复习与现场表达清单

• 能先说清读请求竞态与写请求幂等的区别。
• 能解释 TypeScript（类型脚本）为何不能替代运行时契约校验。
• 能从双端首帧确定性定位 Nuxt3（Vue 服务端渲染框架）水合问题。
• 能用真实用户分位数、主线程、网络与业务结果构建性能证据链。
• 能说明 ECharts（图表库）十万点渲染如何保极值、分层加载和下钻。
• 能区分 XSS（跨站脚本攻击）、CSRF（跨站请求伪造）、认证与对象级授权。
• 能把支付未知态、履约水位和导出交付讲成可验证前端状态机。
• 能设计新旧契约双向兼容、功能开关、灰度指标与回退条件。