17370845950

启动 session 前必须确保无任何输出，session_start() 需置于脚本最顶部；仅调用一次即可；$_SESSION 修改后需脚本结束或 session_write_close() 才持久化；session_destroy() 仅删服务端数据，清空会话需组合操作。

启动 session 前必须确保没有输出

PHP 的 session_start() 会发送 Set-Cookie 头，一旦有任何输出（包括空格、BOM、echo、HTML 标签），就会触发 Cannot send session cache limiter 错误。常见陷阱是：UTF-8 文件带 BOM、配置文件末尾多了一个换行、require 的文件开头有空格。

• 用编辑器检查 PHP 文件是否为

  

  「UTF-8 无 BOM」编码
• 所有 session_start() 必须放在脚本最顶部，前面不能有任何 echo、print、HTML 或空白行
• 如果使用了 require/include，确认被引入文件也满足上述条件

session_start() 调用一次就足够

多次调用 session_start() 不会报错，但属于冗余操作，且在某些 SAPI（如 CLI）或自定义 session handler 下可能引发警告或意外行为。它本质是初始化 session 存储、读取 cookie 中的 PHPSESSID、恢复对应会话数据到 $_SESSION 数组。

• 只需在每个需要会话的脚本开头调用一次 session_start()
• 不要在循环里、条件分支里重复调用；也不要在已调用后又写一遍
• 若需判断 session 是否已启动，可用 session_status() === PHP_SESSION_ACTIVE

$_SESSION 是超全局数组，但不是自动持久化的

$_SESSION 看似像普通数组，但它背后依赖 session 存储机制（默认是文件）。赋值、修改、删除都只是操作内存中的副本，真正写入存储要等脚本结束或显式调用 session_write_close()。

• 给 $_SESSION['user_id'] = 123 赋值后，数据不会立刻落盘，而是等脚本执行完毕时自动保存
• 若脚本中调用了 exit 或发生 fatal error，未保存的数据会丢失
• 长耗时操作（如上传、cURL 请求）前建议调用 session_write_close() 释放 session 文件锁，避免并发请求阻塞

session_destroy() 不等于清空 $_SESSION

session_destroy() 只删除服务器端的 session 数据文件（或对应存储记录），但不会清除当前脚本中 $_SESSION 数组的内容，也不会删除客户端的 cookie。用户刷新页面仍可能因旧 cookie 触发新 session 初始化（取决于配置）。

• 安全退出应组合操作：$_SESSION = []; + session_unset(); + session_destroy(); + 删除 cookie（setcookie('PHPSESSID', '', time()-3600);）
• session_regenerate_id(true) 更适合登录态升级场景，它销毁旧 session 并生成新 ID，防止会话固定攻击
• 注意：session_destroy() 后不能再读写 $_SESSION，否则会触发 warning

会话逻辑看似简单，但 session ID 生命周期、存储锁、cookie 作用域、GC 时机这些细节，稍不注意就会导致“有时能登录，有时跳回登录页”这类问题。尤其在 Nginx + PHP-FPM 配置下，session.save_path 权限和 session.cookie_httponly 设置经常被忽略。