大家好，我最近刚好在帮朋友整理前端和后端存储的知识点，发现这块不管是写项目还是大厂面试，都是绕不开的高频话题，所以干脆做了一份比较系统的总结，也顺手加点自己的吐槽和使用经验，方便大家查漏补缺。
先说结论：为啥需要存储？
一个网页光会展示还不够用，绝大多数业务都绕不开一个问题：怎么记住用户是谁，做了什么，要给他啥内容。
不管是登录状态、购物车、个性化设置，还是离线缓存，背后都离不开“数据要放哪”这件事。
所以前端有一套存储方案，后端有一套存储方案，缓存又是后端和前端之间的“润滑剂”。你要是都搞明白了，面试提问时脑子才不会当场宕机。
前端存储，远不只是 Cookie
1. Cookie：老兵不死，但还没退役
你要是问一个后端同事“前端怎么存用户信息”，十有八九会先说 Cookie。
特点很简单：
-
体积小，一般就 4KB 上下。
-
自动和请求一起发给后端（所以经常用来带 Token 或 Session ID）。
-
可以设置过期时间、作用域，甚至做跨子域共享。
-
那么什么是Token和Session ID呢？
-
Session ID：浏览器保存一个 ID，核心信息放在服务端，典型用 Cookie 带上，适合传统网站、服务端渲染。
-
Token：信息自包含，前端保存 Token 串，放在请求头里，适合前后端分离、多端复用。
举个最土的例子：
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict
这行意思是：
sessionId是唯一标识。HttpOnly表示前端 JS 拿不到（XSS 不好偷了）。Secure表示只有 HTTPS 才发（中间人拿不到）。SameSite=Strict表示 CSRF 不好搞了。
实战：
- 90% 的登录态都靠它或者它背后的 Session/Token 体系。
- 埋点也喜欢用 Cookie，给你种个 ID 追踪一下。
2. LocalStorage：前端的“小仓库”
有了 LocalStorage，开发者就再也不用用 Cookie 储存什么界面偏好了。
特点：
- 体积比 Cookie 大，一个域名一般有 5~10MB。
- 不会自动随着请求发到后端，纯本地。
- 不设置过期时间，除非你自己删，不然它就死活不走。
典型用法：
- 用户选了暗黑模式，LocalStorage 里存个
theme=dark。 - 表单没填完，下次来还能找回。
- 页面之间共享一些小数据（非敏感）。
3. SessionStorage：关了就没了
SessionStorage 和 LocalStorage 很像，但有个关键差别：
- 它的生命周期只跟当前标签页/窗口绑死了。
- 关了就没了，开新窗口也读不到。
通常适用的场景：
- 做多步表单（用户填到一半刷新一下不至于全丢）。
- 某些临时状态保存。
- 单页应用里，页面跳来跳去时传个小数据。
4. IndexedDB：前端里的“数据库”
当本地要存的东西比 LocalStorage 大得多（几 MB 根本不够），IndexedDB 才是更优选。
核心点：
- 可以存上百 MB，甚至 GB。
- 是真正意义上的 NoSQL 数据库，支持索引、事务、游标。
- 异步操作，不会卡主线程。
典型场景：
- PWA（渐进式 Web 应用），做离线缓存。
- 大文件管理，视频/音频的断点下载。
- 有些搜索引擎直接把搜索索引放 IndexedDB，提高前端检索速度。
缺点： API 有点啰嗦，用起来比 LocalStorage 麻烦，不过好在有封装库可选。
后端存储，重点就是“可持久，可扩展”
前端那点存储说到底还是临时的，真正撑住业务的是后端的数据库。
1. MySQL：永远的老大哥
核心场景：
- 用户注册、登录信息
- 订单、支付流水、发票
- 数据强一致性要求高的场景（要保证 ACID）
要点：
- 结构化，表结构清晰。
- 事务性好，最适合做金融、电商、ERP。
2. NoSQL：MongoDB 这种“不讲武德”
有些业务，关系型数据库的结构太死板了，比如：
- 社交评论
- 动态内容
- 日志、埋点
这时候 MongoDB 就很常见：
- Schema 灵活，要存啥存啥，想加字段随便加。
- 横向扩容方便，扛大并发。
- 天生支持 JSON / BSON，和前端数据结构比较对口。
3. 缓存：Redis 不仅仅是“临时工”
面试常考：
“Redis 你怎么用的？”
简答：
- 放热点数据，减少 DB 压力。
- 做 Session 存储，支撑分布式登录（SSO）。
- 排行榜、计数器、队列都能干。
典型场景：
- 秒杀抢购场景，库存先放 Redis 里，数据库异步减库存。
- 用户登录状态放 Redis，挂掉重启都能快速恢复。
- 高频访问的文章、商品详情页先读 Redis，读不到再查 DB。
Cookie 属性，面试真问到能答得出来
很多人只记住了 name=value，实际上面试官一追问：
- 怎么设置过期时间？
Secure和HttpOnly有啥用？SameSite是啥？
你得像背口诀一样熟：
| 属性 | 用法 |
|---|---|
| Expires | 绝对时间，GMT 格式，过期自动失效 |
| Max-Age | 相对时间，单位秒，比 Expires 优先级高 |
| Domain | 限制可用域，做子域共享 |
| Path | 限制路径前缀 |
| Secure | 只能 HTTPS 传输 |
| HttpOnly | JS 拿不到，防止 XSS |
| SameSite | 防 CSRF（Strict、Lax、None） |
实际项目里要搞得安全点，基本组合就是：
Set-Cookie: token=xxx; Secure; HttpOnly; SameSite=Strict;
面试问到怎么答？
有人一听面试官问「你前端用什么存储」，脑子就一片空白。其实你可以这么答（顺便带场景）：
“前端这块，我一般用 LocalStorage 保存非敏感用户设置，比如主题色、语言切换；
登录 Token 我更倾向放 Cookie，后端下发带 HttpOnly、Secure，防止脚本窃取和中间人攻击；
如果是需要做离线缓存的应用，比如 PWA，我会用 IndexedDB 存批量数据；
后端配套用 MySQL 做核心业务表，Redis 做缓存和分布式 Session，常见的比如做秒杀库存预扣、排行榜这种。”
这段基本够用，听起来像真写过项目。
快速小结
| 存储 | 位置 | 生命周期 | 用法 |
|---|---|---|---|
| Cookie | 前端+自动传服务器 | 可配置过期 | 登录态、埋点 |
| LocalStorage | 前端 | 永久 | 界面偏好、草稿 |
| SessionStorage | 前端 | 当前页 | 多步表单 |
| IndexedDB | 前端 | 永久 | 离线缓存 |
| MySQL | 后端 | 永久 | 核心数据 |
| NoSQL | 后端 | 永久 | 日志、动态 |
| Redis | 后端内存 | 临时 | 缓存热点、分布式锁 |
最后一句
这块内容不难，但细节一堆，面试就是爱考。
能背下来当然好，背不下来，至少在自己项目里真用过，用过了就能举例子，面试官一听就知道你不是纸上谈兵。
别嫌啰嗦，真去面试的时候，一句话多举个场景，就能拉开差距。
这篇如果对你有帮助，欢迎点个或收藏一下，咱们一起不掉链子！
