注销账号需满足二次确认、防误触、服务端校验三要素：前端用自定义模态框禁用按钮并明确提示不可逆后果，服务端须清除session、refresh_token及第三方绑定凭证，成功页禁用后退并清理本地数据。
注销账号不是加个按钮就能完事的——它必须带二次确认、防误触、服务端校验，否则用户点一下就删号，客服电话立刻被打爆。
为什么不能只用 <form> 提交就完事
前端直接提交 POST /api/logout 或 DELETE /api/account 是危险的。真实注销要满足三个条件：用户当前已登录、明确知晓后果、操作不可逆。浏览器刷新或误点后退都会导致重复提交，所以不能依赖纯 HTML 表单默认行为。
- 没有 CSRF 保护的注销接口，可能被诱导点击恶意链接静默触发
- 没做前端确认弹窗，移动端容易拇指误触
- 服务端没校验
session有效性或没清空refresh_token，注销后仍能续期登录
confirm() 太简陋，改用自定义模态框 + 按钮禁用
原生 confirm() 样式无法定制、无法添加说明文字、在 iOS Safari 上会阻塞页面渲染。实际项目中应手写一个轻量模态框，重点控制交互节奏。
关键点：
立即学习“前端免费学习笔记（深入）”；
- 点击“注销账号”按钮后，立即
button.disabled = true，防止连点 - 模态框里必须包含两行以上说明：
“此操作将永久删除您的所有数据，包括笔记、设置和绑定设备”+“注销后无法恢复，请谨慎操作” - 确认按钮文字不能是“确定”，而是
“我已知晓，继续注销”，且需再次点击才发请求 - 取消按钮必须调用
modal.close()并重置按钮状态
服务端注销必须清掉三类凭证
只清 session 不够。现代 Web 应用通常有三套身份凭据并存，漏掉任意一种都可能导致“以为登出了，其实还能进”。
- HTTP-only
session_idcookie：服务端调用req.session.destroy()（Express）或等效方法 - JWT
refresh_token（若存在）：必须从数据库或 Redis 中显式标记为revoked，不能只删前端localStorage - 第三方登录绑定（如微信、GitHub）：调用对应平台的
unlink接口，否则下次授权仍自动登录
前端示例（fetch 注销）：
async function handleLogout() {
const btn = document.getElementById('logout-btn');
btn.disabled = true;
try {
const res = await fetch('/api/v1/auth/logout', {
method: 'POST',
headers: { 'X-CSRF-Token': getCsrfToken() },
credentials: 'include'
});
if (res.ok) window.location.href = '/login?logged-out=1';
} catch (e) {
alert('注销失败，请重试');
} finally {
btn.disabled = false;
}
}
注销成功页别留返回入口
很多团队在 /account/deleted 页面放个“返回首页”链接，这是隐患。用户点进去后按浏览器后退键，可能又回到注销确认页，再点一次就重复触发。
- 注销成功页应使用
history.replaceState()替换当前 history 记录，避免后退到注销流程中任何一步 - 不提供任何跳转按钮，只显示简洁信息：
“您的账号已注销。所有数据将在 24 小时内彻底清除。” - 如果业务允许，可在此页自动清除本地敏感数据：
localStorage.removeItem('user_profile')、indexedDB.deleteDatabase('app_cache')
真正难的不是写代码，是让每个环节都拒绝“差不多就行”——比如忘记校验 CSRF，比如没删 refresh_token，比如模态框没禁用按钮。这些点单独看都很小，合起来就是投诉率飙升的源头。
