PHP5 如何使用会话（Session）保存用户登录状态

用户登录后，网站需要在后续请求中识别其身份。HTTP 请求彼此独立，PHP 不会自动记住上一次请求中的变量。Session（会话）可以把少量状态保存在服务器端，并通过浏览器携带的会话 ID 找回这些状态，因此常用于保存登录用户 ID、临时提示信息和购物车标识等。

Session 并不等于完整的身份认证系统：它只提供跨请求保存数据的机制。应用仍须负责验证密码、检查用户权限、防止跨站请求伪造（CSRF），并正确设置 Cookie 和服务器环境。本文示例以 PHP 5 的语法为主；涉及不同 PHP 5 小版本的功能会单独说明。

一、Session 如何保存登录状态

典型流程如下：

1. 浏览器提交登录凭据。
2. 服务器验证凭据，成功后把用户 ID 等必要信息写入 Session。
3. PHP 在响应中发送包含会话 ID 的 Cookie。
4. 浏览器后续请求自动携带该 Cookie，PHP 据此读取服务器端对应的 Session 数据。

常见的默认 Cookie 名称是 PHPSESSID，但名称和 Session 存储方式可以配置。会话 ID 通常是随机标识，不应把密码、权限判定结果或完整用户资料编码进客户端 Cookie。Cookie 被盗用时，会话 ID 可能被攻击者用于冒充用户，所以它本身也是敏感凭据。

Session 数据通常由 PHP 保存到服务器端的文件中，也可以配置为其他存储后端。默认文件存储时，PHP 的配置、文件权限、临时目录和多服务器部署方式都会影响会话能否正常读取。客户端一般只持有会话 ID，而不是服务器端 Session 文件。

二、最小可运行示例：写入和读取 Session

调用 session_start() 后，脚本才可以通过 $_SESSION 访问当前会话。它必须在输出内容之前调用，因为 PHP 通常需要发送 Cookie 等 HTTP 响应头。以下两个文件放在同一目录中即可测试：

<?php
// start.php
session_start();

$_SESSION['message'] = 'Session 已启动';
$_SESSION['count'] = isset($_SESSION['count'])
    ? $_SESSION['count'] + 1
    : 1;

echo '已写入 Session。<br>';
echo '<a href="read.php">读取 Session</a>';
?>

<?php
// read.php
session_start();

if (isset($_SESSION['message'])) {
    echo htmlspecialchars(
        $_SESSION['message'],
        ENT_QUOTES,
        'UTF-8'
    );
    echo '<br>';
}

if (isset($_SESSION['count'])) {
    echo '访问次数：' . (int) $_SESSION['count'];
} else {
    echo 'Session 中没有访问次数。';
}
?>

访问 start.php 后再打开 read.php，浏览器会在同一站点下自动携带会话 Cookie。session_start() 通常会根据 Cookie 中的会话 ID 恢复数据；如果没有可用的 ID，PHP 会创建一个新的会话。每个需要读写 Session 的请求都应在使用 $_SESSION 之前调用它。

示例对输出的文字使用了 htmlspecialchars()。Session 内容即使保存在服务器端，也不能因此假设它永远可信：数据可能来自用户输入、旧版本程序或其他写入路径。输出到 HTML 时仍应按上下文进行转义；输出到 JavaScript、URL 或 SQL 时，则需要对应的安全处理方式。

三、用 Session 保存登录状态

登录状态通常只需要保存用户 ID 和少量辅助信息，不必把密码或完整用户记录放入 Session。下面示例展示登录验证成功后的状态写入和登录检查逻辑。为便于阅读，凭据验证部分通过函数表示；实际项目应从数据库读取用户记录，并验证数据库中保存的密码哈希。

<?php
// login.php
session_start();

$username = isset($_POST['username'])
    ? trim($_POST['username'])
    : '';
$password = isset($_POST['password'])
    ? $_POST['password']
    : '';

// 应由应用实现：查询用户并安全验证密码。
// 成功时返回包含 id 的用户信息，失败时返回 false。
$user = verify_user_credentials($username, $password);

if ($user === false) {
    http_response_code(401);
    echo '用户名或密码错误。';
    exit;
}

// 登录成功后更换会话 ID，降低会话固定风险。
// 第一个参数 true 表示删除旧会话数据文件（适用于支持该参数的版本）。
session_regenerate_id(true);

$_SESSION['user_id'] = (int) $user['id'];
$_SESSION['logged_in'] = true;

header('Location: account.php');
exit;
?>

verify_user_credentials() 是应用自己的验证逻辑，不是 PHP 内置函数。它应使用参数化查询访问数据库，并采用安全的密码哈希验证方式。PHP 5.5 起提供 password_hash() 和 password_verify()；较早的 PHP 5 版本没有这两个函数，不能直接照搬相关代码。旧版本项目应使用其支持的可靠密码哈希方案，评估升级 PHP，并避免使用明文或可逆加密保存密码。

注意，示例中的 http_response_code() 从 PHP 5.4 起提供；如果目标环境是 PHP 5.3 或更早版本，应使用相应的兼容方式设置状态码，或者省略这行。session_regenerate_id() 的布尔参数用于控制是否删除旧会话数据；部署时还应确认实际 PHP 版本和会话处理器对该参数的支持情况。

下面是受保护页面的基本检查：

<?php
// account.php
session_start();

if (empty($_SESSION['logged_in'])
    || empty($_SESSION['user_id'])) {
    header('Location: login.html');
    exit;
}

$userId = (int) $_SESSION['user_id'];

echo '当前用户 ID：' . $userId;
?>

登录页面的跳转只是交互处理，不是权限控制的全部。每个受保护的页面、接口和操作都必须在服务器端验证当前用户身份，并检查其是否有权执行具体操作。例如，用户登录成功并不意味着其可以访问其他用户的订单；查询资源时通常还要把当前用户 ID 纳入授权条件。

四、退出登录与清理会话

退出时，既要清除服务器端的 Session 数据，也应删除浏览器保存的会话 Cookie。仅执行 session_destroy() 并不会自动清空当前请求中的 $_SESSION，也不会替应用删除浏览器 Cookie。可按以下方式处理：

<?php
// logout.php
session_start();

// 清空当前请求内的 Session 变量。
$_SESSION = array();

// 如果使用 Cookie 保存会话 ID，删除浏览器中的对应 Cookie。
// 必须使用与创建 Cookie 时相同的路径、域等属性。
if (ini_get('session.use_cookies')) {
    $params = session_get_cookie_params();

    setcookie(
        session_name(),
        '',
        time() - 42000,
        $params['path'],
        $params['domain'],
        $params['secure'],
        $params['httponly']
    );
}

// 删除服务器端会话数据。
session_destroy();

header('Location: login.html');
exit;
?>

setcookie() 的上述参数形式适用于 PHP 5；较新 PHP 版本还支持选项数组，但不能把新版本写法直接用于 PHP 5。Cookie 的路径、域、是否启用 HTTPS 和 HttpOnly 属性应与会话 Cookie 的配置一致。若项目设置过自定义 Cookie 参数，也要相应调整清理逻辑。

五、Session Cookie 的安全配置

会话安全不只取决于 PHP 代码，还依赖 Cookie 和服务器配置。生产环境应使用 HTTPS，并尽量让会话 Cookie 仅通过 HTTPS 传输，同时启用 HttpOnly，降低客户端脚本直接读取 Cookie 的机会。需要注意，HttpOnly 不能阻止跨站脚本攻击本身，也不能替代输出转义。

PHP 5 可在 session_start() 之前调用 session_set_cookie_params() 设置会话 Cookie 参数，例如：

<?php
// 应在 session_start() 之前执行。
// 参数依次为：生命周期、路径、域、Secure、HttpOnly。
session_set_cookie_params(
    0,
    '/',
    '',
    true,
    true
);

session_start();
?>

上例中的 0 表示 Cookie 在浏览器会话结束时过期，并不代表服务器端 Session 数据必然立即删除。服务器端数据何时清理，受 PHP 会话垃圾回收配置、存储后端和应用逻辑影响。第三个参数为空字符串表示使用当前主机范围；不要为了方便把 Cookie 域扩大到不必要的子域。

session_set_cookie_params() 的这些位置参数在 PHP 5 中可用，最后的 HttpOnly 参数要求 PHP 5.2.0 或更高版本。若运行环境早于此版本，不能假设该参数有效，应检查对应版本文档并优先升级。不同 PHP 版本对配置指令和会话处理器的支持存在差异，部署前应在目标环境验证。

也可以在 PHP 配置中设置会话选项。配置方式取决于运行环境：部分选项可放在 php.ini，也可能由服务器配置或代码在会话启动前设置。不要在会话已经启动后才修改影响 Cookie 创建的参数。尤其应检查会话 ID 是否通过 Cookie 传递、是否允许 URL 中的会话 ID，以及 Session 文件目录是否可被其他用户读取。

六、Session ID、登录固定与会话劫持

会话固定（Session Fixation）指攻击者设法让受害者使用攻击者已知的会话 ID；如果受害者登录后会话 ID 不变，攻击者可能复用该 ID。登录成功后调用 session_regenerate_id() 更新会话 ID，是重要的防护措施。权限提升、重新认证等关键节点也应评估是否需要更新会话 ID。

会话劫持通常涉及会话 ID 泄露或被窃取。HTTPS、合理的 Cookie 属性、避免在 URL 中暴露会话 ID、降低 XSS 风险、保护服务器端存储，都是防护的一部分。会话过期时间也应结合业务风险设置。仅把 Session 变量设置为 false 并不能清除攻击者已经拿到的会话 ID。

PHP 的会话生命周期由多项因素共同决定。浏览器 Cookie 的过期时间与服务器端会话数据的清理时间不是同一件事；PHP 的垃圾回收通常按配置概率触发，不能当作精确的过期定时器。对于高风险业务，可以在应用中记录登录时间或最后活动时间，并在每次请求时执行超时判断；同时还要设计主动撤销会话的机制。

七、适用场景与不适用场景

Session 适合保存服务器端、与当前浏览器会话相关的少量临时状态，例如登录用户 ID、一次性提示、短期流程步骤。它不适合存储大量文件或大型数据结构，也不适合被当作长期、可靠的数据库。用户关闭浏览器、清除 Cookie、切换设备，都会影响会话体验；服务器端存储也可能因过期清理或部署变更而丢失。

普通网页应用可以使用 Session Cookie 维护登录状态。对于无状态 API、移动客户端或需要跨服务验证的场景，可能会采用令牌等方案，但这并不意味着令牌天然更安全。选择方案时要考虑撤销能力、存储方式、跨域行为、刷新机制和威胁模型，不能只根据实现新旧作判断。

多台 Web 服务器部署时，默认文件会话可能出现“请求落到另一台机器就找不到会话”的问题。可通过共享会话存储、负载均衡粘性会话或其他架构解决；粘性会话不等于高可用，也不替代数据备份和安全控制。还应确保各服务器使用一致的 Session 配置，并保护共享存储中的会话数据。

八、常见错误与排查方法

1. 在输出之后才调用 session_start()

HTML、空白字符、UTF-8 BOM，甚至 PHP 文件结束标签后的空格，都可能导致响应头已经发送。常见提示是“headers already sent”。应将 session_start() 放到脚本最前面，检查文件编码和所有被包含文件；输出缓冲可能掩盖问题，不应作为忽略错误的理由。

2. 只在登录页启动 Session

每个要读取或写入 $_SESSION 的请求都应启动会话。受保护页面漏掉 session_start()，就可能读不到登录状态。应在页面入口或统一引导文件中集中启动，并确保它发生在输出之前。

3. 登录成功后不更新会话 ID

旧会话 ID 可能在登录前已被设置或泄露。认证成功后应调用 session_regenerate_id()，并确认调用时会话已经启动。不要为了“兼容”而继续使用认证前的会话标识。

4. 把 Session 当成权限检查

存在 $_SESSION['logged_in'] 只能说明应用记录了登录状态，不代表用户有权访问每个资源。每个敏感操作仍须检查用户 ID、资源归属和角色权限；涉及管理功能时也不能只依赖隐藏按钮或前端页面跳转。

5. 修改了 Cookie 属性却无法维持会话

Cookie 的域、路径、HTTPS 属性配置不当，可能导致浏览器不发送 Cookie。例如在 HTTPS 环境设置 Secure Cookie 后，经 HTTP 访问时浏览器不会发送该 Cookie。应检查浏览器开发工具中的 Cookie、请求头和响应头，并确认代理服务器传递的 HTTPS 信息配置正确。

6. 认为 Session 数据永不过期或自动清理

Cookie 到期不等于服务器数据已删除，服务器数据未清理也不表示浏览器仍持有有效 Cookie。应分别理解客户端 Cookie 生命周期、PHP 垃圾回收配置和应用自己的超时策略，并在需要时实现明确的失效逻辑。

7. 把用户输入直接写进 Session 后原样输出

Session 的服务端存储不代表其中内容可信，也不代表输出安全。对用户名称、提示消息等内容输出到 HTML 时，使用合适的 HTML 转义；不要把转义后的 HTML 和原始数据混为一谈，应尽量在输出时按上下文转义。

九、上线前检查清单

• 所有使用 Session 的请求都在输出前调用 session_start()。
• 登录凭据由服务器端验证，数据库访问使用参数化查询。
• 密码以安全的哈希形式保存，不存明文或可逆加密密码。
• 登录成功后更新会话 ID，并在每个敏感操作中执行授权检查。
• 生产环境使用 HTTPS，并正确设置会话 Cookie 的 Secure、HttpOnly、路径和域。
• 退出时清空会话变量、删除会话 Cookie，并销毁服务器端会话数据。
• 评估会话超时、主动撤销、服务器文件权限和多服务器存储方案。
• 在实际运行的 PHP 5 小版本上验证所使用的函数和参数。

用 Session 保存登录状态的核心很简单：服务器验证用户后，把最少必要的身份信息放入 $_SESSION，后续请求通过会话 ID 找回状态。但安全性来自完整链路，而不是单独一行 session_start()：会话 ID 要妥善保护，登录后应更新 ID，每个资源都要重新做授权判断，退出和过期也要有明确处理。