简历追问：HATEOAS 兜底状态与错误标准化处理

关联：全栈工程师简历 > HATEOAS 资源契约架构、HATEOAS 架构下前端如何处理兜底状态或无网环境。

对应简历描述

围绕资源加载失败、动作缺失、契约缺失、链式导航中断等场景，区分资源不可用、动作不可执行、网络错误与鉴权失败等状态，为 UI 层提供一致的禁用、隐藏、重试与错误反馈策略。

面试官真正想确认

你是否真的处理过“契约驱动 UI”失败时的用户体验，而不是只在 happy path 上渲染按钮。

连续追问链

1. 错误分类

• 资源加载失败、资源不存在、动作缺失、契约缺失、鉴权失败、网络错误分别怎么定义？
• 哪些错误是用户可恢复的，哪些是系统需要报警的？
• _links 为空是合法业务状态，还是后端契约事故？前端如何区分？

2. UI 策略

• 什么时候隐藏按钮，什么时候禁用按钮，什么时候展示重试入口？
• “动作不可执行”和“用户无权限”在交互上是否一样？文案怎么避免误导？
• 链式 follow() 中间失败时，页面是整体失败、局部失败，还是保留上一级资源？

3. 弱网与缓存

• 无网时是否使用最后一次资源快照？如果使用，如何标记“这是旧契约”？
• 用户基于缓存动作提交 mutation，恢复网络后状态已变化，冲突怎么解决？
• 离线队列如何做幂等 id、重试次数、过期时间和用户提示？

4. 可观测性

• 契约缺失是否会上报？上报字段包含 relation、resource type、用户角色、接口版本吗？
• 错误标准化是在 SDK 做，还是每个业务页面自己 try/catch？
• 测试用例如何覆盖 403、404、409、5xx、timeout、invalid contract？

场景推演题

用户打开订单详情页时网络抖动，详情数据从缓存恢复出来，但 _templates.approve 缺失。用户刷新后 approve 又出现。请解释 UI 全流程和 SDK 状态变化。

继续追：如果用户离线点击 approve，恢复网络后服务端说订单已被别人撤回，你怎么提示？

准备证据

• 错误枚举和 UI 策略矩阵。
• 一段链式导航失败的处理伪代码。
• 离线/弱网/契约缺失的测试用例。

容易露馅的回答

• “接口失败就 toast 一下。”
• “没有 _links 就页面空着。”
• “前端可以根据 status 兜底猜一下权限。”
• “无网不考虑，企业 SaaS 一般在线。”