Thứ tự xử lý event loop (tóm gọn)

Nguyên tắc gốc: sau mỗi tác vụ đồng bộ chạy xong (call stack rỗng), event loop luôn dọn sạch queue ưu tiên cao trước khi làm việc khác.

Thứ tự ưu tiên (cao → thấp):

1. Code đồng bộ (synchronous)
2. process.nextTick queue      ← chỉ có ở Node.js, không có ở browser
3. Microtask queue              ← Promise.then/catch/finally, queueMicrotask
4. Macrotask (1 cái duy nhất)   ← setTimeout, setInterval, setImmediate, I/O, UI render
   → sau đó quay lại bước 2, lặp lại

Chốt lại: mỗi lần chỉ chạy đúng 1 macrotask, nhưng toàn bộ microtask/nextTick queue phải rỗng mới được chạy macrotask tiếp theo.

Làm sao phân biệt cái nào là micro, cái nào là macro

Loại	Ví dụ	Ghi nhớ
nextTick (Node only)	`process.nextTick()`	Ưu tiên tuyệt đối, cao hơn cả Promise
Microtask	`Promise.then/catch/finally`, `queueMicrotask()`, `async/await` (phần sau `await`)	Là “phần việc còn dang dở” — thường gắn với kết quả của 1 tác vụ vừa xong, cần chạy ngay trước khi làm gì khác
Macrotask	`setTimeout`, `setInterval`, `setImmediate` (Node), I/O callback (`fs.readFile`, network), UI event (click, render)	Là “tác vụ mới, độc lập” — đến từ nguồn bên ngoài (timer hệ thống, OS I/O, người dùng thao tác)

Mẹo nhận diện nhanh: tự hỏi “cái này có phải là hệ quả trực tiếp của một Promise/async vừa resolve không?”

Có → microtask
Không, nó đến từ timer/OS/user input → macrotask

Hệ quả thực tế hay gặp (đúng như case runQueue vừa làm): nếu bạn tự đệ quy bằng queueMicrotask hoặc Promise.then liên tục, microtask queue sẽ không bao giờ rỗng → macrotask (timer, UI render, input) bị đói vô thời hạn. Muốn nhường lại quyền kiểm soát cho macrotask, phải dùng setTimeout(fn, 0) (hoặc MessageChannel) — chứ queueMicrotask không giải quyết được vấn đề này.

Những điều cần nhớ.