Node.js crypto模块生成的哈希赋值给Express会话ID后值不一致

首先可以明确：你使用crypto模块计算md5哈希的逻辑本身完全正确，不存在哈希计算偏差的问题。你观察到的两个打印值不一致，本质是对express-session模块的内部设计和属性规则的误解——很多人刚接触时会默认认为session对象和普通JS对象一样，所有属性都可以随意读写，但实际上模块对核心属性做了严格的保护封装，具体原因有两点：

• req.session.id是express-session的核心内部属性，仅开放了读取权限，没有提供对应的写入逻辑：模块在初始化会话实例时，仅通过Object.defineProperty为id属性定义了getter方法，不存在可触发的setter逻辑。在非严格模式下，你执行的req.session.id = hash赋值操作会完全静默失败，既不会抛出报错，也不会真正修改会话ID的值。
• 你打印req.session.id的时候，拿到的根本不是你之前计算的md5值，而是express-session在请求最开始、路由处理函数执行前，就已经自动生成的原生会话ID——这个值和你在路由里算的30位随机字符串的md5哈希没有任何关联，自然不可能和Statement-1的输出一致。

整个请求的执行顺序可以完全解释你遇到的现象：

1. 客户端请求到达服务端，最先经过express-session中间件：中间件会优先从请求Cookie中读取已有的会话标识，如果未读取到有效标识，会按照内置的随机规则生成一个全新的会话ID，挂载到req.session对象上。这一步发生在你写的/hash路由处理逻辑运行之前。
2. 路由处理函数开始执行：
   • 生成30位随机字符串test，计算其md5十六进制哈希，打印输出对应值（即Statement-1的结果）
   • 进入未初始化的判断分支，尝试给req.session.id赋值你计算的哈希值——但因为这个属性是只读的，赋值操作完全没有生效
   • 紧接着打印req.session.id，此时读到的还是中间件最开始自动生成的原生会话ID，也就是你看到的和Statement-1不匹配的结果（Statement-2的输出）

会话ID是express-session的安全核心设计，从机制上就不允许业务代码直接篡改，避免出现会话固定、ID伪造的安全风险。如果你需要把自己生成的md5哈希值和当前会话绑定，不需要修改原生的session.id值，只需要将其存储为自定义的会话字段即可：

app.get('/hash', (req, res) => {
  let test = randomString.random(30);
  let hash = crypto.createHash('md5').update(test).digest('hex');
  console.log(hash);

  if (!(req.session.initialised)) {
    req.session.initialised = true;
    // 把自定义哈希值存在独立的session字段中
    req.session.userAuthHash = hash;
    console.log('Random: ' + test);
    // 读取自定义字段的值，即可和之前打印的hash完全一致
    console.log('Session关联哈希值: ' + req.session.userAuthHash);
  }
  res.send("Hello")
})

补充：如果确实需要替换当前会话的原生ID，express-session也提供了官方的req.session.regenerate()方法，该方法会在内部清空旧会话数据、生成符合安全规则的全新会话ID，不支持传入自定义的会话ID值。

内容的提问来源于stack exchange，提问作者kumarp