105 道问答题，一道一卡105 questions, one card each

In one line: Node runs your JavaScript on one thread and its I/O on many. The main thread runs JS; anything slow goes to libuv’s thread pool or straight to the OS, and when it finishes the callback is queued for the event loop to pick up.

Six phases, and the order matters:

1. timers — setTimeout and setInterval callbacks that are due
2. pending callbacks — system callbacks deferred from the previous turn
3. idle / prepare — internal use
4. poll — picks up new I/O events; this is where the process spends most of its time
5. check — setImmediate callbacks
6. close callbacks — things like socket.on("close")

The key point: microtasks are drained between every phase. And Node has two levels of them — process.nextTick outranks Promises. It gets its own queue and runs before any Promise microtask.

How this differs from the browser (this is the part they are testing): the browser has just two tiers, macrotask and microtask, and takes one macrotask per turn. Node has six phases, and within a phase it drains the whole queue.
Node also has setImmediate and process.nextTick, neither of which exists in a browser.

Follow-up: “Which fires first, setTimeout(fn, 0) or setImmediate?” — it is not guaranteed. At the top level of the main module the order depends on how long startup took. But inside an I/O callback setImmediate always wins, because check comes right after poll while timers has to wait for the next turn. Saying “undefined in the main module” is the answer that earns you points.
“What about CPU-bound work?” — one thread means it blocks everything. Use worker_threads, a child process, or hand the job to a different service entirely.

In one line: the client sends a request, it walks through a chain of middleware, a route matches, the handler does its work (hits the database and so on), one response goes out, done.

What it actually passes through in Express:

1. Parsing — express.json() turns the body into req.body (without that middleware req.body is undefined, which is the single most common beginner bug)
2. Generic middleware — CORS, logging, a correlation id, rate limiting
3. Authentication and authorisation — verify the token, hang the user off req.user
4. Route matching — the first registered method + path that matches wins
5. Validation, then business logic, then the database
6. Response — res.status(200).json(...)
7. Catch-alls — the 404 handler and the error-handling middleware

Three rules you have to know:

• Middleware runs in registration order and you must call next() for the chain to continue. Forget it and the request hangs forever while the client spins.
• One request gets exactly one response. A second res.send throws Cannot set headers after they are sent. So always return after you respond.
• Error middleware takes four arguments, (err, req, res, next) — drop one and Express no longer recognises it as an error handler. A classic trap.

Follow-up: “Does Express catch errors thrown inside an async function?” — not in Express 4. It becomes an unhandled rejection and the request hangs. Either try/catch yourself and call next(err), or wrap the handler in an asyncHandler. Express 5 forwards them for you.

In one line: a path parameter says which resource (/users/42); a query parameter says how you want it (?page=2&sort=name).

One test to decide: “Take it away — is it still the same resource?” Drop the 42 and you no longer know who you mean → path parameter. Drop ?page=2 and it is still the same set of users, just a different page → query parameter.

Follow-up: “Can a password go in a query parameter?” — absolutely not. URLs land in browser history, server access logs, the Referer header and CDN logs. HTTPS encrypts the connection; it does not stop the URL from being written down all over the place. Sensitive values go in the body or a header.
“Is there a length limit on query strings?” — not in the spec, but in practice servers and CDNs cap the URL somewhere between 2 KB and 8 KB. Search endpoints with complex filters sometimes switch to POST with a body for that reason.

In one line: Create / Read / Update / Delete — the four basic things you do to data. REST maps them onto HTTP methods.

Two follow-ups they almost always ask:

① PUT vs PATCH. PUT is a full replacement — fields you leave out should be cleared. PATCH is a partial update — only the fields you send change. Plenty of real code uses PUT as if it were PATCH, which is wrong, but know that it happens.

② Idempotency. Send the same request more than once, get the same result — that is idempotent.

• GET / PUT / DELETE — idempotent
• POST — not idempotent (send it twice and you get two records)
• PATCH — depends on the payload ({ n: 5 } is idempotent, { n: { $inc: 1 } } is not)

Why it matters: when a client retries or a gateway resends after a timeout, an idempotent endpoint is safe. POST needs an idempotency key to stop the same order being placed twice.

One more follow-up: “What do you return when deleting something that does not exist?” — 204 or 404, both defensible. 204 fits the idempotent reading (the outcome you asked for is true); 404 tells the caller more. What matters is that the team agrees and it is in the API docs.