H5端需显式设置withCredentials: true才能携带Cookie，且后端必须配置Access-Control-Allow-Credentials: true和具体Origin；推荐统一使用token存本地并添加Authorization请求头。
uni-app的 H5 端无法通过或自动携带 Cookie，因为底层用的是（基于 XMLHttpRequest），默认不启用凭证（credentials）——这是绝大多数登录态失效的根本原因。
uni.request 必须显式开启
这是最关键的一步。H5 端的跨域请求（比如调登录接口）若不带这个选项，浏览器根本不会发送 Cookie，服务端也收不到 session ID 或 token
cookie
。
所有需要鉴权的请求（包括登录、获取用户信息、退出等）都得加
只对 H5 有效；App 和小程序不走 Cookie，所以该字段在非 H5 平台会被忽略或报错，建议条件判断：
后端必须响应
，且
不能是
，得写具体域名（如
）
H5 登录后 Cookie 是自动存储的，但别依赖
读取
浏览器会在收到
响应头后自动存 Cookie，后续同域请求也会自动带上——但前提是上面的
已启用。你不需要手动解析或设置
。
一个php类用于处理cookie会话
一个php类用于处理cookie会话
下载
在 H5 中可读，但内容受限（HttpOnly Cookie 无法读取），且格式难解析，不建议用来取 token 或 session ID
如果后端把 token 放在响应 body 里（比如
），那应该优先从 response.data 提取，而不是去碰
若需主动清除登录态，调后端 logout 接口即可；浏览器层面清 Cookie 不可靠（尤其 HttpOnly），也不必要
App 和小程序不能用 Cookie，统一用 token + 请求头更稳妥
uni-app 的多端一致性陷阱就在这里：H5 依赖 Cookie，App 和小程序却完全不用。硬靠 Cookie 管理登录态，会导致其他端反复掉登录。
推荐方案：登录成功后，把 token 存到
，所有请求统一加
请求头
H5 端可以「同时」发 Cookie 和 token（后端兼容两种方式），但业务逻辑应以 token 为准，避免双路径维护
不要在 H5 里写
—— 这会让状态管理碎片化，后期排查登录问题极其痛苦
真正麻烦的不是怎么设 Cookie，而是忘了后端 CORS 配置要配
且
不能写
；这个错误不会报 JS 错，只会静默丢 Cookie，连 Network 面板都看不出异常。
document.cookiesetCookieuni.requestwithCredentials: truewithCredentials: trueuni.getSystemInfoSync().platform === 'h5'Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin*https://your-site.comuni.request({
url: '/api/login',
method: 'POST',
data: { username, password },
withCredentials: uni.getSystemInfoSync().platform === 'h5',
success: res => { /* 处理登录成功 */ }
})document.cookieSet-CookiewithCredentials: truedocument.cookiedocument.cookie{ token: "xxx" }document.cookieuni.setStorageSync('token', xxx)Authorization: Bearer xxxif (platform === 'h5') { use cookie } else { use token }Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin*