Fiber Ctx values changing after handler returns: copy selectively or enable Immutable globally?

Symptom

In a Fiber (Go, fasthttp-based) service, values obtained from Ctx methods such as c.Body(), c.Params(), and c.Query() appear valid inside the handler but produce corrupted or changing data when read later from a goroutine or stored reference. This matches the documented behavior that Fiber reuses fasthttp request buffers after the handler returns.

Constraints

The service needs some request data to outlive the handler (async workers, queued jobs). Two documented options exist: copy values explicitly (e.g., utils.CopyString or copying byte slices) at the points that need them, or enable Config.Immutable so all Ctx-derived values are copied automatically at the cost of extra per-request allocations. Behavior is version-sensitive between Fiber v2 and v3, so the installed version in go.mod matters.

Questions

1. For a mixed workload where only a few handlers need post-return data, is selective copying or global Immutable the safer default, and what allocation overhead should be expected from each?

2. Beyond Body, Params, and Query, which other Ctx accessors return reused buffers that must be copied?

3. Is a race-detector test with a goroutine reading Ctx data after return a reliable way to verify correctness for a given Fiber version?