移动端webview中javascript不直接管理session，关键在于原生层同步cookie或透传token：android需注入cookiemanager，ios需通过wkhttpcookiestore写入；推荐token方案，由原生通过jsbridge注入并统一校验。
JavaScript 本身不直接管理 Session，Session 是服务端概念，依赖 Cookie 或自定义凭证（如 token）来维持用户会话。在移动端 H5 与原生 App 嵌套 WebView 的场景下，关键不是“传递 Session”，而是确保会话凭证能被 WebView 正确携带、服务端可识别，且不被跨域或安全策略拦截。
WebView 必须复用原生 App 的网络栈和 Cookie 容器
这是最核心的前提。如果 WebView 使用独立 Cookie 存储（如 Android 的 CookieManager 未同步，iOS 的 WKWebView 默认不共享 NSHTTPCookieStorage），H5 就拿不到登录态。
- Android：App 登录后，需主动将服务端返回的 Cookie（如
JSESSIONID、Set-Cookie头内容）注入到CookieManager，并确保 WebView 加载 H5 前已设置；也可使用 OkHttp + WebViewClient 自定义请求，复用同一 CookieJar。 - iOS：
WKWebView默认不共享NSHTTPCookieStorage，需在登录成功后调用HTTPCookieStorage.shared.setCookie(_:for:)写入 cookie，并通过WKHTTPCookieStore确保 WebView 启动时加载这些 cookie（iOS 11+ 支持）。
H5 页面不能依赖 document.cookie 读写敏感 Session ID
服务端生成的 Session ID（如 JSESSIONID）应由原生层统一管理，H5 不应尝试 JS 读取或伪造。否则易受 XSS 攻击，且违反同源策略限制。
- 避免在 JS 中执行
document.cookie = "JSESSIONID=xxx"—— 大多数 WebView 会静默忽略，或仅对当前域名生效但无法触发服务端校验。 - 若需前端感知登录态，建议由原生通过 JSBridge 注入一个只读状态对象（如
window.__APP_USER__ = { uid: 123, token: "xxx" }），H5 用该 token 调用接口（服务端验证 token，而非依赖 Cookie）。
推荐方案：Token 化 + 统一认证网关
比强依赖 Cookie 更健壮的方式是让 H5 和原生共用一套 token 认证机制：
- 用户在原生侧登录后，服务端颁发短期 JWT 或业务 token，并由原生持久化存储（Keychain / Keystore）。
- WebView 加载 H5 前，原生通过 JSBridge 将 token 透传给 H5（或注入全局变量）；H5 所有 Ajax 请求统一在 header 添加
Authorization: Bearer xxx。 - 服务端统一校验 token，无需解析 Cookie，也规避了跨域、第三方 Cookie 限制（尤其 iOS 隐私策略下 ITP 会清理非用户交互触发的 Cookie）。
注意 WebView 的安全配置与域名白名单
即使凭证就位，错误的 WebView 配置也会导致请求失败或凭证丢失：
- Android：确认
setJavaScriptEnabled(true)已开启，且setAllowContentAccess(true)、setAllowFileAccess(false)（禁用 file:// 协议防泄露）。 - iOS：
WKWebView需设置configuration.websiteDataStore = .nonPersistent()或复用持久化 store；若 H5 加载的是 https 地址，确保服务器证书有效，否则 Cookie 不会被保存。 - 所有平台：H5 接口域名必须与原生登录域名同源或显式配置 CORS，否则 fetch / XMLHttpRequest 无法携带凭证（需设
credentials: 'include'，且服务端响应含Access-Control-Allow-Origin具体域名，不能为*）。
不复杂但容易忽略：Session 的“传递”本质是凭证上下文的一致性，而不是 JavaScript 在两端之间做数据搬运。重点始终在原生层如何把登录态可靠地提供给 WebView，以及服务端如何统一识别它。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
