Recenzja Botasaurus: sterownik 4 MB, instalacja 122 MB i liczba 0,08 ms, którą lepiej nie rzucać na lewo i prawo

Botasaurus to oparty na Pythonie framework do web scraping od Omkar Cloud, reklamowany jako kompletne, uniwersalne narzędzie do budowania scraperów. Piszesz zwykłą funkcję, oznaczasz ją dekoratorem @browser, @request albo @task, a framework dokleja do niej sterownik przeglądarki, HTTP-klienta udającego przeglądarkę, cache, równoległe wykonanie i eksport do wielu formatów. To meta-pakiet — i właśnie to jest tu najważniejsze: pip install botasaurus nie wrzuca do środowiska jednej biblioteki, tylko składa zestaw własnych wheeli oraz szerokie drzewo zależności pośrednich. Ten techniczny szczegół okazał się najciekawszą rzeczą, jaką dało się uczciwie zmierzyć.

Botasaurus pozycjonuje się wokół anti-detection i dokładnie tego obszaru ta recenzja nie ocenia. Zrobiłem inwentaryzację frameworka — co się instaluje, co importuje, jakie ma metody, ile waży i na jakiej licencji się opiera — zamiast sprawdzać go przeciwko jakimkolwiek aktywnym zabezpieczeniom. Wszystkie liczby dotyczące footprintu i importu poniżej pochodzą z pip, z python -c "import ..." oraz z introspekcji klas, które zostały utworzone, ale nigdy nie dostały polecenia pobrania strony; do uzyskania żadnej z nich nie uruchamiałem przeglądarki. Później przeglądarki uruchamiałem, ale wyłącznie na stronach napisanych przeze mnie i serwowanych lokalnie na 127.0.0.1, żeby sprawdzić, co sterownik sam o sobie ujawnia i czy potrafi pobrać treść strony budowanej przez JavaScript. Nie użyto żadnej prawdziwej strony, nie kontaktowano się z żadnym systemem antybotowym i nie testowano CAPTCHA. Skuteczność wobec realnych serwisów jest poza zakresem z założenia — i wolę powiedzieć to od razu, niż sugerować benchmark, którego nie wykonałem.

Przy takim zastrzeżeniu główny wniosek dotyczy rozmiaru, i jest to wniosek raczej łagodny. Czysta instalacja tworzy katalog site-packages o rozmiarze 122,3 MB obejmujący 44 pakiety, na maszynie, gdzie sam sterownik przeglądarki stanowiący centrum całego zestawu ma około 4 MB. Framework nie jest ciężki dlatego, że sam sterownik jest ciężki; jest ciężki, bo „all-in-one” oznacza, że dorzuca numpy, lxml, gevent i kilkanaście innych rzeczy do zadania polegającego na pobieraniu HTML-a. A druga połowa wniosku to liczba, którą często cytuje się jako zaletę, a nie powinno się jej traktować dosłownie: import botasaurus zajmuje 0,08 ms, co wygląda na ultralekki framework, a w rzeczywistości jest tylko pustymi drzwiami wejściowymi.

Czym właściwie jest Botasaurus

Botasaurus — omkarcloud/botasaurus na GitHubie, z 5 561 gwiazdkami, 486 forkami i 58 otwartymi zgłoszeniami w momencie pobierania metadanych 14 lipca 2026 — to framework Pythona, a nie biblioteka jednofunkcyjna. Testowane przeze mnie wersje to botasaurus 4.0.97 dla meta-pakietu oraz botasaurus-driver 4.0.92 dla silnika pod spodem. Meta-pakiet deklaruje requires-python >=3.7 (sterownik >=3.5), a klasyfikatory PyPI wskazują wsparcie tylko do Pythona 3.11. Na mojej maszynie zainstalował się i przeszedł test importu w Pythonie 3.14.2. To dowód na działanie tej konkretnej instalacji, a nie obietnica pełnej zgodności każdej funkcji.

Warto precyzyjnie nazwać kategorię, bo od niej zależy, co znaczy „dobry”. Botasaurus znajduje się po stronie frameworka, w podobnym otoczeniu jak Scrapy i Crawlee — przyjmujesz jego strukturę, dekoratory i konwencje, a w zamian dostajesz ogarniętą „hydraulikę” pod spodem. To zupełnie inna propozycja niż wyspecjalizowany sterownik, taki jak nodriver, który daje po prostu połączenie z Chrome DevTools Protocol i usuwa się w cień. Botasaurus zawiera sterownik (czyli botasaurus-driver), ale opakowuje go w runner zadań, warstwę cache, serializery wyników i klienta requestów. Nie kupujesz więc samego sterownika; kupujesz narzucony z góry workflow ze sterownikiem w środku.

Trzy dekoratory to cały projekt w pigułce, a wszystkie trzy wejścia faktycznie istnieją — potwierdziłem, że botasaurus.browser.browser, botasaurus.request.request i botasaurus.task.task można zaimportować. @browser uruchamia funkcję na „uczłowieczonym” sterowniku przeglądarki. @request odpala ją na lekkim kliencie HTTP zbudowanym tak, by wyglądał jak przeglądarka. @task to uniwersalny wrapper do wszystkiego, co nie pasuje wyraźnie do dwóch pierwszych przypadków. Oznaczasz funkcję, a Botasaurus dostarcza resztę: wykonywanie równoległe, ponowne użycie sterownika, cache wyników oraz zapis do JSON, CSV, Excela i HTML. To spójny pomysł. To, czy chcesz aż tyle frameworka wokół scrapera, to już kwestia gustu, a nie wada.

Werdykt i granice tego, co tu oceniono

Botasaurus jest kompetentny, dobrze zaprojektowany i robi to, co frameworki mają robić: skraca drogę w typowych przypadkach. Model dekoratorów jest czysty. Licencja MIT jest naprawdę hojna. Instalacja przebiega bez dramatu. Gdybym oceniał ergonomię API, wynik byłby dobry.

Wciąż wracam jednak do tego, że flagowa obietnica frameworka — anti-detection — jest dokładnie tym jednym obszarem, o którym odpowiedzialna recenzja nie może powiedzieć nic sensownego, jeśli nie zestawi go z produkcyjnymi zabezpieczeniami jakiegoś konkretnego serwisu. Sterownik rzeczywiście udostępnia API opisywane jako anti-detection: potwierdziłem istnienie metod, ale nie sprawdzałem ich działania na żadnym celu. I to jest cała moja teza na ten temat. Nie kierowałem go na chronioną stronę, nie mierzyłem skuteczności, nie odtwarzałem mechanizmu i nie będę tego sugerował stylistyką. Metody są w klasie. To, co robią w realnym świecie, to osobna recenzja — i ta nią nie jest.

Dalej dostajesz więc inwentaryzację funkcji, instalacji, zasobów i licencji, plus to, co sterownik robi na stronie, którą sam kontroluję — czyli znacznie węższe twierdzenie niż w większości recenzji tego narzędzia, i właśnie o to chodzi.

Co samo o sobie ujawnia

Oto pytanie, na które można odpowiedzieć bez wchodzenia w jakąkolwiek prawdziwą obronę: kiedy Botasaurus steruje przeglądarką, co ta przeglądarka zdradza stronie, którą otwiera? Napisałem stronę, która odczytuje oczywiste rzeczy — navigator.webdriver, user-agent, platformę, języki, liczbę wtyczek i zasobów sprzętowych, kształt window.chrome, odpowiedzi API Permissions oraz geometrię okna i ekranu — wystawiłem ją lokalnie na 127.0.0.1 i podpiąłem do niej cztery stosy: Botasaurus, nodriver oraz standardowe Playwright i Puppeteer jako kontrole. Wszystkie cztery sterowały tą samą wersją Chrome (Chrome for Testing 151.0.7922.10), więc wszystko, co się różni, wynika z biblioteki, a nie z samej przeglądarki. Tryb headless i headed, po trzy uruchomienia. Każda wartość poniżej była taka sama we wszystkich trzech powtórzeniach.

Różnice zależą od tego, z jaką kontrolą porównujesz wynik. W zestawieniu ze standardowym Puppeteer Botasaurus zmienił navigator.webdriver; lista języków i geometria okna przy zerowym rozmiarze zgadzały się, a user-agent różnił się tylko formatem wersji. W porównaniu ze standardowym Playwright różnice obejmowały także listę języków i geometrię okna. W porównaniu z nodriver zgadzały się wartość logiczna i języki, a w pokazanych polach inny był jedynie format user-agenta. To są obserwacje domyślnego ujawniania się, a nie ocena anti-detection.

Dwa szczegóły czynią to ciekawszym niż samo false. Po pierwsze, w jaki sposób ta wartość się pojawia. We wszystkich czterech stosach właściwość nadal jest natywnym getterem przeglądarki na Navigator.prototype — function get webdriver() { [native code] } — a nie własną właściwością wpiętą w instancję i nie podmienioną funkcją. Botasaurus nie przepisuje więc właściwości po załadowaniu strony; wartość jest ustalana przy starcie przeglądarki, a sama właściwość zostaje nietknięta.

Po drugie, i to jest element, który studzi marketing: w trybie headless user-agent Botasaurus nadal ogłasza HeadlessChrome/151.0.0.0 — identycznie jak standardowy Puppeteer i standardowy Playwright. W trybie headed zmienia się to na Chrome/151.0.0.0, znowu identycznie. Konstruktor Driver przyjmuje parametr user_agent, więc ustawienie własnego jest tylko argumentem, ale domyślna konfiguracja nie maskuje najbardziej znanego identyfikatora w automatyzacji przeglądarek.

Prawie wszystko inne było takie samo we wszystkich czterech stosach, i warto to powiedzieć wprost, bo zawęża obraz — każda wartość poniżej była identyczna w Botasaurus, nodriver, Playwright i Puppeteer:

Stary klasyk, w którym API Permissions i Notification.permission sobie przeczą, nie pojawił się nigdzie — wszystkie cztery zwracały zgodnie default i prompt. Przeszukałem też document i window pod kątem śladów w stylu cdc_, znanych ze starszych stosów WebDrivera: wszędzie pusto.

Jeszcze jedna rzecz warta wiedzy przed wdrożeniem: przy całych swoich 122 MB Botasaurus nie dostarcza ani nie pobiera przeglądarki. find_chrome_executable() wskazuje na to, co masz już zainstalowane — u mnie /Applications/Google Chrome.app, wersję 150.0.7871.187 — i właśnie tę wersję potem ujawnia user-agent. Twoja flota ogłasza tę wersję Chrome, którą akurat ma zainstalowaną, a jak na framework tak opiniotwórczy, jest to zaskakująco nieopiniujący domyślny wybór.

Nazwijmy to po imieniu: to zapis tego, co automatyczny stos ujawnia, kiedy nikt nie prosi go o ukrywanie się — przydatny, jeśli jesteś po stronie obrony, albo jeśli chcesz wiedzieć, co twoje własne narzędzia rozgłaszają. To nie jest miara tego, czy ma to znaczenie dla konkretnego serwisu. Tego nie testowałem i żadnego wiersza powyżej nie należy czytać jako sugestii wyniku.

Bardziej pobłażliwy odczyt tego fixture’u

Ogłaszanie się to jedno; zwrócenie właściwego HTML-a to drugie. Uruchomiłem Botasaurus na tym samym fixture’ie trzech klas treści, którego używa reszta tego repozytorium benchmarkowego, więc liczby dają się porównać z każdym innym testowanym narzędziem. Strona zawiera trzy elementy: A, statyczny link, którego znacznik jest literalnie wpisany w wysyłane bajty; B, węzeł budowany przez inline script w trakcie parsowania, z markerem i URL-em składanymi z fragmentów tak, że tylko uruchomienie JavaScriptu je ujawnia; oraz C, węzeł wstrzykiwany 800 ms po zdarzeniu load, złożony w ten sam sposób. Klasa C jest tą „wrogą” — odczyt wykonany w chwili load nie może jej zobaczyć.

Botasaurus ląduje tam, gdzie lądują cięższe narzędzia. driver.get() od razu połączone z driver.page_html daje zrzut stanu z momentu ładowania: JavaScript renderuje poprawnie — klasa B to potwierdza, bo B nie istnieje nigdzie w wysłanych bajtach — ale przy opóźnieniu 800 ms pomija klasę C. Dodaj driver.wait_for_element("#delayed-injected"), a dostajesz wszystkie trzy. Stabilnie w trzech powtórzeniach i trzech pełnych uruchomieniach całego zestawu, bez flaków.

Ciekawsza część wychodzi, gdy przesuwasz opóźnienie wstrzyknięcia, by sprawdzić, kiedy domyślny odczyt każdego stosu przestaje nadążać:

Każdy inny stos gubi klasę C, gdy tylko wstrzyknięcie następuje 100 ms lub później po load. Botasaurus nadal ją łapie przy 300 ms, a poddaje się dopiero przy 400. To jest właśnie „frameworkowość” frameworka, a przyczyna leży w samym konstruktorze: wait_for_complete_page_load=True jest wartością domyślną, więc get() wraca zauważalnie później niż sam event load. W praktyce jego domyślny odczyt kosztuje 401–431 ms czasu rzeczywistego, podczas gdy odczyt nodriver wynosi 119–129 ms, a Puppeteera 125–171 ms.

W tym lokalnym fixture’ie z opóźnionym wstrzyknięciem trade-off wynosił mniej więcej 250 ms na każdą nawigację w zamian za późniejszy domyślny snapshot. Dzięki temu w tych uruchomieniach udało się złapać treści wstrzyknięte nawet 300 ms po load; nie dowodzi to jednak, że Botasaurus jest „lepszy” na dowolnej stronie. Jeśli piszesz szybkie scrapery bez precyzyjnych warunków oczekiwania, ten zapas może uratować przed pominięciem późno pojawiającego się elementu. Przy dużej liczbie nawigacji albo gdy i tak czekasz na konkretny warunek, to po prostu narzut.

Dwie kolejne liczby dla skali. Start przeglądarki w Botasaurus był praktycznie na poziomie nodriver i Puppeteera, a wyraźnie wolniejszy od Playwright:

A wait_for_element() nie kosztuje nic dodatkowego do opóźnienia 300 ms — get() zdążył już przejść dalej niż moment wstrzyknięcia — po czym rośnie do około 1,42 s przy 400–800 ms i 2,43 s przy 1500 ms.

Pytanie o 122 MB: co właściwie instaluje meta-pakiet

Oto rachunek, bo to najbardziej użyteczna rzecz, jaką mogę ci dać. Czyste pip install botasaurus w świeżym wirtualnym środowisku utworzyło drzewo site-packages o rozmiarze 122,3 MB obejmujące 44 pakiety z metadanymi dist-info. Jeśli odliczyć samo pip (10,9 MB, czyli narzut venv, a nie coś, o co prosił Botasaurus), zostaje około 111 MB frameworka i zależności. Sam sterownik przeglądarki — czyli komponent faktycznie wykonujący automatyzację — ma około 4 MB. Oznacza to, że jakieś 107 MB stanowi wszystko to, co meta-pakiet uznał za potrzebne.

Gdzie to idzie? Pięć najcięższych zależności pośrednich samo w sobie odpowiada za większość tego rozmiaru (każdy wiersz to wpis install_footprint.heaviest_deps_mb z artifacts/raw/runs/resource_baseline.run1.json; suma jest moim obliczeniem, a nie polem w pliku):

Największe zaskoczenie wywołało u mnie to, że numpy jest pojedynczo największą pozycją — to biblioteka do algebry liniowej siedząca w narzędziu, którego zadaniem jest pobieranie i parsowanie stron. Nie jest to błędem, dokładnie; frameworki lubią dorzucać zależności użytkowe, a coś w drzewie ewidentnie chce wykonywać obliczenia na tablicach. Po prostu sporo maszyny jak na taką robotę.

Dla porównania wyspecjalizowany driver nodriver waży około 17,2 MB w 6 pakietach na tej samej maszynie — można powiedzieć, że jest mniej więcej 7x lżejszy. (Ta liczba nie pochodzi z tego pakietu: to install_footprint.site_packages_total_mb z własnego artifacts/raw/runs/resource_baseline.run1.json nodriver, mierzonego osobno na tym samym hoście, a 122,3 ÷ 17,2 = 7,1). Żadna z tych liczb nie jest wadą i nie jest to ranking możliwości; to po prostu mechaniczny koszt różnicy między frameworkiem „z bateriami” a wyspecjalizowanym sterownikiem. W kontenerze zmierzony footprint site-packages trafia do warstwy aplikacji. Nie jest to pełny rozmiar obrazu, a ten test nie mierzył czasu budowy ani cold-deployu.

Jeszcze jeden niuans footprintu: podczas introspekcji pierwsze użycie from botasaurus.request import request spowodowało jednorazowe pobranie około 12,8 MB. Zapis uruchomienia nie zidentyfikował jednak wystarczająco dobrze artefaktu i miejsca docelowego, by traktować tę wartość jako stabilny przyrost zainstalowanego footprintu. Pokazuje to jednak, że ta ścieżka kodu może wymagać dostępu do sieci przy pierwszym użyciu, co warto odtworzyć we własnym obrazie przed wdrożeniem w środowisku bez dostępu do internetu.

Liczba importu, która kłamie

Czas importu przy cold starcie to miejsce, w którym łatwo źle odczytać liczby. Mierzony w siedmiu świeżych subprocessach import botasaurus na poziomie top-level wyniósł medianę 0,08 ms. Cytowane samo w sobie brzmi to jak najlżejszy framework w kategorii.

Ale nim nie jest. Jest szybki, bo prawie niczego tam nie ma. Top-level botasaurus nie udostępnia żadnego __version__ i ma niemal pustą przestrzeń publiczną — import prawie nic nie robi, bo prawie niczego tam nie ma. Liczbą, która naprawdę ma znaczenie dla narzędzia CLI albo cold startu serverless, jest import silnika: from botasaurus_driver import Driver zajmuje około 135 ms, stabilnie z dokładnością do kilku milisekund w kolejnych uruchomieniach. To jest rzeczywisty koszt stały, który płacisz, zanim zostanie pobrana choć jedna strona. A kiedy moduł sterownika jest już zaimportowany, pamięć rezydentna wynosi około 29–30 MB — i to jeszcze przed uruchomieniem jakiegokolwiek procesu Chrome. Jeśli uruchomi się prawdziwą przeglądarkę, wzrośnie ona wyraźnie; nie mierzyłem pamięci z działającą przeglądarką, więc nie będę podawał liczby.

Wniosek jest mały, ale ostry: to, że import botasaurus jest natychmiastowy, wynika z tego, że pakiet główny jest pustawy, a nie z tego, że framework jest tani. Jeśli liczysz cold start, mierz ten import, od którego naprawdę zależysz.

Kształt API: 99 metod za niemal pustymi drzwiami wejściowymi

Klasa Driver silnika udostępnia 99 publicznych metod — szeroką powierzchnię obejmującą nawigację, zapytania o elementy, cookies i local storage, akcje myszy i klawiatury, zrzuty ekranu, zarządzanie kartami, passthrough do CDP oraz upload plików. Konstruktor przyjmuje 18 parametrów, co jest całkiem przyzwoitą mapą powierzchni konfigurowalnej: 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 i kilka innych. Jako API do tworzenia obiektu obejmuje zwykły zestaw kontroli dla wrappera przeglądarki.

Pułapka kształtu leży na poziomie top-level i jest niegroźna, ale realna. import botasaurus daje niemal pustą przestrzeń nazw — bez __version__, praktycznie bez publicznych nazw na topie. Wszystko, czego naprawdę używasz, siedzi w submodułach: from botasaurus.browser import browser, Driver, from botasaurus.request import request, from botasaurus.task import task. Jeśli będziesz szukać botasaurus.__version__, żeby zalogować wersję, której używasz, nic tam nie znajdziesz; trzeba sięgnąć po importlib.metadata. Nic z tego nie psuje działania. Po prostu układ nie jest taki, jakiego większość programistów Pythona odruchowo się spodziewa, a wiedza o tym oszczędza kilka mylących minut pierwszego dnia.

Jedna obserwacja dokumentacyjna dotycząca wcześniej zaznaczonych metod jest uczciwa i mieści się w moim zakresie: spośród metod nazwanych wprost jako anti-detection tylko 2 mają docstring w kodzie. Reszta jest opisana wyłącznie nazwą, a szczegółowa dokumentacja żyje na zewnętrznej stronie docs, a nie w zainstalowanym źródle. To uwaga o lokalizacji dokumentacji, a nie ocena jakości — wiele dobrych bibliotek trzyma teksty poza kodem — ale jeśli twój workflow polega na czytaniu źródeł, większość tej części API powie ci tylko, jak się nazywa, a nie jak działa.

Licencja: MIT, od meta-pakietu aż po sterownik

Zarówno meta-pakiet, jak i botasaurus-driver deklarują MIT, z klasyfikatorem License :: OSI Approved :: MIT License. MIT jest liberalna: bez obowiązków copyleft, bez wymogu otwierania własnego kodu, z minimalnym tarciem przy użyciu komercyjnym. To naprawdę istotny i niebłahy kontrast z nodriver, sąsiednim anti-detect driverem, który jest wydawany na AGPL-3.0 — licencji copyleft, której klauzula dotycząca użycia sieciowego budzi w wielu działach prawnych niepokój. Jeśli licencja jest dla ciebie warunkiem wejścia, stanowisko MIT po stronie Botasaurus jest realnym plusem.

Zastrzeżenie jest takie samo jak wcześniej: ta liberalna licencja MIT obejmuje własne pierwszoplanowe wheel’e Botasaurus. Nie potwierdza automatycznie licencji około 40 zależności pośrednich, które instalacja pobiera, bo każda z nich ma własne warunki. Potwierdziłem MIT na poziomie pakietów publikowanych przez Omkar Cloud; nie audytowałem licencji każdej zależności w drzewie. Dla projektu hobbystycznego to rozróżnienie zwykle nie ma znaczenia. Dla wdrożenia całego drzewa w firmie, która dba o software bill of materials, to jest coś, co trzeba przepuścić przez własny skaner licencji, zanim się zdecydujesz — nie dlatego, że znalazłem problem, tylko dlatego, że nie sprawdzałem i właśnie w meta-pakietach najłatwiej ukrywa się niespodziewana licencja.

Plusy i minusy

Plusy:

• Czysty model trzech dekoratorów (@browser / @request / @task), z potwierdzoną obecnością wszystkich trzech wejść — framework skraca typowy przypadek.
• Licencja MIT zarówno dla meta-pakietu, jak i sterownika, co naprawdę odróżnia go od AGPL-3.0 podobnego drivera. Permisywna, przyjazna komercyjnie, bez copyleft.
• Szeroka powierzchnia API sterownika: 99 publicznych metod i konstruktor z 18 parametrami, obejmujący typowe potrzeby automatyzacji przeglądarki.
• Zainstalował się i przeszedł testy importu w Pythonie 3.14.2 i 3.12.13, wykraczając poza listę classifierów (która kończy się na 3.11); zgodności runtime nie potwierdzano.
• Najszersze okno poprawności domyślnego odczytu spośród wszystkich porównywanych stosów: nadal łapie treści wstrzyknięte 300 ms po load, podczas gdy nodriver, Playwright i Puppeteer gubią je już przy 100 ms. wait_for_complete_page_load=True faktycznie coś robi.
• Domyślnie zwraca navigator.webdriver jako false, podczas gdy standardowe kontrolki zwracają true, i robi to bez łatania właściwości — descriptor pozostaje natywnym getterem przeglądarki.
• Z założenia „batteries included” — cache, równoległość, ponowne użycie sterownika oraz wyjście JSON/CSV/Excel/HTML są częścią frameworka, a nie dodatkiem.

Minusy:

• Ciężki na dysku: 122,3 MB w 44 pakietach, czyli mniej więcej 7x więcej niż wyspecjalizowany driver, głównie przez zależności takie jak numpy (30,9 MB) i lxml (19,2 MB), a nie przez sam sterownik o rozmiarze ~4 MB.
• Pokrzepiające 0,08 ms importu top-level jest mylące; import silnika, od którego faktycznie zależysz, to około 135 ms, a pamięć po imporcie wynosi około 29–30 MB, zanim uruchomi się przeglądarka.
• Szersze domyślne okno odczytu nie jest darmowe: 401–431 ms na nawigację i odczyt wobec 119–129 ms dla lżejszego drivera na tej samej stronie i tym samym Chrome.
• W trybie headless user-agent nadal ogłasza HeadlessChrome domyślnie, tak samo jak standardowe kontrolki; parametr user_agent w konstruktorze istnieje, ale nic nie ustawia go za ciebie.
• Przy 122 MB nadal nie dostarcza przeglądarki — steruje tym Chrome, który już jest na hoście, więc ujawniana wersja przeglądarki to po prostu ta zainstalowana w twojej flocie.
• Pierwsze użycie @request spowodowało w tym uruchomieniu jednorazowe pobranie około 12,8 MB; artefakt i miejsce docelowe nie zostały zebrane dość dobrze, by uznać to za stały przyrost footprintu.
• Top-level package jest niemal pusty i nie eksponuje __version__; prawdziwe API i wersja siedzą gdzie indziej, mniej oczywiście.
• Większość metod nazwanych w stylu anti-detection nie ma docstringa w kodzie, więc źródła pokazują nazwę, a nie zachowanie.

Poza tym, co obejmują powyższe liczby, i więc nie zostało tu przetestowane: wszystko związane z realną skutecznością wobec botów (poza zakresem z założenia), pamięć na poziomie pojedynczej strony, obsługa proxy i profili, przepustowość na dużą skalę oraz jakakolwiek platforma poza macOS arm64. Wartości footprintu i importu zostały uzyskane bez uruchamiania przeglądarki; liczby dotyczące odczytu i ujawniania pochodzą z przeglądarek, które rozmawiały wyłącznie z fixture’em na 127.0.0.1.

Dla kogo to jest, a kto powinien odpuścić

Botasaurus pasuje wtedy, gdy chcesz framework, a nie pojedynczy klocek. Jeśli zaczynasz projekt scrapingu od pustego pliku i wolisz przyjąć gotową strukturę niż budować ją samemu — dekoratory dla wejść, cache i równoległość obsługiwane, eksport wbudowany — to spójna, objęta MIT opcja. MIT jest liberalna, ale model użycia i dystrybucji i tak zasługuje na standardowy przegląd zgodności. Zespoły, które myślą w kategoriach Scrapy albo Crawlee, poczują się tu znajomo.

Warto odpuścić, albo przynajmniej dwa razy się zastanowić, jeśli środowisko wdrożenia jest wrażliwe na rozmiar. Instalacja 122 MB z numpy i gevent w drzewie to sporo, jeśli chcesz wrzucić to do smukłego kontenera, a tak naprawdę potrzebujesz po prostu „uruchomić przeglądarkę i pobrać kilka pól”. Wyspecjalizowany driver da ci automatyzację za ułamek tej wagi, ale kosztem samodzielnego zbudowania całej reszty. I odpuść całkowicie, jeśli chcesz odpowiedzi na pytanie o skuteczność anti-detection, bo właśnie tego nie testowałem — musiałbyś zaufać marketingowej obietnicy, której ani nie potwierdziłem, ani nie obaliłem.

Alternatywy i miejsce Thunderbit

Najpierw uczciwe ustawienie ramy: Botasaurus jest darmowy, na licencji MIT i self-hostowany. To ty utrzymujesz flotę, to ty zarządzasz aktualizacjami i to ty odpowiadasz za całe drzewo zależności — wszystkich 44 pakietów — włącznie z łatkami, zgodnością licencyjną i tym, co numpy postanowi zrobić w przyszłej wersji. Dla wielu zespołów taka kontrola to właśnie zaleta, a żaden usługowy produkt nie pobije „frameworka, który już masz” pod względem surowego kosztu.

W świecie open source sensowne porównania robi się po kształcie narzędzia. Jeśli jesteś po stronie frameworka tak jak Botasaurus, Scrapy i Crawlee są oczywistymi odpowiednikami do rozważenia — dojrzałe, opiniotwórcze i każde z własnym zestawem konwencji. Jeśli chcesz z jednej strony page-ready Markdown dla LLM-ów, a nie frameworka do budowy crawlera, Crawl4AI oraz nastawiona na treść Trafilatura są do tego celu bardziej bezpośrednie. Jeśli podoba ci się podejście Python + anti-detect, ale chcesz czegoś lżejszego niż meta-pakiet, warto spojrzeć na Scrapling, a jeśli w grę wchodzi język kompilowany, biblioteka Go Colly wymienia renderowanie JavaScriptu na szybkość i minimalny footprint. Każda opcja sterująca przeglądarką, w tym Botasaurus, dziedziczy profil kosztowy opisany w naszym porównaniu Playwright vs Puppeteer — prawdziwe przeglądarki nie są tanie w uruchamianiu, dlatego cały framework wokół nich waży tyle, ile waży.

Gdy na scenę wchodzi zarządzane API, to już inny etap tego samego pipeline’u. Botasaurus to self-hostowany stos deweloperski; Thunderbit oferuje zarządzany wariant, skierowany do tych samych programistów. Open API ma dwa endpointy. POST /distill (1 kredyt) zwraca stronę jako czysty, gotowy dla LLM Markdown, z renderowaniem i anti-bot obsługiwanymi po stronie serwera, więc nie trzeba provisionować ani przeglądarki, ani drzewa zależności. POST /extract (20 kredytów) zwraca ustrukturyzowany JSON według schematu JSON Schema, który definiujesz, z renderMode ustawionym na none, basic albo full w zależności od tego, ile przeglądarki faktycznie potrzebuje dana strona. Oba mają wersje batch dla nawet stu URL-i naraz. Jest też serwer MCP dla agentów i asystentów kodowania — thunderbit_suggest_fields jest darmowe i pokazuje, co strona wystawia, zanim cokolwiek wydasz — oraz CLI uruchamiane przez npx @thunderbit/thunderbit-cli do cronów i CI. Dla osób nietechnicznych, które nie chcą dotykać żadnej z tych rzeczy, rozszerzenie Chrome uruchamia ten sam silnik jako narzędzie no-code, a materiały na kanale Thunderbit na YouTube omawiają typowe workflowy.

Różnica polega na tym, gdzie leży praca, a nie na tym, które narzędzie jest „lepsze”. Botasaurus zostawia framework, flotę przeglądarek, zależności, infrastrukturę i utrzymanie po twojej stronie bez opłaty per request; compute, przepustowość, proxy i operacje nadal kosztują. Zarządzane API zabiera z twojego barku renderowanie i wynik w strukturze schematu, a płacisz za wywołanie — możesz to zestawić z własnym wdrożeniem na stronie cennika.

Wypróbuj Thunderbit do ekstrakcji danych z sieci

Werdykt końcowy

Botasaurus jest sensownym kandydatem, jeśli chcesz framework Python „all-in-one” i akceptujesz jego footprint zależności. Projekt trzech dekoratorów jest czysty, powierzchnia sterownika szeroka, a instalacja i import przeszły testy na wersjach Pythona nowszych niż te zadeklarowane w classifierach. Na moim lokalnym fixture’ie domyślny snapshot złapał też treści wstrzyknięte 300 ms po load, podczas gdy inne testowane stosy gubiły je już przy 100 ms; to jednak wynik dla fixture’u, a nie ogólny ranking.

Trzeba jednak odpowiednio skalować deklaracje. To instalacja 122 MB, 44 pakiety, gdzie sterownik ma około 4 MB, a reszta to numpy, lxml, gevent i spółka — mniej więcej 7x więcej niż wyspecjalizowany driver, a ta waga trafia do twojego obrazu kontenera i czasu cold deployu. 0,08 ms importu top-level to puste drzwi wejściowe, a nie lekki framework; to około 135 ms importu silnika wystawia ci rachunek. Ten pobłażliwy domyślny odczyt kosztuje około 250 ms przy każdej nawigacji. A w kwestii domyślnych ujawnień, którą mogłem rzeczywiście ocenić, obraz jest węższy niż sugeruje marketing: jeden boolean różni się od standardowego Puppeteera, user-agent w headless nadal mówi HeadlessChrome, a wszystkie pozostałe obserwowane przeze mnie właściwości były identyczne we wszystkich czterech stosach. Obietnica anti-detection, na której sprzedaje się ten produkt, to jedyna rzecz, której ta recenzja nie ocenia — potwierdziłem, że metody istnieją, uruchomiłem sterownik na stronie na własnej maszynie i na tym świadomie skończyłem. Jeśli znasz footprint, ignorujesz pochlebny numer importu i traktujesz marketing stealth jako otwarte pytanie, Botasaurus jest uczciwym frameworkiem, który robi dokładnie to, co framework ma robić. Jeśli oczekujesz lekkiego drivera, zaskoczy cię czas budowy Dockera.

Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free

FAQ

Czy Botasaurus jest darmowy i na jakiej jest licencji? Jest darmowy i na licencji MIT — zarówno meta-pakiet botasaurus, jak i silnik botasaurus-driver mają klasyfikator OSI-approved MIT. MIT jest liberalna, więc nie ma obowiązku copyleft i dobrze nadaje się do użycia komercyjnego, co stanowi wyraźny kontrast wobec porównywalnych driverów anti-detect wydawanych na AGPL-3.0. Jedno zastrzeżenie: MIT obejmuje własne pakiety Omkar Cloud, ale nie automatycznie około 40 zależności pośrednich pobieranych przy instalacji, więc przed wdrożeniem całego drzewa w firmie warto uruchomić własny skaner licencji.

Jak duża jest instalacja Botasaurus i dlaczego import botasaurus wygląda na natychmiastowy? Czyste pip install botasaurus utworzyło u mnie drzewo site-packages o rozmiarze 122,3 MB w 44 pakietach. Sam sterownik przeglądarki ma tylko około 4 MB — ciężar bierze się z tego, że meta-pakiet ciągnie szerokie drzewo zależności, na czele z numpy (30,9 MB), lxml (19,2 MB), botasaurus_requests (12,6 MB), gevent (11,3 MB) i pygments (8,4 MB). To mniej więcej 7x większy footprint niż w wyspecjalizowanym driverze takim jak nodriver na tej samej maszynie. Nie jest to wada; to koszt „baterii w zestawie”, a najbardziej ma znaczenie przy rozmiarze obrazu kontenera. Czas importu ukrywa ten footprint: import botasaurus mierzy około 0,08 ms, ale tylko dlatego, że top-level package jest niemal pusty — brak __version__, prawie brak publicznych nazw, więc import robi prawie nic. Import, który cię kosztuje, to silnik from botasaurus_driver import Driver, około 135 ms, z pamięcią rezydentną rzędu 29–30 MB po imporcie i przed uruchomieniem przeglądarki. Liczysz cold start serverless? Mierz import silnika, nie pusty top-level.

Co Botasaurus ujawnia o sobie i czy testowano go na prawdziwych systemach antybotowych? Pierwszą część zmierzono; druga część została celowo pominięta. Na stronie serwowanej z 127.0.0.1, przy tej samej wersji Chrome co w kontrolkach: navigator.webdriver zwraca false, podczas gdy stockowe Playwright i Puppeteer zwracają true. Ta wartość jest ustawiana przy starcie przeglądarki, a nie przez łatanie właściwości — descriptor pozostaje natywnym getterem Chrome. Poza tym booleanem niemal wszystko zgadzało się z kontrolkami: ten sam string platformy, pięć wtyczek, dwanaście rdzeni, 16 GB zgłaszanej pamięci urządzenia, ta sama struktura window.chrome, brak sprzeczności w API Permissions i brak śladów w stylu cdc_ w document i window. W trybie headless user-agent nadal ogłasza HeadlessChrome/151.0.0.0, tak samo jak obie kontrolki — konstruktor Driver ma parametr user_agent, ale nic nie ustawia go za ciebie. A jeśli chodzi o skuteczność: nigdy nie kierowałem sterownika na żywy serwis, nie kontaktowałem się z systemem antybotowym i nie dotykałem CAPTCHA. Sterownik ma wprawdzie zestaw metod nazwanych w stylu anti-detection, których istnienie potwierdziłem, ale nie wywoływałem ich, nie sprawdzałem ich zachowania na żadnym celu, nie mierzyłem skuteczności i nie opisywałem mechanizmu. Tabela ujawniania powyżej mówi tylko, co stos sam o sobie zdradza — i nic o tym, kto to ogląda ani co z tym robi.

Czy Botasaurus poprawnie obsługuje treści renderowane przez JavaScript? Tak, a jego domyślne zachowanie jest bardziej pobłażliwe niż u większości narzędzi. Na fixture’ie z trzema klasami treści driver.get() + driver.page_html zwróciło 2 z 3 przy opóźnieniu wstrzyknięcia 800 ms — JavaScript renderuje poprawnie, ale odczyt następuje zanim bardzo późna treść zdąży się pojawić — a driver.wait_for_element() zwróciło 3 z 3. Charakterystyczne jest to, gdzie domyślny odczyt odpuszcza: Botasaurus nadal łapie treści wstrzyknięte 300 ms po load, podczas gdy nodriver, Playwright i Puppeteer gubią je już przy 100 ms. To zasługa wait_for_complete_page_load=True w konstruktorze i kosztuje około 250 ms na nawigację.

Jak właściwie importować i używać Botasaurus po instalacji? Nie tak, jak byś zgadł. Przestrzeń top-level botasaurus jest niemal pusta, więc prawdziwe API siedzi w submodułach: from botasaurus.browser import browser, Driver, from botasaurus.request import request oraz from botasaurus.task import task. Oznaczasz zwykłą funkcję dekoratorem @browser, @request albo @task, a framework ogarnia resztę: sterownik, cache i eksport. Ponieważ nie ma botasaurus.__version__, użyj importlib.metadata, jeśli chcesz zalogować, jakiej wersji używasz.