两双筷子
type: channel
link: https://www.dbkuaizi.com/
description: 人生就是一段路，当你觉得费力时，你已经走上坡路了！加油，少年！
items: 密码管理：从花密到 Bitwarden 自托管
items: SQLite Zstd进阶压缩-批量压缩
items: Seven Player：Windows上播放115网盘视频的增强工具
items: CDN 盗刷也是被我遇上了
items: 多用户 PassKey 认证插件
items: 博客五年
items: 1Panel 部署 FastAdmin 管理端访问 302 解决方案
items: 解析到本地127的神奇域名
items: Typecho 多吉云上传插件
items: 极简 Docker 入门笔记

密码管理：从花密到 Bitwarden 自托管
type: item
date: 2026-08-22T08:56:00+00:00
description: 前言早期互联网世界里，账号密码几乎是保护数字资产的唯一手段。但记忆密码本身违反人性，因此绝大多数人在不同平台使用相同的账号和密码。即便某个平台有特殊复杂度要求，也无非是在主密码前后加上 a、A、@ 等字符稍作变化，本质上仍基于同一个主密码。这种做法给“撞库”攻击提供了可乘之机。例如，国内某知名技术平台曾使用明文存储用户密码，并发生数据泄露。如果你恰好注册过该平台，且用户名和密码与其他平台一致，那么你的其他数字资产便等同于完全暴露。平台处理用户数据的方式我们无法干预，所以我们需要确保每个平台的账号密码互不相同。但记忆多组密码又很困难，因此借助密码管理工具来代劳，就成了最合理的方案。历史花密我使用密码管理软件的时间不算很长。最早接触到的相关工具，是在异次元软件网站上看到的花密。它通过一个固定算法，要求用户输入主密码和平台唯一标识，然后生成一个高复杂度的密码——不同标识生成不同密码，从而避免重复。但实际体验下来，每次登录都需要打开工具计算密码，对于高频使用场景来说非常繁琐。KeePass后来，同样在异次元上我了解到KeePass。它在密码管理领域堪称老前辈，自 2003 年发布至今仍在迭代，几乎能满足所有密码管理需求。但它也有一些难以回避的缺点：无原生云同步：密码存储在本地的 kdbx 数据库文件中，官方未提供同步功能，需要借助坚果云等第三方网盘手动同步。仅官方支持 Windows：官方至今只发布 Windows 版本。好在 KeePass 开源，社区衍生出多个分支，例如 KeePassXC 提供了 Windows、macOS、Linux 及 Web 版本，界面也更美观。此外，还有众多第三方项目覆盖 Android 和 iOS 等移动端。关于 KeePass 的生态，你可以参考这个收集项目：https://github.com/lgg/awesome-keepass虽然通过“坚果云 + KeePassXC + 移动客户端”的组合可以实现全平台使用，但配置过程较为繁琐。而且多端修改时若同步不及时，容易产生冲突，kdbx 的冲突处理不像文本代码那样直观，需要手动打开两个冲突文件进行合并，操作成本较高。Microsoft Authenticator前几年，一些技术社区和平台陆续开始支持 OTP（一次性密码）双因素认证。起初我不太了解 OTP，后来发现它无需依赖短信（当前个人开发者使用短信服务门槛较高），甚至不依赖网络即可完成身份校验，于是决定为所有支持 OTP 的平台开启该功能。考虑到国内网络环境，我在 Google Authenticator 和 Microsoft Authenticator 之间选择了后者。同时我使用微软邮箱，用微软验证器登录微软服务也更方便。使用约一年后，我换了新手机，在新设备上安装了 Microsoft Authenticator 并登录微软账号，发现 OTP 列表为空。接着查看旧手机，列表也变空了。搜索后才发现这不是个例（参考 被 Microsoft Authenticator 坑惨了，所有 2FA 全丢了），许多用户在新设备登录时都遇到了相同问题。根据大家的反馈，结合自身经历，问题出在：新设备登录时应选择“恢复”而非直接登录账号，点击恢复后再登录才能同步云端 OTP 数据；如果直接登录，新设备的空列表会覆盖云端数据，进而导致旧设备上的 OTP 也丢失。更麻烦的是，即便按“恢复”操作，仍有部分用户报告数据丢失。微软的同步逻辑难以捉摸，经历了这次事故后，我不敢再依赖微软验证器。替代品既然微软验证器靠不住，我需要找一个替代方案。恰巧此时我几乎所有平台的密码仍相同，所以目标从单纯的 OTP 工具转向全功能密码管理器。我评估了 1Password、LastPass、Enpass、Bitwarden 这几个行业主流产品。它们在基础功能上差别不大——账号密码管理、自动填充、密码生成器、OTP、通行密钥、全平台同步等一应俱全。主要差异在于性价比和安全性：LastPass 已多次泄露用户数据，数据库几乎成了公开信息，为了安全直接排除。Enpass 在 2019 年 11 月前采用买断制，之后转为订阅制。它最大的特色是不提供自带云同步服务，只开放同步功能，允许用户通过主流网盘或 WebDAV 自行同步。1Password 功能全面，但订阅价格较高（现为 $47.88/年）。Bitwarden 综合下来最适合我，年费 $19.80，功能齐全，且尚未出现大规模安全事件。因此从 2023 年起，我一直使用 Bitwarden 管理密码。Bitwarden2023 年刚开始使用 Bitwarden 时，我订阅了官方服务，一年约 70 元人民币，价格合理。但使用一年后发现，由于网络问题，同步服务连接不太稳定，不过数据从未丢失。基于网络体验…

SQLite Zstd进阶压缩-批量压缩
type: item
date: 2026-08-05T14:52:00+00:00
description: 起因上一篇《SQLite 压缩存储日志》写的是第一代方案。日志从 MySQL 独立出来，按月写入 SQLite 文件，单条日志超过 150 字节时使用 Zstd 压缩。这套方案已经跑了一段时间，查询和磁盘占用都比原来好很多。不过日志量继续上来以后，逐条压缩的空间节省开始不太够用。本文的测试数据和上一篇不同。上一篇使用 A、B 两个项目的日志，本文使用另一批 500 万条日志和单独的 SQLite 测试文件。两篇文章的数据来源不同，后面出现的体积数据只能分别参考，不能当成同一批数据的前后对比。很多日志的字段名、状态和固定输出会反复出现，变化的可能只有 ID、时间和少量结果字段。第一代方案会把每条日志分别交给 Zstd 压缩。每次压缩只看到当前这一条日志，前面已经出现过的字段名和固定输出，后面还得再压一次。把一批相似日志放在一起压缩，Zstd 才能把这些重复内容利用起来。服务器 CPU 也是我考虑升级的一个原因。我们绝大多数系统的 CPU 都有余量，平时不用也是闲着。日志归档可以放到后台跑，用一些 CPU 换磁盘空间，这笔账能算得过来。这个思路是看 ClickHouse 存储方式时想到的。数据先写进去，后面由后台慢慢做合并和压缩。日志没有必要照搬 ClickHouse 的实现，不过这个方向很适合历史日志。问题直接把多条日志拼起来压缩，看上去很简单，实际会遇到一个麻烦。一条日志在写入过程中，内容可能还会继续补充。假设一个压缩包里已经有 1000 条详情，其中一条又多输出了几行内容，更新它需要先解压整个压缩包，改完后再压回去。一次很小的写入，结果变成了重写 1000 条日志。所以日志需要分开存。任务还在执行时，详情继续按原来的方式写入。等任务结束，确认日志不会再变，再批量压缩归档。改进这次把一条完整日志拆成三部分保存。日志索引表保存时间、任务 ID、状态、列表摘要和压缩包定位，用于列表、筛选和统计。日志详情表保存还会继续追加的完整日志，用于任务执行期间写入。日志压缩表保存多条历史详情合并后的 Zstd 数据，用于长期保存。为了方便理解，可以把日志压缩表里的每一行看成一个压缩包。一个压缩包里放几百条或者几千条已经结束的日志详情。任务开始写日志时，先写入日志索引表和日志详情表。列表页需要的时间、任务 ID、状态这些字段放在索引表里，完整输出留在详情表。这样任务列表查询不会碰到大字段，也不需要解压日志。任务结束后，后台归档任务会从日志详情表里取一批数据。为了在解压后还能区分每条日志的边界，我在每条详情前面写入长度，再把整段数据压缩。[第 1 条详情长度][第 1 条详情内容] [第 2 条详情长度][第 2 条详情内容] [第 3 条详情长度][第 3 条详情内容] ...压缩完成后，需要在同一个事务里完成下面三件事。写入日志压缩表，得到 block_id。更新日志索引表，记录每条日志对应的 block_id 和序号。删除日志详情表中已经归档的内容。block_id 就是压缩包的 ID，序号表示这条日志排在压缩包里的第几条。归档任务下次执行时，只查 block_id 为空的记录，已经归档过的日志不会再被重复压缩。这三个步骤一定要放在一个事务里。中间任意一步失败，整批数据回滚，详情表还在，下次可以继续归档。要是分开提交，就可能出现索引指向了不存在的压缩包，或者详情删掉了却找不到归档数据的情况。查询方式列表查询还是只查日志索引表，和第一代方案差不多。打开某条完整日志时，先从索引表查 block_id。block_id 为空，说明任务刚结束或者还没归档，直接读取日志详情表。block_id 有值，读取对应的压缩包，解压后按序号取出这条详情。一个列表页里可能有多条日志落在同一个压缩包里。这种情况可以在请求里缓存解压结果，避免连续解压同一个包。按月保存 SQLite 文件的做法继续保留。日志过期后直接删除对应月份的文件，索引、详情和压缩数据会一起清掉，维护起来比较省事。效果在一组约 500 万条、日志结构重复度比较高的样本里，测试结果大概如下。存储方式占用空间SQLite 明文行存约 4.27 GB逐行 Zstd 压缩约 2.59 GB三表 JSON 区块压缩约 1.01 GB三表 MessagePack 区块压缩约 1.18 GB从压缩包里随机打开一条详情，大概需要几毫秒。逐行压缩通常只要数十微秒。区块归档省下了不少空间，打开历史详情会慢一些，平时列表查询没有受到影响。这个数据只适合做参考。日志内容越相似，区块压缩越有优势。索引数量、压缩包大小、数据库配置和机器性能都会影响测试结果。补充说明压缩包大小压缩包放得越大，压缩率通常越好，索引表分摊到每条日志的数据也越少。不过读取详情时需要解压更多内容，内存占用和归档等待时间也会跟着增加。我会先用 100…

Seven Player：Windows上播放115网盘视频的增强工具
type: item
date: 2026-06-08T16:06:00+00:00
description: seven-player 播放器使用指南源起由于国内视频平台画质和资源参差不齐，去年我就一直想用 NAS 来看剧。本打算趁双十一活动入手一套 N150 之类的全闪 NAS，结果双十一还没到，内存和硬盘价格反而飞涨，只好作罢。去年 12 月，我在网上刷到了 115 网盘 8 年会员送 40TB 空间、只要 800 块的广告，今年四月底又续了 8 年，变成了 80TB/16 年的会员（这活动已经结束了，现在买性价比不高，不用担心这是广告）。当时选 115，就是看中它空间大、看原盘不限速（我这里下载速度能跑到 130MB/s），还有云下载，对播放原盘影片来说简直不要太香。在 115 上收集了不少影片后，我先后试了网易爆米花 Windows 版和 115-Desktop 两款软件。网易爆米花 Windows 版可能是刚出不久，内置播放器体验不太好，总是出各种问题。115-Desktop 倒是能调用本地第三方播放器来放视频，但功能太多，感觉过于复杂，界面也不太喜欢，后来就放弃了。我主要使用 Windows，如果是 macOS 倒还好，有很多更优秀的播放软件。Windows 上其实也可以折腾一下，比如通过第三方软件把网盘挂载为本地磁盘，再用本地播放器打开；或者用 Alist 等项目转出 WebDAV 服务，在播放器里设置一下也能播。但我总觉得不得劲，我就想简单看个视频，要么装一套复杂的软件，要么搞一堆麻烦的操作。正好今年 AI 这么火，不如自己搓一个试试？技术选型刚好今年五一放五天假，可以大刀阔斧地试一把。先用 Codex 做了技术选型：Node.js 流派有 Electron，Go 流派有 Wails 3，Rust 流派有 Tauri 2.0。Electron 就不考虑了，太重了，我只是想做个播放器。本来最优选应该是 Tauri 2.0，Rust 又快又小，可我用 AI 写了 Demo 编译时才发现，这玩意儿需要依赖 C++ 的开发工具包，颇为麻烦（可能是 Go 的开发模式把我惯坏了，绝大多数情况不用 CGO，除了 Go 什么都不用依赖）。最后开发选了 Go 的 Wails 3，也算是回到了我的舒适区。毕竟用 Go 写了这么多年项目，还是挑自己最熟悉的语言最合适。而且 Go + Wails 3 这一套确实够用：体积不大，性能尚可，还能跨平台（虽然我并没有跨平台的需求）。前端选择了我觉得比较契合桌面端的组件库 Vuetify。它是 Material Design 风格，但又没有搞得太 Material Design。我个人认为 Material Design 好看但不实用，尤其像桌面端这样的场景，但 Vuetify 处理得很棒。至于本地数据库，这还用选？肯定是我最爱的 SQLite 了，轻巧够用。开发开发基本上是用 Codex 5.5 一把梭。Wails 我之前只是看过一点，没实际拿来开发过项目，这次选它也算一次尝试。开发的第一步是申请 115 开放平台的开发者账号，跟 115-Desktop 一样，做官方认可的第三方“正规军”。我把开发者信息提交上去后，页面显示 7 个工作日内审核。结果左等右等一个月过去了，还没通过，最后问官方，得到的答复是：审批暂停了，什么时候恢复还不一定。刚好 2 月份在网上刷到一个开源项目 webdav-115drive，它通过 Cookie 获取 115 的数据，然后转出 WebDAV 协议。于是我参考这个项目，用 Cookie 获取当前账户的文件信息，在点击播放时调用外部播放器，传入一个 WebDAV 播放地址，这样就可以用外部播放器看视频了。目前实现了文件浏览、调用本地播放器播放、云下载链接以及 BT 文件添加。浏览文件时会自动过滤文件名中的广告和技术名词，将技术名词以徽章的形式显示在文件名下方。整个应用的界面大概长这样：目前已支持 Windows 平台主流的几款播放器：首推 MPV，我感觉最好用，但对普通用户有一定门槛；也可以选择 PotPlayer。资源库？可能有网友会失望：“你不是奔着看剧去的吗，资源库呢？”资源库这个功能最开始还真规划过，但后来发现做简单容易，想做好可太难了。数据来源主要是 TMDB 和豆瓣，可大家在网上找的资源文件命名特别不规范，要实现刮削功能就得适配各种各样的情况。我尝试了两天，进展一般，所以后来就取消了这个功能。资源详情页面：你看，连国产剧都识别成这样，这能对吗？发布经过五一假期的开发，大部分功能其实已经完成了，但一直卡在等 115 网盘开放平台审核上，卡了整整一个月。现在审核暂停，那就先通过 Cookie 方式凑合着用，等以后开放了再切换到官方正规军的玩法。目前该软件已发布 1.0.0 版本，提供 Windows amd64、Linux amd64 和 Linux arm64…

CDN 盗刷也是被我遇上了
type: item
date: 2026-05-31T09:18:00+00:00
description: 心存侥幸“CDN 被盗刷”的故事，网上隔三差五就能看到——一晚上甚至几分钟，几千几万块就没了。 听多了，难免会想：“我一个博客，日访问量破百都难，谁盯得上我？” 结果今年 3 月，短短 5 分钟，我的 CDN 被恶意刷掉 1.55 TB 流量 + 661 万次 HTTPS 请求。说来也巧，去年开发 多吉云上传插件 时，我其实已经做过了时间戳防盗链功能。 但当时头像也放在 CDN 上，如果开了防盗链，别人博客上的头像就会裂开（就像下图这样）。于是线上测试没问题后，我果断……关掉了这个功能。事发3 月 12 日下午，手机突然收到多吉云的短信提醒：赶紧登录控制台一看：1.55 TB 流量。 好在之前设了风控规则，被刷 5 分钟后 CDN 服务自动暂停——要不是这个“封顶”，损失还会大得多。处理1. 封禁 IP 段 在后台查到攻击 IP 全是境外地址：美国、日本、韩国、新加坡等。 用 AI 整理后，在多吉云的访问控制策略里，把这些 IP 段一次性封禁。2. 重新开启 URL 鉴权（时间戳防盗链） 之前关掉的防盗链功能，这次老老实实开了回来。 如果当初没关，这次事件大概率可以避免——当然，也就少了这趟“宝贵的教训”。3. 设定风控策略 结合博客正常的访问量、资源大小和数量，重新设置了：每秒 QPS / IP 限制每小时封顶流量盗刷时携带的特定 UA 直接限制后续算了一下，这次在多吉云的实际损失大约 193 元。多吉云（按量计费）流量：1.55 TB = 1587.2 GB × 0.11 元/GB = 174.59 元请求：(660.54 万 - 200 万) = 460.54 万次 × 0.04 元/万次 = 18.42 元合计：193.01 元我又好奇算了一下：如果去年没换到多吉云，还在用又拍云（而且同样没开防盗链），会是什么代价？又拍云（按量计费）流量：1.55 TB = 1587.2 GB × 0.29 元/GB = 460.29 元请求：660.54 万次 × 0.05 元/万次 = 33.03 元合计：493.32 元多吉云可以买流量包和 HTTPS 包抵扣，最后实际只付了 179 元左右，比又拍云便宜了 300 多。一点感悟老话说得好：人教人，教不会；事教人，一次就够了。无论是运维还是开发，安全这件事，永远不能心存侥幸。 所谓的“事前防御”，不是摆设，而是你真正被刷了一次之后，才明白它是多么值钱的东西。尽量做到：事故之前，防患于未然；事故之后，不留下一次机会。

多用户 PassKey 认证插件
type: item
date: 2026-03-08T09:15:00+00:00
description: 出于安全考虑，去年开发了一个 OTP 多因素认证插件，后面就一直想着开发通行密钥插件，这样就不需要输入密码了，点两下就能登录进来，于是就花了两个小时使用 GPT-5.3-Codx 写了这个插件，不得不说 AI 还是太好用了。功能支持多用户的 PassKey 插件（通行密钥、WebAuthn 说的都是它）,支持 Typecho 1.2.0 + 的版本。支持自定义通行密钥名称一个用户支持创建多个通行密钥使用安装插件后，去个人设置页面绑定一个通行密钥通行密钥绑定后 就可以在登录时使用下载去 CNB 下载这个插件https://cnb.cool/dbkuaizi/typecho/passkey/-/releases或者直接下载代码仓库：https://cnb.cool/dbkuaizi/typecho/passkey注意：releases 发布版本 中的 zip 包已经包含 PassKey 插件目录，如果是直接下载的代码仓库，需要自行创建 usr/plugins/PassKey 目录

博客五年
type: item
date: 2025-12-30T15:38:00+00:00
description: 自 2020 年 11 月上线个人博客至今，一眨眼已经五年过去了，一晃时间也不短了，总觉得需要发一篇博文记录一下这个不平凡的时长。但人总归是喜好偷懒的，于是就拖到了 12 月 30 日，也不知道这篇博文今天能写完不，还是要拖到 2026 年 1 月份。更新频率当初上线博客的时候，计划着一个月最少一篇博文来着，刚开始更新倒也是积极，几乎每个月都有一到三篇的博文更新，而且都是笔记向每篇都是过万字的，信息密度还蛮高的。24年、25年 肉眼可见的懒了很多，学习向的博客 今年只更新了一篇 《极简 Docker 入门笔记》，尤其是 4 ~ 7 月 干脆直接断更四个月（虽然也没什么人看）。25 年没有输出较为深度的内容，从侧面印证今年的我也没有太多长进（技术方向）。到了年底想起这件事，总感觉自己今年荒废了很多，有点像温水煮懒蛤蟆，躺平固然是舒服的，但退步也是明显的（在程序员这个行业里，如果一段时间没有太大的进步，其实也是一种退步）。AI 变革与迷茫抛开懒不说，还有一个导致更新懈怠的主观因素，其实是 AI 的飞速发展。今年每次打开 Vnote （笔记软件）想学点东西的时候，心里总是在问自己：「现在 AI 这么厉害，写这些东西还有意义吗」。每次想到这里就没有写下的动力了（其实我自己有个选题库，真要说写文章的话，也不是没有什么东西可写）。写作的本意不过最近我也释然了，回看的当初开始写博文的本意，也并非是奢求有什么阅读量或者名气。只是想有个地方分享我输出的内容，那么我为什么要输出内容呢？我写作的起源来自 https://learnku.com/cs/t/29327 这篇帖子，我印象最深的一句话：「一件事情你不能讲清楚，十有八九你还没有完全理解」。后面发现确实是这样，然后在学习新东西的时候就尝试先学一遍，然后使用自己的方式表达出来，在尝试表达的过程中发现会有很多不明白的地方。所以好奇心就会驱使自己去弄明白这个点，而这个好奇心驱使的对未知知识点的探索欲，最终也会让自己的知识逐渐的丰富起来，甚至超过了最开始要输出的这个技术点本身的知识范畴。求实博客创建的前几年，不得不承认也是我个人技术成长最快的几年。当我写一篇文章的时候会有一种责任感：写下的每一个字都保证尽可能的准确无误，甚至有的时候为了验证一两句话的内容是否确实如此，往往会花费半个小时 甚至数天的休息时间去弄个水落石出。「实践是检验真理的唯一标准」，只有当自己亲手尝试过、确认这个技术方案能行得通，才可以心安理得的写到文章中。后续捋清了博客写作的出发点，希望来年更新的质量和频率也能恢复到之前的水平。其实这个标题我想叫做《写作五年》，但自认为这些年输出的内容撑不起这么大的标题，干脆就叫博客五年吧。

1Panel 部署 FastAdmin 管理端访问 302 解决方案
type: item
date: 2025-12-28T12:52:23+00:00
description: 最近使用 1Panel 面板部署 FastAdmin 项目用于测试，站点的伪静态选择 thinkphp，在部署完成后发现用户端可以正常访问，而管理端则会无限制重定向到 login/index，最终提示 “重定向次数过多...” 如下图所示：经过排查 发现问题出现在 1Panel 自带的 fastcgi-php.conf 上这个文件上，如图 21 行:解决方案是注释掉这一行，然后使用 fastadmin 官方推荐的 fastcgi 配置，代码如下：location ~ [^/]\.php(/|$) { fastcgi_pass 127.0.0.1:9000; # include fastcgi-php.conf; # 注释掉这一行或者直接复制我的示例代码 include fastcgi_params; fastcgi_index index.php; fastcgi_split_path_info ^((?U).+\.php)(/?.+)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }保存修改的配置后，fastadmin 管理端入口即可正常访问：使用版本为 1Panel 2.0.16, OpenResty 版本为 1.27.1.2-2-3-focal

解析到本地127的神奇域名
type: item
date: 2025-11-11T14:36:00+00:00
description: 前言作为一名 Web 开发者，我的日常工作就是在本地进行开发，实现各种功能。过去几年，我一直使用 127.0.0.1 作为本地服务的访问地址。当需要同时开发多个项目时，我会用不同端口来区分，例如：项目A：127.0.0.1:8080项目B：127.0.0.1:8081…以此类推当然，也可以用 localhost 代替 127.0.0.1。前段时间我在想，有没有办法让本地访问的地址看起来更“真实”一点？我知道可以通过配置 HOSTS 文件将任意域名解析到本地，但有没有本身就专门设计用于解析到本地的域名呢？最初，我尝试将 local.dbkuaizi.com 及其子域名解析到 127.0.0.1，这样访问 local.dbkuaizi.com 或 test.local.dbkuaizi.com 都能指向本地站点。但用了几天后发现一个问题：域名太长，输入不方便。于是我又想，不如自己注册一个短域名？但在域名注册网站找了半天，发现两位的短域名要么已被注册，要么价格不菲。后来我在网上搜索了一番，发现确实存在一些专门解析到本地的域名。现将整理结果汇总如下：本地解析域名localhostIETF（互联网工程任务组）在 RFC 6761 中明确规定：localhost 和 *.localhost 应始终解析为本地回环地址（即 127.0.0.1）。因此，以下地址都会被解析到 127.0.0.1，满足各种使用场景：域名说明http://localhost顶级域名http://dbkuaizi.localhost二级域名http://dbkuaizi.test.localhost三级域名需要注意的是，.localhost 解析到本地是应用层规范，Safari、Chrome、CURL 等主流工具都支持，但并非所有应用都遵循。由于这是官方硬性规定，该域名非常稳定且通用性强，在绝大多数情况下推荐使用。*.lvh.me该域名的持有者是 @levicook。自 2010 年起，该域名及其泛域名均解析到 127.0.0.1。2021 年 6 月，作者因认为使用人数不多、不愿继续承担域名费用而停止续费。随后，越来越多网友在其推特下留言表示愿意捐助，希望保留该域名。最终 @levicook 恢复了续费，并开启了捐款通道（但目前该捐款地址已返回 403）。以下地址都会被解析到 127.0.0.1：域名说明http://lvh.me顶级域名http://dbkuaizi.lvh.me二级域名http://dbkuaizi.test.lvh.me三级域名这是目前最短的可用域名，也是我日常开发的选择，体验良好。*.fbi.com这个域名…很有意思，虽然不清楚所有者是谁，但至少从 2022 年至今，它一直解析到本地回环地址。域名说明http://fbi.com顶级域名http://demo.fbi.com二级域名http://demo.test.fbi.com三级域名由于所有者不明，不推荐用于正式开发，当作一个趣闻即可。*.nip.ionip.io 和 sslip.io 是一种 DNS 服务，当查询包含嵌入 IP 地址的主机名时，会将域名解析为对应 IP。这两个服务已稳定运行十多年，每秒处理约 5000 次请求，甚至被 Google 引用在 Kubernetes 文档 中。举例说明：域名解析结果http://127.0.0.1.nip.io127.0.0.1http://app.192.168.0.10.nip.io192.168.0.10http://7f000101.nip.io127.0.0.1（十六进制表示）http://127-0-0-1.nip.io127.0.0.1（带破折号格式）需要注意的是，nip.io 和 sslip.io 本身不解析到 127.0.0.1。虽然该服务稳定，但我个人不太喜欢，因为域名中必须包含 IP，与我最初的目标不符。local.gd这是 nip.io 服务的一部分，该域名及其子域名均解析到 127.0.0.1，用法与其他本地域名相同：域名说明http://local.gd顶级域名http://dbkuaizi.local.gd二级域名http://dbkuaizi.test.local.gd三级域名local.dbkuaizi.com这是我个人持有的域名。对我而言，其稳定性仅次于 localhost。如果你有需要，也可以直接使用（至少在可预见的未来，该域名会持续解析到 127.0.0.1）。域名说明http://local.dbkuaizi.com二级域名http://demo.local.dbkuaizi.com三级域名http://demo.test.local.dbkuaizi.com四级域名其他我还收集了其他一些解析到 127…

Typecho 多吉云上传插件
type: item
date: 2025-10-16T13:19:00+00:00
description: 去年了解到多吉云这个CDN 厂商，感觉性价比很高，并且网友使用后的评价也很不错 @二丫讲梵。然后看了一眼现在使用的又拍云 CDN，还有一些余额没有用完。想着还是等用完了这些余额，再迁移到多吉云上去。直到今年十月前后，终于快用完了。但是迁移时发现 Typecho 没有支持多吉云的插件，有一个支持 S3 存储协议的插件，但是阅读完多吉云文档后发现，多吉云的 S3 文档与标准版 S3 规范有一些差异，不能直接使用，所以就有了这个插件。DogeUpload 插件Typecho 多吉云附件上传插件, 版本要求 Typecho >= 1.2.0 版本。直接上传附件到多吉云，且支持更新和删除附件。自定义加速域名。多吉云图片处理后缀支持。时间戳防盗链，支持自定义 Token 有效期。历史资源处理 （将 博客域名自动替换成 CDN 域名）。超轻量级设计，贯彻 Typecho 极简设计理念，插件体积仅 32 KB。代码结构简单、注释完善、使用命名空间，适合作为插件开发参考。2026-01-26 更新 插件 1.0.1 适配 Typecho 1.3.0 版本，解决因 Upload 基类传参调整导致上传报 “Server Error” 的问题，感谢 @曾墨 的反馈下载地址：https://cnb.cool/dbkuaizi/typecho/DogeUpload/-/releases/tag/1.0.1下载 "DogeUpload.zip"安装方式：将压缩包中的文件夹 DogeUpload 上传至 Typecho 插件目录 typecho/usr/plugins 下 并在插件面板启用。配置页预览更高性价比的选择博客建立后一直使用又拍云的CDN 服务，去年发现了多吉云这个CDN厂商，了解后得知 多吉云其实是一个 "二道贩子"，他们底层使用 阿里云、腾讯云等国内大厂的 CDN 节点作为基础支撑，得益于量大的原因，他们可以给出比直接购买阿里云、腾讯云CDN 更加实惠的价格。因为我前期一直在使用 又拍云，所以对又拍云的计费规则比较了解，这里就对比一下 又拍云 和 多吉云的成本差异：注：这里以 2025年10月15日 各厂商官网价格为基础作比较，若需核算成本，请以官网价格为准。又拍云云存储：0.0043 元 / GB / 天 (注：可以以当天流量使用情况进行抵扣)CDN 国内流量：0.29 元 / GBHTTPS 请求：0.05 元 / 万次HTTPS 证书免费更新多吉云云存储：0.003 元 / GB / 日CDN 国内流量：0.11 元 / GB （每月前 20 GB 免费）HTTPS 请求：0.04 元 / 万次（每月前 200W 次免费，日流量或云存储超过2TB 可联系客服免除 HTTPS 费用）HTTPS 证书续订目前免费，但官方说后期会收费，默认证书厂商 1元/次，指定厂商2元/次（后面有免费方案）我这里以 月流量 100 GB、云存储 10 GB、HTTPS 月请求数量 60W 来计算两家使用成本的差异（注：如果考虑购买资源包，成本会更低）。费用项目又拍云多吉云备注1. 云存储费用 - 计算公式10GB × 0.0043元/天 × 30天10GB × 0.003元/天 × 30天 - 小计1.29 元0.9 元 2. CDN流量费用 - 计算公式100GB × 0.29元/GB(100GB - 20GB) × 0.11元/GB多吉云每月前20GB免费- 小计29 元8.8 元 3. HTTPS请求费用 - 计算公式60万次 × 0.05元/万次0 元多吉云每月前200万次免费，60万次在免费额度内- 小计3 元0 元 4. 费用抵扣 - 规则存储费可抵扣流量费无额外抵扣规则又拍云特色- 抵扣金额1.29 元 月度最终成本 - 计算公式(CDN费 - 抵扣额) + HTTPS费存储费 + CDN费 + HTTPS费 - 总计(29 - 1.29) + 3 = 30.71 元0.9 + 8.8 + 0 = 9.7 元 大家可以参考这个费用情况核算一下，更换为多吉云后可节省多少钱，基本上都能节省 2/3 左右。HTTPS 证书更新多吉云的 CDN HTTPS 证书与又拍云有些差异，又拍云提供免费与收费的证书，且免费的证书可以免费自动续签。多吉云本身提供免费的 HTTPS 证书，但自动申请证书的服务是收费的（更新成功 默认厂商 1元/次，指定厂商 2元/次），但目前处于公测阶段，限时免费 ，具体可见官方文档： https://docs.dogecloud.com/cdn/manual-config-auto-cert。 现阶段证书是免费更新的，但官方文档中说后续肯定是会收费的，那么每年的成本是多少？以多吉云证书自动更新规则来计算，证书有效期 90 天，到期…

极简 Docker 入门笔记
type: item
date: 2025-09-18T14:06:00+00:00
description: 前言：本篇笔记内容来自于 B 站 《40分钟的Docker实战攻略，一期视频精通Docker》视频，博主 @技术爬爬虾，视频地址：https://www.bilibili.com/video/BV1THKyzBER6。Docker 核心概念Docker 容器Docker 简单来说就是通过容器化技术给应用程序封装一个独立的运行环境，每个运行环境就是一个容器，运行容器的计算机被称为 宿主机。与虚拟机最大的区别是：Docker 容器共享同一个系统内核，而每个虚拟机都包含一个完整的系统内核。所以 Docker 容器比虚拟机更轻量，启动速度更快。Docker 镜像镜像可以理解为是一个特殊的压缩包，容器就像是通过压缩包解压（创建）出来的文件，我们可以使用同一个压缩包，解压出很多份相同的文件，也可以将这个压缩包分享给他人，得到和我们一样的文件。这里所说的“文件”，就是上面提到的容器。我们也可以通过修改容器，并生成自己特定的 Docker 镜像，并将这些镜像分享给他人，其他人可以通过镜像，创建出和我们一样的容器环境。Docker 仓库Docker 仓库就是我们用来存储、分享镜像的地方。所有人都可以把自己的镜像上传到仓库里面，其他人就可以下载镜像并使用。Docker 的官方仓库是 Docker Hub (https://hub.docker.com)Docker 技术原理Docker 利用了 Linux 的两大原生功能，实现容器化：Cgroups 用来限制和隔离进程的资源使用。可以为每个容器设定 CPU、内存、网络带宽等资源的使用上限，确保容器的内存消耗不会影响到宿主机。Namespaces 用于隔离进程的资源视图，使得容器只能看到自己内部的进程ID、网络资源、文件目录，看不到宿主机的。容器本质上还是一个特殊的进程，但是当我们进入容器内部时，看起来就像是一个独立的操作系统Docker 安装Docker 是基于 Linux 的容器化技术，Windows 和 Mac 需要虚拟化一个 Linux 的子系统。所以 Docker最好的使用方式是使用 Linux系统的宿主机。Linux 系统Linux 系统可以通过包管理器安装 Docker，例如 Redhat 系可以使用 yum install docker 安装。 Alpine Linux 可以通过 apk add docker 安装Windows 安装打开 “Windows 功能”, 勾选上 Virtual Machine Paftform（虚拟机平台）、适用于 Linux 的 Windows 子系统，并重启电脑。管理员打开命令提示符，安装 wsl2wsl --set-default-version 2 wsl --update --web-download去 Docker 官网 或者 https://github.com/tech-shrimp/docker_installer/releases 下载符合自己系统的 Docker Desktop 安装包，并进行安装，安装成功后 可以在终端尝试一下：PS C:\Users\Administrator> docker --version Docker version 28.3.3, build 980b856在使用的过程中 Docker Desktop 需要一直开着，否则执行命令会出现这个报错。PS C:\Users\Administrator> docker ps error during connect: Get "http://%2F%2F.%2Fpipe%2FdockerDesktopLinuxEngine/v1.51/containers/json": open //./pipe/dockerDesktopLinuxEngine: The system cannot find the file specified.Mac 安装直接在 Docker 官网下载安装包 安装就行。Docker 镜像下载镜像Docker Pull 命令用来从仓库下载镜像。docker pull docker.io/library/nginx:latest一个Docker 镜像下载地址包含 4 部分内容：docker.io: registry：仓库地址/注册表，如果是 Docker 官方仓库，则可以省略这个地址。library: 命名空间（镜像作者），为了防止不同用户上传同一个名字的镜像 发生冲突。“library" 是docker 官方仓库的命名空间，这个空间下的所有镜像都是由 Docker 官方维护。如果是官方的命名空间 则可以省略不写nginx: 镜像名latest: 标签名、版本号。写 "latest" 或者不写 表示获取最新版本的镜像。镜像库repository…