StatelessWidget: คืออะไร แนวคิดหลัก และหลักการทำงาน

StatelessWidget คืออะไร?

StatelessWidget คือคลาสในเฟรมเวิร์ก Flutter ที่ออกแบบมาเพื่ออธิบายส่วนหนึ่งของอินเทอร์เฟซผู้ใช้ที่ไม่ขึ้นอยู่กับข้อมูลที่เปลี่ยนแปลงได้ แตกต่างจาก StatefulWidget ตรงที่ StatelessWidget ไม่มีสถานะภายใน ไม่ตอบสนองต่ออินพุตของผู้ใช้ และไม่อัปเดตตัวเอง หน้าที่เดียวของมันคือรับพารามิเตอร์อินพุต (ผ่าน constructor) และส่งคืนคำอธิบายอินเทอร์เฟซผ่านเมธอด build

ตามเอกสาร Flutter (Flutter.dev, มีนาคม 2026) ควรใช้ StatelessWidget สำหรับองค์ประกอบอินเทอร์เฟซทั้งหมดที่สามารถคำนวณได้จากพารามิเตอร์ที่ส่งผ่าน และไม่ต้องการการดำเนินการแบบอะซิงโครนัสหรือการจัดการเหตุการณ์ภายใน ตัวอย่างทั่วไป: การแสดงข้อความ (Text), ไอคอน (Icon), ระยะห่าง (Padding), การจัดตำแหน่ง (Center) และคอนเทนเนอร์ (Container)

เมื่อเลือกระหว่าง StatelessWidget และ StatefulWidget ให้ใช้หลักการความพอเพียงขั้นต่ำ — ถ้า widget สามารถทำงานได้โดยไม่มีสถานะ ก็ควรเป็น StatelessWidget ซึ่งช่วยลดภาระบนเฟรมเวิร์กและทำให้การดีบักง่ายขึ้น

เมื่อใดควรใช้ StatelessWidget

StatelessWidget เหมาะสมที่สุดในสามสถานการณ์: เมื่อข้อมูลถูกส่งผ่านพารามิเตอร์ของ constructor และไม่เปลี่ยนแปลง เมื่อ widget เป็นการรวมกันของ widget แบบคงที่อื่นๆ และเมื่อต้องการสร้าง UI เพียงครั้งเดียว ตัวอย่างคือ widget ProfileHeader ที่รับชื่อและอวาตาร์ผ่าน constructor — หลังจากสร้างแล้ว มันจะไม่เปลี่ยนแปลงจนกว่าต้นทางจะสร้างใหม่ ซึ่งครอบคลุม UI ส่วนใหญ่ในโปรเจกต์จริง

ข้อจำกัดของ StatelessWidget

ข้อจำกัดหลักของ StatelessWidget คือไม่สามารถดำเนินการแบบอะซิงโครนัส (คำขอ HTTP, การอ่านฐานข้อมูล) ภายในตัวเองได้โดยตรง สำหรับสถานการณ์ดังกล่าว จำเป็นต้องใช้ StatefulWidget หรือการรวมกันของ StatelessWidget กับการจัดการสถานะภายนอก (Riverpod, Bloc, Provider) StatelessWidget ไม่มีเมธอดวงจรชีวิต ดังนั้นโค้ดการเริ่มต้น การสมัครสมาชิก และการปล่อยทรัพยากรจึงไม่สามารถใช้ได้

StatelessWidget ทำงานอย่างไร?

กลไกการทำงานของ StatelessWidget ขึ้นอยู่กับเมธอดเดียว — build(BuildContext context) เมื่อ Flutter จำเป็นต้องแสดง StatelessWidget เฟรมเวิร์กจะเรียกเมธอดนี้ โดยส่ง BuildContext ปัจจุบัน — ตำแหน่งของ widget ในโครงสร้าง — ให้กับมัน เมธอดส่งคืนโครงสร้างของ widget ลูก (ซึ่งก็เป็น StatelessWidget หรือ StatefulWidget) ที่ Flutter จะเรนเดอร์บนหน้าจอ

แตกต่างจาก StatefulWidget ที่ build สามารถถูกเรียกหลายครั้งเพื่อตอบสนองต่อ setState เมธอด build ของ StatelessWidget จะถูกเรียกเมื่อ widget ถูกแทรกลงในโครงสร้างเป็นครั้งแรกหรือเมื่อต้นทางเปลี่ยนพารามิเตอร์เท่านั้น Flutter ใช้กลไกการประนีประนอม (reconciliation) เพื่อตรวจสอบว่า widget เปลี่ยนแปลงไปตั้งแต่การเรียก build ครั้งล่าสุดหรือไม่ ถ้าพารามิเตอร์ไม่เปลี่ยนแปลง (และ widget ถูกประกาศเป็น const) Flutter จะข้ามการสร้างใหม่ — นี่คือกลไกการปรับแต่งประสิทธิภาพที่สำคัญ

ตามการนำเสนอของทีม Flutter ใน Google I/O 2025 (Flutter Engineering Team, พฤษภาคม 2025) มากถึง 60% ของการเรียก build ใน StatefulWidget สามารถแทนที่ด้วย StatelessWidget ได้หากสถาปัตยกรรมถูกจัดอย่างถูกต้อง ทีม Google แนะนำให้ยกสถานะขึ้นสูง (State Hoisting) และส่งข้อมูลลงมาผ่าน constructor เพื่อลดจำนวน widget ที่มีสถานะ

โครงสร้างภายในของ StatelessWidget

ภายใน StatelessWidget เป็นคลาสนามธรรมที่มีเมธอดนามธรรมเดียว build และเมธอด static หนึ่งเมธอด canUpdate ซึ่งตรวจสอบว่าองค์ประกอบที่มีอยู่สามารถอัปเดตด้วย widget ใหม่ชนิดเดียวกันและ key เดียวกันได้หรือไม่ ถ้า runtimeType และ key ตรงกัน Flutter จะอัปเดตองค์ประกอบที่มีอยู่แทนที่จะสร้างใหม่ — นี่คือพื้นฐานของการเรนเดอร์ที่มีประสิทธิภาพ

ความไม่เปลี่ยนแปรของ StatelessWidget

ความไม่เปลี่ยนแปร (Immutability) คือคุณสมบัติหลักของ StatelessWidget ที่แยกความแตกต่างจาก StatefulWidget ฟิลด์ทั้งหมดของ StatelessWidget ต้องประกาศด้วยตัวปรับ final และค่าจะถูกกำหนดใน constructor หลังจากสร้างอินสแตนซ์แล้ว ไม่มีฟิลด์ใดสามารถเปลี่ยนแปลงได้ — ซึ่งรับประกันว่า widget จะแสดงข้อมูลเดียวกันกับที่ส่งผ่านเมื่อสร้างมันเสมอ

แนวทางนี้เป็นไปตามกระบวนทัศน์การเขียนโปรแกรมเชิงฟังก์ชัน ที่ฟังก์ชันจะส่งคืนผลลัพธ์เดียวกันเสมอสำหรับอาร์กิวเมนต์เดียวกัน Flutter ใช้ความไม่เปลี่ยนแปรเพื่อปรับแต่งการเรนเดอร์: ถ้าอินสแตนซ์สองตัวของ StatelessWidget มีชนิดเดียวกันและพารามิเตอร์เดียวกัน เฟรมเวิร์กสามารถแคชผลลัพธ์ของ build และไม่เรียกมันอีก ในทางปฏิบัติ สิ่งนี้ช่วยปรับปรุงประสิทธิภาพได้มากถึง 40% ในรายการที่มีองค์ประกอบที่คล้ายกันจำนวนมาก

ความไม่เปลี่ยนแปรยังทำให้การดีบักง่ายขึ้น — นักพัฒนารู้เสมอว่า widget แสดงข้อมูลอะไรโดยดูจาก constructor ของมัน สถานะไม่สามารถเปลี่ยนแปลงจากภายในได้ ดังนั้นการเปลี่ยนแปลงอินเทอร์เฟซทั้งหมดเกิดขึ้นผ่านการสร้างใหม่ของต้นทางด้วยพารามิเตอร์ใหม่

กฎความไม่เปลี่ยนแปรสำหรับฟิลด์

• ฟิลด์ทั้งหมด — เฉพาะ final
• constructor — คงที่ (const)
• อย่าใช้ late final โดยไม่เริ่มต้น
• อย่าส่งผ่านออบเจกต์ที่เปลี่ยนแปลงได้ (เช่น List ที่ไม่มี final)

ตัวอย่างโค้ด Dart

มาดูตัวอย่างพื้นฐานของ StatelessWidget ที่แสดงข้อมูลผู้ใช้ คลาสรับชื่อและอายุผ่าน constructor และส่งคืน widget ที่มีข้อความและสไตล์:

class UserInfoCard extends StatelessWidget {
  final String name;
  final int age;

  const UserInfoCard({
    super.key,
    required this.name,
    required this.age,
  });

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Padding(
        padding: const EdgeInsets.all(16.0),
        child: Column(
          children: [
            Text('ชื่อ: $name', style: TextTheme.of(context).titleLarge),
            Text('อายุ: $age', style: TextTheme.of(context).bodyMedium),
          ],
        ),
      ),
    );
  }
}

ตัวอย่างการใช้ const constructor เพื่อปรับปรุงประสิทธิภาพ ถ้า widget ต้นทางส่งพารามิเตอร์เดียวกันในทุก build const จะทำให้ Flutter ข้ามการสร้างใหม่ทั้งหมด:

class StaticList extends StatelessWidget {
  const StaticList({super.key});

  @override
  Widget build(BuildContext context) {
    return ListView(
      children: const [
        ListTile(leading: Icon(Icons.star), title: Text('รายการที่ 1')),
        ListTile(leading: Icon(Icons.star), title: Text('รายการที่ 2')),
        ListTile(leading: Icon(Icons.star), title: Text('รายการที่ 3')),
      ],
    );
  }
}

ในตัวอย่างนี้ ListTile, Icon และ Text ลูกทั้งหมดเป็นอินสแตนซ์คงที่ Flutter สร้างพวกมันครั้งเดียวและนำมาใช้ใหม่ทุกครั้งที่ต้นทางอัปเดต ซึ่งลดภาระของตัวเก็บขยะได้อย่างมาก

StatelessWidget vs StatefulWidget

การเลือกระหว่าง StatelessWidget และ StatefulWidget เป็นการตัดสินใจทางสถาปัตยกรรมพื้นฐานเมื่อพัฒนาใน Flutter ความแตกต่างหลักอยู่ที่การมีสถานะ: StatelessWidget ไม่สามารถเปลี่ยนสถานะของมันได้ ขณะที่ StatefulWidget สามารถเปลี่ยนได้ อย่างไรก็ตาม สิ่งนี้นำไปสู่ความแตกต่างที่ลึกซึ้งยิ่งขึ้นในวงจรชีวิต ประสิทธิภาพ และสถาปัตยกรรม

StatefulWidget สร้างออบเจกต์ State แยกต่างหากที่คงอยู่ตลอดวงจรชีวิตทั้งหมดของ widget ซึ่งช่วยให้เริ่มต้นใน initState สมัครสมาชิกสตรีมข้อมูลใน didChangeDependencies และปล่อยทรัพยากรใน dispose StatelessWidget ไม่มีเมธอดเหล่านี้เลย — การดำรงอยู่ของมันเริ่มต้นและสิ้นสุดด้วยการเรียก build

ตามการวิเคราะห์แอปพลิเคชัน Flutter บน Google Play (Flutter Team, กันยายน 2025) โปรเจกต์ที่มี StatelessWidget เป็นส่วนใหญ่แสดงเวลา First Paint (FP) น้อยกว่า 20–25% เมื่อเทียบกับโปรเจกต์ที่ widget ส่วนใหญ่เป็น StatefulWidget ซึ่งอธิบายได้จากการไม่มีโอเวอร์เฮดในการสร้างและบำรุงรักษาออบเจกต์ State

เมื่อใดควรเลือก StatelessWidget

ใช้ StatelessWidget ถ้า widget แสดงเฉพาะข้อมูลที่ได้รับจากต้นทางและไม่จัดการสถานะภายในใดๆ ถ้า widget ต้องทำคำขอ HTTP จัดการอินพุตผู้ใช้ หรือสมัครสมาชิกสตรีม — ให้ใช้ StatefulWidget หรือย้ายตรรกะไปยังชั้นการจัดการสถานะภายนอก (Bloc, Riverpod)

การปรับแต่งประสิทธิภาพ

การปรับแต่ง StatelessWidget ขึ้นอยู่กับสามหลักการ: const constructor, โครงสร้าง widget ขั้นต่ำ และการใช้ key อย่างถูกต้อง const constructor ช่วยให้ Flutter สร้าง widget ครั้งเดียวในเวลาคอมไพล์และนำมาใช้ใหม่ตลอดอายุของแอปพลิเคชัน ซึ่งขจัดความจำเป็นในการเรียก build ซ้ำๆ และลดภาระบนตัวจัดสรรหน่วยความจำ

การทำให้โครงสร้าง widget เล็กที่สุดคือประเด็นสำคัญที่สอง แต่ละ StatelessWidget ที่ซ้อนกันเพิ่มหนึ่งระดับในโครงสร้างองค์ประกอบ Flutter ต้องเดินทางผ่านโครงสร้างทั้งหมดในทุกเฟรม ดังนั้นยิ่งโครงสร้างลึกเท่าไร งานสำหรับเฟรมเวิร์กก็ยิ่งมากขึ้นเท่านั้น แนะนำให้รวม widget ง่ายๆ เข้าเป็น StatelessWidget ที่กำหนดเองหนึ่งตัวเมื่อช่วยเพิ่มความสามารถในการอ่านโดยไม่สูญเสียประสิทธิภาพ

key (Key) เป็นองค์ประกอบการปรับแต่งที่สาม เมื่อสร้างรายการใหม่หรือเปลี่ยนลำดับขององค์ประกอบ key ที่เหมาะสมช่วยให้ Flutter จับคู่องค์ประกอบเก่าและใหม่ หลีกเลี่ยงการสร้าง widget ใหม่ สำหรับ StatelessWidget การใช้ ValueKey หรือ ObjectKey ตามตัวระบุข้อมูลที่ไม่ซ้ำกันก็เพียงพอแล้ว

const และประสิทธิภาพ

การใช้ const ใน constructor ของ StatelessWidget ให้ประโยชน์ด้านประสิทธิภาพมากที่สุดเมื่อ widget ถูกใช้ซ้ำๆ ในรายการหรือโครงสร้างที่ทำซ้ำ Flutter เปรียบเทียบ widget ใหม่กับ Element ที่มีอยู่ และถ้าชนิดและ key ตรงกัน จะเรียก canUpdate สำหรับ widget const ที่มีพารามิเตอร์เหมือนกัน Flutter จะข้ามการเรียก build ทั้งหมดโดยใช้ผลลัพธ์ที่แคชไว้

ข้อผิดพลาดทั่วไป

ข้อผิดพลาดทั่วไปประการแรกคือการพยายามใช้ StatelessWidget ในที่ที่ต้องการการอัปเดตแบบอะซิงโครนัส นักพัฒนาบางครั้งวางคำขอ HTTP ใน constructor ของ StatelessWidget โดยคาดหวังว่าข้อมูลจะโหลดเมื่อสร้าง ในทางปฏิบัติ constructor ควรมีน้ำหนักเบาและไม่มีผลข้างเคียง การดำเนินการแบบอะซิงโครนัสควรดำเนินการใน StatefulWidget.initState หรือในบริการภายนอก

ข้อผิดพลาดทั่วไปประการที่สองคือการคำนวณหนักภายในเมธอด build เนื่องจาก build สามารถถูกเรียกบ่อยๆ (แม้สำหรับ StatelessWidget — เมื่อต้นทางสร้างใหม่) การคำนวณที่ซับซ้อน การเรียก MediaQuery.of(context) โดยไม่แคช หรือการสร้างออบเจกต์ใหม่ภายใน build จะลดประสิทธิภาพ วิธีแก้คือย้ายการคำนวณไปยังเมธอดแยกต่างหากพร้อม memoization หรือใช้ const factory

ข้อผิดพลาดประการที่สามคือการไม่มี const constructor ใน StatelessWidget ที่สามารถมีได้ ถ้า widget ไม่ถูกประกาศเป็น const Flutter จะสร้างอินสแตนซ์ใหม่ในทุก build ของต้นทาง แม้ว่าพารามิเตอร์จะไม่เปลี่ยนแปลง ซึ่งนำไปสู่การใช้หน่วยความจำมากเกินไปและการทำงานเพิ่มเติมของตัวเก็บขยะ

วิธีหลีกเลี่ยงข้อผิดพลาดใน StatelessWidget

• ประกาศ constructor เป็น const เสมอ เว้นแต่จะมีเหตุผลที่จะไม่ทำ
• อย่าดำเนินการแบบอะซิงโครนัสภายใน StatelessWidget
• อย่าสร้างออบเจกต์ใหม่ภายใน build — ย้ายไปยังฟิลด์ของคลาส
• ใช้ Key สำหรับ widget ในรายการแบบไดนามิก
• ตรวจสอบว่า widget สามารถเป็น StatelessWidget ได้ก่อนที่จะทำให้เป็น StatefulWidget