小程序调用PHP接口时session不生效，因默认不携带Cookie导致无法关联会话；需手动透传session ID（如通过header.X-Session-ID），服务端用session_id()注入后调用session_start()，并自行校验$_SESSION['expire_time']控制有效期。
小程序调用 PHP 接口时 session 不生效？检查 session_start() 调用时机和 Cookie 传递
微信小程序默认不携带 Cookie，PHP 的 session_start() 无法自动关联用户会话，导致每次请求都是新 session。必须显式传递 session ID，并确保服务端正确识别。
常见现象：$_SESSION 为空、登录态丢失、session_id() 每次不同。
- 小程序发起请求时，需在 header 中带上
Cookie: PHPSESSID=xxx（从上一次响应中提取） - PHP 接口开头必须调用
session_start()，且不能有任何输出（包括 BOM、空格、echo） - 若使用 Nginx，确认未配置
fastcgi_ignore_client_abort off类似干扰项 - 推荐改用
session_id($_GET['PHPSESSID'] ?? $_POST['PHPSESSID'] ?? null)+session_start()手动注入（更可控）
如何安全地在小程序与 PHP 间同步会话 ID？用 Set-Cookie + 前端存储不如手动透传
小程序的 wx.request 默认不支持自动管理 Cookie（尤其 iOS 下兼容性差），依赖 Set-Cookie 响应头基本不可靠。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 后端登录成功后，返回
session_id()字符串（如{"sid": "abc123..."}） - 小程序将该 sid 存入
wx.setStorageSync('sid', 'abc123...') - 后续所有请求在
data或header中带上该 sid（推荐放header.X-Session-ID，避免污染业务参数） - PHP 接口统一拦截：读取
$_SERVER['HTTP_X_SESSION_ID']，调用session_id($sid)再session_start()
session_set_cookie_params() 对小程序无效，有效期得靠服务端逻辑控制
调用 session_set_cookie_params(3600) 只影响 Cookie 的 Expires 属性，而小程序根本不存 Cookie，所以这个设置毫无作用。
真正控制会话有效期的方式：
- 在
$_SESSION中记录$_SESSION['expire_time'] = time() + 3600 - 每次请求开头校验：
if (!isset($_SESSION['expire_time']) || $_SESSION['expire_time'] - 每次有效访问后刷新过期时间：
$_SESSION['expire_time'] = time() + 3600 - 避免依赖
session.gc_maxlifetime，它只对文件存储有效，且触发不可控
为什么用 $_SESSION 同步状态容易出问题？优先考虑无状态 JWT 方案
PHP session 本质是服务端有状态存储，在分布式或容器化部署下需额外配置共享存储（Redis），而小程序请求来源不可预测，session 文件锁、并发读写、跨域路径问题频发。
更健壮的做法：
- 登录成功后，PHP 生成 JWT（用
firebase/php-jwt），载荷含用户 ID 和过期时间 - 小程序将 token 存本地，每次请求带在
Authorization: Bearer xxx - 后续接口用
JWT::decode()验签并提取用户信息，完全绕过session_start() - JWT 过期即失效，无需服务端维护 session 生命周期，也规避了 sid 透传的安全顾虑
复杂点在于 token 刷新逻辑和登出时的黑名单管理——这些恰恰是很多人忽略、但线上最容易暴露的环节。
