Go-Fiber Context使用疑问：跨函数传递是否合规及文档语句解析

1. 将Context作为函数参数传递是否是不良实践？ #

不是。你示例里的写法完全没问题，只要你是在当前请求的处理链路中同步传递并使用Context，没有在handler返回后保留对它的引用就行。

文档里的规则核心是禁止把Context存到全局变量、结构体字段里，或者在异步goroutine里延迟使用（比如handler返回后才去读Context里的值）。像你这样在请求处理的同步调用链里传递，属于正常的代码拆分，是合理用法。

2. 关于“handler返回后Context值会被重用并变化”的疑问 #

谁会重用这些值？ #

是Fiber框架本身。为了提升性能，Fiber会维护一个Context对象池，当一个请求处理完成（handler返回），这个Context会被重置后放回池子里，分配给下一个进来的请求使用。

其他用户的请求会不会拿到旧的id值？ #

不会。Fiber在把Context重新分配给新请求前，会把里面的所有字段（包括params、请求体、局部存储的值等）都重置为当前请求的内容。你示例里的id=911只会属于当前请求，新请求进来后，Params("id")会拿到它自己的参数值，不会是911。

文档这句话真正要提醒你的是：如果你在handler返回后还保留了对Context的引用（比如存到全局变量、或者在异步goroutine里后续才读），那这个Context可能已经被分配给其他请求了，你读到的会是其他请求的数据，完全不符合预期。

3. “will change below your feet” 是什么意思？ #

这句话直译是“在你脚下变化”，用大白话解释就是：你以为自己拿着的是一个固定不变的Context，但实际上它可能在你没注意的时候偷偷被换掉了内容。

举个直观的例子：

func GetList(c *fiber.Ctx) error {
    // 启动一个异步goroutine，handler返回后才执行
    go func() {
        // 这里的c已经被放回对象池，分配给新请求了
        id := c.Params("id")
        // 此时id可能是另一个用户请求的参数，不是当前请求的911了
        fmt.Println(id)
    }()
    return c.SendString("Hello, World!")
}

你原本以为goroutine里读的是当前请求的id，但实际上在handler返回后，Context已经被重用，里面的参数被改成了新请求的值，就像你脚下的地面突然变了，你却没察觉，结果拿到错误的数据。

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