session 中间件里的 sessionID（以下简称sid）的算法为 24byte 的全随机。sid 重复的可能性比较小，但理论上还是有重复的可能。

session 中间件的 session 维护流程为：

• 新 session 的创建

  1. 将 option 里配的 sessionStore 挂到 req 上；
  2. 修改 res.end 函数，在原函数基础上加入 req.session.save 操作，就是往 sessionStore 里存 session；
  3. 新 session 的接入，因为是新 session，所以 cookie 里没有 sid 信息。随机一个 sid，以此 sid 来创建 session，然后将 session 绑到 req 上；然后将 req 和 res 交给下个中间件或流程处理。

• 旧 session 接入

  1. 同上边的第 1 步；
  2. 同上边的第 2 步；
  3. cookie 里有 sid，根据这个 sid 去 sessionStore 里取回 session 信息；如果 session 过期就取不到 session了，就像上边的第 3 步里那样重新创建一个 session。

为了完全消除 sid 的重复性带来的影响，就要检查新创建的 sid 是否已经存在与 sessionStore 里了。

session 中间件的结构在 Express 的以后版本中还会修改，所以我不想动 session 中间件的源码。于是只能在新 session 创建后的我自己的逻辑流程中来处理。逻辑流程中，当 HTTP 包为登陆验证包时，将 session 中间件给创建的 session 的 sid 拿到 sessionStore 里去查下是否已被使用，如果使用就干掉当前 session，并通知当前客户端重试。

干掉当前 session 有个技巧，就是直接 req.session=null; 这样即可，因为修改后的 res.end 里，判断如果 req.session 未定义，就不会再去调用 req.session.save 了。当前 session 是一定不能让他 save 的，否则就拿当前用户的信息覆盖了之前用此 sid 的用户，造成那个用户后续逻辑混乱。