4.2.7 接口、状态、实时通信、ECharts（图表库）、可访问性、错误监控与项目落地

定位：把浏览器交互、BFF（后端前端聚合层）、Java（编程语言）服务、异步任务、图表和观测信号连成可恢复的全栈契约。本文只把源码直接证明的内容写成项目事实；未发现的 WebSocket（网页套接字）与 RUM（真实用户监控）一律保留为 E0（未证实）方案，不归因于简历项目。

1. 事实等级、边界与复习主线

复习时先回答“谁拥有权威状态”，再回答“状态如何被获取、展示、刷新、恢复和观测”。浏览器拥有交互瞬时状态，BFF（后端前端聚合层）负责面向页面的聚合和兼容，领域服务拥有库存、订单与支付权威状态；图表只是投影，监控只是证据，二者都不能替代服务端裁决。

1. BFF（后端前端聚合层）边界与 REST（表述性状态转移）资源契约

BFF（后端前端聚合层）应围绕页面用例聚合字段、收敛版本和减少往返，但不能复制库存扣减、支付确认等领域规则。REST（表述性状态转移）资源用稳定标识、方法语义、状态码、版本和错误模型表达业务状态；前端不得把 HTTP（超文本传输协议）成功等同于业务成功。

sequenceDiagram
  participant U as 用户
  participant F as Vue（前端框架）页面
  participant B as BFF（后端前端聚合层）
  participant S as Java（编程语言）服务
  participant O as 观测平台
  U->>F: 打开仓储工作台
  F->>B: GET（读取）页面资源视图
  B->>S: 并行读取库存、订单与权限
  alt 依赖完整
    S-->>B: 返回资源版本与权威状态
    B-->>F: 返回稳定视图契约
    F-->>U: 渲染数据与新鲜度
  else 部分依赖失败
    S-->>B: 返回超时或领域错误
    B-->>F: 返回部分结果与可重试错误
    F->>O: 记录 `Trace ID（链路标识）`与页面状态
    F-->>U: 展示局部错误而非伪成功
  end

图解读。 用户、页面、BFF（后端前端聚合层）、Java（编程语言）服务与观测平台构成五个故障域；箭头表示读取、聚合、返回和留证顺序。成立前提是资源版本、错误码和 Trace ID（链路标识）可跨层传递。正常路径输出可解释视图，失败路径保留局部数据并显式标错，结论是聚合层优化交互但不夺走领域权威。

数据演绎 1。 演练一个工作台需要库存、异常订单和账单三类数据。若浏览器分别请求三次，每次都有独立鉴权、超时和版本窗口；BFF（后端前端聚合层）并行请求后可返回 data、partialErrors、resourceVersion 和 Trace ID（链路标识）。假设账单依赖超时，页面保留库存与订单，账单区进入错误态；用户重试只刷新账单分片。该演绎不代表真实请求数，结论是减少接口放大必须同时保留部分失败语义。

热门面试题

1. 问题：BFF（后端前端聚合层）为什么不能承载库存扣减规则？
   • 考点：聚合边界与领域权威。
   • 回答思路：先区分页面适配和业务不变量，再说明重复规则的风险。
   • 详细答案：BFF（后端前端聚合层）适合字段裁剪、并行聚合、版本兼容和错误归一化；库存可用量、冻结、扣减与释放必须由领域服务在一致性边界内裁决。若聚合层复制规则，不同客户端会出现不同结果，重试还可能绕过锁或事务。前端只展示服务端返回的权威状态，并携带版本继续操作。浏览器网络与缓存
   • 进阶追问：聚合层能否计算展示百分比？
   • 进阶回答：可以计算不改变业务事实的展示派生值，但要标明口径并避免反向写回领域状态。
2. 问题：REST（表述性状态转移）契约如何表达部分失败？
   • 考点：资源、状态码和错误模型。
   • 回答思路：把传输结果、业务结果和子资源结果分层。
   • 详细答案：先用 HTTP（超文本传输协议）状态表达整体请求是否可处理，再用稳定业务码表达领域结果，并在聚合响应中为每个子资源附加状态、可重试性和 Trace ID（链路标识）。不可用的分片不应补零伪装成功；可用分片仍可展示，同时给出新鲜度和局部重试入口。
   • 进阶追问：为什么不总返回二百状态？
   • 进阶回答：会让网关、监控和客户端失去传输语义，重试与告警也难以按责任层分流。
3. 问题：如何演进接口而不同时发布前后端？
   • 考点：兼容性与版本治理。
   • 回答思路：从加字段、废弃字段、破坏性变更和观测四步回答。
   • 详细答案：优先做向后兼容的可选字段和默认语义；废弃字段先观测调用，再经过公告窗口移除；破坏性变更使用新资源版本或能力协商。BFF（后端前端聚合层）可暂时适配旧页面，但适配代码要有移除条件，错误响应要携带支持版本，不能靠前端猜测。
   • 进阶追问：默认值会有什么风险？
   • 进阶回答：默认值可能把未知状态伪装成零或否，关键业务字段应显式为空并阻止危险操作。

2. 鉴权、刷新令牌与权限路由

认证回答“你是谁”，授权回答“你能做什么”。访问令牌应短期使用，刷新令牌只用于换取新访问令牌；刷新过程必须单飞合并，失败后清空身份派生状态。前端权限路由改善体验，Java（编程语言）服务仍要对每个资源和动作做最终授权。

sequenceDiagram
  participant F as Vue（前端框架）页面
  participant Q as 请求协调器
  participant A as 鉴权服务
  participant P as 权限服务
  participant R as 路由器
  F->>Q: 并发发起两个受保护请求
  Q->>A: 携带访问令牌
  A-->>Q: 返回令牌过期
  Q->>A: 单飞刷新令牌
  alt 刷新成功
    A-->>Q: 新访问令牌
    Q-->>F: 仅重放安全请求
    F->>P: 获取导航与权限
    P-->>R: 生成允许的运行时路由
  else 刷新失败
    A-->>Q: 身份失效
    Q-->>F: 取消等待请求并清空身份
    F-->>R: 移除运行时路由并转登录
  end

图解读。 请求协调器把并发过期响应合并成一次刷新，避免令牌风暴；刷新成功只重放满足幂等条件的请求，失败则取消队列并清理身份。E1（直接证据）仅确认本地用户仓库持有令牌、清理身份，权限仓库会装卸运行时路由；刷新令牌流程仍属于 E3（通用机制），待源码或现场核对。

数据演绎 2。 演练五个接口同时收到令牌过期。若每个接口都刷新一次，会产生五次刷新和最多五轮重放；单飞协调器只保留一个刷新承诺，其余四个等待。刷新成功后，三个只读请求自动重放，一个带幂等键的写请求可重放，一个无幂等保护的写请求要求用户确认。数字仅用于推导，结论是刷新成功不等于所有请求都可安全重试。

热门面试题

1. 问题：为什么前端权限路由不是安全边界？
   • 考点：体验控制与强制授权。
   • 回答思路：从攻击者可绕过页面、服务端掌握资源两个角度回答。
   • 详细答案：前端路由和按钮都运行在用户可控制的浏览器里，请求可以绕过页面直接构造；它们只能减少误操作和无效入口。Java（编程语言）服务必须根据身份、租户、业务线、资源归属和动作逐次鉴权，并记录拒绝证据。E1（直接证据）表明本地权限仓库能动态装卸路由，但不能据此声称后端授权已完整验证。Vue（前端框架）状态与路由
   • 进阶追问：后端已鉴权还需要隐藏按钮吗？
   • 进阶回答：需要，隐藏无权入口能降低困惑和无效流量，但不能替代服务端校验。
2. 问题：刷新令牌并发风暴如何处理？
   • 考点：并发合并与失败传播。
   • 回答思路：说明单飞状态、等待队列和终止条件。
   • 详细答案：全局只允许一个刷新请求，其他过期请求订阅同一结果；成功后按请求可重试性重放，失败则统一拒绝、清空身份和跳转登录。刷新接口本身不得进入刷新拦截器，队列必须有超时，页面卸载的请求应取消，避免无限循环与内存滞留。
   • 进阶追问：写请求可以自动重放吗？
   • 进阶回答：只有服务端幂等、带稳定幂等键且请求体可重放时才可自动执行，否则要求用户确认。
3. 问题：身份切换后为什么要移除旧路由？
   • 考点：派生状态隔离。
   • 回答思路：把令牌、用户信息、权限和组件缓存视为一组身份快照。
   • 详细答案：只替换令牌会让旧角色、旧业务线、旧动态路由和缓存页面继续可见，形成展示越权甚至误操作。应先取消旧请求，再清空身份派生状态与运行时路由，随后获取新身份和导航。E1（直接证据）可见本地用户仓库清理身份、权限仓库移除并重建路由，生产会话切换效果仍需现场验证。
   • 进阶追问：组件缓存也要清理吗？
   • 进阶回答：要按身份键隔离或销毁，否则旧页面内存中的敏感数据可能在新身份下短暂出现。

3. 幂等键、统一错误与重试预算

幂等要求同一业务意图重复到达时只产生一次权威副作用。客户端生成并持久化一次操作的幂等键，服务端把幂等键、调用方和操作类型绑定；统一错误同时提供稳定业务码、可重试标志、用户文案键和 Trace ID（链路标识）。重试预算限制尝试次数、累计等待和并发放大。

sequenceDiagram
  participant U as 用户
  participant F as 前端
  participant B as BFF（后端前端聚合层）
  participant S as Java（编程语言）服务
  participant D as 幂等记录
  U->>F: 提交导出
  F->>B: POST（创建）并携带幂等键
  B->>S: 转发同一业务意图
  S->>D: 原子登记键与请求摘要
  alt 首次请求
    D-->>S: 允许执行
    S-->>F: 返回任务资源
  else 同键同摘要
    D-->>S: 返回既有结果
    S-->>F: 返回同一任务资源
  else 同键不同摘要
    D-->>S: 拒绝冲突
    S-->>F: 返回不可重试错误与 `Trace ID（链路标识）`
  end

图解读。 幂等记录处于副作用之前，同键同摘要复用结果，同键不同摘要拒绝，防止错误复用。网络超时只说明客户端没收到结果，不代表服务端未执行；因此重试必须复用原键。失败分支提供 Trace ID（链路标识）而不是盲目扩大次数。

flowchart LR
  E[错误] --> T{传输还是业务}
  T -->|传输瞬态| R{预算还有余量}
  T -->|业务可恢复| U[提示修正输入]
  T -->|业务不可恢复| S[停止并留证]
  R -->|是| J[抖动退避后重试]
  R -->|否| D[降级或人工恢复]

图解读。 错误先分类再决定动作；预算是次数、时间和并发的共同上限。用户输入错误不可自动重试，支付未知态改为查询确认，限流遵循服务端退避提示。结论是“可重试”是契约属性，不是所有失败的默认动作。

数据演绎 3。 演练一个请求最多尝试三次，等待序列为一、二、四个时间单位并加入随机抖动；若第一次耗时已占满总预算，就不再重试。十个页面同时失败时还要受全局并发预算约束，避免三十个请求压垮恢复中的服务。数字是演练参数，不是生产配置，实际次数、退避和限流提示应由容量验证确定。

热门面试题

1. 问题：幂等键为什么要绑定请求摘要？
   • 考点：重复意图与键误用。
   • 回答思路：区分同一请求重放和不同请求碰巧复用同一键。
   • 详细答案：幂等键只标识一次业务意图，若不校验调用方、操作类型和请求摘要，客户端误复用键可能拿到另一笔操作的结果。服务端首次登记键与摘要，后续同键同摘要返回原结果，同键不同摘要返回冲突；键还要有与业务恢复窗口匹配的保留期。
   • 进阶追问：键由前端还是后端生成？
   • 进阶回答：可以由前端在用户意图产生时生成，也可由后端预分配；关键是重试复用且服务端原子裁决。
2. 问题：什么请求不应该自动重试？
   • 考点：副作用、未知态与重试安全。
   • 回答思路：按只读、幂等写、非幂等写和业务错误分类。
   • 详细答案：参数错误、权限拒绝和明确业务拒绝不应重试；非幂等写在结果未知时也不能直接重放，应先按业务标识查询权威状态。只读和有服务端幂等保护的写请求可在预算内重试，还要尊重取消、限流提示和总截止时间。JavaScript（脚本语言）异步机制
   • 进阶追问：网关超时为何仍不能断言失败？
   • 进阶回答：超时只描述响应未按时到达，服务端可能已经提交副作用，必须查询确认。
3. 问题：统一错误对象至少需要哪些字段？
   • 考点：用户体验与跨端定位。
   • 回答思路：分别覆盖机器决策、用户展示和工程排障。
   • 详细答案：至少需要稳定业务码、可重试性、用户文案键、字段级错误、Trace ID（链路标识）和可选的退避提示；传输状态仍保留 HTTP（超文本传输协议）语义。前端按码决定重试、聚焦、降级或确认，不展示内部堆栈，也不把敏感请求体写进日志。
   • 进阶追问：文案能直接由后端返回吗？
   • 进阶回答：可返回受控文案键和安全参数；最终展示由前端本地化，避免泄露内部信息。

4. 分页、游标、筛选与排序契约

偏移分页适合稳定小集合和随机跳页，游标分页适合持续变化的大集合。游标必须编码排序键、唯一兜底键和查询上下文；筛选字段、操作符与排序字段采用白名单，前端不拼接数据库表达式。返回结果应说明是否还有下一页、快照或版本语义。

sequenceDiagram
  participant F as 前端列表
  participant B as BFF（后端前端聚合层）
  participant S as 查询服务
  participant D as 数据库
  F->>B: 请求筛选、排序与页大小
  B->>S: 校验白名单并传递游标
  S->>D: 按排序键和唯一键查询多一条
  D-->>S: 返回候选结果
  alt 游标仍有效
    S-->>F: 返回数据、下一游标和版本
  else 游标失效或上下文变化
    S-->>F: 返回游标失效错误
    F->>F: 保留筛选并从首段刷新
  end

图解读。 查询先校验再执行，数据库多取一条判断后续页；游标绑定排序和筛选上下文，条件变化时不能沿用。失败不是静默回到第一页，而是保留用户筛选并明确刷新，以免重复或漏读被误认为完整。

数据演绎 4。 演练按“更新时间倒序、标识倒序”读取，每页三条。首段返回时间为十点的标识九、八、七，并生成包含“十点、七、筛选摘要”的游标；此时插入标识十，下一段仍从七之后继续，不会把十插入已读窗口。若只按非唯一时间排序，七与六同一时间可能重复或漏读。结论是游标稳定性来自完整排序元组。

热门面试题

1. 问题：为什么游标必须包含唯一兜底键？
   • 考点：稳定排序与边界重复。
   • 回答思路：用多个记录排序值相同的场景解释。
   • 详细答案：只有时间或状态等非唯一排序键时，页边界无法唯一定位，同值记录可能在下一次查询中换序，造成重复或漏读。游标应包含主排序键和唯一标识，并固定升降序；服务端用完整元组构造严格大于或小于条件。
   • 进阶追问：游标可以明文吗？
   • 进阶回答：可编码但不应让客户端改写；敏感或需防篡改时应签名，并验证查询上下文。
2. 问题：筛选排序为什么要服务端白名单？
   • 考点：安全、索引与契约稳定。
   • 回答思路：从注入风险、昂贵查询和字段演进回答。
   • 详细答案：客户端传任意字段或表达式会扩大注入、全表扫描和内部字段泄露风险。服务端把公开筛选名映射到受控字段与操作符，同时限制组合复杂度、页大小和排序集合；前端根据能力元数据构造界面，而不是拼数据库语句。
   • 进阶追问：前端白名单是否多余？
   • 进阶回答：前端白名单改善体验并减少无效请求，服务端白名单才是强制边界，两者职责不同。
3. 问题：库存列表变化频繁时如何避免分页误导？
   • 考点：快照、新鲜度与刷新策略。
   • 回答思路：说明权威状态、列表快照和用户提示。
   • 详细答案：列表响应携带查询时间、版本或快照标识；游标绑定该上下文。用户执行库存操作前仍要按版本重新校验单条权威状态，页面显示数据新鲜度并提供刷新。若游标过期，保留筛选从首段重新读取，不能把旧页与新页直接拼成完整集合。
   • 进阶追问：总数必须精确吗？
   • 进阶回答：不一定；大集合可返回估算或省略总数，但必须明确语义，不能把估算当精确值。

5. 取消、防抖、请求竞态、缓存与陈旧数据

防抖减少高频输入触发，取消释放不再需要的网络与回调，序列号或查询键阻止旧响应覆盖新状态。缓存键必须包含身份、租户、筛选和版本；stale-while-revalidate（陈旧时后台再验证）可先展示旧数据再刷新，但关键操作前要重新确认权威状态。

sequenceDiagram
  participant U as 用户
  participant F as 搜索组件
  participant C as 请求协调器
  participant S as 服务端
  U->>F: 输入条件 A
  F->>C: 防抖后发起请求 A
  U->>F: 立即改为条件 B
  F->>C: 取消 A 并发起 B
  C->>S: 请求 B
  S-->>C: 返回 B
  C-->>F: 查询键匹配，提交 B
  S-->>C: A 的迟到响应
  alt A 已取消或序列过旧
    C-->>F: 丢弃 A，不改状态
  else 错误实现
    C-->>F: A 覆盖 B，产生陈旧界面
  end

图解读。 取消并不保证服务端停止，但能阻止前端继续消费；最终提交还要校验查询键或序列号。缓存命中也走同一提交规则，避免旧身份或旧筛选污染。组件卸载时取消请求和计时器，防止无主回调更新状态。

数据演绎 5。 演练用户依次输入 A、AB、ABC，防抖窗口内只发送 ABC；若 A 已经发送且耗时五个单位，ABC 耗时一个单位，则 ABC 先返回。仅靠加载标记会让 A 最后覆盖结果；加入递增序列后，A 的序列小于当前值而被丢弃。若缓存键漏掉仓库标识，即使序列正确也可能展示另一仓库数据，所以竞态控制与缓存隔离必须同时成立。

热门面试题

1. 问题：取消请求后为什么还要校验响应序列？
   • 考点：取消语义与迟到响应。
   • 回答思路：说明取消可能失败、服务端可能已完成和缓存可能同步返回。
   • 详细答案：取消通常只表达客户端不再关心，网络栈、代理或服务端可能已经完成，旧承诺仍可能回调；缓存读取甚至不受网络取消影响。因此每次查询都要生成序列或完整查询键，提交状态前比较当前值，旧结果只能进入诊断日志不能更新界面。
   • 进阶追问：加载状态如何避免闪烁？
   • 进阶回答：加载状态也按查询键计数，旧请求结束不能关闭新请求的加载提示，可设置最短展示时间。
2. 问题：陈旧缓存适合库存页面吗？
   • 考点：新鲜度与业务风险。
   • 回答思路：区分浏览、决策和写操作。
   • 详细答案：浏览趋势或非关键汇总可先展示带时间戳的陈旧数据并后台刷新；库存分配、扣减、支付等决策不能依赖缓存投影，提交前必须携带版本让服务端重新校验。页面要明确新鲜度和刷新失败，不能用旧值配绿色成功状态。
   • 进阶追问：离线时能否继续操作？
   • 进阶回答：可允许只读浏览已标记的缓存；写操作需排队并明确未提交，恢复后仍由服务端幂等裁决。
3. 问题：缓存键需要包含哪些维度？
   • 考点：隔离与命中正确性。
   • 回答思路：从身份、业务上下文、查询条件和版本回答。
   • 详细答案：至少包含租户或业务线、用户权限视角、资源名、筛选、排序、分页或游标、语言和契约版本；敏感数据还要与身份生命周期绑定。登出、身份切换或权限变化时失效相关缓存，服务端验证信息可配合条件请求。浏览器缓存边界
   • 进阶追问：对象序列化顺序会影响键吗？
   • 进阶回答：会，应规范化字段顺序和空值语义，否则同一查询产生多个键，降低命中并增加竞态。

6. 库存查询全栈契约

库存查询要区分现存量、冻结量、可用量、在途量和数据版本，口径由服务端定义。前端筛选仓库与商品后读取投影，展示时间和来源；任何分配或释放操作携带版本，冲突时刷新而不是本地强行覆盖。库存差异属于待处理状态，不应被前端自动归零。

sequenceDiagram
  participant U as 仓储人员
  participant F as WMS（仓储管理系统）页面
  participant B as BFF（后端前端聚合层）
  participant I as 库存服务
  participant D as 库存存储
  U->>F: 按仓库与商品查询
  F->>B: 发送筛选、游标与请求标识
  B->>I: 查询库存投影
  I->>D: 读取数量、冻结与版本
  D-->>F: 返回口径、新鲜度和版本
  U->>F: 发起库存调整
  F->>I: 携带版本与幂等键
  alt 版本一致
    I-->>F: 返回新版本与权威结果
  else 版本冲突
    I-->>F: 返回冲突和当前版本
    F-->>U: 保留输入并提示刷新比较
  end

图解读。 读取投影服务于浏览，写入仍进入库存服务的一致性边界。版本冲突是并发保护信号，不是通用错误；前端要展示旧值、新值和用户输入的差异，让用户决定重试或放弃。E2（结构佐证）只支持把库存差异映射为 WMS（仓储管理系统）场景，不支持声称真实冲突率或处理收益。

数据演绎 6。 演练现存量一百、冻结量三十、质检隔离十，则某口径下可用量为六十；用户打开页面后另一订单又冻结五，服务端版本从七变为八。用户按版本七提交调整，服务端拒绝并返回版本八及可用量五十五。这里的数值仅用于演算，不是项目指标；关键结论是前端不能用最初的六十覆盖新状态。

热门面试题

1. 问题：库存查询为什么要返回版本？
   • 考点：读写并发与乐观控制。
   • 回答思路：从页面停留时间和服务端并发变化解释。
   • 详细答案：页面展示只是某时刻快照，用户操作前库存可能因订单、取消或盘点变化。写请求携带读取版本，服务端比较当前版本；一致才执行，不一致返回冲突和当前值。这样把无声覆盖变成可恢复分支，也便于关联审计。
   • 进阶追问：冲突后能自动重试吗？
   • 进阶回答：纯查询可以刷新；调整操作需重新评估用户意图，通常展示差异后确认，不能盲目重放。
2. 问题：库存页面为何不能只展示一个数量？
   • 考点：业务口径与可解释性。
   • 回答思路：区分现存、冻结、隔离、在途和可用。
   • 详细答案：单一数字会掩盖数量组成，用户无法判断差异来自冻结、质检、在途还是同步延迟。接口应返回受控口径及组成，页面提供摘要和可展开明细，并显示数据时间；最终可分配性仍由服务端在提交时判断。
   • 进阶追问：组成明细会不会过大？
   • 进阶回答：摘要先返回，明细按需分页读取；不要为首屏一次聚合全部流水。
3. 问题：库存差异如何做跨端排障？
   • 考点：证据链与责任分层。
   • 回答思路：按用户条件、请求、服务版本、流水和异步事件追踪。
   • 详细答案：先固定仓库、商品、时间、页面版本和 Trace ID（链路标识），再核对请求筛选、响应口径与版本；随后由后端检查库存流水、冻结记录、消息消费和补偿任务。前端保留原始错误码和新鲜度，不自行改数。项目具体链路和指标需按现场证据核对。4.2.0 事实账本
   • 进阶追问：先刷新页面是否足够？
   • 进阶回答：刷新只能验证陈旧投影，若权威流水不平仍需后端沿业务标识和事件链排查。

7. 异步导出任务契约

大导出不应占用同步请求直到文件生成，而应创建任务资源。创建请求携带筛选快照和幂等键，服务端返回任务标识；前端查询状态，任务完成后获取短期下载凭证。取消只在任务允许时生效，失败要区分参数、容量、权限和执行错误。

sequenceDiagram
  participant U as 用户
  participant F as 前端
  participant S as 导出服务
  participant R as Runner（执行器）
  participant O as 对象存储
  U->>F: 提交导出条件
  F->>S: 创建任务并携带幂等键
  S-->>F: 返回任务标识与查询建议
  S->>R: 调度异步任务
  loop 在预算内查询
    F->>S: 查询任务状态
    S-->>F: 排队、执行中或进度阶段
  end
  alt 任务成功
    R->>O: 写入文件
    S-->>F: 返回完成与短期下载凭证
  else 任务失败或过期
    S-->>F: 返回稳定错误码与 `Trace ID（链路标识）`
    F-->>U: 提供重建任务或修改条件
  end

图解读。 创建、执行、查询和下载是四个独立契约；轮询有服务端建议和前端预算，不是固定高频请求。下载凭证短期有效且与权限绑定，任务状态保留失败阶段，便于区分生成失败和下载失败。Runner（执行器）在本节是通用架构角色，不据此宣称本地前端已接入具体调度平台。

数据演绎 7。 演练任务查询退避为二、四、八个时间单位，页面切到后台后再降频；任务在第三次查询后完成，前端获取一次短期凭证。若第一次创建响应超时，前端用原幂等键查询或重试创建，得到同一任务；若用户修改筛选，则生成新键。数字仅用于说明预算和意图区分，不是生产轮询周期。

热门面试题

1. 问题：异步导出为何要建模成任务资源？
   • 考点：长任务、状态机和恢复。
   • 回答思路：对比同步连接和可查询任务。
   • 详细答案：同步等待会占用连接，浏览器断开后难判断任务是否继续，也不利于限流、取消和重试。任务资源有稳定标识、筛选快照、状态、更新时间、失败码和产物引用，页面关闭后仍能恢复查询；创建任务用幂等键防重复。
   • 进阶追问：进度百分比必须精确吗？
   • 进阶回答：不必须；若总量不稳定，展示阶段与更新时间比伪精确百分比更可信。
2. 问题：导出轮询如何避免形成流量峰值？
   • 考点：退避、抖动和可见性。
   • 回答思路：从服务端建议、客户端预算和页面生命周期回答。
   • 详细答案：服务端返回建议查询间隔，客户端采用递增退避和随机抖动；页面不可见时降频，完成、失败、取消或超过总预算后停止。多个任务可合并查询，服务端也应按用户限制并发与队列，避免导出压力反向拖慢在线查询。
   • 进阶追问：能否改用 SSE（服务器发送事件）？
   • 进阶回答：可以作为方案，但要评估连接数、代理超时和断线恢复；本地是否存在该通道为 E0（未证实）。
3. 问题：导出完成但下载失败如何定位？
   • 考点：阶段化错误与安全下载。
   • 回答思路：分开任务生成、凭证签发、对象存储和浏览器下载。
   • 详细答案：先确认任务已完成及产物摘要，再核对凭证是否过期、用户权限、对象是否存在、跨域和网络响应；记录任务标识、Trace ID（链路标识）和下载阶段错误。重新获取凭证不应重新生成文件，除非产物已过期或校验失败。
   • 进阶追问：文件名可以直接信任后端吗？
   • 进阶回答：应清理控制字符和路径片段，并使用受控内容类型，避免响应拆分与危险文件解释。

8. 支付未知态与确认契约

支付请求超时、页面关闭或回调乱序时，前端不能把“没收到成功”显示为失败。应以支付单标识和幂等键创建意图，把页面状态建模为待提交、处理中、待确认、成功、明确失败和已关闭；未知态只允许查询权威支付单，不能重新扣款。服务端结合渠道查询、回调、账本与对账裁决。

sequenceDiagram
  participant U as 用户
  participant F as 前端
  participant P as 支付服务
  participant C as 支付渠道
  participant L as 账本与对账
  U->>F: 确认支付
  F->>P: 携带支付单标识与幂等键
  P->>C: 发起渠道请求
  alt 明确成功
    C-->>P: 成功
    P->>L: 记录权威结果
    P-->>F: 返回成功
  else 明确失败
    C-->>P: 业务拒绝
    P-->>F: 返回明确失败
  else 超时或响应丢失
    P-->>F: 返回待确认与 `Trace ID（链路标识）`
    F->>P: 只查询原支付单
    P->>C: 查询渠道并结合回调
    P->>L: 对账后裁决
    P-->>F: 返回最终或仍待确认
  end

图解读。 明确失败与未知态分开；未知态不产生新支付意图，只围绕原支付单查询。渠道回调也不是前端直接信任的消息，而是服务端验签、去重并落账后改变权威状态。本文不声称本地前端存在某支付通道实现，只提供 E3（通用机制）契约。

数据演绎 8。 演练支付服务向渠道发送后在五个时间单位超时，渠道在第六个单位返回成功。若前端超时即显示失败并允许新支付，可能产生第二个意图；正确做法是原支付单进入待确认，按预算查询，最终读取成功。若长时间仍未知则转账单待办和人工核对。时间只用于状态推导，不是渠道 SLA（服务等级协议）。

热门面试题

1. 问题：支付超时为什么不能提示支付失败？
   • 考点：分布式未知态。
   • 回答思路：区分通信结果和业务提交结果。
   • 详细答案：超时只说明响应没有按期到达，渠道可能已扣款、支付服务可能已落单，也可能完全未受理。若直接提示失败并允许重付，会放大重复扣款风险。页面应进入待确认，保留原支付单和幂等键，通过查询、回调落账与对账得到权威结论。
   • 进阶追问：待确认多久后算失败？
   • 进阶回答：不能由前端自行计时裁决；超过业务窗口后由服务端关闭或转人工，页面展示服务端状态。
2. 问题：支付回调后前端如何刷新？
   • 考点：服务端权威与刷新触发。
   • 回答思路：先说明回调落在服务端，再比较轮询、推送和返回页面刷新。
   • 详细答案：渠道回调先由服务端验签、去重、更新支付单和账本；前端只读取已裁决状态。可在返回页面立即查询，并在有限预算内轮询；SSE（服务器发送事件）或 WebSocket（网页套接字）只能作为方案。本地实时通道为 E0（未证实），不能写成项目事实。
   • 进阶追问：前端能直接接渠道回调吗？
   • 进阶回答：不能作为权威链路，浏览器无法承担密钥、验签、持久化和可靠重试责任。
3. 问题：支付状态与订单状态为何要分开？
   • 考点：状态机边界和最终一致。
   • 回答思路：说明两个聚合的生命周期和补偿不同。
   • 详细答案：支付成功不等于订单履约已完成，订单取消也不等于退款已到账；二者有独立标识、状态机和失败恢复。页面可聚合展示，但必须分别标注支付、订单和退款状态，BFF（后端前端聚合层）不能把多个未知态压成一个布尔值。
   • 进阶追问：页面如何避免用户误解？
   • 进阶回答：按业务阶段展示明确文案和时间，提供各状态详情，不用单一颜色代替状态说明。

9. Polling（轮询）、SSE（服务器发送事件）、WebSocket（网页套接字）与回调后刷新

通信方式按更新方向、频率、连接成本、代理兼容、顺序、断线恢复和浏览器后台策略选择。Polling（轮询）简单但有空查，SSE（服务器发送事件）适合服务端单向事件流，WebSocket（网页套接字）适合真正双向低延迟会话，回调后刷新适合支付返回页、导出通知等外部事件后的权威查询。推送只提示“可能变化”，前端仍应按资源版本刷新。

sequenceDiagram
  participant F as 前端
  participant G as 网关
  participant S as 服务端
  participant D as 权威存储
  F->>G: 建立订阅或周期查询
  G->>S: 鉴权并绑定游标
  S-->>F: 发送变更提示与事件标识
  alt 连续且顺序完整
    F->>S: 按资源版本读取增量
    S->>D: 查询权威状态
    D-->>F: 返回新版本
  else 断线、事件缺口或令牌过期
    F->>S: 携带最后事件标识恢复
    S-->>F: 补发或要求全量刷新
  end

图解读。 订阅层负责变化提示和恢复游标，领域查询负责权威数据。断线后若服务端无法补发，客户端必须全量刷新；令牌续期、代理空闲超时和后台降频都是连接生命周期的一部分。E0（未证实）边界：指定本地证据未发现 SSE（服务器发送事件）或 WebSocket（网页套接字）接入。

sequenceDiagram
  participant X as 外部系统
  participant S as Java（编程语言）服务
  participant F as 返回页面
  X->>S: 服务端回调
  S->>S: 验签、去重并更新状态
  F->>S: 页面恢复后查询业务标识
  alt 状态已裁决
    S-->>F: 返回最终状态与版本
  else 状态仍处理中
    S-->>F: 返回待确认和下次查询建议
    F->>S: 在预算内再次查询
  end

图解读。 外部回调与浏览器返回没有可靠先后关系，页面恢复后必须查询；回调只在服务端完成安全校验和持久化。该模式连接少、恢复简单，适合低频关键状态，但实时性取决于页面刷新和查询预算。

数据演绎 9。 演练一千个页面每五秒 Polling（轮询）一次，理论入口查询率为每秒二百次；若加入随机抖动只能平滑峰值，不能消除总量。若业务平均一分钟才变化，可改为更长退避或事件提示后刷新。数字用于容量公式，不代表项目流量；选择实时通道前还要计算同时连接、心跳、重连和消息大小。

热门面试题

1. 问题：四种刷新方式如何选择？
   • 考点：实时性、复杂度与容量权衡。
   • 回答思路：先问是否双向、变化频率和丢事件容忍度，再看基础设施。
   • 详细答案：低频且可接受秒级延迟时优先 Polling（轮询）；单向持续事件可选 SSE（服务器发送事件）；真正双向高频才考虑 WebSocket（网页套接字）；外部流程完成后页面只需读权威状态时用回调后刷新。还要评估代理、连接数、断线恢复、鉴权和运维证据。
   • 进阶追问：WebSocket（网页套接字）一定更实时吗？
   • 进阶回答：不一定；服务端生产、队列、背压和重连都会增加延迟，复杂度也更高。
2. 问题：收到推送后为什么还要查询？
   • 考点：事件提示与权威状态。
   • 回答思路：说明事件可能重复、乱序、丢失或只含摘要。
   • 详细答案：推送适合作为失效提示，不一定携带完整、最新且授权后的资源。客户端根据资源标识和版本查询，可统一权限、缓存与错误处理；若事件本身是可重放的完整变更，也仍需校验顺序和版本，发现缺口时全量刷新。
   • 进阶追问：能否直接把事件合并进图表？
   • 进阶回答：可以在版本连续、口径一致时增量合并；否则标记陈旧并重新获取快照。
3. 问题：实时连接如何防止重连风暴？
   • 考点：退避、抖动和服务端保护。
   • 回答思路：从客户端节流、网关限流和恢复游标回答。
   • 详细答案：客户端指数退避并加随机抖动，页面不可见时降频，网络离线时停止；服务端限制用户连接数、握手速率和消息积压，恢复时用最后事件标识补发或要求全刷。实际策略必须容量演练，本地 WebSocket（网页套接字）为 E0（未证实）。
   • 进阶追问：令牌过期如何续期？
   • 进阶回答：连接层收到明确鉴权错误后先刷新身份，再按新令牌重连；避免在消息通道传长期敏感凭证。

10. ECharts（图表库）按需注册与实例生命周期

按需注册只把使用的图表、组件、特性与渲染器纳入依赖图；容器挂载后创建实例，后续数据变化复用实例并调用 setOption，尺寸变化调用 resize，卸载时先解绑窗口、观察器和图表事件，再执行 dispose。同一容器重复 echarts.init 容易产生实例与监听泄漏。

sequenceDiagram
  participant V as Vue（前端框架）组件
  participant C as 图表容器
  participant E as ECharts（图表库）实例
  participant R as ResizeObserver（尺寸观察器）
  V->>C: 挂载并确认尺寸
  V->>E: 初始化一次并注册事件
  V->>E: setOption（设置配置）首次渲染
  R-->>V: 容器尺寸变化
  V->>E: resize（尺寸变化）
  V->>E: setOption（设置配置）增量更新
  alt 组件卸载
    V->>R: 停止观察
    V->>E: off（解绑事件）
    V->>E: dispose（销毁）
  else 容器复用
    V->>E: 复用原实例更新
  end

图解读。 生命周期绑定“容器存在、实例唯一、观察器可清理”三个不变量。E1（直接证据）确认本地类型文件注册多种图表、组件、特性与 CanvasRenderer（画布渲染器），出库趋势组件执行初始化与设置配置；指定证据范围未发现尺寸处理、销毁和事件解绑，因此这些步骤是 E3（通用机制）建议与 E0（未证实）项目缺口。

数据演绎 10。 演练一个页面切换筛选二十次；若每次都在同一容器新建实例且不销毁，理论上可能累积二十个实例相关资源和重复事件。正确实现只保留一个实例，二十次只更新配置；离开页面后实例数回到零。数值用于解释泄漏趋势，不代表本地线上测量，实际应以堆快照、监听器和实例计数验证。

热门面试题

1. 问题：为什么不能每次数据变化都调用 echarts.init？
   • 考点：实例复用和资源生命周期。
   • 回答思路：说明容器与实例是一对一关系，再讲监听和图形资源。
   • 详细答案：初始化会创建渲染上下文、事件系统和内部状态；同一容器反复初始化可能产生警告、重复监听和不可回收资源。应在挂载后保存实例引用，数据变化只调用 setOption，卸载时解绑外部与内部事件并 dispose。本地指定组件确有重复进入渲染函数时再次初始化的代码形态，是否造成线上泄漏仍需运行证据。
   • 进阶追问：如何判断容器已有实例？
   • 进阶回答：优先由组件引用保证唯一，也可通过库提供的按容器取实例能力核对，避免把全局查询当主要状态管理。
2. 问题：resize 应监听窗口还是容器？
   • 考点：布局变化来源。
   • 回答思路：比较窗口变化与侧栏、标签、字体导致的容器变化。
   • 详细答案：只监听窗口会漏掉侧栏折叠、父级网格变化和标签切换；更稳妥是观察容器尺寸并合并高频回调，再调用实例 resize。隐藏容器显示后也要触发一次，卸载时停止观察，避免无主回调。
   • 进阶追问：每次变化立即重排吗？
   • 进阶回答：可按动画帧合并，减少布局抖动；关键是最终尺寸正确且不丢最后一次变化。
3. 问题：E1（直接证据）能证明哪些 ECharts（图表库）能力？
   • 考点：事实等级。
   • 回答思路：逐项区分已读源码和推荐做法。
   • 详细答案：可证明本地有按需注册文件，注册柱、线、饼等图表及组件、特性和 CanvasRenderer（画布渲染器），出库趋势组件调用 useECharts、echarts.init 和 setOption。不能据此证明 resize、dispose、事件解绑、大数据策略、生产性能或无障碍已落地，这些需源码或现场核对。
   • 进阶追问：能否说按需注册一定减小了包体？
   • 进阶回答：不能；需比较构建产物和依赖可达性，源码意图不等于实际包体结果。

11. ECharts（图表库）大数据策略与完整界面状态

图表数据先按用户决策粒度聚合，再考虑降采样、窗口化和渐进渲染；不能为性能任意丢弃峰值、异常点或业务总量。界面至少区分初始加载、刷新中、空数据、部分数据、错误、无权限和陈旧状态，并提供表格或摘要作为替代读取方式。

flowchart TD
  A[原始时间序列] --> B{用途}
  B -->|趋势| C[按时间桶聚合]
  B -->|异常定位| D[保留峰值与异常点]
  B -->|明细核对| E[分页表格]
  C --> F[降采样与渐进渲染]
  D --> F
  F --> G{页面状态}
  G -->|成功| H[图表加摘要]
  G -->|空或无权限| I[专用状态与操作]
  G -->|错误或陈旧| J[保留证据并可重试]

图解读。 处理策略由用途而不是点数单独决定；趋势、异常和核对使用不同投影。渐进渲染降低主线程峰值但会延长完整呈现时间，聚合减少点数但必须守恒总量或记录误差。状态机决定是否显示旧图、骨架、空态或权限说明。

数据演绎 11。 演练一天八万六千四百个秒级点，页面宽度只有一千像素；逐点绘制无法提供等比例信息。按分钟聚合后约一千四百四十桶，每桶保留最小、最大、末值和计数，趋势可读且峰值不被平均吞掉。若用户钻取某分钟，再读取秒级明细。数字是通用演算，不代表项目采样频率。

热门面试题

1. 问题：图表点太多时先做什么？
   • 考点：业务粒度与性能策略。
   • 回答思路：先确认用户问题和像素分辨率，再选聚合或降采样。
   • 详细答案：先问用户看趋势、峰值还是逐条核对，并确认时间范围和容器宽度；趋势优先服务端聚合，异常视图保留极值，明细用分页表。之后再用降采样和渐进渲染控制浏览器压力，不能一上来随机删点。
   • 进阶追问：平均值为什么可能危险？
   • 进阶回答：短时尖峰会被平均稀释，容量和异常判断失真，应同时保留最小、最大、计数等摘要。
2. 问题：空数据与接口错误如何区分？
   • 考点：状态完整性。
   • 回答思路：从契约结果、权限和缓存状态回答。
   • 详细答案：空数据是请求成功且查询范围内确实无记录；错误是请求未成功或契约不可用；无权限是明确拒绝；陈旧数据是旧结果仍可展示但刷新失败。四者文案、颜色、操作和监控级别不同，不能都画成空坐标轴。
   • 进阶追问：刷新时要清空旧图吗？
   • 进阶回答：通常保留旧图并标记刷新中；若身份或筛选已变化，则先隔离旧数据，防止跨上下文误读。
3. 问题：如何验证聚合没有改变业务口径？
   • 考点：数据守恒与边界。
   • 回答思路：核对时间桶、时区、缺失值和汇总不变量。
   • 详细答案：固定同一筛选与时间窗口，对比原始计数、总量、最小最大和桶边界；明确空值、补零、跨时区和迟到数据处理。图表、表格与导出应共享口径标识，发现差异时显示版本而不是前端补算掩盖。
   • 进阶追问：前端能自己聚合吗？
   • 进阶回答：小数据和纯展示可做，但权威口径宜由服务端提供，前端聚合需标明且不能用于资金或库存裁决。

12. ARIA（无障碍富互联网应用）、语义、键盘、焦点与图表替代文本

优先使用原生语义元素，再用 ARIA（无障碍富互联网应用）补足自定义控件的名称、角色、状态和关系。所有操作可由键盘完成，焦点顺序与视觉顺序一致；弹窗开启后聚焦标题或首个有效控件，关闭后回到触发点。颜色不能是唯一编码，图表提供标题、摘要、更新时间和可访问表格。

flowchart LR
  K[键盘输入] --> S[语义控件]
  S --> F[可见焦点]
  F --> A[ARIA（无障碍富互联网应用）名称与状态]
  A --> C{内容类型}
  C -->|表单错误| E[字段关联与错误摘要]
  C -->|图表| T[文字摘要与数据表]
  C -->|弹窗| M[焦点圈定与返回]

图解读。 可访问性不是最后给图表加一段文字，而是从输入、语义、焦点到替代内容的完整链路。屏幕阅读器用户、键盘用户和色觉差异用户都能获取同一业务结论；动态刷新要克制播报，避免每个数据点变化都打断操作。

数据演绎 12。 演练库存差异图有“正常、关注、严重”三类。若只用绿、黄、红，无法保证色觉差异用户识别；增加文字标签、不同标记形状和可排序表格后，三类状态无需颜色也可区分。键盘从筛选到图表摘要再到表格，关闭明细弹窗后回到原行。该演绎描述验收步骤，不代表本地页面已完成。

热门面试题

1. 问题：为什么优先原生语义而不是全部使用 ARIA（无障碍富互联网应用）？
   • 考点：平台语义与维护成本。
   • 回答思路：说明原生元素自带行为、键盘和可访问树支持。
   • 详细答案：原生按钮、链接、表格和表单控件已经定义角色、状态和键盘行为，浏览器与辅助技术兼容更稳定。自定义元素加 ARIA（无障碍富互联网应用）只改变可访问树，不自动提供点击、焦点和键盘逻辑，容易出现“有角色但不能操作”。
   • 进阶追问：禁用按钮如何处理？
   • 进阶回答：真正不可用时使用原生禁用并给出原因；若用户需要聚焦阅读原因，可保留可聚焦说明而非只靠悬停。
2. 问题：ECharts（图表库）如何提供替代内容？
   • 考点：图形信息等价表达。
   • 回答思路：从标题、趋势摘要、更新时间和数据表回答。
   • 详细答案：图表旁提供可读标题、筛选范围、主要趋势与异常摘要，并提供同口径数据表；交互图例和工具提示要支持键盘或在表格中等价呈现。加载、空、错误、无权限和陈旧状态也要用文本明确，不能只显示颜色或空画布。
   • 进阶追问：需要朗读每个点吗？
   • 进阶回答：通常不需要；先读摘要和结构，用户再按需进入数据表，避免信息洪水。
3. 问题：动态错误如何管理焦点？
   • 考点：错误恢复与上下文保持。
   • 回答思路：区分字段错误、全局错误和后台刷新错误。
   • 详细答案：提交后的字段错误把焦点移到错误摘要或首个无效字段，并通过关联描述说明原因；全局阻断错误聚焦到错误标题；后台刷新失败若旧内容仍可用，使用不打断操作的状态提示。修复后焦点留在用户当前任务，不任意跳回页面顶部。
   • 进阶追问：告警区域都要实时播报吗？
   • 进阶回答：只播报需要即时行动的简短变化，频繁数据刷新应合并，避免持续打断辅助技术用户。

13. 错误边界、前端日志、Trace ID（链路标识）与性能观测

错误边界隔离组件渲染失败，网络层记录稳定错误码和阶段，资源层记录查询键与版本；日志不得包含令牌、密码、完整地址、支付敏感信息或大请求体。Trace ID（链路标识）由网关或服务生成并跨端回传，前端日志带页面版本、路由模板、操作类型和采样决策。RUM（真实用户监控）是否接入为 E0（未证实）。

flowchart TD
  U[用户现象] --> B[错误边界或请求层]
  B --> L[结构化前端日志]
  L --> P[采样与脱敏]
  P --> T[`Trace ID（链路标识）`关联]
  T --> G[网关日志]
  G --> J[Java（编程语言）服务日志]
  J --> D[数据库或异步任务]
  D --> A{是否满足告警条件}
  A -->|是| I[聚合告警与处置]
  A -->|否| S[留存用于趋势]

图解读。 用户现象先被边界捕获，再经结构化、脱敏和采样进入观测；Trace ID（链路标识）连接浏览器、网关、服务和存储。告警以用户影响、错误率、持续时间和版本聚合，不能一条异常一条通知。采样失败时关键支付、权限和数据一致性错误仍应保底留证。

数据演绎 13。 演练某版本产生一万次同指纹错误，全部上报会挤占网络与存储。可按会话首条必报、后续概率采样并累计本地计数；支付未知态和权限越权类错误不走普通低采样。告警按版本、路由模板和指纹聚合，恢复后验证错误率回落。数字仅说明采样策略，真实采样率、阈值和 RUM（真实用户监控）链路待现场核对。

正式图说明。 PlantUML（统一建模语言）源文件为 frontend-api-observability.puml，采用不依赖 Graphviz（图形可视化软件）的时序图语法；图中覆盖正常响应、未知态查询、错误留证与跨端定位。

热门面试题

1. 问题：前端日志为什么必须带 Trace ID（链路标识）？
   • 考点：跨端证据关联。
   • 回答思路：说明时间和用户描述不足以唯一定位请求。
   • 详细答案：同一时间可能有大量相似请求，浏览器只知道页面阶段，后端只知道服务调用。Trace ID（链路标识）把前端错误、网关访问、Java（编程语言）服务、数据库和异步任务关联起来；还要带页面版本和业务标识的安全摘要，才能区分前端回归、契约错误和服务异常。
   • 进阶追问：Trace ID（链路标识）能作为安全凭证吗？
   • 进阶回答：不能，它只用于关联且可能暴露内部信息，查询日志仍需权限和审计。
2. 问题：采样如何避免漏掉关键错误？
   • 考点：成本与风险分级。
   • 回答思路：按错误严重度、首次出现、版本和业务类型分层。
   • 详细答案：崩溃、支付未知态、权限异常和数据一致性错误设置保底或更高采样；普通重复错误按指纹与会话采样并上报累计数。新版本、首次出现和短时突增可动态提升，日志管道过载时先丢低价值调试信息，不能随机等比例丢所有信号。
   • 进阶追问：客户端采样可被绕过吗？
   • 进阶回答：可以，所以服务端也要有独立审计和指标；客户端采样只控制体验侧观测成本。
3. 问题：错误边界能捕获所有前端错误吗？
   • 考点：错误域边界。
   • 回答思路：区分渲染、事件、异步、资源和全局错误。
   • 详细答案：组件错误边界主要隔离渲染及生命周期错误，事件回调、承诺拒绝、网络失败、资源加载和第三方脚本需要各自捕获点。全局监听只作最后留证，不能代替局部恢复；捕获后展示可操作降级，并避免把敏感上下文直接上报。
   • 进阶追问：捕获后继续渲染是否安全？
   • 进阶回答：只在受影响区域可隔离且状态仍可信时继续；库存、支付关键状态不可信时应阻断危险操作。

14. WMS（仓储管理系统）项目映射、安全、容量、排障与设计权衡

E2（结构佐证）允许把库存差异、订单或入库异常、导出失败、账单与成本待办映射为管理台场景，但不允许编造数量和收益。页面用统一状态壳承载新鲜度、权限、错误和 Trace ID（链路标识）；库存与支付以服务端状态机为准，导出由任务资源恢复，订单异常可按业务标识追踪。IoT（物联网）报警风暴只能作为容量设计类比，不表示本页已有接入。

flowchart LR
  W[WMS（仓储管理系统）工作台] --> I[库存差异]
  W --> O[订单与入库异常]
  W --> E[导出失败]
  W --> B[账单与成本待办]
  I --> C[版本冲突与流水核对]
  O --> T[状态机与 `Trace ID（链路标识）`]
  E --> R[Runner（执行器）任务恢复]
  B --> P[支付未知态与对账]
  C --> S[服务端权威]
  T --> S
  R --> S
  P --> S

图解读。 工作台只是四类风险入口，点击后进入各自领域证据链；统一的是身份、状态壳、错误模型和观测，不统一业务状态机。E2（结构佐证）说明本地源码结构可承接这些语义，具体请求量、告警阈值、恢复时间和业务收益都为 E0（未证实）。

flowchart TD
  X[现象：空白、陈旧、重复或未知] --> A[固定页面版本、身份视角与时间]
  A --> B[核对网络请求、错误码与 `Trace ID（链路标识）`]
  B --> C{责任层}
  C -->|浏览器| D[竞态、缓存、图表实例、权限路由]
  C -->|网关或 BFF（后端前端聚合层）| E[鉴权、聚合、限流与版本]
  C -->|Java（编程语言）服务| F[状态机、幂等、数据库与任务]
  D --> G[止血、修复、验证与复盘]
  E --> G
  F --> G

图解读。 排障先固定上下文和证据，再按责任层分叉；刷新页面不是根因分析，临时降级也不能抹掉证据。安全上最小权限、输入白名单、幂等和脱敏贯穿各层；容量上同时估算查询率、长连接、数据点、导出并发、日志量和重连峰值。

数据演绎 14。 演练两千个活跃页面：若每十秒刷新一次，入口约每秒二百次查询；每页同时绘制四张各五千点图，浏览器需处理两万点；导出并发和错误日志还会争用后端资源。优化顺序应是延长或事件化刷新、服务端聚合、限制可见窗口、导出队列隔离和日志采样。所有数字为容量公式样例，不代表项目实测，最终阈值需压测和生产证据。

热门面试题

1. 问题：如何把 WMS（仓储管理系统）看板讲成全栈项目而不夸大？
   • 考点：项目证据与系统表达。
   • 回答思路：按事实、机制、缺口和验证路径分层。
   • 详细答案：先说 E1（直接证据）：Vue（前端框架）入口安装路由与 Pinia（状态管理库），ECharts（图表库）存在按需注册和出库趋势初始化；再说 E2（结构佐证）的库存差异、订单异常、导出失败和账单待办界面语义。接口、实时通道、RUM（真实用户监控）、容量和收益未证实的部分明确列为 E0（未证实），只讲设计与核对方法。
   • 进阶追问：没有收益数字会不会显得弱？
   • 进阶回答：可以讲风险、不变量、恢复和证据链；没有数据时不编造，反而体现工程可信度。
2. 问题：前端接口层最重要的安全边界是什么？
   • 考点：最小权限与输入输出控制。
   • 回答思路：从令牌、授权、参数、日志和下载回答。
   • 详细答案：令牌按生命周期管理且不写日志，前端权限只改善体验，服务端做资源级授权；筛选排序白名单化，输出按上下文编码，幂等防重复副作用；下载凭证短期且绑定权限，日志脱敏。发生身份切换时取消旧请求并清空缓存、路由和组件状态。
   • 进阶追问：隐藏敏感字段是否足够？
   • 进阶回答：不够，服务端根本不应向无权用户返回字段，前端隐藏只是二次体验控制。
3. 问题：如何排查“看板数字不对”？
   • 考点：口径、陈旧数据和跨端证据。
   • 回答思路：固定筛选与版本，比较图表、表格、接口和服务端流水。
   • 详细答案：先记录页面版本、身份视角、仓库、时间范围、新鲜度和 Trace ID（链路标识）；检查是否有竞态、缓存键遗漏、前端聚合或图表残留；再核对 BFF（后端前端聚合层）响应口径、资源版本和 Java（编程语言）服务查询，最后沿库存流水、订单状态或账本验证。止血可标记陈旧或切到表格，但不直接改数。
   • 进阶追问：图表和表格一致就说明正确吗？
   • 进阶回答：不一定，二者可能共享同一错误投影；仍需与权威口径和流水核对。

知识小节与综合题库边界

以下题目用于跨节串讲，不新增知识型小节计数。

2. 综合面试题库

1. 问题（综合 1）：如何设计 WMS（仓储管理系统）工作台的 BFF（后端前端聚合层）？

   • 口述答案：我会先把 BFF（后端前端聚合层）定义为页面适配层，而不是新的领域服务。工作台首屏可能同时需要身份视角、库存摘要、订单异常和账单待办，我会让 BFF（后端前端聚合层）按页面用例并行读取，统一字段命名、资源版本、错误对象和 Trace ID（链路标识），再返回 data、partialErrors、freshness 这类明确结构。库存可用量、支付确认和异常状态迁移仍由 Java（编程语言）领域服务裁决，聚合层不能复制规则。正常路径中，各依赖在共同截止时间内返回，页面渲染摘要并标注新鲜度；某个依赖失败时，BFF（后端前端聚合层）保留其他可信分片，把失败分片标成局部错误，前端只重试该分片，不能补零伪装成功。安全上，前端路由只是体验控制，BFF（后端前端聚合层）和服务端都要按身份、业务线和资源授权；日志不记录令牌和完整敏感请求体。容量上，我会限制聚合扇出、设置依赖截止时间和并发舱壁，避免一个页面把一次访问放大为无界调用。观测上记录页面版本、子请求耗时、业务码与 Trace ID（链路标识）。E2（结构佐证）允许把本地仓储页面用于场景映射，但真实扇出、延迟、SLA（服务等级协议）和收益没有证据时不会编造。 验收时我会准备四类用例：全部依赖成功、单分片超时、身份失效和字段版本不兼容；检查页面是否只降级受影响区域、是否保留原筛选、重试是否复用查询上下文、服务端日志能否沿 Trace ID（链路标识） 关联。演进上先从读聚合开始，只有监控证明收益且责任清楚后才增加写编排，并定期删除已无客户端使用的兼容代码。
   • 追问 1：BFF（后端前端聚合层）可以缓存吗？
   • 直答 1：可以缓存只读投影，但缓存键必须含身份和查询上下文，关键写操作前仍由领域服务校验。
   • 追问 2：部分失败用什么状态码？
   • 直答 2：保留整体 HTTP（超文本传输协议）语义，并在响应中逐分片提供稳定状态与可重试性。
   • 追问 3：如何避免聚合层越来越厚？
   • 直答 3：限制其只做编排、适配与兼容，业务不变量和状态机始终回到领域服务。
   • 详细章节：BFF（后端前端聚合层）与资源契约

2. 问题（综合 2）：怎样设计可长期演进的 REST（表述性状态转移）接口契约？

   • 口述答案：我会从资源而不是页面按钮命名接口，先定义稳定资源标识、可见字段、状态机、方法语义和并发版本，再定义传输状态与业务错误。读取接口明确筛选、排序、分页或游标、数据新鲜度和权限视角；写接口携带幂等键与版本，创建、变更、查询各有清楚语义。成功响应不只返回数据，还返回资源版本和必要的关联标识；失败响应包含稳定业务码、用户文案键、字段错误、可重试性、退避建议和 Trace ID（链路标识），同时保留 HTTP（超文本传输协议）状态，避免所有结果都塞进二百状态。演进时优先新增可选字段，不改变旧字段含义；废弃字段先记录调用、公告窗口、双写或适配，再删除。破坏性变更通过新版本或能力协商完成，BFF（后端前端聚合层）可以短期兼容旧页面，但必须有移除条件。安全上只公开白名单筛选和排序，拒绝客户端表达数据库语句；敏感字段按资源权限裁剪。测试上用契约样例覆盖正常、部分失败、重复请求、版本冲突和未知态。观测上按版本统计错误码和不兼容请求。这样前后端可以错峰发布，同时不会靠默认值把“未知”伪装成零、空或成功。 契约发布前还要做消费者样例验证：旧页面面对新增字段仍能运行，新页面面对字段缺失会进入明确兼容状态，部分失败不被反序列化成空数组，重复写和版本冲突都有固定结果。灰度期间按页面版本比较业务码和字段缺失率，出现异常能回退 BFF（后端前端聚合层）适配，而不回滚领域数据或让用户猜测。
   • 追问 1：字段能否直接改名？
   • 直答 1：不能直接破坏旧客户端，应新增字段、双读并经过废弃窗口后移除旧字段。
   • 追问 2：业务错误要不要使用 HTTP（超文本传输协议）状态？
   • 直答 2：要保留传输语义，同时用稳定业务码表达领域原因，两层不能互相替代。
   • 追问 3：默认值有什么问题？
   • 直答 3：关键字段默认值会掩盖缺失和版本不兼容，应显式为空并阻断危险操作。
   • 详细章节：浏览器网络与缓存

3. 问题（综合 3）：如何处理访问令牌过期和刷新令牌并发？

   • 口述答案：我会把认证状态做成独立协调器，而不是让每个接口拦截器各自刷新。多个请求同时收到令牌过期时，只创建一个刷新承诺，其余请求订阅同一结果；刷新接口本身排除在刷新逻辑之外，并设置总截止时间，防止循环。刷新成功后先更新访问令牌，再按请求类型决定是否重放：只读请求通常可重放，写请求只有具备服务端幂等、复用原幂等键且请求体可重放时才自动执行，否则让用户确认。刷新失败时统一拒绝等待队列，取消旧身份下仍在飞行的请求，清空用户信息、角色、权限路由、组件缓存和身份相关数据，再跳转登录，同时保留不含敏感信息的错误证据。前端权限路由只负责隐藏无权入口，Java（编程语言）服务仍对每次资源访问做最终授权。安全上刷新令牌采用受保护的存放与传输策略，不写日志，不通过地址参数传递；具体存放方式要结合跨站请求防护和部署边界。E1（直接证据）可以证明本地用户仓库持有并清理令牌派生状态、权限仓库装卸运行时路由，但刷新令牌机制并未在指定证据中确认，因此我会把这一部分作为 E3（通用机制）方案而非项目事实。 验证时我会并发触发多个过期请求，确认网络中只有一次刷新，其余请求共享结果；再分别测试刷新失败、页面卸载、写请求无幂等键和身份切换，确保队列会终止、旧路由被移除、迟到响应被丢弃。监控只记录刷新结果、等待数量和版本，不记录令牌本身，并为连续刷新失败设置登录恢复而不是无限循环。
   • 追问 1：刷新期间新请求怎么办？
   • 直答 1：加入有上限的等待队列并继承页面取消信号，刷新结束后统一裁决。
   • 追问 2：写请求为何不能全部重放？
   • 直答 2：非幂等副作用可能已成功，盲目重放会造成重复提交或重复扣款。
   • 追问 3：前端路由能否防越权？
   • 直答 3：不能，它只改善体验，服务端资源级授权才是强制安全边界。
   • 详细章节：Vue（前端框架）状态与路由

4. 问题（综合 4）：动态权限路由如何避免身份切换后的数据串用？

   • 口述答案：我会把身份视为由访问令牌、用户资料、角色权限、业务线、运行时路由、页面缓存和在途请求组成的一致快照。身份切换不是简单替换令牌，而是先阻止旧操作继续提交：提升身份世代号、取消旧请求、移除旧运行时路由、清空身份相关 Pinia（状态管理库）状态与组件缓存，再获取新身份信息和导航，最后挂载新路由。每个请求和缓存键都携带身份或业务线维度，响应提交前比较身份世代，旧身份的迟到响应只能记录诊断，不能写入新页面。路由元数据只能决定页面入口和展示，Java（编程语言）服务仍按资源归属与动作授权；如果导航接口成功但某资源授权失败，页面按权限错误处理，不能因为路由存在就假定可访问。E1（直接证据）中，本地权限仓库有移除、生成和挂载运行时路由的实现，用户仓库有清空身份派生状态的动作，这可以支撑架构事实；但生产身份切换、缓存清理完整性和越权测试结果仍需要现场证据。观测上记录身份切换事件的安全摘要、路由版本和拒绝码，不记录令牌和个人敏感字段。 实施上我会把“清理旧身份”和“装载新身份”做成显式两阶段，任何一步失败都不能回到混合状态；页面外壳保留退出和重新认证能力，业务区保持阻断。测试用高权限切低权限、业务线切换、后端导航失败和旧请求迟到四组路径，检查缓存、菜单、按钮、接口授权与日志视角一致，避免只验证路由表表面变化。
   • 追问 1：旧页面的 keep-alive 缓存怎么办？
   • 直答 1：按身份键隔离或在切换时销毁，否则旧内存数据可能短暂出现在新身份。
   • 追问 2：导航接口失败是否保留旧菜单？
   • 直答 2：身份已变化时不能保留旧权限菜单，应进入明确错误或重新认证状态。
   • 追问 3：迟到响应如何识别？
   • 直答 3：请求携带身份世代和查询键，提交状态前必须同时匹配当前值。
   • 详细章节：权限路由

5. 问题（综合 5）：幂等键怎样贯穿前端、BFF（后端前端聚合层）和 Java（编程语言）服务？

   • 口述答案：幂等键应在用户产生一次明确业务意图时创建，而不是每次网络尝试都重新生成。前端把键与操作类型、关键业务标识和请求体摘要一起保存在当前任务上下文；超时、令牌刷新后的安全重放或用户点击“重试”都复用原键，只有用户修改参数或明确发起新意图才生成新键。BFF（后端前端聚合层）必须原样传递，不能为每次下游调用换键；Java（编程语言）服务在副作用之前原子登记“调用方、操作类型、幂等键、请求摘要、处理状态和结果引用”。首次请求执行，同键同摘要返回原结果或处理中状态，同键不同摘要返回冲突，避免键误用。服务崩溃时记录要能表达处理中并由恢复任务确认，不能仅靠内存锁。库存调整、导出创建和支付发起的保留窗口不同，键过期策略应覆盖业务最长恢复期。错误对象返回原资源标识和 Trace ID（链路标识），前端遇到未知态先查询原业务，不直接重放。安全上键不可作为授权凭证，仍需身份和资源校验；容量上对异常调用方限制未完成键数量。这样幂等解决的是重复副作用，不替代并发版本、事务和状态机。 验证幂等不能只做双击测试，我会注入网关超时、服务进程在登记后崩溃、响应丢失和同键改参数，检查数据库或幂等存储只产生一个权威结果、处理中记录可恢复、冲突不会返回旧业务数据。容量上监控未完成记录、键冲突和保留空间，清理任务必须避开仍可能收到渠道回调或人工确认的业务窗口。
   • 追问 1：幂等键可以复用多长时间？
   • 直答 1：至少覆盖请求重试和业务确认窗口，具体时长按场景恢复周期与存储成本确定。
   • 追问 2：只用数据库唯一索引够吗？
   • 直答 2：可作为原子基础，但还需保存请求摘要、处理中状态和原结果，才能区分冲突与恢复。
   • 追问 3：键是否需要全局唯一？
   • 直答 3：通常在调用方和操作类型作用域内唯一即可，服务端必须明确作用域。
   • 详细章节：幂等与重试预算

6. 问题（综合 6）：统一错误模型和重试预算如何设计？

   • 口述答案：我会先把错误分成传输瞬态、限流、业务可修正、权限拒绝、版本冲突和结果未知，只有契约明确为可重试的类别才进入自动重试。统一错误对象保留 HTTP（超文本传输协议）状态，同时包含稳定业务码、字段错误、用户文案键、可重试标志、服务端退避建议和 Trace ID（链路标识）；前端根据类别选择退避、聚焦字段、刷新版本、进入待确认或停止。重试预算不是“最多三次”一个数字，而是单请求尝试次数、累计截止时间、页面并发和全局流量的共同约束。每次重试使用递增退避与随机抖动，继承原取消信号和幂等键；页面隐藏、用户离开或截止时间到达立即停止。网关限流时尊重服务端建议，支付未知态改为查询原支付单，不能重发扣款。为了避免恢复中的服务被放大，BFF（后端前端聚合层）和客户端都设置并发上限与熔断降级。观测上按业务码、版本、路由模板和尝试次数聚合，告警关注用户影响与持续时间。用户文案不暴露内部堆栈，日志先脱敏。生产次数和阈值需要容量演练，不能把演练参数说成事实。 落地时我会让服务端返回机器可判定的重试属性，前端不维护一份容易漂移的错误码猜测表；同时把每次尝试的原因、等待和剩余预算写入诊断上下文。故障演练覆盖瞬态网络、持续限流、参数错误、版本冲突和未知写结果，验证总请求数有上限、用户能停止、关键操作不重复，服务恢复后也不会被同步重试再次压垮。
   • 追问 1：参数错误为何不重试？
   • 直答 1：相同输入不会自行变正确，重试只增加负载，应聚焦字段让用户修正。
   • 追问 2：抖动解决什么问题？
   • 直答 2：让大量客户端不要在相同时间点重试，降低同步峰值。
   • 追问 3：总预算耗尽后怎么办？
   • 直答 3：停止自动尝试，进入明确降级、稍后查询或人工恢复路径并保留证据。
   • 详细章节：JavaScript（脚本语言）异步机制

7. 问题（综合 7）：订单流列表为什么更适合游标分页？

   • 口述答案：订单流持续插入和更新，偏移分页在前面新增记录后会让后续偏移发生漂移，用户可能重复看到或漏掉订单。游标分页把页边界建立在稳定排序元组上，例如“更新时间倒序加订单唯一标识倒序”，响应返回数据、下一游标、是否还有后续、查询时间和可选快照版本；下一次用严格小于该元组继续。游标还要绑定仓库、状态、业务线、排序方向和契约版本的查询摘要，筛选变化或权限变化时立即作废，不能沿用。服务端对页大小、筛选字段、操作符和排序字段做白名单映射，避免昂贵查询和内部字段泄露；游标可编码但需要防篡改时应签名。页面遇到游标失效，保留用户筛选并明确从首段刷新，不把旧页和新页拼成完整集合。对于随机跳页和稳定的小配置表，偏移分页仍更简单；导出则不应由浏览器翻页拼接，而应创建服务端快照任务。观测上记录游标失效原因和查询耗时，不记录可反解敏感条件的原始游标。总数可以省略或标为估算，但语义必须明确。 我还会用插入、删除、同一时间值和权限变化构造分页测试：读取首段后插入更近订单，下一段不应重复；删除边界记录后仍能继续；相同时间的记录依靠唯一键稳定；权限变化则使游标失效并从新上下文重读。性能验证关注索引扫描范围和页大小，而不是只看接口平均耗时，避免游标形式正确但数据库仍全量排序。 数据库侧还要确认排序元组存在同序复合索引，并对深页、热点时间段和大筛选集合查看扫描行数；否则游标只修复一致性表象，不能自动消除昂贵排序。发布时保留旧游标契约的兼容窗口，版本不匹配返回明确失效原因。
   • 追问 1：为什么排序键还要加唯一标识？
   • 直答 1：非唯一时间值无法稳定定位边界，同值记录可能换序并造成重复或漏读。
   • 追问 2：游标能支持上一页吗？
   • 直答 2：可以设计双向游标或由客户端保存历史游标，但实现和一致性成本更高。
   • 追问 3：总数一定要返回吗？
   • 直答 3：不一定，大集合可省略或估算，但必须清楚标注，不能把估算当精确值。
   • 详细章节：分页与游标

8. 问题（综合 8）：如何设计安全且可索引的筛选排序接口？

   • 口述答案：我不会让前端传数据库列名、自由表达式或拼接排序片段，而是定义公开查询语言：每个筛选名映射到受控领域字段，明确允许的操作符、值类型、是否可多选、时间区间边界和空值语义；排序只允许少量有索引支持的字段，并自动追加唯一键保证稳定。服务端首先做身份和业务线授权，再校验字段白名单、组合复杂度、页大小和时间范围，最后将公开字段映射到参数化查询。前端根据能力元数据生成控件，在输入阶段限制格式并给出字段错误，但服务端仍是强制边界。缓存键和游标包含规范化后的筛选、排序和契约版本，字段顺序和等价空值先归一，避免同一查询产生多个缓存键。对昂贵组合可以返回明确错误、建议缩小范围或转异步导出，不能让在线接口无界扫描。响应带查询时间、口径和新鲜度，图表、表格与导出共享同一筛选语义。安全日志只记录字段名、错误类型和安全摘要，不记录完整敏感值。上线前用执行计划和容量演练验证索引路径；索引、阈值和真实数据分布没有证据时只说明验证方法。 验收时除正常组合外，还要直接构造未知字段、非法操作符、超大页、反向时间、过多多选值和无索引排序，确认服务端快速拒绝且返回字段级错误；再用典型数据分布核对执行计划和超时。接口文档给出公开字段与口径，不暴露数据库结构，字段下线经过调用观测和兼容窗口，防止前端配置仍引用已删除能力。
   • 追问 1：前端已经限制字段，服务端还要校验吗？
   • 直答 1：必须，浏览器可被绕过，前端限制只改善体验。
   • 追问 2：排序字段越多越灵活吗？
   • 直答 2：不是，任意组合会增加索引和性能成本，应根据真实决策场景开放。
   • 追问 3：大范围查询如何处理？
   • 直答 3：限制在线范围，提供聚合结果或转异步导出，并清楚说明口径。
   • 详细章节：接口筛选契约

9. 问题（综合 9）：搜索页面如何同时处理防抖、取消和请求竞态？

   • 口述答案：我会把三者看成不同层次：防抖减少尚未发出的高频请求，取消表达页面不再关心已经发出的工作，查询键或序列号决定响应是否有资格提交状态。用户输入变化时，先更新规范化查询键，清理旧防抖计时器；达到窗口或最大等待时间后发请求，并给请求绑定取消控制和递增序列。新查询开始时取消旧请求，但不能假设服务端一定停止；任何网络、缓存或异步回调在写入 Pinia（状态管理库）或组件状态前，都要比较当前身份世代、查询键和序列，旧结果只能丢弃。加载、错误和空态也按查询键管理，旧请求结束不能关闭新请求的加载提示。组件卸载时取消请求、计时器和订阅；写请求不能仅靠取消保证安全，因为服务端副作用可能已发生，必须依靠幂等键和查询确认。缓存命中同样走提交守卫，缓存键含身份、仓库、筛选、排序和版本。观测上记录取消原因、迟到响应数量和最终查询耗时，不把用户输入原文写入日志。这样即使旧请求比新请求晚返回，也不会覆盖用户当前看到的结果。 我会用可控延迟做确定性测试：让旧请求在新请求之后返回，让缓存结果和网络结果交叉，再在组件卸载和身份切换时触发回调，逐一确认状态、加载、错误和空态都只接受当前查询。性能上统计实际发送数和被丢弃的迟到数，若防抖减少不明显或取消过多，说明交互窗口、缓存策略或服务响应需要重新调节，而不是继续叠加计时器。
   • 追问 1：只用取消够不够？
   • 直答 1：不够，取消可能来不及或不影响缓存回调，仍需查询键或序列守卫。
   • 追问 2：防抖窗口越长越好吗？
   • 直答 2：不是，过长会增加输入延迟，应结合请求成本并设置最大等待。
   • 追问 3：加载状态为什么也会竞态？
   • 直答 3：旧请求完成可能错误关闭新请求的加载状态，因此也必须绑定当前查询。
   • 详细章节：取消与竞态

10. 问题（综合 10）：缓存和陈旧数据如何兼顾速度与业务正确性？

• 口述答案：我会先按使用目的分级：趋势浏览、静态字典和非关键摘要可使用缓存并采用 stale-while-revalidate（陈旧时后台再验证）；库存分配、支付确认和权限判断不能把缓存投影当权威，写入前必须由 Java（编程语言）服务按版本重新校验。缓存键包含租户或业务线、身份权限视角、资源、筛选、排序、分页或游标、语言和契约版本，身份切换、登出或权限变化时失效相关条目。页面命中旧数据时明确显示数据时间和“刷新中”，刷新成功以查询键和版本提交，刷新失败保留旧内容但标记陈旧与错误；若上下文已经变化，则不能继续展示旧身份或旧仓库数据。条件请求可以减少传输，但服务端验证信息和浏览器缓存策略必须一致。离线时可允许只读浏览已标记快照，写操作进入明确未提交状态，恢复后仍用幂等键由服务端裁决。安全上敏感响应避免落入不受控持久缓存，日志不记录完整内容。观测上区分命中、再验证、陈旧展示和刷新失败。策略的缓存时长必须由数据变化频率与错误成本决定，不用一个全局时间覆盖所有资源。 验证缓存时我会覆盖同一查询命中、筛选变化、仓库切换、身份降权、条件请求未修改和后台刷新失败；检查界面上的时间、陈旧标识与实际条目一致，旧身份内容绝不短暂闪现。容量评估同时看命中率和错误成本，命中高但经常触发关键版本冲突的缓存并不划算，应缩短时长或只缓存更稳定的摘要。
• 追问 1：刷新失败是否清空旧数据？
• 直答 1：同一身份和查询下可保留并标记陈旧；上下文变化时应隔离旧数据。
• 追问 2：库存列表能不能缓存？
• 直答 2：可缓存浏览投影并显示新鲜度，但操作前必须携带版本由服务端重校验。
• 追问 3：缓存键漏掉权限视角会怎样？
• 直答 3：可能把高权限结果展示给低权限身份，属于严重数据隔离问题。
• 详细章节：浏览器缓存

11. 问题（综合 11）：如何设计库存查询和库存调整的全栈契约？

• 口述答案：我会先和业务确认现存量、冻结量、质检隔离、在途量和可用量的口径，接口返回组成、单位、数据时间、来源和资源版本，前端不自行发明可用量公式。查询支持受控仓库、商品、状态筛选和稳定游标，列表与图表共享口径标识；缓存只用于浏览投影，并明确新鲜度。用户发起调整时，前端携带库存标识、读取版本、调整原因、期望变化和幂等键，Java（编程语言）库存服务在事务或一致性边界内校验当前版本、权限和业务不变量。版本一致才写流水并返回新状态；版本冲突时返回当前值、当前版本和稳定错误码，页面保留用户输入，展示旧值与新值差异，让用户刷新确认，不能本地强制覆盖。响应超时进入未知态时先查询原操作或流水，不能用新键重放。安全上调整原因和数量做服务端校验，授权到仓库与动作；观测上用业务标识和 Trace ID（链路标识）串联页面、网关、库存流水和异步事件。E2（结构佐证）只允许把库存差异用于 WMS（仓储管理系统）场景表达，真实冲突率、数量和收益不会杜撰。 验收要用并发冻结、释放和调整构造版本变化，确认旧版本写入稳定冲突、同一幂等键不重复落流水、查询与表格展示相同口径；再注入响应超时，检查页面进入未知态并查询原操作。若需要降级，只允许只读并标记数据时间，不能绕开版本直接写。项目表达聚焦不变量、证据和恢复，不用未经核实的准确率或收益包装。
• 追问 1：为什么查询也要返回版本？
• 直答 1：页面停留期间状态会变化，版本让后续写入能检测并发冲突。
• 追问 2：冲突后可否自动再次提交？
• 直答 2：通常不能，当前状态变化可能改变用户意图，应展示差异后重新确认。
• 追问 3：图表能否直接算可用量？
• 直答 3：不应作为权威口径，服务端应返回定义清楚的可用量与组成。
• 详细章节：库存契约

12. 问题（综合 12）：线上发现库存差异时如何跨端排障？

• 口述答案：我会先停止猜测并固定上下文：用户身份和业务线、仓库、商品、时间范围、页面版本、筛选条件、数据新鲜度、资源版本和 Trace ID（链路标识）。浏览器侧先确认是否有旧请求覆盖新请求、缓存键遗漏、身份切换残留、前端聚合口径错误或图表实例复用问题，并把接口原始业务码和版本与页面展示对照。BFF（后端前端聚合层）侧检查聚合字段映射、子请求截止时间、部分失败是否被补零、缓存和契约版本；Java（编程语言）服务侧按库存标识核对现存、冻结、隔离、调整流水、订单占用、消息消费和补偿任务，确认状态迁移是否守恒。如果只是投影陈旧，止血方式是标记陈旧并刷新；如果权威流水不平，阻断危险调整并进入人工或补偿流程，不能由前端改数。修复后用同一筛选复算图表、表格和流水，验证新版本不再出现差异，再复盘为何监控没有更早发现。日志和截图要脱敏。项目真实事故、损失和恢复时间没有证据时，我只讲这条证据链和验证标准。 排障过程中我会建立时间线，区分用户看到的时刻、接口响应版本、库存流水提交和异步事件消费，避免把相关性当因果。修复候选先在回放数据上验证守恒，再灰度观察同一错误指纹、版本冲突和差异待办是否下降；若采用补偿，必须可幂等、可审计、可回滚，并由领域服务执行，前端只展示进度和最终裁决。 事故关闭前还要抽取边界样本复核：并发预占与释放、重复消息、跨日补偿和人工调整分别核对前后版本及流水总和，确认投影、导出和告警都读取同一修订结果，而不是只修正一个页面。
• 追问 1：刷新页面能证明什么？
• 直答 1：只能验证投影是否陈旧，不能证明服务端流水和状态机正确。
• 追问 2：图表与表格一致是否足够？
• 直答 2：不足，二者可能共享同一错误接口，还要和权威流水及口径核对。
• 追问 3：先止血还是先抓证据？
• 直答 3：关键风险先阻断危险操作，同时保全请求、版本和链路证据，二者并行。
• 详细章节：WMS（仓储管理系统）排障

13. 问题（综合 13）：如何设计可恢复的异步导出任务？

• 口述答案：我会把大导出建模为任务资源，而不是让一个 HTTP（超文本传输协议）请求一直等待文件。用户确认筛选后，前端规范化条件并生成幂等键，创建请求携带身份视角、筛选快照、字段口径和文件格式；服务端原子创建任务，返回任务标识、初始状态、查询建议和 Trace ID（链路标识）。Runner（执行器）异步读取固定快照或明确一致性语义，分阶段生成文件并记录排队、执行、上传、完成、失败或取消状态。前端按服务端建议递增退避查询，页面不可见时降频，完成、失败、取消和总预算耗尽时停止；同一用户的多个任务可以合并查询。完成后服务端签发短期、绑定身份和产物的下载凭证，重新获取凭证不应重新生成文件。创建响应超时时，前端复用原幂等键查询或重试，得到同一任务；用户修改筛选才创建新意图。取消只在任务状态允许时生效，已经产生的临时文件按策略清理。容量上限制用户并发、查询范围和队列资源，避免导出拖慢在线库存查询。观测上分开创建、执行、对象存储和下载阶段。E2（结构佐证）允许讲导出失败待办，具体 Runner（执行器）产品、时长和成功率仍需证据。 验收时我会模拟创建响应丢失、任务排队超时、执行进程重启、对象上传失败、凭证过期和页面重开，确认始终能用任务标识恢复，同一创建意图不会出现多个任务，阶段错误不会混成一个文案。还要核对筛选快照与最终文件口径一致，下载权限在任务完成后仍重新校验，临时文件和过期任务按审计策略清理。
• 追问 1：为什么不由浏览器分页拼接导出？
• 直答 1：会受页面生命周期、分页漂移、内存和权限变化影响，难保证快照一致。
• 追问 2：进度必须返回百分比吗？
• 直答 2：不必须，无法准确估算总量时返回阶段和更新时间更可信。
• 追问 3：凭证过期怎么办？
• 直答 3：重新鉴权后签发新凭证，不应因此重新执行整个导出任务。
• 详细章节：异步导出

14. 问题（综合 14）：导出失败如何区分生成失败和下载失败？

• 口述答案：我会按任务生命周期切分证据，而不是只显示“导出失败”。先用任务标识查询权威状态：如果任务仍排队或执行中，检查队列积压、执行心跳、截止时间和取消状态；如果生成阶段失败，查看稳定失败码、筛选快照、数据权限、查询范围、Runner（执行器）日志和 Trace ID（链路标识）；如果任务已完成，则核对产物摘要、对象存在性、内容类型、过期策略和权限。下载阶段再检查短期凭证是否过期或身份不匹配、浏览器是否被跨域策略阻止、网络响应和文件完整性。恢复动作也按阶段分开：查询瞬态失败在预算内重试，生成失败可在原因修正后用新幂等键创建新任务，凭证失败只重新签发，产物损坏才重建。前端保留原筛选并给出可操作文案，不自动无限重建；文件名清理控制字符和路径片段，敏感字段由服务端按权限裁剪。容量告警区分在线接口、任务队列和对象存储，避免一个总错误率掩盖责任层。E2（结构佐证）只能说明本地页面语义包含导出失败，真实故障类型、次数和恢复收益不能推断。 我还会建立一张阶段矩阵，把用户现象映射到浏览器网络、任务状态、Runner（执行器）、对象存储和下载响应的证据，值班人员可按最短路径定位。修复后不仅验证能下载，还要比较文件摘要、行数口径、权限字段和过期清理，确保“恢复下载”没有把数据正确性或敏感信息泄露问题隐藏起来。
• 追问 1：任务完成但文件为空算哪类？
• 直答 1：先核对查询确实为空还是生成口径错误；它属于产物正确性问题，不只是下载问题。
• 追问 2：失败后复用旧幂等键吗？
• 直答 2：查询原任务复用业务标识；修正条件后创建新意图应使用新键。
• 追问 3：下载地址能长期有效吗？
• 直答 3：不宜，短期凭证并绑定权限和产物可降低泄露风险。
• 详细章节：工程化发布与制品

15. 问题（综合 15）：支付结果未知时前端应该怎么做？

• 口述答案：我会把“未收到响应”和“业务失败”彻底分开。用户确认支付时，前端生成或获取支付单标识与幂等键，只允许一次业务意图进入处理中；如果服务端返回明确成功或明确拒绝，页面进入对应终态。如果网络超时、页面关闭或服务端返回待确认，页面进入支付未知态，保留原支付单、提交时间和 Trace ID（链路标识），禁用重复支付，只能查询原支付单。Java（编程语言）支付服务结合渠道主动查询、经过验签和去重的服务端回调、内部账本与对账裁决；前端不直接接收渠道回调作为权威结论，也不按本地计时器把未知态改成失败。查询采用有总预算的退避，页面恢复或从渠道返回时立即查一次；长时间未决则展示账单待办或人工核对入口，最终关闭也必须由服务端状态机给出。订单、支付、退款和履约状态分别展示，不能压成一个成功布尔值。日志不记录卡号、令牌或完整支付请求，只记录安全业务摘要和 Trace ID（链路标识）。本文提供 E3（通用机制），未读取到本地支付前端实现，不能声称已经落地或给出成功率。 验证时要覆盖渠道成功响应丢失、回调先到、页面先回、重复回调、查询持续未知和最终人工关闭，检查页面从不把未知显示成失败，也不会产生第二次支付意图。客服或运营看到的待办应能通过安全业务标识关联账本证据，任何人工裁决都有身份、理由和前后状态审计；恢复过程不以刷新按钮次数作为成功标准。
• 追问 1：超时后能否自动再支付一次？
• 直答 1：不能，应先查询原支付单；重复发起可能造成重复扣款。
• 追问 2：前端等待多久可以显示失败？
• 直答 2：前端不能自行裁决，超过窗口后由服务端关闭或转人工并返回权威状态。
• 追问 3：支付成功为何订单仍可能处理中？
• 直答 3：支付和订单是独立状态机，后续事件和履约可能尚未完成。
• 详细章节：支付未知态

16. 问题（综合 16）：支付按钮如何防止重复点击和重复扣款？

• 口述答案：前端的按钮禁用只能减少误触，真正防重必须依靠服务端幂等和支付状态机。用户第一次确认时，页面冻结本次支付参数，关联支付单标识和稳定幂等键，立即进入处理中；同一页面的再次点击、网络重试和令牌刷新后的安全重放都复用原键，不因按钮重新启用而创建新意图。BFF（后端前端聚合层）原样传递，Java（编程语言）支付服务在调用渠道前原子登记键、请求摘要和状态；同键同摘要返回原支付单，同键不同摘要拒绝冲突。若渠道调用超时，状态变为待确认，页面只查询，不能重发扣款；只有原支付单被服务端明确关闭，且用户重新确认新的金额或方式时才生成新键。按钮状态来自权威支付状态，不以本地承诺是否完成为唯一依据；页面刷新后也能按支付单恢复。安全上金额、币种、收款方等关键参数由服务端从订单重算或校验，前端不能篡改；日志脱敏。容量上限制同用户并发支付意图和查询频率。这样即使用户双击、代理重试或浏览器重载，也只会围绕一个支付意图恢复，而不是依赖短暂的界面锁。 测试不能只在单浏览器内双击，还要模拟两个标签页、移动网络重传、网关重试、登录刷新和服务重启，确认支付服务都返回同一支付单或明确冲突。界面层应显示正在处理的业务标识和可恢复入口，刷新页面后仍能查询；若幂等记录异常，系统宁可进入人工确认，也不能放开无保护的再次扣款。
• 追问 1：按钮禁用还有价值吗？
• 直答 1：有，它改善反馈并减少无效请求，但不是可靠幂等边界。
• 追问 2：金额变化后还能复用原键吗？
• 直答 2：不能，同键不同摘要应拒绝；用户确认新参数后生成新意图。
• 追问 3：页面刷新后如何恢复？
• 直答 3：使用支付单或订单业务标识查询权威状态，不依赖内存中的按钮状态。
• 详细章节：幂等键

17. 问题（综合 17）：Polling（轮询）、SSE（服务器发送事件）、WebSocket（网页套接字）和回调后刷新怎么选？

• 口述答案：我会先问四个问题：数据是单向还是双向、变化频率和延迟目标是什么、丢事件后能否从权威状态恢复、现有网关和运维是否支持长连接。低频任务状态、秒级可接受且兼容优先时用 Polling（轮询），配合服务端查询建议、递增退避、随机抖动、页面不可见降频和明确停止条件。服务端单向持续事件、浏览器只需接收提示时可选 SSE（服务器发送事件），需要事件标识、断线续传或全量刷新。只有真正双向、高频交互且连接成本可承担时才选 WebSocket（网页套接字），同时设计心跳、鉴权续期、背压、顺序、去重、重连和连接容量。支付渠道返回、外部任务完成等场景常用回调后刷新：外部回调先在服务端验签落账，页面恢复后查询原业务标识。无论哪种推送，消息通常只是变化提示，前端仍按资源版本读取权威状态，发现事件缺口就全量刷新。选择前用查询率或连接数公式做容量演练，并准备降级到低频查询。指定本地证据未发现实时通道，因此 SSE（服务器发送事件）和 WebSocket（网页套接字）只能作为 E0（未证实）方案，不能归因到项目。 选型评审还要给出失败与退出方案：连接建立失败时页面显示什么，事件缺口如何发现，令牌过期如何恢复，服务降级时如何切回 Polling（轮询），以及如何证明用户没有看见陈旧状态。容量演练同时覆盖日常连接和大面积重连；若团队没有长连接观测、限流和排障能力，简单可恢复的方案通常比理论上更实时的协议更稳妥。
• 追问 1：WebSocket（网页套接字）是不是延迟最低？
• 直答 1：协议开销低不等于端到端最低，生产、排队、背压和重连都影响延迟。
• 追问 2：SSE（服务器发送事件）适合客户端频繁发消息吗？
• 直答 2：不适合，它主要是服务端到浏览器单向流，客户端写入仍走普通请求。
• 追问 3：轮询如何避免整点峰值？
• 直答 3：使用抖动、退避和服务端建议，并在页面不可见时降频。
• 详细章节：实时刷新矩阵

18. 问题（综合 18）：实时连接断线后如何保证不丢状态？

• 口述答案：我不会承诺连接永不掉线，而是设计“可发现缺口、可恢复权威状态”。服务端事件带单调事件标识、资源标识和版本，客户端只保存最后确认处理的位置；断线重连时携带该位置和新身份令牌，服务端在保留窗口内补发，事件已过期或检测到序列缺口时明确要求全量刷新。客户端处理事件要去重并检查资源版本，重复事件不重复产生副作用，乱序事件不能覆盖更新版本；消息只作为失效提示时，直接按资源版本重新查询更简单。重连采用指数退避和随机抖动，网络离线时停止，页面不可见时降低积极程度；网关限制每用户连接数和握手速率，服务端设置消息积压上限并在背压失控时断开，让客户端走快照恢复。令牌过期要收到明确鉴权错误后先刷新身份，再重连，不能在地址中暴露长期凭证。观测上记录连接时长、断线原因、重连次数、事件缺口和全量刷新，不记录消息中的敏感内容。还必须有降级方案，例如实时通道不可用时转低频 Polling（轮询）。这些是 E3（通用机制）；本地 WebSocket（网页套接字）为 E0（未证实），实际代理和容量待核对。 验收时我会人为断网、切后台、让令牌过期、制造乱序重复和超过补发窗口，确认客户端最终都能收敛到服务端快照，且重连不会无限增长。监控要按断线原因区分用户网络、网关空闲超时、服务端背压和鉴权失败，否则单一“连接关闭”指标无法指导修复；恢复期间仍限制危险写操作使用陈旧投影。
• 追问 1：事件标识能否只存在浏览器内存？
• 直答 1：短会话可以；需要跨刷新恢复时可受控持久化，但要绑定身份和订阅上下文。
• 追问 2：补发窗口外怎么办？
• 直答 2：服务端明确要求全量快照，客户端清理增量基线后重新建立版本。
• 追问 3：如何处理消息积压？
• 直答 3：设置背压和上限，合并可合并事件，超限后断开并走快照恢复。
• 详细章节：浏览器网络

19. 问题（综合 19）：支付渠道回调后为什么还要让前端主动刷新？

• 口述答案：渠道回调和浏览器页面没有可靠的先后关系：用户可能先回到页面，回调稍后到；回调也可能先到，但页面仍持有旧缓存；用户甚至直接关闭页面。因此权威链路应完全在服务端完成，渠道回调由 Java（编程语言）服务验签、校验时间与来源、按事件标识去重，再更新支付单、账本或对账状态。前端从渠道返回或页面恢复时，携带原订单或支付单业务标识主动查询；若服务端已裁决就显示终态，仍处理中则返回待确认和下一次查询建议，前端在总预算内退避查询。这里的“主动刷新”不是重新支付，而是只读确认；请求可取消，页面隐藏时降频，预算耗尽后保留待办入口。即使未来增加 SSE（服务器发送事件）或 WebSocket（网页套接字）通知，推送也只触发查询，不直接把未经当前权限校验的消息当最终状态。缓存键包含身份与支付单，成功状态按业务规则决定是否长期保留。观测上用 Trace ID（链路标识）、支付单和回调事件安全摘要关联，但不记录支付敏感信息。这样可以处理回调乱序、重复和浏览器生命周期差异。 我会用状态时间线验证四种顺序：回调早于页面返回、页面早于回调、回调重复、回调永久缺失；每种情况下前端都只查询，服务端都能去重并给出可解释状态。若查询和回调结论冲突，以账本和对账规则裁决并留下审计，页面显示待确认而不是选择“更乐观”的结果，这也是资金场景与普通通知最大的区别。
• 追问 1：回调重复怎么办？
• 直答 1：服务端按渠道事件和支付单幂等去重，重复回调返回已处理结果。
• 追问 2：前端能信任地址上的成功参数吗？
• 直答 2：不能，地址参数只可作为导航提示，最终状态必须查询服务端。
• 追问 3：查询预算耗尽后显示什么？
• 直答 3：继续显示待确认并提供稍后查看或人工入口，不能擅自显示失败。
• 详细章节：支付确认契约

20. 问题（综合 20）：如何实现 ECharts（图表库）按需注册而不夸大收益？

• 口述答案：我会先建立一个集中注册模块，从 echarts/core 引入核心，只注册实际使用的图表类型、标题、提示、网格、图例、数据集、转换、工具箱、地理组件、特性和一个渲染器，再向业务组件导出统一实例入口与配置类型。这样依赖边界清晰，新增图表时能审查需要增加的模块，也避免每个页面各自全量导入。业务组件在容器挂载后初始化一次，数据变化调用 setOption，不因为“按需注册”就忽略实例生命周期。E1（直接证据）中，本地 src/types/echarts.ts 确实使用核心入口，注册柱、仪表、线、饼、地图、散点、桑基等图表，多种组件、特性和 CanvasRenderer（画布渲染器）；出库趋势组件调用 useECharts、echarts.init 与 setOption。但源码意图不能证明最终制品一定变小，因为实际可达依赖、重复包、构建配置和压缩都会影响结果。我只会说“存在按需注册实现”，要声称包体收益必须比较同一构建条件下的产物分析和浏览器加载。SVGRenderer（矢量渲染器）虽被导入但指定注册列表未见启用，也不能据此说双渲染器已使用。性能、线上指标和收益都保持 E0（未证实）。 验证按需注册时，我会固定锁文件、环境变量和构建参数，比较模块可达图、压缩前后制品、重复版本和浏览器实际传输；再走一遍所有图表路由，确认没有因漏注册导致运行时空白。若某图表只在低频页面使用，还要结合路由动态加载评估，而不是把所有能力放进首屏公共块。结论只引用可复现报告，不凭导入语法推断收益。
• 追问 1：按需注册为何可能不减包体？
• 直答 1：其他全量导入、重复依赖或构建不可消除副作用都可能让模块仍进入制品。
• 追问 2：渲染器如何选择？
• 直答 2：根据数据量、交互、清晰度和导出需求验证，选择后只注册实际使用者。
• 追问 3：如何证明收益？
• 直答 3：在相同锁文件与构建参数下比较产物依赖分析、压缩大小和真实加载。
• 详细章节：工程化依赖图

21. 问题（综合 21）：ECharts（图表库）实例泄漏如何预防和排查？

• 口述答案：我会把图表实例与 Vue（前端框架）组件生命周期一一绑定。组件挂载且容器有有效尺寸后初始化一次，把实例保存在组件引用中；查询或筛选变化只构造新配置并调用 setOption，不在每次渲染函数里重新 echarts.init。容器尺寸变化由 ResizeObserver（尺寸观察器）或受控窗口监听触发 resize，高频变化按动画帧合并。图表点击、窗口事件、观察器和业务订阅都保存处理器引用，卸载时按相反顺序停止观察、off 解绑、移除外部监听并 dispose，同时清空引用。排查时重复进入离开页面，观察实例计数、事件触发次数、堆快照、画布节点和内存是否回落；若一次点击触发多次请求，优先检查重复绑定和旧实例。指定 E1（直接证据）可看到本地出库趋势组件在查询后进入渲染函数并调用 echarts.init 和 setOption，但指定范围未见 resize、dispose 或事件解绑，所以只能记录潜在风险和核对路径，不能直接断言线上已泄漏。修复后用循环导航和同一筛选更新验证实例唯一、事件单次、卸载回落。 为了让问题可回归，我会建立循环导航脚本或人工步骤：进入页面、切换筛选、折叠侧栏、离开页面，重复多轮后比较基线与末次的实例、监听器、画布节点和内存；再触发一次点击确认只执行一次处理。修复不能只在卸载加 dispose，还要保证更新路径不重复初始化、观察器引用可释放、隐藏容器恢复尺寸正确。
• 追问 1：为什么 clear 不能代替 dispose？
• 直答 1：清空配置不一定释放渲染上下文、事件系统和容器关联，卸载仍需销毁实例。
• 追问 2：隐藏标签页为什么图表空白？
• 直答 2：初始化时容器可能是零尺寸，显示后需触发一次 resize。
• 追问 3：如何避免重复事件？
• 直答 3：保存处理器引用，更新前按需解绑或只注册一次，卸载时完整 off。
• 详细章节：图表生命周期

22. 问题（综合 22）：ECharts（图表库）数据量很大时如何优化？

• 口述答案：我不会先随机删点，而是从用户决策和像素分辨率倒推数据粒度。看趋势时由服务端按明确时间桶聚合，除了平均或总量，还保留计数、最小、最大和末值，避免短时峰值被吞掉；看异常时使用保峰值的降采样或只加载异常窗口；看明细时切换为分页表格，不强迫图表承担逐条核对。前端限制可见时间范围和系列数量，复用 ECharts（图表库）实例，通过 setOption 更新；必要时启用库支持的渐进渲染，但要验证首个可用画面、完整呈现时间和交互响应，因为渐进只摊平主线程压力，不减少总工作。数据转换尽量避免在每次响应式更新中多次复制大数组，工具提示和标签只在需要时开启。接口返回口径、时区和版本，图表、表格、导出共享筛选；聚合前后用总量、极值和桶边界做守恒校验。观测上记录点数、序列数、转换耗时、长任务和内存趋势，但 RUM（真实用户监控）接入为 E0（未证实）。真实阈值需在目标设备和数据分布上压测，不能把演练中的点数当线上限制。 我会把性能预算写成可验证契约：接口返回的点数和序列有上限，超过范围给出聚合或缩小窗口建议；浏览器记录数据转换、setOption 到首个可用画面、完整渲染和交互阻塞阶段。优化后不仅比较耗时，还要用同一原始窗口核对总量、峰值、异常点和时区边界，确保性能收益没有改变业务结论或让导出与图表口径分叉。
• 追问 1：为什么平均聚合不够？
• 直答 1：平均会掩盖尖峰和短时异常，应至少保留极值与计数。
• 追问 2：渐进渲染能减少网络量吗？
• 直答 2：不能，它主要改变前端绘制调度；网络量要靠聚合、窗口化或压缩降低。
• 追问 3：何时改用表格？
• 直答 3：用户需要精确逐条核对、排序或复制时，分页表格比高密图形更合适。
• 详细章节：图表大数据

23. 问题（综合 23）：图表页面如何设计加载、空、错误、权限和陈旧状态？

• 口述答案：我会先把状态建模清楚，而不是用一个 loading 布尔值覆盖所有情况。首次加载时没有旧数据，展示与布局一致的骨架和可读状态；刷新中若身份与筛选不变，保留旧图并标注刷新中，避免界面跳空；成功且确实无记录才进入空态，说明筛选范围并提供调整条件；传输或业务错误显示稳定文案、Trace ID（链路标识）的可复制安全片段和预算内重试入口；无权限明确说明不可见，不把它伪装成空数据；旧缓存可用但再验证失败时标记陈旧、显示数据时间并阻断依赖实时正确性的危险操作。身份、仓库或筛选变化时不能继续展示旧上下文数据，应先隔离。部分成功的多个图表分片各自呈现状态，页面顶部给总体摘要，避免一个失败让全部白屏。状态文本、图标和颜色共同表达，并提供同口径表格和摘要，满足可访问性。观测上分别统计空态、权限拒绝、刷新失败和陈旧展示，不能把空数据算接口成功后就不再关注。E1（直接证据）只证明本地图表初始化与配置，完整状态是否实现仍为 E0（未证实）。 状态验收会用明确夹具分别返回零条、权限拒绝、部分依赖失败、缓存命中后刷新失败和身份切换，截图与可访问树都要呈现正确文本、操作和焦点。监控也要使用互斥状态定义，否则“空数据率”可能混入权限和错误。产品文案避免“暂无数据”包办一切，关键页在陈旧状态下明确哪些动作仍可执行。
• 追问 1：刷新时为何保留旧图？
• 直答 1：同一上下文下可减少跳动并保持任务连续，但必须明确标记刷新中和新鲜度。
• 追问 2：无权限能否显示空图？
• 直答 2：不能，空图会误导为没有业务数据，应显示明确权限状态。
• 追问 3：错误时可以显示上次数据吗？
• 直答 3：可以在身份和查询一致时显示，但必须标陈旧并限制关键操作。
• 详细章节：图表状态

24. 问题（综合 24）：如何让 ECharts（图表库）对键盘和屏幕阅读器用户可用？

• 口述答案：我会把图表视为一种展示，不把它作为信息的唯一载体。页面先用语义标题说明图表主题、筛选范围、更新时间和口径，再提供一段可读摘要，指出主要趋势、峰值或异常；同一数据提供可排序、可分页的语义表格，用户无需识别画布也能获得等价结论。原生按钮和表单优先，图例、筛选和数据点交互若必须自定义，就补充 ARIA（无障碍富互联网应用）名称、角色、状态和关系，并实现符合预期的键盘行为与可见焦点，而不是只写角色。颜色不作为唯一编码，正常、关注和严重同时使用文字、形状、线型或图案，保证高对比。弹窗打开后聚焦标题或首个有效控件，焦点圈定在弹窗内，关闭后返回触发点；动态刷新不朗读每个数据点，只合并播报需要行动的状态变化。加载、空、错误、无权限和陈旧状态都提供文本。验收时只用键盘完成筛选、查看摘要、打开明细和返回，并用可访问树检查名称。指定源码未证明本地无障碍已落地，所以只能作为 E3（通用机制）和验收方案。 验收不只运行自动规则，我会让测试者关闭鼠标，从页面标题开始完成筛选、读取趋势、进入明细、处理错误并返回；同时检查高对比、放大、焦点可见和动态刷新。数据表与图表必须使用同一筛选和口径，若图形插件无法提供完整键盘交互，表格仍保证任务可完成。发现问题记录具体步骤，不用一个总分掩盖阻断项。 发布门禁应保存关键路径的人工验收记录，并在数据结构或图表交互变化后重新执行，避免一次通过后长期失真。
• 追问 1：需要让每个图表点都可聚焦吗？
• 直答 1：通常不需要，摘要和数据表更高效；只为关键交互点提供合理键盘入口。
• 追问 2：ARIA（无障碍富互联网应用）能代替键盘逻辑吗？
• 直答 2：不能，它只补充可访问树语义，不会自动实现焦点和按键行为。
• 追问 3：如何避免动态播报过多？
• 直答 3：只合并播报需要用户行动的状态，普通数据刷新更新摘要但不强制打断。
• 详细章节：可访问性

25. 问题（综合 25）：复杂筛选、弹窗和错误状态的焦点如何管理？

• 口述答案：我会先保持文档结构和视觉顺序一致，让原生表单、按钮和链接自然进入焦点序列，避免用正数 tabindex 人工重排。复杂筛选提交后，如果存在字段错误，页面生成错误摘要并把焦点移动到摘要或首个无效字段，字段通过语义关联获得错误说明；用户修正后焦点保留在当前控件，不因后台刷新跳走。打开明细弹窗时保存触发元素，聚焦弹窗标题或首个可操作控件，把键盘焦点圈定在弹窗内；关闭后回到原触发点，如果该行因刷新消失，则回到逻辑上最近的列表位置。异步加载完成不自动抢焦点，只有阻断任务的全局错误才把焦点移到错误标题；后台刷新失败但旧数据可用时，用不打断操作的状态区域提示。无权限控件通常不提供无效操作入口，但页面要有可读原因；禁用按钮如果用户需要理解原因，应在附近提供可聚焦说明。图表交互提供摘要和表格路径，键盘用户不必遍历所有点。验收时覆盖正向和失败路径：从筛选到错误、打开关闭弹窗、刷新列表和身份切换，检查焦点可见、顺序稳定且不会落到已销毁节点。E0（未证实）边界是本地指定证据未包含这些无障碍测试结果。 工程实现要把“触发元素、当前业务键、期望回退位置”作为恢复上下文保存，不能只保存一个可能被列表刷新销毁的节点引用。自动化可检查焦点是否仍在可见区域和弹窗圈定范围，人工测试再验证朗读顺序与业务语义；两者结合才能发现异步更新后的真实断点。
• 追问 1：为什么不使用正数 tabindex？
• 直答 1：它会制造难维护的人工顺序，界面变化后容易与视觉和语义顺序冲突。
• 追问 2：后台刷新完成要播报吗？
• 直答 2：只有需要行动的变化才简短播报，普通刷新不应持续打断操作。
• 追问 3：触发元素被删除后焦点放哪里？
• 直答 3：回到逻辑上最近的列表项或列表标题，并保持用户上下文。
• 详细章节：ARIA（无障碍富互联网应用）与焦点

26. 问题（综合 26）：前端错误边界如何设计才能既降级又不掩盖错误？

• 口述答案：我会按故障域设置错误边界：页面外壳负责保持导航和退出能力，业务分区边界隔离单个图表或待办区域，网络与资源层用显式状态机处理请求错误。组件边界捕获渲染和生命周期异常后，记录错误指纹、页面版本、路由模板和 Trace ID（链路标识），展示可操作的局部降级，例如切换到表格、重新加载分区或返回安全页面；它不能捕获所有事件回调、承诺拒绝、资源加载和第三方脚本错误，这些需要各自捕获点，全局监听只做最后留证。是否继续渲染取决于状态可信度：普通图表失败可以保留其他分区，库存调整或支付状态不可信时必须阻断危险按钮，不能为了“页面可用”展示伪成功。重试走统一预算并继承取消，重复崩溃要停止自动重试，防止错误循环。日志先脱敏，不上报令牌、用户输入和完整敏感响应；降级文案不显示内部堆栈。修复后用同一页面版本、操作和失败注入验证边界只影响预期区域，监控错误指纹是否回落。E1（直接证据）未证明本地错误边界实现，所以这里是 E3（通用机制）设计，不冒充项目事实。 边界复位时还要清理该故障域的订阅、计时器、请求和陈旧缓存，随后重新取得权威快照；若只把错误界面隐藏而保留污染状态，用户下一次操作仍可能产生重复副作用。发布前应注入渲染异常、异步拒绝和资源失败，分别验证捕获点、降级范围与恢复路径。 每次降级还应记录触发条件和恢复门槛，防止临时兜底长期取代根因修复。
• 追问 1：边界越多越好吗？
• 直答 1：不是，边界应对应可独立恢复的故障域，过细会增加状态和重复界面复杂度。
• 追问 2：捕获后是否要清空状态？
• 直答 2：清理受污染分区即可；身份或关键业务状态不可信时扩大清理并阻断操作。
• 追问 3：为什么全局监听不能替代局部边界？
• 直答 3：全局监听只能留证，缺少组件上下文和可控恢复界面。
• 详细章节：错误边界与观测

27. 问题（综合 27）：如何用 Trace ID（链路标识）定位一次前端接口失败？

• 口述答案：我会先从用户现象固定页面版本、路由模板、操作时间、业务标识安全摘要、请求阶段、稳定错误码和 Trace ID（链路标识）。浏览器日志记录请求开始、取消、重试、响应解析、状态提交和错误边界阶段，但不记录令牌、完整地址查询参数、支付敏感信息或大请求体；如果响应没有 Trace ID（链路标识），网关需要统一生成并在安全响应头或错误对象中回传。随后按该标识查网关访问日志，确认请求是否到达、身份结果、上游目标、状态和耗时；再进入 Java（编程语言）服务追踪下游调用、数据库、消息或 Runner（执行器）任务。若前端报超时而服务端已成功，就进入未知态查询而不是重放；若网关未见请求，则检查浏览器取消、跨域、网络和代理；若服务端快速返回业务拒绝，则回到契约和输入。跨端时间只作辅助，Trace ID（链路标识）和业务标识共同关联更可靠。修复后使用同一操作验证前端、网关和服务日志能连成一条链，错误码和用户文案符合预期。日志查询本身需要权限和审计，Trace ID（链路标识）不是安全凭证。生产观测平台与保留期未在证据中确认，因此只说明方法。 对消息和异步任务还要记录关联标识的传播或链接关系，因为一次请求结束后工作可能继续；找不到连续父子链时，应按业务键、事件标识和时间窗补证。最终结论必须指出故障发生在哪个阶段、用户状态是否已确定、采用了什么止血，以及哪条证据排除了其他假设。
• 追问 1：只有 Trace ID（链路标识）就够吗？
• 直答 1：不够，还需页面版本、业务标识摘要、错误阶段和时间范围解释上下文。
• 追问 2：前端可以自己生成吗？
• 直答 2：可以生成请求关联标识，但网关应建立可信链路并防止客户端伪造污染内部追踪。
• 追问 3：日志中能记录完整响应吗？
• 直答 3：不应默认记录，应按字段白名单和脱敏摘要留证，避免隐私与容量风险。
• 详细章节：正式跨端时序图

28. 问题（综合 28）：前端性能指标、采样和脱敏如何一起设计？

• 口述答案：我会先定义要回答的体验问题，再选择信号：页面导航和关键资源说明加载阶段，长任务与交互摘要说明主线程阻塞，接口阶段说明网络和服务等待，图表点数与更新时间解释可视化成本。每条事件带页面版本、路由模板、设备与网络的粗粒度分类、会话匿名标识、Trace ID（链路标识）和采样决策，但不包含用户输入、令牌、完整地址、精确位置、支付信息或未经白名单的业务数据。采样采用分层策略：会话首条、崩溃、支付未知态、权限异常和一致性错误保底留证；高频普通性能事件按会话和路由采样，并用本地累计数表达被采样掉的重复；新版本、首次指纹或异常突增可动态提高。采样决定尽量在会话内稳定，避免只收集最慢或最快造成偏差。上报使用小批量、页面生命周期友好且有队列上限的方式，观测管道过载时先丢调试级事件。服务端再次做字段白名单、脱敏和访问控制。告警使用聚合后的用户影响、持续时间和版本，而不是单条事件。RUM（真实用户监控）是否接入、真实采样率和阈值为 E0（未证实），我不会写成当前项目能力。 分析时必须用采样权重还原总体，并同时展示样本量、缺失率和客户端版本分布；否则不同采样率会制造虚假的版本差异。事件模式变更需要版本和兼容窗口，服务端拒收未知敏感字段并统计丢弃原因，使隐私控制和数据质量都能被审计。 仪表盘展示采集版本和覆盖率，避免把观测盲区误判为性能改善。
• 追问 1：为什么不能所有事件都上报？
• 直答 1：会增加用户网络、存储和隐私成本，高频重复也可能淹没关键错误。
• 追问 2：采样会不会漏掉事故？
• 直答 2：会有风险，所以关键类别保底、新指纹提升采样，服务端还有独立指标和审计。
• 追问 3：地址为何要去查询参数？
• 直答 3：查询参数常含业务标识和用户输入，路由模板更适合聚合且隐私风险更低。
• 详细章节：浏览器性能

29. 问题（综合 29）：如何建立从前端错误到告警和恢复的闭环？

• 口述答案：我会把闭环拆成发现、聚合、定位、止血、修复、验证和复盘。前端错误边界、请求层和性能采集先生成结构化事件，经过脱敏与采样后，按错误指纹、页面版本、路由模板、业务码和用户影响聚合；Trace ID（链路标识）把浏览器事件连接到网关、Java（编程语言）服务、数据库和异步任务。告警条件同时考虑错误率或受影响会话、持续时间、新版本变化和关键业务类型，支付未知态、权限越权和库存一致性错误优先级高于普通图表工具提示异常；同一事故合并通知并设置抑制，避免告警风暴。定位后先选可逆止血：关闭危险操作、降级到表格、降低查询频率、回滚前端版本或隔离导出队列，同时保全证据。修复包含契约、状态机或生命周期根因，不只加一个吞错分支。验证时用原操作、失败注入和监控窗口确认错误指纹回落、关键成功路径恢复且没有新回归；复盘记录触发条件、为何未提前发现、门禁和负责人。IoT（物联网）报警风暴治理可作为告警聚合的设计类比，但不能说本前端已经复用该系统。真实告警平台、阈值和恢复时间均需现场核对。 告警关闭不能只看事件暂时归零，还要确认采集链路正常、降级开关已按计划恢复、积压事件处理完毕并复测用户关键路径。复盘中的改进项需要责任人、截止时间和验证信号，下一次同类指纹出现时能自动关联既有事故与处置手册。 最后补做一次恢复演练，确认告警能再次触发、聚合并正常解除。
• 追问 1：单条崩溃要立即告警吗？
• 直答 1：关键业务和新指纹可立即关注，普通重复错误应结合影响与持续时间聚合。
• 追问 2：如何避免告警风暴？
• 直答 2：按指纹、版本和故障域聚合，设置抑制、冷却与恢复通知。
• 追问 3：修复后看错误率归零就够吗？
• 直答 3：不够，还要验证成功路径、性能、降级恢复和无新增指纹。
• 详细章节：可观测性

30. 问题（综合 30）：如何设计一个可信的 WMS（仓储管理系统）运营看板？

• 口述答案：我会先定义看板服务的决策，而不是先画图。库存差异、订单或入库异常、导出失败、账单与成本待办分别有独立口径、状态机、负责人和下钻路径；首屏只给摘要、数据时间、权限视角和风险状态，点击后进入同口径表格与业务证据。BFF（后端前端聚合层）可聚合页面所需分片，但库存、支付和任务状态仍由领域服务裁决；部分失败时保留可信区域并显式标错，不用零值填充。接口支持白名单筛选、稳定游标、资源版本和统一错误，写操作携带幂等键与版本。ECharts（图表库）实例复用，数据先按决策粒度聚合，加载、空、错误、无权限和陈旧状态完整；图表同时提供摘要和表格，颜色不是唯一编码。刷新策略按变化频率选择，未证实的 WebSocket（网页套接字）不作为既有能力，默认设计可恢复的 Polling（轮询）或页面返回后刷新。观测用页面版本、业务码和 Trace ID（链路标识）跨端定位，日志采样脱敏。E1（直接证据）支持本地 Vue（前端框架）、Pinia（状态管理库）、路由和部分 ECharts（图表库）调用，E2（结构佐证）支持四类页面语义；所有数值、收益和生产阈值都不编造。 看板上线前应从一个异常摘要随机抽样下钻到订单、库存流水或任务记录，核对数量、金额、状态和时间窗守恒；部分依赖故障时验证未受影响区域仍可信。容量门禁同时限制接口扇出、首屏点数和刷新频率，超过预算优先聚合或转异步明细，而不是让浏览器（网页浏览器）承担无界数据。
• 追问 1：为什么首屏不展示所有明细？
• 直答 1：会增加接口扇出、渲染和认知负担，摘要加按需下钻更适合重复决策。
• 追问 2：部分失败时是否整页报错？
• 直答 2：只有共享身份或契约失效才整页阻断，独立分片失败应局部降级并留证。
• 追问 3：如何证明看板可信？
• 直答 3：图表、表格、导出共享口径与版本，并可沿业务标识核对权威流水。
• 详细章节：项目事实账本

31. 问题（综合 31）：订单异常页面如何处理状态乱序和重复事件？

• 口述答案：我会让订单服务维护权威状态机和状态版本，前端只消费合法迁移后的投影。每个订单响应包含当前状态、版本、更新时间和可执行动作；如果使用事件提示，事件带唯一标识、订单标识和版本，前端先去重，再比较版本，旧事件不能覆盖新状态，发现版本跳跃就重新查询快照。用户执行重试、取消或补偿时携带订单版本和幂等键，Java（编程语言）服务校验动作在当前状态是否允许；版本冲突返回当前状态，页面保留用户意图并提示刷新，不自动重复副作用。BFF（后端前端聚合层）可以把订单、仓储和物流摘要组合成异常视图，但不能把不同系统的未知态压成一个“失败”；下钻页分别展示订单状态、仓储执行、物流结果和补偿任务。Polling（轮询）、SSE（服务器发送事件）或 WebSocket（网页套接字）只负责刷新触发，断线或缺口都回到权威查询。观测上用订单安全摘要、状态版本、事件标识和 Trace ID（链路标识）串起网关、服务、消息和任务。E2（结构佐证）允许讲订单异常页面语义，不允许宣称本地实时事件、异常率或恢复收益。 验收数据应包含重复事件、终态后迟到中间态、版本跳跃和同版本内容冲突；前端分别做到忽略、查询或显式告警，不能静默覆盖。服务端若对状态做映射，还要保留原始渠道状态和映射版本，便于规则升级后解释历史轨迹，而不是只保存当前展示文案。
• 追问 1：前端可以自行跳过中间状态吗？
• 直答 1：展示可折叠中间过程，但权威迁移必须由服务端状态机决定。
• 追问 2：重复事件如何处理？
• 直答 2：按事件标识去重，并按订单版本保证旧事件不覆盖新状态。
• 追问 3：版本跳跃意味着什么？
• 直答 3：可能漏事件或订阅恢复不完整，应停止增量合并并查询最新快照。
• 详细章节：实时刷新矩阵

32. 问题（综合 32）：账单待办页面如何表达支付、对账和人工处理边界？

• 口述答案：我会把账单待办定义为“需要确认或行动的权威状态集合”，而不是简单失败列表。接口按支付单、账单或结算标识返回当前阶段、金额与币种的安全展示、状态版本、产生原因、最后更新时间、可执行动作和证据引用；支付处理中、渠道结果未知、账本不一致、对账差异和人工审核分别建模，不能统一成红色失败。前端只能发起查询、认领、备注或服务端明确允许的补偿动作，每次写入带权限、版本和幂等键；Java（编程语言）服务核对账本与渠道，前端不自行改金额或终态。页面刷新可用有限 Polling（轮询）或返回后查询，实时通道存在性为 E0（未证实）；旧数据可展示但标新鲜度，涉及资金动作前强制重校验。安全上按岗位和业务线裁剪字段，日志不记录完整支付信息，导出使用短期凭证并审计。观测上以支付单安全摘要和 Trace ID（链路标识）关联回调、查询、账本和对账任务，告警按影响与持续时间聚合。E2（结构佐证）允许讲账单与成本待办入口，但真实渠道、金额、处理量和结果没有证据，面试中应主动说明边界。 人工处理必须采用认领或租约避免多人同时操作，提交时再次校验版本、职责分离和审批条件；所有调整通过追加凭证或受控命令完成，不能直接修改历史账本。关闭待办前重新比较渠道、业务单和分录三方证据，并保留差异原因、审批人和恢复验证记录。
• 追问 1：待办里的未知态能自动关闭吗？
• 直答 1：只有服务端按渠道、账本和业务窗口裁决后才能关闭，前端计时器不能决定。
• 追问 2：为什么金额不由前端重算？
• 直答 2：资金口径与账本一致性属于服务端权威，前端计算只能做展示校验。
• 追问 3：人工操作如何审计？
• 直答 3：记录身份、理由、前后版本、业务标识和 Trace ID（链路标识），敏感内容按权限查看。
• 详细章节：支付未知态

33. 问题（综合 33）：前端接口层如何同时防越权、重放和敏感信息泄露？

• 口述答案：我会把安全责任分层。认证层管理短期访问令牌和受保护的刷新流程，身份切换时取消旧请求并清空权限路由、缓存和组件状态；授权层中，前端隐藏无权入口只改善体验，BFF（后端前端聚合层）和 Java（编程语言）服务必须按租户、业务线、资源归属和动作最终校验。输入层只开放白名单筛选、排序、页大小和文件类型，服务端参数化查询、限制范围并验证业务不变量；写操作携带幂等键、资源版本和必要的防重放信息，同键不同摘要拒绝。传输与浏览器层根据部署选择跨站请求防护、来源控制和安全响应头，令牌不放入地址，不把服务端密钥下发前端。输出层按上下文编码，敏感字段在服务端裁剪；下载凭证短期、绑定身份和产物，文件名与内容类型受控。日志、性能事件和 Trace ID（链路标识）都经过字段白名单、脱敏、采样和访问审计，不记录令牌、密码、完整地址、支付数据或大响应。第三方脚本最小化权限并受版本治理。最后用直接构造请求、身份切换、重复提交、参数篡改和日志检查验证，不能把“按钮看不见”当安全测试通过。 威胁测试还应覆盖旧标签页、撤权后的缓存、跨租户业务标识、重复签名和过期下载凭证，确认每一层独立拒绝且错误响应不泄露资源是否存在。密钥轮换、令牌撤销和审计留存都需要运行手册，安全不是一次上线检查，而是可持续验证的控制面。 关键拒绝路径还要有独立审计告警，确保攻击被阻断后仍可追查来源和影响范围。
• 追问 1：幂等键能防越权吗？
• 直答 1：不能，它只帮助去重，服务端仍需独立身份和资源授权。
• 追问 2：前端脱敏后服务端还需脱敏吗？
• 直答 2：需要，客户端可被绕过，服务端日志管道必须执行最终字段控制。
• 追问 3：下载地址为何要短期有效？
• 直答 3：可缩短泄露后的可利用窗口，并在重新签发时再次鉴权。
• 详细章节：浏览器安全

34. 问题（综合 34）：如何做前端看板容量估算并形成降级和排障方案？

• 口述答案：我会分别估算请求、连接、数据、渲染、任务和观测六类容量。请求量用活跃页面数乘每页接口数再除以刷新周期，并考虑失败重试和 BFF（后端前端聚合层）扇出；长连接按同时在线页面、每用户连接数、心跳和重连峰值估算；图表按可见系列、点数、转换复制和标签数量评估主线程与内存；导出按并发任务、单任务数据范围、队列和对象存储隔离；日志按事件大小、采样率和事故放大量估算。先设可验证预算，再设计降级：延长 Polling（轮询）、页面不可见停更、合并查询、服务端聚合、限制时间窗口和系列、图表切表格、暂停低优先导出、采样低价值日志。排障时固定页面版本、身份、筛选、时间和 Trace ID（链路标识），从浏览器竞态、缓存和 ECharts（图表库）实例，到网关鉴权限流、BFF（后端前端聚合层）扇出，再到 Java（编程语言）状态机、数据库和 Runner（执行器）逐层核对。止血与保全证据并行，修复后用负载阶梯、失败注入和长时间导航验证恢复。所有示例数字必须标为演练；本地连接数、点数阈值、RUM（真实用户监控）和收益为 E0（未证实），不能替代压测与生产观测。 演练时把活跃页面、刷新周期、每次响应大小和失败重试率写入公式，逐项提高直到入口、浏览器（网页浏览器）或下游先达到预算，再验证对应降级能否把系统拉回稳定区。恢复后分阶段撤销开关，观察积压、错误率和交互分位数，避免全部流量同时反弹。
• 追问 1：先优化请求还是渲染？
• 直答 1：先用分阶段证据识别主瓶颈，不能凭感觉；二者也可能因大响应同时恶化。
• 追问 2：重试量为什么要算入容量？
• 直答 2：故障时重试会放大入口和下游负载，常常决定恢复是否成功。
• 追问 3：没有生产数据如何估算？
• 直答 3：用明确假设给出公式和范围，再通过压测、灰度与观测逐步校准，不把假设当事实。
• 详细章节：容量与排障

3. 项目话术

面试中可这样复述：本地 E1（直接证据）能确认 hiwi-web（仓储前端工程）使用 Vue（前端框架）入口、路由和 Pinia（状态管理库），权限仓库会装卸运行时路由；ECharts（图表库）有集中按需注册，出库趋势组件调用初始化和 setOption。我会把这部分讲成“已经读到的架构事实”。WMS（仓储管理系统）页面对库存差异、订单异常、导出失败、账单与成本待办的承接属于 E2（结构佐证），用于解释如何设计资源契约、状态壳、下钻和跨端证据，但不编造数量和收益。BFF（后端前端聚合层）、幂等、游标、支付未知态、实时通信、图表完整生命周期、ARIA（无障碍富互联网应用）和观测闭环属于可落地的 E3（通用机制）。指定范围没发现的 WebSocket（网页套接字）、RUM（真实用户监控）、resize、dispose、事件解绑、生产容量和告警阈值明确列为 E0（未证实），回答核对路径而不说成既有成果。

4. 快速复习清单

• 能说明浏览器、BFF（后端前端聚合层）与领域服务各自拥有的状态和责任。
• 能设计 REST（表述性状态转移）资源、版本、统一错误、幂等键和重试预算。
• 能解释访问令牌刷新单飞、权限路由装卸与服务端最终授权。
• 能比较偏移分页、游标分页、筛选排序白名单和快照语义。
• 能用查询键解释防抖、取消、迟到响应和陈旧缓存。
• 能口述库存查询、异步导出和支付未知态三组全栈契约。
• 能比较 Polling（轮询）、SSE（服务器发送事件）、WebSocket（网页套接字）和回调后刷新。
• 能解释 ECharts（图表库）按需注册、实例复用、setOption、resize、off 与 dispose。
• 能为大数据图表选择聚合、降采样、渐进渲染和表格替代。
• 能区分加载、空、错误、无权限、部分成功和陈旧状态。
• 能设计 ARIA（无障碍富互联网应用）语义、键盘、焦点、颜色与替代文本。
• 能用错误边界、脱敏日志、Trace ID（链路标识）、采样和告警完成跨端定位。
• 能以公式估算查询、连接、图表、导出和日志容量，并给出降级。
• 能严格区分 E1（直接证据）、E2（结构佐证）、E3（通用机制）与 E0（未证实）。