📚 全部文章

本文旨在为初学者和进阶用户提供一份清晰、实用的 Git 使用指南。Git 是目前世界上最先进的分布式版本控制系统。 1. 基础配置 在开始使用 Git 之前，你需要配置你的身份标识。 # 设置全局用户名 git config --global user.name "你的名字" # 设置全局邮箱 git config --global user.email "你的邮箱@example.com" # 查看配置列表 git config --list 2. 基础工作流 Git 的核心工作流通常涉及以下几个步骤： 初始化仓库 # 在当前目录初始化一个新的 Git 仓库 git init 状态查询 # 查看当前工作区的状态（哪些文件被修改了，哪些在暂存区） git status 添加到暂存区 # 添加指定文件到暂存区 git add <filename> # 添加所有修改过的文件到暂存区 git add . 提交到本地仓库 # 提交暂存区内容到仓库，并添加提交说明 git commit -m "提交说明内容" 查看日志 # 查看提交历史 git log # 以精简的一行形式查看日志 git log --oneline 3. 分支管理 分支是 Git 的杀手锏功能，允许你同时进行多个任务。 ...

服务端简单配置 注意： 使用了"method": "2022-blake3-aes-128-gcm", Shadowsocks-2022对密码格式有严格的校验要求，如果不符合规范，sing-box 启动时会直接报错。 密码必须是 Base64 格式。 密码生成方式： openssl rand -base64 16 生成的字符串类似于vgY7B3N6hM+8pW/J1Q9v9g==，把它填入 password 字段。 { "log": { "level": "info" }, "dns": { "servers": [ { "type": "tls", "tag": "ali-dns", "server": "223.5.5.5" } ] }, "inbounds": [ { "type": "shadowsocks", "tag": "ss-in", "listen": "::", "listen_port": 10808, "network": [ "tcp", "udp" ], "method": "2022-blake3-aes-128-gcm", "password": "vgY7B3N6hM+8pW/J1Q9v9g==", "multiplex": { "enabled": true, "padding": true } } ], "outbounds": [ { "type": "direct", "tag": "direct" } ], "route": { "rules": [ { "port": 53, "action": "hijack-dns" } ], "final": "direct" } } 客户端配置 下面的模版是，根据局域网设备的ip，确定出口 ...

非容器模式 前端部署 后端部署 容器模式 在一个 VPS 上部署前后端时，最科学、最省资源的方案是：利用前端容器自带的 Nginx 兼职做全站反代。 在这种情况下，只需要 一个 Nginx（即前端容器里的那个） 就可以处理所有事情：发送 HTML、解决 SPA 路由、转发 API 请求。 以下是针对“同机部署”的两种模板： 方案一：本地构建模式 (Build 模式) 适用场景：你在 VPS 上拉取了源码，想直接根据源码生成镜像并运行。 📂 目录结构 /opt/sitebox/ ├── frontend/ # 前端源码 (含 Dockerfile 和 nginx.conf) ├── backend/ # 后端源码 (含 Dockerfile 和 server.node.js) └── docker-compose.yml 🚀 docker-compose.yml (Build) version: '3.8' services: # 前端：既是网页服务器，也是 API 网关 frontend: build: context: ./frontend dockerfile: Dockerfile container_name: sitebox-frontend restart: always ports: - "80:80" # 外部通过 80 端口访问整个项目 environment: - BACKEND_PROTO=http - BACKEND_ADDR=backend:3000 # 使用内部服务名，流量不走公网，安全且快 - BACKEND_HOST=backend networks: - sitebox-net # 后端：纯 API 服务 backend: build: context: ./backend dockerfile: Dockerfile container_name: sitebox-backend restart: always expose: - "3000" # 端口只对容器开放 # ports: # - "3000:3000" # 端口对公网开放，比如给插件使用 environment: - PORT=3000 - DB_PATH=/app/data/db/sitebox.db - DEPLOY_MODE=docker # 如果要同步到github这下面三个参数是必填项 - GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxx - GITHUB_REPO=xxxxxx/yyyyyyyy - GITHUB_PATH=backup_json/backup.json volumes: - ./data/db:/app/data/db # 持久化数据库 networks: - sitebox-net networks: sitebox-net: driver: bridge 方案二：远程镜像模式 (Image 模式) 适用场景：已经在本地打包好镜像推送到 Docker Hub，VPS 只需要一行命令直接起飞。 ...

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 地址，如： ...

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. 💡 变量赋值示例（供参考验证） 当使用这个完美模板时，针对两种场景，环境变量应该这样传： ...