加载中...
不想等待可以点我关掉

博客

本站是一个使用Stellar主题的hexo博客,目前Stellar再一次进入了快速迭代期,是时候更新一下了

升级主题

这是我站在使用该主题的关系图,

graph LR
    A[BLOG]
    B[thun888/stellar:myself]
    C[thun888/stellar:main]
    D[xaoxuu/stellar:main]

    B -->|子模块| A
    D -->|保持同步| C 
    C -->|合并更新| B

你可能会有疑问,为什么我不直接使用main分支。而是在新开一个myself分支。我之前试过一回被机器人强制同步上游,虽然不知道是不是bug,但是为了保险起见,我选择让主分支始终与上游仓库保持一致,在上游仓库有改动后同步到main分支,然后再合并到myself分支。

然后我就碰到了另一个问题——主分支无法与上游保持同步
问题在于GitHub的PR操作。举个例子,假如现在某个文件(下称A)的改动是这样

gitGraph
    commit id: "main commit 1"
    commit id: "main commit 2"
    branch myself
    checkout myself
    commit id: "myself commit 1"
    commit id: "myself commit 2"
    commit id: "myself commit 3"
    checkout main
    commit id: "main commit 3"
    commit id: "main commit 4"

myself分支与main分支同时修改了A,并且修改的结果不同,这就会导致在合并(main --> myself)的时候出现冲突,作为合并发起者你需要来处理哪一分支上是正确的,这就会导致你必须要把myself分支中的A处修改给同步过来,才能够保证这一块代码没有冲突进而完成合并

gitGraph
    commit id: "main commit 1"
    commit id: "main commit 2"
    branch myself
    checkout myself
    commit id: "myself commit 1"
    commit id: "myself commit 2"
    commit id: "myself commit 3"
    checkout main
    commit id: "main commit 3"
    commit id: "main commit 4"
    merge myself id: "merge: myself into main"

随后再有更改时,它们两个分支可以视为“同一起点”上,就可以直接把提交直接给合并过去了

gitGraph
    commit id: "main commit 1"
    commit id: "main commit 2"
    branch myself
    checkout myself
    commit id: "myself commit 1"
    commit id: "myself commit 2"
    commit id: "myself commit 3"
    checkout main
    commit id: "main commit 3"
    commit id: "main commit 4"
    merge myself id: "merge: myself into main"
    commit id: "main commit 5"
    commit id: "main commit 6"

这也就导致了其实在GitHub的网页上进行PR操作过程中会污染原来的 main 分支

我在这里正是这个问题。由于长期的PR操作,导致main分支上有不少myself分支的修改,而高速迭代中的主题已经把这些部分改的面目全非,所以说全是冲突嘛,根本没法自动同步

那么摆在我的面前的问题就是:

  1. 我要怎么同步上游仓库到main分支
  2. 绕过现有的PR这个问题也就是在本地完成PR操作

我的方法就很简单粗暴了,既然是因为我多修改了main分支上的代码,那我就一口气回档到一个上古年代的提交,然后再强制同步

1
2
git reset --hard {commitID}
git push -f

最后在本地发起pr请求,解决代码冲突就行了

1
2
3
4
git checkout myself
git fetch origin
git rebase origin/main
git push -f

话又说回来,我还是建议直接fork后对main分支作更改,然后再用命令来同步
Stellar 主题更新解决与上游 fork 项目的冲突 - 宇宙尽头的餐馆

接下来就是应用到网站上面了,我这里就直接同步过来更新了,没有进行本地测试(之前同步的都是小改动,都没有出过事),然后就没管他了,但是啊,因为那几天填志愿比较忙就先搁置了没看,结果发现后来发现它爆了一地错,虽然没有构建产物输出,但是hexo又没有报错退出,触发了网页部署,导致那几天直接404了,又得debug一下了。

根据报错的代码定位到两个问题——一个是页面类型,另外一个是懒加载。页面类型好办,直接post改成page就行了(不过奇怪的是,我依稀记得以前写的就是page),但是懒加载我琢磨了好久,最后发现因为懒加载的引入组件的目录做出了更改,但是原来的配置项依然能够生效,生效了以后引入的那个懒加载组件的目录不存在,引入不了而发生报错

在处理完这些问题以后发现又有新版本了,修复冲突后又来bug了——我的几个自定义css和js被转换成了json,不是,这也太离谱了。

红澄澄
红澄澄
Snipaste_2025-07-05_12-42-26.jpg
Snipaste_2025-07-05_12-42-26.jpg

一开始我根据最近的几个提交命名初步锁定了几个提交,查对应提交所改动的代码,然后发现都没有问题,看了半天绷不住了,用二分法来查,最后定位在了这个pretty_url上,当时修改配置文件的时候,其实也注意到了这个突然多出来的一个设置项,但是这名称一看就不是好吧,但是仔细研究了一下,pretty_urls.js重写了Hexo的页面生成器,但是它又没有单独排除js、css这些资源,然后就导致了这些离谱的出错,补上去就行
其他还有一些小bug,比如说自定义主题色个功能失效什么的。简单修了一下,暂时不管他了,找bug太难受了

以上问题已修复

在更新同时,主题也引入了更有表现力的丰富色彩,现有的可以定义左边栏和背景,但是我认为这还是太花里胡哨了,就暂时改回了之前的样式。

7月23号又更新了一下到最新的版本,然后发现评论区划不动了,我初步判断是由于那个平滑滚动酷获取到的页面高度出了问题,一到往下他就以为已经到头了,实际上并没有,然后就会卡住跳转回去,鉴于它会接管全局的滚动监听事件,在部分滚动条(像是评论区表情框)没法通过滚轮滚动,干脆把这功能砍了

一些变更

在主题更新的同时,我也对一些其他的功能做出了一些变更

首先就是这个大事记,在这么久以来它已经活成更新日志的样子了。而这个更新日志因为我嫌静态时间线写时间太麻烦又改成了动态的(基于电报频道),但是吧,这终归不太方便。

关于这个时间线问题,其实GitHub也有老哥已经做出来了自动添加当前时间的功能,大家有兴趣的话可以去看一看:[feat] 更新 timeline 组件的功能,可以自动显示时间戳 by Cactusinhand · Pull Request #539 · xaoxuu/hexo-theme-stellar

而且如果说这个页面还叫做大事记的话,那怎么更新一下就算一个大事啊,这不对吧?
所以我打算把大事记中的更新日志给独立出来成一个页面,但是又回到之前那个问题上了,我要怎么样才能够快捷地记录一些更改呢。毕竟我是懒得写日志的,有的时候改动太多写不过来,改动太少我觉得没必要,就很尴尬
所以说我不能够通过git的commit记录来简单显示出这一个提交做出了哪样的更新呢
说干就干,先获取git log存储到json文件中,我这里用Hexo的插件来执行

再给Stellar写个数据服务

至于提交的标题,我用的是这么一个逻辑,基本上可以覆盖大多数的提交,同时在前端映射成对应的汉字

/A
(新增)
D
(移除)
M
(修改)
E
(修订)
F
(修复)
U
(升级)
P
(页面)
APDPMPEP\\
F
(功能)
AFDFMDEFFF\
T
(主题)
\\\\\UT

Git要禁用路径转义:

$

GitHub Action 部署时还要设置拉取深度

.github\workflows\autodeploy.yml
1
2
3
4
5
6
7
8
9
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: 检查分支
uses: actions/checkout@v4
with:
ref: main
+ fetch-depth: 0

效果如下

效果
效果
By the way

还可以在CI阶段自动将更新内容转发到电报上,然后再在电报里面编辑来添加详细的更新日志。在本地也可以用Git的pre-commit来在提交时就上传日志。不过嘛能用就行~

项目列表

借用了wiki页面的卡片

效果
效果

注册标签

themes\stellar\scripts\tags\index.js
1
2
3
4
5
// data
hexo.extend.tag.register('users', require('./lib/friends')(hexo))
hexo.extend.tag.register('friends', require('./lib/friends')(hexo))
+ hexo.extend.tag.register('projects', require('./lib/projects')(hexo))
...

示例配置

source\_data\links\projects_my.yml
1
2
3
4
5
6
7
8
9
10
11
- name: Whisper on Cloudflare
time: "2025-06-22"
logo:
url: https://github.com/thun888/whisper_cloudflare
description: 基于 Cloudflare Workers Whisper 语音转文字服务
language: JS
tags:
- name: Demo
icon: lineicons:website
url: https://whisper.ohen5pbf93.workers.dev/
color: '#181818'

用法:

source\wiki\Serve-list\projects\index.md
1
2
3
4
5
6
7
8
9
10
11
## 项目

{% projects projects_my %}

## 改动/参与开发

{% projects projects_coopreate %}

## 旧项目

{% projects projects_myold %}

侧栏背景图

散步的时候看到天上的云挺漂亮的,就想着能不能给网站上也加上几朵云,根据天气实时更改网页背景的云朵密度

就从内容可视度的角度决定只是改动左侧栏的背景
至于图像生成,一开始有这个思路的时候我直接让AI写了一个,然后他生成出来也太真实了一点

cloud.png
cloud.png

这个显然不太合适
那认真考虑一下,现在是需要怎么样的云,从风格上来看的话,我更偏向于像素化的云

比如说这个世界盒子里面的
比如说这个世界盒子里面的

但是考虑到在实际情况下,如果使用一个高清晰度的素材再被作为背景的话,那就会影响可读性。为了降低影响最直接的方法就是高斯模糊了,但是这样子的话就没必要保留那么多的细节
那不妨看一下云的组成,是一个一个水分子组成的,水分子可以抽象成一个球体模型,在微观角度上,一朵云就是由几十亿个水分子组成的,几十亿个球重叠在一起,从而显现出了一朵云的形状,那不妨我们做出一些相应的简化,比如说直接使用5个圆形叠加生成,这个时候就得到一个简略版的云了,类似这样

效果
效果

绘制逻辑:随机一个点为初始点,在一定距离范围内随机下一个点,重复若干次,绘制以其为圆心的圆

obt3.gif
obt3.gif

单一的云朵觉得还是略显单调了一点,如果它能进行动态生成使得每一次生成的位置都不一样那就更具可玩性了,在此基础上我希望它能够被现实赋予更多的特性,比如说云朵的数量和颜色,背景的颜色(比如随着时间动态调整)等等

一开始我是想用和风天气的api来获取云量,但是我试了半天都返回400错误,我干脆就用小米天气的api接口来获取天气的信息。感谢ClassIsland在获取小米天气数据方面的成果

虽然获取不到云量这个直接数字,但是天气状况跟云量其实也是呈正相关的,那就可以用天气代码来替代了,这里将云朵的颜色与天气代码挂钩

天气代码索引表

编码中文描述
00
01多云
02
03阵雨
04雷阵雨
05阵雨伴有冰雹
06雨夹雪
07小雨
08中雨
09大雨
10暴雨
11大暴雨
12特大暴雨

最终结果就这样了,虽然你认真看也不一定看得出来这是朵云,不过我这里主要起到一个点缀的作用,咱也不能喧宾夺主是吧

效果
效果

后来迁移到前端,使用canves进行渲染

有个意外发现在境内或者境外来请求同一个城市的天气信息的时候,当然天气的值会有出入,比如说在国外请求湛江是8,在国内是7
可能是在缓存策略上有所不同,为了保证数据不因为过时数据而导致别的问题,所以直接砍掉了分钟级的预报

AI对不同数据的分析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
好的,我们来比较一下这两个 JSON 数据,看看有什么不同之处。

### 主要区别概览

第二个 JSON 对象比第一个多了 `minutely` (分钟级) 降水预报。此外,两者在 `current` (当前天气状况), `forecastDaily` (每日预报), `forecastHourly` (逐小时预报) 和 `alerts` (预警信息) 的一些具体数值上也存在差异。

### 详细差异对比

#### 1. 新增信息
* **分钟级降水预报 (`minutely`)**: 第二个 JSON 对象中包含了详细的分钟级降水信息,而第一个则没有此项。

#### 2. 当前天气状况 (`current`)
* **天气现象 (`weather`)**: 第一个为 "中雨" (代码 8),第二个为 "小雨" (代码 7)。
* **风向 (`wind.direction`)**: 第一个为 169.33°,第二个为 169.0°。

#### 3. 每日预报 (`forecastDaily`)
* **降水概率 (`precipitationProbability`)**:
* 第一个 JSON 显示未来几天有较高的降水概率,例如第二天为 72%。
* 第二个 JSON 则显示未来几天降水概率为 0% 或非常低。
* **天气现象 (`weather`)**: 今日天气第一个为 "中雨转多云" (代码 8 转 1),第二个为 "小雨转多云" (代码 7 转 1)。
* **风向与风速 (`wind`)**: 两个 JSON 对象在未来几天的风向和风速预报上存在一些数值差异。

#### 4. 逐小时预报 (`forecastHourly`)
* **天气现象 (`weather`)**:
* 第一个 JSON 的 18:00 时天气为 "中雨" (代码 8)。
* 第二个 JSON 的 18:00 和 19:00 时天气为 "阴" (代码 2)。
* **风速 (`wind`)**: 两个 JSON 在逐小时的风速预报数值上有所不同。

#### 5. 天气预警 (`alerts`)
* **暴雨黄色预警 (` defense`)**: 第一个 JSON 在暴雨黄色预警的“防御指南”中包含三条建议,而第二个只包含一条。

#### 6. 其他细微差别
* **更新时间 (`pubTime` 和 `updateTime`)**: 两个 JSON 的发布和更新时间有细微差别。
* **源数据 (`sourceMaps.clientInfo.appVersion`)**: 客户端应用版本号不同。
* **CHS 字段**: 第二个 JSON 的 `chs` 字段中多了 "CWA11" 和 "MNPCH1" 类型。

总的来说,两个 JSON 数据虽然在大部分基础信息上保持一致,但在具体的实时天气、降水概率以及部分预报细节上存在明显差异。

页面背景图

后来在生成文章背景图的时候意外的发现这种类似于等高线的曲线样式其实还怪好看的,所以说能不能将它直接应用到网页的背景中呢

也不是很突兀,不会影响文章内容的可读性。一开始我打算通过ip来推测用户所在地区,然后在那个大概的区域的一个范围内,随机获取一部分高度数据,然后将其转换成等高线的图片,然后最后再取随机的倍率和随机旋转角度进行裁切最后显示,但似乎没有开放的接口能直接获取,所以说要换一个思路,使用纯数学方法来实现。我一开始打算借用物理中电势图的思路,随机多个电荷量大小不同的点电荷,将场强叠加后得到多个三维坐标,再用画等距等高线的方法来标记点位,连接成线。不过喂给AI半天都搞不出来一个可行的,干脆让它自己发挥了,效果拔群

其实还有个思路

从结果出发,可近似处理为若干椭圆叠加:

  1. 新建画布 1920 x 1080
  2. 在画布中随机2个点作为焦点
  3. 随机 2a 的长度,绘制椭圆,绘制完毕后检查有无在画面内
  4. 固定其中一个焦点,随机一个焦点(可选:是否在外部)
  5. 再次绘制椭圆,绘制完毕后检查有无与原椭圆重叠
  6. 作新焦点对的连线和中垂线,在交点处作一条直线,且该直线与中垂线有正负15°到正负60°的夹角
  7. 在新直线上距离交点处正负50px到正负100px的地方再随机取2个点作为焦点,该步骤视为第二步重复以上操作5次
    效果嘛。。他应该没懂我意思
不过结果没眼看
不过结果没眼看

在完成实装后发现加载有些许卡顿,排查发现绘制背景太慢了,目前改成了自动缓存渲染结果(10分钟)

添加缓存前
添加缓存前
缓存后
缓存后

页面文章列表

封面所占据的空间太大,感觉有点不协调,所以我在想要怎么样改变一下。文章卡片可以分为封面、标题、描述、时间、分类这些杂项,其实我一开始是想把描述砍掉的,像隔壁宇宙尽头的餐馆一样,但砍掉以后与卡片样式有点不协调,然后还是改封面吧。一开始是打算像这样从右往左逐渐过渡的,然后越看越眼熟,想起来之前纸鹿就是这样子的,然后直接就去cv了,效果很 Amazing 啊

初稿
初稿
纸鹿🐄
纸鹿🐄

附属组件

友链朋友圈

在此前我使用的是Rock-Candy-Tea/hexo-circle-of-friends,但是该项目已经停止更新许久,加上又莫名其妙地同步了上游导致我配置丢失没法使用,干脆全部迁移到willow-god/Friend-Circle-Lite

整体部署起来比较方便,我这里也不多说了,主要说一下我遇到的问题
首先是获取友链列表,旧项目基于页面解析实现的,填个友链页面就行(不过我用的是websites标签,所以还要自己改改代码),而这个项目是通过部署时调用程序直接导出。我参考了评论区老哥HPCesia的写法

评论区
评论区

注:linkList这样写是因为我有多个链接配置

1
2
3
4
5
6
7
8
9
10
11
12
13
PS F:\myblog\source\_data> tree links /f
文件夹 PATH 列表
卷序列号为 686F-079D
F:\MYBLOG\SOURCE\_DATA\LINKS
d-friends.yml
friends.yml
mogul.yml
projects_coopreate.yml
projects_my.yml
projects_myold.yml
websites.yml

没有子文件夹

Stellar数据服务:

组件配置:

source\_data\widgets.yml
1
2
3
4
5
6
friends_timeline:
layout: timeline
title: 看看朋友们
api: https://faster-raw-git.hzchu.top/thun888/Friend-Circle/refs/heads/page/all.json
type: fclite
limit: 20

部分链接没有提供RSS,这里使用PolitePol来生成RSS链接,挺方便的

Snipaste_2025-07-08_23-25-05.jpg
Snipaste_2025-07-08_23-25-05.jpg
Snipaste_2025-07-08_23-25-15.jpg
Snipaste_2025-07-08_23-25-15.jpg
Snipaste_2025-07-08_23-25-59.jpg
Snipaste_2025-07-08_23-25-59.jpg

自动截图

一直以来友链页面使用的是预先截图的图片,后来换用了thum.io,不过免费版本的还是太差劲了,后来试了一大堆项目都不太满意,最后修了下zkeq/Python-WebSite-Screenshot,效果如图(自动更新)

本站_lastest.png (1280×720)
哔哩哔哩_lastest.png (1920×1080)

配置:

  1. Fork仓库
  2. 修改config.yaml
  3. 修改main.py中外部友链导入
  4. 启用Action的写权限
  5. 运行Action!
config.yaml(Demo)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
list:
- url: https://www.bilibili.com
timeout: 10
real_time_out: 5
height: 1080
width: 1920
full_page: 2 #原先配置可以选择不同的截图方式,但我只保留了这种
- url: https://blog.hzchu.top
timeout: 10
real_time_out: 5
height: 720
width: 1280
full_page: 2

host: #指定ip功能
- domain: blog.mc-sep.top
ipaddr: 35.212.202.85
main.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
...
if __name__ == "__main__":
# 读取配置文件
with open("config.yaml", "r") as f:
data = yaml.safe_load(f)["list"]

# 导入友链信息
try:
# print("------------------------------")
print("正在获取友链信息")
- response = requests.get("https://blog.hzchu.top/data/friends.json")
+ response = requests.get("https://yourDomain/friends.json")
if response.status_code != 200:
print("请求失败")
friends_data = response.json()["friends"]
# 遍历友链信息
for i in friends_data:
url = i[1]
data.append({
"url": url,
"timeout": 30,
"width": 1050, # 外部友链默认配置,按需修改
"height": 700,
"real_time_out": 10,
"full_page": 2,
})
...

最后Summer给我丢了个wr.do早知道就不折腾了,支持自部署,也可以用它提供的在线服务

Obsidian

一直以来写文章都是在小米便签上写好,然后再发到电脑上用Typora做修改,或者说直接用kdeconnect连到电脑上用语音实时输入,不过现在新手机安卓版本太高,后台限制的死死的,连接一会就断,那我不如找一个靠谱的支持跨设备同步的编辑软件

不过迁移后体验不能比迁移前差吧,主要有这两个功能挺需要的:

  1. 自动补全,原先基于obgnail/typora_plugin实现,obsidian中可以用Various Complements平替
  2. 表情面板,原先是自己写的插件,obsidian还没有现成的替代品

所以迁移工作一直扔在一边,不过后来Summer整了个infinitesum/obsidian-emoji-selector,欸,齐活了

跨设备同步

一开始我想使用GitHub来进行同步,一方面考虑到版本控制,和与现有博客仓库的集成。然后后面发现现有的插件或多或少都有bug或不适用于移动端。最后我用Remotely Save来进行同步

一开始我直接用又拍云的S3储存来进行同步,配置如下:

Snipaste_2025-07-23_14-58-35.jpg
Snipaste_2025-07-23_14-58-35.jpg

后来我自己用OpenAlist搭了一个webdav服务器,并用DNS实现内外网分流,在内网环境下同步基本上一点就完事了,外网环境就要多个几秒钟

graph LR
    A[客户端]
    B[公网服务器]
    C[内网服务器]


    A -->|公网| B
    B -->|FRP| C 
    A -->|内网| C

至于写完后的部署,我目前还是再复制粘贴到博客里面,更进一步可以参考探索Hexo多端写作 - 星日语

有个思路,添加一个Action用来同步webdav上文件,随后通过像shabegom/buttons这类插件来在编辑器内直接运行Action完成同步。不过懒得折腾了

自动添加元数据

Obsidian 自动添加元数据

templates/post
1
2
3
4
5
6
7
8
9
10
11
12
13
---
title: <% tp.file.title %>
date: <% tp.file.creation_date("YYYY-MM-DD HH:mm:ss") %>
updated: <% tp.file.last_modified_date("YYYY-MM-DD HH:mm:ss") %>
author: thun888
tags:
cover:
banner:
description:
categories:
references:
mermaid: false
---

效果:

自动添加元数据
自动添加元数据
自动补全

增强 Stellar 标签组件写作体验 - 宇宙尽头的餐馆

自动补全
自动补全
表情面板

目前还未上架到商店,可以手动安装

表情符号模板:{% emoji {category} {fullfilename} %}

_config.stellar.yaml
1
2
3
4
tag_plugins:
emoji:
Blob: https://emoticons.hzchu.top/emoticons/Blob/{name}
酷安: https://emoticons.hzchu.top/emoticons/coolapk/{name}
面板选择
面板选择
自动建议
自动建议
图片上传

我图床是Lskypro,直接用Image to Lskypro秒了

设置页面
设置页面
杂项

编辑器 - 解决 Obsidian 在粘贴代码时自动添加空行的问题 - 个人文章 - SegmentFault 思否

Ctrl + Shift + v即可

修改部署方式

访问本站时候主要请求了blog.hzchu.topstatic.hzchu.toponep.hzchu.top,之前都是托管在vercel上的,速度不错,但还有进步空间。目前把blog.hzchu.top部署在Edgeone Page上,资源站使用多吉云和又拍云作为CDN,图片服务优化了国外的访问情况,对其它比如说评论,统计类服务也使用了国内CDN。

图片服务

国内用户(常规流程)

sequenceDiagram
    participant A as 国内用户
    participant B as 主节点
    participant C as 国内边缘节点

    A->>B: 请求图片1
    B-->>A: 302
    A->>C: 请求图片1
    C-->>A: 返回图片1数据
    A->>C: 请求图片2
    C->>B: 缓存不存在,请求图片2数据
    B-->>C: 返回图片2数据
    C-->>A: 返回图片2数据

国内用户(本站):
为了降低多次请求时中间跳转的耗时,在本站做了本地替换链接处理。不过目前还是不太优雅,以后用SW来替代

sequenceDiagram
    participant A as 国内用户
    participant B as 主节点
    participant C as 国内边缘节点

    A->>B: 请求节点列表
    B-->>A: 返回节点列表数据
    A->>C: 请求图片1数据
    C-->>A: 返回图片1
    A->>C: 请求图片2
    C-->>A: 返回图片2数据

国外用户(常规流程,本站流程与上文类似):

sequenceDiagram
    participant A as 国外用户
    participant B as 主节点
    participant C as Cloudflre边缘节点
    participant D as Cloudflre R1
    participant E as 主节点(未分流)
	 participant F as webp.se
     
    A->>B: 请求图片1数据
    B->>C: DNS解析分流到Cloudflare worker
    C->>D: 读取缓存
    D-->>C: 返回图片1数据
    C-->>A: 返回图片1数据
    A->>C: 请求图片2数据
    C->>D: 读取缓存
    D-->>C: 数据不存在
    C->>E: 请求图片2数据
    E-->>C: 返回图片2数据
    C->>F: 进行格式转换
    F-->>C: 返回图片2数据
    C->>D: 写入缓存
    C-->>A: 返回图片2数据

以往会无脑跳转到国内节点,导致国外体验不佳,现在应该不错

修复动态代码

主要是前端的问题,因为Stellar更改了前端服务脚本的执行方式为异步执行,导致原来的程序出错,我干脆就根据参考隔壁语佬的教程集成为Stellar的一个功能了
这是…动态代码框? - Thun888

配图

把一些配图/占位图换成了猫猫
用了ChatGPT生成:

1
以这只可爱的猫猫为主角形象。使用该形象和绘画风格创建4张背景透明的分辨率为1280*720的横版图片,图片的左侧是504http状态码字样,右侧是这只猫根据相应的状态码所对应的含义做出相应的动作。字体和图案距离边缘要有一定距离。

关于版权问题:原图在这里,但我找不到出处了,如果能联系到原作者再沟通下

Snipaste_2025-05-23_20-52-37.png
Snipaste_2025-05-23_20-52-37.png

统计

受够了Umami的破坏性迁移,恰巧群友发了Rybbit统计系统的介绍就用上了

后台页面
后台页面

安装起来一串命令的事,具体参考Quick Start - Rybbit

1
2
3
4
git clone https://github.com/rybbit-io/rybbit.gitcd rybbit
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

安装完后会自动配置SSL证书,如果你不需要内置的web服务可以运行:

$

一开始我是部署在一台公网服务器上,但是因为带宽问题访问后台异常的卡。后来干脆迁移到家里面,但这样有没有公网(特指80,443端口)
虽然可以用非标准端口绕开限制,但带着端口号访问终归不太优雅
所以只能加个CDN来反代一下:

graph LR
    A[客户端(国内)(访问后台)]
    B[客户端(国外)(访问后台)]
    C[多吉云]
    D[Cloudflare]
    E[内网服务器]
    F[客户端(内网)]
    G[客户端(全球)(调用统计API)]

    A --> C
    C -->|非标准端口| E 
    B --> D
    D -->|非标准端口| E    
    G -->|非标准端口| E
    F -->|DNS分流| E

同时,对于延迟敏感的统计API接口通过非标准端口直接访问
为了实现上述操作,还要自己改改统计的js代码

服务器

之前重装了下耗子面板后内存一直爆表,经过各种错误的尝试后终于给我发现了问题——面板安装的PHP和Nginx策略太激进了
Snipaste_2025-07-18_22-50-52.jpg
Snipaste_2025-07-18_23-01-01.jpg
直接把他们狠狠地限制下

注意

该配置上限很低,请根据实际情况更改

可以参考:OpenResty 的性能优化配置建议 - 杜老师说