英语/日语翻译：沉浸式翻译

我的日常要看到很多英文文章和网站，因此，可以借助沉浸式翻译，帮助我快速翻译多种语言为中文，从而降低我在阅读不同语言内容的障碍。

快速搜索：超级搜索

超级搜索支持我快速的选中词汇并进行搜索，对于一些特定的场景下，会非常有帮助。比如我在浏览网页的时候，发现了一部电影，想快速在豆瓣电影中找到并标记，就可以借助超级搜索，配置一个搜索关键词来实现。

SEO 检查器：AITDK

AI TDK 是我用来检查自己的网页是否完成了一些基本的 SEO 设置的工具。当我上线了一个新的网站后，就会打开 AITDK，然后查看哪里的信息还不完整，需要补充的。就可以继续去补充相应的内容。

JSON 查看：JSON Viewer

在开发的时候，经常会有要查看服务端返回的 JSON 的情况， 借助 JSON Viewer 可以将不容易看明白的 JSON 给格式化了，方便你快速定位要看的 JSON。

广告拦截：AdGuard

广告拦截我选择了 AdGuard，有了它，我看 Youtube 再也没有广告了。。。

复制为 Markdown：Copy as Markdown

因为经常要将部分内容复制为 Markdown，方便在我的其他工具中使用，所以我安装了这个 Copy as Markdown 插件，方便自己随意复制。

页面增强：篡改猴

当我需要对一些网页做一些快速的改造，但同时又不想写成 Chrome 插件的时候，就会选择写成油猴脚本，然后放在篡改猴里来用，非常方便。

灵感记录：Memos

我自己部署了一个 Memos ，用于记录自己的灵感和想法。因此，我使用了一个 Chrome 插件，来方便我记录。

漏洞风险：可以在其他应用借助小宇宙端内跳转任何网页。

此文章发布前，小宇宙已经修复了这个问题，所以你们可能不能复现这个问题了。

先看漏洞效果，这个漏洞的问题是你可以在小宇宙里跳转到任何网站，甚至是 PornHub。不过这个 Bug 不重要，重要的是发现 Bug 的过程。

0. 背景

在一天晚上，我在和朋友聊小宇宙的 URL Scheme，想要做个功能，可以实现一键打开小宇宙的节目页面。但卡在我面前的是，我不知道小宇宙的 URL Scheme 到底是什么。于是便开始了我的 Hack 之旅，也就找到了小宇宙的这个安全漏洞。

1. 找到小宇宙的 URL Scheme

由于 Scheme 是在 App 中定义的，所以当我想到要找 Scheme 之后，第一反应的是去拿 iOS App 的 Info.plist（因为 iOS 是将 Scheme 定义在 info.plist 当中）。

过去需要通过 IPA 备份、越狱等方式来获取到这个文件，不过得益于 M 系列支持在 macOS 上运行的原因，现在 IPA 的获得变得非常的简单。 先在 App Store 安装小宇宙，并在「应用程序」中找到小宇宙。

然后右键点击小宇宙，点击「显示包内容」

然后看到这样的内容，WrappedBundle 是一个假的应用程序，所以继续点击 Wrapper 往里跳转。

然后会发现里面还有一个 Podcast 应用，这个才是真正的小宇宙的 IPA 包。然后继续点击「显示包内容」

在包内容当中可以看到 info.plist 文件，使用 Xcode 或者 VSCode 打开 info.plist 文件。

在 info.plist 文件中，搜索 CFBundleURLSchemes ，找到了小宇宙的 URL Scheme（里面有很多个，但很多都是其他应用的，试一下就可以发现）：cosmos://。

2. 找到 URL Scheme 能够打开的页面

找到了 URL Scheme，只能通过 cosmos:// 打开应用首页，无法满足我的需求，于是开始继续寻找可能的 URL Scheme 。一般来说，这个时候就只能继续反编译 IPA 包或者 APK 包了。不过对于我来说，这些不是一个好的选项（成本太高）。

然后想到，小宇宙的网页似乎是提供了打开客户端的能力，所以可以从网页版找到突破口。通过简单的搜索，果然让我在网页前端找到了突破口。找到了 7 个 Scheme 。

当然，中间存在一些重复的 Scheme。所以最终梳理出来的 Scheme URL：

• cosmos://page.cos/discover:打开发现页
• cosmos://page.cos/shownotes/EPISODE_ID：打开节目的 Shownote 页面
• cosmos://page.cos/episode/EPISODE_ID：打开节目的详情页
• cosmos://page.cos/webView?url=：意义不明，看起来像是打开一个特定的 URL
• cosmos://page.cos/web?url=:意义不明，看起来像是打开一个特定的 URL

3. 发现问题 URL Scheme

前面的三个很正常，但后面的两个带 URL 的引起我的注意 —— as a Hacker，你知道的，任何一个可能的输入框都可能成为我们的注入点，于是乎，我就构建了一个链接，来打开我的 Blog

cosmos://page.cos/web?url=https%3A%2F%2Fwww.ixiqin.com

将这个链接使用 Safari 打开，就会自动唤起小宇宙，并打开我的播客。

至此，我发现了小宇宙这个跳转注入漏洞，并快速将其反馈给小宇宙官方同学。

复盘：如何规避这样的问题

在这个 Case 当中，小宇宙因为没有设置 URL 跳转的白名单，导致实际上出现了跳转恶意网站的风险。理论上，作为应用提供商，出于安全合规的视角，最好是控制 URL 跳转的域名和空间，避免被恶意滥用。

或者也可以参考我们现在见到的很多网站，在外部跳转时加一个风险提醒。

如果在这个 Case 当中，小宇宙在一开始就限制了可以打开有限域名，那也不会出现如今我这次的漏洞问题。

这个问题风险大么？

取决于如何定义和如何使用。如果只是跳转一些常规网站，自然是风险不大的。但如果不受限制的，比如跳转到一些诈骗网站，可能风险就是大的。

前言

很久很久以前，久到我都已经快忘记了，只记得那是一个夏天，我刚搭建完个人网站并尝试接入 Google AdSense ，当时还写过一篇关于 个人网站接入 Google AdSense 心得 的文章 ，今天终于收到 Google 邮寄过来的 PIN 码了。

就一张对折密封起来的纸，皱皱巴巴的很简陋，感觉还没普通信封靠谱，难怪很多过来人会说容易寄丢呢？

好在我是顺利收到了，这篇文章就简单记录一下 PIN 码的认证过程吧！

[...]

前言

你们的博客网站有隔三岔五就收到这么多的垃圾评论吗？

这里所说的垃圾评论专指机器人通过自动化脚本或直接调用接口发起的评论，由于评论不经过前端页面，因此并不会给网站带来任何流量。说到垃圾评论，真的是非常恶心，如果仅仅是偶尔来一两条我都所谓，大不了隔段时间集中删一次，但实在架不住它短时间内狂轰乱炸，尤其是像我这样接入了邮件通知的，一旦开始，手机就响个不停，烦得要死。

[...]

前言

通过上一篇文章 如何基于 Typecho 实现中英双语网站（上），我们已经把 中英双语网站 的基本框架搭建好了。实际上很多支持多语言的网站，也就这样了，例如著名的 YouTube 就是如此，至于具体的内容显示什么语言，则完全是由内容的创作者决定的。

上一篇文章也提到了，Typecho 其实并不是很适合做多语言网站，因为，一方面需要修改源码，另一方面，开发一个不同国家的人都来发布创作内容的网站，想想也不是个人应该考虑的。 Typecho 还是更适合作者自己创作，然后向用户展示的场景，这时如果要实现多语言，就不得不将文章的内容也进行翻译了。

[...]

前言

我在前面谈 Google Adsense 的文章（如 一组数据让大家直观感受一下出海的重要性）中多次提到过，要想让网站中的 Google Adsense 有更高的收益，就一定要考虑出海，而出海就离不开多语言这个话题。理论上网站应该支持尽可能多的语言，但每增加一种语言，网站的复杂度和维护难度都会成倍增加，因此，对我们而言，性价比最高、最常用的无疑还是 中英双语网站。

比较遗憾的是，我查过一些资料，也读过 Typecho 的源码，并没有找到一种简单直接的多语言方案（直接部署并维护多个站点除外）。虽然 Typecho 本身就提供了多语言翻译功能，但需要管理员在后台切换，并且切换后会全局生效。也就是说， Typecho 并不能满足 内地显示中文，海外显示英文 这种看似简单的需求，其本质还是仅支持单一语言。换句话说，要想实现常规意义上的多语言网站，就必须修改 Typecho 源码，至少我暂时还没有找到仅扩展 插件 或 主题 就能同时支持多语言的方案。

[...]

前言

通过前面三篇文章，我们已经把个人网站接入支付宝支付时需要做的准备工作全部准备就绪了，如果还不清楚，可以先行了解一下：

1. 独立开发如何接入支付宝和微信支付
2. 独立开发者应该如何注册个体工商户
3. 为个人网站接入支付功能 - 支付宝准备篇

接下来就该正式写代码实现了，但考虑再三之后，我还是决定不过多介绍开发细节，因为这涉及到 沙箱环境 和 SDK 的使用，感觉解释起来会比较墨迹，而且想来有开发需求的人看了上面的文章之后，再自行参考官方API开发文档，思路可能会更清晰，毕竟官方文档支持在线调试，效果也更直观。
看过我往期文章的应该知道，我的网站都是基于 PHP 的 Typecho 二次开发的，因此，我这里就以 PHP 为例，简单梳理一下 电脑网站支付 的接入要点吧。

[...]

Advanced Media Offloader 提供了 Bulk Offload 功能，可以实现将历史的文件上传到对象存储中，从而降低本地的存储压力，使得站点自身变得无状态。

但其默认的 Bulk Offload 功能每次只能加载 50 个图片，如果附件太多，则需要点击 N 次，十分麻烦。

不过，可以通过简单的修改，来实现一次上传，将多个图片进行 Offload。

在 WordPress 后台的插件管理器中，找到 Advanced Media Offloader 插件，并将includes/BulkOffloadHandler.php文件打开，找到其中的 get_unoffloaded_attachments 函数，修改函数定义中的 $batch_size = 50 为你想要的大小即可使其一次批量加载多个文件了。

修改后效果：

前言

通过前面两篇文章：独立开发如何接入支付宝和微信支付 和 独立开发者应该如何注册个体工商户，我们知道，个人开发者也是可以比较简单、且体面的为自己的产品接入支付功能的。

众所周知，对接支付相对而言还是比较麻烦且敏感的，但无论是开发网站还是APP，只要涉及到支付，就很难绕开这个话题。而且不同的业务场景、产品形态，需要对接的支付方式也不太一样。不仅如此，在国内，支付至少要支持支付宝和微信两种方式，其复杂性就再一次翻倍了。

因此，接下来我将以我自己的网站为例，分两篇文章介绍一下我是如何以尽可能简单的方式接入支付宝支付的，微信支付后面再说。

当然，思路仅作参考，正式对接起来，还是应该多多查阅官方文档，官方文档才是最靠谱的。

[...]

在 使用 Caddy 处理 WordPress 当中，我提到在用 Caddy 处理 WordPress，且为了性能做了很多优化。

我的博客经历了三重优化：最基础的 PHP OpCache + Redis 数据查询缓存 + 静态化缓存。

其中一个比较有效的，便是在整个站点上加入静态化缓存，绝大多数游客看到的其实是预先生成好的静态页面，从而减少了数据库加载、渲染、计算的成本。

而想要实现静态化，则需要借助于 Cache Enabler 插件和 Caddy 配置来完成。

安装插件并启用

安装 Cache Enabler 插件，并启用插件，启用后，在后台设置中，配置过期时间和对应的清除策略，并保存。这个时候，Cache Enabler 就会自动帮你去生成不同的页面了。

配置 Caddy 路由转发

首先，你应该在你的 php_fastcgi unix//run/php/php-fpm.sock 前面加入缓存的代码并重启 Caddy，具体如下

缓存配置如下

     @cache {
		not header_regexp Cookie "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in"
		not path_regexp "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(index)?.xml|[a-z0-9-]+-sitemap([0-9]+)?.xml)"
		not method POST
		not expression {query} != ''
    }

    route @cache {
        try_files /wp-content/cache/cache-enabler/{host}{uri}/https-index.html /wp-content/cache/cache-enabler/{host}{uri}/index.html {path} {path}/index.php?{query}
    }
       

这部分配置先定义了一个 @cache 块，用于后续判断，并在其中加入了多种条件判断，说明了不使用缓存的情况：

• 如果用户有以下 Cookie，就不使用缓存：
  • comment_author（评论作者）
  • wordpress_[a-f0-9]+ （WordPress 的会话 Cookie）
  • wp-postpass（密码保护文章的 Cookie）
  • wordpress_logged_in（登录状态的 Cookie）
• 如果当前请求命中了以下路径则不缓存
  • /wp-admin/（后台管理页面）
  • /xmlrpc.php（XML-RPC 接口）
  • 所有 wp-*.php 文件（WordPress 系统文件）
  • /feed/（RSS 订阅）
  • sitemap 相关文件
• POST 请求不缓存（比如评论）
• 带查询参数的缓存不请求。

随后，通过 route @cache 定义了命中缓存部分的查找顺序：

1. 先找 HTTPS 版本的缓存：/wp-content/cache/cache-enabler/{host}{uri}/https-index.html
2. 再找普通缓存：/wp-content/cache/cache-enabler/{host}{uri}/index.html
3. 如果找不到缓存，就尝试原始路径：{path}
4. 最后尝试 PHP 文件：{path}/index.php?{query}

查看效果

打开一个无痕窗口，访问你的网站，如果在 html 底部看到 <!-- Cache Enabler by KeyCDN @ Sat, 04 Jan 2025 03:05:34 GMT (https-index.html) --> ，则说明你已经成功启用静态化缓存了！

参考资料

• 如果你使用 WP Supercache 、 WP Rocket、WP Fastest cache、W3 Total Cache，则可以参考 https://caddy.community/t/example-configure-wordpress-with-a-static-cache/8215 进行相关配置。

在用了很久的 Docker 托管 WordPress 后， 近期我把 Blog 迁移到了腾讯云的香港轻量云主机上，以获得更快的访问体验。在这次迁移后，出于 Hack 方便的目的，我将 Nginx 替换成了 Caddy。你目前访问的站点便是一个基于 Caddy 托管的 WordPress 站点。

安装 Caddy

安装 Caddy 的过程不需要太过赘述，遵循 Caddy 官方安装文档当中的指南安装即可。

安装 PHP

完成了 Caddy 的安装后，则是安装 PHP，这里我使用的是 ondrej 维护的仓库

sudo add-apt-repository ppa:ondrej/php
sudo apt update

执行上述命令安装 PPA 仓库，就可以继续执行 apt install php 来安装 php & 对应的版本。此外，记得安装相关的依赖包

apt-get install php-fpm php-mysql php-curl php-gd php-mbstring php-common php-xml php-xmlrpc -y

配置 Caddy

完成安装后，就可以正常来配置 Caddy 。得益于社区的集成和 Caddy 官方的支持，Caddy 配置 WordPress 的支持非常简单，可以直接使用 Caddyfile 格式来撰写。

example.ixiqin.com { # 这个配置是给 example.ixiqin.com

    root * /data/caddy/example.ixiqin.com # 我的网站文件都放在 /data/caddy/xxx 下，/data 是我挂载的数据盘

    log { #日志配置
        output file /var/log/caddy/example.ixiqin.com.log  # 日志路径
        format console # 日志格式
    }

    request_body { # 请求体大小
        max_size 20MB # 最大 20MB
    }

    encode zstd gzip # 支持 gzip 和 zstd 压缩
    file_server # 直接提供静态文件（比如图片啥的）
    php_fastcgi unix//run/php/php-fpm.sock # 使用 php_fastcgi 调用 php-fpm 来处理动态 php 文件。
}

只需要这样的配置，你就可以完成一个最基础的 WordPress 的站点的配置。

其他配置

对静态文件提供单独的 404 返回

按照上面的配置，其实所有的请求都会转发给 php-fpm 来处理，从而造成额外的 PHP 资源浪费。因此，可以在配置当中加入如下代码，来让 Caddy 直接返回，从而避免对 PHP 性能的浪费。

@static_404 {  
  path_regexp \.(jpg|jpeg|png|webp|gif|avif|ico|svg|css|js|gz|eot|ttf|otf|woff|woff2|pdf)$  
  not file  
}  

respond @static_404 "Not Found" 404 {  
  close  
}

配置缓存头

除了静态文件的 404 处理，你还可以在 Caddy 当中配置静态文件的缓存，从而让浏览器更多的应用缓存，减少服务器的流量，提升加载速度。

@static {  
  path_regexp \.(jpg|jpeg|png|webp|gif|avif|ico|svg|css|js|gz|eot|ttf|otf|woff|woff2|pdf)$  
}  
header @static Cache-Control "max-age=31536000,public,immutable"

前言

在上一篇文章 独立开发如何接入支付宝和微信支付 中讲到了为什么独立开发者应该注册一个个体工商户。总结来说，最主要的目的就是 为了以最简单直接、且正规的手段，解决个人开发线上支付的问题。

考虑到注册个体户流程比较简单，而且不同地区注册方式又都略有差异，本来不打算写这篇文章的，但为了确保内容的完整性，并且也考虑到很多个人开发者可能跟我之前一样，并没有了解过个体工商户的注册流程，所以，最后还是决定以自己为例，简单介绍一下吧！

[...]

前言

无论是开发网站、APP、小程序、游戏，还是一些其它类型的应用，支付都是一个十分重要的环节，但众所周知，对于个人开发者而言，这个环节却并不怎么友好，甚至可以说是一只拦路虎。这次我也花了不少时间查阅资料，并且也阅读了大量支付宝和微信的官方文档，最终确定了一条相对而言比较靠谱的方案 --- 个体工商户。

[...]

前面有朋友问，我博客评论中的外链跳转过渡页是如何实现的？其实，在 本博客的源码 中就可以很容易找到具体的实现代码。不过，为了方便理解，我还是简单梳理一下实现思路。

实际效果

先看看效果图：

上图是点击评论者头像后跳转的页面，然后点击“继续访问”就可以打开目标网站了，当然，这需要评论者在评论时填写网址才行。

该页面比较简单，是模仿“知乎”实现的，网址路径中也用到了一个 target 参数，这个比较关键，后面会多次用到，接下来看一下详细的实现过程。

[...]

我写博客经历过两个阶段 ：

1. 2012 ～ 2014 年：买虚拟主机、云主机，折腾性能和技术。在这个阶段，我的博客也经历过几轮变迁，也因为我自己没做好生产环境和测试环境的分离，导致数据丢了不少。目前的博客只能回溯到 2016 年便是因此。
2. 2016 ～ 至今：不再折腾博客，开始专注于内容写作，并且保持每年都有更新，做一个活博客。

写了十年，我也算是没少搞和 WordPress 相关的事情，不过，时间久了，脑子里那些工程师的想法，难免重新冒出来 —— 我是不是应该自己写一个 Blog 系统。对于曾经的我来说，可能是不容易的，我并没有那么丰富的开发经验。但对于如今的我来说，确实是不那么困难的事情。

不过，写总是要有个目的和收益评估，不能「为了写而写」，而是应该有一个明确的目的，评估 ROI。

我为什么想写？

• 觉得 WordPress 还是太臃肿，有不少我用不上的能力。
  • 那么我自己的 Blog 系统应该有一个明确的 Feature List。这样才能避免需求无限的膨胀。
• 我的需求已经逐步稳定下来，不太需要新的主题/插件了。
  • 这些年的确主要是更新内容，博客的形式、内容啥的，基本上都是稳定不变了。

我为什么不能写？

• 写 Blog 对于我来说没有什么特别的收益。
  • 毕竟这玩意没办法卖，除非写的过程中有别的收益，可能还好，不然大概率亏本。

我如果要写一个 Blog 系统，我需要哪些 Feature？

• 文章系统：包含标题、描述、内容、Slug、目录、标签几个核心属性和实体。
  • Slug 需要自动翻译：我特别依赖这个功能。懒得自己翻译 Slug
• 支持图片自动上传 S3
  • 我现在的图片都是用的外链，这样服务器自身的压力没那么大。
• 支持评论
  • 评论还需要能够自动发送邮件更新。
  • 评论要能实现反垃圾。
  • 历史的 600+ 评论可导入
• 简洁稳定的主题设计
  • 坦白来讲，这几年我很少做主题方面的变更了，基本上就是在几个景点主题上来回切换。
• 支持 RSS Feed 等能力
• 支持在线编写（可能非必需，最近开始逐步用 Ulyssess 写作，其实对于网页写文章的诉求越来越小了，maybe Hexo 是可接受的方案。）

在软件领域，我们有非常经典的 IaaS、PaaS、SaaS 模型，我们使用这个模型定义着我们的产品。

但另一方面，这个定义也局限了很多人的想法 —— SaaS just Software as a Service。

实际上，如果你是一个独立开发者 / 直面用户的岗位，你需要深刻的明白 —— SaaS 更大的价值不应该是 Software ，而应该是 Solution —— 用户从来不关心你是不是有 Software，用户只关心你的 Solution 能不能解决你的问题。

如果你不知道你的 Software 是在解决谁的问题 —— 不妨想想，是不是你没有找到你的Software 到底应该如何放在 Solution 当中 ，以及那个 Solution 对应的问题到底是什么。

持续关注用户的问题，尝试提供靠谱的 Solution 去解决他的问题 —— 而不是关注你的 Software。除了你，没有人真正在意你的 Software。

前言

前面的文章说过，我在开发 一起学笛子 网站的时候，用的是邮箱验证的方式，这篇文章将详细介绍一下具体的实现过程。

实际上，在 一起学笛子 这个网站中，有两处用到了邮箱验证，一个是注册，另一个是重置密码（忘记密码），而且这两个地方的用法是一模一样的，所以，我接下来还是以熟悉的注册场景举例说明。

[...]

前言

前面我在 typecho如何实现前台登录/注册 一文中详细介绍了一下 前台登录/注册 的实现原理与细节，当时是以登录为例说明的，因为登录比较简单，代码量也比较少，但考虑再三之后，还是决定单独写一篇关于注册的文章，毕竟注册还是要复杂一些，而且还涉及到邮箱验证。不过，这篇文章就不再解释原理了，而是直接贴出核心代码，然后对部分要点做一些简单的解释，方便后续有需要的人可以直接复用。

[...]

前言

前面我已经写过好几篇关于 Google Adsense 的文章了，虽然收益甚微，但记录的都是亲身探索的过程，可能贵在真实吧，因此，也吸引了很多朋友的关注，其中也包括一些做的比较出色的先行者。他们无一例外，都极为重视项目出海，而我也多次提到过出海的问题，并且也一直在构思出海障碍小的项目，一起学笛子 就是这样一个项目。

[...]

前言

Typecho是一款很好的博客系统，通过 主题 和 插件 开发几乎可以随心所欲的定制自己的博客网站。但也仅限于博主编辑文章，读者阅读+评论这样的类博客网站，如果希望做更复杂的扩展，就未必能很好的实现了。

本文即将介绍的前台登录/注册功能就是一个这样的功能，虽然通过 主题 和 插件 也能实现，但二者必然紧耦合，撇脚不说，插件的通用性也是个问题。

[...]

飞书执行季 OKR 已经很久了，相比于过去的双月 OKR，我认为这确实是一个好的事情。季度 OKR 可以让我们在一个更长期的事情上来完成我们要达成的目标而无需担心自己所做的事情要更加的长远和长期，也期待更多的团队和协作方可以享受到季 OKR 的带来的长期。

但从另外一个方向来看，即使我们使用了季度 OKR，也需要关注执行的迭代。

OKR周期是我们达成目标的周期，而做事的手段则应该尽可能的敏捷和快速。快速判断、快速执行、快速复盘、快速修正。

目标大和周期长是我们要着眼于更重要、更长期的事情。而迭代的敏捷，则可以帮助我们更好更快的抵达目标。

前言

前段时间，在我博客的评论区中，有几位大佬讨论到了博客要不要加 RSS 的问题，因为我自己平时是不使用 RSS 订阅的，所以就先入为主的认为 RSS 过时了，应该没什么人用了，但看他们的讨论发现似乎用的人还挺多的。

今天突然想起来这个事，因此就也试了一下，发现确实还挺方便、挺好用的，于是乎，今天就赶紧在主题中把这个功能给加上了，顺便也发了一个版本。

本来这是一个很小的功能，加就加了，但由于这里面有个小坑，所以感觉还是需要说明一下，不然估计很多人都不一定会用。

[...]

前言

前面我们已经通过两篇文章，简单的介绍了如何为开发一个自己的 Typecho 主题。我本来还想着再简单剖析一下源码，介绍一下 Typecho 有哪些扩展形式，以及预留了哪些扩展点的。但考虑到可能正如一些朋友所说的，会的人不需要看，不会的人又未必能看懂。我自己一想也对，真到了需要开发的时候，大部分情况还是会面向搜索引擎开发，遇到了问题再解决问题，反而会更容易一些。

考虑到前面的几篇文章已经基本把 Typecho 主题的开发思路说的差不多了，剩下的都是一些细节。因此，这篇文章我想干脆把我开发过程中遇到的最常见问题，进行一下梳理，方便大家需要时查询。毕竟，实话实说，Typecho 的官方文档做的确实太差了，很多东西需要翻源码才能了解。

[...]

前言

前面我们已经通过一个简单的 Hello World 主题简单了解了一下 Typecho 的主题开发过程。这次我们也不讲太多理论，而是直接还原一个相对真实的开发场景。

1. 寻找目标网站

既然是开发主题，那一定是看到了心仪的网站或者网站局部功能，希望自己也能实现一个类似的。最好不要完全凭想象实现，这样难度比较大不说，还不一定能达到预期的效果，除非你是懂设计的。技术好一点的可以直接通过浏览器开发者工具分析目标网站的源码，仿照实现。而更粗暴的方式是直接复制目标网站的源码，然后本地修改。

当然，你还可以到一些前端的模板网站下载源码，这样会比CV目标网站更简单一些，只不过这种操作往往要么收费，要么需要一些非常规手段，这里就不介绍了。

我这里就以仿百度为例，因为这个网站界面相对比较简单。

[...]

前言

Typecho 主题开发首先需要搭建PHP开发环境，可以参考 通过VS Code搭建轻量级PHP开发环境 一文，但实际上，如果你只是微调一下别人的主题，不打算自己开发，那么直接跳过这个也是可以的，因为PHP程序完全可以通过记事本编写，然后直接放到服务器上运行就可以了，不需打包、编译等一系列预处理的工作，但为了普适性，我还是得从开发者的角度来阐述这个问题。

[...]

前言

昨天写了一篇 纯 JS + CSS 手搓一个在线节拍器 的文章，主要阐述了一下实现思路，后面又想了一下，感觉好像说了很多，但又好像什么也没说，因为，高手不需要，而新手看了好像也很难因此而直接上手，毕竟 ，咱们自己也常说“Talk is cheep. Show me the code.”。

因此，这篇文章，我干脆直接把源代码从项目中抠出来，然后简化一下贴上来，这样有需要的人直接复制代码本地运行就可以了。简单、直接，不搞弯弯绕让大家自己去悟了！

[...]

在开发过程中，你可能会需要实现某些和工作日相关的特性（比如，工作日才发某些通知 /推送），这个时候，你可以借助于 chinese_calendar 这个包，来查看当前是否是工作日，你可以引入 chinese_calendar 这个包，来实现判断今天是否是工作日。

可以参考如下代码，is_workday_today 返回 True 时，就是工作日，就需要执行某些特定的逻辑。

from datetime import datetime
from chinese_calendar import  is_workday

# https://github.com/LKI/chinese-calendar
def is_workday_today():
    today = datetime.now();
    return is_workday(today)

在一开始使用 CapRover 时，我使用的是一个 10 GB 的数据盘，但在部署了诸多应用后，10GB 的数据盘已经无法满足我的需求，于是我就对其进行了扩容，扩容至 20GB。在完成扩容 & 重启后，仍需要执行 Linux 的扩容命令 resize2fs 来扩容硬盘。

但由于 CapRover 中运行的服务跑在这个数据盘上，并没有办法直接在这个数据盘上进行扩容（进程会持续读取文件），因此，需要先将 CapRover 上的服务暂停，暂停后进行扩容，并重新启动服务。

CapRover 底层是使用 Docker Swarm + Nginx 来进行的，因此，我们只需要使用 Docker Swarm 的命令，来停止服务运行即可。

1. 获取服务名称

首先，你需要先获取到当前所有在跑的服务，以便于稍后去暂停。执行 docker service ls 来获取到具体的服务名称。

2. 拼接所需的命令

在 Docker Swarm 当中，并没有直接的 Start or Stop 概念，而是通过将 Replica 设置为 0 来实现关闭的能力。这个命令可以通过 docker service scale 服务名=服务数 来实现。因此，你需要将对应的服务设置为 0 来解决这个问题。你可以先行把开启和停止的命令拼接好，从而实现快速的启动和关闭，尽可能的减少宕机时间。

如果是有多个服务，可以直接拼接在后面，从而实现一次关闭 / 开启多个服务。

# docker service scale service_name=1 service_name_2=0
# 停止命令
docker service scale srv-captain--blog-ixiqin-com=0 srv-captain--mysql-8-production-db=0 srv-captain--pgsql-16-production=0 srv-captain--redis-server-production=0
# 启动命令
docker service scale srv-captain--blog-ixiqin-com=1 srv-captain--mysql-8-production-db=1 srv-captain--pgsql-16-production=1 srv-captain--redis-server-production=1

3. 执行命令，扩容硬盘

你可以先执行停止命令，然后执行扩容命令。完成扩容后，重新启动，即可完成整体的扩容。

在开发应用的时候，我们会选择使用 PostgreSQL 作为数据库进行开发，但在 Github Actions 环境下，默认是没有 PostgreSQL 作为数据库后端的，这个时候如果你想要测试一些和数据库相关的逻辑，就不得不面临两个选择：

1. 使用一个和生产环境无关的数据库，比如 SQLite。
2. 在 Github Actions 当中添加一个 PostgreSQL。

前者是大多数常规的做法，大概率也不会出现什么问题（毕竟作为 CURD 仔，我们用的大部分时候都是一些 ORM，很少裸写 SQL），不过依然存在一些概率是你写了一些 PostgreSQL Only 的 Query 无法覆盖到测试。

另外就是本文的核心了：在你的 Github Actions 当中添加一个 PostgreSQL。

Github Actions Service

想要实现这个效果，我们依赖了 Github Actions Service Containers 这个能力。

服务容器是 Docker 容器，以简便、可携带的方式托管您可能需要在工作流程中测试或操作应用程序的服务。 例如，您的工作流程可能必须运行需要访问数据库和内存缓存的集成测试。

您可以为工作流程中的每个作业配置服务容器。 GitHub 为工作流中配置的每个服务创建一个新的 Docker 容器，并在作业完成后销毁该服务容器。 作业中的步骤可与属于同一作业的所有服务容器通信。 但是，你不能在组合操作中创建和使用服务容器。

GitHub

你可以选择你需要运行测试的环境中，找到对应的 Job，并在 Job 下新增一个 services ，即可为你的 job 设定一个依赖的服务容器，它可能是数据库 、 缓存之类的。比如我这里用的就是 PostgreSQL。

我的 Github Actions 完整参考：

• services 是我运行的服务容器。
• steps 是我的真正的测试流程。

name: Django CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

env:
  DEBUG: true
  SECRET_KEY: django-insecure-github-actions
  DB_NAME: postgres
  DB_USER: postgres
  DB_PASSWORD: postgres
  DB_HOST: localhost
  DB_PORT: 5432

jobs:
  build:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres
        # Set health checks to wait until postgres has started
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

    strategy:
      max-parallel: 4
      matrix:
        python-version: [3.12]

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install Dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
    - name: Run Tests
      run: |
        python manage.py test

在开发前端应用的时候，我比较推荐在真正开始写代码之前试着画一画组件树 / 状态树。

在很多时候，可能你的设计师已经帮你做好了组件树，但在某些场景下，你的设计时并不会帮你拆解组件树，或者是你是直接和产品经理对接，他不会帮你拆解组件树。

这个时候，相比于写代码，我更推荐你先拆解组件树，在完成组件树之后，再开始你的 Coding。

Figma / Sketch 之类的软件提供的分组能力、图层的能力，可以帮助你将组件合理的拆解、分组、归类。当你完成树的建设之后，可以试试看将不同的模块拆解，每个模块是否可以独立正常的运转。如果不可以，则说明你的状态拆解的可能是有问题的。

当你完成拆解之后，只需要按照你拆解出来的树组织你的 Component 即可。

在前端留存一些状态，是在前端场景下提升性能的常规操作。最近我有一个场景需要在前端留存一个状态，借着这个机会，试了试 IndexedDB 来作为数据存储，拓展一下新的方向。

关于 Indexed DB

Chrome 在中提供了多种不同的存储，按下 F12 ，打开 DevTools ，找到应用 – 存储，你就会看到目前 Chrome 支持的多种存储方式。常用的主要就是本次存储空间（Local Storage）、会话存储空间（Session Storage）和 Indexed DB。这次我用的便是 Indexed DB。

开发使用建议

由于 Indexed DB 提供的 API 整体比较裸，在实际应用开发时，可能并不好用，你可以根据自己的需要，选择使用不同的第三方开发库来开发你的应用。在这篇文章中，我使用了 idb-keyval 来作为我的开发库。

用法

首先，使用 yarn add idb-keyval 来安装依赖，安装完成后，可以参考如下代码来在你的项目中引入 indexedDB.

import { set,get,keys } from 'idb-keyval';


// 下面演示了一个 get_books 函数，会将内容存储在 IndexedDB 的 your-keys 当中。
// 如果存在缓存，则直接使用缓存，不存在，则进行数据获取
function get_books(){
   // 使用 keys 获取当前 IndexedDB 当中的所有 Key，用于判断当前是否有缓存结果。
   const exists_keys = await keys();
   if(exists_keys.indexOf('your-keys') !== -1){
    console.log("use cached glossary")
    return await get('your-keys');
   }

   // fetch data
   let data = fetch_data();
   
   await set('your-keys',data)
   return data;
}

使用前后的效果

在性能上，使用 Indexed DB 之后，根据你的数据获取的难度，会有不同的性能提升。比如这里我不使用缓存，单次数据获取需要花费 800ms，借助于 Indexed DB，时间可以被控制在 10ms 以内，从而得到一个不错性能。