PHP会话是通过服务器端专属内存与ID绑定请求，ID通常存于Cookie，数据不发给浏览器；session_start()必须在任何输出前调用，否则报“headers already sent”错误。
PHP会话不是“记住用户”，而是“用服务器端的一块专属内存+一个ID来绑定请求”——ID通常藏在Cookie里，数据永远不发给浏览器。
session_start() 必须在任何输出前调用，否则报 “headers already sent”
这是新手踩得最多、最隐蔽的坑：哪怕开头多了一个空格、BOM字符、或 echo ''，session_start() 就会失败，并抛出警告甚至致命错误。
- 检查文件是否以 UTF-8 无 BOM 格式保存（尤其 Windows 编辑器容易带 BOM）
- 确认
session_start()是脚本中第一个执行的 PHP 语句，前面不能有任何echo、print、HTML 或空白行 - 如果用框架或 Composer 自动加载，注意某些 autoloader 可能提前输出了不可见内容
- 临时调试可用
ob_start()缓冲输出，但只是掩耳盗铃，不能替代修复根源
$_SESSION 不是全局变量，而是会话上下文的映射入口
$_SESSION 看似像普通数组，但它背后绑定的是当前会话 ID 对应的存储空间。没调 session_start()，它就是空的；调了但没传有效 ID，PHP 就新建一个——所以你可能以为“登录态还在”，其实已是全新会话。
- 不要用
unset($_SESSION)清空全部，这会破坏会话注册机制；应改用session_unset()+session_destroy() - 修改完
$_SESSION后若后续还有耗时操作（如 API 调用、文件写入），建议立刻调用session_write_close()释放文件锁，避免并发请求阻塞 - 敏感数据（如权限等级、支付状态）必须存在
$_SESSION中，绝不能靠前端传来的$_GET['role']='admin'做判断
会话超时不是“浏览器关了就失效”，而是由三个时间参数共同控制
用户关掉浏览器，只影响 Cookie 的生命周期（session.cookie_lifetime）；真正决定会话数据何时被服务器清除的，是 session.gc_maxlifetime —— 它默认 1440 秒（24 分钟），且垃圾回收不是实时触发的。
立即学习“PHP免费学习笔记（深入）”；
-
session.gc_maxlifetime = 3600：设为 1 小时，表示会话数据最多存活 1 小时（从最后写入时间算起） -
session.cookie_lifetime = 0：0 表示关闭浏览器即丢弃 Cookie（推荐登录态使用） -
session.cookie_httponly = 1和session.cookie_secure = 1：防止 JS 窃取、强制 HTTPS 传输，上线前必须开 - 别依赖
session_destroy()立即清理——它只删服务器数据，客户端 Cookie 还在；要彻底登出，还得手动setcookie()清掉 Cookie
高并发或集群环境下，files 存储会迅速成为瓶颈
默认 session.save_handler = files 意味着每个会话对应一个磁盘文件，同一会话的多个请求会被文件锁串行化——AJAX 多请求、页面含多个 iframe 时极易卡死。
- 单机高并发：直接切 Redis，两行配置搞定：
ini_set('session.save_handler', 'redis')+ini_set('session.save_path', 'tcp://127.0.0.1:6379') - 跨服务器部署：必须用集中式存储（Redis / Memcached / 数据库），否则用户刷新可能跳到另一台机器，
$_SESSION就变空了 - Redis 不仅快，还天然支持过期（
SET session:abc123 ... EX 3600），和session.gc_maxlifetime无缝对齐
会话真正的复杂点不在语法，而在时间维度（超时策略）、空间维度（存储位置）、安全维度（ID 生成与传输）三者的耦合。改一个参数，可能让登录态变“永不过期”，也可能让 10 个并发请求堵成一列——务必在真实压测环境验证配置组合。
