简介

来自 iOS 27 和 iPadOS 27 的内置壁纸，其中 iOS 27 内含 5 种颜色的壁纸，iPadOS 27 内含 2 种颜色的壁纸 (但 iPadOS 提供横向和纵向版)

预览图

++(拼接压缩图 不要直接下载这里的 下载地址在最下面)++

下载

OneDrive (免登录 慢)

移动云盘 (需登录 不限速)

字体介绍

2024年 10 月 23 日消息，OPPO 与汉仪字库联合开发的 OPPO Sans 4.0 字体于 10 月 18 日正式发布，搭载于 ColorOS 15 系统中，优化了整体笔划曲线。
目前 OPPO Sans 4.0 字体已在 OPPO 开放平台提供下载，继续免费授权给全社会使用（含商用）。

OPPO Sans 4.0 使用条款

OPPO Sans 允许个人或企业免费使用，含商业用途，版权归 OPPO 广东移动通信有限公司所有。使用过程中，您应遵守以下条款，违者将会被追究法律责任：
1、不对字体进行改编或二次开发；
2、不对外售卖字体；
3、不向他方提供其他下载渠道；
4、不用于违法用途。

字体展示

字体下载

OneDrive(免登录 慢)

移动云盘(需登录 不限速)

网站介绍

网上刷到好看的地标，不知道是哪个地方？现在可以用这款利用 AI 识别照片拍摄地点的免费在线工具 GeoSpy 上传图片，让 AI 分析建筑风格、地标、环境特征、标志和文化指标以识别位置。支持最大 10MB 的 JPG、PNG 和 WEBP 格式。

网站展示

网站地址

https://www.geospy.info/zh

总述

2026 年 8 月 22 日，在南京大学 e-Science 中心主办的第四届开源软件论坛期间，教育网联合镜像站 MirrorZ 正式发布上线，该项目最初由清华大学开源软件镜像站在 2020 年发起，获得中国教育和科研计算机网 (CERNET) 网络中心在计算资源、域名以及网络基础设施方面的支持。

用处

长期以来国内高校和科研机构普遍搭建自己的开源软件镜像站用于加速 Linux 发行版、开发工具、编程语言生态以及各类开源项目的下载。不过各个镜像站都是独立运行的，因此在用户实际使用过程中可能会遇到多种问题：不同站点同步的软件仓库数量不同、访问速度受地域和网络环境影响、用户通常需要手动寻找合适的镜像地址。

MirrorZ 联合镜像站本身并不存储所有开源软件镜像，而是作为调度入口将多个高校和科研机构已有的镜像资源进行整合，用户只需要访问 MirrorZ 联合镜像站地址即可获得最佳的镜像节点。

使用方法

1.直接访问联合镜像站地址

https://mirrors.cernet.edu.cn/

访问该地址时联合镜像站将根据用户所在地域和网络环境选择状态最佳的镜像站，实际为用户提供下载的有可能是清华大学镜像站、上海交大镜像站或其他镜像站。需要说明的是，联合镜像站也采用反爬措施，所以有可能会触发短暂的自动验证。

2.优先选择特定镜像站

https://ustc.mirrors.cernet.edu.cn/

部分用户习惯于使用特定的高校镜像站，因此用户也可以通过增加前缀的方式选择特定镜像站，例如在地址前缀增加 ustc 代表选择中国科学技术大学镜像站，实际访问时也会优先通过指定的镜像站获取资源。但请注意：如果镜像站状态异常或存在其他问题，联合镜像站也会自动选择其他可用的镜像站。

3.排除特定镜像站

https://avoidnju.mirrors.cernet.edu.cn/

联合镜像站支持使用参数 avoid + 镜像站名称排除特定镜像站，例如 avoidnju 代表不使用南京大学镜像站，如果某个镜像站临时出现异常且联合镜像站未发现异常时，用户就可以通过排除参数来使用其他镜像站继续获取资源。

查看各个镜像站状态

用户可以在 教育网联合镜像站 - 站点 查看每个镜像站的近期成功同步数量、异常同步数量、未知同步数量，以及镜像站所属高校、名称、主页、联系方式等。

其他

项目主页：https://github.com/mirrorz-org

引言

你是不是也经常遇到下面的情况

当 Chrome 出现这个页面的时候 过去大多数人都以为这个网站访问不了了，只能等他修好(包括我自己)
但有时候有些网站当时又特别急着要用(Edge还好可以高级选项直接进入)

正文

但是今天，我偶然看到一条帖子下面的评论。
说遇到这种情况有一种办法可以直接解决。

方法

方法就是在这个时候 用键盘盲输一个 thisisunsafe
这样 Chrome 就可以临时加载这个网页，忽略 Https 问题。

解释

基于安全考虑目前很多网站都已经部署 HTTPS 加密连接，但有时候网站服务器出现问题时可能会退回到 HTTP 明文连接。而谷歌浏览器采用的 HSTS 严格传输安全机制，会强制浏览器和服务器之间必须通过 HTTPS 加密连接。

遇到 HSTS 导致的无法加载时，正常情况下对访问者来说应该直接关闭页面，因为这种情况要么是网站服务器出现问题，要么是用户到该网站之间的连接遭到劫持，因此继续尝试访问存在潜在的安全隐患。

不过谷歌也在 Chrome 中预留小彩蛋，只需要通过键盘盲打 thisisunsafe 即可绕过 HSTS 继续加载，输入 thisisunsafe 时页面不会有任何提示，当完成输入时 Chrome 就会自动重新加载这个页面。

正常情况这个功能应该是给程序员临时测试网站用的，但是有些时候普通用户也可以使用，相当于用户已经知道这个连接不安全但签了个免责协议，所以谷歌会重新允许用户进行加载。

结语

理论上这也算不上是一个彩蛋,算是跟开发者之间的一个小秘密，主要是为了方便开发人员测试。
此外，实测 Edge 也可以，但是没必要(因为 Edge 可以直接在高级选项中选择继续服务 bushi)。

前言

英伟达日前正式宣布以 129.303 亿美元收购 AI 模型社区抱抱脸 (Hugging Face)，目前相关协议已经完成签署，英伟达预计该交易最终将在明年上半年完成，前提是没有监管机构阻止这场收购。

为什么是 129.303

英伟达提交的监管文件显示，英伟达将支付 119 亿美元收购抱抱脸当前股东持有的股份 (英伟达本身就是该平台的投资者)，剩余 10 亿美元将作为股权激励用来留住加盟英伟达的抱抱脸现有员工。

通常这类收购都是整数金额，那为什么英伟达开出的价格是 129.303 亿美元呢？收购金额这里其实暗藏小彩蛋：

129303 是 Unicode 码位 U+1F917 的十进制表示，若将其转换为十六进制则是 1F917，对应的就是 🤗 这个表情。129303 写成十六进制颜色 #129303 后会得到绿色，这种颜色与英伟达传统使用的绿色品牌色也非常接近。

英伟达承诺收购抱抱脸后不会将其变成英伟达专属平台，开发者仍然可以自行选择模型、框架、云服务、推理服务商和计算平台。抱抱脸也不会被要求必须采用英伟达 GPU，英伟达称平台将继续支持其他公司的芯片。

先看看 D-blog 实现后的效果

Ping 延迟

国内外分流

国内 EdgeOne Pages (现在叫 Makers) 国外 Cloudfalre Pages

教程

第一步:确认DNS商支持DNS分流解析

Cloudflare 不支持DNS解析分流
建议使用 DNSPOD
如果想继续把主域名留在 Cloudflare 或其他服务器
可以选择把子域名 如 blog.pldduck.com 托管到 DNSPOD
只需要在 DNSPOD 里添加并在 CLoudflare 里为子域名添加NS记录即可
如下图

第二步:部署 Pages

Cloudflare Pages 部署

点击 新建应用程序

点击 部署Pages?开始使用

部署方式自行选择 如果是直接上传源码ZIP文件就选下面的

在项目列表选择自定义域并绑定(获取CNAME地址 等下解析用)

EdgeOne Makers 部署

点击创建项目 同样的 需要绑定Git仓库就选择 导入Git仓库 直接上传源码ZIP就选择直接上传
可用区-自行选择 如果没有备案：选择 全球可用区（不含中国大陆） 如果已备案：选择 全球可用区（含中国大陆）

同样来到项目页 点击 域名管理 添加和刚刚在 Cloudflare Pages 添加的一样的域名 并同样记录下CNAME地址

第三步:分流解析

打开DNSPOD

如图添加两条记录
一条 默认 指向 Cloudflare Pages 的CNAME
另一条选择 境内 指向 EdgeOne Makers 的CNAME

第四步:完善SSL

由于分流原因 EdgeOne Makers 可能无法自动申请SSL
需要使用第三方网页并手动上传部署
我是用的是 Certple

获得SSL证书后来到 腾讯云SSL管理 上传证书

最后回到 EdgeOne Makers 的域名管理

点击HTTPS下的 配置 按钮

点击 配置

选择SSL托管证书 并勾选刚刚上传的证书 然后点击保存

最后等待部署完成就好了

第五步:验证分流

最后测试分流是否成功
如果成功 国外节点IP位置应该显示 Cloudflare anycast
国内节点IP位置应在国内(如果在部署时选择的是 全球可用区不含中国大陆 则为其他国家IP)

总结

所有内容到此就结束了
通过这样的DNS分流 可以有效加快国内外的访问速度
同时减轻单个平台的压力 避免风控
此教程建议已备案域名使用 备案域名使用效果更佳

通过Cloudflare规则实现纯静态随机图API

参考项目 D-RandomPIC

基于 Cloudflare Pages 404 规则与 GitHub Actions 自动构建的随机图 API。

访问 https://randompic.pldduck.com/ecy-v 之类的地址即可获得一张随机图片。

演示

介绍

工作原理

不依赖任何后端服务，完全由静态文件与 Cloudflare 规则实现随机取图：

1. gen_pic.py 扫描 pic/ 下的分类子文件夹，将每个分类的图片复制到 dist/<分类>/ 目录下，并按十六进制编号重命名，生成 000.jpg 到 fff.jpg 共 4096 个文件（对应规则中 3 位十六进制 hash 的全部取值，覆盖所有可能路径，保证不会 404）。
2. 构建产物 dist/ 部署到 Cloudflare Pages。
3. 在 Cloudflare 为该 Pages 项目配置 404 规则（见 rule.txt）：

 concat(http.request.uri.path, "/", substring(uuidv4(cf.random_seed), 0, 3), ".jpg")

当用户访问 /ecy-v 时，如果该路径不存在（返回 404），规则会使用随机种子生成 3 位十六进制字符串并重写到 /ecy-v/xxx.jpg，从而随机返回该分类下的一张图片。

D-RandomPIC 目录结构

D-RandomPIC/
├── gen_pic.py            # 构建脚本：生成 dist/ 下的随机图片文件
├── index.html            # 演示页面（列出各分类 API 地址）
├── 404.html              # 404 响应体
├── rule.txt              # Cloudflare 404 规则表达式
├── pic/                  # 源图片目录（按分类存放）
│   ├── ecy-h/            # 随机二次元图（横屏/电脑）
│   ├── ecy-v/            # 随机二次元图（竖屏/手机）
│   ├── fj/               # 其他分类示例
│   └── ys/               # 其他分类示例
└── dist/                 # 构建产物（由 gen_pic.py 生成，不提交到仓库）

新增图片分类时，只需在 pic/ 下新建一个子文件夹并放入图片，推送到仓库即可，构建脚本与 Cloudflare 规则无需改动。

本地构建测试

需要 Python 3（仅使用标准库，无需安装任何依赖）。

python gen_pic.py

构建完成后检查 dist/ 目录，每个分类下应生成 4096 个文件（000.jpg 到 fff.jpg）。

搭建部署

部署方法

1.Fork D-RandomPIC

将 D-RandomPIC Fork一份到你的Github

2.创建 Pages 项目

在 Cloudflare Dashboard 中创建 Pages 项目
选择直传项目 Direct Upload

3.配置 GitHub Actions Secrets

CLOUDFLARE_API_TOKEN 获取方法

点击右上角 支持 右边的 账户图标

点击配置文件

选择API令牌 点击右上角创建令牌
选择创建自定令牌

按照上图配置权限
最后点击获取令牌就可以得到令牌了

CLOUDFLARE_ACCOUNT_ID 获取方法

红色码住的这一段就是 也可以随便找个域名的页面进去的右侧下滑就有

4.配置 404 规则

配置Rules 为 404 状态码配置重写规则 表达式见 rule.txt

找到随机图要使用的域名 点击进入
在左侧菜单栏里找到 规则>概述
点击创建规则

选择URL重写规则

选择自定义表达式
按照上图配置 重写到 后面的内容如下

concat(http.request.uri.path, "/", substring(uuidv4(cf.random_seed), 0, 3), ".jpg")

最后保存即可

5.触发Action

进入action页面后 找到左侧的Build and Deploy to Cloudflare Pages 点击右侧的Run workflow
再次点击绿色的Run workflow
最后等待部署成功即可

API 使用

• GET /ecy-v：随机二次元图（竖屏/手机）
• GET /ecy-h：随机二次元图（横屏/电脑）
• 新增分类 xxx 后，GET /xxx 即生效

示例：

curl -L https://randompic.pldduck.com/ecy-v

在 HTML 中直接使用：

<img src="https://randompic.pldduck.com/ecy-v" alt="随机图片">

D-blog 接入不蒜子统计

不蒜子是一款轻量极简的网站访问量统计工具
通过引入脚本和标签代码，即可实现网站访问量(PV)、访客数(UV)和页面阅读量的访问数据实时统计
由于不需要后端 简直是静态博客的福音

不蒜子统计首页截图

D-blog 的不蒜子统计

你可以通过一下两个方式查看 D-blog 的不蒜子统计

• D-blog 统计页
• 不蒜子统计页

使用 giscus 和 akismet 实现静态博客评论及垃圾审查功能

静态博客的优点是部署简单、访问速度快，也不需要维护数据库和后端服务。不过，评论功能往往会把问题带回来：评论数据放在哪里？访客如何登录？垃圾评论如何处理？如果为这些问题单独搭建一套服务，系统复杂度很快就会超过博客本身。

giscus 提供了一个轻量的解决方案：它使用 GitHub Discussions 保存评论，博客只需要加载一段客户端脚本。再配合 Akismet 和 GitHub Actions，就可以在评论创建后自动进行垃圾检测，并删除被判定为垃圾的评论。

这套方案适合源码托管在 GitHub、文章以 Markdown 管理的个人静态博客。评论的存储、登录和通知由 GitHub 负责，垃圾审核交给 Action 执行，博客本身不需要增加评论后端。

工作原理

评论系统由三个部分组成：

1. giscus 把网页评论映射到 GitHub Discussions。
2. GitHub Discussion 负责保存评论，并提供 GitHub 登录能力。
3. discussion_comment 事件触发 GitHub Actions，Action 将评论内容提交给 Akismet；如果返回垃圾评论结果，则通过 GraphQL 删除评论。

flowchart LR
  A[文章页面] --> B[giscus 客户端脚本]
  B --> C[GitHub Discussion]
  C --> D[discussion_comment 事件]
  D --> E[GitHub Actions]
  E --> F[Akismet 检测]
  F -->|正常| G[保留评论]
  F -->|垃圾| H[GraphQL 删除评论]

配置 giscus

1. 准备 GitHub 仓库

首先准备一个公开的 GitHub 仓库作为评论仓库。可以直接使用博客源码仓库，也可以创建一个单独的空仓库。评论仓库需要开启 GitHub Discussions 功能：

1. 打开仓库的 Settings。
2. 在 Features 中启用 Discussions。
3. 创建一个用于评论的分类，例如 Announcements。

2. 在 giscus 中生成配置

打开 giscus 中文配置页面，填写仓库名称并完成检查。随后选择评论映射方式。

最推荐使用 pathname 映射。假设文章地址是 /post/hello-world，只要这个路径保持不变，评论就会一直关联到同一个 Discussion。

常见映射方式的区别如下：

建议同时开启严格匹配。严格匹配会为页面和 Discussion 建立额外的哈希标识，可以降低不同页面评论串台的概率。

如果需要把页面重新映射到一个已经存在的 Discussion，可以根据 giscus 生成的页面标识计算 SHA-1，然后把对应标识写入目标 Discussion 的正文。一般情况下不需要手动处理，首次加载时让 giscus 自动创建即可。

3. 选择分类和功能

评论分类可以选择 Announcements（公告）等适合公开讨论的分类。表情反应、输入框位置、语言和主题根据博客需要选择。

生成的脚本大致如下：

<script src="https://giscus.app/client.js"
        data-repo="OWNER/REPOSITORY"
        data-repo-id="REPOSITORY_ID"
        data-category="Announcements"
        data-category-id="CATEGORY_ID"
        data-mapping="pathname"
        data-strict="1"
        data-reactions-enabled="1"
        data-emit-metadata="0"
        data-input-position="top"
        data-theme="preferred_color_scheme"
        data-lang="zh-CN"
        data-loading="lazy"
        crossorigin="anonymous"
        async>
</script>

把脚本放在文章正文下方的评论区容器中即可。React、Vue 或其他前端框架项目应在组件挂载后创建脚本，避免 SSR 阶段访问 document。

对于 SPA，还要注意两个问题：切换文章时需要重新加载脚本，让 giscus 读取新的 pathname；站点切换深浅主题时，需要向 giscus iframe 发送主题更新消息，不能只在首次加载时设置主题。

配置 Akismet

1. 获取 API Key

打开 Akismet 官网 注册账号，选择适合个人博客的订阅方案。个人方案可以将价格调整为 $0，完成注册后在账户页面获取 Akismet API Key。

Akismet 的检测接口会接收评论作者、评论内容、来源页面等信息，并返回 true 或 false。true 表示 Akismet 认为评论是垃圾内容，false 表示评论可以保留。

2. 创建 GitHub Token

Action 需要删除 Discussion 评论，因此默认的 GITHUB_TOKEN 可能不一定满足仓库权限要求。可以在 GitHub Token 设置页面 创建一个专用令牌，并按照实际仓库设置授予必要的 Discussions 写权限。

令牌应保存为仓库 Secret，例如：

• AKISMET_API_KEY：Akismet API Key。
• GH_TOKEN：用于调用 GitHub GraphQL API 的令牌。

不要把这两个值直接写进 workflow 文件，也不要在日志中输出完整令牌。

创建垃圾评论检测 Action

在启用了 giscus 的仓库中创建 .github/workflows/akismet-discussion-comment-check.yml：

name: Akismet Discussion Comment Checker

on:
  discussion_comment:
    types: [created]

permissions:
  contents: read
  discussions: write

jobs:
  check-akismet:
    runs-on: ubuntu-latest
    steps:
      - name: Check and delete spam comments
        uses: actions/github-script@v8
        env:
          AKISMET_API_KEY: ${{ secrets.AKISMET_API_KEY }}
        with:
          github-token: ${{ secrets.GH_TOKEN }}
          script: |
            const apiKey = process.env.AKISMET_API_KEY;
            const comment = context.payload.comment;
            const discussion = context.payload.discussion;
            const repository = context.payload.repository;

            const params = new URLSearchParams({
              blog: repository.html_url,
              user_ip: '127.0.0.1',
              user_agent: 'D-blog Akismet Action/1.0',
              referrer: discussion.html_url,
              comment_type: 'comment',
              comment_author: comment.user.login,
              comment_author_url: comment.user.html_url,
              comment_content: comment.body,
            });

            const response = await fetch(
              `https://${apiKey}.rest.akismet.com/1.1/comment-check`,
              {
                method: 'POST',
                headers: {
                  'Content-Type': 'application/x-www-form-urlencoded',
                  'User-Agent': 'D-blog Akismet Action/1.0',
                },
                body: params,
              },
            );
            const result = (await response.text()).trim();

            if (!response.ok || !['true', 'false'].includes(result)) {
              core.setFailed(`Akismet returned HTTP ${response.status}`);
              return;
            }

            if (result === 'true') {
              await github.graphql(
                `mutation DeleteDiscussionComment($commentId: ID!) {
                  deleteDiscussionComment(input: { id: $commentId }) {
                    clientMutationId
                  }
                }`,
                { commentId: comment.node_id },
              );
              core.info('Spam comment deleted.');
            }

这个 workflow 的关键点有三个：

1. 监听 discussion_comment.created，只在新评论产生时执行。
2. 使用 github-script 直接读取事件对象，评论中的换行、引号和特殊字符不会破坏 shell 命令。
3. 删除评论使用 GraphQL 的 deleteDiscussionComment mutation，因为 giscus 评论对应的是 Discussion comment，而不是普通 Issue comment。

测试垃圾评论检测

完成配置后，可以发布一条测试评论验证流程。Akismet 提供了专门的测试字符串：

viagra-test-123

这条评论应当被判定为垃圾评论。发布后进入仓库的 Actions 页面，检查 workflow 是否成功运行，并确认评论是否被删除。

测试完成后不要继续保留测试评论，也不要在生产环境中把测试字符串当作普通内容使用。

处理持续刷屏的用户

Akismet 适合处理自动化垃圾内容，但它不是完整的社区管理系统。如果某个用户持续发布刷屏内容，可以在 GitHub 中打开该用户的个人资料页，手动阻止用户。

具体操作可以参考 GitHub 文档：阻止用户访问您的个人帐户。

防止新用户刷评论

如果垃圾评论来自大量新注册账号，可以配置仓库的交互限制：

https://github.com/你的用户名/你的仓库/settings/interaction_limits

根据博客的访问情况，可以临时限制新用户创建 Discussion、发表评论或进行其他交互。限制不应长期设置得过于严格，否则可能误伤正常读者。

注意事项

这套方案虽然简单，但仍有几个边界需要提前了解：

• giscus 依赖 GitHub，GitHub 登录或 Discussions 服务异常时，评论区也会受到影响。
• pathname 是评论关联的关键，文章 ID 和文章路径不应随意修改。
• Action 删除评论需要足够的 Discussions 写权限，Secret 令牌应使用最小必要权限。
• Akismet 的判断结果不是绝对准确，重要博客仍应保留人工复核能力。
• 不要在 workflow 日志中打印评论正文、API Key 或完整 GitHub Token。
• 评论区脚本来自第三方服务，应在站点隐私政策和 Cookie 策略中说明相关数据处理方式。

总结

对于使用 GitHub 托管源码的静态博客，giscus 可以用很低的接入成本提供完整的评论体验，Akismet 则负责过滤常见的垃圾内容。两者结合后，博客不需要搭建数据库、用户系统或单独的评论后端，就能拥有 GitHub 登录、Discussion 存储、评论通知和自动垃圾审查功能。

本文参考并沿用了二叉树树博客原文章的配图。
此外，请注意，本文采用了AI润色，请注意辨别。

测试结果截图(最新)

测试结果分享链接(最新)

测试结果分享链接

历史记录

2026-08-05

软件介绍

CodeDrobe Desktop 是一款面向 AI 桌面应用的开源主题管理器，目前支持 OpenAI Codex、WorkBuddy、QoderWork 与 TRAE SOLO，运行于 macOS 和 Windows。在应用内浏览 CodeDrobe 主题商店、一键把主题应用到任意受支持的应用，并可随时恢复原生界面。主题只改变外观，不会修改应用安装包和你的数据。

软件展示

软件下载

OneDrive (免登录 慢)

移动云盘 (需登录 不限速)

网站介绍

文件加密解密工具「LocalFileEncrypt」在本地加解密文本、文件或整个文件夹，只需要上传文件加密或者解密。据介绍使用标准密码学方法 AES 加密您的数据，只有掌握密钥的人才能正确解密。

网站展示

网站地址

Local File Encrypt | 在本地加解密文本、文件或整个文件夹

用 GitHub Issue 和 Actions 为静态博客实现新文章订阅

静态博客通常只有 RSS。RSS 很可靠，但读者需要自行准备阅读器，也不一定会及时看到更新。如果博客源码托管在 GitHub，还可以利用一个很容易被忽略的能力：GitHub Issue 本身可以被用户订阅。

本篇文章实现一套不依赖第三方推送平台的方案：读者订阅一个公开 Issue；当 posts/ 中出现新的 Markdown 文章或文章更新时，GitHub Actions 自动在该 Issue 下发布评论。GitHub 会再根据读者的通知设置，发送站内通知或邮件。

最终效果

这套方案完成后有两条清晰的路径：

1. 作者向 main 推送文章。
2. GitHub Actions 识别本次变更的文章，生成标题、摘要、链接和发布日期。
3. Action 在指定 Issue 下创建一条评论。
4. 已点击 Issue Subscribe 的读者收到 GitHub 通知。

它特别适合内容以 Markdown 管理、源码公开托管在 GitHub 的个人博客。

为什么选择 Issue 订阅

相较于自建邮件列表、Webhook 服务或即时通讯机器人，这个方案的依赖非常少。

Issue 订阅不取代 RSS，而是补充一种对 GitHub 用户更自然的订阅通道。博客可以同时保留 RSS、页面订阅入口和 Issue 更新通知。

工作原理

核心由四个部分组成：GitHub 的 push 事件、文章变更检测、Front Matter 解析，以及 Issue 评论 API。

flowchart LR
  A[推送文章到 main] --> B[GitHub Actions]
  B --> C[识别 posts/*.md 变更]
  C --> D[读取 Front Matter]
  D --> E{是否为草稿?}
  E -->|是| F[结束]
  E -->|否| G[创建 Issue 评论]
  G --> H[订阅者收到 GitHub 通知]

1. 用路径过滤减少无关执行

工作流只关心文章目录，因此可以在触发器中限制路径：

on:
  push:
    branches: [main]
    paths:
      - 'posts/**/*.md'

这样修改样式、图片或站点配置不会产生文章提醒，也不会浪费 Actions 执行时间。

2. 对比本次推送前后的提交

一次 push 可能包含一个或多个 commit。只比较 HEAD~1 与 HEAD 会漏掉同一次推送中较早的提交，因此应使用 GitHub 事件给出的前后 SHA：

git diff --name-only --diff-filter=AM "$BEFORE_SHA" "$AFTER_SHA" -- 'posts/*.md'

其中：

• --name-only 只输出文件路径。
• --diff-filter=AM 只保留新增（A）与修改（M）的文件。
• -- 'posts/*.md' 仅检查 posts/ 根目录内的 Markdown 文件。这里使用的是 Git pathspec，与工作流触发器中的 Actions glob 不是同一种匹配规则。

如果仓库是首次推送，前一个 SHA 会是全零值。此时改用 git show 获取当前提交中的文章文件即可。

3. 从 Front Matter 读取文章信息

D-blog 的文章在顶部使用 YAML 风格的 Front Matter：

---
id: github-issue-blog-subscription
title: 用 GitHub Issue 和 Actions 为静态博客实现新文章订阅
excerpt: 不依赖第三方推送平台，实现自动的新文章提醒。
date: 2026-07-22
draft: false
---

通知脚本需要的字段很少：

• id：生成文章 URL，例如 /post/github-issue-blog-subscription。
• title：评论标题。
• excerpt：评论中的摘要。
• date：展示发布日期。
• draft：值为 true 时不通知。

生产环境中可以使用完整 YAML 解析器。不过为了使工作流不增加额外依赖，简单的单行字段可通过正则和逐行分割读取。对于多行 YAML、复杂嵌套对象或引号转义较多的内容，则应使用可靠的 YAML 解析库。

4. 使用 GITHUB_TOKEN 发布评论

actions/github-script 提供了已认证的 Octokit 客户端，可以直接调用 GitHub REST API：

permissions:
  issues: write

await github.rest.issues.createComment({
  owner: context.repo.owner,
  repo: context.repo.repo,
  issue_number: Number(process.env.ISSUE_NUMBER),
  body,
});

这里不需要个人访问令牌。GitHub 会自动为工作流注入 secrets.GITHUB_TOKEN。当前实现只需 issues: write，用于创建 Issue 评论。

实现教程

下面以 D-blog 的结构为例，从零配置一套可用的提醒工作流。

第一步：创建订阅 Issue

在仓库中创建一个公开 Issue，例如标题为“D-blog 更新订阅”。读者打开该 Issue 后点击 Subscribe，后续 Issue 评论就会进入其 GitHub 通知中心。

例如 D-blog 的订阅入口是：

https://github.com/ououduck/D-blog/issues/6

Issue 编号是 URL 最后的数字，本例为 6。

第二步：确定接收通知的 Issue

D-blog 的工作流默认将提醒发送到 Issue #6，因此不需要额外创建仓库变量即可使用：

env:
  ISSUE_NUMBER: ${{ vars.BLOG_NOTIFY_ISSUE_NUMBER || '6' }}

BLOG_NOTIFY_ISSUE_NUMBER 是可选的覆盖项。只有在未来需要更换订阅 Issue 时，才在仓库的 Settings -> Secrets and variables -> Actions -> Variables 中创建它：

Name: BLOG_NOTIFY_ISSUE_NUMBER
Value: 12

配置后，通知会发送到 Issue #12；未配置时则始终发送到默认的 Issue #6。

第三步：创建工作流文件

在仓库新增 .github/workflows/notify-post-update.yml：

name: Notify Blog Post Update

on:
  push:
    branches: [main]
    paths:
      - 'posts/**/*.md'
  workflow_dispatch:
    inputs:
      post_files:
        description: 'Markdown paths to notify, separated by new lines'
        required: true
        type: string

jobs:
  notify:
    runs-on: ubuntu-latest
    permissions:
      issues: write

    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

这里的 fetch-depth: 0 会取得完整 Git 历史。虽然比浅克隆稍多一些数据，但能保证 before SHA 在同一次包含多个 commit 的 push 中可用于比较，逻辑更可靠。

第四步：识别文章并发布通知

推荐把多篇文章合并为一条 Issue 评论。一次批量发布三篇文章时，读者只会收到一条通知，评论中列出全部文章。

当前实现将变更检测、草稿过滤和评论发布放在同一个 actions/github-script 步骤中。这样只要匹配到非草稿文章，Action 就一定会调用评论 API；若权限或 API 调用失败，工作流会明确失败，不会再出现绿色成功但没有评论的情况。

下面是核心逻辑的简化版：

const childProcess = require('child_process');
const fs = require('fs');

const files = childProcess
  .execFileSync('git', ['diff', '--name-only', '--diff-filter=AM', beforeSha, afterSha, '--', 'posts/*.md'], { encoding: 'utf8' })
  .split(/\r?\n/)
  .filter(Boolean);

const posts = files.flatMap((file) => {
  const content = fs.readFileSync(file, 'utf8');
  const frontmatter = getFrontmatter(content);

  if (frontmatter.draft === 'true' || !frontmatter.id) return [];

  return [{
    title: frontmatter.title || frontmatter.id,
    excerpt: frontmatter.excerpt,
    date: frontmatter.date,
    url: `https://www.pldduck.com/post/${encodeURIComponent(frontmatter.id)}`,
  }];
});

let body = '## D-blog has new article updates\n\n';
for (const post of posts) {
  body += `### [${post.title}](${post.url})\n\n`;
  if (post.excerpt) body += `${post.excerpt}\n\n`;
  if (post.date) body += `Published: ${post.date}\n\n`;
}

encodeURIComponent 不应省略。虽然 D-blog 的 id 通常是英文 slug，但对 URL 参数进行编码是稳妥的默认做法。

第五步：授予工作流权限

除了 YAML 中的 permissions，还需要在仓库设置中允许工作流令牌写入：

1. 打开 Settings -> Actions -> General。
2. 找到 Workflow permissions。
3. 选择 Read and write permissions。
4. 保存设置。

如果只保留只读权限，创建 Issue 评论会收到 Resource not accessible by integration 一类的错误。

第六步：手动验证通知

除了在推送文章时自动执行，工作流也支持在 GitHub Actions 页面手动运行。打开 Notify Blog Post Update，点击 Run workflow，选择 main 分支，并在 Markdown paths to notify 中填写一个文章路径，例如：

posts/github-issue-blog-subscription.md

这会立即针对该文章创建一条 Issue 评论，是检查权限、订阅入口与通知设置的最快方式。

手动输入时每行填写一个相对于仓库根目录的路径，不要加反引号、引号或项目 URL。工作流会自动清理每行首尾空格，因此下面两种多篇文章写法都可用：

posts/github-issue-blog-subscription.md
posts/cf-tunnel.md

第七步：通过日志确认结果

工作流的 Post article notification 步骤会输出关键诊断信息。正常执行时，日志会依次出现：

Changed post files: posts/github-issue-blog-subscription.md
Notification posted: https://github.com/ououduck/D-blog/issues/6#issuecomment-...

第二行给出的 URL 就是新建评论的永久链接。出现以下提示时可按对应方式处理：

给读者的订阅入口

自动通知做好后，最容易遗漏的是让读者知道它的存在。建议在以下位置放置相同链接：

• 页脚：让全站访问者都能找到。
• 关于页：适合介绍博客订阅方式。
• 文章底部：读者刚读完内容时，订阅意愿通常最高。

按钮链接应直接指向 Issue：

<a
  href="https://github.com/ououduck/D-blog/issues/6"
  target="_blank"
  rel="noopener noreferrer"
>
  前往订阅
</a>

读者只需登录 GitHub，打开该 Issue 并点击 Subscribe。取消订阅同样由 GitHub 原生提供，不需要网站存储用户信息。

常见问题

只修改旧文章，也会发通知吗？

会。当前方案的目标是“文章更新提醒”，新增与修改的 Markdown 都会被识别。如果只希望首次发布时提醒，需要额外比较文件在 BEFORE_SHA 中是否存在：不存在才视为新文章。

草稿为什么没有提醒？

这是预期行为。draft: true 的文章通常尚未公开，通知脚本会主动跳过它。将草稿改为 draft: false 后推送，便会成为可提醒的发布内容。

为什么我没有收到邮件？

先确认 Issue #6 中已经出现由 github-actions[bot] 创建的新评论，再确认已在目标 Issue 上点击 Subscribe。最后检查 GitHub 的 Notifications 设置：GitHub 可以只显示站内通知，也可以按仓库、参与情况或关注状态发送邮件。Issue 评论已创建但没有邮件时，通常是个人通知渠道配置，而不是博客工作流问题。

我需要配置仓库变量吗？

不需要。D-blog 默认使用 Issue #6。只有需要迁移订阅入口时，才配置可选变量 BLOG_NOTIFY_ISSUE_NUMBER。变量值只应是数字，例如 12，不要填写 #12 或完整 URL。

为什么工作流成功却没有评论？

先查看 Post article notification 步骤的 Changed post files 输出，确认它识别到正确的文件。然后检查文章不是 draft: true。当前工作流会在文件不存在、没有可发布文章或评论 API 没有权限时明确失败并显示具体原因，不会再静默跳过。

安全与维护建议

• 不要将个人访问令牌写入工作流。优先使用 GitHub 自动提供的 GITHUB_TOKEN。
• 为默认订阅 Issue 提供回退值，并用可选仓库变量覆盖它，避免遗漏配置导致工作流静默跳过通知。
• 不要将用户邮箱或订阅名单提交到仓库。Issue 订阅由 GitHub 管理，博客不需要保存个人数据。
• 使用最小权限。当前只需要 issues: write；不要额外授予仓库写入或个人访问令牌权限。
• 为脚本保留草稿过滤与缺失 id 的告警，避免未完成文章或格式错误文章被推送出去。

总结

GitHub Issue + GitHub Actions 的文章订阅方案并不复杂：用 push 事件捕获文章变更，读取 Markdown 元数据，调用 Issue 评论 API，再由 GitHub 完成通知分发。

它的价值不在于替代 RSS，而在于为 GitHub 用户提供一个零额外注册、零额外服务、可随时取消的订阅方式。对于源码与内容都在 GitHub 中维护的静态博客，这是一条足够轻量、可维护且透明的更新通知链路。

时隔一年半 deepseek v4 众望所归

这次官网上线分为了两个版本 并且一如既往的开源

分别为 Pro 和 Flash 版本

Pro 是 1.6T 总参 49B 激活
Flash 是 284B 总参 13B 激活

两档都支持1M上下文
相较于上一代 V3 仍有明显提升

话不多说 先看看价格

其实我觉得这个价格 特别是现在打折的话 还是挺便宜的

重点：这次DeepSeek-V4开创了一种全新的注意力机制

DeepSeek-V4 开创了一种全新的注意力机制，在 token 维度进行压缩，结合 DSA 稀疏注意力（DeepSeek Sparse Attention），实现了全球领先的长上下文能力，并且相比于传统方法大幅降低了对计算和显存的需求

• 相比于上一代V3.2降低了3-10倍的算力需求
  

• V4-Pro 比 V3.2 降低 3.7 倍

• V4-Flash 比 V3.2 降低 9.8 倍
  也就是说 在相同算力下 可以处理更多请求(硅基流动狂喜 bushi)

接下来看跑分(仅作参考 你懂的)

总结

时隔一年半 Deepseek V4 不负众望
也是拿出了自己的实力 V4在各个方面都有不小的提升 尤其是算力方面 我认为是非常不错的

CentOS 宝塔面板无法安装 Swoole5 解决教程

教程介绍

最近在给程序部署环境时，发现CentOS 系统下的宝塔面板始终无法安装 Swoole 5，无论怎么点击安装都会失败。 排查后发现并不是 Swoole 本身问题，而是系统缺少相关依赖库。于是整理了这篇教程，记录完整解决过程，方便遇到同样问题的朋友参考。

问题现象

在宝塔面板中安装 Swoole5 时：

• 安装失败
• 编译报错
• 提示缺少依赖

通常是因为系统缺少brotli-devel 相关依赖。

解决步骤

第一步：更新系统：

执行以下命令：

yum update

⚠️注意

如果执行 yum update 出现报错，例如：

• 无法连接镜像源
• DNS 解析失败
• 下载失败

说明你的 CentOS 镜像源有问题，需要自行更换国内镜像源（如阿里云、腾讯云镜像源）

如何更换CentOS镜像源

第二步：安装缺失依赖

执行命令安装 brotli-devel：

yum install brotli-devel

安装完成后，可使用以下命令确认依赖是否已安装：

rpm -q brotli-devel

第三步：重新安装 Swoole5

回到宝塔面板：

1. 进入【软件商店】；
2. 找到对应 PHP 版本
3. 安装 Swoole5

此时应该可以正常编译并安装成功：

原因分析

Swoole 5 在编译时依赖 brotli 压缩库，如果系统中没有安装 brotli-devel，就会导致编译失败。 CentOS 默认环境中通常不会自带该依赖，因此需要手动安装：

总结

如果你在 CentOS + 宝塔面板 环境下安装 Swoole5 失败，可以按照以下顺序排查：

1. 执行 yum update
2. 安装依赖 yum install brotli-devel
3. 重新安装 Swoole5

基本都可以解决问题

微信和元宝打架？是腾讯内斗还是有意而为？

前情提要

这两天 腾讯元宝推出了送10亿的活动
于是微信 QQ等各大平台全都被元宝的红包邀请广告刷屏

主要事件

结果......微信出手了
直接反手给元宝封了

很快 元宝也在微博发出了回应

观点看法

有的人认为这是腾讯内斗
有的人认为不同部门各尽其责很正常
也有人认为就是博流量和热度

但我看来：
1.确实是为了博流量
2.不完全是博流量 也不单单是为了彰显微信的公平
3.我认为最根本 最真正的原因是为了接下了其他AI软件的活动做伏笔 因为很多AI软件(如千问)都宣布要开启送福利活动 腾讯内部决定故意封禁元宝 避免之后封其他AI软件的时候被说“双标”

总结

这次事件绝非内斗或普通引流 而是为腾讯的一步好棋

后补-2026.2.10

果然猜想是正确的

使用Cloudflare Tunnel轻松实现内网穿透

引言

在日常开发和运维中，我们经常遇到需要从公网访问本地网络服务的需求。传统的做法可能涉及复杂的配置或高昂的成本。然而，随着Cloudflare Tunnel的出现，这一切都变得简单而高效。

Cloudflare Tunnel简介

Cloudflare Tunnel通过建立一条安全、加密的隧道，将本地的服务暴露到公网，无需公网IP地址或端口转发。这不仅简化了内网穿透的过程，还提升了安全性。

主要功能

• 内网穿透：允许公网用户访问位于私有网络中的服务。
• 端口转发：支持将非常规端口的请求转发至常规端口号（如80/443）。
• 自动HTTPS：为您的服务自动配置SSL证书，确保数据传输的安全性。
• 额外认证：为您的服务添加额外的安全层，提高访问控制。

工作原理

Cloudflare Tunnel利用Cloudflare全球网络作为中介，通过运行在本地服务器上的cloudflared守护程序与Cloudflare云端进行通信，从而实现在公网访问本地服务的目的。

开始使用Cloudflare Tunnel

前置条件

• 拥有一个域名，并将DNS解析托管于Cloudflare
• 内网中有一台能够运行cloudflared程序的服务器
• 一张国际双币信用卡（仅用于验证，不会产生费用）（其实没有也可以 有骚操作）

步骤1：注册并登录Cloudflare

首先，前往Cloudflare Zero Trust注册账号并登录。

步骤2：创建Tunnel

先设置团队名称 随便写

选择免费计划 然后的添加付款方式这一步很重要，有卡的直接绑定即可，反正免费，没卡的有一个骚操作，在这个页面直接关闭 重新进入Cloudflare Zero Trust就可以跳过。

最后直接在Access Tunnels中，创建一个Tunnel

这样创建Tunnel的步骤就完成了

步骤3：安装并配置cloudflared

根据官方指南，在您的本地服务器上安装cloudflared并配置Tunnel连接。以下是一个示例命令：

docker run --name cloudflared -d --restart unless-stop cloudflare/cloudflared:latest tunnel --no-autoupdate run --token YOUR_TOKEN_HERE

请记得替换YOUR_TOKEN_HERE为您自己的Token。

步骤4：配置域名和转发规则

为你的域名配置一个子域名（Subdomain），Path 留空，URL 处填写内网服务的IP加端口号。注意 Type 处建议使用 HTTP，因为 Cloudflare 会自动为你提供 HTTPS，因此此处的转发目标可以是 HTTP 服务端口。

现在，你就能通过刚刚设置的子域名直接在公网访问你的内网项目了

安全增强

为了进一步提升安全性，您可以为服务添加基于Email、IP等多种方式的身份验证。

结论

Cloudflare Tunnel 夯完了 免费又好用 除了慢点