รีวิว Colly: HTML แบบสแตติก, JSON โดยตรง และขอบเขตของเบราว์เซอร์

ฉันสร้างเว็บไซต์ฟิกซ์เจอร์ขึ้นมาเพื่อทดสอบสิ่งที่การดูจำนวนเพจหรือชื่อเสียงด้านความเร็วของ Colly ตอบไม่ได้ นั่นคือ callback ของมันดึงข้อมูลตามที่คาดไว้หรือไม่, ส่งต่อ HTTP error ได้หรือไม่, ไล่กราฟแบบมีขอบเขตได้หรือไม่, และเข้าถึงเนื้อหาที่ถูกส่งมาอยู่นอก HTML ที่เรนเดอร์แล้วได้หรือไม่ รีวิวนี้จึงเน้นเรื่องความถูกต้องและขอบเขต ไม่ใช่การวัด throughput

บนฟิกซ์เจอร์ที่ควบคุมไว้ มันดึงข้อมูล static ที่คาดไว้ครบทุกชิ้น, ส่ง response 500 หนึ่งรายการไปที่ OnError, และเยี่ยมชม 17 URL ในกราฟที่กำหนด depth ไว้แล้ว มันได้ผลลัพธ์เป็นศูนย์สำหรับสองหน้าที่องค์ประกอบจะปรากฏหลัง JavaScript ทำงานเท่านั้น ส่วน JSON endpoint ที่เข้าถึงได้โดยตรงยังใช้งานได้โดยไม่ต้องใช้เบราว์เซอร์ ซึ่งเป็นประเด็นสำคัญที่ต่างจากการเรนเดอร์หน้าเว็บฝั่งไคลเอนต์

Colly คืออะไรจริง ๆ

Colly เรียกตัวเองว่าเป็น “elegant scraper and crawler framework for Golang” ซึ่งคำนี้มีนัยมากกว่าที่เห็นตอนแรก มันคือ Go library — มีดาวบน GitHub ราว 25,300 ดวง และ fork ประมาณ 1,850 ครั้ง — ภายใต้สัญญาอนุญาต Apache-2.0 ไม่ใช่ CLI ที่ดาวน์โหลดมาแล้วชี้ไปที่ URL ได้ทันที แต่คุณต้องเขียน Go, import Colly, ลงทะเบียน callback ต่าง ๆ แล้วคอมไพล์ออกมาเป็น executable เดียว

แนวคิดการทำงานเป็นแบบ event-driven คุณจะผูก handler เข้ากับ Collector: OnHTML ทำงาน extraction สำหรับ CSS selector ที่ตรงกัน, OnResponse ให้ response body ดิบ, และ OnError จัดการความล้มเหลวของ request ส่วน handler สำหรับลิงก์จะเรียก Visit() บน URL ที่พบ ขณะที่ MaxDepth ใช้จำกัดการไล่ลิงก์ ปลายทางจึงไม่จำเป็นต้องติดตั้ง Go runtime หรือเบราว์เซอร์แยกต่างหากสำหรับเส้นทางแบบ HTTP-only; ส่วน binary จะเป็น static เต็มรูปแบบหรือไม่ขึ้นอยู่กับ build flags และการใช้ CGO ซึ่งการทดสอบครั้งนี้ไม่ได้บันทึกไว้

ฟีเจอร์หลัก และเบื้องหลังการทำงาน

สิ่งสำคัญที่สุดคือ callback model เพราะนี่คือเหตุผลที่ Colly ให้ความรู้สึกต่างจากสคริปต์ที่แค่ request แล้ว parse มี callback สามตัวที่ใช้ขับเคลื่อนทุกการทดสอบของฉัน

OnHTML(selector, handler) คือแรงงานหลัก ถ้าคุณลงทะเบียนกับ .product หรือ article p Colly จะเรียก handler ของคุณหนึ่งครั้งต่อ element ที่ match ขณะ parsing DOM ตรงนี้คือจุดที่ structured extraction เกิดขึ้น และมันอ่านง่าย — คุณกำลังบอกว่าจะเก็บอะไร ไม่ได้เขียนลูป parse เอง

OnResponse(handler) อยู่ระดับล่างลงมาอีกขั้น และให้ข้อมูลเป็น bytes ดิบ เมื่อ target ส่ง JSON กลับมาแทน HTML คุณก็ข้าม DOM ไปเลยแล้ว decode body เอง callback ตัวเดียวนี้เองที่ทำให้ Colly จัดการ JSON API ได้อย่างสะอาดในตอนทดสอบ โดยไม่ต้อง parse HTML เลย

OnError(handler) จัดการความล้มเหลวของ request และสามารถเปิดเผยสถานะ response ให้โค้ดฝั่งผู้เรียกเห็นได้ ในการทดสอบนี้ response ตัวอย่างที่มีสถานะ 500 ถูกส่งมาถึง callback ที่ลงทะเบียนไว้ Retry, timeout, DNS failure, connection reset, callback panic, persistence และ alerting ยังไม่ได้ทดสอบ

เหนือ callback เหล่านี้ยังมีฟีเจอร์เชิงปฏิบัติการอีกสองอย่าง MaxDepth ใช้จำกัดการไล่ลิงก์ตาม semantics ของ depth ใน Colly ส่วน Go executable ที่คอมไพล์แล้วก็หลีกเลี่ยงการต้องติดตั้ง language runtime แยกบนโฮสต์ปลายทาง แต่รอบการรันนี้ไม่ได้บันทึก build flags หรือสถานะ CGO จึงยังสรุปไม่ได้ว่า binary ทุกตัวที่ได้จะ static เต็มรูปแบบ

การตั้งค่า: ต้องมี Go toolchain ก่อน

เรื่อง dependency สั้น ๆ แต่เป็นเรื่องจริง จึงขอพูดก่อนติดตั้งอะไรเพิ่มเติม เครื่องที่ฉันทดสอบไม่มี Go ติดตั้งอยู่ และ Colly เป็น Go library — ดังนั้นขั้นตอนแรกคือการติดตั้ง Go toolchain ลงเครื่อง (ฉันติดตั้ง Go 1.26.5 ผ่าน Homebrew) ถ้าทีมของคุณไม่ได้อยู่บน Go อยู่แล้ว นี่แหละคือแรงเสียดทาน: ไม่ใช่ Colly เอง แต่เป็นสภาพแวดล้อมภาษาโปรแกรมที่ต้องมีมาก่อนจะคอมไพล์ได้แม้แต่บรรทัดเดียว

พอมี Go แล้ว go get github.com/gocolly/colly/v2 ก็แกะออกมาเป็น v2.3.0 เส้นทางที่ทดสอบไม่ต้องใช้เบราว์เซอร์หรือ headless Chrome

มีจุดหนึ่งที่อาจทำให้อ่านสับสนได้ module ของ Go resolve ไปที่ v2.3.0 (เผยแพร่เดือนธันวาคม 2025) ขณะที่รายการล่าสุดที่เห็นในหน้า GitHub Releases คือ v2.2.0 (มีนาคม 2025) ตอนที่ตรวจสอบ ความต่างนี้คือ version บน module/repository เทียบกับรายการ GitHub Release ไม่ใช่ module เทียบกับ Git tag ฉันทดสอบ v2.3.0

ลงมือทดสอบ: การดึงข้อมูลและขอบเขตการทำงาน

ฉันทดสอบ Colly กับเซิร์ฟเวอร์ฟิกซ์เจอร์ที่สร้างขึ้นเอง (Go httptest) รวมถึง demo site สาธารณะสองแห่ง ไดเรกทอรี benchmark ปัจจุบัน และ results/colly-test-summary.json เปิดเผย artifacts ไว้ แต่ลิงก์ทั้งสองอิง branch ที่เปลี่ยนไปได้ บทความนี้ยังไม่ได้ระบุ commit ที่ทดสอบ, command ที่แน่นอน, build flags หรือ seed ของฟิกซ์เจอร์ จึงยังไม่ใช่วิธีทำซ้ำที่คงที่ถาวร

บนฟิกซ์เจอร์ static ที่ควบคุมไว้ selector ที่กำหนดไว้ดึง record สินค้าได้ครบ 12 จาก 12 รายการ และดึงย่อหน้าบทความได้ครบ 3 ย่อหน้าใน 3 ย่อหน้าที่คาดไว้ JSON response โดยตรงไม่แตะ HTML parser เลย: OnResponse ส่ง body มาให้ และ harness ถอดรหัสรายการที่คาดไว้ทั้ง 8 รายการได้ครบ response ฟิกซ์เจอร์ 500 ตัวเดียวไปถึง OnError พร้อมสถานะที่มองเห็นได้ และไม่ทำให้รอบนั้นล้มลง แต่มันยังไม่ใช่หลักฐานของความเชื่อถือได้แบบ unattended ส่วนหน้า Books to Scrape สาธารณะ selector ก็คืนผล 20 products เป็น smoke test บนเว็บไซต์จริง

สำหรับการ traverse collector ถูกตั้งค่า MaxDepth(2) โดยใช้รูปแบบ seed-depth ของ harness และเยี่ยมชม 17 URL ในกราฟฟิกเจอร์ ผลลัพธ์นี้คือ coverage ของการ crawl ไม่ใช่ความเร็ว trace ที่สังเกตได้—ไม่ใช่ข้ออ้างแบบกว้าง ๆ กับกราฟใด ๆ—อยู่ใน results/local_crawl_graph.json

Colly ไม่รัน JavaScript ฟิกซ์เจอร์ที่เรนเดอร์ด้วย JavaScript ให้ผลเป็น 0 target cards และหน้า Quotes to Scrape JS สาธารณะก็ให้ผลเป็น 0 target quotes เช่นกัน ถ้า element มีอยู่หลังจาก browser execute เท่านั้น และไม่มี backing endpoint ที่เข้าถึงได้ส่งข้อมูลมาให้ เส้นทาง HTTP-only ก็จะมองไม่เห็น element เหล่านั้นในฐานะ DOM ที่เรนเดอร์แล้ว ให้ใช้ renderer คู่กัน หรือเรียก backing endpoint โดยตรงเมื่อมีให้ใช้งาน ซึ่งตัวอย่าง JSON ฟิกซ์เจอร์ได้แสดงให้เห็นแล้ว

ฉันไม่ได้ทดสอบ async collector, การตั้งค่า rate limiting หรือ politeness, การสลับ proxy, retries หรือ backend สำหรับ queue และ storage ใด ๆ ไม่ได้วัด elapsed time, throughput, concurrency, CPU, memory, latency ของ target หรือ baseline สำหรับเปรียบเทียบ บทความนี้จึงไม่มีข้อสรุปเรื่องความเร็วหรือความเชื่อถือได้แบบ unattended

วิธีตีความผลลัพธ์จากฟิกซ์เจอร์

เส้นทางเนื้อหาที่สำเร็จทั้งสามแบบทดสอบสัญญาการทำงานคนละมิติ เคสแคตตาล็อกและบทความทดสอบการเลือก CSS บน HTML ที่ส่งกลับจากเซิร์ฟเวอร์ ตัวหารของมันคือสิ่งที่กำหนดไว้ก่อน extraction ได้แก่ product 12 รายการและย่อหน้าบทความ 3 ย่อหน้า การรายงานว่า “ดึงข้อมูลตามที่คาดไว้ครบ” จึงเป็นการตั้งใจ เพราะรอบนี้ไม่ได้กำหนด fuzzy matching, การจัดการข้อมูลซ้ำ, ความทนต่อฟิลด์บางส่วน หรือ metric recall ระดับทั้งคอร์ปัส ดังนั้นผลลัพธ์นี้ไม่ควรถูกยกระดับเป็นความถูกต้องในการดึงข้อมูลแบบทั่วไป

เคส JSON ข้ามการเลือก DOM ไปเลย Colly รับ bytes ของ response ผ่าน OnResponse และ harness เป็นคน decode JSON ดังนั้นคำว่า “Colly ไม่เรนเดอร์ JavaScript” จึงไม่ได้หมายความว่าเว็บไซต์ที่พึ่ง client ทุกเว็บจะใช้ไม่ได้ ถ้าแหล่งข้อมูลที่ client ใช้อยู่คือ endpoint ที่เรียกตรงได้ และ request นั้นทำซ้ำได้โดยไม่ต้องเปิดเบราว์เซอร์ HTTP crawler ก็ยังพอเพียงได้อยู่ การยืนยันตัวตน, signature ที่สร้างขึ้น, state เฉพาะในเบราว์เซอร์ และการป้องกันบอท อาจเปลี่ยนคำตอบนี้ได้ ซึ่งในที่นี้ไม่ได้ทดสอบเลย

เส้นทาง 500 ทดสอบการ dispatch ไม่ใช่การกู้คืน มันแสดงให้เห็นว่า callback OnError ที่ลงทะเบียนไว้ได้รับ response ฟิกซ์เจอร์นั้นพร้อมสถานะแล้ว แต่ crawler ในงานจริงยังต้องมีนโยบายชัดเจนสำหรับ status ที่ retry ได้, backoff, ความล้มเหลวแบบ terminal, persistence และ alerting การทดสอบนี้ไม่ได้ให้หลักฐานสำหรับการตัดสินใจเหล่านั้น และการที่ “callback ถูกเรียก” ไม่ควรถูกอ่านว่า “งานนี้เชื่อถือได้เมื่อปล่อยรันเอง”

กราฟ 17 URL ก็มีขอบเขตแคบเช่นกัน มันยืนยันชุด URL ที่ถูก visit จากฟิกซ์เจอร์นี้, seed convention นี้ และ MaxDepth(2) เท่านั้น ไม่ได้พิสูจน์ pages per second, ความยุติธรรมข้าม host, การเติบโตของ memory หรือพฤติกรรมเมื่อเจอวงวนและ URL ที่มีรูปแบบซ้ำกัน เรื่องเหล่านั้นต้องทดสอบ workload และ queue แยกต่างหาก

เช็กลิสต์สำหรับการเลือกเครื่องมือ จากผลทดสอบนี้

เริ่มจากดู response ที่ Colly ได้รับจริง ๆ ถ้าฟิลด์ที่ต้องการอยู่ใน HTML ที่เซิร์ฟเวอร์ส่งกลับมา ให้ใช้ OnHTML และตรวจนับฟิลด์หรือ keys ที่จำเป็นก่อนยอมรับ record ถ้า response เป็น JSON ให้จัดการ body ผ่าน OnResponse และตรวจ schema ถ้า HTML เป็นเพียง shell ของแอป ให้ดูว่ามี request backing ที่เข้าถึงได้ซึ่งมีข้อมูลอยู่หรือไม่ ก่อนจะเพิ่มเบราว์เซอร์เข้าไป

เมื่อจำเป็นต้องใช้ browser execution ให้มองมันเป็นอีกหนึ่ง component ไม่ใช่คาดหวังว่า flag ของ Colly จะเปิดการเรนเดอร์ได้ Browser ต้องสร้าง readiness, เปิดเผยเนื้อหาที่เรนเดอร์แล้วหรือ response ต้นทาง และส่งข้อมูลเข้าสู่ pipeline ส่วนที่เหลือ การรีวิวนี้ไม่ได้ทดสอบการเชื่อมต่อแบบนั้น

สำหรับการนำไปใช้งานจริง ให้บันทึก Go version, module version, build flags, สถานะ CGO, command ที่แน่นอน, seed ของฟิกซ์เจอร์ และ repository commit รายละเอียดเหล่านี้หายไปจากลิงก์ที่เผยแพร่ตอนนี้ และนี่แหละคือความต่างระหว่าง artifacts ที่ตรวจสอบได้กับ reproduction ที่ยืนยาว สำหรับงานปฏิบัติการ ให้เพิ่ม failure matrix และวัด workload ที่คุณต้องการจริง ๆ ก่อนจะเรียกระบบว่าเร็วหรือเชื่อถือได้

ข้อดีและข้อเสีย

ข้อดี:

• ดึงสินค้าในแคตตาล็อกได้ 12/12 รายการ และย่อหน้าบทความได้ 3/3 ย่อหน้าผ่าน OnHTML
• จัดการ JSON ได้สะอาดผ่าน OnResponse ไม่ต้อง parse DOM — API items ได้ 8/8 รายการ
• response 500 ที่ทดสอบส่งเข้า OnError พร้อมเปิดเผย status
• crawl แบบจำกัด depth เยี่ยมชมได้ 17 หน้า จาก collector ตัวเดียว
• คอมไพล์เป็น Go executable ได้ ปลายทางไม่ต้องติดตั้ง Go runtime แยกสำหรับเส้นทางที่ทดสอบ
• สัญญาอนุญาต Apache-2.0 ใช้งานได้ค่อนข้างเสรี

ข้อเสีย:

• ไม่รัน JavaScript — เนื้อหาที่เรนเดอร์ฝั่งไคลเอนต์ได้ผลเป็น 0 แบบชัดเจน
• ต้องมี Go toolchain; ทีมที่ไม่ใช้ Go ต้องจ่ายต้นทุนการตั้งค่านี้ก่อนเขียน scraper
• module ที่ทดสอบ (v2.3.0) ใหม่กว่ารายการ GitHub Release ล่าสุดที่เห็น (v2.2.0)
• output คือโค้ดของคุณเอง Colly ให้ callback มา ไม่ได้มี built-in dataset/feed exporter แบบ Scrapy
• async, rate limiting, proxy และ queue backend มีอยู่จริงแต่ไม่ได้ทดสอบในที่นี้; throughput และ scale ยังไม่ได้วัด

เหมาะกับใคร — และใครควรข้าม

Colly เหมาะถ้าคุณเขียน Go อยู่แล้ว และเป้าหมายคือ HTML ที่เซิร์ฟเวอร์เรนเดอร์หรือ JSON ที่เข้าถึงได้โดยตรง callback model ช่วยแยก structured match, payload ดิบ และ request failure ออกจากกัน executable ที่คอมไพล์แล้วก็ช่วยหลีกเลี่ยงการต้องติดตั้ง language environment แยกบนเครื่องปลายทาง แม้ว่าในการรีวิวนี้จะยังไม่ได้ยืนยันการ link แบบ fully static

เพิ่ม renderer เมื่อองค์ประกอบเป้าหมายปรากฏหลัง browser execution เท่านั้นและไม่มี backing endpoint ที่ใช้ได้จริงให้เรียกตรงได้ JSON endpoint โดยตรงยังคงเรียกได้โดยไม่ต้องเรนเดอร์ Colly จึงอาจไม่เหมาะกับทีมที่ไม่ต้องการ Go toolchain หรือทีมที่อยากให้บริการ extraction เป็นผู้รับผิดชอบเรื่อง schema shaping และการดูแล selector

ทางเลือกอื่น รวมถึง Thunderbit อยู่ตรงไหน

Colly คือซอฟต์แวร์โอเพนซอร์สที่คุณรันเองได้ ไม่มีค่าบริการจากผู้ขาย แต่ค่า compute, bandwidth, proxy, storage, observability และงานวิศวกรรมยังเป็นต้นทุนของคุณเอง คุณต้องรับผิดชอบพฤติกรรมการ request, callback สำหรับ parsing, logic การ crawl และการเชื่อม browser หาก target ต้องใช้การเรนเดอร์

บริการ extraction แบบ managed จะย้ายความรับผิดชอบบางส่วนเหล่านั้นไปให้ผู้ให้บริการ เราสร้าง Thunderbit ขึ้นมา แต่ไม่ได้ทดสอบกับฟิกซ์เจอร์เหล่านี้ ดังนั้นบทความนี้จึงไม่มีการเปรียบเทียบเรื่อง rendering, anti-bot, quality, latency หรือค่าใช้จ่าย สิ่งที่ต่างกันชัดเจนคือ ownership: Colly เปิดเผย HTTP response และ callback ภายในโปรเซส Go ของคุณ ส่วนบริการแบบ managed อาจเป็นเจ้าของทั้ง acquisition และ schema shaping โดยคิดค่าบริการต่อครั้ง

รีวิว benchmark ที่เกี่ยวข้อง: การเปรียบเทียบ open-source scraper แบบเต็ม, รีวิว crawler Python ของ Scrapy, และ รีวิว selector แบบ adaptive ของ Scrapling

ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บ

บทสรุป

Colly เป็นตัวเลือกที่แข็งแรงสำหรับทีม Go ที่ต้องการดึงข้อมูลจาก HTML ที่เซิร์ฟเวอร์เรนเดอร์หรือ JSON โดยตรง และพร้อมรับผิดชอบโค้ด extraction ของตัวเอง ฟิกซ์เจอร์ที่ทดสอบยืนยันการดึง records ตามที่คาดไว้, trace การ crawl แบบมีขอบเขตหนึ่งชุด, และ callback 500 ที่สังเกตได้หนึ่งครั้ง — ไม่ใช่ความเร็ว, ขนาดสเกล หรือความเชื่อถือได้แบบ unattended DOM ที่เรนเดอร์โดยเบราว์เซอร์ต้องใช้เส้นทางอื่น เว้นแต่ endpoint ข้อมูลเบื้องหลังจะเรียกตรงได้

ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บ Get Started Free

คำถามที่พบบ่อย

รีวิวนี้วัดความเร็วของ Colly หรือไม่? ไม่ รีวิวนี้วัดการดึง record ตามที่คาดไว้, การจัดการ JSON โดยตรง, callback ของ error หนึ่งครั้ง และ coverage ของกราฟ crawl จากฟิกซ์เจอร์เท่านั้น ไม่ได้วัด elapsed time, throughput, concurrency, CPU, memory หรือ baseline สำหรับเปรียบเทียบ

Colly ดึงข้อมูลจากหน้าเว็บที่เรนเดอร์ด้วย JavaScript ได้ไหม? Colly ไม่ execute JavaScript ของหน้า เว็บ เส้นทาง HTTP ที่ทดสอบจึงไม่พบองค์ประกอบเป้าหมายที่มีอยู่เฉพาะใน DOM ที่เรนเดอร์แล้ว อย่างไรก็ตาม มันยังเรียก JSON endpoint ต้นทางที่เข้าถึงได้โดยตรงได้ดังที่ฟิกซ์เจอร์ JSON แสดงไว้ ใช้ renderer เมื่อจำเป็นต้อง execute และไม่มี request ต้นทางที่ทำซ้ำได้ให้ข้อมูลมา

ต้องรู้ Go ไหมถึงจะใช้ Colly ได้? ต้อง Colly เป็น Go library ไม่ใช่ CLI แบบสำเร็จรูป — คุณต้อง import, ลงทะเบียน callback (OnHTML, OnResponse, OnError) และคอมไพล์ เครื่องที่ฉันทดสอบไม่มี Go จึงเริ่มจากการติดตั้ง Go toolchain (1.26.5) ถ้าทีมของคุณยังไม่ได้ใช้ Go อยู่แล้ว นั่นคือ cost จริงของการตั้งค่าสภาพแวดล้อม

ทำไมเวอร์ชันที่ฉันติดตั้งไม่ตรงกับ GitHub release ล่าสุดของ Colly? Go module resolve ไปที่ v2.3.0 (ธันวาคม 2025) ขณะที่รายการ GitHub Release ล่าสุดที่เห็นคือ v2.2.0 (มีนาคม 2025) ฉันทดสอบ v2.3.0; นี่คือความต่างระหว่าง version surface ไม่ใช่หลักฐานว่าการติดตั้งมีปัญหา

Colly ใช้เชิงพาณิชย์ฟรีไหม? ใช่ เป็น Apache-2.0 ซึ่งค่อนข้างผ่อนปรนและเหมาะกับการใช้งานเชิงพาณิชย์เสมอ แต่เพื่อความแน่ใจควรตรวจสอบ license ปัจจุบันบน repo ก่อนนำไปพัฒนาต่อ

ก่อนจะนำไปใช้จริง ควรเพิ่มการทดสอบที่สะท้อนความเสี่ยงในการใช้งานจริง ไม่ใช่แค่ขยายผลจากฟิกซ์เจอร์โดยอนุมาน วัดเวลาของ crawl ซ้ำบน target ที่ใกล้เคียงงานจริง, บันทึก CPU และ peak memory, ทดสอบ failure แบบ retryable และ terminal, และตรวจความสุภาพต่อ target ภายใต้ concurrency หากเรื่อง persistence สำคัญ ให้หยุดแล้วเริ่ม crawl ต่อ พร้อมตรวจการจัดการข้อมูลซ้ำและสถานะของ queue หากความง่ายในการ deploy สำคัญ ให้บันทึก compiler และ linker configuration แบบละเอียด และตรวจ dependency ตอนรันของ executable ที่ได้ การตรวจเหล่านี้ไม่ได้เปลี่ยนสิ่งที่ฟิกซ์เจอร์ปัจจุบันพิสูจน์ไว้ แต่มันเป็นตัวตัดสินว่า configuration เดียวกันนี้เหมาะกับงาน production เฉพาะแบบหรือไม่