根本原因是session未显式启动，tp5.1中session::set()/get()不自动调用session_start()，必须在每个控制器方法开头手动执行session_start()或session::start()，否则所有操作静默失败。
TP5.1 开发前后端分离项目时，用 AJAX 调用登录接口后无法维持登录态，后续请求始终提示未登录——根本原因不是 token 错了，而是 Session 在 API 场景下压根没被正确读取或写入。
确认 Session 是否真正启动
打开所有涉及 Session 的控制器方法（如 LoginController@login、IndexController@index），在方法体最开头插入：
session_start();
⚠️ 这一步必须做：TP5.1 的 Session::set() 或 Session::get() 不会自动调用 session_start()，它只操作已启动的 $_SESSION；若没显式启动，所有 set 都静默丢弃，get 永远返回 null。
检查你的 login.php 或入口控制器是否在调用 Session::set('user_id', 123) 前漏掉了 session_start() —— 这是 80% 的 API 登录失效根源。
禁用 Cookie 自动续期陷阱
TP5.1 默认开启 session.auto_start = true，但该配置在 CLI 或纯 API 请求中行为不稳定；更关键的是，它会自动设置 cookie_lifetime，导致每次请求都重置过期时间，掩盖真实失效逻辑。
第一步：修改 config/session.php，将 'auto_start' => false；
第二步：在登录成功后的控制器里手动执行：
Session::start();
Session::set('user_id', $uid);
这能确保 Session 启动时机可控，且避免框架在你不注意时偷偷覆盖 cookie 过期策略。
解决跨域请求丢失 PHPSESSID
方法一：前端 AJAX 显式携带凭证
fetch('/api/login', { credentials: 'include' }) → 后端必须响应 Access-Control-Allow-Credentials: true，且 Access-Control-Allow-Origin 不能为 *，需指定具体域名（如 https://admin.example.com）。
方法二：后端强制写入 Cookie（绕过浏览器自动管理）
在登录成功后追加：
cookie('PHPSESSID', session_id(), ['expire' => 3600, 'path' => '/', 'domain' => '.example.com', 'httponly' => true]);
【domain 必须带点前缀，如 .example.com，否则子域间无法共享】 若你前端部署在 admin.example.com，后端 API 在 api.example.com，不加点会导致 Cookie 写入失败。
验证 Session 存储路径可写
执行以下命令检查：
php -r "echo session_save_path();"
输出路径如 /var/lib/php/sessions，然后运行：
ls -ld /var/lib/php/sessions
若权限不是 drwx-wx-wt 或属主非当前 Web 用户（如 www-data、nginx），Session 文件将无法创建，所有 write() 静默失败。
修复命令（以 Ubuntu + Nginx 为例）：
sudo chown www-data:www-data /var/lib/php/sessions
sudo chmod 1733 /var/lib/php/sessions
替换 Session ID 避免复用冲突
API 场景下常出现「登录成功但下一请求就失效」，本质是前端复用了旧的 PHPSESSID Cookie，而服务端因 gc 或并发写入导致 session 文件被清空或覆盖。
在登录成功后立即执行：
session_regenerate_id(true);
Session::set('user_id', $uid);
这一步强制生成新 ID 并删除旧 session 文件，彻底切断复用链路。不加 true 参数只换 ID 不删旧文件，仍可能被恶意复用。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
