一旦 JavaScript 真正进入业务页面，它几乎一定会和两件事发生关系：向服务端拿数据，以及把一部分状态保存在浏览器侧。前者解决“页面要展示什么”，后者解决“这些信息能不能跨刷新、跨页面或跨会话保留”。很多初学者会把 fetch、cookie、localStorage、sessionStorage 看成几个零散 API，实际上它们背后对应的是请求链路、认证方式、状态持久化和缓存边界。
这一篇的重点，是建立一个浏览器数据协作心智：请求为什么不能只看“能不能拿到数据”，存储为什么不能只看“能不能存进去”，以及缓存为什么不是“先存起来再说”这么简单。
fetch 解决的是请求流程，不只是发个接口
现代浏览器里，fetch 已经成为非常主流的请求方式。它的价值不是单纯替代旧 API，而是提供了一套更现代、更可组合的网络请求接口。但真正进入项目后，你会很快发现，请求从来不只是“调用一下 fetch”：
- 请求头要不要带鉴权信息；
- 参数怎么编码；
- 响应成功是不是业务成功；
- 网络异常和接口错误怎么区分；
- 超时、取消、重试、并发控制怎么做；
- 加载态、空态、异常态怎么反馈给用户。
这说明，请求层本质上是前后端协作边界的一部分，而不是一个随手可写的工具调用。
cookie 为什么在前端里依然重要？
哪怕很多现代项目都把 token 存在别的位置，cookie 仍然是浏览器世界里非常重要的机制。因为它和 HTTP 请求天然绑定，常被用于会话、身份标识、某些跨请求状态的传递。它的特殊性在于：它不像普通变量那样只活在 JavaScript 逻辑里，而是直接参与浏览器和服务端的通信。
也正因为如此，cookie 的使用必须和安全、同源、鉴权流程一起看。很多前端问题看似是“请求没带身份”，其实可能是 cookie 域、路径、SameSite 或跨域设置出了问题。后面讲安全专题时，这条线会继续展开。
localStorage 和 sessionStorage 的差别，不只是生命周期
最表面的差异当然是持久时间：localStorage 更持久，sessionStorage 通常和当前会话绑定。但真正的选择标准，不应只看“谁存得更久”，而要看业务语义：
- 这份数据是否需要跨标签页、跨刷新保留；
- 它是否敏感，能不能直接暴露在浏览器持久存储中；
- 它是否适合由客户端单方面决定；
- 数据失效策略如何控制。
也就是说，存储不是“能放就放”。像主题偏好、某些轻量缓存、非敏感 UI 状态，适合本地存；但权限判断、核心鉴权、强一致性业务数据，不能因为本地存方便就让浏览器自行决定真相。
缓存心智为什么重要？
很多人一听到缓存，就只想到“为了快，把结果保存起来”。这当然没错，但项目里更关键的是另外几个问题：
- 什么时候命中缓存是合理的；
- 什么时候必须失效；
- 页面刷新、切页、重新登录后是否还该继续使用旧数据；
- 本地缓存和服务端数据不一致时，以谁为准。
如果只讲“提高性能”，却不讲一致性和失效策略，缓存就很容易变成 bug 的来源。真实项目里，缓存策略从来不是独立技术细节，而是业务正确性的一部分。
请求层和存储层为什么要收口？
初学者很容易在任何地方直接写 fetch、任何地方随手 localStorage.setItem()。短期很方便，长期会带来明显问题：鉴权头不统一、错误处理风格不一致、序列化规则杂乱、缓存键命名混乱、调试和迁移困难。
更成熟的项目通常会把请求封装成统一入口，把存储封装成清晰的工具层。这样做不是为了“看起来高级”，而是为了：
- 统一错误和重试策略；
- 统一鉴权和拦截逻辑；
- 统一序列化和字段命名；
- 降低业务层对底层实现的耦合。
常见误区
这一章最常见的误区包括：
- 认为请求成功等于业务成功，忽略状态码和业务码区别；
- 把任何状态都存进
localStorage； - 把 cookie 只当成“存点字符串”，不理解它和请求链路的关系；
- 没有缓存失效策略，导致页面总是拿旧数据；
- 请求和存储到处直接写，后期难以收口。
和后续章节的关系
网络与存储这条线，后面会分别延伸到安全、性能、服务端协作和浏览器专题深拆。尤其是认证、缓存一致性和跨域问题，会不断出现。所以这一章更像是总图，而不是单独的 API 介绍。
写在最后
JavaScript 在浏览器里的价值，很大一部分来自它连接了前端界面、浏览器状态和服务端数据。只要你开始把请求、存储和缓存当成“边界设计”而不是“随手调用”，很多项目问题会提前减少。下一篇我们就继续往这条主线延伸，进入浏览器安全与性能。