Theo báo cáo State of Open Source 2025, 96% tổ chức đã tăng hoặc giữ nguyên mức sử dụng mã nguồn mở trong năm qua — và lý do đứng đầu vẫn là “không tốn chi phí bản quyền”. Nhưng có một điều ít ai nói với bạn khi tải scraper từ GitHub: “mã nguồn mở” và “an toàn để dùng trong sản phẩm thương mại” không phải là một khẳng định giống nhau.
Tôi đã dành một phần thời gian trong năm nay để sàng lọc những cái tên quen thuộc — Scrapy, Playwright, Puppeteer, cùng các crawler thế hệ mới như Crawl4AI và ScrapeGraphAI — và điều thực sự quan trọng cho một quyết định kinh doanh gần như không bao giờ xuất hiện trong các bảng xếp hạng “scraper tốt nhất” thông thường: loại giấy phép. Phần lớn danh sách chỉ xếp theo số sao GitHub. Còn tôi xếp theo điều sẽ xảy ra khi đội pháp chế hỏi: “Khoan đã, cái này có phải AGPL không?” Danh sách này ưu tiên phân nhóm theo mức độ phù hợp trước (parser, tự động hóa trình duyệt, scraper AI-native, framework crawl, extension không cần code), rồi mới đến giấy phép, vì đó mới là thứ tự ra quyết định ngoài thực tế.
Vì Sao Loại Giấy Phép Là Bộ Lọc Đầu Tiên Khi Chọn Open Source Web Scraper
“Mã nguồn mở” không có nghĩa là “muốn dùng sao cũng được”. Định nghĩa Open Source có quy định rõ rằng không được phân biệt đối xử với việc sử dụng thương mại — vì vậy mọi công cụ trong danh sách này đều cho phép dùng cho mục đích kinh doanh. Nhưng bạn được phép dùng như thế nào, và nghĩa vụ nào phát sinh khi bạn triển khai nó, lại phụ thuộc hoàn toàn vào giấy phép cụ thể.
Các giấy phép kiểu permissive — MIT, BSD-3-Clause, Apache-2.0 — cho phép bạn làm gần như mọi thứ, miễn là giữ lại thông báo bản quyền. Apache-2.0 còn đi xa hơn với điều khoản cấp phép bằng sáng chế rõ ràng, đây cũng là kiểu giấy phép mà giới pháp lý thường thích nhất. Cả ba loại này đều không bắt bạn phải công khai mã nguồn của chính bạn.
Copyleft là một câu chuyện khác. AGPL-3.0 là giấy phép khiến nhiều người vấp nhất, và đó chính là giấy phép mà core tự host của Firecrawl đang dùng (SDK là MIT, nhưng engine scraping lõi là AGPL). Theo Điều 13 của AGPL-3.0, nếu bạn sửa đổi chương trình thuộc phạm vi giấy phép rồi cho người dùng tương tác với bản sửa đổi đó qua mạng, bạn phải cung cấp cho họ mã nguồn tương ứng. Đây không phải kiểu “cả SaaS sẽ biến thành mã nguồn mở” như nhiều diễn đàn hay diễn giải; nghĩa vụ nằm ở chính phiên bản đã sửa đổi của chương trình được cung cấp để truy cập từ xa. Nhưng đây là một câu hỏi pháp lý thực sự, cần tư vấn đúng nghĩa chứ không phải một thread trên Stack Overflow, trước khi bạn xây sản phẩm đóng trên nền tảng đó.
Rồi còn nhóm “open-core” mờ nhạt hơn nữa. Web Scraper, tiện ích Chrome đó, từng có một repo LGPL-3.0 trên GitHub — nhưng lần commit cuối của repo này là từ 2017, và không có đối chiếu xác thực nào giữa source cũ đó với extension hiện đang có trên Chrome Web Store (phiên bản 1.111.13 tại thời điểm viết bài). Cách hiểu trung thực là: extension cục bộ là miễn phí, còn bản Cloud với tính năng lập lịch và xoay proxy là một sản phẩm thương mại riêng, và gọi toàn bộ là “mã nguồn mở” sẽ che mờ sự tách biệt đó.
Cách Chúng Tôi So Sánh 12 Công Cụ Web Scraper Mã Nguồn Mở Tốt Nhất
Tôi đánh giá từng công cụ theo bảy tiêu chí: loại giấy phép và mức độ “vướng” khi dùng thương mại, ngôn ngữ/runtime, hỗ trợ render JavaScript nguyên bản (so với phải ghép thêm plugin), độ khó học, chi phí compute hoặc proxy ẩn, tín hiệu sức khỏe cộng đồng (issue mở, tần suất release, commit gần nhất), và trường hợp sử dụng phù hợp nhất.
Danh sách được chia theo nhóm — static parser, framework tự động hóa trình duyệt, scraper AI-native, framework crawl, rồi đến extension trình duyệt không cần code — thay vì chỉ xếp theo số sao. Đây là lựa chọn có chủ đích. Beautiful Soup và Scrapy giải quyết những bài toán hoàn toàn khác nhau dù đều rất phổ biến; xếp chúng trên cùng một trục thực ra chẳng giúp ai chọn công cụ cả.
| Tiêu chí | Tôi đã kiểm tra gì |
|---|---|
| Giấy phép và mức phù hợp cho thương mại | Giấy phép chính xác của repo, yêu cầu ghi nhận nguồn, điều khoản copyleft |
| Runtime và độ phù hợp với team | Python, Node/TypeScript, Java hay đa ngôn ngữ |
| Render JS | Hỗ trợ trình duyệt nguyên bản, cần plugin ghép thêm hay không, hoặc không có |
| Phạm vi framework | Chỉ parser, driver trình duyệt, pipeline crawl đầy đủ, hay sản phẩm quản lý sẵn |
| Sức khỏe cộng đồng | Sao GitHub, ngày release gần nhất, issue mở, lần push cuối |
| Chi phí ẩn | Bộ nhớ trình duyệt, nhu cầu proxy, phụ thuộc API model, công sức bảo trì |
| Phù hợp nhất | Cặp đội ngũ/nhiệm vụ cụ thể, dựa trên tính năng hoặc issue đã được ghi nhận |
Một lưu ý thẳng thắn về số liệu sức khỏe cộng đồng: Beautiful Soup phát triển chính trên Launchpad, không phải GitHub, nên số sao GitHub của nó (một mirror không chính thức với 223 sao, lần cập nhật cuối từ 2022) không thể so sánh trực tiếp với 10 công cụ còn lại. Tôi sẽ nói rõ điều này bên dưới thay vì giả vờ rằng nó khớp hoàn toàn với cùng một bảng.
Thư Viện Parse Mã Nguồn Mở Tốt Nhất Cho Website Tĩnh: BeautifulSoup
BeautifulSoup là thư viện Python để duyệt và tìm kiếm cây phân tích HTML/XML. Nó không tải trang, không thực thi JavaScript, cũng không quản lý hàng đợi crawl — nó chỉ nhận phần markup bạn đã có sẵn rồi cho phép bạn khai thác dữ liệu bằng một API rất thân thiện. Phạm vi hẹp này chính là mục đích của nó: công cụ bạn dùng khi đã có HTML và chỉ cần lấy dữ liệu ra.
- Giấy phép: MIT — rất thoáng, không có nghĩa vụ ngoài việc giữ thông báo bản quyền
- Độ khó học: thực sự thân thiện với người mới; mô hình đối tượng khá dễ chịu
- Render JS: không có sẵn — cần ghép với một công cụ khác để lấy HTML đã render trước
- Giới hạn đã biết: tài liệu chính thức thừa nhận nó “sẽ không bao giờ nhanh bằng các parser bên dưới nó”, và các backend parser khác nhau (lxml, html5lib, html.parser) có thể tạo ra cây DOM khác nhau đáng kể khi HTML lỗi
Phù hợp nhất cho: script nội bộ nhanh, hoặc trích xuất một lần từ HTML tĩnh hay HTML đã được tải sẵn — không phù hợp cho quy mô lớn, cũng không hợp với site nặng JS.
Framework Tự Động Hóa Trình Duyệt Tốt Nhất Cho Kiểm Thử Đa Trình Duyệt Cũ: Selenium
Selenium là cái tên lâu đời nhất trong danh sách này, ban đầu được xây cho kiểm thử trình duyệt rồi được cả thế giới scraping tái sử dụng. Điểm mạnh đặc trưng của nó không phải tốc độ — mà là độ phủ. Bộ binding chính thức của Selenium 4 hỗ trợ Java, Python, C#, Ruby và JavaScript, đồng thời điều khiển Chrome, Edge, Firefox và Safari qua chuẩn W3C WebDriver.
- Giấy phép: Apache-2.0
- Sức khỏe GitHub: 34.366 sao, 98 issue mở, 12 release ổn định trong năm qua (mới nhất: 4.47.0)
- Render JS: có sẵn, thông qua trình duyệt thật
- Điểm cản trở đã được ghi tài liệu: chính docs của Selenium gọi đồng bộ hóa là “một trong những thách thức phổ biến nhất” — trang đã tải xong không có nghĩa là các phần tử do JS sinh ra đã sẵn sàng, và DOM thay đổi động sẽ quăng ra
StaleElementReferenceException
Phù hợp nhất cho: team cần hỗ trợ nhiều trình duyệt hoặc nhiều ngôn ngữ, hoặc vốn đã dùng Selenium cho QA và muốn tận dụng lại kỹ năng đó cho scraping.
Framework Tự Động Hóa Trình Duyệt Tốt Nhất Cho Website JS Hiện Đại Nặng: Playwright
Playwright, do Microsoft duy trì, là câu trả lời hiện đại cho cảm giác “Selenium chậm và rườm rà”. Nó tự động hóa Chromium, Firefox và WebKit một cách nguyên bản, với các kiểm tra actionability tự chờ cho đến khi phần tử thật sự sẵn sàng — hiển thị, ổn định, bật — rồi mới tương tác. Chỉ riêng cơ chế auto-wait này đã loại bỏ rất nhiều boilerplate WebDriverWait mà người dùng Selenium phải tự viết tay.
Có một sắc thái thường bị bỏ qua trong mọi thread “Scrapy vs. Playwright vs. Selenium”: Scrapy tự thân không render JavaScript. Nó cần plugin riêng — scrapy-playwright — ghép vào để có browser rendering. Playwright và Puppeteer render nguyên bản vì render chính là sản phẩm.
- Giấy phép: Apache-2.0
- Sức khỏe GitHub: 94.443 sao, 15 release ổn định trong năm qua (mới nhất: 1.62.1)
- Chi phí ẩn: chỉ riêng browser binary đã vào khoảng 281 MB cho Chromium, 187 MB cho Firefox và 180 MB cho WebKit — và thay đổi gây phá vỡ tương thích ở bản 1.38 đã dừng việc tự động tải trình duyệt, nên việc ghim phiên bản trong Docker image là rất quan trọng
Phù hợp nhất cho: team scraping các single-page app React/Vue cần hành vi đa trình duyệt đáng tin cậy mà không muốn tự viết logic chờ đợi.
Công Cụ Tự Động Hóa Trình Duyệt Mã Nguồn Mở Tốt Nhất Cho Dự Án Tập Trung Chrome: Puppeteer
Puppeteer, thư viện tự động hóa của Google, được thiết kế ưu tiên Chrome ngay từ đầu — tích hợp sâu với Chrome DevTools Protocol, có sẵn tạo screenshot/PDF, đủ cả. Nhưng cần sửa lại một giả định cũ ở đây: Puppeteer hiện cũng hỗ trợ chính thức Firefox ổn định, nên nói “chỉ Chrome” thì không còn hoàn toàn chính xác nữa, dù Chrome vẫn là trường hợp sử dụng chính.
- Giấy phép: Apache-2.0
- Sức khỏe GitHub: 95.458 sao, 249 issue mở — số issue mở cao hơn Playwright khá rõ, điều này đáng cân nhắc nếu bạn quan tâm đến tốc độ phản hồi
- Thực tế chống bot: issue #7006 của Puppeteer ghi nhận một lượt điều hướng hoàn toàn bình thường vẫn bị Cloudflare challenge chặn — render trang không có nghĩa là bạn tàng hình trước hệ thống chống bot
Phù hợp nhất cho: team Node.js đã chuẩn hóa trên Chrome, đặc biệt khi cần tạo PDF/screenshot song song với scraping.
Scraper AI-Native Tốt Nhất Cho Pipeline LLM Và RAG: Crawl4AI
Crawl4AI thực chất là Playwright ở lớp bên dưới, được thiết kế để xuất Markdown sạch cho các pipeline LLM và RAG thay vì HTML thô lộn xộn. Nó hỗ trợ cả chế độ “clean Markdown” và “Fit Markdown” tối ưu cho context window, cộng thêm trích xuất bằng LLM nếu bạn muốn — còn lọc CSS/XPath và BM25 thì chạy hoàn toàn không cần đụng tới API model.
Có một điểm cần nêu thật chính xác: GitHub hiển thị repo là Apache-2.0, nhưng file license thực tế lại thêm một yêu cầu ghi nhận nguồn bắt buộc cho việc sử dụng và phân phối công khai. Đây không phải Apache-2.0 nguyên bản — mà là Apache-2.0 cộng thêm điều kiện riêng của dự án, và thứ cần đọc là file license thật, không phải badge ở thanh bên GitHub.
- Sức khỏe GitHub: 77.959 sao, bản phát hành mới nhất v0.9.2 (tháng 7/2026)
- Yêu cầu tài nguyên: hướng dẫn self-hosting khuyến nghị container nên có ít nhất 4 GB RAM trống
- Tính không ổn định đã được ghi nhận: changelog v0.9.0 có các thay đổi breaking đối với mặc định xác thực Docker-server và di chuyển module — đây là một đích nhắm đang thay đổi nhanh, nên hãy ghim phiên bản
Phù hợp nhất cho: team Python đưa dữ liệu web mới vào LLM agent hoặc RAG pipeline, và có thể tự quản lý hạ tầng trình duyệt.
Scraper AI-Native Tốt Nhất Cho Triển Khai Tự Host Nhưng Có Cái Bẫy Giấy Phép: Firecrawl
Core tự host của Firecrawl là nơi câu chuyện AGPL trở nên rất cụ thể. Đây là crawler API-first, trả về Markdown, HTML, screenshot và dữ liệu có cấu trúc — thực sự rất mạnh, xây trên Fetch và Playwright. Nhưng phần “đánh bóng” mà nhiều người gắn với cái tên Firecrawl — xử lý anti-bot dạng managed, xoay proxy, lớp stealth Fire-engine — lại thuộc về Firecrawl Cloud, không phải repo tự host. Tài liệu self-host chính thức của Firecrawl nói rất rõ rằng Fire-engine và hành vi chống bot nâng cao không có trong stack self-host mặc định, và screenshot/page actions cũng cần chúng.
- Giấy phép: chủ yếu AGPL-3.0-or-later cho core, MIT cho SDK
- Sức khỏe GitHub: 166.527 sao — thực sự cực lớn trong nhóm này
- Thực tế triển khai: tự host đồng nghĩa phải dựng Redis, RabbitMQ, PostgreSQL và tùy chọn FoundationDB — đây là một hệ thống nhiều dịch vụ, không phải một container đơn lẻ
Phù hợp nhất cho: công cụ nội bộ hoặc dự án mã nguồn mở chấp nhận nghĩa vụ cung cấp source theo AGPL. Nên suy nghĩ thật kỹ trước khi dùng core tự host này làm nền cho một sản phẩm thương mại đóng mà chưa được pháp chế xem xét.
Scraper AI-Native Tốt Nhất Cho Trích Xuất Bằng Ngôn Ngữ Tự Nhiên: ScrapeGraphAI
ScrapeGraphAI cho phép bạn mô tả nhu cầu bằng ngôn ngữ tự nhiên thay vì viết selector — đây là một pipeline dạng graph, trong đó các lời gọi LLM đảm nhiệm phần ánh xạ trường dữ liệu. Thư viện MIT này chạy trên hạ tầng của chính bạn: API key LLM của bạn (hoặc model Ollama cục bộ nếu bạn muốn tránh chi phí token), cùng instance Playwright do bạn cấu hình.
Và đây là cái bẫy cần gọi tên rõ ràng: “mã nguồn mở” ở đây không có nghĩa là “không tốn chi phí vận hành”. Mỗi lần trích xuất đều tiêu tốn token của model bạn đã nối vào. Và trích xuất theo prompt có một kiểu lỗi riêng mà tool dựa trên selector không có: một issue mở báo rằng pipeline chạy qua mọi bước thành công nhưng lại trả về các trường trống/NA cho dữ liệu vốn hiển thị rõ trên trang — một kiểu lỗi âm thầm mà CSS/XPath xác định không sinh ra.
- Giấy phép: MIT
- Sức khỏe GitHub: 29.447 sao, bản stable mới nhất v2.1.6
Phù hợp nhất cho: các job trích xuất không thường xuyên, một lần, nơi sự linh hoạt của prompt đáng giá hơn chi phí model và công sức kiểm tra lại.
Scraper AI-Native Tốt Nhất Cho Trích Xuất Nhẹ, Không Phụ Thuộc Model: AutoScraper
AutoScraper bỏ qua LLM hoàn toàn. Bạn chỉ cần đưa URL và một giá trị mẫu muốn trích xuất; công cụ sẽ suy ra quy tắc cấu trúc từ trang và tái sử dụng chúng trên những trang tương tự. Không cần API key model, không tốn token — chỉ có requests và BeautifulSoup chạy bên dưới.
Cẩn thận với nhãn “bỏ rơi” mà vài thread diễn đàn hay gán cho công cụ này. Điều đó không chính xác: vẫn có commit thật vào giữa năm 2025, và lần push cuối của repo là tháng 7/2026. Nhưng bản release đóng gói mà người dùng thực sự pip install vẫn là v1.1.14, từ 2022. Nói “nhịp phát hành đóng gói chậm” là công bằng — còn gọi là “project chết” thì không.
- Giấy phép: MIT
- Sức khỏe GitHub: 7.844 sao
- Giới hạn cứng: không render JS nguyên bản — nó gọi
requests.get()rồi parse phần HTML trả về, hết.
Phù hợp nhất cho: các job trích xuất nhỏ, lặp lại, trên những trang tĩnh có cấu trúc ổn định, nơi bạn chấp nhận huấn luyện lại đôi lúc sau khi giao diện đổi.
Framework Crawl Tốt Nhất Cho Dự Án Python Quy Mô Lớn: Scrapy
Scrapy là framework crawl Python cấp sản xuất — engine, scheduler, downloader, item pipelines, đủ cả. Nếu Beautiful Soup là dao mổ, thì Scrapy là cả phòng phẫu thuật: networking bất đồng bộ, kiểm soát đồng thời theo domain, AutoThrottle, và exporter ghi thẳng ra CSV, JSON, JSON Lines, XML hoặc cloud storage.
Sắc thái tôi đã nhấn mạnh ở trên vẫn rất đáng nhắc lại ở đây vì nó là nguồn gây nhầm lẫn lớn nhất của Scrapy: Scrapy không có render JavaScript nguyên bản. Tài liệu của Scrapy khuyên bạn trước hết nên tìm và tái tạo request dữ liệu gốc — vì cách đó thường nhanh hơn và đầy đủ hơn so với việc render cả trình duyệt — và chỉ dùng scrapy-playwright khi thật sự không thể tránh browser.
- Giấy phép: BSD-3-Clause
- Sức khỏe GitHub: 63.830 sao, 304 issue mở, 9 release ổn định trong năm qua (mới nhất: 2.17.0)
- Khoảng trống xử lý rate-limit: một yêu cầu cải tiến mở ghi nhận rằng AutoThrottle tinh chỉnh dựa trên độ trễ chứ không phải phản hồi HTTP 429 — backoff nhận biết phản hồi vẫn là thứ bạn phải tự xây
Phù hợp nhất cho: crawl website tĩnh ở quy mô lớn, nơi pipeline có cấu trúc và khả năng xuất dữ liệu linh hoạt quan trọng hơn render JS.
Framework Crawl Tốt Nhất Cho Sản Phẩm Node.js Ở Môi Trường Production: Crawlee
Crawlee, từ đội Apify, là tương đương gần nhất với Scrapy trên Node/TypeScript — chỉ khác là render JavaScript không phải ghép thêm sau, mà đã được tích hợp từ đầu qua các lớp crawler dựa trên Playwright và Puppeteer, nằm dưới một tầng queue, storage và xoay proxy dùng chung.
- Giấy phép: Apache-2.0
- Sức khỏe GitHub: 25.364 sao, 8 release ổn định trong năm qua (mới nhất: 3.18.1)
- Chi tiết thông minh:
AutoscaledPoolcủa nó tự điều chỉnh đồng thời dựa trên tải CPU, bộ nhớ và event loop theo thời gian thực — và docs nói rõ rằng đặt mức đồng thời tối thiểu quá cao có thể làm sập cả quá trình crawl
Phù hợp nhất cho: team Node.js/TypeScript muốn quản lý queue sẵn sàng cho production và render JS mà không phải tự ghép các phần tương đương Scrapy.
Framework Crawl Tốt Nhất Cho Lập Chỉ Mục Doanh Nghiệp Bằng Java: Apache Nutch
Apache Nutch là trường hợp khác biệt trong danh sách này — một crawler Java được xây cho lập chỉ mục web quy mô lớn, thường đổ dữ liệu vào Solr, Elasticsearch hoặc OpenSearch. Đây không phải công cụ để đi lấy giá sản phẩm từ website đối thủ; nó là công cụ mà các team search doanh nghiệp dùng khi xây lớp crawl phía dưới một search index.
- Giấy phép: Apache-2.0
- Sức khỏe GitHub: chỉ 3.276 sao, nhưng vẫn được push gần đây nhất vào tháng 8/2026 — số sao thấp phản ánh một ngách chuyên biệt, không phải sự lơ là
- Xử lý JS: cần plugin
protocol-seleniumriêng; một ticket JIRA ghi nhận lỗi proxy HTTPS ngay trên nhánh plugin đó
Phù hợp nhất cho: team đã chạy hạ tầng Java/Hadoop và cần lập chỉ mục web quy mô doanh nghiệp, không phải trích xuất dữ liệu ad-hoc.
Extension Trình Duyệt Không Cần Code Tốt Nhất: Web Scraper
Web Scraper là lựa chọn kiểu bấm-chọn — một công cụ tạo sitemap và cây selector nằm ngay trong Chrome DevTools. Nó có thể đi qua pagination, bấm nút, cuộn các trang tải vô hạn và xuất cục bộ sang CSV/XLSX, hoàn toàn không cần viết một dòng code nào.
Điểm tách open-core ở đây quan trọng hơn gần như mọi công cụ khác trong danh sách. Trích xuất cục bộ thực sự là miễn phí. Nhưng tự động hóa theo lịch, chạy trên cloud, truy cập API và quản lý proxy đều nằm sau Web Scraper Cloud, một sản phẩm trả phí riêng. Và như đã nói ở trên, repo nguồn LGPL-3.0 công khai đã không có commit code nào từ 2017 — vì vậy hãy hiểu “mã nguồn mở” là nói về lịch sử của extension cục bộ, chứ không phải một bảo đảm về thứ đang chạy trong bản Chrome Web Store hiện tại.
Phù hợp nhất cho: cá nhân hoặc team nhỏ, thỉnh thoảng trích xuất dữ liệu cục bộ, không muốn viết code và không cần quy mô lớn.
Parser Tĩnh vs. Trình Duyệt Không Giao Diện: Chọn Công Cụ Đúng Cho Site Nặng JS
Có một con số khá đáng chú ý ở đây: 98,9% website dùng JavaScript như một ngôn ngữ phía client. Nhưng con số này thường bị diễn giải sai thành “98,9% site cần headless browser để scrape” — trong khi đó không phải ý nghĩa của nó. Nó chỉ đo sự có mặt của JavaScript, chứ không nói dữ liệu bạn cần nằm trong HTML ban đầu hay chỉ xuất hiện sau khi script chạy xong.
Sự khác biệt đó mới là điểm quyết định thực sự. Chia 12 công cụ thành hai nhóm trung thực:
Static parser — BeautifulSoup, AutoScraper — nhanh, rẻ và hoàn toàn mù với mọi thứ được render phía client. Nếu dữ liệu bạn cần đã nằm trong HTML ban đầu hoặc trong một endpoint JSON có thể gọi trực tiếp, nhóm này sẽ thắng về tốc độ và độ đơn giản.
Framework headless browser — Playwright, Puppeteer, Selenium, crawler trình duyệt của Crawlee — thực sự thực thi JavaScript, đồng nghĩa với việc tiêu tốn compute thật. Dữ liệu HTTP Archive 2024 cho thấy payload JavaScript trung vị của một trang trên mobile là 558 KB với 22 request JS riêng biệt — đó là khối lượng mà một headless browser phải xử lý mỗi lần tải trang, trong khi parser tĩnh chỉ cần lấy HTML thô.
Và Scrapy nằm ở vị trí trung gian khá đặc biệt, cần nhắc lại thêm một lần: nó không thuộc hẳn bên nào. Đây là một framework crawl đầy đủ nhưng không có render nguyên bản, nên nếu cần JS thì bạn phải ghép thêm scrapy-playwright.
Cái Giá Ẩn Của “Miễn Phí”: Proxy, Compute Và Giờ Bảo Trì
Chi phí bản quyền bằng 0 chỉ là một đầu vào trong tổng chi phí, không phải toàn bộ bức tranh. Tôi sẽ tách mô hình chi phí thật thành vài nhóm rất cụ thể:
Compute. Chạy headless browser ở quy mô lớn có nghĩa là bạn đang trả tiền cho browser-seconds, không chỉ thời gian máy chủ. AWS Fargate tính khoảng $0.000011244 cho mỗi vCPU-giây và $0.000001235 cho mỗi GB-giây trên Linux/x86 — nhân lên với số phiên bản Playwright chạy đồng thời, con số tăng nhanh hơn nhiều người tưởng.
Proxy. Bảng giá công khai của Bright Data cho thấy proxy dân cư bắt đầu khoảng $5/GB và proxy datacenter từ $0.9/IP — và “băng thông” trong các mô hình giá này tính cả request lẫn response, không chỉ phần bạn tải xuống. Đây là khoản mục thường khiến đội ngũ bất ngờ: tránh rate limit và block không hề miễn phí, mà là một dòng chi thường xuyên trong ngân sách hạ tầng.
Bảo trì. Mỗi static parser và công cụ dựa trên quy tắc cấu trúc trong danh sách này đều có thể bị hỏng khi site đổi layout khiến selector không còn khớp. Ví dụ README của AutoScraper đã phải cập nhật giá sau khi site mục tiêu thay đổi. Đây là nhóm “chi phí compute/proxy ẩn” mà nhãn $0 cho giấy phép không bao giờ đề cập — số giờ kỹ thuật bỏ ra để sửa lại trích xuất sau khi đội dev của website đích tung ra một lần redesign.
Với những team liên tục gặp bức tường này — selector hỏng liên miên, phải quản lý tài khoản proxy, DevOps nặng đầu không hồi kết — một stack open source tự host không tự động là lựa chọn rẻ hơn khi bạn đã tính cả giờ công kỹ sư. Chrome extension của Thunderbit đi theo hướng khác cho người không phải dev: trỏ vào trang đã được phép truy cập, bấm One Click Extract, rồi hệ thống sẽ tự phân tích trang để hiểu cần lấy gì — không selector, không phải viết script bảo trì khi layout đổi. Nó không thay thế Scrapy ở quy mô framework crawl, nhưng là một bước đi hợp lý tiếp theo cho người dùng doanh nghiệp đang phải tự giữ một bộ quy tắc AutoScraper mỏng manh bằng tay.
Khung Ra Quyết Định: Ghép Công Cụ Đúng Với Ràng Buộc Của Đội Bạn
Phần lớn các bài so sánh chỉ dừng ở “tốt nhất cho use case X”. Đó mới chỉ là một biến. Trên thực tế, các team thường phải cân nhắc ít nhất bốn biến cùng lúc: nhu cầu render JS × ngôn ngữ của team × định dạng đầu ra cần có × ràng buộc giấy phép.
| Tình huống của team | Công cụ phù hợp nhất | Vì sao |
|---|---|---|
| Python, HTML tĩnh, script nhanh | BeautifulSoup, AutoScraper | Không cần JS, giấy phép MIT, setup tối thiểu |
| Python, crawl có cấu trúc lớn | Scrapy | BSD-3-Clause, pipeline tích hợp sẵn, chỉ ghép scrapy-playwright nếu thực sự cần JS |
| Node/TypeScript, crawl production có JS | Crawlee | Apache-2.0, hỗ trợ trình duyệt nguyên bản tích hợp trong hệ queue |
| Đa ngôn ngữ, phủ trình duyệt rộng | Selenium | Apache-2.0, phủ ngôn ngữ/trình duyệt rộng nhất |
| Tự động hóa SPA hiện đại, đa trình duyệt | Playwright | Apache-2.0, render nguyên bản, auto-wait tích hợp |
| Tự động hóa tập trung Chrome với screenshot/PDF | Puppeteer | Apache-2.0, tích hợp sâu CDP |
| Pipeline Markdown cho LLM/RAG | Crawl4AI | Apache-2.0 + điều khoản ghi nhận nguồn; nên kiểm tra mức chấp nhận của đội pháp chế với điều kiện bổ sung |
| Trích xuất theo prompt, không thường xuyên | ScrapeGraphAI | MIT, nhưng cần tính chi phí token LLM |
| Crawler tự host tương thích API, chấp nhận AGPL | Firecrawl | AGPL-3.0-or-later; cần pháp chế duyệt trước khi xây SaaS đóng trên đó |
| Lập chỉ mục Java/Hadoop cho doanh nghiệp | Apache Nutch | Apache-2.0, sinh ra cho hạ tầng search |
| Không cần code, dùng thỉnh thoảng, không phải dev | Web Scraper extension | Miễn phí ở local; cần hiểu mô hình open-core trước khi nghĩ rằng nó minh bạch hoàn toàn |
So Sánh Song Song Cả 12 Công Cụ Web Scraper Mã Nguồn Mở
| Công cụ | Ngôn ngữ | Giấy phép | An toàn cho dùng thương mại? | Render JS | Độ khó học | Phù hợp nhất |
|---|---|---|---|---|---|---|
| BeautifulSoup | Python | MIT | ✅ Có | Không có (cần ghép thêm) | Thấp | Parse HTML tĩnh |
| Selenium | Đa ngôn ngữ | Apache-2.0 | ✅ Có | Nguyên bản | Trung bình | Kiểm thử đa trình duyệt/ngôn ngữ chuyển sang scraping |
| Playwright | JS/TS/Python/Java/.NET | Apache-2.0 | ✅ Có | Nguyên bản | Trung bình | Site hiện đại nặng JS |
| Puppeteer | Node.js/TS | Apache-2.0 | ✅ Có | Nguyên bản | Trung bình | Tự động hóa tập trung Chrome |
| Crawl4AI | Python | Apache-2.0 + điều khoản ghi nhận nguồn | ⚠️ Cần xem điều khoản | Nguyên bản (qua Playwright) | Trung bình | Pipeline Markdown cho LLM/RAG |
| Firecrawl (tự host) | TypeScript | AGPL-3.0-or-later (core) | ⚠️ Có điều kiện | Nguyên bản (qua Playwright) | Cao (nhiều dịch vụ) | AI crawling tự host, chấp nhận AGPL |
| ScrapeGraphAI | Python | MIT | ✅ Có | Nguyên bản (qua Playwright) | Trung bình | Trích xuất bằng ngôn ngữ tự nhiên |
| AutoScraper | Python | MIT | ✅ Có | Không có | Thấp | Tác vụ tĩnh nhẹ, lặp lại |
| Scrapy | Python | BSD-3-Clause | ✅ Có | Cần ghép thêm | Cao | Crawl site tĩnh quy mô lớn |
| Crawlee | Node.js/TS | Apache-2.0 | ✅ Có | Nguyên bản | Trung bình | Crawler Node.js cho production |
| Apache Nutch | Java | Apache-2.0 | ✅ Có | Cần plugin | Cao | Lập chỉ mục search doanh nghiệp |
| Web Scraper (extension) | N/A (không cần code) | Open-core | ⚠️ Tùy gói | Nguyên bản (trình duyệt thật) | Thấp | Người không phải dev, dùng thỉnh thoảng |
Kết Luận: Bạn Nên Dùng Open Source Web Scraper Nào?
Không có công cụ nào là “tốt nhất” tuyệt đối ở đây — câu trả lời đúng phụ thuộc vào ràng buộc giấy phép, ngôn ngữ của team, và việc dữ liệu đích nằm trong HTML tĩnh hay ẩn sau bức tường JavaScript. Scrapy thắng cho crawl Python quy mô lớn trên site tĩnh. Playwright hoặc Crawlee thắng khi render JS là điều bắt buộc. Crawl4AI phù hợp nếu bạn đang nuôi pipeline LLM, với lưu ý là file license của nó có thêm một điều khoản ghi nhận nguồn cần đọc nhanh. Core tự host của Firecrawl rất mạnh, nhưng đi kèm cuộc thảo luận AGPL mà đội pháp chế của bạn nên tham gia, không nên bỏ qua.
Và nếu việc bảo trì selector cùng quản lý proxy đang ngốn nhiều giờ kỹ sư hơn chính việc scraping, đó thường là dấu hiệu đã đến lúc xem xét một lựa chọn không cần code như Thunderbit thay vì tiếp tục chồng thêm một lớp nữa lên stack OSS tự host.
Câu Hỏi Thường Gặp Về Công Cụ Web Scraper Mã Nguồn Mở
Dùng công cụ web scraper mã nguồn mở để thu thập dữ liệu kinh doanh có hợp pháp không?
Nhìn chung, việc scraping dữ liệu công khai thường ít rủi ro hơn việc scraping phía sau đăng nhập hay paywall, nhưng điều đó không có nghĩa là lúc nào cũng hợp pháp. Hãy luôn kiểm tra điều khoản sử dụng của website đích và file robots.txt — lưu ý rằng robots.txt chỉ là giao thức yêu cầu, không phải cơ chế cấp phép, nên tuân thủ nó là thực hành tốt nhưng bản thân nó không tạo ra quyền pháp lý. Các luật về quyền riêng tư dữ liệu như GDPR cũng vẫn áp dụng dù dữ liệu có hiển thị công khai hay không. Đây không phải tư vấn pháp lý — hãy hỏi luật sư nếu bạn làm gì ngoài mức sử dụng nhỏ, không thường xuyên.
“Mã nguồn mở” có nghĩa là công cụ được dùng thương mại miễn phí không?
Có, theo nghĩa Open Source Definition cấm giấy phép phân biệt đối xử với việc sử dụng thương mại. Nhưng “dùng thương mại được” và “không có nghĩa vụ gì” là hai chuyện khác nhau — AGPL-3.0 (được core tự host của Firecrawl dùng) cho phép dùng thương mại nhưng vẫn yêu cầu bạn cung cấp source tương ứng cho các phiên bản đã sửa đổi khi được truy cập qua mạng. MIT, BSD và Apache-2.0 không có yêu cầu đó.
Khác nhau giữa scraper mã nguồn mở và công cụ scraping không cần code là gì?
Scraper mã nguồn mở như Scrapy, Playwright hoặc BeautifulSoup yêu cầu bạn viết code, quản lý hạ tầng và tự xử lý logic crawl, proxy và xuất dữ liệu. Công cụ không cần code như Web Scraper Chrome extension hoặc browser extension của Thunderbit xử lý phát hiện trường dữ liệu và trích xuất qua giao diện trực quan hoặc phân tích trang bằng AI, đổi lại là giảm đáng kể rào cản thiết lập.
Công cụ web scraper mã nguồn mở nào tốt nhất cho người không phải lập trình viên?
Hầu hết công cụ trong danh sách này — Scrapy, Playwright, Puppeteer, Crawlee và các công cụ còn lại — đều giả định bạn biết viết code. Với người không chuyên kỹ thuật, Web Scraper Chrome extension cho phép thiết lập bằng cách bấm chuột, dù tính năng lập lịch và cloud nằm sau gói trả phí. Một công cụ no-code mang tính agent như browser extension của Thunderbit thường là điểm khởi đầu thực tế hơn nếu bạn muốn tự động phát hiện field mà không phải đụng vào selector.
Vì sao Scrapy cần plugin riêng để render JavaScript?
Scrapy được xây như một framework ưu tiên HTTP — nó gửi request rồi parse HTML trả về, không thực thi script phía client. Kiến trúc này giúp nó nhanh và nhẹ cho crawl site tĩnh, nhưng đồng thời cũng có nghĩa là nội dung được render bằng JavaScript đơn giản là không có trong response mà Scrapy nhận được. scrapy-playwright bắc cầu cho khoảng trống đó bằng cách đẩy những request nhất định qua một instance Playwright thật khi việc render là không thể tránh.
Tìm hiểu thêm
- 15 Dự Án Web Scraping GitHub Tốt Nhất Năm 2026, Kèm Lựa Chọn No-Code Tốt Nhất
- Crawl4AI Chạy Trình Duyệt Thật Để Biến Thành Markdown — Và Không, Nó Không Tự Sửa Selector Cho Bạn
- Tôi Đã Chạy Playwright Và Puppeteer Qua Cùng Một Bộ Test Scraping
- Top 10 Công Cụ Web Scraper Không Cần Code Cho Giải Pháp Tự Động
- Web Scraping Có Bị Cấm Không? Hiểu Rõ Các Hệ Lụy Pháp Lý
