Session 与 Cookie 的分工：登录态到底存在哪一端

登录态真正住的地方在服务端，浏览器里那个 Cookie 只是张「取件码」。结论先放这里：Cookie 不存身份，只存一个随机 Session ID；服务端 Session 里才记着「这个 ID 对应哪个用户、什么时候登录的」。所以清掉浏览器 Cookie 会掉登录，但改了 Cookie 内容通常换不来别人的身份。

Cookie 是钥匙，Session 是锁后面的抽屉

结论：两端分工的本质是「客户端只放不可信的标识，服务端放可信的数据」。

Cookie 是浏览器自动携带的一小段键值文本，每次请求都会原样发给服务器，用户自己在开发者工具里就能随便改。Session 是服务端保存的一份会话数据，PHP 系系统一般用 session_id 做索引，里面记 user_id、登录时间、权限快照这类东西。两者靠一个随机字符串对接：服务器下发 `Set-Cookie: PHPSESSID=xxxx`，之后浏览器每次请求自动带上，服务端拿它去查那份数据。

为什么要拆成两半？因为放在客户端的东西默认都不可信。你要判断「来的人是不是管理员」，依据必须落在自己机器上。

为什么登录态不能直接塞进 Cookie

结论：只要能被用户读到并改写的内容，就不能作为身份依据；要用也必须加签名。

把 `user_id=1` 直接写进 Cookie，等于把管理员权限做成一个下拉框。折中方案是签名或加密 Cookie（JWT 属于这一类），内容改了签名就对不上，能防一部分伪造。代价是「撤销难」——服务端不保存状态，想立刻把某人踢下线，只能靠黑名单或极短的过期时间兜底。

Clara BBS 这类系统在密码环节走的是 bcrypt 哈希存储，数据库里不出现明文，配合全站 CSRF 防护，等于给「客户端提交的东西一律当脏数据」这条原则做了兜底。

一次登录，两端各干了什么

结论：登录成功的关键动作发生在服务端，Cookie 只是把凭证带回浏览器的搬运工。

1. 浏览器 POST 账号密码，表单里还带一个 CSRF token；
2. 服务端比对 bcrypt 哈希，通过则创建或更新会话数据，写入 user_id；
3. 响应头下发 `Set-Cookie`，正常会加 `HttpOnly`（JS 读不到）、`Secure`（只走 HTTPS）、`SameSite` 三个属性；
4. 后续每个请求自动带 Cookie，服务端查会话，认出「你是谁」；
5. 退出登录时服务端销毁会话，浏览器手里的钥匙才彻底作废。

这也解释了为什么改密码后要重新登录——服务端把会话清了，Cookie 自然不好使。

登录环节本身也是攻击重点。Clara BBS 默认开启同 IP 高频失败拦截（防密码喷洒），连续输错默认 5 次锁定 15 分钟（后台可配），到期自动解锁，也能在后台手动解锁；每次登录都会进后台「用户体系→登录日志」，方便排查异常来源。

最容易踩的三个坑

结论：多数「登录态莫名丢失」不是 Session 机制坏了，而是 Cookie 的域或有效期对不上。

• 「页面已过期，请刷新后重试」：这是 CSRF 校验没过，通常因为页面缓存太久，或换了登录态导致 token 对不上。Clara BBS 新版编辑器已内置自动重试（拉取新 token 重发一次），若仍出现，刷新页面即可。另外建议后台「基本设置」里把站点地址写规范——带 https:// 且用主域名，避免 www 和裸域混用导致会话丢失。
• www 与裸域切换后掉登录：Cookie 按域隔离，`example.com` 和 `www.example.com` 拿到的不是同一份，跨域访问自然读不到。
• HttpOnly 别关：一旦让 JS 能读会话 Cookie，一次 XSS 就能把登录态打包带走。

什么时候该用哪一端

结论：需要「随时能强制失效」就用服务端 Session；只求证明「是我」，且能接受延迟撤销，才考虑签名 Cookie。

判断标准很简单：要踢人下线吗？要按用户封禁、要即时注销吗？要，就把权威状态留在服务端。典型做法是两者混用——长期「记住我」放一个带签名的持久 Cookie，短期会话走 Session，各管一段。

回到标题：登录态住在服务端，Cookie 只负责把钥匙来回带。搞清楚这条分工，登录丢失、CSRF 报错、跨域掉登录这几类问题基本都能自己定位。