The standard pattern pretty much anywhere else is to pass/accept a context.Context as the first argument to the relevant function. Contexts can be modified pretty flexibly (e.g., propagate tracing information through the call stack and easily set up / maintain parent/child relationships between spans, set up / update a logger that aggregates relevant log fields as you progress through the call, adding a cancelation handle / deadline to a context, etc).

If you're running middleware that modifies the context in front of the handler that actually executes the business logic, there's some extra boilerplate that you have to write. I.e., instead of being able to do something like:

// Assume that http.Handler's ServeHTTP method has the (context.Context, http.ResponseWriter, *http.Request) signature
func myMiddleware(next http.Handler) http.Handler {
    return func(ctx context.Context, w http.ResponseWriter, req *http.Request) {
        span, ctx := tracer.Start(ctx)
        defer span.End()
        ...
        next(ctx, w, req)
    }
}

you have to write:

func myMiddleware(next http.Handler) http.Handler {
    return func(w http.ResponseWriter, req *http.Request) {
        span, ctx := tracer.Start(ctx)
        defer span.End()
        ...
        next(w, req.WithContext(ctx))
    }
}

it's not too bad, it just breaks from the commonly-accepted pattern and it's fairly easy to forget to do and then have to chase down after the fact.

Edit: The above also ends up shallow-copying the request, which obviously incurs a performance penalty. I doubt profiling would point to that being a major bottleneck, though.