Zbudowałem stronę-fiksturę, żeby sprawdzić ten obszar Colly, którego nie pokazuje ani liczba stron, ani reputacja szybkości: czy jego callbacki wyciągają oczekiwane rekordy, kierują błąd HTTP do właściwej obsługi, przechodzą po ograniczonym grafie i ujawniają treści dostarczane poza renderowanym HTML. To była analiza poprawności i granic działania, a nie test wydajności.
Na kontrolowanych fiksturach narzędzie wyodrębniło wszystkie oczekiwane statyczne rekordy, przekierowało jedną odpowiedź 500 do OnError i odwiedziło 17 adresów URL w grafie z ustawionym limitem głębokości. Zwróciło zero elementów docelowych na dwóch stronach, gdzie elementy pojawiały się dopiero po wykonaniu JavaScriptu. Bezpośrednio dostępny endpoint JSON pozostawał użyteczny bez przeglądarki — to ważna różnica względem renderowania interfejsu klienta.
Czym właściwie jest Colly
Colly określa się jako „elegancki framework do scrapingu i crawlowania dla Golanga”, i ten opis znaczy więcej, niż mogłoby się wydawać. To biblioteka Go — około 25 300 gwiazdek na GitHubie i 1 850 forków — na licencji Apache-2.0. To nie jest CLI, które po prostu pobierasz i podajesz mu URL. Piszesz kod w Go, importujesz Colly, rejestrujesz kilka callbacków i kompilujesz wszystko do jednego pliku wykonywalnego.
Model działania jest oparty na zdarzeniach. Do Collector podłączasz handlery: OnHTML uruchamia logikę ekstrakcji dla dopasowanych selektorów CSS, OnResponse udostępnia surową treść odpowiedzi, a OnError obsługuje błędy żądań. Handlery linków wywołują Visit() dla wykrytych adresów URL, a MaxDepth ogranicza przechodzenie po kolejnych stronach. Dla tych ścieżek opartych wyłącznie na HTTP docelowy host nie potrzebuje osobno zainstalowanego środowiska Go ani przeglądarki; to, czy wynikowy plik wykonywalny jest w pełni statyczny, zależy od flag kompilacji i użycia CGO, czego ten test nie rejestrował.
Kluczowe funkcje i jak działają pod spodem
Najważniejszy jest model callbacków, bo właśnie dlatego Colly działa inaczej niż skrypt typu request-and-parse. Trzy callbacki obsłużyły każdy test, który przeprowadziłem.
OnHTML(selector, handler) to główna siła napędowa. Rejestrujesz go dla .product albo article p, a Colly wywołuje handler raz dla każdego dopasowanego elementu podczas parsowania DOM. To tutaj odbywa się strukturalna ekstrakcja — opisujesz, co chcesz pobrać, zamiast pisać pętlę parsującą.
OnResponse(handler) działa niżej i daje surowe bajty. Gdy docelowa usługa zwraca JSON zamiast HTML, możesz całkowicie pominąć DOM i samodzielnie zdeserializować treść odpowiedzi. To właśnie ten pojedynczy callback sprawił, że Colly bez problemu obsłużył API JSON w moich testach, bez jakiegokolwiek parsowania HTML.
OnError(handler) obsługuje błędy żądań i może przekazać kod statusu odpowiedzi do kodu wywołującego. W tym teście jedna fikstura z kodem 500 trafiła do zarejestrowanego callbacka. Nie testowano ponowień, timeoutów, błędów DNS, resetów połączeń, wyjątków w callbackach, trwałości danych ani alertowania.
Na tych callbackach opierają się też dwie funkcje operacyjne. MaxDepth ogranicza przechodzenie po linkach zgodnie z semantyką głębokości Colly. Skompilowany plik wykonywalny Go eliminuje potrzebę osobno instalowanego runtime języka na hoście docelowym. Ta sesja nie zapisała flag kompilacji ani statusu CGO, więc nie twierdzi, że każdy taki binarny plik jest w pełni statyczny.
Konfiguracja: wymagany toolchain Go
Historia zależności jest krótka, ale realna, więc warto ją wyjaśnić, zanim cokolwiek zainstalujesz. Maszyna, na której testowałem, nie miała zainstalowanego Go, a Colly to biblioteka Go — więc krok zerowy polegał na dołożeniu toolchaina Go do systemu (zainstalowałem Go 1.26.5 przez Homebrew). Jeśli Twój zespół nie działa już w ekosystemie Go, to właśnie jest tarcie: nie Colly samo w sobie, tylko środowisko językowe, którego potrzebuje jeszcze przed kompilacją pierwszej linii.
Gdy Go było gotowe, go get github.com/gocolly/colly/v2 rozwiązało się do wersji v2.3.0. Testowane ścieżki nie wymagały przeglądarki ani headless Chrome.
Jedna rzecz dotycząca wersji może mylić czytelników. Moduł Go wskazał na v2.3.0 (opublikowaną w grudniu 2025), podczas gdy najnowszy wpis widoczny w interfejsie GitHub Releases to v2.2.0 (marzec 2025). To różnica między wersją modułu/repozytorium a wpisem w GitHub Releases, a nie między modułem a tagiem Git. Testowałem v2.3.0.
Test praktyczny: ekstrakcja i granice działania
Uruchomiłem Colly na samowystarczalnym serwerze fikstur (Go httptest) oraz dwóch publicznych serwisach demonstracyjnych. Aktualny katalog benchmarków i plik results/colly-test-summary.json pokazują artefakty, ale oba linki prowadzą do gałęzi, która może się zmieniać. Artykuł nie podaje testowanego commita, dokładnej komendy, flag kompilacji ani seeda fikstur, więc nie jest to jeszcze niezmienny przepis reprodukcji.
| Test | Cel | Wynik |
|---|---|---|
| Statyczny katalog + paginacja | lokalna fikstura | 12/12 oczekiwanych produktów wyodrębnionych |
| Ekstrakcja artykułu | lokalna fikstura | tytuł + 3/3 akapity |
| Bezpośrednia odpowiedź JSON | lokalna fikstura | 8/8 oczekiwanych elementów przez OnResponse |
| Obsługa HTTP 500 | lokalna fikstura | przekazano do OnError, status 500 |
Graf crawlowania (MaxDepth 2) | lokalna fikstura | 17 stron |
| Books to Scrape | publiczny demo | 20 produktów |
| Strona dynamiczna (bez JS) | lokalna fikstura | 0 kart (zgodnie z oczekiwaniem) |
| Quotes JS (bez renderowania) | publiczny demo | 0 (zgodnie z oczekiwaniem) |
Na kontrolowanych statycznych fiksturach skonfigurowane selektory zwróciły 12 z 12 oczekiwanych rekordów produktów i wszystkie trzy oczekiwane akapity artykułu. Bezpośrednia odpowiedź JSON nie trafiła do parsera HTML: OnResponse przekazał treść, a harness zdekodował wszystkie osiem oczekiwanych elementów. Jedna fikstura 500 dotarła do OnError z ujawnionym statusem i nie spowodowała awarii podczas tego uruchomienia; nie dowodzi to jednak bezobsługowej niezawodności. Na publicznej stronie Books to Scrape selektor zwrócił 20 produktów jako szybki test na żywym serwisie.
Do przechodzenia po grafie kolektor został skonfigurowany z MaxDepth(2) według konwencji głębokości użytej w harnessie i odwiedził 17 adresów URL w grafie fikstury. To wynik pokrycia crawlowania, nie szybkości. Zaobserwowany ślad — a nie szersze twierdzenie o dowolnych grafach — znajduje się w results/local_crawl_graph.json.
Colly nie uruchamia JavaScriptu. Fikstura renderowana po stronie JS zwróciła 0 docelowych kart, a publiczna strona Quotes to Scrape JS zwróciła 0 docelowych cytatów. Jeśli elementy istnieją dopiero po wykonaniu w przeglądarce i nie ma dostępnego endpointu zaplecza, który je udostępnia, ścieżka tylko-HTTP nie zobaczy tych elementów jako renderowanego DOM. Połącz Colly z rendererem albo odwołaj się bezpośrednio do endpointu zaplecza, jeśli jest dostępny — tak jak pokazuje to fikstura JSON.
Nie testowałem kolektora asynchronicznego, limitowania tempa ani ustawień uprzejmości, rotacji proxy, ponowień, ani backendów kolejki i magazynu. Nie mierzono czasu, throughputu, współbieżności, CPU, pamięci, opóźnienia po stronie celu ani punktu odniesienia do porównania. Ten artykuł nie formułuje więc żadnego twierdzenia o szybkości ani o niezawodności bez nadzoru.
Jak interpretować wyniki z fikstur
Trzy udane ścieżki treści sprawdzają różne kontrakty. Przypadki katalogu i artykułu testują selekcję CSS na HTML zwracanym przez serwer. Ich mianownikiem są oczekiwania z fikstury zapisane przed ekstrakcją: dwanaście rekordów produktów i trzy akapity artykułu. Opisanie tego jako „wyodrębniono oczekiwane rekordy” jest celowe. To uruchomienie nie definiuje dopasowania przybliżonego, obsługi duplikatów, tolerancji dla częściowo brakujących pól ani metryki recall dla całego korpusu, więc wynik nie powinien być przedstawiany jako ogólna dokładność ekstrakcji.
Przypadek JSON omija selekcję DOM. Colly otrzymuje bajty odpowiedzi przez OnResponse, a harness wykonuje dekodowanie JSON. Właśnie dlatego stwierdzenie „Colly nie renderuje JavaScriptu” nie oznacza, że każda strona oparta o klienta jest niedostępna. Jeśli źródłem danych dla klienta jest endpoint, który można wywołać bezpośrednio i żądanie da się odtworzyć poza przeglądarką, crawler HTTP może wciąż wystarczyć. Uwierzytelnianie, generowane podpisy, stan dostępny tylko w przeglądarce i mechanizmy antybotowe mogą zmienić odpowiedź; nic z tego nie było tutaj testowane.
Obsługa 500 testuje przekazanie zdarzenia, a nie odporność. Pokazuje, że zarejestrowany callback OnError otrzymał tę odpowiedź z fikstury wraz ze statusem. Crawler produkcyjny nadal potrzebuje jawnej polityki dla kodów, które można ponawiać, dla backoffu, błędów terminalnych, trwałości oraz alertów. Test nie dostarcza dowodów na te decyzje, a stwierdzenie „callback zadziałał” nie powinno być czytane jako „zadanie można bezpiecznie puścić bez nadzoru”.
Graf z 17 adresami jest równie wąski. Potwierdza zbiór odwiedzonych stron wygenerowany przez tę fiksturę, tę konwencję seeda i MaxDepth(2). Nie mówi nic o stronach na sekundę, sprawiedliwości między hostami, wzroście pamięci ani zachowaniu na cyklach i zduplikowanych formach URL. To wymaga osobnych testów obciążenia i kolejek.
Lista wyboru oparta na tym uruchomieniu
Zacznij od sprawdzenia, co Colly faktycznie otrzymuje w odpowiedzi. Jeśli potrzebne pola są obecne w HTML zwracanym przez serwer, użyj OnHTML i zweryfikuj liczbę pól lub wymagane klucze, zanim zaakceptujesz rekord. Jeśli odpowiedź to JSON, obsłuż treść przez OnResponse i sprawdź jej schemat. Jeśli HTML jest tylko powłoką aplikacji, sprawdź, czy dostępne żądanie zaplecza zawiera dane, zanim dodasz przeglądarkę.
| Co zawiera odpowiedź | Ścieżka w Colly | Kryterium akceptacji |
|---|---|---|
| Wymagane pola w HTML zwracanym przez serwer | selektory OnHTML | wymagane klucze i oczekiwana liczba rekordów |
| Bezpośrednio wywoływalny payload JSON | OnResponse + dekodowanie JSON | walidacja schematu i wymaganych pól |
| Powłoka HTML wsparta przez odtwarzalne żądanie | wywołanie endpointu zaplecza | status odpowiedzi, schemat i kompletność |
| Dane tworzone dopiero po wykonaniu w przeglądarce | dodaj renderer albo użyj crawlera przeglądarkowego | gotowość i kompletność specyficzna dla celu |
Gdy konieczne jest wykonanie w przeglądarce, traktuj je jak kolejny komponent, a nie jak coś, co można włączyć samą flagą Colly. Przeglądarka musi potwierdzić gotowość, udostępnić renderowaną treść lub odpowiedzi zaplecza i przekazać dane do dalszej części pipeline’u. Ta recenzja nie testowała takiej integracji.
Przed wdrożeniem zapisz wersję Go, wersję modułu, flagi kompilacji, status CGO, dokładną komendę, seed fikstury i commit repozytorium. Tych danych brakuje w obecnych linkach do publikacji, a to właśnie różnica między artefaktami możliwymi do obejrzenia a trwałą reprodukcją. W operacjach dodaj macierz awarii i zmierz obciążenie, które naprawdę Cię interesuje, zanim nazwiesz system szybkim lub niezawodnym.
Plusy i minusy
Plusy:
- Wyodrębnił 12/12 oczekiwanych produktów z katalogu i 3/3 oczekiwanych akapitów artykułu przez
OnHTML. - Czysta obsługa JSON przez
OnResponse, bez potrzeby parsowania DOM — 8/8 elementów API. - Testowana odpowiedź 500 trafiła do
OnError, a status został ujawniony. - Crawlowanie z limitem głębokości osiągnęło 17 stron z jednego kolektora.
- Kompiluje się do pliku wykonywalnego Go; dla testowanych ścieżek host nie potrzebuje osobno zainstalowanego runtime Go.
- Liberalna licencja Apache-2.0.
Minusy:
- Brak wykonywania JavaScriptu — treści renderowane po stronie klienta zwracają 0, bez wyjątków.
- Wymaga toolchaina Go; zespoły spoza Go płacą koszt konfiguracji jeszcze przed napisaniem pierwszego scrapera.
- Testowany moduł (
v2.3.0) wyprzedza najnowszy widoczny wpis GitHub Release (v2.2.0). - Wynikowy kod jest Twój — Colly daje callbacki, a nie wbudowany dataset/eksporter feedu jak Scrapy.
- Asynchroniczność, limity tempa, proxy i backendy kolejki są dostępne, ale tutaj nie były testowane; throughput i skala pozostają niezmierzone.
Dla kogo to jest — a kto powinien pominąć
Colly pasuje, jeśli już piszesz w Go i celujesz w HTML renderowany po stronie serwera albo bezpośrednio dostępny JSON. Model callbacków rozdziela dopasowania strukturalne, surowe payloady i błędy żądań. Skompilowany plik wykonywalny eliminuje też potrzebę osobno instalowanego środowiska językowego na maszynie docelowej, choć pełnego statycznego linkowania tutaj nie zweryfikowano.
Dodaj renderer, gdy wymagane elementy pojawiają się dopiero po wykonaniu w przeglądarce i nie ma użytecznego endpointu zaplecza. Bezpośredni endpoint JSON nadal można wywołać bez renderowania. Colly jest też słabszym wyborem dla zespołów, które nie chcą toolchaina Go albo oczekują usługi ekstrakcji, która sama zajmie się kształtowaniem schematu i utrzymaniem selektorów.
Alternatywy, w tym miejsce Thunderbit
Colly to open-source, które uruchamiasz samodzielnie. Nie ma opłaty licencyjnej od dostawcy, ale Twoimi kosztami pozostają moc obliczeniowa, transfer, proxy, storage, observability i praca inżynierska. To Ty odpowiadasz za zachowanie żądań, callbacki parsujące, logikę crawlowania i integrację z przeglądarką, jeśli cel wymaga renderowania.
Zarządzana usługa ekstrakcji przenosi część tych obowiązków na dostawcę. Tworzymy Thunderbit, ale nie testowaliśmy go na tych fiksturach, więc ten artykuł nie porównuje renderowania, anty-bota, jakości, opóźnień ani kosztów. Różnica, którą można tu potwierdzić, to odpowiedzialność: Colly udostępnia odpowiedzi HTTP i callbacki w Twoim procesie Go; usługa zarządzana może przejąć pozyskiwanie danych i kształtowanie schematu w modelu płatności za wywołanie.
Powiązane recenzje benchmarków: pełne porównanie open-source scraperów, recenzja crawlera Scrapy w Pythonie oraz recenzja adaptacyjnych selektorów Scrapling.
Wypróbuj Thunderbit do ekstrakcji danych z sieci
Werdykt
Colly to mocny kandydat dla zespołów Go, które celują w HTML renderowany po stronie serwera albo bezpośredni JSON i są gotowe samodzielnie utrzymywać kod ekstrakcji. Fikstury potwierdzają wyodrębnianie oczekiwanych rekordów, jeden ograniczony ślad crawlowania i jedno zaobserwowane wywołanie callbacka dla 500 — ale nie szybkość, skalę ani niezawodność bez nadzoru. DOM renderowany w przeglądarce wymaga innej ścieżki, chyba że można bezpośrednio odwołać się do źródłowego endpointu danych.
Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free
FAQ
Czy ta recenzja mierzyła szybkość Colly? Nie. Mierzono wyodrębnianie oczekiwanych rekordów, bezpośrednią obsługę JSON, jeden callback błędu oraz pokrycie grafu crawlowania w fiksturach. Nie mierzono czasu całkowitego, throughputu, współbieżności, CPU, pamięci ani punktu odniesienia do porównania.
Czy Colly potrafi scrapować strony renderowane przez JavaScript? Colly nie wykonuje JavaScriptu strony. Testowana ścieżka HTTP nie znalazła więc żadnych docelowych elementów, które pojawiały się tylko w renderowanym DOM. Może jednak bezpośrednio odwołać się do dostępnego endpointu JSON, jak pokazuje fikstura JSON. Użyj renderera, gdy wykonanie jest konieczne i nie ma odtwarzalnego żądania zaplecza, które dostarcza dane.
Czy muszę znać Go, żeby używać Colly?
Tak. Colly to biblioteka Go, a nie samodzielny CLI — importujesz ją, rejestrujesz callbacki (OnHTML, OnResponse, OnError) i kompilujesz. Na maszynie, na której testowałem, nie było Go, więc konfigurację zacząłem od instalacji toolchaina Go (1.26.5). Jeśli Twój zespół nie pracuje już w Go, to właśnie to środowisko jest realnym kosztem wdrożenia.
Dlaczego wersja, którą instaluję, nie zgadza się z najnowszym releasem Colly na GitHubie?
Moduł Go rozwiązał się do v2.3.0 (grudzień 2025), podczas gdy najnowszy widoczny wpis w GitHub Releases to v2.2.0 (marzec 2025). Testowałem v2.3.0; to różnica między powierzchniami wersji, a nie dowód na uszkodzoną instalację.
Czy Colly jest darmowy do użytku komercyjnego? Tak, ma licencję Apache-2.0, która jest liberalna i przyjazna dla zastosowań komercyjnych. Jak zawsze, przed wdrożeniem warto potwierdzić aktualną licencję w repozytorium.
Przed wdrożeniem produkcyjnym dodaj testy odpowiadające realnemu ryzyku operacyjnemu, zamiast rozszerzać wynik z fikstur przez analogię. Zmierz czas wielokrotnych crawlów na reprezentatywnych celach, zapisz CPU i maksymalne zużycie pamięci, przetestuj błędy, które można ponowić, i te terminalne oraz sprawdź uprzejmość pod obciążeniem współbieżnym. Jeśli ważna jest trwałość, zatrzymaj i wznowij crawl, obserwując obsługę duplikatów i stan kolejki. Jeśli liczy się prostota wdrożenia, zapisz dokładną konfigurację kompilatora i linkera oraz sprawdź zależności runtime wynikowego pliku wykonywalnego. Żaden z tych testów nie zmienia tego, co potwierdziła obecna fikstura; to one decydują, czy ta sama konfiguracja biblioteki pasuje do konkretnego zadania produkcyjnego.
