sitebox后端部署指南

1. 什么是 wrangler.toml backend/wrangler.toml 是 Worker 项目的部署配置文件,相当于 Cloudflare 的“项目清单”。 当前项目示例: name = "sitebox-backend" main = "server.mjs" compatibility_date = "2024-01-01" compatibility_flags = ["nodejs_compat"] [[d1_databases]] binding = "DB" database_name = "sitebox" database_id = "148bb43e-fb40-4dc5-94e0-f2e689194b4b" [vars] DEPLOY_MODE = "cloudflare" GITHUB_TOKEN="xxxxxxxxxxxxxxxxxxxxxxxx" GITHUB_REPO="xxxxxx/yyyyyyyy" GITHUB_PATH="backup_json/backup.json" 各字段含义: name:Worker 服务名(最终会生成可用地址 <name>.<subdomain>.workers.dev) main:入口文件(本项目是 server.mjs,ES Module) compatibility_date:Cloudflare 运行时兼容日期 compatibility_flags:运行时特性开关(这里启用 nodejs_compat) [[d1_databases]]:D1 数据库绑定 binding = "DB" 表示代码里通过 env.DB 访问数据库 database_id 指向具体 D1 数据库 [vars]:普通环境变量(非敏感) 注意:database_id 通常是资源标识,不是密钥;真正敏感的是 API Token / Secret。 2. 使用 Wrangler CLI 部署(推荐) 适用于当前这套 SiteBox 后端,最稳妥。 2.1. 前提 Node.js >= 18 Cloudflare 账户 已在 backend/ 中准备好 wrangler.toml 2.2. 部署步骤 cd SiteBox/backend npm install npx wrangler login npm run deploy:cf 部署成功后会输出 Worker 地址,如: ...

2026年3月20日 · 5 分钟 · 冇文化

sitebox前端部署与使用指南

1. 网站信息设置之图标设置 在当前后端项目中,网站图标(Favicon)的处理方式为“动态生成外部 URL 链接”。 以下是具体的处理逻辑: 1.1. 图标 URL 的生成逻辑 (utils/faviconUtils.js) 后端不再将图标下载到本地服务器,而是根据网站域名生成指向第三方图标服务的 URL: 优先使用 DuckDuckGo 服务:生成的格式为 https://icons.duckduckgo.com/ip3/{domain}.ico。 Google 服务兜底:如果 URL 解析出现异常,会退而使用 Google 的图标 API:https://www.google.com/s2/favicons?sz=64&domain_url={websiteUrl}。 支持自定义:如果用户手动提供了图标 URL,后端会优先采用用户提供的地址。 1.2. 业务层的处理流程 (services/websiteService.js) 创建网站时:系统会自动调用 fetchFavicon 方法,根据用户输入的网站地址生成对应的图标 URL,并将其存入数据库。 更新网站时: 如果用户修改了网站的 url(导致域名变化),或者当前记录中缺失图标,系统会重新生成图标 URL。 如果域名未发生变化,则继续沿用现有的图标 URL,避免不必要的更新。 删除网站时:由于不再存储本地物理文件,删除操作仅需清理数据库记录,无需处理文件删除逻辑(相关方法已变更为 no-op)。 1.3. 数据存储 图标信息直接以字符串形式存储在 SQLite 数据库 websites 表的 favicon_url 字段中。 1.4. 自定义设置技巧(可选操作,可以不填,自动获取) 1.4.1. 方式一:使用网络图片 URL GitHub 图片的正确地址格式: Raw 格式(推荐):https://raw.githubusercontent.com/你的用户名/仓库名/main/图片路径(main也可能是master,看仓库主支名字) jsDelivr CDN 格式(更快): https://cdn.jsdelivr.net/gh/你的用户名/仓库名@main/图片路 示例: 假设你的 GitHub 用户名是 zhangsan,仓库名是 my-icons,图片在仓库根目录叫 logo.png,那么填写:https://raw.githubusercontent.com/zhangsan/my-icons/main/logo.png 或者用 CDN 加速:https://cdn.jsdelivr.net/gh/zhangsan/my-icons@main/logo.png 在添加网站的表单中,找到"图标地址"或"Favicon"输入框,粘贴上述地址即可。 获取网站的真实favicon地址 1.4.2. 方式二:存放在项目后端服务中(仅仅对非cf部署情况有效) 在图标地址栏输入相对路径,如 /data/icons/custom.ico 要使用这个相对路径,需要确保,后端服务器/data目录下有相应的文件或者文件夹。可以在部署的时候将/data/incos/这个文件夹挂载到本地某个具有图片资源的文件夹 2. nginx配置模版 2.1. ✅ 优化后的完美模板 server { listen 80; server_name localhost; # 监听域名,可以根据需要修改 root /usr/share/nginx/html; # 前端静态文件根目录 index index.html; # ======================================================= # 处理 favicon.ico 请求(直接提供文件) location = /favicon.ico { expires 30d; add_header Cache-Control "public, immutable"; } # ======================================================= # 个人导航主站 (必须放在特定的 location 后面) location / { try_files $uri $uri/ /index.html; # SPA 应用,处理路由问题 } location /api/ { # 直接代理到变量地址,完美支持 IP 或 域名 proxy_pass ${BACKEND_PROTO}://${BACKEND_ADDR}; # 强制设置 Host 头,对云服务/外部域名极其重要 proxy_set_header Host ${BACKEND_HOST}; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 开启 SNI 支持:如果是 https 域名,这行保命;如果是 http IP,这行无副作用 proxy_ssl_server_name on; } } 2.2. 💡 变量赋值示例(供参考验证) 当使用这个完美模板时,针对两种场景,环境变量应该这样传: ...

2026年3月20日 · 3 分钟 · 冇文化

CF的D1数据自动同步到githu仓库

为了保证成功,我将流程分为四个详细步骤: 第一步:准备 GitHub 访问令牌 (PAT) 你需要一个令牌让 Cloudflare 有权把文件写入你的私有仓库。 登录 GitHub,访问 Tokens (Fine-grained) 设置页面。 点击 Generate new token。 Token Name: 填 CF-D1-Backup。 Repository access: 选择 Only select repositories,并选择 用户名/仓库名。 Permissions: 点击 Repository permissions,找到 Contents,选择 Read and write。 点击 Generate token,立即复制并保存这个 Token(它只会出现一次)。 第二步:准备 Cloudflare API 令牌 Worker 需要权限来操作 D1 数据库进行导出。 访问 Cloudflare API Tokens 页面。 点击 Create Token。 选择 Create Custom Token。 Token name: D1-Export-Token。 Permissions: Account -> D1 -> Edit (导出操作需要 Edit 权限)。 Resources: Include -> 你的账号。 点击继续并生成,保存这个 Token。 同时,在 D1 数据库的控制面板页面,记录下你的 Account ID 和 Database ID。 ...

2026年3月20日 · 7 分钟 · 冇文化

优雅至极:基于 Hugo + Cloudflare 构建代码与内容分离的静态博客

在搭建个人博客时,很多人会将博客的框架代码(如 Hugo/Hexo)、主题文件和文章的 Markdown 文件混在一个 GitHub 仓库里。这虽然简单,但随着文章越来越多,你的写作环境会被各种前端配置文件干扰;而且,如果你想写一些不公开的私密草稿,公开的仓库也无法满足需求。 为了获得最纯粹的写作体验,我采用了 「代码与内容分离」 的架构。今天这篇文章,就来详细聊聊如何基于 Hugo + PaperMod 主题,配合 Cloudflare Pages 部署这样一个现代化的博客。 🏗️ 架构概览:双仓库联动 我的博客由两个 GitHub 仓库组成: 引擎仓库 (公开):PaperMod-Blog-Cloudflare 角色:博客的“打印机”与“骨架”。 内容:包含 Hugo 的配置文件、PaperMod 主题、自定义 CSS 等。没有实质性的文章内容。 内容仓库 (私有):blog-content 角色:博客的“燃料”与“血肉”。 内容:纯净的 Markdown 文件和图片资源。 优势:设置为 Private (私有),确保草稿和私密笔记的安全。写作时只需在本地使用 Obsidian 或 Typora 即可。 这两个仓库通过 Hugo Modules(Go Modules 底层)连接。当云端开始构建时,引擎会自动把内容仓库拉取过来,合并渲染成最终的网页。 在 config.yml 中添加如下配置: module: imports: - path: github.com/adityatelange/hugo-PaperMod - path: github.com/monstercjz/blog-content mounts: - source: blog-paper # 内容仓库的blog-paper目录 target: content/posts # 挂载到 content/posts 🛠️ 部署痛点一:Cloudflare 如何拉取私有内容? 将公开的引擎仓库绑定到 Cloudflare Pages 非常简单,但在执行 hugo 构建命令时,如何拉取私有的 blog-content 仓库是核心难点。 ...

2026年3月18日 · 7 分钟 · 冇文化