为了解决 Cloudflare Pages Functions 请求数过高（每天超过 10 万次限制）的问题，我们对项目进行了以下关键优化：
我们根据媒体类型拆分了流量路径，以平衡成本与功能：
| 资源类型 | 处理策略 | 路由地址 | Functions 消耗 | 说明 |
|---|---|---|---|---|
| 图片 (JPG/PNG/WebP) | 外部代理 | wsrv.nl |
0 | 使用免费的全球即时图片处理服务，完全剥离流量压力。 |
| 贴纸 (Stickers) | 外部代理 | wsrv.nl |
0 | 同上。 |
| 视频 (MP4) | 本地代理 | /static/ |
1次/请求 | wsrv.nl 不支持视频，保留本地代理以确保播放功能。 |
| 音频 (MP3/OGG) | 本地代理 | /static/ |
1次/请求 | 同上。 |
调整了 src/lib/telegram/index.js 中的懒加载策略：
- 变更：将立即加载（Eager Load）的阈值从前 16 个帖子降低为 前 5 个。
- 收益：
- 大幅减少首屏加载并发请求数。
- 有效规避
wsrv.nl的速率限制（700请求/3分钟），确保服务稳定性。
优化了 src/middleware.js，设置了更激进的 Cache-Control 头：
s-maxage=3600：指示 Cloudflare CDN 缓存 HTML 页面 1小时。在此期间，重复访问直接命中 CDN，不消耗 Functions 额度。
原理：基于 Serverless 函数的透明反向代理。
- 工作流：用户请求图片 -> 触发 Cloudflare Function -> 脚本下载图片 -> 脚本转发给用户。
- 问题：
- 按次计费：每张图片的加载都会触发一次代码执行。如果页面有 100 张图，刷新一次就消耗 100 个配额。
- 资源浪费：这相当于雇佣了一个“秘书”，每次看照片都要秘书亲自跑一趟 Telegram 总部取回来。
原理：基于 Nginx 和 CDN 的公共图片缓存服务。
- 工作流：用户请求图片 -> wsrv.nl 全球 CDN 节点 -> (如无缓存)回源获取并优化 -> 返回给用户。
- 优势：
- 零消耗：流量完全不经过你的 Cloudflare 账号。
- 高性能：自动进行 WebP 转换和压缩，加载速度更快。
- 省心：相当于直接告诉用户“照片在快递柜，自取”，你的“秘书”（Function）可以休息了。