确认session劫持需查日志：同一session_id多ip登录或用户异常自动登录；检查$_session关键字段及$_server['http_user_agent']、['remote_addr']是否突变；注意session_start()失败导致的假劫持。
怎么确认Session是否已被劫持？
不能靠猜，得看实际请求和日志。最直接的线索是：同一时间多个IP在用同一个session_id，或用户反馈“刚登出又被自动登录”。检查$_SESSION中关键字段（如user_id、login_time）是否被篡改，再比对$_SERVER['HTTP_USER_AGENT']和$_SERVER['REMOTE_ADDR']是否突变——这些值在正常会话中应相对稳定。
常见误判点：session_start()失败时返回false但不报错，导致后续$_SESSION为空或写入失败；此时看似“掉登录”，实为初始化异常，不是劫持。
setcookie()里必须设哪些安全属性？
PHP 7.3+ 推荐用数组参数一次性配齐，漏掉任意一项都可能留下缺口：
-
'secure' => true：强制只走 HTTPS，HTTP 请求下浏览器根本不会发这个 Cookie -
'httponly' => true：阻止document.cookie读取，XSS 脚本拿不到 Session ID -
'samesite' => 'Lax'：防 CSRF，大多数场景够用；若需跨站 POST（如支付回调），才考虑'None'，但必须搭配'secure' => true -
'expires'建议显式设置，别依赖浏览器默认（关闭即失效）；值用time() + 3600这类计算，避免硬编码时间戳
错误示范：setcookie('PHPSESSID', $id, 0, '/') —— 没secure和httponly，等于把钥匙挂门把手上。
php.ini 和 runtime 配置哪个优先级更高？
运行时调用ini_set()或session_set_cookie_params()会覆盖php.ini里的同名配置，但前提是调用发生在session_start()之前。一旦session_start()执行，再改session.cookie_httponly就无效了。
容易踩的坑：
- 在框架里（如 Laravel）
session_start()可能被自动触发，你写的ini_set()如果放得太晚，就白设了 -
session.use_strict_mode = 1必须通过ini_set()或php.ini设，它能拒绝未注册的 Session ID，防 Session Fixation，但很多项目漏掉这一项 -
session.cookie_lifetime设为0时，Cookie 关闭浏览器就删；设为正数则按秒算有效期，和expires语义不同，别混用
为什么重生成 session_id 还是被劫持？
session_regenerate_id(true)只是换 ID 并删旧文件，但若没同步清理客户端 Cookie，老 ID 仍可能被重放。必须确保三件事同时发生：
- 调用
session_regenerate_id(true)后，立刻用setcookie()或session_set_cookie_params()刷新客户端 Cookie - 旧 Session 文件真正被删除（
true参数保证这点），否则攻击者仍可用老 ID 访问 - 登录后立即做这件事，而不是等页面跳转完成后再执行——中间有时间窗口
更隐蔽的问题：如果前端用了 Ajax 登录，后端换了session_id，但前端没收到新 Cookie（比如没处理Set-Cookie响应头），下次请求还是带旧 ID，等于白换。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
