从现在开始，努力学习吧！本文《如何用 localStorage 实现网页“记住我”功能的本地持久化存储》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

localStorage应只存token及过期时间戳，绝不存明文密码；需配合服务端验证实现安全自动登录，并在登出或token吊销时同步清除。

localStorage 存什么？只存 token，别碰密码

“记住我”不是记住用户名+密码，而是记住一次合法登录后下发的短期/长期凭证。现代实践里，这个凭证通常是后端签发的 token（如 JWT），配合一个过期时间戳。你存 localStorage.setItem('authToken', token) 和 localStorage.setItem('authExpires', Date.now() + 7 * 24 * 60 * 60 * 1000) 就够了。

绝对不要存明文密码——哪怕用户勾了 checkbox，前端也不该拿到、更不该落地。浏览器密码管理器会自己处理密码填充；你硬存，等于把钥匙挂门把手上。

• 存密码明文：XSS 一打就全漏，安全扫描直接标红高危
• 只存 token：即使被窃，token 可被后端主动废止，且通常带 scope 限制
• 必须配过期时间：否则 token 永久有效，违背最小权限原则

页面加载时怎么判断是否自动登录？先验本地，再验服务端

不能只靠 localStorage.getItem('authToken') 就跳转主页。用户可能手动改了 localStorage、或 token 已被后端吊销、或过期时间被篡改。必须走两步：

• 第一步：读取 authToken 和 authExpires，用 Date.now() 做客户端时间比对，过期就清空并退出
• 第二步：用该 token 发起一次轻量验证请求（如 GET /api/me 或 POST /api/verify），仅检查有效性，不拉全量数据
• 服务端响应 { valid: true, user: { id, name } } 才算真正可登录，此时再跳转、再初始化用户态

漏掉第二步，会导致“假自动登录”：界面上显示已登录，但后续所有接口 401，体验极差。

checkbox 状态怎么持久化？用 localStorage 同步，但别当真

用户勾选“记住我”，你得让这个勾选状态在刷新后依然存在，否则体验割裂。但这只是 UI 层面的同步，和是否真的自动登录无关。

• 监听 checkbox 的 change 事件，存 localStorage.setItem('rememberMeChecked', e.target.checked)
• 页面加载时，读 localStorage.getItem('rememberMeChecked') 并设置 checkbox.checked = value === 'true'
• 注意：Safari 隐私模式下 localStorage 写入会静默失败，必须包 try/catch，失败时降级为只记当前 tab（用 sessionStorage）

这个 checkbox 的唯一作用，是告诉后端“用户点了记住我”，所以登录请求体里要带上 remember=true 字段——否则后端根本不知道该发长期 cookie 还是 session cookie。

为什么不能用 document.cookie 存这个状态？它不是为这事设计的

document.cookie 是给 HTTP 请求自动携带用的，每发一次请求都得传一遍，纯属浪费带宽。而且它没加密、易被 JS 读写篡改，连基础防误改能力都没有。

• 存状态用 localStorage：只在前端读写，不参与网络传输，容量大（通常 5–10MB），API 简单
• 存认证凭证用 HttpOnly cookie：由后端 set，前端 JS 读不到，防 XSS 盗 token
• 二者分工明确：localStorage 存“要不要自动登录”的意图和本地缓存凭证，HttpOnly cookie 才是实际生效的登录态载体

混淆这两者，要么导致 token 被 XSS 劫持，要么让浏览器反复发送无用字段。真正的难点不在存，而在“什么时候清”——比如用户主动登出、密码修改、或 token 被后端吊销时，localStorage 里的值必须同步清除，否则下次打开页面还会尝试用废 token 自动登录。

今天关于《如何用 localStorage 实现网页“记住我”功能的本地持久化存储》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！