Go HTTP中间件中*http.Request指针更新与中间件挂载顺序问题

行为是否符合预期 #

这是完全符合预期的行为，和Go语言特性、HTTP中间件的洋葱执行模型直接相关：

• Go标准库的context.Context是不可变类型，任何追加KV、设置超时的操作都会返回一个全新的Context实例。而http.Request的WithContext方法同样会返回全新的*http.Request指针，指向携带新Context的Request实例，不会修改原指针指向的实例内容。
• Chi中间件遵循洋葱模型，先注册的中间件处于洋葱外层，后注册的处于内层。外层中间件调用next.ServeHTTP时采用值传递规则，哪怕参数是指针，传递的也是指针的拷贝，内层中间件修改指针指向（替换为新的Request实例）的操作，对外层中间件持有的原始指针完全不可见。

出现该问题的本质是：日志中间件先注册时，持有的是最原始的Request指针，后续RequestID中间件生成的新Request实例的地址，永远不会被外层的日志中间件拿到，自然读不到新Context里的RequestID。

可行的解决方案 #

方案1：调整中间件注册顺序（最推荐） #

所有需要向Context写入日志字段的中间件（RequestID、JWT鉴权、用户信息提取等），全部注册到日志中间件之前。
这个方案完全符合中间件的设计逻辑，没有额外开发成本和性能损耗：洋葱模型下，先执行的前置中间件会把所有需要的字段写入Context，后续内层的所有逻辑（包括业务Handler和后置执行的日志逻辑）都能直接读取到完整的Context字段。

方案2：绕过限制的实现（不推荐，仅做原理说明） #

如果确实需要把日志中间件放在最外层，可以通过共享可变容器的方式实现字段透传：

1. 日志中间件初始化一个用于存储日志字段的map[string]interface{}，将这个map的指针写入原始Request的Context
2. 后续所有需要写入日志字段的中间件，从Context中取出这个map指针，直接向map中追加字段
3. 日志中间件在后置打印日志时，直接读取map中的所有字段即可

这种方案破坏了Context的不可变特性，额外引入了并发安全风险（需要给map加锁），除非有特殊需求否则不要使用。

结论 #

对于常规业务场景，直接调整中间件注册顺序即可，后续JWT提取用户信息的中间件也同样注册到日志中间件之前，就能直接在日志中读到对应的用户名字段。

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