Cloudflare Workers 的代码包上限放宽到 64 MiB，让依赖较多的应用更容易部署到边缘运行环境。但代码能上传，不代表应用一定适配 Workers，也不代表运行成本为零。
这篇整理公众号“海冰AI备忘录”列出的 20 个开源项目，从短网址和 RSS 一直延伸到 AI 网关、IoT 与电商系统。先弄清限制和费用，再按用途选项目，会比只看“免费部署”更有帮助。
64 MiB 指的是未压缩代码包
Cloudflare 官方限制文档列明：Workers Free 和 Workers Paid 的 Worker size 上限均为 64 MiB，按未压缩 bundle 计算；不再另设压缩后体积上限。
这是一项代码包大小限制，不是运行内存额度。更大的依赖可以被打进包中，依然要符合运行时兼容性、启动时间、请求 CPU 时间和其他平台限制。
可以在本地用 Wrangler 预先构建并查看上传大小：
wrangler deploy --outdir bundled/ --dry-run输出中的 Total Upload 是未压缩代码包大小，gzip 数值用于参考。减少无用依赖、把静态资源放到合适的存储中，仍然有助于控制启动和部署成本。
一、个人工具：短链、粘贴板、书签和 RSS
1. Url-Shorten-Worker：短网址服务
项目地址：xyTom/Url-Shorten-Worker。
以 Workers 和 KV 实现长链接转短链接，可使用自己的域名。原文列出自定义短链、密码保护和 CAPTCHA 等能力。
短链服务每次请求的处理逻辑通常较轻，适合从小规模边缘应用入手。不过，要结合实际点击量检查 Workers 请求额度与 KV 读写额度；开放给公众使用时，也需要考虑滥用链接的管理。
2. shrtnr：带统计和 MCP 的短链平台
项目地址：oddbit/shrtnr。
除短网址外，原文列出点击统计、二维码、管理后台、API Key、多语言及 TypeScript、Python、Dart SDK，还包括 MCP Server。
它将短链从网页工具扩展成可被 Agent 调用的服务，底层使用 Workers 与 D1。仓库所述 Free Tier 部署方式适合作为起点，是否落在免费额度中仍由实际访问和数据库操作决定。
3. pastebin-worker：分享文本与配置片段
项目地址：xiadd/pastebin-worker。
适合分享代码、JSON、配置或日志，生成链接后供他人查看。原文介绍其使用 D1 保存内容和元数据，并支持 R2 文件上传。
这类服务可以减少聊天窗口中的大段粘贴，但上传前应先清除 API Key、密码和内部地址等敏感信息。
4. Gongyu：自托管书签管理
项目地址：angristan/gongyu。
原文列出的功能包括全文搜索、缩略图、Bookmarklet、Atom Feed、导入导出和备份恢复，并可将收藏同步发布到 Mastodon、Bluesky。
其架构组合使用 Workers、D1、R2、Queues 与 Workflows。它适合希望统一管理大量收藏、保留搜索和导出能力的用户；选择前可重点检查网页内容抓取与后台任务的用量。
5. TSRSS：自己的 RSS 阅读器
项目地址：johnwmail/tsrss。
一个基于 Workers 与 D1 的 RSS 阅读器。用途直接：自己选择订阅源，在统一入口阅读更新。
与一次性访问页面不同，RSS 抓取通常需要定时任务和数据库写入。订阅源数量、刷新频率与历史保留时间，会影响实际资源消耗。
二、站长工具：监控、访问分析和资源管理
6. UptimeFlare：站点监控与状态页
项目地址：lyc8503/UptimeFlare。
原文介绍它可以监控网站、API、SSL 证书及服务状态，并提供多地区检测、故障历史、计划维护与 Webhook 通知。
这类工具的价值在于更早发现故障，并向用户展示服务状态。项目配置与存储方案会演进，部署时应按对应版本的 README 核对 D1 等绑定，而不直接照搬旧教程。
7. MonitorFlare：监控、订阅与备份
项目地址：xusteve/MonitorFlare。
原文列出 Vue 3 与 PWA 前端、Worker 后端、D1 监控记录及 R2 每日备份等组件。项目目标是让小规模网站监控落在免费套餐额度内。
“以免费额度为目标”需要与“任何规模都免费”区分。监控目标数量、检查间隔、通知和备份保留策略都会改变用量。
8. InsightFlare：自托管访问分析
项目地址：RavelloH/InsightFlare。
原文将它定位为注重隐私、无需 Cookie 的 Web Analytics，技术栈包括 Workers、Durable Objects、D1、KV 与 R2。
它适合希望掌握分析数据存储位置的站长。无 Cookie 并不自动免除数据管理责任，实际采集字段、保留期限与站点隐私说明仍需要匹配。
9. Dashflare：非官方 Cloudflare 管理面板
项目地址：SukkaW/dashflare。
通过 Cloudflare API 查看和管理 DNS、缓存、TLS 等资源。它属于对现有平台能力的另一种界面组织方式。
部署这类面板时，核心配置是 API Token 的权限范围；应按实际管理需求授权，而不是为了省事把账号级全部权限交给应用。
10. cf-ledger：按应用理解资源费用
项目地址：dennisklappe/cf-ledger。
当一个账号同时运行多个 Worker、数据库和存储桶时，总账单不一定能直观看出每个项目的成本。原文介绍 cf-ledger 会定期收集用量，并按应用拆分成本信息，本身也运行在 Worker 上。
它更适合已经拥有多个项目的开发者，用来建立持续观察用量的习惯。
三、AI 应用：对话、网关和 Agent 分析
11. workersai：AI Chat 应用
项目地址：akazwz/workersai。
原文列出 AI 对话、TTS、STT 与对话状态等功能，组合使用 Workers、Durable Objects、KV 和 AI Gateway。
这类应用展示了边缘平台承载界面、请求编排和状态管理的方式。模型推理本身可能由 Workers AI 或其他上游服务提供，其额度与费用要单独核对。
12. ai-gateway-openai-wrapper：API 网关封装
项目地址：pokon548/ai-gateway-openai-wrapper。
Worker 位于客户端与真实上游之间，上游 API Key 保存在服务端，客户端使用网关凭据调用，再通过 Cloudflare AI Gateway 转发。
这样可以集中观察请求和管理凭据，但客户端替代 Key 仍需要保护。只有在网关确实验证访问权限、限制用量时，隐藏真实上游 Key 才能形成有效的访问边界。
13. cc-monitor-worker：观察 Claude Code 用量
项目地址：cometkim/cc-monitor-worker。
原文介绍它通过 OpenTelemetry 或 API Proxy 收集使用信息，利用 Workers Analytics Engine 查看 Token、成本与使用趋势。
对团队来说，适合关注任务、会话和模型用量如何变化。费用统计还需要匹配实际模型价格与采集范围，不能仅凭估算值代替供应商账单。
14. Agent Analytics：Agent 事件分析
项目地址：Agent-Analytics/agent-analytics。
面向 AI Agent 的事件记录与统计，原文列出用户识别、项目统计和事件历史等能力。
如果网站分析回答的是用户看了哪些页面，Agent 分析更关注调用了什么工具、经历了哪些步骤、任务在何处结束。记录事件时应控制需要保留的内容，避免把完整业务上下文不加筛选地写入分析系统。
15. Prism：AI 编程面试网关
项目地址：OkLychee/prism。
原文将其定位为 AI Coding Interview 网关，支持 OpenAI 与 Anthropic 协议。面试官可以分配受控 Key，设置 Token 数量、允许模型和有效期，并查看候选人的提示时间线。
这类工具关注的是如何提供可观察、可限额的 AI 使用环境，而不只是限制候选人是否能使用 AI。
四、实时应用与 IoT
16. Cloudflare Workers Chat Demo：实时聊天室
项目地址：cloudflare/workers-chat-demo。
这是 Cloudflare 官方的聊天室示例，使用 Durable Objects 与 WebSocket 管理聊天室连接、广播和状态。
它适合学习有状态边缘应用的组织方式。Durable Objects 的存在让 Workers 不只承担无状态 HTTP 转发，也能为需要多人协调的功能提供状态入口。
17. nodrix：IoT 数据与仪表盘
项目地址：decoded-cipher/nodrix。
原文介绍 ESP32、ESP8266 等设备可以经 HTTPS 或 WebSocket 上传遥测数据，再通过仪表盘观察变量、创建自动化、读取 API 或分享页面。
其后端组合使用 Workers、Durable Objects、D1 与 R2。设备数量和上报频率对成本影响明显，评估时应从实际遥测流量出发。
五、电商与行业 SaaS
18. minshop：全栈电商应用
项目地址：ddyy/minshop。
原文列出商品、分类、购物车、后台、订单、客户、库存、图片、搜索及数字商品等模块，并接入 Stripe、Lightning Payment、OpenNode，提供 API 或 MCP 入口。
项目使用 D1 保存数据、R2 保存文件，应用运行在 Workers 上。即使使用免费套餐作为初始部署配置，支付手续费和外部服务费用也不在 Workers 免费额度之内。
19. Tinycrate：多租户电商平台
项目地址：nicco-b/tinycrate。
与单个店铺相比，多租户平台还需要处理商家之间的数据与配置隔离。原文列出独立店铺、子域名或自定义域名、后台、Stripe Checkout、订阅退款、运单和 Magic Link 登录等能力。
底层组合包括 D1、R2、KV 与邮件绑定。它展示的是更完整的 SaaS 结构，生产使用前要逐项核对第三方账号和平台功能的开通条件。
20. OpenInspection：房屋验房行业应用
项目地址：InspectorHub/OpenInspection。
原文描述的功能包括客户、预约、现场检查、照片、报告、电子签名、PDF、PWA 离线、多人编辑、AI 辅助、Stripe、邮件与审计记录。
它将 Worker 与 D1、Durable Objects 等服务组合成垂直行业应用。对开发者来说，值得研究的是这些模块如何协作；功能清单本身不能证明某个版本已满足所有生产需求。
免费额度应该怎样判断
判断一个项目能否低成本运行，需要同时看三层资源。
第一层是 Worker 本身，包括请求、CPU 时间、子请求、启动时间与包体。第二层是绑定服务：D1 的读写、KV 的操作、R2 的存储和请求、Durable Objects 等都有自己的配额与计费。第三层是外部依赖，例如模型 API、支付、邮件与其他第三方服务。
因此，更准确的结论是：部分个人项目、小工具和低流量应用可以从免费额度起步；用量增长后，仍应按各组件的规则核算。基础组件如何搭配，可继续阅读本站的 Cloudflare 核心服务与搭配方式；需要选择存储时，可参考 Workers KV 的限制与适用场景。
64 MiB 降低了部分应用打包部署的门槛。这 20 个项目更值得研究的地方，是它们如何把计算、数据库、对象存储和状态协调组合起来，解决具体需求。
