确认 php session 是否真正启动：调用 session_start() 后立即检查 session_status() === php_session_active 是否为 true；确保无任何输出（含空格、bom）在 session_start() 前发生；检查浏览器 cookies 中是否存在 phpsessid；验证 session.save_path 可写及 cookie 参数（如 domain、secure）配置正确。
怎么确认 PHP session 是否真的启动了
很多调试问题的起点其实是 session 根本没启动成功。PHP 不会自动报错，session_start() 失败时可能静默失败，导致后续 $_SESSION 写入无效、读取为空。
- 在调用
session_start()后立刻加一句：var_dump(session_status() === PHP_SESSION_ACTIVE);
返回true才算真正激活 - 检查是否在输出（包括空格、BOM、echo）之前调用了
session_start()—— 任何输出都会触发“headers already sent”警告，且 session cookie 无法写入 - 用浏览器开发者工具 → Application（或 Storage）→ Cookies 查看是否有
PHPSESSID字段；没有说明 session cookie 没发出去，常见于session.cookie_secure=1但当前是 HTTP 环境
为什么 $_SESSION 数据不跨页保存
这不是代码逻辑问题，而是 session 生命周期或存储机制被意外干扰了。
-
session.save_path目录不可写（比如权限为755但 Web 进程用户无写权），会导致 session 文件生成失败，session_start()虽返回 true，但数据实际未持久化 - 调用了
session_write_close()后又尝试写$_SESSION—— 此后修改不会保存，PHP 不报错但静默丢弃 - 多个子域名共用 session 但未统一设置
session_set_cookie_params(['domain' => '.example.com'])，导致 cookie 被隔离 - CLI 环境下运行脚本（如 cron）默认不加载 web 的 php.ini，
session.save_handler可能是files，但路径不对或根本禁用
如何安全地打印和追踪 session 内容
直接 print_r($_SESSION) 在生产环境有风险：可能泄露敏感字段（如 token、权限标识），也容易因输出破坏 AJAX 响应格式。
- 开发时用
error_log(print_r($_SESSION, true), 3, '/tmp/session-debug.log')记录到文件，避免污染响应流 - 启用
session.cache_limiter = ''（php.ini 或运行时session_cache_limiter('')），否则某些浏览器可能缓存旧 session 状态 - 若用 Redis 存储 session（
session.save_handler = redis），可用redis-cli keys "PHPREDIS_SESSION:*"查看活跃 session key，并用get命令读取原始序列化值（注意 PHP 的serialize格式）
session_destroy() 和 unset($_SESSION) 的区别必须分清
这是最常混淆的操作，直接导致“明明删了 session 却还能登录”。
立即学习“PHP免费学习笔记（深入）”；
-
unset($_SESSION)只清空当前请求的数组引用，不删除服务端 session 文件/记录，也不清除客户端 cookie —— 下次请求仍会恢复旧数据 -
session_destroy()删除服务端存储，但不会重置$_SESSION数组，也不会删除 cookie；必须配合setcookie('PHPSESSID', '', time()-3600, '/')才算真正登出 - 安全登出推荐组合：
$_SESSION = [];<br>if (ini_get("session.use_cookies")) {<br> $params = session_get_cookie_params();<br> setcookie("PHPSESSID", '', time() - 3600,<br $params["path"], $params["domain"],<br $params["secure"], $params["httponly"]<br );<br>}<br>session_destroy();
session 的调试难点不在语法，而在它横跨 HTTP 请求、服务端存储、客户端 Cookie 三层。任何一个环节配置偏移（比如 nginx 的 fastcgi_buffering off 影响 header 发送，或 CDN 缓存了带 Set-Cookie 的响应），都可能让 session 表现异常，且难以复现。
