PHP session.use_strict_mode 如何与自定义 session handler 配合

PHP 开启 session.use_strict_mode 后，浏览器带来的 session ID 只有在存储中已经存在时才应被接受。自定义 session handler 的关键不是在 read() 里“读不到就创建”，而是额外实现 SessionUpdateTimestampHandlerInterface::validateId()，让 PHP 先判断 ID 是否属于一个已初始化的会话；未知 ID 会被 PHP 换成新的 ID。

官方文档：https://www.php.net/docs.php

strict_mode 真正检查的是哪一层

session.use_strict_mode=1 的判断对象是客户端提交的 session ID，而不是 $_SESSION 里的业务字段。默认文件 handler 能根据文件是否存在完成这一步；换成数据库、Redis 或自定义存储后，PHP 不知道你的记录规则，因此必须由 handler 提供 ID 验证回调。

在面向对象写法中，存储类通常同时实现 SessionHandlerInterface 和 SessionUpdateTimestampHandlerInterface。前者负责会话数据生命周期，后者提供 validateId() 与 updateTimestamp()。validateId() 应只返回布尔结果：ID 存在、未过期就返回 true，否则返回 false。不要在这里插入一条空记录，否则未知 ID 又被“收养”了。

让生成、验证、读取和续期共用同一套约定

最容易出错的是四个方法各自使用不同规则。例如 create_sid() 生成 32 位十六进制字符串，validateId() 却只查询未过期记录，read() 又把过期数据当成空会话返回。正确做法是先写清楚存储模型：id 是主键，payload 保存 PHP 交给 handler 的原始字符串，expires_at 负责有效期。

下面的代码是数据库 handler 的最小骨架，SQL 使用预处理参数；它是结构示例，不代表在本文环境中已经执行。生产实现还要补上连接池、并发更新策略、索引和错误日志。

 :now';
        $stmt = $this->db->prepare($sql);
        $stmt->execute(['id' => $id, 'now' => time()]);
        return (bool) $stmt->fetchColumn();
    }

    public function read(string $id): string
    {
        // 必须返回 write() 收到的原始序列化字符串；没有数据时返回空字符串。
        $stmt = $this->db->prepare(
            'SELECT payload FROM app_sessions WHERE id = :id AND expires_at > :now'
        );
        $stmt->execute(['id' => $id, 'now' => time()]);
        return (string) ($stmt->fetchColumn() ?: '');
    }

    public function write(string $id, string $data): bool
    {
        // PHP 已经完成会话序列化；这里只保存原值并刷新过期时间。
        $stmt = $this->db->prepare(
            'UPDATE app_sessions SET payload = :payload, expires_at = :expires WHERE id = :id'
        );
        $stmt->execute(['payload' => $data, 'expires' => time() + $this->ttl, 'id' => $id]);
        return $stmt->rowCount() > 0;
    }

    public function updateTimestamp(string $id, string $data): bool
    {
        // 只续期，不改写 payload；适合 lazy_write 未发现内容变化的请求。
        $stmt = $this->db->prepare(
            'UPDATE app_sessions SET expires_at = :expires WHERE id = :id'
        );
        $stmt->execute(['expires' => time() + $this->ttl, 'id' => $id]);
        return $stmt->rowCount() > 0;
    }

    public function destroy(string $id): bool
    {
        // 注销或轮换旧 ID 时删除对应记录。
        $stmt = $this->db->prepare('DELETE FROM app_sessions WHERE id = :id');
        return $stmt->execute(['id' => $id]);
    }

    public function gc(int $max_lifetime): int|false
    {
        // 清理阈值由 PHP 传入，避免 handler 自己维护另一套生命周期。
        $stmt = $this->db->prepare('DELETE FROM app_sessions WHERE expires_at execute(['cutoff' => time() - $max_lifetime])
            ? $stmt->rowCount() : false;
    }
}

// 严格模式和 handler 必须在 session_start() 前完成配置与注册。
ini_set('session.use_strict_mode', '1');
$handler = new DbSessionHandler($pdo);
session_set_save_handler($handler, true);
session_start();

为什么 read() 读不到时不能替代 validateId()

两者回答的是不同问题。validateId() 回答“客户端带来的 ID 能不能继续使用”；read() 回答“这个已接受的 ID 对应的会话数据是什么”。如果只实现后者，handler 可能把任意 ID 都送进读取流程，严格模式便失去了保护意义。

上线前按三类 ID 做排查

先确认 ini_get('session.use_strict_mode') 的值，再确认 handler 注册发生在 session_start() 前。排查请求时不要只测“正常登录”：至少准备一个数据库中存在且未过期的 ID、一个格式正确但不存在的 ID、一个已经过期的 ID。前者应读取原会话，后两者应进入新 ID 路径，而不是复用外部传入值。

同时检查会话表的 id 唯一约束、expires_at 查询索引和写入失败日志。若 validateId() 查询成功但 read() 仍返回空字符串，优先检查存储编码、连接到的库和序列化 handler 是否一致；不要先把 strict mode 关闭。

常见问题

只实现 SessionHandlerInterface，strict_mode 还有效吗？

对自定义 handler 来说不可靠。官方手册明确提示，缺少 validateId() 或过程式 validate_sid 时，严格模式实际上被禁用。

validateId() 返回 false 会删除客户端 Cookie 吗？

它表示当前 ID 无效，PHP 会为会话生成新的 ID；Cookie 的具体更新仍由 PHP 的会话配置和响应头流程完成。

read() 返回 false 可以吗？

推荐按接口契约返回字符串；没有数据返回空字符串，并把存储异常作为失败记录处理，不要用空会话掩盖数据库错误。

开启 strict_mode 就不用 session_regenerate_id() 了吗？

不是。strict mode 处理未知 ID 的接纳问题，登录、提权等身份变化仍应按应用流程轮换会话 ID，并同步处理旧记录。