A Next.js middleware file exports `config = { matcher: ['/((?!api|_next/static|_next/image|favicon.ico).*)'] }`. Explain what that pattern matches and why those particular prefixes are excluded.

## Reading the pattern ``` /((?!api|_next/static|_next/image|favicon.ico).*) ``` Break it apart: - The leading `/` is mandatory — every matcher entry describes a URL path and must start with a slash. - `(...)` is a group covering the rest of the path. - `(?!...)` is a **negative lookahead**: a zero-width assertion that says "at this position, the text that follows must not match this alternation". It consumes nothing itself. - `api|_next/static|_next/image|favicon.ico` is the alternation of excluded prefixes. - `.*` then matches the remainder of the path. So the whole entry reads: match any path, unless immediately after the leading slash it begins with `api`, `_next/static`, `_next/image` or `favicon.ico`. It is a deny-list expressed inside a catch-all, which is the shape Next's own documentation uses as the starting point. A common extension is to exclude static file extensions as well, for files served straight out of `public/`: ``` /((?!api|_next/static|_next/image|favicon.ico|.*\.(?:svg|png|jpg|jpeg|gif|webp)$).*) ``` ## Why the exclusions exist: the pipeline order The reason this is a real question and not regex trivia is where middleware sits. Next processes an incoming request roughly in this order: headers and redirects declared in the Next config, then **middleware**, then rewrites, then filesystem routes — `public/`, `_next/static`, and your `app` routes — then dynamic routes and fallbacks. Middleware is at step three; the filesystem is later. That ordering is what makes middleware useful (you can rewrite or redirect before anything has resolved) and it is also what makes an unscoped matcher expensive: the framework has not yet decided that `/_next/static/chunks/main-8f3a1c.js` is a build artifact when it consults your matcher. It is just a path. If your matcher accepts it, your function runs. ## The cost argument Count the requests a single page view generates: one document, several JavaScript chunks, a stylesheet, a few optimized images, a favicon, and — once the user starts navigating — an RSC payload request per navigation and often one per prefetched link. The document is a small minority of that traffic. An unscoped middleware turns each of the rest into an extra hop through your code. That hop costs three things. Latency, because it is on the critical path of every matched request and asset requests are otherwise served without touching application logic. Compute, because middleware is bundled, loaded and executed. And on hosts that meter middleware separately from rendering, money — the invocation count is driven by asset requests, not by page views, so the bill scales with something you were not thinking about. ## The correctness argument Cost is the headline, but excluding these prefixes also prevents outright bugs. Middleware written for pages tends to assume a browser navigating: it may attach cookies, negotiate a locale from `Accept-Language`, rewrite the path, or redirect. Applying any of that to `/_next/static/...` produces nonsense — a redirected chunk request is a broken page, and a `Set-Cookie` on an immutable asset response is at best noise. `/_next/image` is the optimizer endpoint; rewriting its path breaks image delivery. Excluding `api` similarly keeps page-shaped logic away from machine clients that will not follow a redirect to a login page and expect a JSON error instead. ## Where the deny-list shape helps and hurts A deny-list matcher is *exhaustive by default*: any route you add later is covered without touching the config. For concerns that must never be missed, that is the right property. The cost is that anything you forget to exclude is included — a new asset directory, a well-known path such as `/robots.txt` or `/.well-known/...`, a health-check endpoint. The opposite shape, an allow-list of explicit paths, has the mirror-image tradeoff: minimal invocations, but a route added six months later silently falls outside it. Whichever shape you pick, treat the matcher as reviewable configuration. A cheap safeguard is a test that asserts a handful of representative paths — an asset path, an API path, a page path — are or are not matched, so an edit to that regex cannot quietly change the traffic population entering middleware.