确认页面是表单提交成功后的状态页，核心在于清晰传达操作结果与后续指引，需用语义化HTML（如<main><dl>）组织信息，提供可操作入口，并通过交互控制与服务端幂等性防止重复提交。
确认页面本质是表单提交后的状态页，不是独立页面类型
所谓“确认页面”，在前端开发中实际就是一次表单提交（POST）成功后服务端返回的响应页，或前端拦截提交后用 JS 渲染的静态状态视图。它没有特殊 HTML 标签或语义元素，核心在于信息组织和用户预期管理——用户需要立刻看清“刚做了什么”“结果是否生效”“下一步该干什么”。
常见错误是把确认页做成纯展示（只写 <h2>提交成功</h2>），导致用户不敢关页、反复刷新、甚至重新提交。真正的确认页必须包含可操作的上下文：原始数据摘要、关键 ID、跳转链接或返回入口。
用语义化 HTML 结构表达确认逻辑，别堆 div
确认页不是视觉设计稿的像素还原，而是信息层级的诚实表达。用对标签比调样式更重要：
-
<main>包裹整个确认区域，明确主内容边界 - 用
<dl><dt><dd>展示键值对（如订单号、支付金额、预计送达时间），比表格更轻量且语义清晰 - 关键动作按钮必须是
<button type="button">或带href的<a>，绝不能是<div onclick>—— 否则屏幕阅读器无法识别、键盘用户无法聚焦 - 若需强调风险操作（如“撤销本次提交”），按钮应加
aria-describedby指向一段说明文字
示例片段：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
<main>
<h1>预约已提交</h1>
<dl>
<dt>预约编号</dt>
<dd><code>ORD-2024-7890</code></dd>
<dt>服务时间</dt>
<dd>2024-06-15 14:00</dd>
</dl>
<p>我们已发送确认短信至您的手机尾号 1234。</p>
<a href="/order/<code>ORD-2024-7890</code>">查看订单详情</a>
</main>
防止重复提交的关键不在 HTML，而在交互控制
很多开发者以为加个 disabled 就万事大吉，但仅靠 HTML 属性远远不够：
- 提交按钮设
disabled后，必须同步禁用整个表单（form.setAttribute('aria-disabled', 'true')），否则辅助技术仍可能触发其他控件 - 服务端必须校验请求幂等性（例如用
Idempotency-Key请求头或订单号去重），因为网络超时可能导致前端没收到响应，用户手动刷新又发一遍 - 确认页本身要避免用户误操作：不要自动跳转（
<meta http-equiv="refresh">已淘汰），不默认聚焦到输入框，不保留原表单 DOM - 如果确认页由前端 JS 渲染（如 SPA 场景），路由切换后务必清空原表单状态，否则后退可能看到脏数据
移动端确认页最常被忽略的三个细节
PC 端能靠鼠标悬停、多窗口并行缓解焦虑，移动端必须一次给全关键信息：
- 订单号、交易号等关键字符串必须可长按复制（加
user-select: text，并确保父容器未设pointer-events: none） - 所有按钮文字必须大于 16px（iOS 最小触控尺寸），且垂直间距 ≥ 8px，避免拇指误点
- 确认页禁止出现「返回上一页」浏览器原生按钮以外的导航入口（比如顶部加个「← 返回」），否则用户会困惑：点哪个？点错会不会丢数据？
真正可靠的确认页，是让用户看一眼就敢关掉页面、去干别的事——而不是盯着屏幕等刷新、反复截图、或者打开新标签查订单状态。
