将Express Request对象全局暴露给Pug视图的副作用与弊端咨询

先说说你提到的便利点（确实能省不少事） #

• 彻底告别重复传参：不用在每一个路由的res.render里手动把req.query、req.user这类常用数据挨个传给视图，省了大量冗余代码，不用反复写类似res.render('page', { user: req.user, query: req.query })的模板代码。
• 全局统一访问：所有Pug视图都能直接拿到完整的req对象，需要用到请求相关数据时，不用再纠结当前路由有没有传，直接写req.xxx就能用，开发效率拉满。

但这个方式的副作用和弊端也不能忽视，具体有这些： #

• 敏感数据泄露风险：req对象里藏着不少敏感信息——比如req.headers里的Cookie、Authorization授权头，req.session里的用户隐私数据（如果用了session中间件），甚至req.connection里的客户端IP、端口等。一旦Pug模板里不小心输出了这些内容（比如调试时的console.log(req)，或者模板代码误写），很容易造成信息泄露。而且你没法限制视图能访问req的哪些属性，相当于把整个请求上下文的权限都放开了，风险很高。
• 破坏关注点分离原则：视图层的核心职责应该是展示经过处理的数据，而不是直接操作原始的请求对象。把完整的req丢给视图后，很容易出现“越界”逻辑——比如在Pug模板里直接解析req.query做业务判断，甚至处理请求参数，这会让视图和控制器的职责边界变得模糊，后期代码维护起来会非常头疼。
• 调试和排障变麻烦：如果某个视图里用到了req的某个属性，你没法直接从当前路由的res.render传参里找到数据来源，得去追溯全局的那个挂载中间件。尤其是团队协作时，新成员可能会一脸懵：“这个req是哪来的？”，增加了沟通和排障的成本。
• 潜在的性能隐患：虽然res.locals是每个请求独立的，但把整个req对象挂载进去，意味着在视图渲染阶段，这个包含大量属性的对象会一直被引用，可能会延迟垃圾回收的时机。在高并发场景下，这种累积效应可能会影响应用性能（当然，普通小项目可能感受不到）。
• 单元测试难度上升：测试Pug视图时，你需要模拟一个完整的req对象，而不是只传视图需要的特定数据。这会让测试用例变得复杂很多，得构造一堆请求上下文的模拟数据，才能覆盖视图里用到的req属性。

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