错误提示怎么设计？字段定位、文案与读屏反馈

错误提示的任务是帮助用户完成修复，而不是宣布系统出了问题。先定位字段，再解释原因，最后给出可执行动作；页面级服务失败则补充重试或联系客服。涉及无障碍时，可用WCAG 2.2 设计检查清单核对颜色、焦点和读屏顺序。

字段级与页面级错误分开

文案写事实和下一步

“输入错误”无法帮助修复。可以说明“请输入包含 @ 的邮箱地址”，但不要把内部错误码直接展示给用户。涉及权限、库存或审核时，写清当前限制和可用入口，避免承诺并不存在的解决方式。

错误位置和摘要同步

多个字段出错时，顶部摘要列出数量和可点击字段名，字段旁保留具体说明。点击摘要后焦点落在首个错误字段；修复一个后，摘要和错误数量同步更新。

重试和重复提交

服务失败要保留用户已经填写的内容，并区分“重试请求”和“重新填写”。涉及支付或创建操作时，先确认请求是否已受理，再决定是否允许重试，避免生成重复记录。

颜色、焦点与读屏

错误颜色只做辅助，图标和文字要同时存在。状态消息应被读屏正确播报，且不会因为页面重新渲染把焦点丢到无关位置。键盘用户能够从摘要进入字段并返回提交按钮。

把修复路径放进原型

准备字段错误、页面摘要、服务失败、重试成功和全部修复五个画板，连接焦点与提示。评审重点不是红色是否醒目，而是用户能否在一次操作中找到原因并完成恢复。

错误信息由三部分组成

一条可执行的错误提示通常包含位置、原因和修复动作。位置可以通过字段标签和焦点表达；原因要接近真实规则；修复动作可以是修改格式、补齐信息、重试请求或联系支持。三者缺一时，用户只能反复试错。

密码强度不足应说明需要满足的条件，但不要在错误提示中泄露敏感信息。上传失败应说明文件类型、大小或网络原因，并保留重新选择入口。服务错误无法定位到单个字段时，提供页面摘要和重试，不要把错误码当成解释。

注册表单的多错误路径

用户提交注册表单时邮箱格式错误、密码为空、验证码过期。顶部摘要显示三个错误，焦点先到邮箱；修复邮箱后摘要减少到两个，点击验证码错误可重新获取。服务暂时不可用时，已填字段保持原值，提交按钮进入可恢复的重试状态。

无障碍与交付检查

• 错误文案是否能让用户直接采取下一步？
• 摘要、字段提示和读屏播报是否使用同一套文本？
• 颜色之外是否有图标、文字或焦点变化？
• 错误修复后，状态和提交按钮是否同步恢复？

提交前后两类错误

客户端格式错误可以在失焦或提交时提示，服务端业务错误则应在请求返回后解释。两类错误使用不同的恢复动作：格式错误直接回到字段，服务错误保留表单并允许查询或重试。不要在客户端提前断言服务端一定接受。

错误摘要的数量需要和实际字段一致，隐藏字段或折叠区域中的错误也要能被找到。点击摘要后展开相关区域并移动焦点，修复后再收起时不应把未读错误藏起来。

把错误文案作为内容组件管理，设计、开发和客服使用同一术语。上线前抽查长文本、英文混排和系统字体放大，确保提示不会截断关键动作。

错误组件的复用规则

字段错误、页面摘要、提示条和对话框各自承担不同任务，不要用一个红色提示组件覆盖所有情况。组件属性写明错误级别、文案长度、可执行动作和焦点策略，开发与内容团队可以共同维护。

异步请求失败时，错误组件要知道请求是否可能已成功。支付、发布和删除等不可重复操作，需要查询状态或提供安全的再次确认；普通搜索失败则可以直接重试。文案按风险级别写清影响范围。

交付前把错误文案放进长文本、英文混排和窄屏画板，检查换行和按钮宽度。发布后再抽查读屏顺序，确保视觉修复没有破坏语义。

为不同用户写同一事实

字段旁的短提示服务于立即修复，页面摘要服务于快速定位，客服或日志则需要更完整的上下文。三处可以长短不同，但原因和状态必须一致。不要为了缩短提示而删掉关键限制，也不要把内部堆栈暴露给普通用户。

表单重新加载后，错误状态是否保留取决于请求是否已提交。若结果未知，显示查询或再次确认；若明确失败，保留错误和输入。用户切换页面再回来时，能够区分旧错误和最新提交结果。

把错误提示纳入组件和内容审核流程，检查术语、标点、换行和读屏顺序。高风险操作还要让用户知道数据是否已经改变，避免因错误提示不清而重复操作。

交付时统一术语和焦点

错误组件交付包含字段级、页面级、服务级三个变体，以及摘要、焦点和读屏顺序。内容团队按词汇表维护原因和动作，开发按状态接入，测试按恢复路径验收。

对支付、发布、删除等高风险操作增加结果查询说明，避免把未知状态误写成失败并诱发重复提交。

从错误回到成功

每个错误状态都要有一条可完成的恢复路径，并记录修复后摘要、字段、焦点和服务结果。特别测试重复点击和刷新，确保高风险操作不会因为提示不清被执行两次。

用恢复率而不是红色判断

为每种错误准备“发现—理解—修复—提交成功”的连续路径，记录用户是否能在一次操作中找到字段和下一步。颜色、图标和动画都只是辅助，恢复路径才是验收核心。

高风险请求另外测试未知结果和刷新，确认页面不会把已受理的操作误判为失败，也不会让用户重复创建或提交。

错误组件上线后按错误级别抽查读屏、键盘和移动端显示，确认提示仍能指引用户完成恢复。修复文案时同步更新组件说明和测试用例，避免旧提示在其他页面继续出现。

最终验收以“用户能否恢复”为准：找到字段、理解原因、完成动作、看到结果四步缺一不可。这个标准比单看错误颜色更适合全站复用。