后端开发中为何要向request请求对象添加自定义属性？

你的猜测是对的——中间件/处理链路间的内部数据传递，是给request加属性最核心的原因，但背后是两个对象的职责差异，你之前的认知有个小偏差：
request对象从来不是“前端传什么就只有什么、后端只能读不能改”的静态数据包，它是后端框架为单次请求创建的、贯穿整个请求处理全生命周期的上下文容器；而response对象才是最终会序列化后通过网络发回给前端的内容载体，二者职责完全独立，你往request上写的内容，只要你不主动把它塞进response，永远不会发到前端去。

给request对象加属性的常见场景 #

• 请求处理链路的上下文共享
  后端处理一个请求通常要经过好几层逻辑：全局日志中间件→鉴权中间件→参数校验中间件→业务路由处理函数→响应格式化中间件。这些逻辑是串行执行的，很多数据不需要重复计算：比如鉴权中间件解析完请求头里的JWT，查库拿到当前登录用户的ID、角色、权限列表，直接挂到req.user上，后面所有环节直接读这个值就行，不用每个环节都重新解析token、查一次用户信息；再比如日志中间件给每个请求生成唯一的追踪ID，挂到req.requestId上，全链路打日志都带这个ID，排查问题的时候能直接串起整个请求的所有处理记录。这些数据都是后端内部用的，既没必要传给前端，很多甚至属于敏感内部数据不能传给前端，自然不可能往response上放。
• 框架原生能力的挂载（比如你提到的req.session）
  你疑惑为什么session挂在req而不是res上，本质是搞混了session的流转逻辑：

  session的完整业务数据默认是存在后端的（内存/Redis/数据库），前端只会拿到一个存了session ID的cookie，从来不会拿到完整的session数据。
  session中间件的处理逻辑是：先从请求带的cookie里取出session ID，去后端存储里把对应的session数据查出来，挂到req.session上供业务代码读写；等整个请求处理完，中间件会自动检查req.session有没有被修改，如果有更新就把新值存回后端存储，只有在session ID失效、需要重新生成的时候，才会往response上写Set-Cookie头通知前端更新cookie。整个过程里session的业务数据全程只在后端流转，自然不会挂在专门存返回内容的response对象上。

• 请求维度的临时状态存储
  很多只在单次请求生命周期内有效的临时数据，都适合挂在request上：比如同一个请求里多次用到的配置项，第一次查库后挂到req.appConfig上，后续直接读取避免重复查库；比如接口请求过程中调用上游服务的耗时、临时报错信息，挂在req上最后统一上报监控；比如文件上传场景下解析完的文件对象，挂在req.files上供业务逻辑直接使用。这些数据都是临时的，请求处理完就跟着request对象一起被垃圾回收，根本不需要传递给前端。

一个关键认知澄清 #

不要把request和response当成“前端发过来的包”和“后端发回去的包”这两个纯粹的网络传输对象，在后端框架的运行逻辑里，它们是单次请求处理过程中两个独立的上下文载体：

• 所有和“当前请求是什么、处理过程中产生了什么内部数据”相关的内容，都可以存在request上
• 只有你明确要返回给客户端的内容（状态码、响应头、响应体），才需要写到response上
  你往request上挂的任何自定义属性，只要不主动写到response里，永远不会泄露给前端。

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