รีวิว Botasaurus: ไดรเวอร์ขนาด 4 MB, ติดตั้งจริง 122 MB และตัวเลข 0.08 ms ที่ไม่ควรเอาไปอ้าง

Botasaurus คือเฟรมเวิร์กสำหรับทำเว็บสคราปิงด้วย Python จาก Omkar Cloud ที่วางตัวเองเป็นชุดเครื่องมือครบวงจรสำหรับสร้างสคราเปอร์ คุณเขียนฟังก์ชันธรรมดา แล้วค่อยใส่ @browser, @request หรือ @task เข้าไป จากนั้นเฟรมเวิร์กจะจัดการทั้งไดรเวอร์เบราว์เซอร์ ไคลเอนต์ HTTP ที่ทำตัวเหมือนเบราว์เซอร์ ระบบแคช การรันแบบขนาน และการส่งออกข้อมูลหลายรูปแบบให้ครบ เป็นแนว meta-package ซึ่งตรงนี้แหละที่สำคัญ: pip install botasaurus ไม่ได้แค่ติดตั้งไลบรารีหนึ่งตัวลงในสภาพแวดล้อมของคุณ แต่มันลากเอาแพ็กเกจของตัวเองหลายตัว รวมถึง dependency แบบลูกโซ่อีกยาว เหตุผลเชิงกลไกนี้คือสิ่งที่ผมวัดได้อย่างตรงไปตรงมาและน่าสนใจที่สุด

Botasaurus ทำการตลาดเรื่องการหลบการตรวจจับอย่างชัดเจน และนั่นคือประเด็นที่รีวิวนี้จะไม่แตะเลย ผมสำรวจแค่ตัวเฟรมเวิร์ก — มีอะไรถูกติดตั้งบ้าง import อะไรได้บ้าง มีเมธอดอะไรอยู่ ขนาดเท่าไร และใช้ไลเซนส์อะไร — แทนที่จะเอาไปชนกับระบบป้องกันจริงที่ออนไลน์อยู่ ทุกตัวเลขด้านล่างมาจาก pip, จาก python -c "import ..." และจากการ introspect คลาสที่ถูกสร้างขึ้นมาแต่ไม่เคยถูกสั่งให้ดึงหน้าเว็บใด ๆ; ไม่มีการเปิดเบราว์เซอร์เพื่อผลิตค่าพวกนี้ ภายหลังผมเปิดเบราว์เซอร์จริง แต่ก็เฉพาะหน้าเว็บที่ผมเขียนและรันเองบน 127.0.0.1 เพื่อดูว่าไดรเวอร์บอกอะไรเกี่ยวกับตัวมันเอง และมันดึงเนื้อหาจากหน้าที่สร้างด้วย JavaScript ได้หรือไม่ ไม่ได้เกี่ยวข้องกับเว็บไซต์จริง ไม่มีการติดต่อกับบริการกันบอท และไม่มี CAPTCHA ใดถูกแตะต้อง ความสามารถในการสู้กับเว็บจริงจึงอยู่นอกขอบเขตตั้งแต่ต้น และผมอยากบอกตรงนี้ตั้งแต่แรก มากกว่าจะทำเหมือนว่ามีการรัน benchmark ที่จริง ๆ ไม่ได้รัน

เมื่อวางขอบเขตไว้แบบนั้น ประเด็นหลักของเรื่องนี้จึงกลายเป็น footprint ซึ่งข่าวดีก็คือมันไม่ได้เลวอะไรเลย การติดตั้งแบบสะอาดจะสร้างไดเรกทอรี site-packages ขนาด 122.3 MB ครอบคลุม 44 แพ็กเกจ บนเครื่องที่ไดรเวอร์เบราว์เซอร์ซึ่งอยู่แกนกลางของระบบมีขนาดราว 4 MB ดังนั้นตัวเฟรมเวิร์กไม่ได้หนักเพราะไดรเวอร์ใหญ่ แต่หนักเพราะคำว่า "ครบเครื่อง" หมายถึงมันพา numpy, lxml, gevent และอีกเป็นโหลติดมาด้วยเพื่อทำงานแค่การดึง HTML และอีกครึ่งหนึ่งของข้อสรุปคือเลขที่คนชอบเอาไปอ้างว่าเบามาก ทั้งที่ไม่ควรเชื่อ: import botasaurus ใช้เวลาแค่ 0.08 ms ซึ่งฟังดูเหมือนเฟรมเวิร์กที่เบาหวิว แต่จริง ๆ แล้วมันก็แค่ประตูหน้าที่แทบว่างเปล่า

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

Botasaurus — omkarcloud/botasaurus บน GitHub ซึ่งตอนที่ผมดึงเมตาดาต้าเมื่อ 14 กรกฎาคม 2026 มี 5,561 stars, 486 forks และ 58 issues ที่ยังเปิดอยู่ — เป็นเฟรมเวิร์กสำหรับ Python ไม่ใช่ไลบรารีแบบทำงานจุดเดียว เวอร์ชันที่ผมทดสอบคือ botasaurus 4.0.97 สำหรับ meta-package และ botasaurus-driver 4.0.92 สำหรับเอนจินข้างใต้ ตัว meta-package ระบุ requires-python >=3.7 (ส่วน driver คือ >=3.5) และตัว classifier บน PyPI อ้างรองรับแค่ถึง Python 3.11 แต่บนเครื่องผมมันติดตั้งและผ่านการทดสอบ import แบบพื้นฐานบน Python 3.14.2 ได้ นี่คือหลักฐานเฉพาะการติดตั้งครั้งนี้ ไม่ใช่คำรับประกันความเข้ากันได้ของทุกฟีเจอร์

การจัดหมวดหมู่สำคัญ เพราะมันกำหนดว่า "ดี" แปลว่าอะไร Botasaurus อยู่ฝั่ง framework ของสเปกตรัมเดียวกับ Scrapy และ Crawlee — คุณต้องยอมรับโครงสร้าง เดคอเรเตอร์ และคอนเวนชันของมัน แล้วมันจะจัดการ plumbing ให้แทน นั่นต่างจากไดรเวอร์ที่โฟกัสมาก ๆ อย่าง nodriver ซึ่งให้แค่การเชื่อมต่อ Chrome DevTools Protocol แล้วถอยออกมา Botasaurus มีไดรเวอร์อยู่ข้างใน (botasaurus-driver) แต่ครอบมันด้วย task runner, ชั้นแคช, ตัว serialize ผลลัพธ์ และ request client คุณไม่ได้ซื้อแค่ driver แต่คุณซื้อ workflow ที่ถูกออกแบบมาแล้วทั้งชุด

เดคอเรเตอร์สามตัวคือภาพย่อทั้งหมดของการออกแบบ และทั้งสามจุดเข้าใช้งานนั้นมีอยู่จริง — ผมยืนยันแล้วว่า botasaurus.browser.browser, botasaurus.request.request และ botasaurus.task.task import ได้ทั้งหมด @browser จะรันฟังก์ชันของคุณบน browser driver ที่ถูกทำให้ดูเป็นมนุษย์ @request จะรันบน HTTP client น้ำหนักเบาที่พยายามทำตัวเหมือนเบราว์เซอร์ ส่วน @task คือ wrapper สากลสำหรับทุกอย่างที่ไม่ชัดว่าเป็นสองตัวแรก ใส่เดคอเรเตอร์เข้าไปแล้ว Botasaurus จะจัดการเครื่องมือรอบ ๆ ให้เอง ทั้งการรันแบบขนาน การ reuse driver การแคชผลลัพธ์ และตัวเขียนไฟล์ JSON, CSV, Excel และ HTML แนวคิดมันสอดคล้องดีมาก คำถามจริงคือคุณอยากให้สคราเปอร์มีเฟรมเวิร์กมาครอบเยอะแค่ไหน ซึ่งนั่นเป็นเรื่องของรสนิยม ไม่ใช่ข้อบกพร่อง

ข้อสรุป และขอบเขตของมัน

Botasaurus เป็นเครื่องมือที่ใช้ได้ดี รูปร่างของมันลงตัว และทำหน้าที่แบบที่เฟรมเวิร์กควรทำ คือทำให้เคสธรรมดาสั้นลง โมเดลเดคอเรเตอร์ชัดเจน ไลเซนส์ MIT ใจกว้างจริง ๆ และการติดตั้งก็ไม่วุ่นวาย ถ้าผมต้องให้คะแนนด้าน ergonomics ของ API surface มันได้คะแนนดี

สิ่งที่ผมวนกลับไปคิดอยู่เรื่อย ๆ คือจุดขายหลักของเฟรมเวิร์กนี้เอง — anti-detection — กลับเป็นสิ่งเดียวที่รีวิวอย่างรับผิดชอบไม่ควรพูดถึง ถ้าไม่เอามันไปชนกับระบบป้องกันจริงของใครสักคน ตัว driver เองมี API ที่ประกาศตัวว่าเกี่ยวกับการหลบการตรวจจับจริง ซึ่งผมยืนยันแค่ว่ามีเมธอดเหล่านั้นอยู่ แต่ไม่ได้ทดสอบพฤติกรรมของมันกับเป้าหมายใด ๆ นั่นคือทั้งหมดที่ผมจะยืนยันได้ ผมไม่ได้เอามันไปจ่อเว็บที่มีการป้องกัน ไม่ได้วัดอัตราความสำเร็จ ไม่ได้ reverse-engineer กลไก และจะไม่พยายามสื่อความหมายทั้งสามอย่างนั้นผ่านการเขียนคำ ถ้าเมธอดมีอยู่ในคลาส ก็แค่นั้นเอง ส่วนมันทำอะไรในโลกจริง เป็นรีวิวอีกแบบหนึ่ง ซึ่งรีวิวนี้ไม่ได้ทำ

จากนี้ไปจะเป็นการสำรวจความสามารถ การติดตั้ง ทรัพยากร และไลเซนส์ รวมถึงสิ่งที่ driver แสดงออกเมื่ออยู่บนหน้าเว็บที่ผมควบคุมเอง — ซึ่งเป็นคำกล่าวที่แคบกว่ารีวิวเครื่องมือนี้ส่วนใหญ่ และความแคบนี้คือประเด็นสำคัญ

มันบอกอะไรเกี่ยวกับตัวมันเอง

มีคำถามหนึ่งที่ตอบได้โดยไม่ต้องไปแตะระบบป้องกันจริงเลย: เมื่อ Botasaurus เป็นคนขับเบราว์เซอร์ ตัวเบราว์เซอร์นั้นเปิดเผยอะไรเกี่ยวกับตัวเองให้หน้าเว็บเห็นบ้าง? ผมสร้างหน้าเว็บที่อ่านค่าชัด ๆ อย่าง navigator.webdriver, user-agent, platform, languages, จำนวน plugin และ hardware, รูปร่างของ window.chrome, สิ่งที่ Permissions API ตอบ, รวมถึงเรขาคณิตของ window และ screen แล้วเสิร์ฟมันบน 127.0.0.1 จากนั้นผมเอา 4 สแตกไปจ่อหน้าเว็บนั้น: Botasaurus, nodriver, และ Playwright กับ Puppeteer แบบ stock เป็นตัวควบคุม ทั้งสี่ใช้ Chrome build เดียวกันคือ Chrome for Testing 151.0.7922.10 ดังนั้นถ้ามีอะไรต่าง มันต่างที่ไลบรารี ไม่ใช่เบราว์เซอร์ ทดสอบทั้ง headless และ headed อย่างละ 3 รอบ ค่าด้านล่างนี้เหมือนกันครบทั้ง 3 รอบ

ความแตกต่างขึ้นอยู่กับคุณใช้ตัวควบคุมตัวไหน เทียบกับ stock Puppeteer แล้ว Botasaurus เปลี่ยนค่า navigator.webdriver ส่วนรายการภาษาและ geometry ของหน้าต่างที่ไม่มีขนาดก็ตรงกัน ขณะที่ user-agent ต่างกันแค่รูปแบบการแสดงเวอร์ชัน เทียบกับ stock Playwright ความต่างที่เห็นยังรวมถึงรายการภาษาและ geometry ของหน้าต่างด้วย เทียบกับ nodriver ค่า boolean และ languages ตรงกัน โดยมีแค่รูปแบบ user-agent ในฟิลด์ที่แสดงนี่ต่างกัน นี่คือการสังเกตการเปิดเผยค่าโดยปริยาย ไม่ใช่คะแนน anti-detection

มีสองรายละเอียดที่ทำให้เรื่องนี้น่าสนใจกว่าแค่เห็นค่า false เฉย ๆ อย่างแรกคือค่าดังกล่าวไปอยู่ตรงนั้นได้อย่างไร ในทั้งสี่สแตก property นี้ยังคงเป็น getter ดั้งเดิมของเบราว์เซอร์บน Navigator.prototype — function get webdriver() { [native code] } — ไม่ได้กลายเป็น own-property ที่ถูกแปะลงบน instance และไม่ได้ถูกแทนที่ด้วยฟังก์ชันใหม่ Botasaurus จึงไม่ได้ไป rewrite property หลังหน้าเว็บโหลด ค่ามันถูกกำหนดตอนเบราว์เซอร์เริ่มต้น และตัว property เองก็ยังไม่ถูกแตะต้อง

รายละเอียดที่สองคือจุดที่ทำให้คำโฆษณาต้องถูกใส่วงเล็บ ในโหมด headless user-agent ของ Botasaurus ยังประกาศ HeadlessChrome/151.0.0.0 อยู่ — เหมือนกับ stock Puppeteer และเหมือนกับ stock Playwright เป๊ะ ๆ ถ้าเปิดแบบ headed มันจะกลายเป็น Chrome/151.0.0.0 ซึ่งก็เหมือนกันอีก Driver constructor รับพารามิเตอร์ user_agent อยู่ ดังนั้นจะตั้งเองก็แค่ส่ง keyword argument เข้าไป แต่ค่าตั้งต้นไม่ได้พยายามซ่อน string ที่เป็นลายเซ็นชัดที่สุดของ browser automation เลย

เกือบทุกอย่างที่เหลือเหมือนกันหมดทั้งสี่สแตก และควรพูดให้ชัด เพราะมันทำให้ภาพแคบลง — ทุก property ด้านล่างมีค่าเหมือนกันใน Botasaurus, nodriver, Playwright และ Puppeteer:

คำโบราณที่ว่า Permissions API กับ Notification.permission ให้ค่าขัดกันนั้นไม่เกิดขึ้นเลย — ทั้งสี่ตัวรายงาน default และ prompt สอดคล้องกันทั้งหมด ผมยังสแกน document และ window หาเศษ cdc_ แบบที่ WebDriver รุ่นเก่าชอบทิ้งไว้ ก็ไม่พบในทั้งสี่

อีกเรื่องหนึ่งที่ควรรู้ก่อนใช้งานจริง: แม้ Botasaurus จะมีขนาด 122 MB แต่มันไม่ได้แถมหรือดาวน์โหลดเบราว์เซอร์มาให้ find_chrome_executable() จะชี้ไปยัง Chrome ที่มีอยู่ในเครื่องเท่านั้น — บนเครื่องผมคือ /Applications/Google Chrome.app เวอร์ชัน 150.0.7871.187 — และนั่นคือเวอร์ชันที่ user-agent เปิดเผยออกมา ฟลีตของคุณจะประกาศ Chrome เวอร์ชันใด ก็ขึ้นกับ Chrome ที่ฟลีตนั้นติดตั้งอยู่ ซึ่งสำหรับเฟรมเวิร์กที่มีความเห็นชัดเจนแบบนี้ ค่าเริ่มต้นกลับไม่ค่อยมีความเห็นอะไรเท่าไร

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

มุมมองที่ให้อภัยมากขึ้นกับ fixture นี้

การเปิดเผยตัวเองเป็นเรื่องหนึ่ง แต่การคืน HTML ที่ถูกต้องคือหน้าที่หลัก ผมรัน Botasaurus กับ fixture เดิมที่ benchmark นี้ใช้กับเครื่องมืออื่น ๆ เพื่อให้ตัวเลขเทียบกันได้ หน้าเว็บมี 3 อย่างคือ A ลิงก์แบบ static ที่ marker เป็น literal อยู่ใน bytes ที่เสิร์ฟออกไป B โหนดที่ถูกสร้างโดย inline script ระหว่าง parse โดย marker และ URL ถูกประกอบจากเศษชิ้นส่วน ทำให้ต้อง รัน JavaScript จึงจะเห็นมัน และ C โหนดที่ถูก inject หลัง load ไปแล้ว 800 ms และประกอบในแบบเดียวกัน Class C คือฝั่ง adversarial — การอ่านที่ทำตอน load event จะมองไม่เห็นมัน

Botasaurus ไปอยู่ในจุดเดียวกับตัวใหญ่ ๆ driver.get() แล้วตามด้วย driver.page_html คือภาพที่อ่านตอนโหลดจบ: มันเรนเดอร์ JavaScript ได้ถูกต้อง — class B เป็นหลักฐาน เพราะ class B ไม่มีอยู่ใน bytes ที่เสิร์ฟเลย — แต่ถ้า injection ช้า 800 ms ก็จะพลาด class C ถ้าเพิ่ม driver.wait_for_element("#delayed-injected") เข้าไป ก็ได้ครบทั้งสาม Stable มากตลอด 3 รอบ และรันทั้งชุด 3 ครั้งก็ไม่มีสั่น

ส่วนที่น่าสนใจขึ้นมาคือเมื่อผมไล่เวลาการ inject เพื่อดูว่า default read ของแต่ละสแตกยอมแพ้ตรงไหน:

สแตกอื่น ๆ ทั้งหมดจะพลาด class C ทันทีที่การ inject ช้ากว่า load event ไป 100 ms ขึ้นไป Botasaurus ยังเก็บมันได้ถึง 300 ms และเพิ่งยอมแพ้ที่ 400 ms เท่านั้น นี่คือเฟรมเวิร์กที่ทำตัวเป็นเฟรมเวิร์ก และสาเหตุอยู่ใน constructor ตรง ๆ เลย: ค่าเริ่มต้นคือ wait_for_complete_page_load=True ดังนั้น get() จึงกลับมาช้ากว่าแค่ load event แบบเปล่า ๆ อย่างเห็นได้ชัด พูดแบบตัวเลขคือ default read ของมันใช้เวลา wall clock ราว 401–431 ms ขณะที่ nodriver ใช้ 119–129 ms และ Puppeteer ใช้ 125–171 ms

บน fixture ที่มีการ inject ช้าบนเครื่องนี้ การแลกเปลี่ยนคือช้าขึ้นประมาณ 250 ms ต่อหนึ่ง navigation เพื่อแลกกับการ snapshot ที่มาช้ากว่าและเก็บเนื้อหาที่ถูก inject ได้ถึง 300 ms หลังโหลดในรอบที่ทดสอบ นี่ไม่ได้พิสูจน์ว่า Botasaurus ถูกต้องกว่าบนเว็บทั่วไป ถ้าคุณเขียนสคราเปอร์เร็ว ๆ โดยไม่กำหนด wait condition แบบชัดเจน เบาะเวลานี้อาจช่วยไม่ให้พลาดโหนดที่มาทีหลัง แต่ถ้าคุณมีปริมาณ navigation สูง หรือคุณรอ condition แบบเจาะจงอยู่แล้ว มันก็แค่ overhead เท่านั้น

มีอีกสอง timing สำหรับใช้เทียบขนาด การเปิดเบราว์เซอร์ขึ้นมาทำให้ Botasaurus ใกล้เคียง nodriver และ Puppeteer มาก และช้ากว่า Playwright พอสมควร:

และ wait_for_element() แทบไม่เพิ่มค่าใช้จ่ายอะไรจนถึงดีเลย์ 300 ms — เพราะ get() รอผ่านช่วง inject ไปแล้ว — จากนั้นจึงขยับไปแถว ๆ 1.42 s เมื่อช้า 400–800 ms และ 2.43 s เมื่อช้า 1500 ms

คำถามเรื่อง 122 MB: meta-package ติดตั้งอะไรเข้ามาบ้าง

มาดูเลขคณิตกัน เพราะนี่คือสิ่งที่ผมคิดว่ามีประโยชน์ที่สุดที่จะส่งต่อให้คุณ การติดตั้ง pip install botasaurus แบบสะอาดใน virtual environment ใหม่สร้างต้นไม้ site-packages ขนาด 122.3 MB ที่มี 44 dist-info packages ถ้าตัด pip ออกเองก่อน (10.9 MB ซึ่งเป็น overhead ของ venv ไม่ใช่สิ่งที่ Botasaurus เรียกใช้) คุณจะเหลือ framework กับ dependency ราว 111 MB ส่วน browser driver — ตัวที่ทำงานด้าน automation จริง ๆ — มีอยู่แค่ประมาณ 4 MB ดังนั้นอีกประมาณ 107 MB คือทุกอย่างที่ meta-package ตัดสินใจว่าคุณควรมี

มันไปอยู่ตรงไหน? dependency ลูกโซ่ที่หนักที่สุด 5 ตัวรวมกันก็กินส่วนใหญ่ไปแล้ว (แต่ละแถวคือค่า install_footprint.heaviest_deps_mb ใน artifacts/raw/runs/resource_baseline.run1.json; ตัวรวมคือผมคำนวณเพิ่มเอง ไม่ได้มีอยู่ในไฟล์):

ที่ทำให้ผมยกคิ้วขึ้นคือ numpy กลายเป็นชิ้นที่ใหญ่ที่สุด — นี่คือไลบรารีคณิตเชิงเส้นที่อยู่ในเครื่องมือซึ่งหน้าที่คือดึงและ parse เว็บเพจ ไม่ได้ผิดเสียทีเดียว เพราะเฟรมเวิร์กมักจะค่อย ๆ สะสม utility dependencies และบางอย่างในต้นไม้ก็ชัดว่าต้องการ array math เพียงแต่สำหรับงานนี้ มันคือเครื่องจักรที่ใหญ่พอสมควร

ถ้าดูเทียบสเกล ไดรเวอร์แบบโฟกัสอย่าง nodriver หนักราว 17.2 MB จาก 6 แพ็กเกจบนเครื่องเดียวกัน — เรียกง่าย ๆ ว่าเบากว่าประมาณ 7 เท่า (ตัวเลขนี้ไม่ได้มาจากชุดนี้ แต่เป็น install_footprint.site_packages_total_mb ใน artifacts/raw/runs/resource_baseline.run1.json ของ nodriver ที่วัดในรันแยกบนโฮสต์เดียวกัน และ 122.3 ÷ 17.2 = 7.1) ตัวเลขทั้งสองไม่ได้เป็นข้อบกพร่อง และนี่ไม่ใช่การจัดอันดับความสามารถ แต่มันคือความต่างด้านกลไกระหว่างเฟรมเวิร์กแบบมีของแถมครบ กับ driver ที่โฟกัสเพียงอย่างเดียว ในคอนเทนเนอร์ ขนาด site-packages ที่วัดได้จะไปอยู่ใน application layer ไม่ใช่ขนาด image ทั้งก้อน และการทดสอบนี้ไม่ได้วัดเวลา build หรือ cold-deploy

มีอีกจุดที่ต้องระวังเรื่อง footprint: ระหว่าง introspection การใช้งานครั้งแรกของ from botasaurus.request import request ทำให้มีการดาวน์โหลดแบบครั้งเดียวประมาณ 12.8 MB รันที่เก็บมานี้ไม่ได้ระบุ artifact และปลายทางได้ชัดพอที่จะถือว่าตัวเลขนี้เป็นการเพิ่ม footprint ที่เสถียร แต่มันแสดงให้เห็นว่า code path นี้อาจต้องใช้อินเทอร์เน็ตในครั้งแรก ซึ่งควรลองซ้ำใน image ของคุณเองก่อนเอาไปใช้ในสภาพแวดล้อม air-gapped

ตัวเลข import ที่หลอกตา

การวัดเวลา cold-start ของ import คือจุดที่การอ่านตัวเลขแบบผิวเผินพาให้เข้าใจผิดได้ จากการวัด 7 subprocess ใหม่ import botasaurus ที่ระดับ top-level ออกมาเป็น median 0.08 ms ถ้าพูดค่านี้เดี่ยว ๆ มันฟังเหมือนเฟรมเวิร์กที่เบาที่สุดในหมวดนี้

แต่มันไม่ใช่ มันเร็วเพราะข้างในแทบไม่มีอะไรเลย แพ็กเกจ botasaurus ระดับ top-level ไม่มี __version__ และมี public namespace ว่างเกือบทั้งหมด — การ import มันแทบไม่ทำงานอะไรเพราะข้างในแทบไม่มีอะไรให้ทำ ตัวเลขที่สำคัญจริง ๆ สำหรับ CLI tool หรือ cold start ของ serverless คือการ import เอนจิน: from botasaurus_driver import Driver ใช้เวลาราว 135 ms และค่อนข้างนิ่งในช่วงไม่กี่มิลลิวินาทีจากการรันหลายครั้ง นั่นคือ fixed cost ที่คุณจ่ายก่อนจะดึงหน้าเว็บสักหน้า และเมื่อ import โมดูล driver แล้ว resident memory จะอยู่แถว 29–30 MB — ยังไม่รวม Chrome process ใด ๆ ทั้งสิ้น เปิดเบราว์เซอร์จริงแล้วมันจะเพิ่มขึ้นอีกมาก แต่ผมไม่ได้วัด memory ตอนที่มีเบราว์เซอร์รันอยู่ จึงไม่ขอใส่ตัวเลขให้

บทเรียนตรงนี้สั้นแต่ชัด: import botasaurus ที่ดูเร็วมากเป็นคุณสมบัติของแพ็กเกจ top-level ที่กลวง ไม่ใช่ของเฟรมเวิร์กที่ประหยัด ถ้าคุณกำลังประเมิน cold start ให้ไปวัด import ที่คุณจะพึ่งจริง ๆ

รูปร่างของ API: 99 เมธอดอยู่หลังกำแพงหน้าบ้านที่แทบว่างเปล่า

คลาส Driver ของเอนจินมี public methods 99 ตัว — พื้นที่กว้างที่ครอบคลุมการนำทาง การ query element คุกกี้และ local storage การกระทำด้วยเมาส์และคีย์บอร์ด สกรีนช็อต การจัดการแท็บ การ pass-through ไป CDP และการอัปโหลดไฟล์ constructor รับพารามิเตอร์ 18 ตัว ซึ่งก็พอสะท้อนพื้นผิวที่ปรับแต่งได้ดีพอสมควร: headless, proxy, profile, tiny_profile, block_images, block_images_and_css, wait_for_complete_page_load, chrome_executable_path, extensions, arguments, user_agent, window_size, lang และอีกไม่กี่ตัว ในฐานะ API ตอนสร้าง object มันครอบคลุมตัวควบคุมเบราว์เซอร์ที่เจอบ่อยได้ค่อนข้างครบ

จุดที่ชวนสะดุดอยู่ตรง top-level และมันไม่ได้แย่ แต่เป็นความจริง import botasaurus จะได้ namespace ที่แทบว่าง — ไม่มี __version__ แทบไม่มี public names ที่ระดับบน ทุกอย่างที่คุณใช้งานจริงอยู่ใน submodule: from botasaurus.browser import browser, Driver, from botasaurus.request import request, from botasaurus.task import task ถ้าคุณไปหาค่า botasaurus.__version__ เพื่อ log ว่ากำลังรัน build ไหนอยู่ คุณจะไม่เจอ ต้องไปใช้ importlib.metadata แทน ไม่มีอะไรพังจากเรื่องนี้ เพียงแต่มันไม่ใช่โครงสร้างที่นักพัฒนา Python มักคาดโดยสัญชาตญาณ และการรู้ไว้ล่วงหน้าจะช่วยให้คุณไม่เสียเวลาไปกับความงงในวันแรก

อีกหนึ่งข้อสังเกตจากเอกสารของเมธอดที่ผมพูดถึงก่อนหน้านี้ก็ยังอยู่ในขอบเขตนี้: ในบรรดาเมธอดที่มีชื่อเกี่ยวกับ anti-detection มีเพียง 2 ตัวเท่านั้นที่มี docstring ในโค้ด ที่เหลืออาศัยชื่อเมธอดเป็นตัวอธิบายตัวเอง โดยคำอธิบายรายเมธอดไปอยู่บนเว็บไซต์เอกสารภายนอกมากกว่าที่ source ที่ติดตั้งมา นี่เป็นข้อสังเกตเรื่องที่เก็บข้อมูล ไม่ใช่การตัดสินคุณภาพ — ไลบรารีดี ๆ จำนวนมากก็เก็บคำอธิบายไว้บน docs แทนโค้ด — แต่ถ้าเวิร์กโฟลว์ของคุณคือ "อ่าน source เพื่อเข้าใจเมธอด" พื้นที่ส่วนใหญ่ตรงนี้จะบอกแค่ชื่อ และไม่บอกอะไรเพิ่ม

ไลเซนส์: MIT ล้วน แม้แต่ตัว driver

ทั้ง meta-package และ botasaurus-driver ระบุไลเซนส์เป็น MIT พร้อม classifier มาตรฐาน License :: OSI Approved :: MIT License MIT เป็นไลเซนส์แบบ permissive: ไม่มีข้อบังคับ copyleft ไม่บังคับให้คุณต้องเปิดซอร์สงานของตัวเอง และเหมาะกับการใช้งานเชิงพาณิชย์อย่างแท้จริง ซึ่งต่างจาก nodriver ซึ่งเป็น driver แนว anti-detect ที่ใกล้เคียงกันแต่ใช้ AGPL-3.0 — ไลเซนส์ copyleft ที่เงื่อนไขการใช้งานผ่านเครือข่ายทำให้ฝ่ายกฎหมายหลายแห่งไม่สบายใจ ถ้าไลเซนส์เป็นเงื่อนไขตั้งต้นของคุณ ตรงนี้คือคะแนนบวกจริงสำหรับ Botasaurus

แต่มีข้อควรระวังอีกครั้งตรงรูปแบบ meta-package ไลเซนส์ MIT นี้ใช้กับ wheel ที่ Omkar Cloud ปล่อยเองเท่านั้น มันไม่ได้การันตีอัตโนมัติถึง dependency ลูกโซ่ราว 40 ตัวที่การติดตั้งดึงเข้ามา เพราะแต่ละตัวมีไลเซนส์ของตัวเอง ผมยืนยัน MIT ระดับบนสุดของแพ็กเกจที่ Omkar Cloud เผยแพร่ แต่ไม่ได้ audit ไลเซนส์ของ dependency ทุกตัวในต้นไม้ สำหรับโปรเจกต์เล่น ๆ ความต่างนี้อาจไม่สำคัญ แต่ถ้าจะรับทั้งต้นไม้ไปใช้ในบริษัทที่ซีเรียสเรื่อง software bill of materials นี่คือสิ่งที่ควรส่งผ่าน license scanner ของคุณเองก่อนจะ commit — ไม่ใช่เพราะผมเจอปัญหา แต่เพราะผมไม่ได้ไล่ดู และ meta-package คือจุดที่ไลเซนส์ไม่คาดคิดชอบซ่อนตัว

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

ข้อดี:

• การออกแบบสามเดคอเรเตอร์ (@browser / @request / @task) ชัดเจน และทั้งสามจุดเข้าใช้งานมีอยู่จริง — เฟรมเวิร์กทำให้เคสธรรมดาสั้นลงได้ดี
• ไลเซนส์ MIT ทั้งบน meta-package และ driver เป็นจุดต่างจริงเมื่อเทียบกับ AGPL-3.0 ของ driver คู่เทียบบางตัว เปิดกว้างและเหมาะกับงานเชิงพาณิชย์
• พื้นที่ของ driver กว้างมาก: public methods 99 ตัว และ constructor 18 พารามิเตอร์ ครอบคลุมงาน browser automation ทั่วไปได้ดี
• ติดตั้งและผ่าน smoke test ตอน import ได้บน Python 3.14.2 และ 3.12.13 ซึ่งใหม่กว่ารายชื่อ classifier ที่หยุดไว้แค่ 3.11; อย่างไรก็ตามยังไม่ได้พิสูจน์ความเข้ากันได้เชิงรันไทม์แบบเต็ม
• มีหน้าต่าง default-read ที่ให้อภัยมากที่สุดในบรรดาสต็กที่ผมวัด: ยังเก็บเนื้อหาที่ inject หลังโหลด 300 ms ได้ ในขณะที่ nodriver, Playwright และ Puppeteer พลาดตั้งแต่ 100 ms; wait_for_complete_page_load=True ทำงานจริง
• รายงาน navigator.webdriver เป็น false โดยปริยาย ในขณะที่ stock controls ทั้งสองรายงานเป็น true และไม่ได้ patch property นี้ — descriptor ยังเป็น native getter ของเบราว์เซอร์
• เป็นแบบ batteries included โดยตั้งใจ — มีแคช การรันแบบขนาน การ reuse driver และ output JSON/CSV/Excel/HTML มาให้ครบ ไม่ต้องไปประกอบเอง

ข้อเสีย:

• ใหญ่บนดิสก์: 122.3 MB จาก 44 แพ็กเกจ ราว 7 เท่าของ focused driver และน้ำหนักส่วนใหญ่ไม่ได้มาจาก driver 4 MB แต่เกิดจาก dependency อย่าง numpy (30.9 MB) กับ lxml (19.2 MB)
• ตัวเลข import botasaurus 0.08 ms ที่ดูดีนั้นหลอกตา; import เอนจินที่คุณต้องพึ่งจริง ๆ คือราว 135 ms และหลัง import แล้ว memory อยู่แถว 29–30 MB ก่อนที่เบราว์เซอร์จะเริ่มด้วยซ้ำ
• default-read window ที่ให้อภัยกว้างขึ้นไม่ได้มาฟรี ๆ: ช้ากว่าในการ navigate-and-read ประมาณ 401–431 ms เทียบกับ 119–129 ms ของ driver แบบเบากว่าบนหน้าเดียวกันและ Chrome ตัวเดียวกัน
• headless ยังประกาศ user-agent เป็น HeadlessChrome ตามเดิมโดยปริยาย เหมือน stock controls ทุกอย่าง; constructor มีพารามิเตอร์ user_agent แต่ไม่มีอะไรตั้งให้คุณ
• แม้จะหนัก 122 MB แต่มันก็ยังไม่แถมเบราว์เซอร์มาให้ — มันขับ Chrome ที่มีอยู่ในเครื่อง ดังนั้นเวอร์ชันเบราว์เซอร์ที่เปิดเผยก็ขึ้นกับ Chrome ที่คุณติดตั้งไว้
• การใช้งาน @request ครั้งแรกในการรันนี้ทำให้มีการดาวน์โหลดแบบครั้งเดียวราว 12.8 MB; artifact และปลายทางไม่ได้ถูกเก็บชัดพอจะนับเป็น footprint ที่เสถียร
• แพ็กเกจระดับบนแทบว่าง และไม่มี __version__; API จริงกับเวอร์ชันจริงไปอยู่ในที่ที่ไม่ค่อยเด่น
• เมธอดส่วนใหญ่ที่ตั้งชื่อเกี่ยวกับ anti-detection ไม่มี docstring ในโค้ด จึงอ่าน source แล้วเห็นแค่ชื่อ ไม่เห็นพฤติกรรม

นอกเหนือจากตัวเลขเหล่านี้ และจึงไม่ได้ทดสอบที่นี่: ทุกอย่างเกี่ยวกับประสิทธิผลจริงในการสู้กับบอท (ตั้งใจไม่ทดสอบ), หน่วยความจำต่อหน้า, การจัดการ proxy และ profile, throughput ขนาดใหญ่ และแพลตฟอร์มอื่นที่ไม่ใช่ macOS arm64 ตัวเลข footprint และ import เกิดขึ้นโดยไม่ได้เปิดเบราว์เซอร์เลย ส่วนตัวเลขเรื่องการอ่านค่าและการเปิดเผยข้อมูล มาจากเบราว์เซอร์ที่คุยกับ fixture บน 127.0.0.1 เท่านั้น

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

Botasaurus เหมาะถ้าคุณอยากได้เฟรมเวิร์ก ไม่ใช่แค่ชิ้นส่วน ถ้าคุณเริ่มโปรเจกต์สคราปิงจากไฟล์ว่าง ๆ และอยากยอมรับโครงสร้างที่มีคนวางไว้แล้ว — มีเดคอเรเตอร์สำหรับจุดเข้าใช้งาน มีแคชและการรันแบบขนานให้ มีตัวเขียน output ในตัว — นี่คือทางเลือกที่สอดคล้องกันและใช้ไลเซนส์ MIT ซึ่ง permissive มาก แต่รูปแบบการใช้และการกระจายของคุณก็ควรผ่านการตรวจ compliance ตามปกติ ทีมที่คิดแบบ Scrapy หรือ Crawlee อยู่แล้วจะคุ้นกับกรอบคิดนี้ทันที

ควรข้าม หรืออย่างน้อยควรคิดซ้ำ ถ้าเป้าหมาย deployment ของคุณอ่อนไหวต่อขนาด การติดตั้ง 122 MB ที่มี numpy และ gevent อยู่ในต้นไม้ถือว่าเยอะมาก ถ้าสิ่งที่คุณต้องการจริง ๆ คือ "ให้เบราว์เซอร์ทำงานและดึงข้อมูลบางฟิลด์" focused driver จะให้ automation ได้ในน้ำหนักที่ถูกกว่ามาก แต่คุณต้องเขียน plumbing รอบ ๆ เอง และควรข้ามไปเลยถ้าสิ่งที่คุณต้องการคือคำตัดสินเรื่อง anti-detection effectiveness เพราะนั่นคือสิ่งเดียวที่ผมตั้งใจไม่ทดสอบ — คุณจะกำลังเชื่อคำโฆษณาที่ผมไม่ได้ยืนยันและไม่ได้หักล้าง

ทางเลือกอื่น และ Thunderbit อยู่ตรงไหน

เริ่มด้วยกรอบที่ซื่อสัตย์ก่อน: Botasaurus ฟรี ใช้ MIT และโฮสต์เองได้ คุณเป็นคนดูแล fleet เอง จัดการอัปเดตเอง และเป็นเจ้าของ dependency tree ทั้งหมด — 44 แพ็กเกจนั้น — รวมถึงการแพตช์ การปฏิบัติตามไลเซนส์ และทุกอย่างที่ numpy จะตัดสินใจทำใน release ถัดไป สำหรับหลายทีม การเป็นเจ้าของแบบนี้คือสิ่งที่ต้องการอยู่แล้ว และไม่มี managed service ไหนจะชนะ "เฟรมเวิร์กที่คุณมีอยู่แล้ว" ในแง่ต้นทุนตรง ๆ

ถ้ามองในโลก open source ตัวเปรียบเทียบที่มีประโยชน์คือการดูจากรูปแบบ ถ้าคุณอยู่ฝั่ง framework แบบ Botasaurus, Scrapy และ Crawlee คือคู่เทียบที่ชัดเจน — โตแล้ว มีแนวทางของตัวเอง และมีคอนเวนชันที่ต้องยอมรับ ถ้าคุณต้องการ Markdown ที่พร้อมใช้กับ LLM จากหน้าเว็บ มากกว่าจะเป็นเฟรมเวิร์กจัดโครง crawler, Crawl4AI และเครื่องมือโฟกัสเนื้อหาอย่าง Trafilatura ถูกสร้างมาเพื่องานนั้นโดยตรง ถ้าคุณชอบมุม Python และ anti-detect แต่ต้องการอะไรที่เบากว่า meta-package, Scrapling ก็น่าสน และถ้าคุณพร้อมใช้ภาษาคอมไพล์, ไลบรารี Go อย่าง Colly ก็แลกการเรนเดอร์ JavaScript ออกไปกับความเร็วและ footprint ที่เล็กกว่า ตัวเลือกที่ขับเบราว์เซอร์ทุกแบบ รวมถึง Botasaurus ย่อมรับต้นทุนตามที่บทความเทียบ Playwright vs Puppeteer อธิบายไว้ — เบราว์เซอร์จริงไม่ใช่ของถูก ซึ่งเป็นเหตุผลส่วนหนึ่งว่าทำไมเฟรมเวิร์กที่ครอบมันถึงมีน้ำหนักตามไปด้วย

เมื่อมี managed API เข้ามา มันคือจุดคนละจุดใน pipeline เดียวกัน Botasaurus คือสแตกสำหรับนักพัฒนาแบบ self-hosted; Thunderbit ขายตัว managed ที่มุ่งไปยังนักพัฒนากลุ่มเดียวกัน Open API มีสอง endpoint POST /distill (1 credit) คืนหน้าเว็บเป็น Markdown ที่สะอาดและพร้อมใช้งานกับ LLM โดยให้ rendering และ anti-bot จัดการฝั่งเซิร์ฟเวอร์ คุณจึงไม่ต้อง provision browser หรือ dependency tree เองเลย POST /extract (20 credits) คืน JSON ที่มีโครงสร้างตาม JSON Schema ที่คุณกำหนด โดยตั้ง renderMode เป็น none, basic หรือ full ตามว่าเว็บนั้นต้องใช้เบราว์เซอร์มากแค่ไหน ทั้งสองแบบมี batch version สำหรับครั้งละได้ถึงร้อย URL มี MCP server สำหรับ agents และ coding assistant — thunderbit_suggest_fields ฟรีและจะบอกว่าหน้าเว็บมีอะไรให้ดึงก่อนที่คุณจะเสียเครดิต — และมี CLI ผ่าน npx @thunderbit/thunderbit-cli สำหรับ cron และ CI ถ้าคุณไม่ใช่นักพัฒนาและไม่อยากแตะสิ่งเหล่านี้เลย Chrome extension ก็ใช้เอนจินเดียวกันในรูปแบบ no-code และวิดีโอสาธิตบน Thunderbit's YouTube channel ก็ครอบคลุมเวิร์กโฟลว์ที่พบบ่อย

การแลกเปลี่ยนอยู่ที่งานไปอยู่ตรงไหน ไม่ใช่ว่าเครื่องมือไหนดีกว่า Botasaurus เก็บเฟรมเวิร์ก fleet ของ browser dependency โครงสร้างพื้นฐาน และการดูแลรักษาไว้ฝั่งคุณ โดยไม่คิดค่าบริการต่อ request; แต่ compute, bandwidth, proxies และงาน operations ก็ยังเป็นต้นทุนของคุณ Managed API เอางาน rendering และ output ที่มีโครง JSON ออกไปจากมือคุณ แล้วคิดราคาต่อการเรียก — คุณเอาไปเทียบกับระบบ self-hosted ได้บน pricing page

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

คำตัดสิน

Botasaurus เป็นตัวเลือกที่ใช้ได้ ถ้าคุณต้องการเฟรมเวิร์ก Python แบบ all-in-one และยอมรับ footprint ของ dependency ได้ การออกแบบสามเดคอเรเตอร์ชัดเจน driver surface กว้าง และมันผ่าน smoke test ของ install/import บน Python รุ่นที่ใหม่กว่าที่ classifier อ้างไว้ บน fixture ในเครื่องของผม default snapshot ยังเก็บเนื้อหาที่ถูก inject หลังโหลด 300 ms ได้ ในขณะที่สแตกอื่นที่ทดสอบพลาดตั้งแต่ 100 ms; แต่นั่นคือผลของ fixture ไม่ใช่อันดับแบบทั่วไป

แต่ต้องประเมินคำกล่าวให้ถูกขนาด มันคือการติดตั้ง 122 MB, 44 แพ็กเกจ โดย driver มีแค่ราว 4 MB และที่เหลือคือ numpy, lxml, gevent และพวกเดียวกัน — ประมาณ 7 เท่าของ focused driver และน้ำหนักนั้นจะตกอยู่ใน image ของคอนเทนเนอร์และเวลา cold-deploy ของคุณ import botasaurus ที่ 0.08 ms เป็นแค่หน้าบ้านที่ว่าง ไม่ใช่เฟรมเวิร์กที่เบา; ตัวเลขที่คุณต้องจ่ายจริงคือการ import เอนจินราว 135 ms default read ที่ให้อภัยมากขึ้นนั้นแลกด้วยเวลาประมาณ 250 ms ทุกครั้งที่ navigate และในคำถามเรื่องการเปิดเผยข้อมูลแบบ default ที่ผมตอบได้จริง ภาพก็แคบกว่าที่การตลาดบอก: มีเพียง boolean หนึ่งตัวที่ต่างจาก stock Puppeteer, user-agent แบบ headless ยังบอก HeadlessChrome, และ property อื่น ๆ ที่วัดได้ก็เหมือนกันหมดในทั้งสี่สแตก จุดขายด้าน anti-detection ที่ทำให้คนสนใจเครื่องมือนี้คือสิ่งเดียวที่รีวิวนี้ไม่ให้คะแนน — ผมยืนยันแค่ว่าเมธอดนั้นมีอยู่ ขับ driver ไปยังหน้าเว็บบนเครื่องของตัวเอง และหยุดแค่นั้นโดยตั้งใจ รู้ footprint ของมัน อย่าเชื่อตัวเลข import ที่ดูดีเกินจริง และมอง marketing เรื่อง stealth เป็นคำถามเปิด Botasaurus จึงเป็นเฟรมเวิร์กที่ทำงานได้ตามแบบของเฟรมเวิร์กจริง ๆ ถ้าคุณคาดหวัง driver ที่เบาหวิว คุณจะประหลาดใจกับเวลา docker build แน่นอน

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

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

Botasaurus ฟรีไหม และใช้ไลเซนส์อะไร? ฟรี และใช้ MIT ทั้ง botasaurus meta-package และ botasaurus-driver engine ต่างก็มี classifier ว่าเป็น OSI-approved MIT MIT เป็นไลเซนส์แบบ permissive จึงไม่มีภาระ copyleft และเหมาะกับการใช้งานเชิงพาณิชย์ ซึ่งต่างจาก anti-detect driver คู่เทียบหลายตัวที่ใช้ AGPL-3.0 อย่างมีนัยสำคัญ ข้อควรระวังคือ MIT ครอบคลุมแค่แพ็กเกจของ Omkar Cloud เอง ไม่ได้ครอบคลุม dependency ลูกโซ่ราว 40 ตัวที่การติดตั้งดึงเข้ามาโดยอัตโนมัติ ดังนั้นถ้าจะใช้ทั้งต้นไม้ในระดับองค์กร ควรรัน license scan ของคุณเองก่อน

การติดตั้ง Botasaurus ใหญ่แค่ไหน แล้วทำไม import botasaurus ถึงดูเร็วมาก? การ pip install botasaurus แบบสะอาดสร้างต้นไม้ site-packages ขนาด 122.3 MB จาก 44 แพ็กเกจบนเครื่องของผม ตัว browser driver เองมีแค่ประมาณ 4 MB — น้ำหนักมาจาก meta-package ที่ดึง dependency tree กว้างเข้ามา โดยตัวที่ใหญ่สุดคือ numpy (30.9 MB), lxml (19.2 MB), botasaurus_requests (12.6 MB), gevent (11.3 MB) และ pygments (8.4 MB) ซึ่งประมาณ 7 เท่าของ footprint ของ focused driver อย่าง nodriver บนเครื่องเดียวกัน ไม่มีสิ่งไหนเป็นบั๊ก; มันคือราคาของ "มีของแถมครบ" และมันสำคัญมากที่สุดกับขนาด image ของคอนเทนเนอร์ ส่วนเวลา import คือที่ที่ footprint ซ่อนตัวอยู่: import botasaurus วัดได้ราว 0.08 ms แต่ที่เร็วได้ก็เพราะ top-level package แทบว่าง — ไม่มี __version__, แทบไม่มี public names ดังนั้น import จึงแทบไม่ทำอะไร ตัวที่แพงคือเอนจิน from botasaurus_driver import Driver ราว 135 ms และหลังจาก import แล้ว memory จะอยู่แถว 29–30 MB ก่อนที่ browser จะเริ่มจริง ถ้าคุณกำลังประเมิน serverless cold start ให้ไปวัด engine import ไม่ใช่ top-level ที่กลวง

Botasaurus เปิดเผยอะไรเกี่ยวกับตัวมันเองบ้าง และถูกทดสอบกับระบบ anti-bot จริงหรือยัง? ครึ่งแรกวัดมาแล้ว; ครึ่งหลังตั้งใจไม่ทดสอบ บนหน้าเว็บที่ผมเสิร์ฟจาก 127.0.0.1 โดยใช้ Chrome build เดียวกับตัวควบคุม: navigator.webdriver กลับมาเป็น false ในขณะที่ stock Playwright และ stock Puppeteer รายงาน true ทั้งคู่ ค่านั้นถูกตั้งตั้งแต่ตอน browser launch ไม่ใช่การ patch property — descriptor ยังเป็น native getter ของ Chrome อยู่ นอกเหนือจาก boolean นี้ แทบทุกอย่างตรงกับตัวควบคุมเป๊ะ: platform string เหมือนกัน, plugin ห้าตัว, twelve cores, reported device memory 16 GB, รูปร่าง window.chrome เหมือนกัน, ไม่มีความขัดแย้งจาก Permissions API และไม่พบเศษ cdc_ บน document หรือ window เลย headless ยังประกาศ user-agent เป็น HeadlessChrome/151.0.0.0 เหมือนกับตัวควบคุมทั้งสอง — constructor ของ Driver มีพารามิเตอร์ user_agent อยู่ก็จริง แต่ไม่มีอะไรตั้งค่าให้คุณเอง ส่วนประสิทธิผลจริง ผมไม่เคยเอา driver ไปชนกับ live site ไม่เคยติดต่อ anti-bot service และไม่เคยแตะ CAPTCHA ตัว driver มีเมธอดที่ตั้งชื่อเกี่ยวกับ anti-detection อยู่หลายตัว ซึ่งผมยืนยันว่าเห็นจริง แต่ไม่ได้เรียกใช้ ไม่ได้วัดผลกับเป้าหมายใด ๆ ไม่ได้วัดอัตราความสำเร็จ และไม่ได้อธิบายกลไก ตาราง disclosure ด้านบนบอกได้แค่ว่าสแตกประกาศอะไรออกมา ไม่ได้บอกว่ามีใครรับฟังอยู่หรือเปล่า

Botasaurus รองรับคอนเทนต์ที่เรนเดอร์ด้วย JavaScript ไหม? รองรับ และค่าเริ่มต้นของมันให้อภัยมากกว่าหลายตัว บน fixture ที่มี content สามแบบ driver.get() + driver.page_html ให้ผล 2 จาก 3 เมื่อ inject หน่วง 800 ms — มันเรนเดอร์ JavaScript ได้ถูกต้อง แต่ไปอ่านก่อนที่เนื้อหาช้ามาถึง — ขณะที่ driver.wait_for_element() ให้ครบ 3 จาก 3 จุดที่ต่างคือ default read ยอมแพ้ช้ากว่าใคร: Botasaurus ยังจับเนื้อหาที่ถูก inject หลังโหลด 300 ms ได้ ในขณะที่ nodriver, Playwright และ Puppeteer แพ้ตั้งแต่ 100 ms ซึ่งมาจาก wait_for_complete_page_load=True ใน constructor และต้องจ่ายเวลาประมาณ 250 ms ต่อการ navigate หนึ่งครั้ง

ถ้าจะ import และใช้ Botasaurus หลังติดตั้ง ต้องทำยังไง? ไม่ใช่แบบที่เดาง่าย ๆ namespace ระดับบนของ botasaurus แทบว่าง ดังนั้น API จริงอยู่ใน submodule: from botasaurus.browser import browser, Driver, from botasaurus.request import request, และ from botasaurus.task import task คุณก็แค่ decorate ฟังก์ชันธรรมดาด้วย @browser, @request หรือ @task แล้วเฟรมเวิร์กจะจัดการ driver, แคช และ output ให้เอง เพราะไม่มี botasaurus.__version__ ถ้าต้องการ log ว่ากำลังรัน build ไหนอยู่ ให้ใช้ importlib.metadata แทน