session中間件里的sessionID（以下簡稱sid）的算法為24byte的全隨機(jī)。sid重復(fù)的可能性比較小，但理論上還是有重復(fù)的可能。 session中間件的session維護(hù)流程為：
（一）新session的創(chuàng)建
（1）將option里配的sessionStore掛到req上；
（2）修改res.end函數(shù)，在原函數(shù)基礎(chǔ)上加入req.session.save操作（就是往sessionStore里存session）；
（3）新session的接入，因為是新session，所以cookie里沒有sid信息。隨機(jī)一個sid，以此sid來創(chuàng)建session，然后將session綁到req上；然后將req和res交給下個中間件或流程處理。
（二）舊session接入
（1）同上邊的第（1）步；
（2）同上邊的第（2）步；
（3）cookie里有sid，根據(jù)這個sid去sessionStore里取回session信息；如果session過期就取不到session了，就像上邊的（3）里那樣重新創(chuàng)建一個session。
為了完全消除sid的重復(fù)性帶來的影響，就要檢查新創(chuàng)建的sid是否已經(jīng)存在與sessionStore里了。
session中間件的結(jié)構(gòu)在express的以后版本中還會修改，所以我不想動session中間件的源碼。于是只能在新session創(chuàng)建后的我自己的邏輯流程中來處理。邏輯流程中，當(dāng)http包為登陸驗證包時，將session中間件給創(chuàng)建的session的sid拿到sessionStore里去查下是否已被使用，如果使用就干掉當(dāng)前session，并通知當(dāng)前客戶端重試。
干掉當(dāng)前session有個技巧，就是直接（req.session=null;）這樣即可，因為修改后的res.end里，判斷如果req.session未定義，就不會再去調(diào)用req.session.save了。當(dāng)前session是一定不能讓他save的，否則就拿當(dāng)前用戶的信息覆蓋了之前用此sid的用戶，造成那個用戶后續(xù)邏輯混亂。