Posts

视频 https://www.bilibili.com/video/BV1BCi1B7E1q/ Demo https://2x.nz/s 拿域名！ 我们需要一个短域名，来作为我们的短链服务的入口 我们可以前往这些地方购买短域名，建议后缀 .nz .mk .im ，建议2-3位长度的域名 迈向未来 - Spaceship porkbun.com | An oddly satisfying experience. 【趣域网】域名注册网站哪个好_注册域名查询购买_whois信息查询_域名交易网_ - 趣域网 基础思路 Cloudflare Page/Worker的重定向文件提供了基于文件的重定向功能，参考 这篇文章 接下来我们再利用 Cloudflare Worker 连接Github帮我们去更新这个文件，顺便搓一个前端出来让用户能够生成短链即可 防护措施 [!CAUTION] 必须在最终重定向时不直接重定向到业务域名，需要配置中间页，否则你的域名一定会在后期被举报为 滥用/钓鱼/诈骗网站 重定向文件限制静态重定向 2000 ，动态重定向 100 单行字符串不超过 1024 服务架构图

从KV迁移 由于原项目于26/1/3将数据存储从KV迁移到了D1，并且配备了完备的i18n，如果你仍在运营旧版的UptimeFlare，建议升级，下面是迁移教程 首先，将你之前配置的Cloudflare API令牌添加一个新的权限 编辑D1 然后备份根目录的 uptime.config.ts ，直接 把原仓库删了（但是不要删KV，Worker，Page），Fork我的仓库 afoim/UptimeFlare 接下来编辑新的 uptime.config.ts 参阅 UptimeFlare/uptime.config.ts at main · afoim/UptimeFlare 主要就是将自定义callback迁移到官方的WebHook方法 编辑后推送，会自动触发Github Action的自动部署，它会自动将KV内的数据迁移到D1 这迁移到D1何意味 前言 本来这个教程应该是永远都不会出的，因为在此之前，我曾经给大家介绍了一个无需自托管的监控服务：UptimeRobot 但是，就在最近我再次查看控制台，发现之前创建的监控全部都没了，咱也不知道是被官方删了还是号被黑客大手子肘击了，总之，我现在不得不要重建监控服务了 原理 首先，UptimeFlare是一个基于Cloudflare Worker+D1的监控服务 它的原理非常简单，一共由三个部分组成 前端：放在Cloudflare Page，用于给用户展示zhandianzhuangt 后端：放在Cloudflare Worker，通过 Worker 自带的 Cron 每分钟 检查站点状态，并将状态持久化进 D1 正式开始 首先我们需要 Fork 项目，建议Fork我的项目（由于原项目不知道为什么不给在某些地方注入环境变量，所以建议Fork我的） afoim/UptimeFlare 首先，我们先尝试将其部署到Cloudflare 创建一个Cloudflare API Token 编辑Workers 和 D1 接下来将该Token绑定到你的Github仓库 最后，来到 Action 页面，手动创建一个 Deploy to Cloudflare 的工作流 等待工作流运行结束，你应该可以在Cloudflare仪表板看见一个新的Page，新的Worker和新的D1 点开 Page，注意不要点错了 绑定你的域名，尝试访问 如果你能看到一个初始的监控页面，则正常 接下来，我们开始自定义该监控 编辑根目录的 uptime.config.ts 如果服务故障如何做通知？ UptimeFlare非常自由，你可以在 callbacks 中编写故障时要做的任何事情，这里以发送 POST 请求让 Resend 发送邮件给你举例 ...

探索架构 我们先不讲一个抽象的概念，我们首先来做一个小项目 一个随机图API，每次请求都返回不同的图片 你会怎么做？ 有非常多的解决方案，就拿最简单的一说，我们可以先搞来一个服务器，然后往里面塞图片，最后写一个脚本创建一个Web服务器，接收客户端请求，每一个请求都从图片库里抽一张图返回 能实现吗？ 当然可以！这是你的流程图！ flowchart TD A[客户端请求GET /random] B[Web 服务器接收请求] C[从图片目录读取图片列表] D[随机选择一张图片] E[读取图片文件内容] F[构造 HTTP 响应Content-Type: image/*] G[返回图片给客户端] A --> B B --> C C --> D D --> E E --> F F --> G 但也会带来一些问题，比如，图片存在本地，给客户端响应图片的时候走的是你机子的流量，那么你就需要一个 高带宽 的服务器，这无疑是一个 高昂 的成本 那可能你会有新的方案： 前后端分离 （逻辑与资产分离），只将返回这个图片的逻辑存放在服务器上，而图片存到其他地方，如对象存储（Cloudflare R2）、IPFS等等 flowchart TD A[客户端请求GET /random] B[随机图逻辑服务器] C[读取图片索引 / 元数据] D[随机选择一张图片] E[生成图片访问地址R2 / IPFS / 对象存储] F[返回 302 重定向Location: 图片URL] G[客户端请求图片资源] H[对象存储 / IPFS / CDN] I[返回图片数据给客户端] A --> B B --> C C --> D D --> E E --> F F --> G G --> H H --> I 那么问题又来了，假如说你的项目太多人用了，那你的服务器性能可能不够，在后期，你仍然需要一个 高昂 的 维护成本 ...

正式开始 首先，我们想要迁移，首先肯定是要拿到原来的Umami Cloud存放的数据 在 Umami Cloud Data | Settings 中，我们可以选择，导出数据（Export） 当数据准备好后（几分钟左右），你的邮箱会收到一封Umami Cloud发来的邮件 下载下来的文件是一个以UUID命名的ZIP压缩包，将其解压可以得到3个CSV文件 其中，只有 website_event.csv 有用，其他两个文件仅有表头，无数据 这样，我们就成功拿到了旧Umami数据 接下来，我们需要在本地部署Umami PostgreSQL版本的 最新版 （目前版本为 3.x）（部署教程略） 然后我们还需要安装一个CSV编辑软件： SmoothCSV - The ultimate CSV editor for macOS & Windows 在本地Umami中新建一个网站，Umami会随机为你生成一个UUID 接下来我们需要在你的终端安装一个图形化管理PostgreSQL的软件： pgAdmin - PostgreSQL Tools 然后连上数据库，你将可以看到这些表 接下来我们查看 website 这张表，将 website_event.csv 打开，查看旧的 website_id 将新的ID改为旧的，这样才能数据匹配 接下来，我们正式开始数据导入，由于导入后的数据有两个 session_id 字段，而在Umami自我管理的过程中这个 session_id 字段是 唯一约束的 ，我们需要先解除这个限制，在正式上线前还要再加回这个限制（后面会说） 让我们删除主键约束和索引 ALTER TABLE session DROP CONSTRAINT session_pkey; DROP INDEX session_session_id_key; 接下来，我们需要将数据配对，我们先查看 website_event.csv 这张表。这里应该只有表头，没有数据（我有是因为我已经导入完成了，教程是后写的） 注意顺序 如： event_id website_id session_id … 编辑CSV文件，你需要将顺序配对，并且删除表中没有的列，如： browser os … ...

这是What 这是橘猫，会哈气（见封面 你可以前往 AnuNeko 逗猫 逆！ okok，注意到登陆后的请求头中有 x-token 字段 手搓个请求发发，data 携带内容 curl --location 'https://anuneko.com/api/v1/msg/会话id/stream' \ --header 'x-token: 账号Token' \ --header 'Content-Type: text/plain' \ --header 'Cookie: 自动拿取' \ --data '{"contents":["test"]}' 通了 然后还有一种情况，在遇到Pick的时候，我们要发送要选择的回复编号 发个如图请求帮橘猫选择 curl --location 'https://anuneko.com/api/v1/msg/select-choice' \ --header 'x-token: 你的Token' \ --header 'Content-Type: text/plain' \ --header 'Cookie: 自动拿取' \ --data '{"msg_id":"会话id","choice_idx":0或1}' 还有还有，这有个橘猫和黑猫，如何切换一个会话的猫？ curl --location 'https://anuneko.com/api/v1/user/select_model' \ --header 'x-token: 你的Token' \ --header 'Content-Type: text/plain' \ --header 'Cookie: 自动拿取' \ --data '{"chat_id":"会话id","model":"Exotic Shorthair或Orange Cat"}' 随便写了个适用于NoneBot2的插件，玩吧 AnuNeko_NoneBot2_Plugins/anuneko.py at main · afoim/AnuNeko_NoneBot2_Plugins

何为Serverless 就像简介所说，传统来说我们搭建Web服务一般会选择买一个VPS，然后在其上安装管理面板，再安装所需软件，如Nginx，AList，最后运行，开放端口，再设置DNS解析，这样，一个网站就成功上线了 而Serverless就简单多了，毕竟 Server 被 Less 掉了 这又是什么意思呢？在Serverless服务里，你不再需要管理传统的VPS，而是直接将业务代码上传到目标平台，再由平台的CI/CD自动部署你的服务 举个不恰当的例子就比如你正在观看的这个 博客 ，首先我将源码上传到 边缘安全加速平台 EO Pages_腾讯云 ，再经由平台构建出最终的HTML页面，然后再在平台上绑定域名，直接访问就可以了 不难看出，在上一个例子中，我并没有去从零开始搭建这个服务，而是仅做了两件事：1. 源码上传 2. 绑定域名，而其他事情全部交给平台的自动化，这不仅极大减少了运维成本，并且在做版本控制的时候也更加容易 Serverless的利与弊 在Serverless中，你不再需要管理基础设施，只需要确保你的代码能跑，然后直接上传到平台，平台会帮你做好后续工作 并且，这往往是 免费 的，或者说，大部分Serverless平台都有 免费层 。因为在平台看来，你只是租用了你所需要的东西，相比于哪些大客户，你的开销可以说是忽略不计 并且在Serverless中，你永远只是用户，但是如果你买的是VPS，一般来说你是可以完全控制这台VPS的，如设置防火墙，或是重装系统，而这种代价是高昂的，这也是为什么你能看到许许多多免费的Serverless服务，但是几乎看不到免费的VPS提供商 但这也有一些弊端，Serverless往往有严格的用量限制，在传统的VPS中，往往IDC会限制你的 最大带宽、公网IP 和 总流量 ，但是在Serverless中，往往只会限制你的 总流量 ，但可能还会有一些限制，如：CPU最长执行时间 、总请求数 、函数总请求数 、函数最长执行时间 等等等等 因为当你在用Serverless的时候，你的服务直接跑在其平台的CDN上的，你将直接享有所属平台的CDN IP段以及带宽，这也让平台的管理更加方便，不需要大量购入物理机开虚拟机做VPS，只需要做一个小集群并做好用户分配即可 Serverless也比Server更容易做版本控制和Debug，由于Serverless和Git是天生一体的。在用户看来，只需要先将代码托管到Github，再将代码库连接到Serverless平台，此后，你的服务每一次更新就只需要更新源码了，平台会自动帮你构建。当你想要回滚版本的时候，直接将部署回退为之前的提交即可，而Debug无需再连到服务器上做，只需要有一台电脑，将代码拉下来，本地Dev Debug后，再将修复后的代码提交，平台就能自动部署了 好用的Serverless平台 边缘全栈开发平台 - EdgeOne Pages :::caution 请不要在其上部署日流量超 10M 的服务，很有可能会被停用账号 ::: 支持原生JS和Node Function，如果你的项目是基于Node打造的，仅需修改一下函数出入口即可无缝迁移。并且目前的 Pages Function 是 不计请求也不计费 的，非常适合部署一些仅自己用的服务 不过其自带的构建服务性能较低，上线速度可能稍慢 示例服务： 自建一个匿名文件上传终结点 - AcoFork Blog Vercel Functions 支持非常多的语言，如 Node.js、Python、Go、Wasm 等等。构建服务非常强劲！默认分配 4C8G 帮你构建！ 用量限制非常宽松，并且可以超过限制的 2倍 以上仍保持正常访问 示例服务： 来！让我们用Vercel来分享你的OneDrive！ - AcoFork Blog ...

前言 你可能会觉得：远程控制电脑而已，直接装个 UU 远程、向日葵之类的软件不就好了，为什么还要专门写一篇文章？ 但问题在于：如果你的电脑是 32 位系统，而不是 64 位；或者你所在的网络 NAT 类型不够开放，甚至没有 IPv6，又该怎样尽可能优雅、高效、流畅地远程访问家里的电脑呢？ 正式开始 这篇文章分两部分来讲：一部分针对 64 位电脑，配置相对简单；另一部分针对 32 位电脑，操作会稍微复杂一些。 64位 首先，打开家里路由器的 UPnP 功能，然后直接下载 网易UU远程官网_真4K、真免费、真好用。登录账号后即可直接连接，大部分情况下都能走 P2P（点对点连接，也就是控制端和被控端直接建立连接）。 32位 由于 UU 远程仅支持 64 位电脑，这里就得换一种思路了。 我采用的方法会稍微“极客”一些：把家里设备的 RDP 端口映射到公网，也就是借助 STUN。不过，这种方案要求家庭网络的 NAT 类型为 1（Full Cone）。 首先，把家中路由器的 DMZ 主机 设置为家里电脑的 IP 地址。 启用 DMZ 后，所有打到路由器端口上的流量（除路由器自身占用的端口外）都会被转发到这台 DMZ 主机。 换句话说，访问路由器的 3389 端口，本质上就是在访问这台电脑的 3389 端口。 完成这一步后，就可以借助 STUN 协议，把路由器的 3389 端口映射到 ISP 分配给你的公网地址上。 更直白一点说，完成 STUN 后，只要访问 公网 IP:随机端口，就能连到路由器的 3389 端口；而由于前面已经配置了 DMZ，这个请求最终又会被转发到电脑的 3389 端口。 ...

前言 为什么要回到Win10 有太多理由了 Win11几乎只升级了UI，并且新的UI优化不完全，导致很多地方有粘滞感，参见： 我们发现了Win11操作总是不跟手的深层原因！_哔哩哔哩_bilibili Win10和Win11都是NT 10.x的内核，能跑在Win11上的程序必然能在Win10上跑。而微软大部分的程序文档中规定的最低版本号几乎都为 Windows 10 1607 and later ，也就是 支持 Windows 10 2016年的版本，以及之后的版本 ，而我们一般使用的都比这新的多，如 21h2 22h2 ，根本不用担心兼容性问题 这种非正常手段的“升级”有哪些影响 几乎没有影响，虽然我们需要做点善后工作，但得益于Win10和11本质上是一个东西，并不会造成什么不可逆的损害 “升级”后，我会丢失什么？ Win11有但Win10没有的东西会消失，两者都有的会保留。专为Win11打造的Appx，“升级”后会不可用或直接消失 是保留数据的“升级”吗 是的。理论上来说仅会替换Windows版本，并不会清除你的所有数据，如应用，文档，个人信息 为什么微软不开放官方通道降级？ 其实是有的，当你先安装Win10，再通过Windows更新升级为Win11后，你有30天的后悔期，期间你可以在设置中选择回到Windows 10。但30天并不是一个特殊的日子，只是微软为了减少麻烦设置的一个保守日期 正式开始 :::caution 数据无价，谨慎操作 ::: :::warning 确保你有PE U盘，如果你听不懂我在说什么，请不要继续操作！ ::: 首先确保你正在运行Win11的 正式版 ，如果你加入了 Windows Insider Preivew ，请想办法回到 正式版 接下来我们先去下载Win10的ISO，前往 https://www.microsoft.com/zh-cn/software-download/windows10 ，如果你发现你没有可以下载ISO文件的地方，如图 点击F12，打开Devtools，切换为设备仿真 按F5，刷新页面，此时网页就会认为你是手机，就会让你下载ISO了 选择版本 Windows 10 （多版本ISO） 选择 简体中文 下载 64位版本的ISO 得到ISO文件 确保你安装了 支持解压缩ISO 的软件，如 Bandizip 官方网站 - 免费压缩软件下载 (Windows) ，解压ISO文件 打开 已解压的ISO 文件夹，重命名 setup.exe 为 setup1.exe ...

正式开始 正如标题所说，我的博客是在 saicaca/fuwari: ✨A static blog template built with Astro. 的基础上深度改造而来的。 和 Fuwari 原版一样，它本质上仍然是一个 静态博客：文章以 Markdown 文件形式维护，构建后输出为 HTML。 但原项目在设计之初并没有重点考虑 动态功能，例如我现在用到的 访问量显示，因此后续接入这类能力时就容易出现一些问题。 关于访问量显示的整体思路，我已经在 这篇文章 中讲过。简单来说，它分为两步：1. 先获取全局分享 Token；2. 再使用这个 Token 请求实际访问量数据。 当时出现了一个比较奇怪的问题：第一步会发生多次重复请求。分析之后我发现，博客里有三个位置都用了同一套逻辑，而且彼此独立。也就是说，用户一打开页面，博客既会获取全站访问量，也会同时请求首屏几篇文章的访问量。 但这个全局分享 Token 在很长一段时间内其实都不会变化，这就导致出现了不少冗余请求。为了解决这个问题，我当时写了一个中间层：首次请求后把 Token 缓存在用户浏览器里，后续直接复用，不再重复请求。 不过后来还是有读者发现，某些页面依旧会多次请求 Umami，如图所示： 于是他提交了一个 issue：Bug: 站内转跳时由于swup处理不当导致的多umami实例 · Issue #79 · afoim/fuwari。问题的核心是 Swup 不应该接管这类脚本资源，把相关 JS 排除后，问题确实得到了解决。 按 issue 中的方法调整后，我们随便打开一个页面，再来分析一次请求情况： 我们只看Umami请求： https://cloud.umami.is/script.js ：Umami官方的全局JS，注入在所有页面中，用于后续将访客行为告知给Umami http://localhost:4321/js/umami-share.js ：之前写的中间件，用于避免多次请求Umami拿全局Token https://umami.2x.nz/analytics/us/api/websites/5d710dbd-3a2e-43e3-a553-97b415090c63/stats?startAt=0&endAt=1763429011353&unit=hour&timezone=Asia%2FShanghai&compare=false ：获取全站统计信息。为什么在文章页也会获取全站统计？因为全站统计被安放在用户配置块，而用户配置块全局可见 https://umami.2x.nz/analytics/us/api/websites/5d710dbd-3a2e-43e3-a553-97b415090c63/stats?startAt=0&endAt=1763429243350&unit=hour&timezone=Asia%2FShanghai&path=eq.%2Fposts%2Fswup-js%2F&compare=false ：获取本页统计信息 两个预检请求：由于存在 CORS，请求源和被请求源不一致，因此浏览器会先发起预检请求，再决定是否继续发送正式请求。这是浏览器的安全机制，用来确认目标站点是否明确允许这次跨域访问。 https://api-gateway.umami.dev/api/send ：Umami的官方JS，用于将本次访问的行为汇报给Umami 到这里，问题就算彻底解决了：没有多余实例，也没有冗余请求，整体请求链路也干净了很多。

正式开始 你可以根据前文免费拿E3，得到至高免费5T的OneDrive存储空间，也可以用你个人永久免费的5G空间，都可以！ 前往 高级 - OneDrive Vercel Index 拿到 clientid 和 secret 前往该页面，点击快速部署 onedrive-index/README.zh-CN.md at main · iRedScarf/onedrive-index 填写必须的5个环境变量 其中，USER_PRINCIPAL_NAME为类似 huding@Smartree233.onmicrosoft.com 的电子邮箱，也就是你登陆OneDrive的用户名 Vercel部署完毕后，会报错连不上Redis，因为我们还没创建和绑定，现在我们开始做 前往 https://vercel.com/integrations/upstash 点击 Install 选择你要绑定的Vercel项目，并且设置Redis实例名称 来到Vercel的环境变量页面，这就是绑定成功了 随便打开一个部署，点击 Redeploy 重新部署，就能成功连接数据库了 接下来访问你的项目域名，进入OneDrive-Index的引导，需要打开微软的一个链接授权 授权后会重定向到一个localhost的域名，复制该URI，粘贴回OneDrive-Index即可（仅需一次） 成功部署！ 同项目更改OneDrive账号 首先在Vercel上更改这三个环境变量 然后打开 Upstash 找到对应的Redis，删除里面存储的所有Token