php会话失效主因是session_start()调用位置错误，须在任何输出前执行且每个文件单独调用；其次检查session.save_path权限、cookie域配置及销毁逻辑是否完整。
PHP 会话没生效？先确认 session_start() 调用位置
绝大多数 $_SESSION 写不进去、读不出来的问题，根源在 session_start() 没被正确调用。它必须出现在任何输出（包括空格、BOM、HTML 标签）之前，且每个需要访问会话的 PHP 文件里都得有——不能只在登录页调一次就完事。
-
session_start()必须是脚本中第一个可能产生输出的操作，放在<?php后立刻执行最安全 - 如果用了 UTF-8 编码，确保文件无 BOM；编辑器保存时选“UTF-8 无 BOM”
- Apache + mod_php 下，
session.auto_start = 1在php.ini里开启虽能自动启动，但不推荐：无法控制启动时机，且 CLI 环境下行为不一致 - 常见错误现象：
Warning: session_start(): Cannot send session cache limiter—— 这说明已有输出，检查是否有 echo、空行、或前端 HTML 提前发送
$_SESSION 数组赋值后不持久？检查 session.save_path 权限和存储方式
写进 $_SESSION['user_id'] = 123 后刷新页面变空，大概率不是代码问题，而是 PHP 根本没把会话数据存下来。关键看 session.save_path 是否可写，以及是否被其他机制干扰（如 opcache、APCu 的 session 处理器配置）。
- 运行
var_dump(ini_get('session.save_path'))查路径，再用is_writable()检查权限 - 共享主机常默认指向
/tmp，但某些环境会清理旧文件，导致会话“莫名消失”；建议显式设置为项目内可写目录，如session_save_path(__DIR__ . '/runtime/sessions') - 使用 Redis 存储会话时，必须安装
redis扩展，并在php.ini中设session.save_handler = redis和session.save_path = "tcp://127.0.0.1:6379"；漏配 handler 就会退回到文件存储，而你可能根本没留意 - CLI 脚本默认不启用会话，即使调了
session_start()，也不会读写 Web 请求中的会话数据
为什么 $_SESSION 数据跨页面丢失？注意 cookie 设置与域匹配
会话 ID 通常靠 Cookie 传递，session.cookie_domain、session.cookie_secure 等配置不匹配当前请求域名或协议，就会导致浏览器不发会话 Cookie，服务端自然找不到对应会话。
- 开发时用
localhost，但设置了session.cookie_domain = '.example.com'→ 浏览器拒绝发送 Cookie - HTTPS 站点却未开启
session.cookie_secure = 1，Chrome 等现代浏览器会忽略非 Secure Cookie，造成会话中断 - 子域名间共享会话需显式设
session.cookie_domain = '.example.com'（注意开头的点），且主域和子域必须同属一个注册域 - 可通过
var_dump($_COOKIE[ini_get('session.name')])直接检查浏览器是否传了会话 ID；没输出就说明 Cookie 没发过来
session_destroy() 之后还能读 $_SESSION 吗？别混淆销毁和清空
session_destroy() 只删服务器端的会话数据文件（或 Redis key），不会 unset 当前脚本里的 $_SESSION 数组。所以调用后仍能 echo 出值，但这只是内存残留，下次请求就没了。真正要清空当前上下文，得配合 $_SESSION = [] 或 unset($_SESSION)。
立即学习“PHP免费学习笔记（深入）”；
- 退出登录常用组合：
$_SESSION = [];+session_unset();+session_destroy();+setcookie(session_name(), '', time() - 3600, '/'); -
session_unset()清空$_SESSION数组内容，但不销毁会话本身；session_destroy()不影响当前数组变量 - 忘记调
setcookie(..., time() - 3600)会导致浏览器还带着旧会话 ID 发起请求，服务端可能重建同名会话（尤其用文件存储时），造成“登出后还能进”的假象
会话看似简单，但每一步都卡在细节上：输出顺序、路径权限、Cookie 域、销毁逻辑……少一个条件，就可能让整个流程静默失败。调试时优先验证 session_id() 是否前后一致，比反复检查赋值语句更有效。
