PHP 表单校验怎么把错误回显到对应字段：session flash 与 aria-describedby 的实现

做用户资料类表单的时候，最影响体验的场景就是提交失败后，页面只在顶部孤零零显示一句「提交失败」，用户根本不知道到底是邮箱格式不对、昵称长度超限还是手机号没填对。如果你在 PHP 项目里用了 POST-Redirect-GET 模式做提交防重，校验产生的错误还没法直接挂在当前请求变量里，一重定向之前的错误数据就全丢了。

先把一次失败提交拆成三个状态

以 /profile/save 为例，浏览器先提交 POST，服务端校验昵称和邮箱。校验失败时，不直接渲染 HTML，而是保存一组短生命周期数据并返回 303；GET 页面读取它、展示错误，随后立即删除。这样既保留了 PRG 的刷新安全性，又不会让错误状态永久留在 session 中。

用 session flash 穿过一次重定向

先集中处理输入读取和规则判断。示例只演示结构，业务中的邮箱唯一性、权限和数据库约束仍要在服务端再次确认。

 30) {
    $errors['nickname'] = '昵称不能为空，且不能超过 30 个字。';
}
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    $errors['email'] = '请输入可用的邮箱地址。';
}

if ($errors) {
    $_SESSION['form_flash'] = [
        'errors' => $errors,
        'old' => ['nickname' => $nickname, 'email' => $email],
    ];
    header('Location: /profile/edit', true, 303);
    exit;
}

// 通过业务服务保存资料后再重定向到成功页。
header('Location: /profile/edit?saved=1', true, 303);
exit;

这里的关键不是把所有 $_POST 原样塞进 session，而是只保留表单需要回显的字段。密码、验证码和文件内容不应进入 flash。session 也要设置合理的过期策略，避免用户打开多个标签页时看到很久以前的错误。

字段提示如何和输入框建立稳定关联

表单页读取 flash 时要做到“读一次、删一次”。输出值和提示前先转义；错误字段使用固定 ID，例如 error-nickname，输入框只在有错误时添加 aria-describedby。

 [], 'old' => []];
unset($_SESSION['form_flash']);
$errors = $flash['errors'];
$old = $flash['old'];

function e(string $value): string {
    return htmlspecialchars($value, ENT_QUOTES, 'UTF-8');
}

$nicknameErrorId = 'error-nickname';
?>
昵称
>
= e($errors['nickname']) ?>

aria-describedby 不是样式钩子，而是告诉辅助技术“这个输入框的补充说明在哪”。因此错误提示不能只靠红色边框或图标表达，文字节点必须真实存在，而且 ID 不能在每次渲染时随机变化。

错误很多时，焦点和页面提示怎么取舍

多个字段出错时，可以在表单顶部放一段简短的错误摘要，并把焦点移到第一个错误字段；每个字段仍保留自己的详细提示。这样键盘用户不用从页面顶部重新寻找，读屏用户也能听到具体原因。

    请检查标记为错误的字段。
  

如果页面由局部刷新驱动，焦点处理要放在 DOM 更新完成之后；如果是完整重载，服务端可以给第一个错误输入框增加一个明确的焦点标记，再由前端轻量执行。不要让脚本成为唯一的错误提示来源。

性能与边界：flash 只装小数据

一次表单失败通常只有几条短文本，session 存储不会成为瓶颈。真正需要留意的是把大段富文本、上传内容或数据库对象放进 session，导致每次请求都要读写大块数据。错误字典应使用字段名做键，避免把用户输入拼到 HTML 属性名或 CSS 类名里。

• 成功跳转时删除旧 flash，避免用户在另一个标签页重新看到旧错误。
• 校验规则和数据库约束保持一致，避免页面显示“可用”但保存时又失败。
• 对错误摘要使用 role="alert" 要克制；静态页面可以用普通说明，动态更新才需要即时播报。

常见问题

为什么不直接把错误放在 URL 参数里？

URL 会进入历史记录、日志和分享链接，错误文本也可能被截断或编码混乱。短期表单状态更适合放在一次性 session flash 中。

刷新页面后还要保留旧值吗？

错误重定向后的第一次 GET 可以保留旧值；flash 被读取并清除后，普通刷新应回到干净状态。若产品明确需要草稿，应使用独立的草稿机制。

只有 aria-invalid，没有 aria-describedby 可以吗？

不够。前者表示字段无效，后者把字段和具体解释连起来；两者配合，用户才知道哪里错以及如何修改。

把错误回显做成可复用的检查点

这套实现的边界很清楚：POST 负责校验和写入一次性状态，GET 负责读取、转义和展示，HTML 负责稳定的字段关系。联调时用空昵称、非法邮箱、两个字段同时出错、成功后刷新四组用例检查；再用键盘和浏览器辅助功能检查确认焦点与错误文字都能被发现。