uni.request 默认不带 Cookie 是设计使然，H5 需 withCredentials: true 且同域，小程序无 Cookie 概念，APP 端完全无视 Cookie，三端应统一使用 token 认证。
uni.request 默认不带 Cookie，这不是 bug，是设计使然——H5、小程序、App 三端机制完全不同，硬要“统一带 Cookie”只会掉坑里。
uni.request 在 H5 端不自动带 Cookie？检查 withCredentials
H5 环境下，uni.request 不会自动带上浏览器已存的 Cookie，除非你显式开启凭证传递：
-
withCredentials: true必须设置，且只对同域请求生效（跨域时后端还需响应Access-Control-Allow-Credentials: true） - 若后端接口域名和当前页面域名不一致（比如页面在
https://a.com，请求发到https://b.com），即使开了withCredentials，浏览器也会拒绝发送 Cookie - 开发阶段用代理（如
vite.config.js中配置/api代理）可绕过跨域，让请求“看起来同源”，此时withCredentials: true才真正起作用 - 别在
header.Cookie里手动拼字符串——浏览器自动管理更可靠；手动塞反而容易漏 HttpOnly、Domain、Path 等属性
小程序端根本没 Cookie 概念，别试图解析 Set-Cookie
微信/支付宝/钉钉等小程序环境没有 document.cookie，uni.request 的 res.cookies 数组虽能读到服务端返回的 Set-Cookie 字符串，但：
-
res.cookies是只读快照，不是浏览器级 Cookie 存储，不会自动追加到下次请求 - iOS 钉钉小程序甚至不返回
cookies字段，只能靠后端把 token 放在response.data里 - 手动提取
res.header['Set-Cookie']并存进uni.setStorageSync，再每次塞进header.Cookie—— 这种做法在真机上极不稳定，尤其多 Cookie 或含 Secure/HttpOnly 时会丢字段 - 正确姿势：登录成功后，从
res.data.token（或类似字段）取值，存uni.setStorageSync('token', xxx)，后续所有请求加Authorization: Bearer xxx
APP 端（Android/iOS）完全无视 Cookie，必须彻底放弃幻想
原生打包后的 APP 没有 Cookie 上下文，withCredentials 和 document.cookie 全无效：
- 哪怕后端返回了
Set-Cookie: sessionid=abc; Path=/，下次uni.request的请求头里也绝不会有Cookie字段 -
uni.getStorageSync('token')存的值，在 APP 升级重装后会被清空——这是官方明确行为，不是存储异常 - 可靠方案是双写：内存用
uni.setStorageSync快速读取，持久化用uni.getFileSystemManager().writeFile写入固定路径文件（如${uni.env.USER_DATA_PATH}/login_state.json），启动时优先读文件恢复 - 拦截器里统一注入 header 时，务必判断
token是否存在且未过期，避免空值或过期 token 被发出去
为什么全局拦截器 + 手动塞 Cookie 多数时候行不通
很多人在 main.js 里用 uni.addInterceptor('request', {...}) 想一劳永逸塞 Cookie，但实际踩坑密集：
- 拦截器执行时机早于
uni.getStorageSync初始化完成，首次冷启动可能读不到值 - 如果用户手动清除了本地存储，拦截器仍会把空字符串或旧值塞进
header.Cookie，导致 401 - 不同端对
header.Cookie的格式容忍度不同：H5 接受分号分隔的多个键值对；小程序某些版本只认第一个；APP 端则压根不解析 - 最麻烦的是调试成本——你在 H5 看着正常，真机一跑就 403，还得逐端排查，不如从一开始就约定只走 token
真正难的不是“怎么让 uni.request 带 Cookie”，而是接受三端网络模型不可调和的事实。一旦开始混用 Cookie 和 token，H5 登录态和 App 登录态就会分裂，后期维护成本指数级上升。留个心眼：所有需要持久化的凭证，只存 token，只走 header，只校验 expireAt。
