微信小程序无法使用 cookie/session，需用自定义 token+本地存储+手动透传实现会话管理：登录存 token，请求带 authorization 头，封装请求统一处理，服务端校验 header 中 token，支持 refresh_token 自动续期。
微信小程序本身没有传统 Web 中的 Cookie 和 Session 机制，也不能直接使用 document.cookie 或服务端依赖浏览器自动携带 Cookie 的 Session 方案。要在小程序中“模拟”类似 Session 的会话管理，核心思路是：**用自定义 token（如 JWT 或服务端生成的 session_id） + 小程序本地缓存 + 每次请求手动透传**。
为什么不能直接用 HTTP Session？
微信小程序的网络请求（wx.request）默认不携带 Cookie，即使服务端设置了 Set-Cookie，小程序也不会保存或自动带上。这是平台限制，不是 bug，出于安全和隐私考虑。
推荐的模拟方案：Token + 本地存储 + 请求拦截
本质是把 Session ID（或 Token）当作一个普通字符串来管理，由前端主动存、取、传：
-
登录后获取 token：用户登录成功，服务端返回一个短期有效的 token（如 JWT 或随机字符串），小程序用
wx.setStorageSync('token', 'xxx')存到本地。 -
请求时手动带 token：所有需要鉴权的接口，在
header中添加字段，例如：{ 'Authorization': 'Bearer xxx' }或{ 'X-Session-ID': 'xxx' }。 -
封装请求函数统一处理：避免每个
wx.request都重复写 header，建议封装一个api.request方法，自动读取 token 并注入 header。 -
token 过期/失效时主动清理：服务端返回 401 或自定义错误码（如
{ code: 4001, msg: '登录已过期' }），小程序捕获后清空本地 token，并跳转登录页。
服务端配合要点
服务端不能依赖 Cookie 解析 Session，而要从请求 header（如 Authorization）中提取 token，再验证其有效性（查 Redis / JWT 签名校验 / 数据库 session 表等）：
- 登录接口返回
{ token: 'eyJhbG...', expires_in: 7200 }； - 其他接口统一校验该 token，不依赖
req.session（Express/Koa 默认的基于 Cookie 的 session 中间件需禁用或绕过）； - 可选：为小程序分配独立的 token 类型或 app_id 标识，便于权限隔离。
进阶：支持自动刷新 token（可选）
若 token 有效期短（如 2 小时），可设计 refresh_token 机制：
- 登录时额外返回
refresh_token（长期有效、仅用于换新 token）； - 当主 token 即将过期或请求返回 401 时，用
refresh_token向服务端申请新 token； - 更新本地
token缓存，重试原请求（需队列或 Promise 暂停机制，避免并发刷新）。
这套模式不是“模拟 Session”，而是采用更现代、更可控的无状态鉴权方式，恰好契合小程序的运行环境。不需要 hack，也不依赖 WebView 或 Cookie，稳定且符合微信规范。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
