Aura.Session 不直接操作 $_SESSION，而是通过存储层、生命周期控制和段隔离三层机制规避原生会话缺陷；敏感数据须存于独立 Segment（如 auth），禁止裸露根段；防御会话固定需显式管理 ID、登录后 regenerateId、严格 Cookie 策略；CSRF Token 与 Flash 消息分属不同段，验证失败须重定向而非渲染错误。
为什么不用 $_SESSION 直接操作？
Aura.Session 不是替代 PHP 原生会话的“增强版”，而是彻底绕开 session_start() 和全局 $_SESSION 的手动管理方式。它把会话拆成「存储层」+「生命周期控制」+「段（segment）隔离」三层，避免跨功能模块污染（比如登录态和购物车数据混在同一个 $_SESSION 里）。直接改 $_SESSION 容易漏掉 session_write_close() 导致后续请求阻塞，而 Aura.Session 在对象销毁时自动 flush + close。
Aura\Session\Segment 怎么安全存取用户数据？
所有用户敏感数据（如 user_id、role、csrf_token）必须放在独立 Segment 中，不能裸露在根会话里。Segment 名字就是命名空间，天然隔离。
常见错误：用 $session->get('user_id') —— 这实际读的是根段，不安全；正确做法是：
$auth = $session->getSegment('auth');
$auth->set('user_id', 123);
$auth->set('role', 'admin');
// 读取时也必须指定段
if ($auth->get('user_id')) { ... }
注意：getSegment() 是懒加载，多次调用返回同一实例，但每个段有独立的过期策略和加密上下文。
立即学习“PHP免费学习笔记（深入）”；
如何防止会话固定（Session Fixation）和劫持？
Aura.Session 默认不生成或管理会话 ID，ID 必须由你显式提供（比如从安全 Cookie 或 JWT 中提取），这反而成了防御关键点：
- 绝不接受客户端传来的
PHPSESSID值，只接受你签发的、带 HMAC 的 session token - 登录成功后必须调用
$session->regenerateId()，它会清空旧段并生成新存储键（不是简单改session_id()） - 设置
SameSite=Strict+Secure+HttpOnly的会话 Cookie，且 Cookie 名不要叫PHPSESSID - 敏感操作（如改密码）前，用
$session->isRegenerated()校验 ID 是否刚刷新过
CSRF Token 和 Flash Message 怎么配合用？
Aura.Session 自带 Flash 段（自动跨重定向存活一次）和 CsrfToken 工具，但它们默认不共享密钥 —— 这是故意设计：Flash 数据可公开，CSRF Token 必须强绑定会话。
实操要点：
- CSRF Token 必须从
$session->getCsrfToken()->getValue()获取，不能自己生成 - 验证时用
$session->getCsrfToken()->isValid($_POST['_token'])，内部会检查是否匹配当前段的加密上下文 - Flash 消息走
$session->getFlash()->set('notice', 'Saved.')，它底层用的是独立的flashsegment，不影响 auth 数据的 TTL - 别把 CSRF Token 存进
auth段 —— 会延长其生命周期，增加泄露窗口
最常被忽略的是：CSRF 验证失败时，getCsrfToken()->getValue() 会返回新 Token，但旧表单里的值已失效 —— 必须重定向回表单页，而不是直接渲染错误，否则用户刷新页面会二次提交。
