php会话session怎么用_session跨页面数据存储操作【说明】-php教程-PHP中文网

session_start()必须在任何输出前调用，否则触发致命错误；$_SESSION需显式启动且不可直接赋值覆盖；session_destroy()仅删服务端数据，不清理$_SESSION或Cookie；推荐用Redis替代files存储以避免并发锁。

php会话session怎么用_session跨页面数据存储操作【说明】

session_start() 必须在任何输出之前调用

PHP 的 session_start() 会发送 session ID（通常通过 Cookie），一旦有空白、<?php echo '' ?>、BOM 字节或 HTML 标签提前输出，就会触发 “Headers already sent” 错误。这不是 warning，是 fatal 级别的运行中断。

常见踩坑点：

文件开头存在 UTF-8 BOM（尤其 Windows 编辑器保存时默认带 BOM）——用 VS Code 或 Notepad++ 切换为 “UTF-8 无 BOM” 编码保存
session_start() 前有空行、<?php ?> 后的换行、echo/print 语句、甚至注释前的空格
包含的配置文件（如 config.php）里有输出或 BOM

验证方式：用 headers_sent() 检查，例如：

if (headers_sent($file, $line)) { die("Headers sent in $file on line $line"); }

$_SESSION 是全局数组，但需显式启动且不能直接序列化赋值

PHP 不会自动把变量写入 session，必须通过 $_SESSION 数组操作。它不是 superglobal 的“魔法容器”，而是 session 扩展注册的特殊超全局变量，依赖 session_start() 初始化。

正确写法示例：

session_start();
$_SESSION['user_id'] = 123;
$_SESSION['cart'] = ['item_a' => 2, 'item_b' => 1];

错误做法：

$_SESSION = ['user_id' => 123]; —— 会覆盖整个 session 数组，丢失 PHP 内部维护的元数据（如 session_id 关联），下次请求可能读不到
存资源类型（如 fopen() 返回的 file handle）、闭包、PDO 实例等 —— 序列化失败，session_write_close() 时静默丢弃
存大对象或大量数据（如完整 JSON 字符串再 json_decode 存进去）—— 增加 session 文件体积和反序列化开销，影响性能

session_destroy() 不等于清空 $_SESSION

调用 session_destroy() 只是删除服务器端的 session 文件（或存储介质中的记录），不会自动清空当前脚本里的 $_SESSION 数组内容，也不会删除客户端 Cookie。

Browser Session Manager

使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能

下载

跨页面保持登录态的典型清理流程应是：

session_start();
$_SESSION = []; // 清空数组内容
if (ini_get("session.use_cookies")) {
    $params = session_get_cookie_params();
    setcookie(
        session_name(),
        '',
        time() - 3600,
        $params["path"],
        $params["domain"],
        $params["secure"],
        $params["httponly"]
    );
}
session_destroy();

注意：session_unset() 和 $_SESSION = [] 效果一致，但后者更直观；session_regenerate_id(true) 建议在登录成功后调用，防止 session fixation。

session.save_handler 设置影响实际存储位置和并发行为

默认 session.save_handler = files 把 session 存成磁盘文件，单个 session ID 对应一个文件。这在高并发下容易因文件锁导致请求阻塞（比如 A 页面在写 session，B 页面读同一 session 就会卡住）。

生产环境建议：

改用 redis 或 memcached：设置 session.save_handler = redis + session.save_path = "tcp://127.0.0.1:6379"，无锁、速度快、支持过期自动清理
若仍用 files，确保 session.cookie_httponly = 1 和 session.cookie_secure = 1（HTTPS 下）防止 XSS 窃取
不要在 CLI 脚本中依赖 session —— CLI 默认不启用 session，且无 Cookie 上下文

session 生命周期由 session.gc_maxlifetime 控制（单位秒），不是浏览器 Cookie 过期时间；两者需对齐，否则用户看到“已登录”，实际服务端 session 已被 GC 清理。