PHP 登录态由服务端 Session 与浏览器 Cookie 共同维系。本文梳理会话配置、HttpOnly 与 SameSite 设置、会话固定与水平越权的常见成因，并给出可逐项核对的上线自查清单。
登录态不是「记住用户名」，而是两条线
不少 PHP 项目里，登录功能看起来只是查一次用户表、把用户 ID 放进会话，但线上真正出问题的往往不是查询本身，而是会话数据放在哪里、浏览器又怎么把标识带回来。所谓 PHP Session 登录态，其实是两条线：服务端用会话标识找到一份会话数据，浏览器用 Cookie 在每次请求里带回这个标识。任意一条线断了，表现都差不多——用户刚登录又被弹回登录页，或者换个账号能看到别人的数据。
先把边界划清楚：Cookie 里只放一个随机、无含义的会话标识，用户 ID、角色、权限这些放在服务端会话里；不要把权限判断结果直接写进 Cookie 交给浏览器。这样排查时能很快定位，是标识没带回来，还是服务端会话没读到。
Session 配置里值得逐项确认的几项
php.ini 中与会话相关的配置不算多，但每一项都会改变行为。session.save_handler 决定会话存在文件、数据库还是缓存里。单机部署用文件没什么问题；换成多实例之后，如果每台机器各存一份，请求被转发到另一台就会掉登录，这时需要把会话集中存放，或者在网关层做会话保持，两者选其一并写进部署说明。
session.gc_maxlifetime 是服务端会话数据的存活时间，session.cookie_lifetime 是浏览器端 Cookie 的存活时间，含义不同。常见现象是 Cookie 还在、服务端数据已经被回收，用户点着点着就退出。另外回收是按概率触发的，不要把它当成精确的过期定时器，业务上的超时判断仍要自己记录时间。
session.use_strict_mode 建议开启，开启后服务端不会接受客户端自行编造的会话标识，能减少会话固定类问题。项目如果从老版本升级上来，若干配置项的默认值可能发生变化，升级时顺手核对一遍更稳妥，兼容检查的思路也可以参考 PHP 7.4 升级 PHP 8.2 的兼容性排查清单。
Cookie 的三个属性和一个范围
HttpOnly 让脚本读不到会话标识，能降低脚本窃取标识的风险，但它并不能替代输出转义，XSS 该防还是要防。Secure 表示只在 HTTPS 连接里发送，本地用 http 调试时 Cookie 一直带不上，是很常见的误会。SameSite 控制跨站请求是否携带 Cookie，Lax、Strict、None 的差别会直接影响从第三方页面跳转回来的场景；设为 None 时必须同时带上 Secure。
domain 与 path 决定 Cookie 的作用范围。domain 不要为了省事设得过大，同主域下的其他站点可能因此共享到同一个标识；path 一般设为根目录即可。登录校验通过之后调用 session_regenerate_id(true) 重新生成标识，让登录前后使用不同的会话 ID，这一步很多老代码会漏掉。
还要留意输出时机：会话 Cookie 属于响应头，任何在 header 之前的输出都可能导致设置失败。框架项目一般由框架统一处理，自己写的原生脚本则要检查文件末尾有没有多余的空行或闭合标签。
常见越权与会话固定问题
最需要警惕的是只判断「是否登录」，不判断「有没有权限操作这个资源」。例如详情接口接收一个订单 ID，代码只检查会话存在就直接查库返回，把 ID 改成别人的编号就能读到别人的数据，这类水平越权在后台系统里很普遍。凡是涉及资源 ID 的接口，都要把当前用户与资源归属做一次校验，不能依赖前端不显示别人的入口。
第二类是把用户 ID 直接放进 Cookie 并信任它。Cookie 由浏览器持有，内容可以改，服务端读到之后必须重新验证来源。第三类是会话固定：如果登录前后沿用同一个会话标识，别人事先让受害者使用了某个已知标识，登录之后这个标识就带上了受害者权限，重新生成标识正是为了解决它。
还有两个容易忽略的点：管理员调整了某个账号的角色，但旧会话里缓存的角色没有刷新，权限变更看起来不生效；排查日志时把完整会话标识写进日志文件，等于把凭据复制到了另一处。角色变更后重新读取或让相关会话失效，日志里只保留标识的短前缀。
续期、退出与多端同时在线
续期有两种做法：滑动续期是每次访问都往后延长，体验好但长期不操作也一直有效；固定过期则到点必须重新登录。选哪种取决于业务对安全与体验的取舍，选定之后服务端记录的时间戳要与之对应，别只依赖配置里的回收时间。
退出登录要做两件事：清空或销毁服务端会话数据，同时让浏览器端 Cookie 过期。只 unset 一个变量、或者只删前端 Cookie，都会留下能继续使用的残留。修改密码之后是否需要让其他设备重新登录，也要提前定好规则。
如果允许一个账号多端在线，建议会话表按设备列出并支持单独失效，而不是只存一条记录。「记住我」不建议用超长会话实现，可以单独建一张可撤销的令牌表，与会话标识分开管理。另外，同一个用户短时间内多个并发请求同时写会话，文件型存储可能出现锁等待，接口设计上尽量减少在长请求里持有会话写锁，这一点和 内容管理 RESTful API 设计 里的并发处理思路是相通的。
上线前的自查清单
核对 session.save_handler、回收时间、Cookie 生命周期与 strict_mode 的实际值，而不是只看代码里的默认值。
确认登录成功后重新生成了会话标识，退出时服务端数据与浏览器 Cookie 一起清理。
检查会话 Cookie 是否设置 HttpOnly、Secure，SameSite 是否与跨站跳转场景匹配。
逐个检查带资源 ID 的接口，确认都做了当前用户与资源归属的校验。
确认前端隐藏按钮只是展示层处理，服务端有独立的权限判断。
多实例部署时确认会话集中存放，并验证跨实例请求不掉登录。
检查日志文件、错误上报里没有出现完整会话标识与敏感字段。
用两个不同账号做一次交叉访问回归，覆盖登录、退出、改权限、改密码四个动作。
小结
会话相关的故障，多数不是某一行代码写错，而是服务端存储、Cookie 属性、权限校验这三处没有对齐。把标识的生成与传递、资源的归属判断、退出的双清理分别做成可核对的检查项，比事后逐页面找问题省事得多。改造老系统时，也建议先把现有登录路径画出来，再决定动哪一层。
如果现有系统的登录模块改造、会话逻辑重构需要有人一起梳理改动范围和实现方式，PHPLEFT（西安尊云科技）承接程序定制开发、老系统二次开发与接口对接，可通过微信 yvsm316 说明需求。本文为技术经验分享，具体方案以实际沟通为准。