TG Books Site

这个项目来自一个具体的场景：服务器能访问 Telegram，但用户不一定能。有一批电子书存放在 Telegram 群组里，需要一个方式让用户通过普通网页浏览和下载，而不是直接进 Telegram。

为什么用 Telegram 当存储后端

Telegram 本身是一个可靠的文件托管平台——上传的文件永久保留，不限容量，CDN 分发，Bot API 提供稳定的下载代理接口。与其另起炉灶搭对象存储，不如直接复用已有的 Telegram 群组作为仓库。

这是这个项目最核心的产品决策：不迁移存储，而是在 Telegram 上搭一层 Web 界面。

关键技术决策

1. Python + FastAPI，SQLite 做全文检索

后端选 FastAPI 而不是更重的框架，因为这里的业务逻辑本质上是：同步 Telegram 消息 → 存元数据 → 代理下载。接口数量有限，不需要 ORM 或复杂的中间件体系。

SQLite 内置 FTS5 扩展，对标题、作者、标签做全文检索开箱即用。不引入额外的搜索服务，部署复杂度保持最低。

2. Telegram Bot API 代理下载

用户点击下载时，后端通过 Bot API 获取文件的临时下载链接，再以流式代理转发给浏览器。这样用户侧不需要访问 Telegram，服务器作为唯一出口。

封面缩略图同理——Bot API 拉取后缓存到本地文件系统，避免每次都回源。

3. React SPA，语言 tab + 分类过滤

前端用 React + Vite 构建，最终由 FastAPI 静态托管，不需要单独的前端服务器。

UI 的核心交互是两层过滤：顶部 tab 按语言切换（ALL / EN / 中文等），下方 chip/下拉按分类过滤。搜索走模糊匹配，即时响应。移动端和桌面端布局分开处理，分类过滤在移动端收进下拉框。

4. Admin 功能

图书馆内容来自 Telegram 消息的解析，但自动解析不总是准确。Admin 面板允许手动修正书目元数据（标题、作者、语言、标签等），也可以从库中移除条目，可选是否同步删除 Telegram 原消息。

Admin 接口通过 X-Admin-Key 请求头鉴权，key 通过环境变量配置。

项目结果

一个完全自托管、无外部依赖的电子书站点——Telegram 存文件，SQLite 存元数据，单个 Python 进程同时服务 API 和前端静态资源。

对我来说最值得记录的是：Telegram Bot API 作为存储后端比预期稳定得多，文件代理的延迟在可接受范围内，且不需要维护任何存储基础设施。