javascript本身不管理session，session是服务器端机制；微前端中需通过统一认证中心（sso）颁发全局凭证（如jwt），各子应用依赖一级域名共享cookie（domain=.example.com、samesite=none、secure）或iframe+postmessage实现登录态同步，前端仅负责安全传递与状态广播，校验均由后端完成。
JavaScript 本身不管理 Session，Session 是服务器端机制；微前端中多个子应用共享统一服务端会话，关键在于**后端统一认证 + 前端协同传递凭证**，而非前端“共享 Session”本身。核心目标是：所有子应用发出的请求，都能被后端识别为同一用户、同一登录态。
依赖统一认证中心（SSO）作为会话源头
各子应用不能各自生成或校验 Session，必须全部接入同一个认证服务（如 OAuth2 授权服务器、Keycloak 或自建 Auth Center）。用户首次登录后，由该中心颁发全局有效凭证（如 JWT 或加密 ticket），后续所有子应用只负责：
- 将凭证安全存储（推荐
httpOnly Cookie，禁用 localStorage 存 token） - 在每次请求中自动携带（浏览器自动附带 Cookie，或前端手动注入 Authorization Header）
- 向认证中心验证凭证有效性（非本地 Session 校验）
解决跨子应用域名下的 Cookie 共享问题
若子应用部署在不同二级域（如 shop.example.com、user.example.com、admin.example.com），需通过一级域共享 Cookie：
- 认证中心与所有子应用后端均部署在
.example.com下 - 登录成功后，后端 Set-Cookie 时指定
Domain=.example.com、SameSite=None、Secure=true - 前端无需额外操作，浏览器自动在同父域下所有请求中携带该 Cookie
若无法统一域名（如混合部署公网/内网或第三方系统），可改用 iframe + postMessage 方案：各子应用嵌入指向 auth.example.com/status 的隐藏 iframe，由认证中心响应当前用户 ID 或短期 token，再由前端分发给对应子应用。
微前端内部状态同步需与服务端会话解耦
Cookie 已保证服务端能识别用户，但子应用前端仍需感知登录态变化（如头像、菜单、权限按钮）。此时应：
- 避免各子应用自行读取 Cookie 或解析 token —— 易出错且不安全
- 由基座（主应用）统一监听登录/登出事件，通过
initGlobalState（qiankun）或自定义事件（CustomEvent）广播用户信息 - 子应用订阅该状态，仅用于 UI 渲染和本地逻辑判断，不参与身份校验
- 敏感操作（如提交订单）仍须后端二次鉴权，不可仅依赖前端状态
注意 Cookie 属性配置的常见陷阱
即使设置了 Domain=.example.com，以下配置错误仍会导致共享失败：
-
SameSite=Lax或Strict：跨子应用跳转时可能被拦截，必须设为SameSite=None - 未启用
Secure=true：在 HTTPS 环境下，SameSite=None强制要求Secure - 路径（
Path）设为/app1等子路径：导致其他子应用无法读取，应设为/ - 前端 JS 尝试用
document.cookie读取httpOnlyCookie：浏览器禁止，只能由后端注入或通过接口返回
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
