我今天在修改会话库时遇到了一个问题，这可能是我第一次在后端脚本上看到特定于浏览器的问题。我希望有人能说清楚。
基本上，会话库的工作原理是：实例化时，它会在客户端计算机上检查名为“id”的cookie（以uniqid结果的形式）。如果找到cookie，则脚本会根据会话表中的条目检查该用户代理字符串的散列副本。如果找到匹配的条目，则脚本将恢复会话。如果未找到名为“id”的cookie，或者会话表中不存在匹配的条目，则脚本会同时创建两者。我认为相当标准。
现在这里有一个奇怪的部分：在Firefox中，一切都按预期工作。用户获得一个会话，只要24小时不活动，他就会在连接时恢复。但是当我在Chrome中访问该页面时，即使它看起来相同并且似乎以相同的顺序执行查询，我在会话表中看到两个条目。会话共享代理字符串，但ID不同，时间戳记日志表示在为用户创建的会话之后不久（在一秒内）创建了ghost会话。
出于调试目的，我在执行时一直在屏幕上打印查询，这是我在Chrome应该打开一个会话时所看到的一个例子，而是以某种方式打开两个：
// Attempting to resume a session
SELECT id FROM sessions WHERE id = '4fd24a5cd8df12.62439982' AND agent = '9bcd5c6aac911f8bcd938a9563bc4eca'
// No result, so it creates a new one
INSERT INTO sessions (id, agent, start, last) VALUES ('4fd24ef0347f26.72354606', '9bcd5c6aac911f8bcd938a9563bc4eca', '1339182832', '1339182832')
// Clear old sessions
DELETE FROM sessions WHERE last < 1339096432
以下是我之后在数据库中看到的内容：
id, agent, start, last
4fd24ef0347f26.72354606, 9bcd5c6aac911f8bcd938a9563bc4eca, 1339182832, 1339182832
4fd24ef0857f94.72251285, 9bcd5c6aac911f8bcd938a9563bc4eca, 1339182833, 1339182833
我错过了一些明显的东西吗？我唯一能想到的是Chrome可能会在后台创建一个隐藏的会话，可能会抓取该页面。如果是这种情况，那么当我开始将活动会话与users表中的条目相关联时，它可能会成为一个问题。我一直在寻找我的脚本中可能存在的错误，但到目前为止我还没有找到任何东西，并且一切都在Firefox中按预期工作。
答案 0 :(得分：3)
我之前遇到过这种情况并且同样困惑。几个月前，Chrome已启用预取功能。因此，为了加快用户的感知速度，它会抓取页面上的大多数链接并提前检索并呈现它们。非常适合最终用户，因为如果您使用宽带，它可以真正减少页面更改时间。
不幸的是，对于我们的Web开发人员来说，它会像上面那样引起混淆。例如，当Chrome用户访问网站但尚未分配Cookie或会话时，会发生这种情况，但浏览器已预先提取多个网页并分配了多个会话。
因此，假设有人访问了一个页面，其中包含指向PHP脚本不同区域的链接，该脚本旨在为所有访问者分配Cookie ...如果Chrome同时或接近其中的两个页面，PHP将会最终分配不同的会话，因为Chrome中的另一个线程基本上需要一个新的会话/ cookie才能完成其他任务。
我知道有两种解决方案：一种是Google's JavaScript API for handling prerendering，我没有发现它特别好。另一种方法是在从PHP分发会话和cookie时执行更严格的检查。要么不为访客用户分配会话，要么添加一些额外的检查（IP，主机名，等等）。
希望有所帮助。