我一直在观察顺序请求的会话ID，并观察了一些我无法解释的事情：
1）在调用req.sessionID与req.cookies["connect.sid"]时，值不同（显示 request.sessionID神奇地从其关联的响应返回SID - 对我来说似乎不可能）。
根据我对Connect源代码的理解，req.sessionID与Cookie密钥同义，为什么会有差异？
2）我第一次从节点服务器发出请求时，会向浏览器发出一个SID（让我们调用这个SID1）。下次连接时，浏览器会发出SID2。第三次及以后我再次发布SID2。为什么node + Connect在安定之前会发出两个会话ID？
答案 0 :(得分：8)
所以这就是我的结论：
1）当请求通过中间件/模块时，我只能假设当前的SID附加到请求之后才能在中记录踢法。当req.sessionID包含先前的SID1时，这将部分解释为什么req.cookies["connect.sid"]可能包含SID2。
一些警告：
仅当浏览器首次连接到新节点服务器实例时才会出现此现象。
浏览器必须已连接到节点服务器的先前实例，该实例发出的cookie具有相同的键值（例如connect.sid）。
2）在窥探Sesame和Connect的源代码后，我发现他们已经记录了他们发布的所有会话ID - 以前我不知道。我怀疑这是防止会话固定的一步。
考虑到这一点，我意识到在初始连接期间在请求中发送的SID1是从先前的会话cookie中遗留下来的。 Connect会在其会话存储中查找与发送的cookie匹配的SID1的会话，但由于它是节点服务器的新实例（这里只是内存会话，没有持久会话ATM），因此无法找到它，因此是新的SID （SID2）将被发布 - 这一个坚持。应该早点想到这个。 ：）
TL; DR预期行为。旧会话中的Cookie不会为了安全起见而重复使用。
答案 1 :(得分：3)
req.sessionID与req.cookies["connect.sid"]相同。
但是，如果您使用supervisor或nodemon，则在修改文件时会重新启动服务器。当服务器重新启动时，它将丢弃服务器存储的所有会话，但客户端没有清除存储在cookie中的旧sessionID。所以你可以获得不同的sessionID。
有关详情，请参阅this answer。