本文解析两种实现相同功能的 express+ejs 代码差异，重点说明为何将计算结果存于全局变量会导致并发请求数据污染，强调每次响应应基于当前请求独立渲染。
本文解析两种实现相同功能的 express+ejs 代码差异，重点说明为何将计算结果存于全局变量会导致并发请求数据污染，强调每次响应应基于当前请求独立渲染。
在 Express 应用中，看似“简洁”的全局变量状态管理（如你代码中的 let countLetters = 0）实则隐藏着严重的并发安全隐患。你的实现逻辑是：
- GET / 渲染时读取全局 countLetters；
- POST /submit 更新该全局变量，再重定向回 /；
- 依赖重定向后 GET 请求“看到”刚更新的值。
问题本质在于：countLetters 是共享的、无作用域隔离的全局状态。Node.js 的单线程事件循环虽不允许多线程并发修改，但 Express 处理的是多客户端并发 HTTP 请求。假设用户 A 提交姓名 “Alice Smith”（11 字符），countLetters 被设为 11；此时用户 B 打开新标签页访问 /，服务器会直接渲染 There are 11 letters in your name.——即使 B 还未提交任何数据。更严重的是，若 A 和 B 几乎同时提交不同姓名，countLetters 将被后者覆盖，A 的响应可能显示错误结果（即竞态条件）。
而教师方案采用纯函数式、请求级数据流：
app.post("/submit", (req, res) => {
const numLetters = req.body["fName"].length + req.body["lName"].length;
res.render("index.ejs", { numberOfLetters: numLetters }); // ✅ 数据绑定到本次响应
});它完全规避了全局状态，每个 POST 请求独立计算、独立传参、独立渲染。EJS 模板中通过 <% if (locals.letterNumber) { %> 判断是否存在 letterNumber 局部变量（注意：教师代码中实际传入键名为 numberOfLetters，模板却读 letterNumber，此处应统一——这是另一处需修正的细节），确保逻辑与当前请求强绑定。
✅ 最佳实践总结：
- 永远避免用全局变量存储请求相关数据（如表单结果、用户会话临时值）；
- POST 处理完成后，优先选择 res.render() 直接返回结果页（而非 res.redirect() 触发二次 GET），既减少请求次数，又杜绝状态漂移；
- 若必须重定向（如防止重复提交），应改用 Flash Messages 或 Session 存储（如 req.session.message = numLetters），而非全局变量；
- 中间件如 logger 可保留，但须确保其自身无副作用或共享状态。
你的日志中间件设计合理，体现了良好的调试意识；但核心数据流设计需转向“请求→处理→响应”闭环。这才是 Express “无状态服务”哲学的正确落地方式。
