Yukkihome

Office 365 订阅状态监控系统的配置

Sat, 15 Nov 2025 00:00:00 GMT

这是xiaokun567佬开发的一款面板，可以检查当前365订阅的状态和用户信息

项目地址：xiaokun567/office365: 一个轻量级的 Office 365 订阅状态监控系统，支持自动检测、手动检测和异常通知。

下载和启动

创建一个文件夹，例如office365
进入文件夹内，输入git clone https://github.com/xiaokun567/office365
安装依赖，pip install -r requirements.txt
启动程序，python app.py
访问系统，看Terminal显示的地址

[!NOTE] 依赖安装到虚拟环境的方法：
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt

配置方法

1. 进入面板

点击右上角设置
往下移动点击添加订阅

2. 获取订阅token

进入Admin面板-Billing-Licenses-随便找个你订阅的365点进去
F12打开开发者工具，找到网络，搜索subscriptions，刷新
选择复制为cURL(bash)
粘贴到许可证查询 Curl 命令

3. 获取用户token

进入Admin面板-Users-Active users
F12打开开发者工具，找到网络，搜索user，刷新
选择复制为cURL(bash)
粘贴到创建用户的 Curl 命令

试一试缤纷云

Sat, 01 Nov 2025 00:00:00 GMT

存储费用

给了慷慨的50G，而且还有一条规则：每个小时 S4 产生的出口流量数可抵扣当前小时相应容量的存储费用，即：该小时 A、B、C 三个桶的出口流量总共为 40GB，则该小时存储费用全免（12GB存储费用被40GB流量抵消

流量费用

并且这三项每项独立，不知道S4出口流量和CDN回源流量是不是一起算的。并且CDN 海外节点回源跨境加速流量目前是全免费的另外还有一条限制：免费额度为每月每项10GB，但为防止滥用，目前限制每天用量不能超过5GB（当天超过5GB后会开始计费）

请求费用

每月免费10w次，看起来直接请求存储桶和请求CDN是分开算的

媒体处理费用

这项目前还是免费使用

七牛云免费额度的坑

Sat, 01 Nov 2025 00:00:00 GMT

Kodo对象存储

首先，只有标准存储才有免费额度，空间是10G，创建存储桶的时候不能选错

流出流量的10G免费额度，必须通过CDN回源才行，直接访问存储桶是会被收费的幸好我这里没有直接投入生产使用，没有被扣太多费用

CDN

于是赶紧去配置了Kodo的加速域名（七牛云会系统分配一个域名，但是每30天会变，很麻烦），但是没想到CDN还有一层坑七牛云的CDN流量是额外计费的，每个月是10G，而且只有HTTP流量有免费额度。难怪官方分配的域名是HTTP的最后，如果要删除配置好的域名，需要到控制台-加速域名，选择停用并输入密码，然后才可以删除

一种备份本地Postgres和Redis数据库到Neon和Upstash的方法

Wed, 29 Oct 2025 00:00:00 GMT

Postgress

从Neon拉取到本地

使用本地的postgres从neon dump

sudo docker compose exec -T memos-postgres pg_dump "You_PG_URL" > ./backup/memos_backup.sql

恢复到本地postgres数据库

cat ./backup/memos_backup.sql | sudo docker compose exec -T memos-postgres psql -U memos -d memos

备份到云端

创建脚本 sync_to_cloud_backup.sh

#!/bin/bash
set -euo pipefail

# === Configuration ===

# 1. Your Compose project network's full name
# Verify with: sudo docker network ls | grep caddy_network
COMPOSE_NETWORK="docker_caddy_network" 

# 2. Backup path (using your home directory for safety)
BACKUP_DIR="/home/yukki/docker/backup"
mkdir -p "$BACKUP_DIR"
DUMP_FILE="$BACKUP_DIR/redis.dump" # Define the dump file name

# 3. PostgreSQL (Neon connection string)
NEON_DB_URL="You_PG_URL"

# 4. Redis (Upstash connection string)
UPSTASH_URL="You_Upstash_URL"

# 5. Log file
LOG_FILE="$BACKUP_DIR/backup_$(date +%Y%m%d_%H%M%S).log"
exec > >(tee -a "$LOG_FILE") 2>&1

echo "===== Backup started at $(date) ====="

# === PostgreSQL Part (Memos Backup) ===
# ... (This part was correct, keep it) ...
echo "[1/2] Dumping PostgreSQL from 'memos-postgres'..."
docker compose exec -T memos-postgres \
    pg_dump -U memos -d memos --format=custom \
    > "$BACKUP_DIR/memos.dump"

echo "[1/2] Restoring PostgreSQL dump to Neon..."
docker run --rm -v "$BACKUP_DIR/memos.dump:/backup/memos.dump" postgres:17 \
    pg_restore --clean --no-acl --no-owner -d "$NEON_DB_URL" /backup/memos.dump

echo "✅ PostgreSQL (Memos) backup to Neon successful."

# === Redis Part (LunaTV Backup) ===

# !!! Using the Go binary to DUMP and redis-cli to PIPE from file !!!
echo "[2/2] Dumping Redis from 'lunatv-redis' (using Go tool)..."

# !!! Prerequisite: Ensure lunatv-redis exposes port 6379 to host's localhost:
# ports:
#  - "127.0.0.1:6379:6379"
# (Restart lunatv-redis if you just added this)

# Execute the Go binary to dump to the file
# Using the correct flags based on its help output
./backup/upstash-redis-dump \
    -host localhost \
    -port 6379 \
    --output resp \
    > "$DUMP_FILE"

echo "[2/2] Piping Redis dump file to Upstash (using redis-cli)..."

# Execute redis-cli inside the lunatv-redis container
# Use --tls and --pipe, reading (<) from the dump file
# Note: We mount the backup dir into the container temporarily
docker run --rm \
    --network="$COMPOSE_NETWORK" \
    -v "$BACKUP_DIR:/backup" \
    redis:alpine \
    sh -c "redis-cli --tls -u '$UPSTASH_URL' --pipe < /backup/redis.dump"

echo "✅ Redis (LunaTV) backup to Upstash successful."

# Cleanup the temporary dump file (optional)
# rm -f "$DUMP_FILE"

echo "===== Backup finished successfully at $(date) ====="

下载upstash-redis-dump到backup目录 https://github.com/upstash/upstash-redis-dump

给予执行权限

chmod +x /home/yukki/docker/sync_to_cloud_backup.sh
chmod +x /home/yukki/docker/backup/upstash-redis-dump

执行脚本

sudo /home/yukki/docker/sync_to_cloud_backup.sh

定时备份

sudo crontab -e
# 每天凌晨 3:00 执行备份脚本
0 3 * * * /usr/bin/bash /home/yukki/docker/sync_to_cloud_backup.sh >> /home/yukki/docker/backup/cron_$(date +\%Y\%m\%d).log 2>&1

Web开发免费资源指南

Wed, 22 Oct 2025 00:00:00 GMT

一、前端部署服务 (Frontend Deployment)

对于现代前端框架（如 React, Vue, Svelte）构建的静态或服务端渲染（SSR）应用，以下平台提供了极致的部署体验和慷慨的免费额度。

Vercel
- 免费额度 (Hobby Plan): Vercel 的 Hobby 套餐非常适合个人项目。它提供每月 100GB 带宽、每月 6,000 次 Serverless Function 执行，以及自动 CI/CD。对于个人博客或作品集网站来说绰绰有余。
Netlify
- 免费额度 (Starter Plan): 提供每月 100GB 带宽、300 分钟构建时间（Build Minutes）。它同样拥有强大的全球 CDN、CI/CD、Serverless Functions，并包含表单处理、身份认证等功能。
Cloudflare Pages
- 免费额度: 免费版提供了无限的静态站点、无限的请求数和无限的带宽。其全球边缘网络性能顶级，并能与 Workers 无缝集成。是纯静态网站的“天花板”选择。
腾讯云 EdgeOne
- 免费额度 (个人版): 面向中国大陆访问的绝佳选择。个人版（免费）提供不限量的 CDN 流量和不限量的 DDoS 防护，并有每月 10 万次的边缘函数（Edge Functions）调用额度。

二、后端与全栈部署 (Backend & Full-Stack Deployment)

需要托管 Docker 容器、后端 API 或更复杂的应用时，以下平台提供了强大的 Serverless 或 PaaS（平台即服务）能力。

Google Cloud Run
- 免费额度 (Always Free): 永久免费层级包括每月 200 万次请求、180,000 vCPU-秒 的计算时间和 360,000 GiB-秒 的内存使用。它会根据请求自动缩放至零，没有请求时不产生费用。
Zeabur
- 免费额度: 提供每月 5 美元的免费信用额度。您可以用来部署任意服务（如 Node.js, Docker, Postgres 等）。对于小型服务，5 美元的额度足以支撑多个项目免费运行。
ClawCloud Run
- 免费额度: 使用大于180天的Github账号注册，提供每月 5 美元的免费额度。可以用来部署任意Docker服务（如 Node.js, Docker, Postgres 等）。按照CPU核数、Ram、Storage和实例数量付费。
Render
- 免费额度 (Web Services): 提供每月共 750 小时的免费实例运行时间（所有免费 Web 服务共享）。服务在闲置 15 分钟后会自动休眠（下次访问时唤醒）。此外还包括 100GB 免费出口带宽。
- (请注意：Render 的免费 Postgres 数据库有 30 天的试用期限制，之后会过期，不适合用于永久免费存储。)
[Railway](Railway Pricing and Plans)
- 免费额度第一个月5美元，后面每个月1美元。最多512MB存储，1v CPU，0.5G Volume

三、 Serverless Postgres 数据库

Serverless 数据库按需使用、自动扩展，并提供慷慨的永久免费层级。

Neon
- 免费额度 (Free Tier): 提供 20 个项目，每个项目 0.5 GB 存储空间，每月每个项目 100 计算小时（Compute Hours）。支持数据库分支（Branching）功能，并会在不活动时自动休眠。
Supabase
- 免费额度 (Free Plan): 不只是数据库，更是一个开源的 Firebase 替代品。免费版包含 2 个免费项目、每个项目 500MB 数据库空间、1GB 文件存储、50,000 月活跃用户（Auth），以及实时数据库和边缘函数。
Prisma Postgres
- 免费额度：
  - 100,000 operations included
  - 500 MB storage
  - 5 databases
  - No credit card required

四、 Serverless Redis 缓存

Upstash
- 免费额度 (Free Tier): 提供了性能极高的 Serverless Redis。免费版支持每天 10,000 条命令，最大 256MB 数据存储，延迟极低，非常适合用作缓存、会话存储或速率限制。

五、对象存储 (Object Storage)

Cloudflare R2
- 免费额度: 大善人CF最大的亮点是 $0 出口（Egress）费用。免费版每月提供 10GB 存储、100 万次 A 类（写入）操作和 1000 万次 B 类（读取）操作。
- 需要绑定支付方式
Backblaze B2
- 免费额度: 免费版提供 10GB 存储空间、每天 1GB 的下载流量（通过 Cloudflare CDN 可免费）以及无限的上传。
- 不绑定支付方式无法设置公开桶（可以在CF worker设置反代）
Tebi
- 免费额度：25G（额外送一个镜像）和每月250G流量，但需要绑卡。
缤纷云 Bitiful
- 免费额度：50G。10G CDN出口流量，但每日限5G。是小厂，且需要实名认证。绑定自己域名需要备案。
- 七牛云 Kodo
  - 免费额度 (标准存储): 为实名认证用户提供每月 10GB 标准存储空间、10GB CDN 回源流出流量、100 万次 GET 请求和 10 万次 PUT/DELETE 请求。
  - 但是！免费额度仅限CDN回源，并且CDN免费流量仅限HTTP。HTTPs是没有免费额度的

从DDNS到零信任：家庭NAS远程访问技术栈

Wed, 22 Oct 2025 00:00:00 GMT

引言：远程访问的三大障碍

在数字化时代，家庭网络附加存储（NAS）已成为个人和家庭的数据中心。然而，将其安全、稳定地暴露给公网，以便随时随地访问，始终面临三大经典挑战：

动态IP（Dynamic IP）： 家庭宽带的公网IP地址经常变化，导致域名无法持续指向。
网络地址转换（NAT）： 设备位于路由器后方的内网，无法被公网直接寻址。
非标准端口（Non-standard Ports）： NAS管理页面（如:5001）等服务使用非标准端口，直接暴露既不美观也不安全。

本文将按照问题分类，系统性地梳理解决这些挑战的主流技术方案。

第一部分：解决“IP在变”的问题 —— DDNS

这是实现远程访问的基石。

DDNS：传统的动态IP解决方案

技术原理： DDNS（Dynamic DNS，动态域名解析）是解决动态IP问题的传统方案。其核心逻辑是：在NAS或路由器上运行一个DDNS客户端，该客户端会定时检测公网IP地址。一旦IP发生变更，客户端会立即通知DDNS服务商，更新特定域名（例如 mynas.provider.com）所指向的IP记录。
评估：如果宽带提供商分配的是固定公网IP，则无需此方案。DDNS的缺点在于需要在客户端设备上进行配置，并依赖第三方DDNS服务的稳定性。

值得注意的是，DDNS本身只解决“找到你家大门”的问题，并不能帮你“进入大门”（即穿透NAT）或“找到正确的房间”（即访问特定端口）。

第二部分：穿透“NAT之墙”并隐藏端口

解决了IP寻址后，我们必须面对NAT环境。这里的方案根据您对网络出口的控制权分为两类。

场景一：公网出口路由器可控

这是最理想的家庭网络环境，例如光猫已设为桥接模式，由自己的高性能路由器负责拨号和NAT。

1. 基础操作：端口转发 (Port Forwarding)

技术原理：这是实现内网服务公网访问的必要前提。您需要在边缘路由器上配置NAT规则，将来自公网的特定端口（例如 TCP/443）的入站流量，转发到内网NAS主机的IP地址和端口（例如 192.168.1.10:443）。

2. 端口美化与整合：两种截然不同的方案

完成了端口转发，您虽然可以通过 https://mynas.provider.com:5001 访问，但这暴露了端口。要实现 https://nas.yourdomain.com 这样的优雅访问，您需要解决端口问题：

1. 方案A ：本地反向代理 (Reverse Proxy)

技术原理：这是专业且健壮的解决方案。您在NAS上（或内网任何主机上）部署Nginx、Caddy或使用系统内置的反向代理服务（如群晖的“应用程序门户”）。此服务监听标准的 80/443 端口，并根据HTTP请求的Host标头（例如 nas.yourdomain.com），将流量代理至正确的内部服务（如 localhost:5001）。
优点：
- SSL终止： 可以在反代层统一处理SSL证书，实现HTTPS加密。
- 高可扩展性： 可用单一 443 端口，通过不同子域名代理内网所有服务（NAS, Plex, Home Assistant等）。
- 安全增强： 可在反代层配置WAF、访问控制等安全策略。
缺点：
- 需要本地自部署反向代理服务

2. 方案B ：DNS服务商的URL转发

此方案尝试在DNS应用层“取巧”，而非在网络层解决问题。

1. 隐性URL转发 (Masked Forwarding)
- 技术原理： DNS服务商在其服务器上配置一个网页，该网页使用HTML <iframe> 框架来嵌入并显示您的目标地址（例如 https://[DDNS域名]:5001）。
- 评估： 此方案在现代Web环境中基本不可用。
  - 安全策略阻断： 绝大多数Web应用（包括NAS后台）都会发送 X-Frame-Options: DENY 或 CSP: frame-ancestors 'none' HTTP标头，以防范“点击劫持”攻击。这将强制浏览器拒绝在 <iframe> 中加载页面，导致一片空白。
  - 功能性缺陷： 破坏浏览器的书签、历史记录和子页面分享。
  - HTTPS兼容性： 极易引发“混合内容”（Mixed Content）安全错误。
2. 显性URL转发 (301/302 Redirect)
- 技术原理： DNS服务商对访问请求返回 301 或 302 HTTP状态码，将浏览器重定向到目标地址 https://[DDNS域名]:5001。
- 评估： 此方案功能有效，但不符合核心需求。浏览器地址栏会立即更新为完整的目标URL，导致端口号完全暴露，未实现“隐藏端口”的目的。

本节结论： 对于可控的公网环境，“DDNS + 端口转发 + 反向代理” 是传统上最专业的技术栈。URL转发方案因其固有的技术缺陷，不应被视为可靠的解决方案。

场景二：公网路由器不可控（CG-NAT）

这是日益普遍的困境，例如处于运营商级NAT（大内网）、校园网、公寓楼共享宽带等环境。没有公网IP，或者无法配置边缘路由器。

1. 方案C：内网穿透 (NAT Traversal)

技术原理：此方案（如Frp, Sakura Frp, nps等）的核心是“反向连接”。您在内网NAS上运行一个客户端，该客户端主动连接到一台您部署在公网VPS上的服务端。公网服务端充当一个中继，将来自公网的访问请求通过这条已建立的连接，转发给内网的客户端。
缺点：
- 需要一台公网VPS，有额外成本。
- 数据流量受限于VPS的带宽和性能。
- 需要自行部署和维护服务端，有一定技术门槛。

2. 方案D：虚拟组网 (SD-WAN / Mesh VPN)

技术原理：此方案（如Tailscale, Zerotier, 蒲公英, Easytier等）旨在创建一个“虚拟局域网”。您在所有设备（NAS、电脑、手机）上安装客户端，它们会共同加入一个私有的虚拟网络。
评估：这是一种点对点的解决方案，非常适合个人或小团队的私有访问。所有设备如同在同一局域网内，可以直接通过分配的虚拟IP（如 100.x.x.x）互相访问，安全性极高。
缺点：它的设计目标不是向公网发布服务。如果您希望任何人都能通过域名访问，而不是仅限已安装客户端的设备访问，此方案不适用。

第三部分：统一方案：Cloudflare Tunnel (零信任网络接入)

面对上述所有方案的复杂性和局限性，Cloudflare Tunnel 提供了一种基于“零信任（Zero Trust）”模型的现代、统一解决方案。它同时解决了动态IP、CG-NAT和端口隐藏三大问题。

技术原理

此方案通过反向连接（Reversed Connection）彻底颠覆了传统的访问模式：

Connector (cloudflared)： 在NAS主机上（通常通过Docker）部署一个轻量级的守护进程 cloudflared。
持久化出站隧道： cloudflared 进程主动向Cloudflare的全球边缘网络发起加密（QUIC）出站连接，建立一条安全隧道。因为连接是出站的，所以无需公网IP，也无需端口转发。
请求代理： 用户的DNS请求将 nas.yourdomain.com 解析到Cloudflare的任播IP。请求到达Cloudflare边缘后，Cloudflare鉴权并通过已建立的隧道将请求安全地代理到您内网的cloudflared进程。
本地转发： cloudflared 进程再将流量转发到本地配置的服务（如 localhost:5001），这步在功能上取代了反向代理。

方案优势（Pros）

极致安全（核心优势）： 无需在路由器上开放任何入站端口。NAS主机和家庭IP地址对公网完全不可见（零攻击面），从根本上杜绝了来自公网的扫描和直接攻击。
无视网络限制： 由于连接是出站发起的，因此完美兼容CG-NAT和动态IP环境，彻底摆脱了对公网IP和DDNS的依赖。
自动化安全： Cloudflare自动处理公网侧的SSL证书签发与续期，并提供基础的WAF和DDoS防护。

权衡与考量（Cons）

服务依赖： 强依赖Cloudflare服务的可用性和性能（尽管其稳定性全球顶尖）。
潜在延迟： 所有流量必须绕行Cloudflare边缘节点，相比传统的直连方案，可能会引入额外的网络延迟。
配置门槛： 初始设置需要在NAS上安装和配置cloudflared守护进程，需要一定的命令行或Docker基础。
服务条款： Cloudflare免费套餐的ToS限制（2.8节）主要针对非HTML内容（如视频流）的大规模分发，但对于个人合理使用（如NAS管理、文件访问）通常是默许的。

结论

传统方案（DDNS+端口转发+反代） 提供了最佳性能和控制权，但它配置复杂、依赖公网IP，且安全风险最高。
内网穿透/虚拟组网 解决了CG-NAT问题，但各有其局限性（成本或访问模型）。
Cloudflare Tunnel 以其零信任的安全模型、对复杂网络的普适性和高度集成的功能，成为了目前个人用户在安全、便利和成本之间取得最佳平衡的现代标准方案。

校园网环境下路由器双栈（IPv4/IPv6）连接问题排查总结

Fri, 17 Oct 2025 00:00:00 GMT

🎯 问题现象

同时插网线 + Wi-Fi：IPv6 可用，IPv4 不可用
仅插网线：IPv4/IPv6 均不可用
仅连 Wi-Fi：IPv4/IPv6 均可用
手动设置以太网 DNS 后，无线 IPv4 恢复（看似“影响无线”，实为修复全局 DNS）

🔍 根本原因分析

1. 网络环境特征

属于校园网/科研网
路由器 WAN 口获取公网 IPv4 + IPv6 前缀
启用 MAC 地址绑定认证，且策略严格

2. 初始错误配置

注册了电脑有线网卡 MAC
路由器 WAN 口克隆该 MAC
导致 同一 MAC 从两个端口出现（路由器 WAN 口 + 电脑有线口）
触发校园网 MAC 冲突保护 → 阻断有线单播通信（ARP/NDP 失败）

3. IPv6 Passthrough 的双刃剑

优点：内网设备直获公网 IPv6
缺点：暴露电脑真实 MAC 给校园网
当 MAC 未正确注册或存在冲突时，IPv4 被策略阻断，IPv6 因策略宽松仍通

🛠️ 排查与解决步骤

✅ 步骤 1：理解 DNS 设置“影响无线”的真相

Windows DNS 解析是系统级全局行为
手动设置以太网 DNS → 加入可靠 DNS 服务器 → 全局 DNS 恢复 → 无线“看似变好”

✅ 步骤 2：确认有线链路层故障

单独插网线时：
- 能获取 IP（DHCP 广播成功）
- 但 ping 192.168.31.1 和 ping fe80::...%9 均失败
证明：L2（数据链路层）单播通信故障，非 IP 配置问题

✅ 步骤 3：识别 MAC 冲突核心问题

路由器克隆电脑 MAC + 电脑直连 → 同一 MAC 多端口出现
校园网交换机触发 MAC flapping 保护 → 静默丢弃流量

✅ 步骤 4：尝试 DHCPv6 模式失败原因

校园网 只允许终端设备（IA_NA）获取 IPv6
拒绝路由器前缀委派请求（IA_PD）
导致 LAN 无公网 IPv6 前缀 → 仅剩 fe80:: 本地地址

✅ 步骤 5：正确解决方案

操作	说明
1. 取消路由器 MAC 克隆	使用路由器原生 WAN MAC
2. 将路由器 WAN MAC 提交注册	让校园网信任路由器本身
3. WAN 设置：IPv4 DHCP + IPv6 Passthrough	保持 IPv6 端到端能力
4. 避免电脑有线/无线同时连接	防止多 MAC 混淆

✅ 最终效果

IPv4：经路由器 NAT，校园网只认路由器 MAC → 正常
IPv6：Passthrough 下电脑获公网地址，因端口已认证 → 正常
双栈全通，稳定可靠

💡 经验总结（最佳实践）

在受控网络（校园/企业）中使用家用路由器：

永远注册路由器自身的 MAC，而非终端设备 MAC

不要启用 MAC 克隆（除非明确需要且无终端直连）

优先使用 IPv6 Passthrough（若需公网 IPv6）

避免同一设备多网卡同时接入（防策略冲突）

若 IPv6 非必需，关闭 IPv6 可极大提升稳定性

🎉 问题本质：不是技术故障，而是网络策略与家用设备行为的冲突。
正确理解认证机制 + 合理配置 MAC 注册，即可完美解决。

CF D1 database 访问

Thu, 16 Oct 2025 00:00:00 GMT

D1 必须通过 Cloudflare Workers 或 Pages Functions 访问。您不能像传统数据库那样使用 IP 地址或端口从外部直接连接。

以下是 Worker 访问 D1 的详细步骤和配置参数：

Cloudflare Worker 访问 D1 的步骤

1. 在 `wrangler.toml` 文件中配置绑定

D1 数据库是通过一种称为“Bindings”的机制连接到 Worker 的。您需要在 Worker 项目的配置文件 wrangler.toml 中声明这个绑定。

配置示例：

name = "my-d1-worker"
main = "src/index.ts"
compatibility_date = "2024-01-01"

# D1 数据库绑定部分
[[ d1_databases ]]
binding = "DB"        # 1. Worker 脚本中引用的变量名
database_name = "my-d1-db" # 2. D1 数据库的实际名称 (在 Cloudflare 控制台创建的)
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 3. D1 数据库的唯一 ID

关键参数解释：

参数	描述	用途
`binding`	您的 Worker 脚本中将用来访问 D1 的环境变量名。	在您的代码中，您会通过 `env.DB` 来调用 D1 API。
`database_name`	D1 数据库在 Cloudflare 控制台中显示的名称。	用于管理和识别。
`database_id`	D1 数据库的唯一标识符。	最关键的参数。您必须在 Cloudflare 控制台的 D1 页面获取此 ID。

2. 在 Worker 脚本中执行查询

一旦绑定配置完成，D1 数据库就会作为环境变量注入到您的 Worker 代码中。

TypeScript/JavaScript 示例：

假设您的 Worker 是一个Module Worker，并且您的 wrangler.toml 中配置的 binding 是 "DB"：

// src/index.ts (或 .js)

export interface Env {
  DB: D1Database; // D1Database 类型是 Cloudflare 提供的
}

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    try {
      // 1. 使用绑定变量 (env.DB) 访问 D1
      const { results } = await env.DB.prepare(
        "SELECT * FROM users WHERE status = ?"
      )
        .bind("active") // 绑定参数以防止 SQL 注入
        .all(); // 执行并获取所有结果

      // 2. 返回查询结果
      return Response.json({ success: true, users: results });
      
    } catch (error) {
      console.error(error);
      return Response.json({ success: false, error: "Database query failed" }, { status: 500 });
    }
  },
};

核心访问方法：

在 Worker 代码内部，您使用 env.DB（或您在 binding 中设置的任何名称）来访问 D1 API：

env.DB.prepare(sql): 准备一个 SQL 语句（推荐使用这种方式）。
.bind(params...): 绑定参数（非常重要，用于安全地处理用户输入）。
.all(): 执行语句并返回所有结果。
.first(): 执行语句并返回第一行结果。
.run(): 执行非查询语句（如 INSERT, UPDATE, DELETE），返回执行信息（如影响的行数）。

总结一下，访问 D1 不是通过网络连接字符串，而是通过在 wrangler.toml 中配置 database_id 和 binding 名称，然后直接在 Worker 代码中使用 env.BINDING_NAME 变量。

Steam探索队列脚本