表单必须包含 required 和 aria-label 属性以确保浏览器校验触发及屏幕阅读器识别；fetch 提交需显式处理 422 和超时；成功后应内嵌确认文案而非跳转或 alert；移动端须调用 blur() 收起键盘。
表单结构必须包含 required 和 aria-label 属性
用户提交失败常不是因为逻辑错，而是浏览器原生校验没触发或屏幕阅读器无法识别控件。没有 required 的 <input> 或 <textarea></textarea>，在移动端可能直接跳过必填提示；缺少 aria-label 或关联 <label for="xxx"></label>，会导致视障用户无法理解“意见内容”字段用途。
实操建议：
-
<textarea name="feedback" required aria-label="请填写您的意见或建议"></textarea>比单纯写placeholder="请输入意见..."更可靠——placeholder不是标签，且在输入后消失 - 避免只用视觉样式（如红色星号
*）表示必填，必须配合required属性和语义化标签 - 如果用
<fieldset></fieldset>分组（例如“问题类型”单选），记得给<legend></legend>，它天然承担组描述作用
fetch() 提交时务必处理 422 Unprocessable Entity 和网络超时
后端返回 422 通常意味着字段格式不合法（如邮箱格式错、字数超限），但前端若只监听 ok === true 或 status >= 200 && status ，就会把 <code>422 当成功处理，导致用户以为提交成功，实际被服务端拒绝。
实操建议：
- 显式检查
response.status：对422解析响应体中的errors字段，并用setCustomValidity()绑定到对应表单控件，触发原生报错气泡 - 添加
signal: AbortSignal.timeout(8000)防止请求挂起，超时后显示“网络不稳定，请重试”，而非静默失败 - 禁用提交按钮后，要在
finally块中恢复，否则错误后按钮永远不可点
提交成功后不要用 alert() 或跳转到新页面
弹 alert() 会打断用户上下文，尤其在 iOS Safari 中可能被拦截；跳转到“感谢页”则丢失来源路径，用户无法回退继续浏览原内容，也增加服务端路由负担。
实操建议：
- 用
innerHTML替换表单区域为一段简短确认文案，例如：<p>✅ 意见已收到，我们会在 3 个工作日内回复</p> - 保留原页面 URL 和滚动位置，必要时可加
scrollIntoView({ behavior: 'smooth' })聚焦到反馈结果区 - 如果页面含其他交互模块（如评论区、文档目录），确保 DOM 替换不影响它们的事件监听器
移动端键盘收起与焦点管理容易被忽略
在 iOS 上，<textarea></textarea> 输入完成后点击“提交”，键盘常不自动收起，用户看不到提交结果；安卓部分机型则会在提交后焦点仍停留在输入框，导致软键盘遮挡成功提示。
实操建议：
- 提交前执行
document.activeElement?.blur()，强制移除焦点 - 避免在
submit事件里调用focus()，除非明确需要（如重新聚焦错误字段） - 不在
textarea上设autofocus—— 页面加载即唤起键盘，对非首屏反馈入口很突兀
422 响应解析和移动端 blur() 调用，这两处一出问题，用户感知就是“点了没反应”或“明明填了还说没填”，排查时却要来回比对前后端字段定义和 focus 状态。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
