Same three lines. Two completely different moments.

import express from 'express';

const app = express();

app.set('query parser', 'extended');

app.use(express.json());

app.get('/products/:productId/reviews', (req, res) => {
  const productId = req.params.productId;

  res.json({ productId, query: req.query, body: req.body });
});

app.listen(3000);

1. 1
   app.set writes one key into app.settings. A plain object hanging off the app, plus the compiled form the setter derives alongside it. Nothing reads either one yet — when it gets read is the whole story of section five.
2. 2
   express.json() is a factory. Calling it returns a middleware function; app.use pushes that function onto the stack as a layer with no path, so it will match every request. The function itself has not run.
3. 3
   The path is compiled to a regex right here, at startup. path-to-regexp turns /products/:productId/reviews into a pattern with a named capture group, and your callback is wrapped in a Route that sits there until a request matches it.
4. 4
   Request time starts here, and only because the layers above ran. req.params is bound by the router for this layer alone, and its value is a string whatever the URL looked like.
5. 5
   All three surfaces populated at once, for the only time in the walk. req.query uses the parser chosen above; req.body exists only because the parser layer ran and matched.
6. 6
   app.listen is roughly http.createServer(app).listen(3000). The app object is itself the request handler. From here the stack is frozen in practice and the process waits.

app.use(logger);

app.use('/api', rateLimit);

app.use('/a/:aid', loadAccount);

app.use('/api/v1', v1Router);

app.use((err, req, res, next) => { /* ... */ });

1. 1
   No path, so it matches everything. The path defaults to /, which as a prefix matches every request. The only case where a .use layer genuinely sees an empty req.params.
2. 2
   A path, matched as a prefix. Measured: /api matches /api, /api/ and /api/x — but not /apix. The boundary is the slash, not the character.
3. 3
   A pattern, so it captures. This layer gets req.params.aid, and req.baseUrl reads /a/9 — the resolved segments, not the pattern.
4. 4
   A router, so the handle is another stack. The prefix stays stripped until the child hands control back through next(), so the child matches from its own root and never needs to know where it was mounted.
5. 5
   Four parameters, so it is an error layer. Classified on fn.length alone. Skipped during a normal walk, and the only kind considered once an error is in flight.

const app = express();

app.set('query parser', 'extended');

app.use((req, res, next) => next());

app.set('query parser', 'extended');

app.get('/x', (req, res) => res.json(req.query));

1. 1
   Before any registration, this position always wins. Guaranteed to be in place before anything can read it — correct in every version, for every setting, which is why "put app.set at the top" is decent advice.
2. 2
   In v4 this line triggers app.lazyrouter(). It reads query parser fn once and closes over the result inside a built-in query layer. Nothing re-reads it afterwards.
3. 3
   The same call here is already too late on v4. app.settings changes and the behaviour does not, so the setting reports one parser while another does the work. Nothing warns you.
4. 4
   On v5 there is no cutoff anywhere. req.query is a getter that looks the parser up on every access, so even a change made after app.listen takes effect on the next request.

defineGetter(req, 'query', function query() {
  var queryparse = this.app.get('query parser fn');
  if (!queryparse) {
    return Object.create(null);
  }
  var querystring = parse(this).query;
  return queryparse(querystring);
});

1. 1
   It is a getter, not a property. defineGetter puts this on the request prototype, so no layer ever assigns req.query — it is computed the instant someone reads it.
2. 2
   Looked up per access. This is the whole reason v5 has no app.set cutoff: nothing here holds a cached copy of the parser, so a change lands immediately.
3. 3
   A null prototype on the empty case. Setting query parser to false disables parsing entirely. The null prototype means a key called constructor cannot collide with anything inherited.
4. 4
   Re-parsed on every read. Which is why a write to req.query lands on a throwaway object and silently disappears, and why req.query !== req.query.

app.lazyrouter = function lazyrouter() {
  if (!this._router) {
    this._router = new Router({
      caseSensitive: this.enabled('case sensitive routing'),
      strict: this.enabled('strict routing')
    });
    this._router.use(query(this.get('query parser fn')));
    this._router.use(middleware.init(this));
  }
};

1. 1
   The guard makes this run exactly once. Called by your first app.use, app.get, app.route or app.param — never by app.listen — and everything it reads is frozen at that moment.
2. 2
   Router options are read here and baked in. Which is why case sensitive routing and strict routing must be set before your first registration of any kind, app.use included, not merely before app.listen.
3. 3
   The cutoff, in one line. this.get(...) evaluates now, and query() closes over what it returns. A later app.set updates app.settings and never reaches this closure, so setting and behaviour drift apart with no warning.
4. 4
   The second built-in layer. It cross-links req and res and swaps in the Express prototypes. v5 moved this work out of the stack entirely.

app.post('/products', express.json({ limit: '10kb' }), (req, res) => {
  res.status(201).json({ created: req.body });
});

1. 1
   Middleware passed as an argument is scoped to the route. It becomes a layer inside this Route rather than in the app stack, so it runs for this path and this method only.
2. 2
   Scoping the parser also scopes its limit. The body cap is per-parser, so a route that accepts large uploads does not have to widen the limit for everything else.
3. 3
   Reached only after the parser called next(). If the payload was over the limit the parser called next(err) instead, and this line never ran.

app.use((req, res) => {
  res.status(404).json({ error: 'not found', path: req.originalUrl });
});

app.use((err, req, res, next) => {
  console.error(err);
  res.status(err.status || 500).json({ error: err.message });
});

1. 1
   Three arguments, no path, registered after every route. So it is reached only when nothing above it wrote a response. Express has no special 404 hook — running off the end of the stack is the mechanism. Put this before your routes and it swallows the whole app.
2. 2
   originalUrl, not url. Inside a mounted router req.url has had the mount prefix stripped, so logging it would report a path your API does not have.
3. 3
   Four arguments, so Express classifies this as an error layer. It reads fn.length and nothing else, so the parameter names are irrelevant — and a default value on any of them drops length to 3 and quietly demotes this to ordinary middleware.
4. 4
   err.status is a convention, not a guarantee. Some libraries set it and some do not, which is what the fallback is for.