Node.js中可经req、res.locals传递的flash消息为何需存入session

核心本质是：你当前使用的「挂载到req对象 → 通过res.locals传给视图」的链路，仅在单次HTTP请求的生命周期内有效，完全无法覆盖Flash消息最核心的跨请求传递场景。

单次请求传值的天然边界 #

• Node.js服务中，每一个进来的HTTP请求都会生成全新的独立req、res对象，当服务端给当前请求返回响应（不管是正常页面响应还是302重定向响应），这次请求的生命周期就彻底结束，挂载在上面的所有自定义属性都会被回收，下一次同个用户的请求完全访问不到这些数据。
• 如果你在业务中不走重定向，接口收到请求后直接渲染视图返回，那直接把消息挂在req上透传给res.locals确实能用，但这种场景占Flash消息实际使用的比例非常低。

Flash消息的核心使用场景就是跨重定向传递 #

Flash消息的设计初衷，就是为了解决「Post/Redirect/Get」模式下的一次性提示传递问题，这也是Web开发的通用最佳实践：

常规表单提交流程：

1. 用户通过POST请求提交表单（比如注册、登录、内容发布）
2. 服务端完成业务校验/处理后，不会直接返回结果页面，而是返回302重定向响应，引导浏览器发起新的GET请求跳转到结果页/原表单页——这种设计是为了避免用户刷新页面时重复提交POST请求
3. 整个流程涉及两次完全独立的HTTP请求：第一次POST、第二次GET，两次请求的req/res对象完全隔离，仅靠单次请求上挂载的属性根本没法把错误提示、成功提示从POST请求传递到GET请求渲染的视图里。

Session存储刚好匹配Flash消息的特性 #

• Session本身是针对单个用户、跨多次请求持久化存储的存储结构，能解决跨请求传值的基础问题。
• 基于Session实现的Flash机制天然自带「一次性消费」逻辑：消息写入Session后，只会在第一次被视图/业务逻辑读取后自动删除，既保证跨重定向能拿到消息，也不会出现消息残留、用户跳转到其他页面还重复展示旧提示的问题。

代码示例对比 #

仅挂载到req的方案（重定向场景失效） #

// 表单提交接口
app.post('/register', (req, res) => {
  const { username } = req.body
  if (userExists(username)) {
    // 把错误提示挂在当前POST请求的req对象上
    req.flashError = '用户名已被占用'
    // 走重定向逻辑，当前POST请求生命周期结束
    return res.redirect('/register')
  }
})
// 注册页GET接口
app.get('/register', (req, res) => {
  // 这里的req是浏览器收到302后发起新请求生成的全新对象
  // req.flashError 值为 undefined，视图拿不到错误提示
  res.render('register', { error: req.flashError })
})

基于Session的Flash方案（正常工作） #

// 简化版flash实现逻辑，和主流connect-flash库核心逻辑一致
app.post('/register', (req, res) => {
  const { username } = req.body
  if (userExists(username)) {
    // 消息写入session，跨请求保留
    req.session.flash = { error: '用户名已被占用' }
    return res.redirect('/register')
  }
})
app.get('/register', (req, res) => {
  // 从session中读取消息，读取后立刻删除，保证仅展示一次
  const errorMsg = req.session.flash?.error
  delete req.session.flash
  res.render('register', { error: errorMsg })
})

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