Y!an 发布的文章

不知不觉又过去一个月，上个月（2025.08.19~09.18）主要给 passport 新增了 OIDC 支持和给词焙做了一些迭代，然后更新了各种系统。

开发

  • 给 passport 新增了 OIDC 支持，逐步替代之前的简单粗暴、微服务式 SSO。也因为新增 OIDC，终于是给 passport 加上前端页面了，顺便再一次复习了 React Router
  • 给词焙新增了非法单词列表。查词接口如果单词不在数据库就会调 AI 接口去获取数据，但是如果用户给的本身就不是一个英语单词，那么无论查多少次都是没有数据的，既浪费时间又浪费接口费用，所以直接加了个非法单词列表，命中则直接返回报错了

其他

  • 将主路由从 RouterOS v6 升级到了 v7。宽带优惠套餐续期之后掉了公网 IP，在跟电信 argue 要回公网期间折腾了一下路由器，原因是在没有公网 IPv4 那几天把 IPv6 开了，然后发现 RouterOS v6 的 IPv6 有个比较蛋疼的问题，就是设备获取到的 IPv6 地址会越来越多，看到 V2EX 和恩山论坛有人讨论说 RouterOS RA 的默认 Preferred Lifetime 和 Valid Lifetime 是很长的（7 天和 30 天），而电信给的前缀是 3 天有效，一开始以为把 RouterOS 的 RA 生命周期缩短到不超过运营商给的时长就行，但是还是不够完美，因为我设置了路由器在凌晨定时重新拨号，而 ROS v6 在旧 IPv6 前缀失效时不会再通告，就会导致设备还在持有旧地址一段时间，这样造成的影响就是比如微信在切后台再回来的时候会先尝试用旧地址连接服务器，然后超时了再换新地址，“连接中...”的菊花就会转很久。后来又在 Reddit 和 Chiphell 看到有人提到说 RouterOS v7 新增了旧前缀失效时会通告，想了一下还是升级到 v7 了，至此双栈公网 IP 的宽带折腾告一段落。
  • 把一台东京的服务器从 Ubuntu 18.04 更新到 24.04 了，不知不觉这台机器连续工作了 1500+ 天没有重启过，并且还有个每天都在用的进程也跑了 3 年多没有因为内存泄漏之类的挂掉，这稳定性着实有点震惊到我了🤣。顺便也把 Homelab 一台 Ubuntu 20.04 的虚拟机更新到 24.04 了。

文章

在做词焙的非法单词列表的时候写了个简易可靠的 Set，具体实现：

问题出现

在做词焙词库更新的时候遇到一个问题：如果某一个单词是一个非法的单词，那就需要进行标记，之后再次遇到的时候可以直接跳过。

这个方案要实现的话，可能第一时间会想到用 Redis 的 Set；或者数据库里加一张表，一行一个非法单词。

但是词焙本身是没有用到 Redis 的，如果要用还得配置下内存淘汰策略；这么简单的需求放数据库的话又有点杀鸡用牛刀了。

所以我选择了直接使用内存 + 定期持久化到文件，整个技术方案不难，加起来就一百行左右的代码。

- 阅读剩余部分 -

🎉 Chrome 扩展「词焙+」上架

先广而告之一下，Chrome 扩展「词焙+」已经过审并且发布到 Chrome 应用商店了，欢迎戳这里安装体验~

开发

这个月的开发重心几乎全在词焙 Chrome 扩展上，做了一些局部重构的工作：

  • content_scripts 由纯手写 DOM 操作改为 React
  • 因为将整个插件所有页面都改成 React 之后打包出了一些奇奇怪怪的问题，于是改用 vite-plugin-web-extension
  • 开发扫码登录流程（浏览器插件、小程序、后端接口三端联动）
  • ...

踩了各种坑之后，Chrome 扩展开发初体验算是圆满结束

其他

这个月还抽空重装了一台应用服务器，然后把词焙 API 迁移了过去，并且接入了 EdgeOne CDN；

8 月初回老家参加好基友婚礼的时候顺便折腾了一下老家的网络，试了下 RouterOS 开启联通 IPv6 + DDNS6（为了给即将可能失去的电信公网 IPv4 做准备），结果就是不太理想，于是又折腾了私有部署 Tailscale，具体情况见下方新文章

文章

先说方案

使用 Docker compose 编排 Headscale + Headplane（一个很像 Tailscale 官方的 WebUI），使用 Caddy 来申请 TLS 证书（用 NGINX 也行，只是我懒，Caddy 可以帮我搞定 TLS 证书的自动申请和续期）并反向代理到 Docker 容器。

我直接用了 Headscale 自带的 DERP 服务，比网上找到的一些需要额外搭的 DERP 简单不少😎

需要准备的是一个域名和一台装好了 Docker 的服务器（如果需要买服务器，可以点后面链接购买腾讯云轻量应用服务器）。

后文会给出 Caddyfile、compose.yml、Headscale 和 Headplane 的配置文件示例，只需要简单修改（域名）即可直接使用。

- 阅读剩余部分 -

最近一个月（2025.06.19~07.18）输入跟输出各占一半吧，输入主要是把过去的一些东西复盘了一下，然后找资料，对旧东西有了新的认识，输出主要还是词焙相关的优化工作：

开发

  • 词焙新增了用户个人设置同步，新增了发音偏好：「国际音标」和「近似发音」，近似发音类似于小时候学英语写的谐音，不过用的是简短的英语单词，例如 wordsbaking 的近似发音是 wurds·bay·king，对于不想看音标的懒人来说是一种记发音的友好方式了吧🤣
  • 为了做划词翻译插件，优化了下 AI 翻译单词的队列，现在可以并发处理了（其实就是申请了多几个 API key，防止单个 key 超 rate limit）

其他

  • 申请了腾讯云 EdgeOne CDN，也体验了一把 EdgeOne Pages，托管了个开源小游戏，点此体验：TapMe 和 小游戏合集
  • 重装了一台闲置的服务器

文章

写了两篇新文章，其中一篇是之前说好要写的两篇之一（还剩一篇迟点写）：

微信小程序的 WXML 目前（2025.07）是不支持 <svg> 标签的，所以没办法直接使用 Lucide 这一类的图标，但小程序提供了 <image> 标签，是支持 SVG 格式的，但！直接用 <image> 引入 SVG 就没办法自定义颜色了。

有解决方案吗？有的，因为 <image> 是支持 base64 格式的，那我们动态创建 SVG 图标即可。

怎么动态创建呢，把图标的 SVG 字符串中的颜色熟悉（stroke）提取出来，将整个 SVG 字符串作为图标模板，然后用字符串的 replace() 替换即可。

本文的代码是 React + Taro，其他框架的思路是一样的，只是写法略有差异。这里需要用到 js-base64 这个库，记得先 npm 安装一下。

以 Lucide 的 book 图标为例，它的 SVG 是这样的：

- 阅读剩余部分 -

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 15