Scope และ Closures

var, let และ const

JavaScript มี keyword การประกาศสามแบบ แต่ละแบบมีกฎ scoping ที่แตกต่างกัน:

Keyword	Scope	Hoisted	Reassignable	Re-declarable
var	Function	ใช่ (เป็น undefined)	ใช่	ใช่
let	Block	ใช่ (TDZ)	ใช่	ไม่
const	Block	ใช่ (TDZ)	ไม่	ไม่

Block scope หมายความว่าตัวแปรมีอยู่เฉพาะระหว่างเครื่องหมาย {} ที่ใกล้ที่สุด Function scope หมายความว่าตัวแปรมีอยู่ตลอด function body ไม่ว่า block ด้านในจะเป็นอย่างไร

function example() {
  if (true) {
    var x = 1;   // function-scoped — leaks outside the if
    let y = 2;   // block-scoped — stays inside the if
    const z = 3; // block-scoped
  }
  console.log(x); // 1  — visible here
  console.log(y); // ReferenceError: y is not defined
}

Hoisting

การประกาศตัวแปรถูก hoist — เลื่อนไปที่ด้านบนของ scope โดย engine ก่อนการ execution

การ hoist ของ var จะ initialise ตัวแปรเป็น undefined ทันที ส่วน let/const ถูก hoist แต่อยู่ใน Temporal Dead Zone (TDZ) — การเข้าถึงก่อนบรรทัดที่ประกาศจะ throw ReferenceError

// @expect-throw
console.log(a); // undefined — var is hoisted and initialised
var a = 5;

console.log(b); // ReferenceError — let is in TDZ
let b = 10;

Function declarations ก็ถูก hoist อย่างสมบูรณ์ — สามารถเรียกก่อนบรรทัดที่เขียนได้ แต่ Function expressions (ที่กำหนดให้กับตัวแปร) ไม่ถูก hoist

Lexical scope

Scope ใน JavaScript เป็น lexical (หรือ static): scope ของฟังก์ชันถูกกำหนดโดยตำแหน่งที่เขียนใน source code ไม่ใช่ตำแหน่งที่เรียก ฟังก์ชันด้านในสามารถอ่านตัวแปรจาก scope รอบนอกได้เสมอ

const prefix = 'LOG';

function outer() {
  const level = 'INFO';

  function inner(msg) {
    // inner can read both prefix (module scope) and level (outer scope)
    console.log('[' + prefix + ':' + level + '] ' + msg);
  }

  inner('started');
}

outer(); // [LOG:INFO] started

Closures

Closure คือฟังก์ชันที่เก็บการเข้าถึงตัวแปรของ scope รอบนอกไว้แม้ว่าฟังก์ชันนั้นจะ return ไปแล้ว ฟังก์ชันด้านในไม่ได้คัดลอกค่า — แต่ถือ reference ที่มีชีวิตอยู่ไปยังตัวแปรนั้น

use case คลาสสิกคือ counter factory:

function makeCounter(start) {
  let count = start;

  return {
    increment: function() { count += 1; },
    decrement: function() { count -= 1; },
    value:     function() { return count; },
  };
}

const counter = makeCounter(0);
counter.increment();
counter.increment();
counter.increment();
counter.decrement();
console.log(counter.value()); // 2

count อาศัยอยู่ใน scope ของ makeCounter ทุกฟังก์ชันที่ return จาก makeCounter ถือ reference ไปยัง count ตัวเดียวกัน

Demo Closure ที่รันได้

JavaScriptRun ▸Open in StackBlitz ▸

function makeCounter(start) { let count = start; return { increment: function() { count += 1; }, decrement: function() { count -= 1; }, value: function() { return count; }, }; } const c1 = makeCounter(0); const c2 = makeCounter(100); c1.increment(); c1.increment(); c1.increment(); c2.decrement(); console.log('c1:', c1.value()); // 3 console.log('c2:', c2.value()); // 99 console.log('counters are independent:', c1.value() !== c2.value());

สังเกตว่า c1 และ c2 เป็นอิสระจากกันอย่างสมบูรณ์ — การเรียก makeCounter แต่ละครั้งสร้างตัวแปร count ใหม่ใน scope ใหม่ และแต่ละ object ที่ return กลับมาจะ close over ตัวแปรของตัวเอง

🟢 Closures capture variables, not values

ฟังก์ชันด้านในถือ reference ที่มีชีวิตอยู่ไปยังตัวแปรภายนอก หากตัวแปรนั้นเปลี่ยนแปลงหลังจากสร้าง closure แล้ว closure จะเห็นค่าใหม่ นี่คือสาเหตุที่ bug loop ของ var แบบคลาสสิกให้ผลลัพธ์ที่ไม่คาดคิด — callback ทุกตัว close over ตัวแปร i เดียวกัน ซึ่งเพิ่มไปยังค่าสุดท้ายแล้วเมื่อ callback ใดๆ รัน ใช้ let ใน loops เพื่อสร้าง binding ใหม่ต่อ iteration

Bug loop closure ของ var

นี่คือ closure bug ที่ถูกทำซ้ำมากที่สุด: var เป็น function-scoped ดังนั้น loop for ที่ใช้ var จะมี i แค่ ตัวเดียว ที่แชร์กันทุก iteration พอถึงเวลาที่ callback ที่ถูก defer ไว้ทำงานจริง loop ก็จบไปแล้วและ i ถือค่าสุดท้ายอยู่ — callback ทุกตัวเห็นตัวเลขผิดตัวเดียวกัน let แก้ปัญหานี้เพราะ loop จะสร้าง binding ของ i ใหม่ทุก iteration และแต่ละ callback close over copy ของตัวเอง

flowchart TD
  subgraph var loop - one binding
    V0["i (shared)"] --> V1["callback 0 reads i"]
    V0 --> V2["callback 1 reads i"]
    V0 --> V3["callback 2 reads i"]
    V4["loop finishes: i = 3"] --> V0
  end
  subgraph let loop - one binding per iteration
    L0["i = 0"] --> L1["callback 0 reads i = 0"]
    L2["i = 1"] --> L3["callback 1 reads i = 1"]
    L4["i = 2"] --> L5["callback 2 reads i = 2"]
  end

var: binding เดียวที่แชร์กันตลอดทั้ง loop — let: binding ใหม่ทุก iteration

JavaScriptRun ▸Open in StackBlitz ▸

console.log('--- var: shared binding ---'); const varCallbacks = []; for (var i = 0; i < 3; i++) { varCallbacks.push(function() { return i; }); } console.log(varCallbacks.map(function(fn) { return fn(); })); // [3, 3, 3] console.log('--- let: fresh binding per iteration ---'); const letCallbacks = []; for (let j = 0; j < 3; j++) { letCallbacks.push(function() { return j; }); } console.log(letCallbacks.map(function(fn) { return fn(); })); // [0, 1, 2]

bug เดียวกันนี้กัดแรงที่สุดกับ callback แบบ async จริง (setTimeout, promise .then(), event listener) เพราะพอถึงเวลาที่ callback ตัวไหนก็ตาม ทำงาน loop จบไปแล้วเสมอ — ไม่มี var loop ตัวไหน “เร็วพอ” ที่จะหลีกเลี่ยง bug นี้ได้

การ dispose อัตโนมัติ: using และ Symbol.dispose

Node 24 เพิ่ม using (และ await using) declaration: resource ที่มี method [Symbol.dispose]() (หรือ [Symbol.asyncDispose]()) จะถูก dispose อัตโนมัติทันทีที่ block ที่ครอบมันจบลง — ทั้งตอน return ปกติ และ ตอนที่มี error ถูก throw — โดยไม่ต้องมี try/finally ด้วยมือ นี่คือ block scope ที่ถูกนำมาใช้ทำ resource cleanup: using binding มี scope เหมือน let ทุกประการ และการ dispose เกิดขึ้นตรงจุดที่ scope ของ block นั้นจบลง

Node.jsOpen in StackBlitz ▸

function makeResource(name) { return { name, [Symbol.dispose]() { console.log('disposed:', name); }, }; } console.log('--- normal exit ---'); { using r1 = makeResource('r1'); console.log('using r1:', r1.name); } // r1[Symbol.dispose]() runs here automatically console.log('after block'); console.log('--- exit via throw ---'); try { using r2 = makeResource('r2'); throw new Error('boom'); } catch (e) { console.log('caught:', e.message); } // r2 was disposed BEFORE the catch block ran, as the throw unwound the scope

Output (verified on Node 24)

--- normal exit ---
using r1: r1
disposed: r1
after block
--- exit via throw ---
disposed: r2
caught: boom

ก่อนมี using การรับประกันแบบเดียวกันนี้ต้องใช้ try/finally ด้วยมือรอบ resource ทุกตัว — ลืมง่าย และผิดพลาดง่ายเมื่อฟังก์ชันหนึ่งมี resource มากกว่าหนึ่งตัวที่ต้อง release

Mental Model

{ } block ทุกอันที่ประกาศ let, const หรือ using คือ scope ใหม่ — ให้นึกภาพ loop ที่ใช้ let เป็นการสร้าง stack frame ใหม่ทุก iteration แต่ละอันมี i ของตัวเอง แทนที่จะเป็นกล่องเดียวที่ทุก iteration เขียนทับกัน var ไม่ได้รับการปฏิบัติแบบนี้เลย — มันเขียนลงใน binding เดียวที่เป็นของฟังก์ชันที่ครอบใกล้ที่สุดเสมอ (หรือ module ถ้าไม่มีฟังก์ชัน) using ใช้แนวคิด “block สร้าง lifetime ของตัวเอง” แบบเดียวกัน แต่ผูกการ dispose — ไม่ใช่แค่ lifetime ของตัวแปร — เข้ากับตอนที่ scope ของ block จบลง

Trade-offs

Choice	Benefit	Cost
var	คุ้นเคยสำหรับคนที่มาจาก JS รุ่นเก่า; hoist ไปบนสุดของฟังก์ชัน	Function-scoped, re-declare ได้ และแชร์ binding เดียวตลอดทุก loop iteration — ต้นเหตุของ closure bug คลาสสิก
let/const ใน loops	binding ที่ถูกต้องและเป็นอิสระต่อ iteration; TDZ จับ use-before-declare ได้	allocation เยอะกว่า var ตัวเดียวเล็กน้อย (ไม่มีผลจริงในทางปฏิบัติ)
Manual try/finally cleanup	ใช้ได้กับ JS ทุกเวอร์ชัน ไม่มี syntax ใหม่	ยืดยาวเมื่อมีหลาย resource; ลืมง่ายใน code path หนึ่ง
using/await using	รับประกันการ dispose ทุก exit path (return, throw, break) โดยไม่มี boilerplate	รองรับแค่ Node 24+ / browser ล่าสุดมากๆ; resource ต้อง implement Symbol.dispose/Symbol.asyncDispose

Common Misconceptions

• “Closure copy ค่าของตัวแปรที่มัน capture” มัน capture live reference ต่างหาก ถ้าตัวแปรเปลี่ยนทีหลัง closure ทุกตัวที่อ้างถึงมันจะเห็นค่าใหม่ — นี่คือสาเหตุที่แท้จริงของ bug loop ของ var
• “ใช้ let แทน var เป็นแค่เรื่อง style” ใน loop ที่มี callback แบบ defer มันคือการแก้ correctness ไม่ใช่แค่ style — var ทำให้เกิด bug จริงที่ reproduce ได้เสมอ
• “using เป็นแค่ try/finally ที่หรูขึ้น” มันมากกว่า syntax sugar: มันให้แต่ละ resource ประกาศ cleanup ของตัวเองตรงจุดที่มันถูกสร้าง ทำให้ cleanup ของหลาย resource อ่านจากบนลงล่างแทนที่จะซ้อน finally และมันรัน dispose ตามลำดับย้อนกลับของการประกาศให้อัตโนมัติ

Reading AI-generated code

โค้ดที่ AI สร้างซึ่ง push callback (setTimeout, callback ของ array method ที่เก็บไว้ใช้ทีหลัง, event listener ที่ลงทะเบียนเป็นชุด) ไว้ใน loop for ที่ประกาศด้วย var เป็นหนึ่งใน bug ที่พบบ่อยและ review ยากที่สุด เพราะ loop รันถูกต้องและ bug จะโผล่ก็ต่อเมื่อ callback ที่ defer ไว้ทำงานจริงเท่านั้น — มักอยู่ห่างจาก loop มากในไฟล์หรือใน stack trace

🐛 หา bug ในโค้ดนี้

function scheduleGreetings(names) {
for (var i = 0; i < names.length; i++) {
  setTimeout(function() {
    console.log('Hello, ' + names[i]);
  }, 100);
}
}

scheduleGreetings(['Alice', 'Bob', 'Carol']);

เฉลย

var i เป็น function-scoped ดังนั้นมี i แค่ตัวเดียวที่แชร์กันทั้งสาม setTimeout callback พอถึงเวลาที่ timer ตัวแรกทำงาน (100 ms ต่อมา) loop จบไปแล้วและ i เป็น 3 — callback ทุกตัวอ่าน names[3] ซึ่งเป็น undefined พิมพ์ “Hello, undefined” สามครั้งแทนที่จะทักทายแต่ละชื่อครั้งเดียว วิธีแก้คือเปลี่ยนแค่ตัวอักษรเดียว: for (let i = ...) let สร้าง i binding ใหม่และเป็นอิสระให้แต่ละ iteration ดังนั้นแต่ละ callback close over ค่าของตัวเอง

🟢 สรุปหนึ่งบรรทัด

var ให้ loop มี binding เดียวที่แชร์กัน ดังนั้น callback ที่ defer ไว้ทุกตัวเห็นค่าสุดท้ายของ loop; let สร้าง binding ใหม่ต่อ iteration ซึ่งเป็นเหตุผลที่มันเป็น default ที่ถูกต้องสำหรับตัวแปร loop ตัวไหนก็ตามที่ callback อาจ capture ไว้

ความแตกต่างหลักระหว่าง let และ var ในเรื่อง scope คืออะไร?

let เป็น function-scoped; var เป็น block-scoped let เป็น block-scoped; var เป็น function-scoped ทั้งคู่เป็น block-scoped แต่ var อนุญาตการ reassignment ไม่มีความแตกต่าง — ทำงานเหมือนกันทุกประการภายในฟังก์ชัน

Closure คืออะไร?

วิธีทำให้ตัวแปร private โดยห่อด้วย IIFE ฟังก์ชันที่ capture และเก็บการเข้าถึงตัวแปรจาก scope รอบนอก method ที่ปิด file descriptor หลังการใช้งาน pattern สำหรับป้องกัน memory leaks ใน loops

เกิดอะไรขึ้นเมื่อเข้าถึงตัวแปร let ก่อนบรรทัดที่ประกาศ?

ได้ undefined — เหมือนกับ var ได้ null throw ReferenceError — let อยู่ใน Temporal Dead Zone engine hoist และ initialise เป็น 0

โค้ดนี้พิมพ์อะไร?

const fns = [];
for (var i = 0; i < 3; i++) {
  fns.push(function() { return i; });
}
console.log(fns.map(function(fn) { return fn(); }));

[0, 1, 2] [3, 3, 3] [undefined, undefined, undefined] ReferenceError

โค้ดนี้พิมพ์อะไร และวิธีแก้ที่น้อยที่สุดคืออะไร?

function scheduleGreetings(names) {
  for (var i = 0; i < names.length; i++) {
    setTimeout(function() {
      console.log(names[i]);
    }, 0);
  }
}
scheduleGreetings(['Alice', 'Bob']);

Alice แล้วตามด้วย Bob — โค้ดถูกต้องอยู่แล้ว undefined สองครั้ง — เปลี่ยน var เป็น let ใน for statement TypeError — names เข้าถึงไม่ได้ภายใน setTimeout Alice แล้วตามด้วย Bob แต่สลับลำดับแบบสุ่ม

Submit

Mark as complete