عندما تبحث عن كلمة "Colly" ستجد أن أول صفة تُقال عنه دائمًا هي نفسها: سريع. زاحف Go سريع، وسريع لأنه يُترجم إلى ملف تنفيذي، وسريع لأنه ما فيه متصفح يبطّئه. لكن نادرًا ما أحد يحط رقم واضح مع هذا الكلام.
لذلك ما اكتفيت بالوصف. أنشأت موقعًا تجريبيًا صغيرًا، وجرّبت Colly عليه، ثم راقبت المكتبة وهي تشتغل فعلًا: كيف تسترجع البيانات من الصفحات الحقيقية، وكيف تتعامل مع الطلبات الفاشلة، وإلى أي درجة تقدر تتحرك ضمن زحف محدود العمق. والخلاصة المختصرة قبل الدخول في الأرقام: الاستخراج من الصفحات الثابتة كان كاملًا من ناحية الاسترجاع، وخطأ 500 وصل إلى المكان الصحيح بالضبط، وزحف بحد عمق محدد وصل إلى 17 صفحة من ملف تنفيذي ثابت واحد، من دون أي متصفح مرفق. كما أن المكتبة رجّعت نتيجة صفر نظيفة في كل شيء يعتمد على JavaScript — وهي بالضبط النقطة التي كثير ناس يتجاهلونها وهم يتكلمون عن "السرعة".
ما هو Colly فعلًا وما الذي ليس كذلك
Colly يعرّف نفسه بأنه "إطار عمل أنيق للكشط والزحف في Golang"، وهذه الجملة القصيرة تحمل أكثر مما تبدو عليه. هو مكتبة Go — وبحلول 2026-07-09 كان عنده حوالي ~25.4k نجمة على gocolly/colly، مع ترخيص Apache-2.0. وهو ليس أداة سطر أوامر تنزّلها وتشغّلها على رابط. أنت تكتب Go، وتستورد الحزمة، وتربط مجموعة من الدوال الراجعة، ثم تطلع بالنتيجة كملف تنفيذي واحد.
النموذج الذهني هنا قائم على الأحداث، وهذا اللي يربك كثير من الناس القادمين من أسلوب الطلب ثم التحليل. أنت ما تتنقل بين الاستجابة وتستخرج الحقول سطرًا بسطر. بدل هذا، تربط معالجات بـ Collector وتخلي المكتبة تشغّلها أثناء مرورها على الصفحات. OnHTML ينفذ منطق الاستخراج كلما ظهر محدد CSS مطابق. OnResponse يعطيك نص الاستجابة الخام، وهذا مهم لما تكون الحمولة JSON بدل HTML. OnError يلتقط الطلبات الفاشلة. والزحف يشتغل بالطريقة نفسها: داخل معالج الروابط، تستدعي Visit() على العناوين التي تجدها، فتضعها Colly في طابور، بينما MaxDepth يحدد إلى أي مدى يُسمح للزحف بالذهاب. دوال راجعة، وطابور زيارة، وحد عمق، وتوليد ثابت. لا مترجم تفسيري، لا بيئة تشغيل، ولا Chrome بلا رأس يستهلك الذاكرة.
نموذج الدوال الراجعة ولماذا يغيّر طريقة شعورك بالاستخراج
الدوال الراجعة هي روح الأداة فعلًا، لذلك تستحق وقفة قصيرة. ثلاثة منها كانت كافية لكل اختبار نفذته.
OnHTML(selector, handler) هو الأكثر استخدامًا. اربطه بـ .product أو article p، وColly راح يستدعي معالجك مرة لكل عنصر مطابق أثناء تحليل DOM. هنا يعيش الاستخراج المنظم، وهو مريح بالقراءة — أنت تصف ما تريده، لا الحلقة التي تجيبه.
OnResponse(handler) يشتغل على مستوى أدنى ويعطيك البايتات الخام من الشبكة. عندما يرجع الهدف JSON بدل الوسوم، ما تلمس DOM أصلًا — بل تفك تسلسل الجسم بنفسك. هذه الدالة وحدها هي السبب في أن Colly تعامل مع API بصيغة JSON في تجربتي من دون أن يحلل أي جزء من HTML.
OnError(handler) هي الدالة التي ينساها الجميع إلى أن تتعطل أداة الكشط عند الثالثة صباحًا. تُستدعى عندما يفشل الطلب، وتمنحك الاستجابة حتى تقرأ رمز الحالة وتقرر الخطوة التالية. الزاحف الذي يبتلع الفشل بصمت أسوأ من الذي ينهار بصوت عالٍ؛ وColly ما يسوي أيًا منهما، وهذه نقطة أهم مما تبدو عليه عندما تترك الشغل يمشي من غير مراقبة.
فيه ميزتان إضافيتان فوق هذه الدوال وتهمان من ناحية التشغيل. MaxDepth يضع سقفًا للزحف، بحيث يتوقف جامع الروابط بعد خطوتين بدل ما يتمشى في الويب المفتوح. أما ناتج البناء فهو ملف Go ثابت واحد — تبنيه مرة واحدة، وتحصل على ملف واحد بلا تبعيات تشغيل، وتحطه على خادم أو داخل مهمة CI وتبدأ الشغل. وإذا سبق وضيعت لك فترة بعد الظهر بسبب بيئة Python افتراضية على جهاز جديد، فبتشوف إن هذا الأسلوب في النشر ميزة حقيقية، مو مجرد ملاحظة جانبية.
الإعداد — سلسلة أدوات Go التي ما أحد يذكرها
قصة الاعتماديات قصيرة، لكنها فيها نقطة احتكاك حقيقية، لذلك أذكرها قبل أي تثبيت. الجهاز الذي اختبرته ما كان عليه Go أصلًا، وColly مكتبة Go، فكانت الخطوة صفر هي تثبيت سلسلة الأدوات على الجهاز — وقد ثبّتُّ Go 1.26.5 عبر Homebrew. إذا فريقك أصلًا ما يشتغل داخل بيئة Go، فهذه هي المعاناة الحقيقية. ليست المكتبة. بل بيئة اللغة التي تحتاجها قبل أول سطر يُترجم.
بعد توفر Go، كان جلب Colly سهل جدًا. go get github.com/gocolly/colly/v2 وصل إلى v2.3.0 من غير أي تعقيد — لا متصفح، لا headless، لا شيء سوى الملف التنفيذي في النهاية. وإذا قارنت هذا بكواشف Python التي تثبت محلل ثم تنهار عند أول جلب بسبب سلسلة من الحزم الناقصة، راح تلاحظ أن التجربة كانت مملة بشكل مريح. والممل هنا مدح.
وفيه ملاحظة دقيقة لازم تنقال بوضوح، لأنها بتربكك إذا رحت تدور في التفاصيل. أحدث module على Go proxy هو v2.3.0، وصدر في ديسمبر 2025. أما أحدث إصدار موسوم على GitHub فهو v2.2.0 من مارس 2025. لذلك الكود الذي اختبرته — v2.3.0 — أحدث مما يظهر في صفحة Releases داخل المستودع. هذه مجرد خاصية من تباعد نسخ Go modules عن وسوم GitHub مع الوقت، وليست علامة على مشكلة. فقط لا تستغرب عندما يعطيك go get وصفحة Releases رقمين مختلفين.
التجربة العملية — الأرقام وراء كلمة "سريع"
اختبرت Colly على خادم تجريبي ذاتي الاحتواء مبني على httptest من Go، بالإضافة إلى موقعين عامين تجريبيين، بحيث تكون النتيجة قابلة لإعادة الإنتاج، مو مجرد حكاية أرويها لك. وهذا اللي ظهر.
| الاختبار | الهدف | النتيجة |
|---|---|---|
| كتالوج ثابت + ترقيم صفحات | fixture محلي | 12/12 منتجًا، استرجاع 1.0 |
| استخراج مقال | fixture محلي | العنوان + 3/3 فقرات |
| API JSON ديناميكي | fixture محلي | 8/8 عناصر عبر OnResponse، استرجاع 1.0 |
| التعامل مع HTTP 500 | fixture محلي | تم توجيهه إلى OnError، الحالة 500 |
رسم بياني للزحف (MaxDepth 2) | fixture محلي | 17 صفحة |
| Books to Scrape | عرض عام | 20 منتجًا |
| صفحة ديناميكية (بدون JS) | fixture محلي | 0 بطاقات (متوقع) |
| Quotes JS (بدون عرض) | عرض عام | 0 (متوقع) |
إذا قرأت النتائج من فوق لتحت، راح تلاحظ الصورة مترابطة. الاستخراج الثابت كان نظيفًا — 12 من 12 منتجًا من الكتالوج، وكل الفقرات الثلاث من المقال، وكل هذا بفضل محددات OnHTML. أما اختبار JSON API فلم يفتح محلل HTML أصلًا: دالة OnResponse سلّمتني الجسم، وأنا فككت التسلسل بنفسي، فطلعت النتيجة 8 من 8 عناصر. واختبار 500 هو اللي أعتمد عليه أكثر من غيره، لأنه الحد الفاصل بين زاحف تقدر تخليه يشتغل طول الليل وزاحف ما تقدر؛ Colly أوصل الفشل إلى OnError وبيّن رمز الحالة بوضوح، من دون انهيار ولا تجاهل صامت. وعلى العرض العام Books to Scrape استخرج 20 منتجًا من غير أي معالجة خاصة.
أما نتيجة الزحف فهي الأهم، وأبغى أصيغها بدقة. جامع باستخدام MaxDepth(2)، ومع تتبع الروابط وتحويلها إلى عناوين مطلقة، وصل إلى 17 صفحة عبر الرسم البياني الموجود في fixture الخاص بي. وهذه أول مرة يصير فيها وصف "زاحف Go سريع" مرتبط بعدد صفحات حقيقي، مو مجرد انطباع. لكن انتبه للصياغة: 17 صفحة ضمن زحف بعمق 2. رقم العمق هنا هو عداد بيئة الاختبار نفسها، ويصف كيف ضبطت التنفيذ؛ وأنا ما أدّعي أن Colly يضمن داخليًا "عمق 2 فقط، ولا خطوة إضافية" كعقدة ثابتة. والعبارة الدقيقة القابلة للتحقق هي: مع وضع سقف للعمق عند 2، اجتاح الزحف الرسم البياني ووصل إلى 17 صفحة.
وهنا السقف اللي غالبًا يسكت عنده اللي يبالغون في الحديث عن السرعة. Colly ما يشغّل JavaScript. وجهته إلى fixture يعتمد على JavaScript فكانت النتيجة 0 بطاقة؛ ووجهته إلى صفحة Quotes to Scrape JS العامة فكانت النتيجة 0 مرة ثانية. هذا ليس خطأ، وليس عيبًا. Colly هو زاحف HTTP — ينزل HTML ويحلله، لكنه ما يشغل متصفحًا لتنفيذ السكربتات الجانبية. مثل Scrapy وغيره من الزواحف اللي تعتمد على HTTP أولًا، إذا كان المحتوى الذي تريده ما يظهر إلا بعد تنفيذ JavaScript، فColly راح يعطيك نتيجة فارغة كل مرة، وما فيه أي سرعة خام تقدر تغيّر هذه الحقيقة. يا تربطه بمُعرِّض Rendering، أو تختار أداة فيها هذا المكوّن من الأساس.
وبنفس الوضوح، لازم أقول ما اختبرته حتى ما أحد يوسع نتائجي أكثر من الأدلة. ما اختبرت collector غير المتزامن، ولا إعدادات تحديد المعدل ولطف الطلبات، ولا تدوير البروكسيات، ولا مخازن الطوابير والتخزين. هذه كلها موجودة في Colly. لكنني اختبرت نواة الاستخراج والزحف، مو البنية التشغيلية عند التوسع. وملف README يذكر أنه يحقق أكثر من ألف طلب في الثانية على نواة واحدة، لكن هذا رقم المشروع نفسه — أنا قست عدد الصفحات والاسترجاع، لا معدل النقل، لذلك لما أقول "سريع" فأنا أقصد مسار الاستخراج المبني بـ Go الذي قسته فعليًا، مو مقارنة مباشرة مع Scrapy ما سويتها.
المزايا والعيوب
المزايا:
- استرجاع كامل في الاستخراج الثابت — 12/12 من منتجات الكتالوج و3/3 من فقرات المقال عبر
OnHTML. - التعامل النظيف مع JSON عبر
OnResponseمن دون الحاجة إلى تحليل DOM — 8/8 عناصر API. - توجيه الفشل بشكل صحيح — وصل خطأ 500 إلى
OnErrorمع إظهار الحالة، من دون انهيار. - زحف محدود العمق وصل إلى 17 صفحة من جامع واحد.
- ملف Go ثابت واحد، بلا تبعيات تشغيل — نموذج نشر وتشغيل ممتاز جدًا.
- ترخيص Apache-2.0 المرن.
العيوب:
- لا ينفذ JavaScript — المحتوى المولّد على جهة العميل يرجع صفرًا، من دون استثناء.
- يحتاج إلى سلسلة أدوات Go؛ الفرق اللي ما تشتغل أصلًا بـ Go تدفع تكلفة الإعداد قبل كتابة أي كاشف.
- أحدث module (
v2.3.0) يتقدم على أحدث إصدار موسوم (v2.2.0)، وهذا قد يربك من يقرأ صفحة Releases. - الناتج النهائي هو كودك أنت — Colly يعطيك دوالًا راجعة، لا مجموعة بيانات جاهزة أو مُصدِّر موجز مثل Scrapy.
- فيه بنية متزامنة وتحديد معدل والبروكسي والطوابير، لكن ما اختبرتها هنا؛ و"السريع" هنا يعني مسار الاستخراج الذي قسته، لا رقم throughput مباشر.
لمن يناسب Colly ومن الأفضل له أن يتجاوزه
Colly مناسب إذا كنت تكتب Go أصلًا وتزحف إلى مواقع تعتمد على HTML أو JSON وبسرعة. وإذا كان تعريفك للنشر النظيف هو نسخ ملف تنفيذي واحد إلى جهاز وتشغيله — من دون مترجم تفسيري، من دون virtualenv، ومن دون دوامة الاعتماديات — فهذه الأداة مصممة لهذا الأسلوب بالضبط. نموذج الدوال الراجعة يثبت قيمته أول ما يتجاوز الاستخراج مرحلة البساطة: OnHTML للبنية، وOnResponse للحمولات الخام، وOnError للأخطاء التي قد ما تشوفها أصلًا لولا ذلك. ولأهداف ثابتة أو قائمة على API وتزحف إليها وفق جدول CI، فهو خيار قوي وبلا دراما.
أما إذا كانت أهدافك تعتمد على JavaScript، فالأفضل تتجاوزه أو تربطه بأداة ثانية على الأقل. Colly رجّع 0 على كل صفحة تعتمد على جهة العميل جرّبتها معه، وهذا مقصود في تصميمه وليس خيارًا تقدر تبدله. وتجاوزه أيضًا إذا فريقك ما يشتغل مع Go وما تبي تشغّل سلسلة أدوات كاملة فقط من أجل كشط عدة مواقع — فالتزام اللغة هنا حقيقي وراح يبقى عليك. وإذا كنت تريد بيانات منظمة تُسلَّم لك بدل ما يكتبها كودك، فدوال Colly الراجعة تخلّي هذا العبء عليك بشكل واضح.
البدائل — أين تناسبك واجهة كشط مدعومة بالذكاء الاصطناعي
Colly مكتبة مجانية مفتوحة المصدر تبنيها وتشغّلها بنفسك. أنت تملك كود Go، والدوال الراجعة، ومنطق الزحف، والجهاز الذي يشتغل عليه — وفي المقابل ما تدفع شيء لكل طلب وتبقي العملية كلها داخل مؤسستك. بالنسبة لفريق يعمل بـ Go، هذا حل يمكن الدفاع عنه، والنشر كملف واحد مريح فعلًا.
لكن فيه نقطتان يتوقف عندهما، وهما بالضبط ما يستحق المقارنة مع شيء آخر. أولًا، JavaScript — Colly ما يعرضه، لذا أي شيء يعتمد على جهة العميل خارج الحساب إلا إذا أضفت متصفحًا خارجيًا. ثانيًا، البنية — Colly يعطيك دوالًا راجعة ويترك لك تشكيل المخرجات النظيفة. واجهة كشط مدعومة بالذكاء الاصطناعي ومُدارة تحل هاتين المسألتين بطريقة مختلفة. حزمة المطورين في Thunderbit تتكفل بعرض JavaScript وتعيد بيانات منظمة من جهة الخادم. POST /distill يحوّل الصفحة إلى Markdown نظيف جاهز لـ LLM، مع التعامل مع المحتوى الديناميكي ومكافحة الحظر نيابة عنك. وPOST /extract يعيد JSON منظمًا وفق JSON Schema تحدده أنت، مع renderMode تقدر ترفعه إلى عرض متصفح كامل عندما تحتاج الصفحة لذلك. وهناك خادم Thunderbit MCP للوكلاء الذكيين ومساعدي البرمجة — thunderbit_suggest_fields مجاني، بحيث تقدر تستكشف ما تكشفه الصفحة قبل الالتزام — بالإضافة إلى CLI تقدر تشغله عبر npx @thunderbit/thunderbit-cli للاستخدام من الطرفية وCI وcron.
جرّب Thunderbit لاستخراج بيانات الويب
المفاضلة ليست أفضل مقابل أسوأ. بل أين يصير الشغل. مع Colly يبقى العرض — أو بالأصح غيابه — والتحليل والصيانة داخل الملف التنفيذي الذي بنيته بنفسك، من دون تكلفة لكل استدعاء، وعليك أنت أن ترعاه عندما يتغير شكل الموقع. أما مع واجهة مُدارة فتنقل عرض JavaScript ومكافحة الحظر والمخرجات المنظمة إلى الخارج، وتدفع مقابل كل استدعاء لقاء هذه الراحة. هل تتعامل مع أهداف صغيرة، أصلها Go، وتعتمد على HTML أو JSON، وأنت مرتاح تتحمل مسؤولية صيانتها؟ هنا يتفوق Colly بالتحكم والسرعة. أما الصفحات الثقيلة بـ JavaScript، أو إذا كنت ببساطة تفضّل تستلم JSON مطابقًا للـ schema بدل كتابة دالة راجعة إضافية؟ فهذه حالة مناسبة للمسار المُدار. وإذا تبغى صورة أوسع، فمراجعتا أفضل أدوات web scraping وأفضل مشاريع web scraping على GitHub ترسمان موقع مكتبة مثل Colly جنب الخيارات المعتمدة على المتصفح أو الخدمات المُدارة.
الحكم النهائي
هل يجب أن تستخدم Colly؟ نعم — إذا كنت تكتب Go وتزحف إلى HTML أو JSON بسرعة، فهو فعلًا يفي بوعد "الزاحف السريع"، والآن فيه أرقام تؤكد هذه السمعة. استرجاع كامل في الاستخراج الثابت. JSON نظيف عبر OnResponse. خطأ 500 وصل إلى OnError بدل ما يختفي. وزحف بعمق 2 وصل إلى 17 صفحة. وكل هذا يترجم إلى ملف ثابت واحد بلا تبعيات تشغيل، وهو من أريح قصص النشر في هذه الفئة كلها.
لكن لازم تقيس الادعاءات بواقعية. هو ما يعرض JavaScript — كل صفحة تعتمد على العميل في تجربتي رجعت 0، وهذه حالة دائمة مو إعداد نسيت تفعيله. كما أنه يحتاج إلى سلسلة أدوات Go، لذلك الفرق غير العاملة بـ Go تدفع تكلفة إعداد مسبقة. والـ module الذي تثبته (v2.3.0) يتقدم على أحدث إصدار موسوم (v2.2.0)، فلا تنصدم إذا اختلفت الصفحات. و"سريع" هنا يعني مسار الاستخراج الذي قسته، لا اختبار throughput ما سويته. ضمن هذه الحدود، Colly زاحف Go سريع وموثوق وقابل للنشر فعلًا — ويستحق سمعته فور ما تتوقف عن مطالبته بتشغيل JavaScript.
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
الأسئلة الشائعة
هل Colly سريع فعلًا، وهل يوجد رقم يثبت ذلك؟ هو سريع بالمعنى المهم لمسار العمل الأساسي الذي قسته: Go مُترجم، استرجاع كامل في الاستخراج الثابت (12/12 من منتجات الكتالوج)، تعامل نظيف مع JSON، وزحف بعمق 2 وصل إلى 17 صفحة — وكل هذا من ملف تنفيذي ثابت واحد. ما سويته هو اختبار throughput مباشرًا مقابل Scrapy، لذلك تعامل مع كلمة "سريع" هنا على أنها سلوك استخراج مقاس، لا نتيجة سرعة من مواجهة مباشرة.
هل يستطيع Colly كشط الصفحات المعتمدة على JavaScript؟ لا. Colly زاحف HTTP — ينزل HTML ويحلله لكنه لا يشغّل متصفحًا. وبالفعل أعطتني الصفحة التجريبية المعتمدة على JavaScript نتيجة 0 بطاقات، وكذلك صفحة Quotes JS العامة. بالنسبة للمحتوى الذي يظهر في جهة العميل ستحتاج إما إلى ربط Colly بمُعرِّض Rendering أو استخدام أداة يأتي معها عرض المتصفح مدمجًا.
هل أحتاج لمعرفة Go لاستخدام Colly؟
نعم. Colly مكتبة Go وليست أداة CLI مستقلة — أنت تستوردها، وتسجل الدوال الراجعة (OnHTML، OnResponse، OnError)، ثم تُترجم. الجهاز الذي اختبرته ما كان عليه Go أصلًا، لذلك بدأت عملية الإعداد بتثبيت سلسلة أدوات (1.26.5). إذا فريقك أصلًا ما يشتغل داخل Go، فهذه البيئة هي تكلفة الإعداد الحقيقية.
لماذا لا يطابق الإصدار الذي ثبتّه أحدث إصدار على GitHub؟
لأن module الخاص بـ Go وعلامة الإصدار على GitHub تباعدا مع الوقت. أحدث module على Go proxy هو v2.3.0 (ديسمبر 2025)، بينما أحدث إصدار موسوم على GitHub هو v2.2.0 (مارس 2025). وقد اختبرت v2.3.0. هذه مجرد خاصية بين modules والوسوم، وليست مشكلة تثبيت.
هل Colly مجاني للاستخدام التجاري؟ نعم، فهو Apache-2.0، أي ترخيص مرن ومناسب تجاريًا. وكما هو الحال دائمًا، تأكد من الترخيص الحالي في المستودع قبل البناء عليه.
