if these are not in memory created probably standard library sendfile can help

this needs to be adjusted to Echo interface

		w.Header().Set("Content-Disposition", `attachment; filename="report.pdf"`)
		http.ServeFile(w, r, "./files/report.pdf")

For on-disk PDFs http.ServeFile (via c.Response().Writer + c.Request()) is genuinely the best answer — it sets Content-Type, handles Range requests for free (pause/resume downloads, PDF viewer byte-range fetches), and uses sendfile(2) on Linux so bytes go kernel-to-socket without userland copies. Expanding @aldas' sketch a little:

func servePDF(c echo.Context) error {
    path := "./files/report.pdf"

    f, err := os.Open(path)
    if err != nil {
        return echo.NewHTTPError(http.StatusNotFound)
    }
    defer f.Close()

    stat, err := f.Stat()
    if err != nil {
        return echo.NewHTTPError(http.StatusInternalServerError)
    }

    c.Response().Header().Set("Content-Type", "application/pdf")
    c.Response().Header().Set(
        "Content-Disposition",
        `inline; filename="report.pdf"`, // "attachment" forces download
    )
    // Let http.ServeContent handle Range, ETag, and Last-Modified correctly.
    http.ServeContent(c.Response().Writer, c.Request(), stat.Name(), stat.ModTime(), f)
    return nil
}

A few important nuances vs. ServeFile:

• ServeContent + explicit os.Open lets you control the Content-Disposition. ServeFile would also work but using ServeContent keeps all the Range/ETag goodness and your disposition header.
• inline vs attachment. If the user's browser should render the PDF, use inline. If you want Save-As, use attachment.
• ETag + Last-Modified = conditional GETs. ServeContent handles If-None-Match and If-Modified-Since, so a PDF viewer that re-requests the same URL gets a 304 and no bytes transfer.
• Nothing about this loads the PDF into memory. sendfile(2) on Linux and TransmitFile on Windows move pages from the OS cache directly to the socket. On FreeBSD/macOS the code path is similar.

If the PDF is generated on the fly

Your third option ("stream PDF bytes") is the right move — but it's generated-content streaming, not file streaming. Two shapes:

A. You can seek while generating (uncommon for PDFs but possible with a tempfile):

tmp, _ := os.CreateTemp("", "report-*.pdf")
defer os.Remove(tmp.Name())
defer tmp.Close()

if err := pdfgen.Write(tmp); err != nil { return err }
if _, err := tmp.Seek(0, 0); err != nil { return err }

stat, _ := tmp.Stat()
c.Response().Header().Set("Content-Type", "application/pdf")
c.Response().Header().Set("Content-Disposition", `inline; filename="report.pdf"`)
http.ServeContent(c.Response().Writer, c.Request(), "report.pdf", stat.ModTime(), tmp)
return nil

Tempfile cleanup is a defer os.Remove(...) — no scheduled sweep needed, Go's runtime handles the removal when the request returns.

B. You cannot seek (pure streaming):

c.Response().Header().Set("Content-Type", "application/pdf")
c.Response().Header().Set("Transfer-Encoding", "chunked")
c.Response().WriteHeader(http.StatusOK)

// Stream bytes directly into the response. Flush every so often
// so intermediaries don't buffer the whole body.
pr, pw := io.Pipe()
go func() {
    defer pw.Close()
    if err := pdfgen.Write(pw); err != nil {
        pw.CloseWithError(err)
    }
}()

_, err := io.Copy(c.Response().Writer, pr)
return err

Trade-offs vs A:

• No Content-Length, so PDF viewers can't show a download-progress bar.
• No Range requests, so pause/resume doesn't work.
• Works for truly huge outputs where writing a tempfile isn't acceptable.

What I'd pick

• On-disk PDF you already have: ServeContent with the snippet at top. It's the right answer.
• Generated PDF, small-to-medium (< 100 MB): write to a tempfile, then ServeContent it. You get Range support for free.
• Generated PDF, huge or truly streaming source: io.Pipe with chunked transfer.

The "file on disk" is the suboptimal middle option only if you're thinking of it as "load bytes into memory" — with ServeContent it's not that at all, it's zero-copy kernel-to-socket.