JavaScript本地存储的方式总结大全

JS 本地存储的常见方式

1. ​​Cookie

​​Cookie 是存储在用户浏览器端的一小段文本数据，用于在客户端和服务端之间保持状态（比如用户身份、登录状态、偏好设置等）。​​某些网站为了辨别用户身份而储存在用户本地终端上的数据。是为了解决 HTTP无状态导致的问题。

• ​​Cookie 本身不认证用户，它通常只是个“载体”​​

  • 可以存 ​​Session ID​​（传统方式，服务端查 Session）

  • 也可以存 ​​JWT Token​​（现代方式，服务端或前端解析 Token）

• ​​浏览器每次访问网站时，会自动把 Cookie 发给服务端，服务端根据里面的 ID 或 Token 来识别用户​​

✅ ​​Cookie 是桥梁，真正区分用户的是 Session 或 JWT​​

• 由 ​​服务端通过 HTTP 响应头 Set-Cookie设置​​

• 浏览器后续请求会自动通过 ​​HTTP 请求头 Cookie把匹配的 Cookie 发回给服务端​​

• 常用于 ​​会话管理（Session）、身份认证（如登录态）、个性化设置、跟踪等​​

存的一般是：

• 一个 sessionId的唯一标识符或者 JWT

• 一般不会直接把用户信息（如密码、用户对象）存在 Cookie 中 ❌（不安全）

• ✅ 特点：

• 存储在浏览器中，​​每次 HTTP 请求都会自动携带​​（在请求头 Cookie字段中）。如果不使用 HTTPS并对其加密，其保存的信息很容易被窃取，导致安全风险。

• 举个例子，在一些使用 cookie保持登录态的网站上，如果 cookie被窃取，他人很容易利用你的 cookie来假扮成你登录网站，标记为 Secure的 Cookie就是通过被HTTPS协议加密过的请求发送给服务端

• ​​容量较小​​：每个 Cookie 通常不超过 ​​4KB​​，一个域名下一般限制在 ​​20~50 个 Cookie​​。

• 不适合存储大数据并且每次 HTTP 请求都会携带 Cookie，如果 Cookie 太多或太大，会增加请求头大小，影响性能。

• ​​有过期时间​​：可以设置过期时间（Expires / Max-Age 优先级更高）。

• Expires 用于设置 Cookie 的过期时间

• Max-Age 用于设置在 Cookie 失效之前需要经过的秒数

• ​​可设置作用域​​：通过 Domain和 Path控制哪些路径/域名可以访问。

• ✅ 用途：传统用于身份验证（如 Session ID）、用户跟踪。

• 但​​不适合存储大量数据​​，且有隐私和安全问题（如 CSRF）。

📌 示例：

// 设置 cookie
document.cookie = "username=JohnDoe; expires=Thu, 18 Dec 2024 12:00:00 UTC; path=/";

// 读取 cookie（需自己解析）
console.log(document.cookie); // username=JohnDoe; otherKey=value...

// 删除 cookie（设置过期时间为过去）
document.cookie = "username=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;";

有哪些字段？

前端如何查看 Cookie？

在浏览器中：

• 打开 ​​开发者工具（F12）→ Application → Cookies​​

• 或者直接在 Console 里输入：document.cookie（但只能获取非 HttpOnly 的 Cookie）

🔒 ​​注意：如果 Cookie 设置了 HttpOnly，前端 JS 是无法通过 document.cookie读取的！​​

如何设置 Cookie？

document.cookie手动设置一个简单的 Cookie（但无法设置 HttpOnly / Secure 等服务端专属字段）：

document.cookie = "username=John; expires=Thu, 18 Dec 2025 12:00:00 UTC; path=/";

更复杂的属性（如 HttpOnly、Secure、Domain）​​只能由服务端（后端）通过 HTTP 响应头 Set-Cookie 设置​​

当服务端响应时，通过 HTTP 响应头设置 Cookie，格式如下：

Set-Cookie: Name=Value; Expires=date; Path=/; Domain=.example.com; Secure; HttpOnly; SameSite=Lax

🔧 这是一个完整的 Cookie 设置示例，包含多个 ​​字段（属性）​​，每个字段都是 ​​键值对形式，用分号 ;分隔​​。

删除cookie：设置和目标cookie相同的key，path，domain，只是把expires设置成过去的时间，浏览器自动删除过期的cookie。

Cookie 本身可以包含中文，但需要正确编码，否则会出现乱码或设置失败。使用 encodeURIComponent对中文进行编码，读取时用 decodeURIComponent解码。

• 原因：​ Cookie 的值（Value）本质上是一个字符串，但由于 HTTP 协议和 Cookie 规范要求其内容必须是 合法 ASCII 或经过编码的字符串，如果你直接设置含有中文的 Cookie 值，比如：

  document.cookie = "username=张三"; // 可能出错或乱码

  浏览器或服务器可能无法正确解析，导致存储失败或乱码。

✅ 子域名如何访问主域名的 Cookie？

设置Cookie 的作用域（Domain 和 Path） 他俩控制着哪些域名/路径可以访问该 Cookie。

注意 domain前面要加 点（.），表示该 Cookie 可被主域名及所有子域名共享。

默认情况下：

• 如果你在 www.example.com下设置了一个 Cookie 没有特别指定 domain，那么这个 Cookie 只能被 www.example.com访问，子域名如 blog.example.com 是无法访问的！

你需要在设置 Cookie 时，显式指定 Cookie 的 domain 为主域名（不带 www 或子域名），通常为 .example.com（注意前面的点 . ）

🔧 示例：在主域名下设置一个子域名可访问的 Cookie

// 假设当前是主域名 www.example.com 或 api.example.com
document.cookie = `token=abc123; domain=.example.com; path=/; max-age=3600`;

• domain=.example.com：表示该 Cookie 可以被 example.com及所有它的子域名（如 blog.example.com、shop.example.com）访问。

• path=/：表示整个域名下所有路径都可访问该 Cookie。

• max-age=3600：有效期为 1 小时（单位秒）

• ⚠️ 注意：domain必须是你当前域名所属的父域名，你不能设置一个你控制之外的域名​ 的 cookie（出于安全限制）。

Cookie 和 Token 的区别？

• Cookie：​ 是浏览器提供的一种 “自动夹带的东西”，只要浏览器发现你要访问同域下的网站，就会把这个（Cookie）自动塞进请求头里，适合做传统的登录态保持，但有 CSRF 风险。

• 如果你的 token 或 session id 是通过 Set-Cookie​ 由服务端下发，并且存储在浏览器的 Cookie 中，那么 浏览器会在后续同域请求中自动把 Cookie 附加到请求头（Cookie: xxx）里，无需手动处理。

• ✅ 优点：自动管理，适合保持登录态，尤其对传统服务端应用友好

• ❌ 缺点：受 SameSite 限制，跨域携带麻烦；有 CSRF 攻击风险（可通过SameSite=Lax/Strict + CSRF Token 防范）

• =====================================

• Token：​ 是你自己生成的一张 “身份证/令牌”，你需要 手动把它交给服务器（通常放在请求头里，如 Authorization: Bearer xxx），适合现代 SPA、跨域 API 场景，更灵活但需要自己管理安全性（防 XSS）。

• 如果你把 token（比如 JWT）存在 localStorage或 sessionStorage，那么每次发起 HTTP 请求时（比如调用 API），你需要手动从 storage 中取出 token，然后加到请求头里，

• Token（尤其是 JWT）可以携带丰富的信息，比如用户 ID、角色、权限、过期时间等，不需要每次都查询数据库，适合分布式系统、微服务、跨平台身份验证。

• 服务端只需校验 JWT 的签名与有效期，即可识别用户身份与权限，非常适合 现代前后端分离架构、移动端 App、第三方登录、SSO 等复杂场景。

• ✅ 优点：存储灵活，可存复杂信息，适合跨域、多系统共享 token

• ❌ 缺点：需要手动管理，容易因忘记添加而导致鉴权失败；存在 XSS 攻击风险（恶意脚本可读取 localStorage）

• 很多大型系统会采用如下混合模式：

• 用 Cookie 存一个 CSRF Token（只读，不用于身份认证）

• 用 Token（JWT）做身份认证，存在 localStorage 或内存，手动加到请求头

• 或者用 HttpOnly + Secure 的 Cookie 存 JWT（更安全，防止 XSS 读取），但此时仍需服务端配合设置 Cookie，前端无法直接读取

✅ 最佳实践建议（结合你的业务场景选择）

2. ​​LocalStorage（本地存储）​​

✅ 特点：

       生命周期：​​持久化存储​​，数据​​不会随着浏览器关闭而消失​​，除非手动删除。

• 当本页操作（新增、修改、删除）了localStorage的时候，本页面不会触发storage事件,但是别的页面会触发storage事件。

• ​​存储容量较大​​：一般为 ​​5MB~10MB​​（不同浏览器可能略有差异）。

• ​​仅支持字符串类型​​，存储对象需用 JSON.stringify()和 JSON.parse()转换。

• ​​同源策略​​：只能在​​相同协议、域名、端口​​下访问。

• ​​不自动发送到服务器​​，仅在客户端使用。

• ​​任何 JS 代码（包括恶意脚本、XSS 攻击）都能读取它们​​，没有 HttpOnly 保护。

• 如果网站存在 XSS 漏洞，攻击者可以轻松通过 localStorage.getItem()获取你的数据。​​所以不适合存储​​：用户的密码、Token（尤其长期有效的）、身份信息等敏感数据。

• 缺点：

• 无法像Cookie一样设置过期时间
• 只能存入字符串，无法直接存对象

✅ 用途：

• 保存用户主题设置、语言偏好、表单草稿、缓存数据等。

• ​​适合存储​​：用户主题、语言偏好、表单草稿、缓存的数据（如 JSON 配置）。

• 适合存储​​非敏感、长期保存​​的数据。

📌 示例：

// 存数据
localStorage.setItem('username', 'Alice');

// 取数据
const user = localStorage.getItem('username'); // 'Alice'

// 删除某个 key
localStorage.removeItem('username');

// 清空所有 localStorage
localStorage.clear();

 LocalStorage 本身​​没有过期机制​​，但你可以手动实现，例如：

// 存储时带上时间戳
const data = { value: 'hello', expires: Date.now() + 1000 * 60 * 60 }; // 1小时后过期
localStorage.setItem('myData', JSON.stringify(data));

// 取的时候判断是否过期
const stored = JSON.parse(localStorage.getItem('myData'));
if (stored && stored.expires > Date.now()) {
  console.log(stored.value); // 未过期
} else {
  localStorage.removeItem('myData'); // 已过期，删除
}

3. ​​SessionStorage（会话存储）​​

✅ 特点：

• sessionStorage和 localStorage使用方法基本一致，唯一不同的是生命周期，一旦页面（会话）关闭，sessionStorage 将会删除数据

• ​容量与 LocalStorage 类似（约 5MB）​​。

• ​​同样仅支持字符串，同源策略限制​​。

• 不同标签页之间​​不能共享​​（即使域名一样）。

• ✅ 用途：

• 适合存储​​当前会话的临时数据​​，比如表单填写中途的数据、当前页面状态等。

📌 示例：

// 存数据
sessionStorage.setItem('tempData', '12345');

// 取数据
const data = sessionStorage.getItem('tempData');

// 删除 / 清空 同 localStorage
sessionStorage.removeItem('tempData');
sessionStorage.clear();

4. ​​IndexedDB（索引数据库）​​

✅ 特点：

• 是浏览器提供的​​低级、异步、事务型数据库​​，基于 ​​NoSQL（键值对或对象存储）​​。

• ​​存储容量大（一般几十MB甚至更多）​​，适合存储大量结构化数据。

• ​​支持索引、事务、查询等高级功能​​，类似小型数据库。

• ​​异步 API（使用 Promise 或回调）​​，不会阻塞主线程。

• ​​同源策略限制​​。

✅ 用途：

• 适合存储​​大量结构化数据​​，如离线应用数据、用户生成的文件、复杂缓存等。

• 比 LocalStorage 更强大，但​​使用较复杂​​。

📌 示例（简化，实际通常封装或使用库如 idb、Dexie.js）：

// 打开或创建数据库
const request = indexedDB.open('myDatabase', 1);

request.onupgradeneeded = (event) => {
  const db = event.target.result;
  if (!db.objectStoreNames.contains('users')) {
    db.createObjectStore('users', { keyPath: 'id' });
  }
};

request.onsuccess = (event) => {
  const db = event.target.result;
  const tx = db.transaction('users', 'readwrite');
  const store = tx.objectStore('users');
  store.add({ id: 1, name: 'Alice' });
};

5. ​​Service Worker

✅ 特点：

• 主要用于​​离线缓存​​，和 ​​Service Worker​​ 配合使用。

• 可以缓存​​请求和响应​​，实现离线访问（PWA 的关键技术之一）。

• 存储的是网络请求资源，如 HTML、JS、CSS、图片等。

• 一般不直接用来存普通业务数据。

✅ 用途：

• 实现​​离线网页、渐进式 Web 应用（PWA）​​

• 缓存 API 请求、静态资源，提升二次访问速度

区别表格

如何选择IndexedDB/ LocalStorage

🔧 ​​什么时候用 IndexedDB？​​

• 当你需要存储​​大量结构化数据​​（如离线博客文章、用户笔记、文件缓存等）。

• 需要​​查询、排序、分页等能力​​，类似小型数据库。

JWT 和 Session 的区别

JWT 和 Session 是两种不同的用户身份认证机制：

• 1.Session 是需要用服务端存储用户登录状态的方案，需要依赖 Cookie 或 Session ID来实现，服务端需要保存会话信息；

用户登录成功后，服务端会创建一个 Session（会话）对象，保存用户身份信息（如用户 ID、权限等），并生成一个唯一的 Session ID，通常通过 Cookie​ 返回给浏览器。之后，浏览器每次请求都会带上这个 Session ID（通常通过 Cookie: sessionId=xxx），服务端通过这个 ID 找到对应的 Session 数据，确认用户身份。

      2.JWT

它是一个 自包含的 Token，包含了用户信息（payload），并由服务端进行签名，客户端收到后保存（一般在 localStorage 或 Cookie），并在每次请求时 自行携带这个 Token，服务端通过验证签名来确认其有效性，无需存储用户会话信息。

✅ 简单来说：Session 是服务端记住你，JWT 是你自己带着证明（Token）去证明你是谁。

✅ 2. JWT 的组成（三部分，用点号 .分隔）

一个 JWT Token 通常长这样：

xxxxx.yyyyy.zzzzz

它由三部分组成：

1. Header（头部）：表明 Token 类型（JWT）和使用的加密算法（如 HS256、RS256）

2. Payload（负载）：包含用户信息（如用户 ID、角色、过期时间等）—— 这是你存的信息

3. Signature（签名）：服务端用密钥对前两部分进行签名，防止被篡改

👉 服务端不保存这个 Token，只负责生成和验证签名！

✅ 3. JWT 的工作流程

1. 用户登录

   • 客户端提交用户名密码

   • 服务端验证成功，生成一个 JWT Token（包含用户 ID、过期时间等信息，用密钥签名）

   • 服务端 返回 Token 给客户端（通常放在响应体里，如 { token: "xxx.yyy.zzz" }）

2. 客户端保存 Token

   • 一般保存在 localStorage、sessionStorage 或 Cookie（HttpOnly 更安全）

3. 客户端后续请求

   • 客户端在请求头（如 Authorization: Bearer <token>）中带上 JWT Token

   • 服务端收到后，验证签名和有效期，确认用户身份，无需查询数据库或 Session

4. 登出 / 失效

   • JWT 本身是无状态的，服务端通常 不主动使其失效

   • 想让 Token 失效，一般通过：

     • 设置短过期时间 + Refresh Token

     • 黑名单机制（额外维护已失效的 Token）

选择JWT 还是 Session？

✅ JWT 的最佳实践（安全增强）

由于 JWT 默认是无状态的，为了提升安全性，通常会：

2. 浏览器保存 Cookie，自动发送

3. 服务端识别用户身份

4. 用户退出 / Session 过期

✅ 2. 服务端 Session 存在哪？

常见存储方式：

1. 设置短过期时间（如 15~30 分钟）

2. 使用 Refresh Token 机制刷新 Access Token

3. 将 JWT 存在 HttpOnly 的 Cookie 中（防 XSS）

4. 使用 HTTPS，防止 Token 被窃听

5. 可配合黑名单机制，使特定 Token 失效

使用session的完整流程

1. 用户登录

1. 用户在浏览器访问登录页面，输入用户名和密码，点击登录。

2. 前端通过表单或 AJAX 把用户名密码发送到服务端（如 POST /login）。

3. ​​服务端验证用户名密码正确后：​​

   • 在服务端的内存 / Redis / 数据库中创建一个 ​​Session​​，比如：

     {
       "sessionId": "abc123",
       "userId": 1001,
       "username": "Alice",
       "isLoggedIn": true,
       "expiresAt": "2024-06-30T10:00:00Z"
     }

   • 然后服务端生成一个唯一的 ​​Session ID（比如 abc123）​​，并通过 HTTP 响应头 ​​Set-Cookie: sessionId=abc123; Path=/; HttpOnly​​ 把这个 ID ​​下发给浏览器，存入 Cookie。​​

4. 浏览器收到响应后，会把 sessionId=abc123这个 Cookie ​​保存在本地（浏览器）​​。

5. 之后，​​只要访问同一个域名（比如 example.com）下的任何页面或接口，浏览器都会自动在 HTTP 请求头中带上这个 Cookie：​​

   Cookie: sessionId=abc123

   （这是浏览器自动做的，前端 JS 通常不需要关心）

6. 当用户访问首页、个人资料等需要登录的页面时，请求会带上这个 Cookie。

7. 服务端收到请求后，会从 HTTP 请求头中的 Cookie: sessionId=abc123提取出 sessionId。

8. 然后去服务端存储（比如 Redis / 内存 / 数据库）中查找 sessionId=abc123对应的 ​​Session 数据​​。

9. 如果找到，并且未过期，服务端就知道：“哦，这个用户是 Alice，已经登录了”，于是返回对应的用户页面或数据。

10. 用户退出登录时，服务端可以：

    • 删除服务端存储的 sessionId=abc123对应的 session 数据

    • 或者让这个 session 过期

11. 同时，也可以选择让浏览器删除对应的 Cookie（比如设置过期时间为过去的时间）

12. 之后用户再访问页面，由于服务端找不到对应的 Session，就会认为用户未登录，跳转到登录页

总结 

到此这篇关于JavaScript本地存储方式总结大全的文章就介绍到这了,更多相关JS本地存储方式内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论