根本原因是输出早于session_start()执行，需检查bom、空白符、引入文件输出及session配置一致性。
PHP session_start() 报 “headers already sent” 怎么快速定位
根本原因不是 session 本身出错，而是输出（包括空格、BOM、echo、print）早于 session_start() 执行。浏览器收到 HTTP 头之前已有内容，PHP 就没法再发 Set-Cookie。
- 用编辑器检查 PHP 文件开头：有没有 UTF-8 BOM（尤其 Windows 下用记事本保存过）；可以用
hexdump -C file.php | head看前几个字节是否为ef bb bf - 确认所有
session_start()都在文件最顶部，前面不能有任何输出——包括<?php之前空白、<?php和session_start()之间换行或空格 - 如果用了
require/include，检查被引入文件是否也“静默”：哪怕一个或注释后的空行都可能触发 - 临时加
if (session_status() === PHP_SESSION_NONE) { session_start(); }可避免重复调用报错，但不解决根本问题
为什么 $_SESSION 在页面间为空？常见漏掉的三件事
Session 数据没丢，只是没连上——PHP 默认用文件存 session，但路径、权限、生命周期全得对得上。
-
session.save_path目录必须存在且 Web 进程（如 www-data、nginx、apache）有写权限；用ls -ld /var/lib/php/sessions看属主和权限，常见错误是目录属 root 且权限为 755 - 确保所有页面用的是同一个
session.name（默认PHPSESSID），如果改过，前后端 cookie 名、session_name()调用、php.ini设置必须一致 - 检查
session.cookie_lifetime和session.gc_maxlifetime：前者为 0 表示浏览器关闭即失效；后者默认 1440 秒（24 分钟），超时后服务端文件被清理，但客户端 cookie 还在，看起来像“登录突然掉线”
调试时怎么立刻看到当前 session 内容和配置？
别翻日志、别猜配置，用两行代码直接 dump 出来，比查 phpinfo() 更聚焦。
- 加这段到页面开头（确保在
session_start()后）：var_dump($_SESSION);<br>print_r(ini_get_all('session')); - 重点关注输出里的
session.save_handler（默认files，若为redis或memcached就得查对应服务）、session.cookie_domain（跨子域要用.example.com，少个点就传不过去） - 如果
$_SESSION是空数组但 session_id() 有值，说明 session 已启动，只是没存数据；如果session_id()为空，说明session_start()根本没执行成功
用 Chrome DevTools 查 session cookie 却看不到 PHPSESSID？
不是没生成，是它被设成了 HttpOnly + Secure，或者 domain/path 匹配失败，浏览器直接不发。
立即学习“PHP免费学习笔记（深入）”；
- 打开 DevTools → Application → Cookies，看协议是否为
https://；如果本地用http://localhost但session.cookie_secure = 1，cookie 就不会出现 - 检查
session.cookie_domain：设成example.com时，www.example.com可以读，但localhost绝对不行；开发时建议留空或显式设为'' - 如果用了
session_set_cookie_params(['httponly' => true, 'samesite' => 'Strict'])，在跨站跳转或表单提交时 cookie 会被浏览器屏蔽，此时需临时改为Lax测试
Session 不是黑盒，它的每个行为都对应明确的配置项和运行时状态。真正卡住的，往往是某处 ini 值和实际请求环境不匹配，或者 cookie 的 domain/path/securesettings 没对齐——而不是 session 机制本身有问题。
