企业官网建设流程全解析

Next.js 治愈系表单的错误恢复：从错误状态回到正常，比报错本身更重要

一、错误恢复体验比错误提示文案更影响用户感受

表单错误处理的讨论通常聚焦在提示文案上。如何写得温和、如何避免指令性语气、如何在提交时统一提示。这些都很重要，但忽略了一个更关键的环节：用户看到错误后如何恢复到正常状态。

日记保存失败后，用户看到"保存失败请重试"。点击重试按钮后，输入框被清空了。用户需要重新写一遍500字的日记内容。这种恢复体验比错误提示本身更糟糕——提示写得再温和，让用户重新写500字也不是温和体验。

错误恢复的核心原则是：不丢失用户已经输入的数据。保存失败后，输入框内容必须保留。用户只需要点重试，不需要重新输入。这个原则的实现比写好提示文案更重要。

二、错误恢复的三层策略：保留、引导、简化

错误恢复应该分三层处理：数据保留、操作引导和操作简化。

flowchart TD A[操作失败] --> B[第一层：保留已有数据] B --> C[输入框内容不清空，本地自动保存] C --> D[第二层：引导恢复操作] D --> E[明确告知用户下一步做什么：重试/修改/取消] E --> F[第三层：简化恢复步骤] F --> G[一键重试而非重新填写整个表单]

三层策略的核心顺序是先保数据、再引方向、最后减步骤。很多应用的错误处理只做了第二层（写了提示文案）而忽略了第一层和第三层。保留数据和简化步骤是工程实现层面的事，比文案设计更底层但更重要。

三、错误恢复的实现

// DiaryEditor.tsx：错误恢复优先保留用户输入数据 import { useState, useEffect, useRef } from "react"; export function DiaryEditor() { // 本地自动保存：即使服务端保存失败，本地数据不丢失 const [content, setContent] = useState(""); const [saveStatus, setSaveStatus] = useState<"idle" | "saving" | "error" | "saved">("idle"); const [errorMessage, setErrorMessage] = useState(""); const autoSaveTimerRef = useRef<number | null>(null); // 每30秒自动保存到本地，防止意外丢失 useEffect(() => { autoSaveTimerRef.current = window.setInterval(() => { if (content.trim()) { localStorage.setItem("diary_draft", content); } }, 30000); return () => { if (autoSaveTimerRef.current) clearInterval(autoSaveTimerRef.current); }; }, [content]); // 加载时恢复本地草稿 useEffect(() => { const draft = localStorage.getItem("diary_draft"); if (draft) setContent(draft); }, []); async function handleSave() { setSaveStatus("saving"); try { const response = await fetch("/api/diary", { method: "POST", body: JSON.stringify({ content }), }); if (!response.ok) { setSaveStatus("error"); setErrorMessage("保存遇到了问题，内容还在，点击重试即可"); // 关键：不清空content，用户数据完整保留 return; } setSaveStatus("saved"); localStorage.removeItem("diary_draft"); // 保存成功后清除草稿 } catch (error) { setSaveStatus("error"); setErrorMessage("网络暂时不通，内容已本地保存，稍后重试"); } } return ( <div className="diary-editor"> {/* 输入框内容始终保留，错误状态不影响 */} <textarea value={content} onChange={(e) => setContent(e.target.value)} placeholder="今天想记点什么..." disabled={saveStatus === "saving"} // 保存中禁用输入，避免冲突 /> {/* 错误提示：温和文案 + 一键重试 */} {saveStatus === "error" && ( <div className="error-recovery"> <p className="error-message">{errorMessage}</p> <button onClick={handleSave}>重试保存</button> <button onClick={() => setSaveStatus("idle")}>稍后保存</button> </div> )} {/* 保存成功提示 */} {saveStatus === "saved" && ( <p className="success-note">已保存</p> )} </div> ); }

核心设计有三点。第一，textarea 的 value 始终绑定 content state，错误发生时不清空。第二，localStorage 每30秒自动保存草稿，即使浏览器意外关闭内容也不丢失。第三，错误恢复区提供"重试"和"稍后保存"两个选项，用户可以根据场景选择立即重试或暂时放弃保存但不丢数据。

四、错误恢复不能掩盖真实错误原因

温和的恢复体验不应该掩盖错误的技术原因。"保存遇到了问题"是面向用户的文案，但技术团队需要知道具体是什么问题——是数据库超时、是网络断连、还是数据格式异常？

错误日志应该记录详细的技术信息。面向用户的提示温和简短，面向开发者的日志详细精确。两层信息服务于不同目的，不应该混在一起。如果把技术细节展示给用户，温和文案就变成了噪音。

还有一个边界：本地草稿的存储时间。localStorage 的草稿不应该永久保留。如果用户一周都没重试保存，草稿应该提示用户处理——要么保存要么删除。无限保留的草稿会让 localStorage 变成数据垃圾桶。

最后，错误恢复在多步骤表单中更复杂。第一步保存成功但第二步失败时，第一步的数据已经提交了。恢复时需要决定是重新提交第二步还是回滚第一步。这个决策取决于业务逻辑——日记保存可以部分成功（先保存文字后保存标签），但支付不能部分成功。

五、总结

表单错误恢复应优先保留用户输入数据，不让用户重新填写。三层策略：数据保留（本地自动保存）、操作引导（明确告知下一步）、操作简化（一键重试而非重新填写）。localStorage 每30秒保存草稿防止意外丢失。面向用户的提示温和简短，面向开发者的日志详细精确。草稿不应永久保留，超过一周需提示处理。多步骤表单的错误恢复需根据业务逻辑决定部分回滚还是全部重试。