确认页必须带唯一标识，如报名id或加密Token，以确保数据链路完整；禁用提交按钮防重复；服务端渲染保障seo；返回201或303状态码避免刷新重提。
确认页必须带唯一标识，否则无法区分用户
用户提交表单后跳转的确认页，如果所有人的 URL 都是 /confirm.html，后台就完全没法关联到具体是谁报了名、报的哪场活动。这不是“好不好看”的问题，是数据链路直接断掉。
实操建议：
- 后端生成确认页时，把报名 ID 或加密 token 拼进 URL，比如
/confirm.html?id=abc123或/confirm.html#t=eyJhbGciOi... - 前端页面用
location.search或location.hash读取参数，再请求/api/registration?token=...拉取真实数据 - 别用
window.history.replaceState随便改 URL——用户刷新会丢参，且不利于分享和回溯
表单提交后禁用按钮 + 显示加载态，不是可选项
用户点完“提交”立刻又点一次，很可能触发重复报名。浏览器不会自动阻止，HTML 本身也不管这事。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 按钮没置
disabled，用户连点两下，后端收到两条几乎一样的请求 - 只改文字为“提交中”，但没加
disabled，仍可点击 - 用 CSS 隐藏按钮，但没禁用，
Enter键或屏幕阅读器仍能触发
正确做法很简单：
<button type="submit" id="submitBtn">立即报名</button> <script> document.getElementById('submitBtn').addEventListener('click', function(e) { this.disabled = true; this.textContent = '提交中...'; }); </script>确认页内容不能靠 js 渲染，否则 SEO 和分享失效
微信、钉钉、搜索引擎打开链接时，往往不执行 JS，或者等不及就截屏/抓取。如果报名人姓名、活动时间、地点全靠 fetch() 后塞进 document.getElementById('name').innerText，那别人转发出去，看到的就是空白页或“加载中”。
使用场景决定渲染时机：
- 服务端渲染（SSR）：Node.js / PHP / Python 吐出完整 HTML，最稳妥
- 静态生成（如 Jekyll）：适合固定活动，提前生成
confirm-20240615-abc123.html - 客户端渲染（CSR）：必须 fallback——在 HTML 里预留占位文案，比如
<div id="event-time">请稍候，正在加载活动时间…</div>，并确保 JS 加载失败时文案仍可读
http 状态码别返回 200，要返回 201 或 303
确认页本质是“资源创建成功后的响应”，返回 200 OK 会让爬虫、缓存、甚至部分支付网关误判为普通页面。更麻烦的是，用户刷新确认页，浏览器可能重发 POST 请求（即使原始表单已跳转）。
关键参数差异：
-
201 Created：适用于直接返回确认页 HTML（比如后端渲染完立刻吐出），表示“刚创建成功” -
303 See Other：更推荐，POST 提交后 303 跳转到 GET 的确认页（如Location: /confirm.html?id=abc123），彻底避免刷新重复提交 - 千万别用
302 Found：老浏览器可能把后续 GET 当成 POST 重放
性能影响很小，但兼容性差的旧系统（比如某些企业微信内嵌浏览器）对 303 支持更稳。
确认页真正的难点不在样式或动效，而在于怎么让每个环节都“不可逆”——用户不能多点、链接不能乱传、刷新不能出错、爬虫得看得见。这些地方一松劲，后面查数据、对账、补救，全是苦活。