最稳方案是直接用uni.request调用ThinkPHP接口，需后端显式设置JSON响应头、统一POST传参、Token放header、关闭调试模式并规范错误返回、小程序改用JWT鉴权替代session。
uni-app 里用 uni.request 调用 ThinkPHP 接口最稳
直接用 uni.request，别碰 uni.fetch 或自己封装 axios——它不兼容 uni-app 的条件编译和登录态管理，容易在小程序端静默失败。
ThinkPHP 默认返回 JSON，但要注意它的 Content-Type 可能是 text/html（尤其开启调试或出错时），导致 uni.request 解析失败、res.data 变成字符串而不是对象。
- 务必在 ThinkPHP 后端显式设置响应头：
header('Content-Type: application/json; charset=utf-8'); - 接口统一用
POST传参（避免 GET 在 H5 和小程序 URL 长度限制不一致） - 如果接口带 Token 鉴权，把 token 放在
header里，别塞进 query 或 body —— ThinkPHP 的input()默认不从 header 读，得手动用request()->header('token')
跨域问题只在 H5 端出现，小程序和 App 端根本没这回事
uni-app 的 H5 端本质是浏览器环境，调用本地开发中的 ThinkPHP（比如 http://localhost:8080）会触发 CORS；而微信小程序、App 端走的是原生网络栈，不存在跨域限制。
所以你看到「H5 能跑，小程序白屏」，大概率不是接口问题，而是 H5 调试时被跨域拦住，但你没注意到控制台报了 CORS policy 错误。
立即学习“PHP免费学习笔记（深入）”；
- H5 开发阶段：在 ThinkPHP 的中间件或公共入口加 CORS 头，至少允许
localhost:8080和你的实际域名 - 上线后 H5：把接口域名配到
vue.config.js的devServer.proxy，或让 Nginx 反向代理，彻底避开浏览器跨域 - 别在
uni.request里设withCredentials: true——uni-app 不支持，设了也没用
ThinkPHP 返回的错误格式会影响前端判断逻辑
ThinkPHP 默认错误响应可能是 HTML 页面（如调试开启时的异常页），也可能是 JSON 但结构不统一（比如成功是 {code:1,data:{}}，失败却是 {error: 'xxx'}），导致前端 if (res.data.code !== 1) 判断失效。
必须前后端约定一套响应规范，且 ThinkPHP 侧要兜底：
- 关闭调试模式（
app_debug = false），否则任何异常都吐 HTML - 全局异常处理里统一返回 JSON：
return json(['code' => -1, 'msg' => $e->getMessage(), 'data' => []]); - 业务逻辑中统一用
json(['code' => 1, 'msg' => 'ok', 'data' => $data])，别混用success()/error()辅助方法 - uni-app 端收到响应后，先检查
res.statusCode === 200，再检查res.data.code，缺一不可
登录态保持：ThinkPHP 的 session 在小程序里默认不生效
小程序发起请求时不会自动携带 Cookie，而 ThinkPHP 默认靠 PHPSESSID 维持 session。结果就是：H5 登录后能调用接口，小程序每次请求都被当成未登录。
解决方案不是“让小程序发 Cookie”，而是换鉴权方式：
- ThinkPHP 登录成功后，生成一个短期有效的 token（比如 JWT），写入数据库或 Redis，并返回给前端
- uni-app 把 token 存进
uni.setStorageSync('token', ...)，后续每个uni.request都带上：header: { 'Authorization': 'Bearer ' + token } - ThinkPHP 中间件里拦截请求，从 header 读 token 并校验，通过后再取用户信息，注入到
$this->auth或think\Auth - 别依赖
session_start()或cookie——它们在小程序里天然断连
这个环节最容易被忽略：你以为登录态“应该自动延续”，其实从第一笔请求开始，就得自己管 token 的存、传、续、删。
