背景 先打个招呼：下文里的「大鹅」「大鹅蛋」「喵喵内核」，分别对应大家熟悉的那套透明代理组合。 之前我在 Cudy TR3000 上吃过大鹅蛋 。实习租房那会儿宽带只有 200Mbps，测下来代理下行能跑满，CPU 也看着还行，一度觉得这台小路由自己扛透明代理就够了。 离职回家以后带宽粗了不少，Cudy 就开始露馅：直连能跑满的速度，一走代理就掉下来。网口挺体面，真干活还是那颗小 SoC 扛不住加密解密和规则匹配。 内存也是坑。Cudy 只有 512MB，挂美西这种高延迟节点时，TCP 窗口会跟着 RTT 往上抬，
本站是用 Nuxt v4 + Nuxt Content v3 + i18n 搭出来的纯 SSG 博客。开站时随手定了一个看似无关紧要的策略—— 所有页面 URL 以 / 结尾 。 听起来一行配置就该完事的事，做下来才发现 Nuxt 在尾斜杠这件事上 至今没有一个统一的官方开关 （ nuxt/nuxt#15462 这个 issue 从 2022 年挂到现在），整套策略最后是靠 六个不同层面 拼出来的。这篇就把站点里所有跟 trailing slash 相关的配置完整盘一遍，留作给自己和后人的备忘。 为什么要尾斜杠 简
深夜的“冲动”消费 前几天深夜 0 点，躺在床上百无聊赖刷着京东，居然奇迹般地逮到了这台常年断货的 Xiaomi Book Pro 14 2026 顶配版的现货！这突然弹出来的购买按钮，简直像是在跟我招手。虽然脑子里天人交战了一番，最后我的手还是非常诚实地按下了付款键。 虽说错过了首发折扣，原价 10499 让人隐隐有些肉疼，但好在还能叠一波本地的国补，实付 8999 拿下的价格也算是“真香”了。仔细想想一点也不亏，毕竟也是时候让我那台任劳任怨、被我折腾了四年的老伙计 ThinkPad T14 Gen2i 顺理成章
在去年的 11 月，我入手了一台新的国行版的小米 15 作为我的主力机。其实之前手上的 Redmi K70 Ultra 与这台小米 15 是同一年发布的产品，性能上也不相上下，但我在 Gap Year 期间在全国多地旅行，意识到没能将自己所见的夜景拍下是一件挺可惜的事，于是就想换一台拍照更好的手机。新发布的小米 17 在价格上正处于高位，且相对于 15 来说并没有太大的提升，所以我就直接入了小米 15。 入手以后，我按照自己的使用习惯打开了设置中的「谷歌基础服务」，安装好「Google Play」后便正常使用。但就
如果大家对目前中国大陆境内的网络环境足够了解，应该就会知道 dl.google.com 在很多情况下是 可以直连访问 的。比如，你可以通过 google.cn/chrome/?standalone=1 这个 URL 直接在境内的网络环境下下载 Chrome 的离线安装包，最终的下载域名就是 dl.google.com 。 我平常的使用习惯是 24 小时开启代理工具的 TUN，让所有流量先经过一张虚拟网卡，再根据分流规则自动判断要不要走代理。这个习惯大部分时候都挺省心的——直到最近我用 yay 滚 Arch 的时候，
Vercel 默认的缓存配置其实并不合理，但鲜有人注意。 先看效果 分析 测试方案 这两张图都是我博客在 PageSpeed Insights 上测得的，测试步骤如下： 部署 在 PageSpeed Insights 进行第一次测试 等待 120s，防止 PageSpeed Insights 拿之前的结果糊弄你 进行第二次测试，取第二次测试的结果 取第二次结果的目的是为了 让 PageSpeed Insights 所命中的 Vercel CDN 节点完成回源，并 将内容缓存在 CDN 节点上 ，这样第二次访问的时候
背景 在我的一台优化线路 vps 上，我的 443 端口要承担两个职责 作为我博客对中国大陆境内访客的服务提供者，同时承担 https 流量加解密和 static server 的职责 把某些特殊用途的流量特征通过一些手段伪装成某些知名、常见、且被广泛允许的站点的 https 流量 （没错，是 Reality） 因此，我需要一个能够在同一台服务器的同一端口上同时处理这两种职责的方案。 方案选择 其实我很早就知道 Nginx 的 stream 关键词可以实现 Layer 4 （即 TCP 字节流原样转发）下基于 SN
在 上一篇博客 中，我提到过一个核心观点—— 对于流量少、访客的地理位置不集中的小型站点，DNS 冷启动不是偶发的“意外”，而是一种被动的“常态”。 对于大多数站长而言，自己的站点流量不是一时半刻就能提上去的，因此我们的访客大概率都要走完一遍完整的 DNS 解析过程。上一篇博客中我提到过更改为距离访客物理位置更近的权威 DNS 服务器来提升速度，但 TLD（域名后缀）的 Nameservers 是我们无法改变的 ，也就是下图中红色背景的那一段解析过程。 sequenceDiagram autonumber part
当我们谈论网站性能时，我们通常关注前端渲染、资源懒加载、服务器响应时间（TTFB）等。然而，在用户浏览器真正开始请求内容之前，有一个至关重要却鲜少在性能优化方面被提及的部分—— DNS 解析。对于默默无闻的小型站点而言，“DNS Cache Miss”（缓存未命中）或我称之为“DNS 冷启动”，会成为绕不过去的性能瓶颈，也就是本文标题所提到的“西西弗斯之石”。 神话的隐喻：DNS 解析的漫长旅程 要理解这块“石头”的重量，我们必须重温 DNS 解析的完整路径。这并非一次简单的查找，而是一场跨越全球的接力赛： 起点：
我最近一阵子在重构我的博客，恰巧之前一阵子准备秋招的时候背八股时看到了 HTTP/2 的服务端推送，于是便尝试在部署阶段为我的博客配置好 HTTP/2 的服务端推送，试图以此来进一步优化首屏加载速度。 HTTP/2 服务端推送为什么能提升首屏加载速度 如下图，在传统的 HTTP/1.1 中，浏览器会先下载 index.html 并完成第一轮解析，然后再从解析出的数据中拿到 css/js 资源的 url，再进行第二轮请求，在 tcp/tls 连接建立后最小需要 两个 RTT 才能取回 完整渲染页面所需的资源。 seq
Nuxt Content 是 Nuxt 生态中用于处理 Markdown、YAML 等内容的强大模块。最近，我在使用 Nuxt v4 + Nuxt Content v3 重构博客（原为 Hexo）时，遇到了一个棘手的问题：v3 版本的默认查询 API 并未直接提供 对数组字段进行“包含”（ $contains ）操作的支持。 例如，这是我的正在写的这篇博客的 Front Matter： --- title: Nuxt Content v3 中数组字段的筛选困境 date: 2025-10-20 21:52:59 s
2023 年 8 月，CA/Browser Forum 通过了一项投票——不再强制要求 Let’s Encrypt 等公开信任的 CA 设立 OCSP Server 2024 年 7 月，Let's Encrypt 发布 博客 ，披露其计划关闭 OCSP Server 同年 12 月，Let's Encrypt 发布 其关闭 OCSP Server 的时间计划表 ，大致情况如下： 2025 年 1 月 30 日 - Let’s Encrypt 不再接受新的包含 OCSP Must-Staple 扩展的证书签发请求，
在今年八月的时候，我这边所在的一个 Github Organization 在私有项目开发阶段频繁触发 CI，耗尽了 Github 为免费计划 (Free Plan) 提供的 每月 2000 分钟 Action 额度 （所有私有仓库共享，公有仓库不计）。大致看了下，CI 流设置得是合理的，那么就要另寻他法看看有没有办法去提供更宽裕的资源，因此也就盯上了文章标题中所提到的 Github Action Self-hosted Runner 。 对于这个 Self-hosted Runner，与 Github 官方提供的
去年夏天，我花了不少时间搭建博客图床，核心目标是 分地区解析 DNS ，让国内外访客都能快速加载图片。技术方案看起来完美无缺，直到最近群友反馈首次访问时图片加载很慢，我才发现问题所在。 955 毫秒的 DNS 解析时长！ 这个数字让我大吃一惊。访客点开博客后，光是确定图片服务器位置就要等将近一秒，这完全抵消了 CDN 优化的效果。 为什么之前没发现？ 主要是 DNS 缓存 的"功劳"。它会为后续访问记住解析结果，让我的本地测试和复访测试看起来都很正常。直到用户反馈，结合最近准备秋招复习的 DNS 解析流程（递归查询
上回回顾：当 morphdom 遇上 Vue 在 上一篇文章 中，我们经历了一场 Markdown 渲染的性能优化之旅。从最原始的 v-html 全量刷新，到按块更新，最终我们请出了 morphdom 这个“终极武器”。它通过直接比对和操作真实 DOM，以最小的代价更新视图，完美解决了实时渲染中的性能瓶颈和交互状态丢失问题。 然而，一个根本性问题始终存在：在 Vue 的地盘里，绕过 Vue 的虚拟 DOM (Virtual DOM) 和 Diff 算法，直接用一个第三方库去“动刀”真实 DOM，总感觉有些“旁门左道
需求背景 在最近接手的 AI 需求中，需要实现一个类似 ChatGPT 的对话交互界面。其核心流程是：后端通过 SSE（Server-Sent Events）协议，持续地将 AI 生成的 Markdown 格式文本片段推送到前端。前端负责动态接收并拼接这些 Markdown 片段，最终将拼接完成的 Markdown 文本实时渲染并显示在用户界面上。 Markdown 渲染并不是什么罕见的需求，尤其是在 LLM 相关落地产品满天飞的当下。不同于 React 生态拥有一个 14k+ star 的著名第三方库—— rea
更新目标 node-sass -> sass ( dart-sass ) 减少影响面，非必要不更新其他依赖的版本 在前两条基础上，看看能否提升 node.js 的版本 抛弃 node-sass 的理由 node-sass 已经停止维护，dart-sass 是 sass 官方主推的继任者 node-sass 在 windows 下的安装非常麻烦，npm 安装时需要开发机上同时装有 python2 和 Microsoft Visual C++ 在安装 node-sass 时，需要从 Github 拉取资源，在特定网络环
前端「量子态」现象的首次观测 这事说来也邪乎，半个月前吃着火锅唱着歌，在工位上嘎嘎写码，发现一个诡异的 bug。作为如假包换的人类程序员，写出 bug 是再正常不过的事情了，但这 bug 邪门就邪门在我一打开 F12 的 DevTools 观察相关的 dom 结构，这 bug 就自动消失了；再把 DevTools 一关，Ctrl + F5 一刷新页面，Bug 又出现了。 下面是使用 iframe 引入的 demo 这 Bug 给我整得脑瓜子嗡嗡的，我又不是物理学家，写个前端怎么量子力学的观察者效应都给我整出来了（？
事情的起因是需要在网页上展示一个时长约为 5 分钟的产品展示视频，拿到的 H264 编码的原文件有 60MB 大。高达 1646 Kbps 码率的视频文件通过网络传输，烧 cdn 流量费用不说，对于弱网环境下的用户体验也绝对不会好。因此必须在兼顾浏览器兼容性（太好了不用管 IE）的情况下，使用更现代的视频压缩算法进行压缩。 哪些压缩算法是目前的主流？ AV1 AV1 作为目前压缩效率最高的主流视频编码格式，在 2025 年的今天已经在 YouTube、Netflix、Bilibili 等视频网站全面铺开，毫无疑问是
这是精弘内部的图床开发时遇到的事情，大一的小朋友反馈说 el-image 和 el-table 打架了。 demo 的 iframe 引入 看到后面的表格透出 el-image 的预览层，我的第一反应是叫小朋友去检查 z-index 是否正确，el-image 的 mask 遮罩的 z-index 是否大于表格。 经过我本地调试，发现 z-index 的设置确实没问题，但后面的元素为什么会透出来？谷歌搜索一番，找到了这篇文章 给 el-table 加一行如下代码即可 .el-table__cell { positi
基础原理 如果你尝试在搜索引擎上检索本文的标题，你搜到的文章大概会让你使用下面两个 API。 我希望你用的搜索引擎不至于像某度一样灵车到 2025 年还在让你使用基于 Flash 的 ZeroClipboard 方案 document.execCommand 2012 年不止有世界末日，还有 IE 10。随着 IE 10 在当年 9 月 4 日发布，execCommand 家族迎来了两个新的成员—— copy/cut 命令（此说法来自 Chrome 的博客 ，而 MDN 认为 IE 9 就已经支持了 ）。三年之后，
事情的起因是因为精弘的 前技术总监 抱怨学校的内网服务器无法连接外网，从而导致 apt 安装与更新异常困难，需要手动从源中下载软件包、软件包的依赖及其依赖的依赖。。。然后将这些包通过 sftp/rsync 一类的手段传到服务器上手动安装。 于是本文应运而生，我们可以在本机使用 Caddy （Nginx 当然也行）反代一个 APT 源镜像站，通过 ssh 隧道建立端口转发，这样就可以在内网服务器上访问到本地的 Caddy 服务器，进而访问到外网的镜像站。 前提条件 主控机（你自己的电脑）能够通过 ssh 直接连接电脑
缘起 前不久在京东自营看到我馋了很久的 Cudy TR3000 有 ￥153 的折扣价，虽然比起 ￥130 的史低价（甚至 ￥110 的凑单史低价）还有些距离，但已经到我的可接受范围内了，于是果断下单剁手了这台我心心念念的 Cudy TR3000 迷你路由器，以此来缓解我的 开学前综合症 （一种精神性疾病） 这台路由器使用 Type-C 供电，拥有一个 2.5Gbps 的 WAN 口和一个 1Gbps 的 LAN 口，在此基础上还有一个 USB 口可用于打印机共享、挂载外接存储、安卓手机 USB 共享网络等多种用途
确信，是 cloudflare workers 用上瘾了 在 「使用 Github Action 更新用于 rpm 打包的 spec 文件」 一文中，我利用 Github Action 实现了自动化的 spec 版本号更新，配合 Fedora Copr 的 webhook 就可以实现 Copr 软件包更新的自动化构建。看似很完美，但缺少了一个构建状态的监控机制，这导致出现构建错误的时候我不能及时得到通知（无论构建错误是 spec 本身的问题或者是构建时的网络环境问题）。 西木野羰基 提出 notifications
起因 受一些客观因素的影响，微精弘前一阵子针对学校教务系统的数据爬取服务状态出现了非常不稳定的状态，而后端在设计初并没有考虑到异常告警机制，恰逢现任员工都身陷期末周的痛苦之中，我这种计院 Lite 专业的精弘老人就打算实现一个针对「 微精弘主后端 <-> funnel 爬虫服务 <-> 教务系统 」这一条链路的告警机制。旨在短期内（即期末周结束之前）填补微精弘的后端服务告警机制的空白，让运维人员能够及时收到并处理排查后端网络链路的异常情况，尽最大努力保证服务在线率，保障工大本科生在期末周内使用体
起因 早在去年 10 月，我就写过一篇 《创建 b23.tv 追踪参数移除 bot》 。记录了部署 b23.tv 的追踪参数移除 Bot 的部署方案。其中提到的 TG Bot 随着服务器到期不再续费也一同落灰了—— 公益服务总是这样，开始时满腔热血，随着时间散去没有多少人能坚持投入成本，徒留下一地鸡毛。 大概半个月前，我在群里看见 Asuka Minato 开发的群消息总结 Bot，整体部署在 Cloudflare Workers 上，在保证零运营成本的情况下有着相当非常不错的在线率保证，因此便考虑将这个 Bot
小试一下？ 在开始阅读后面的内容之前，或许你可以试试看你正在使用的浏览器能不能访问下面两个链接: https://digicert-tls-ecc-p384-root-g5-revoked.chain-demos.digicert.com/ https://revoked-isrgrootx1.letsencrypt.org/ 这两个链接分别是由 digicert 和 Let's Encrypt 维护的，特意维持了一个 证书没过期，但被 CA 吊销 的状态。 在我的 Firefox for Linux 上，两个链接
写在前面 一个月前，我发现小爱课程表中针对我学校的教务系统导入系统年久失修，因此我便决定自己另立门户、独立维护一版针对 ZJUT 教务系统课表信息导入的适配项目。 整个流程不难，如果你对于 js 代码和爬虫技术有简单的了解，那么很快就可以上手，我大概只花了 2 小时就完成了 阅读文档-编写代码-自测通过-提交审核 的过程，并在一周内正式上架，得到了身边同学的认可。 在适配过程中，一定要仔细阅读官方文档，所有技术性问题几乎都能通过官方文档解决。这篇博客我尽量详细记录了使用 fetch 打请求获取 json 的正方教务
waline 更新到 V3 版本已经是九个月前的事情了，眼瞅着 hexo fluid 主题并没有带我更新的意思，我就打算自己更新到最新版，结果遇到了两个坑，写文供大家参考。 在 Hexo 目录下的 _config.fluid.yml 文件中找到 waline 的 cdn，将版本号指向最新版。 - waline: https://registry.npmmirror.com/@waline/client/2.15.8/files/dist/ + waline: https://registry.npmmirror.c
前两天给自己的 N100 小主机重装成了最近发布的 Fedora 41 ( KDE )，也是花了不少时间把整个系统调成自己熟悉的样子，因此开一篇博客记录一下。以下仅为我个人的 HomeServer 小主机使用，不具有普适性。 换官方源 我这里比较适合用上交的源，直接参考 他们的文档 。 sudo sed -e 's/^metalink=/#metalink=/g' -e 's|^#baseurl=http://download.example/pub/|baseurl=https://mirror.sjtu.edu