本文揭示了 Express 应用中因误用 app.locals 导致多用户会话相互覆盖的核心错误，并提供符合 Express 设计规范的安全替代方案，确保每个请求独立维护用户状态。
本文揭示了 express 应用中因误用 `app.locals` 导致多用户会话相互覆盖的核心错误，并提供符合 express 设计规范的安全替代方案，确保每个请求独立维护用户状态。
在使用 express-session 与 passport 构建用户认证系统时，一个常见但极具隐蔽性的陷阱是：多个用户同时登录并操作时，页面渲染出错——显示为其他用户的会话数据（如用户名、权限、Flash 消息等）。这种“会话污染”并非由 session 存储（如 MySQL）或 Passport 序列化逻辑引起，而往往源于对 Express 作用域模型的误解。
根本原因在于您代码中的这一段：
// ❌ 危险：全局共享，绝对禁止用于用户级数据！
app.use((req, res, next) => {
app.locals.message = req.flash('message');
app.locals.success = req.flash('success');
app.locals.user = req.user; // ← 这是问题核心！
next();
});
app.locals 是 Application-level 的全局对象，整个 Express 实例（即整个 Node.js 进程）仅有一个 app 实例。当用户 A 的请求执行 app.locals.user = userA，紧接着用户 B 的请求又执行 app.locals.user = userB，此时 app.locals.user 立即被覆盖。若两个响应尚未完成（例如模板正在异步渲染），后端可能将 userB 的数据错误地注入到用户 A 的 HTML 中——造成典型的“会话串扰”。
✅ 正确做法：始终使用 request-scoped 或 response-scoped 的数据容器：
- ✅ req.user：Passport 已自动挂载，直接在路由或中间件中使用（如 if (req.user?.role === 'admin')）；
- ✅ res.locals：专为单次响应生命周期设计，每个请求拥有独立副本，安全可靠；
- ✅ Handlebars 模板中可直接访问 {{user.name}}（前提是通过 res.locals 传递）。
修复后的中间件示例：
// ✅ 正确：为每个请求独立设置 locals
app.use((req, res, next) => {
// 将 flash 消息和用户数据绑定到当前响应上下文
res.locals.message = req.flash('message');
res.locals.success = req.flash('success');
res.locals.user = req.user; // 安全！仅影响本次 res 渲染
next();
});
同时，请确保您的视图模板（如 .hbs 文件）引用的是 res.locals 中的数据：
<!-- views/layouts/main.hbs -->
{{#if user}}
<span>欢迎，{{user.username}}！</span>
<a href="/logout">退出</a>
{{else}}
<a href="/login">登录</a>
{{/if}}
⚠️ 额外关键检查点：
- resave: true 和 saveUninitialized: true 在生产环境易引发冗余 session 写入，建议设为 false（需确保 passport.serializeUser 正确实现）；
- cookie.httpOnly: false 降低安全性，除非明确需要前端 JS 访问 cookie，否则应设为 true；
- secret 值应使用 process.env.SESSION_SECRET 等环境变量管理，禁止硬编码。
总结：Express 的作用域层级必须严格区分——app（全局）、req/res（请求级）、locals（响应级）。只要坚持“用户状态永不触碰 app.locals”，而是通过 req.user 或 res.locals 访问，即可彻底规避多用户会话混淆问题，构建健壮、可扩展的认证系统。
