2026/9/11 20:23:51
FEATURED · 精选文章 
在 GCP Cloud Functions 上部署 Crawlee CheerioCrawler 项目从本地爬虫到云函数实战指南【免费下载链接】crawleeCrawlee—A web scraping and browser automation library for Node.js to build reliable crawlers. In JavaScript and TypeScript. Extract data for AI, LLMs, RAG, or GPTs. Download HTML, PDF, JPG, PNG, and other files from websites. Works with Puppeteer, Playwright, Cheerio, JSDOM, and raw HTTP. Both headful and headless mode. With proxy rotation.项目地址: https://gitcode.com/GitHub_Trending/cr/crawlee本文是一份面向 Node.js 开发者的实战指南围绕 Crawlee 官方部署文档 docs/deployment/gcp-cheerio.md 展开完整讲解如何将基于CheerioCrawler的爬虫项目改造成 Google Cloud FunctionsGCP 云函数可运行的形态并完成上传部署与在线测试。读完本文你将掌握Configuration实例与persistStorage: false的隔离配置、无状态handler函数包装、GCP ZIP Upload 部署的完整步骤以及云函数入口点Entry point的配置方法同时结合仓库源码理解这些改动的底层原理。为什么 CheerioCrawler 适合跑在 Cloud Functions 上CheerioCrawler是 Crawlee 中基于纯 HTTP 请求 Cheerio 解析的轻量爬虫它不需要启动完整浏览器只发出普通 HTTP 请求并用 Cheerio 库解析 HTML 与提取数据。这意味着它的内存占用与冷启动开销都远小于 Puppeteer/Playwright 方案非常适合 GCP Cloud Functions 这类无服务器函数计算平台。官方文档中也明确指出在 Cloud Functions 上运行 CheerioCrawler 项目实际上相当容易只需要对项目代码做几处小改动。提示如果你的爬虫需要完整浏览器渲染可以参考仓库中的姊妹文档 docs/deployment/gcp-browsers.md —— GCP Cloud Functions 的最新运行时缺少运行 Chromium 所需的依赖因此浏览器类爬虫在 GCP 上应转向 Docker 容器平台 Cloud Run。第一步改造项目代码创建 Crawlee 项目并调整 package.json在本地使用 Crawlee 官方 CLI 创建项目npx crawlee create该命令对应仓库中 CLI 包的实现 packages/cli/src/commands/CreateProjectCommand.ts创建完成后终端会提示进入项目目录并运行npm start。创建完成后将package.json中的main字段设置为src/main.js。GCP Cloud Functions 会依据该字段定位项目入口文件{ name: my-crawlee-project, version: 1.0.0, main: src/main.js, ... }传入独立的 Configuration 实例修改src/main.js在构造CheerioCrawler时传入一个独立的Configuration实例并设置persistStorage: falseimport { CheerioCrawler, Configuration } from crawlee; import { router } from ./routes.js; const startUrls [https://crawlee.dev]; const crawler new CheerioCrawler({ requestHandler: router, }, new Configuration({ persistStorage: false, })); await crawler.run(startUrls);这一步包含两个关键语义理解它们对正确部署至关重要独立的Configuration实例默认情况下Crawlee 的所有爬虫实例共享同一个全局配置与存储通过Configuration.getGlobalConfiguration()访问全局单例见 packages/core/src/configuration.ts。如果云函数实例被复用这种共享状态会造成难以排查的偶发问题。为每个爬虫传入独立实例可以从根本上隔离状态。persistStorage: false启用纯内存存储persistStorage是 Crawlee 核心配置项之一默认值为true对应环境变量CRAWLEE_PERSIST_STORAGE字段定义见 packages/core/src/configuration.ts。设为false后Crawlee 不会把 Dataset、Key-Value Store、Request Queue 等持久化到本地磁盘而是全部保存在内存中。从源码看该选项直接决定存储后端的选择。在 packages/core/src/service_locator.ts 中getStorageBackend()会根据configuration.persistStorage二选一persistStorage为true默认→ 创建FileSystemStorageBackend数据写入storageDir默认./storage目录persistStorage为false→ 创建MemoryStorageBackend数据仅驻留内存。这与 AWS Lambda 场景完全一致详见 docs/deployment/aws-cheerio.md无服务器平台的本地文件系统要么只读、要么随时被回收只有关闭持久化、改用内存存储爬虫才是真正无状态、可安全复用的。用 handler 函数包装爬虫并导出接下来把爬虫调用包装进一个独立的handler函数。Cloud Functions 的入口函数需要满足可以是异步函数async接收两个位置参数req包含用户对云函数发起请求的详情与res可修改的响应对象调用res.send(data)将任意数据返回给调用方以命名导出named export的方式从src/main.js模块导出。改造后的完整src/main.jsimport { CheerioCrawler, Configuration } from crawlee; import { router } from ./routes.js; const startUrls [https://crawlee.dev]; export const handler async (req, res) { const crawler new CheerioCrawler({ requestHandler: router, }, new Configuration({ persistStorage: false, })); await crawler.run(startUrls); return res.send(await crawler.getData()) }其中crawler.getData()用于在爬取结束后读取 Dataset 中的全部结果并作为 HTTP 响应返回其底层对应 Dataset 的数据读取能力参见 packages/core/src/storages/dataset.ts 中getData()的实现。由于存储是内存态getData()读到的正是本次调用刚写入的数据天然满足无状态要求。无状态原则与 AWS Lambda 一致的铁律官方文档在 AWS Lambda 部署篇中给出了同一条硬性建议docs/deployment/aws-cheerio.md在 Cloud Functions 上同样适用务必为每次函数调用实例化全新的爬虫实例。AWS 会在首次执行后让运行环境存活一段时间以减少冷启动GCP 同理——后续的函数调用会触达已被使用过的爬虫实例。TLDR让云函数保持无状态。把new CheerioCrawler(...)放进handler内部而不是模块顶层正是这一原则的直接体现每次请求都得到全新的爬虫、全新的Configuration与全新的内存存储。第二步部署到 Google Cloud Platform创建云函数并配置资源在 Google Cloud 控制台中新建一个 Cloud Function并按需配置内存与 CPU根据爬取目标站点规模分配爬取大页面可适当提高内存区域Region选择离目标站点较近的区域以减少网络延迟函数超时Function timeout需覆盖完整爬取时长页面多、网络慢时应相应调大。选择 ZIP Upload 上传方式部署时选择ZIP Upload上传方式。GCP 会要求创建一个新的 GCSGoogle Cloud Storage存储桶用于存放 zip 包。打包时请注意关键区别只打包项目文件夹的全部内容排除node_modules文件夹。这一点与 AWS Lambda 不同——GCP 没有类似 Lambda Layers 的机制但它会根据package.json自动为你在云端安装项目依赖因此依赖目录不需要也不应该打进包里。项目文件夹/ ├── package.json ← GCP 据此安装依赖 ├── src/ │ ├── main.js ← 入口文件package.json 的 main 字段指向它 │ └── routes.js └── ...其余源码与配置排除 node_modules设置 Entry point上传后务必在函数配置中把Entry point设置为从src/main.js导出的函数名即handler。GCP 会从package.json的main字段读取入口文件并从 Entry point 配置得知要调用的导出函数两者配合才能正确触发爬虫。在 Testing 标签页验证函数部署完成后点击控制台中的Testing测试标签页即可验证。该页面会提供一段curl脚本用于调用你的新 Cloud Function。如果不想在本地安装gcloudCLI可以直接点击代码块上方的链接在 Cloud Shell 中运行这段脚本——无需任何本地命令行配置即可完成验证。与 Cloud Run 方案的对比同样是 GCP 上的部署Crawlee 官方对纯 Cheerio与浏览器方案给出了不同的平台建议对照 docs/deployment/gcp-browsers.md场景推荐平台部署形态关键差异CheerioCrawler纯 HTTP 解析Cloud FunctionsZIP 上传 Entry point无需 DockerGCP 自动装依赖PlaywrightCrawler / PuppeteerCrawler完整浏览器Cloud RunDocker 容器需自行包装 Express HTTP 服务监听 GCP 注入的PORT环境变量两者有一个共同点都要给爬虫传入new Configuration({ persistStorage: false })以保证云上无状态运行区别在于浏览器方案需要额外承担 HTTP 服务包装与容器化的工作。如果你的爬虫用 Cheerio 就能满足需求Cloud Functions 无疑是最轻量的选择。小结将 Crawlee 的 CheerioCrawler 项目部署到 GCP Cloud Functions核心就是三件事隔离配置独立ConfigurationpersistStorage: false、无状态包装每次调用新建爬虫实例、正确导出handler。再加上 ZIP 上传排除node_modules与 Entry point 设置即可完成一次标准的无服务器部署。这条路径与 AWS Lambda 方案 高度同构掌握了它你在其他 FaaS 平台上部署 Crawlee 也能举一反三。【免费下载链接】crawleeCrawlee—A web scraping and browser automation library for Node.js to build reliable crawlers. In JavaScript and TypeScript. Extract data for AI, LLMs, RAG, or GPTs. Download HTML, PDF, JPG, PNG, and other files from websites. Works with Puppeteer, Playwright, Cheerio, JSDOM, and raw HTTP. Both headful and headless mode. With proxy rotation.项目地址: https://gitcode.com/GitHub_Trending/cr/crawlee创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
在 GCP Cloud Functions 上部署 Crawlee CheerioCrawler 项目：从本地爬虫到云函数实战指南
在 GCP Cloud Functions 上部署 Crawlee CheerioCrawler 项目从本地爬虫到云函数实战指南【免费下载链接】crawleeCrawlee—A web scraping and browser automation library for Node.js to build reliable crawlers. In JavaScript and TypeScript. Extract data for AI, LLMs, RAG, or GPTs. Download HTML, PDF, JPG, PNG, and other files from websites. Works with Puppeteer, Playwright, Cheerio, JSDOM, and raw HTTP. Both headful and headless mode. With proxy rotation.项目地址: https://gitcode.com/GitHub_Trending/cr/crawlee本文是一份面向 Node.js 开发者的实战指南围绕 Crawlee 官方部署文档 docs/deployment/gcp-cheerio.md 展开完整讲解如何将基于CheerioCrawler的爬虫项目改造成 Google Cloud FunctionsGCP 云函数可运行的形态并完成上传部署与在线测试。读完本文你将掌握Configuration实例与persistStorage: false的隔离配置、无状态handler函数包装、GCP ZIP Upload 部署的完整步骤以及云函数入口点Entry point的配置方法同时结合仓库源码理解这些改动的底层原理。为什么 CheerioCrawler 适合跑在 Cloud Functions 上CheerioCrawler是 Crawlee 中基于纯 HTTP 请求 Cheerio 解析的轻量爬虫它不需要启动完整浏览器只发出普通 HTTP 请求并用 Cheerio 库解析 HTML 与提取数据。这意味着它的内存占用与冷启动开销都远小于 Puppeteer/Playwright 方案非常适合 GCP Cloud Functions 这类无服务器函数计算平台。官方文档中也明确指出在 Cloud Functions 上运行 CheerioCrawler 项目实际上相当容易只需要对项目代码做几处小改动。提示如果你的爬虫需要完整浏览器渲染可以参考仓库中的姊妹文档 docs/deployment/gcp-browsers.md —— GCP Cloud Functions 的最新运行时缺少运行 Chromium 所需的依赖因此浏览器类爬虫在 GCP 上应转向 Docker 容器平台 Cloud Run。第一步改造项目代码创建 Crawlee 项目并调整 package.json在本地使用 Crawlee 官方 CLI 创建项目npx crawlee create该命令对应仓库中 CLI 包的实现 packages/cli/src/commands/CreateProjectCommand.ts创建完成后终端会提示进入项目目录并运行npm start。创建完成后将package.json中的main字段设置为src/main.js。GCP Cloud Functions 会依据该字段定位项目入口文件{ name: my-crawlee-project, version: 1.0.0, main: src/main.js, ... }传入独立的 Configuration 实例修改src/main.js在构造CheerioCrawler时传入一个独立的Configuration实例并设置persistStorage: falseimport { CheerioCrawler, Configuration } from crawlee; import { router } from ./routes.js; const startUrls [https://crawlee.dev]; const crawler new CheerioCrawler({ requestHandler: router, }, new Configuration({ persistStorage: false, })); await crawler.run(startUrls);这一步包含两个关键语义理解它们对正确部署至关重要独立的Configuration实例默认情况下Crawlee 的所有爬虫实例共享同一个全局配置与存储通过Configuration.getGlobalConfiguration()访问全局单例见 packages/core/src/configuration.ts。如果云函数实例被复用这种共享状态会造成难以排查的偶发问题。为每个爬虫传入独立实例可以从根本上隔离状态。persistStorage: false启用纯内存存储persistStorage是 Crawlee 核心配置项之一默认值为true对应环境变量CRAWLEE_PERSIST_STORAGE字段定义见 packages/core/src/configuration.ts。设为false后Crawlee 不会把 Dataset、Key-Value Store、Request Queue 等持久化到本地磁盘而是全部保存在内存中。从源码看该选项直接决定存储后端的选择。在 packages/core/src/service_locator.ts 中getStorageBackend()会根据configuration.persistStorage二选一persistStorage为true默认→ 创建FileSystemStorageBackend数据写入storageDir默认./storage目录persistStorage为false→ 创建MemoryStorageBackend数据仅驻留内存。这与 AWS Lambda 场景完全一致详见 docs/deployment/aws-cheerio.md无服务器平台的本地文件系统要么只读、要么随时被回收只有关闭持久化、改用内存存储爬虫才是真正无状态、可安全复用的。用 handler 函数包装爬虫并导出接下来把爬虫调用包装进一个独立的handler函数。Cloud Functions 的入口函数需要满足可以是异步函数async接收两个位置参数req包含用户对云函数发起请求的详情与res可修改的响应对象调用res.send(data)将任意数据返回给调用方以命名导出named export的方式从src/main.js模块导出。改造后的完整src/main.jsimport { CheerioCrawler, Configuration } from crawlee; import { router } from ./routes.js; const startUrls [https://crawlee.dev]; export const handler async (req, res) { const crawler new CheerioCrawler({ requestHandler: router, }, new Configuration({ persistStorage: false, })); await crawler.run(startUrls); return res.send(await crawler.getData()) }其中crawler.getData()用于在爬取结束后读取 Dataset 中的全部结果并作为 HTTP 响应返回其底层对应 Dataset 的数据读取能力参见 packages/core/src/storages/dataset.ts 中getData()的实现。由于存储是内存态getData()读到的正是本次调用刚写入的数据天然满足无状态要求。无状态原则与 AWS Lambda 一致的铁律官方文档在 AWS Lambda 部署篇中给出了同一条硬性建议docs/deployment/aws-cheerio.md在 Cloud Functions 上同样适用务必为每次函数调用实例化全新的爬虫实例。AWS 会在首次执行后让运行环境存活一段时间以减少冷启动GCP 同理——后续的函数调用会触达已被使用过的爬虫实例。TLDR让云函数保持无状态。把new CheerioCrawler(...)放进handler内部而不是模块顶层正是这一原则的直接体现每次请求都得到全新的爬虫、全新的Configuration与全新的内存存储。第二步部署到 Google Cloud Platform创建云函数并配置资源在 Google Cloud 控制台中新建一个 Cloud Function并按需配置内存与 CPU根据爬取目标站点规模分配爬取大页面可适当提高内存区域Region选择离目标站点较近的区域以减少网络延迟函数超时Function timeout需覆盖完整爬取时长页面多、网络慢时应相应调大。选择 ZIP Upload 上传方式部署时选择ZIP Upload上传方式。GCP 会要求创建一个新的 GCSGoogle Cloud Storage存储桶用于存放 zip 包。打包时请注意关键区别只打包项目文件夹的全部内容排除node_modules文件夹。这一点与 AWS Lambda 不同——GCP 没有类似 Lambda Layers 的机制但它会根据package.json自动为你在云端安装项目依赖因此依赖目录不需要也不应该打进包里。项目文件夹/ ├── package.json ← GCP 据此安装依赖 ├── src/ │ ├── main.js ← 入口文件package.json 的 main 字段指向它 │ └── routes.js └── ...其余源码与配置排除 node_modules设置 Entry point上传后务必在函数配置中把Entry point设置为从src/main.js导出的函数名即handler。GCP 会从package.json的main字段读取入口文件并从 Entry point 配置得知要调用的导出函数两者配合才能正确触发爬虫。在 Testing 标签页验证函数部署完成后点击控制台中的Testing测试标签页即可验证。该页面会提供一段curl脚本用于调用你的新 Cloud Function。如果不想在本地安装gcloudCLI可以直接点击代码块上方的链接在 Cloud Shell 中运行这段脚本——无需任何本地命令行配置即可完成验证。与 Cloud Run 方案的对比同样是 GCP 上的部署Crawlee 官方对纯 Cheerio与浏览器方案给出了不同的平台建议对照 docs/deployment/gcp-browsers.md场景推荐平台部署形态关键差异CheerioCrawler纯 HTTP 解析Cloud FunctionsZIP 上传 Entry point无需 DockerGCP 自动装依赖PlaywrightCrawler / PuppeteerCrawler完整浏览器Cloud RunDocker 容器需自行包装 Express HTTP 服务监听 GCP 注入的PORT环境变量两者有一个共同点都要给爬虫传入new Configuration({ persistStorage: false })以保证云上无状态运行区别在于浏览器方案需要额外承担 HTTP 服务包装与容器化的工作。如果你的爬虫用 Cheerio 就能满足需求Cloud Functions 无疑是最轻量的选择。小结将 Crawlee 的 CheerioCrawler 项目部署到 GCP Cloud Functions核心就是三件事隔离配置独立ConfigurationpersistStorage: false、无状态包装每次调用新建爬虫实例、正确导出handler。再加上 ZIP 上传排除node_modules与 Entry point 设置即可完成一次标准的无服务器部署。这条路径与 AWS Lambda 方案 高度同构掌握了它你在其他 FaaS 平台上部署 Crawlee 也能举一反三。【免费下载链接】crawleeCrawlee—A web scraping and browser automation library for Node.js to build reliable crawlers. In JavaScript and TypeScript. Extract data for AI, LLMs, RAG, or GPTs. Download HTML, PDF, JPG, PNG, and other files from websites. Works with Puppeteer, Playwright, Cheerio, JSDOM, and raw HTTP. Both headful and headless mode. With proxy rotation.项目地址: https://gitcode.com/GitHub_Trending/cr/crawlee创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
