2025-08-01 00:00:00
现代浏览器真是强大，可以替代一些服务器的功能了！
前段时间在和群友聊天的时候，提到了我博客的分发方案，这么多年过去之后我已经在很多平台上分发了我的博客，不过这只是多重冗余，并不算去中心化（虽然我也有向IPFS同步，不过IPFS还得pin，也不太可靠）……所以这么看来，我的博客似乎还不算极其可靠😂？但其实不完全是这样。因为除了向不同平台的分发，我的博客还有一个全文搜索的功能。更重要的是，之前做文章推荐功能时，会把整个博客所有文章的文字存到访客浏览器的localStorage中。这么说来，只要有人访问了我博客的文章，他们的浏览器中就会保存一份我博客文章的完整文本副本。从这个角度看，可靠性应该算是相当高了吧？
不过我之前的分发方案里还记录了一点，在GitHub Pages以外的平台我还打包了一份全站生成后的代码，之所以要全站打包，也是希望我的博客能尽可能的分发，考虑到几乎所有的Linux发行版一定有tar，而不一定有zip，所以我最终打包成了tgz格式。如果能让访客下载这个全站打包好的副本，相比于浏览器里只存储了文章文字的全文数据，这应该是一个更好的备份方式吧？毕竟我的博客本身也是我的作品……所以这个压缩包到底有什么地方可以用到呢？
这时候我想起来，现代的浏览器功能已经非常强大了，甚至在浏览器里直接运行一个Web服务器也完全没问题。如果能让访客在浏览器里下载那个压缩包并运行一个Web服务器，那就相当于在他们本地设备上部署了一份我的博客副本。这样一来，除了我自己搭建的网站之外，这些访客的本地也运行着一个我的博客实例😆（当然，这份副本只有访客自己能看到）。
想要在浏览器上运行Web服务器其实很简单，那就是使用Service Worker，它可以完全离线在浏览器上工作。格式的话和以前写过的Cloudflare Worker非常相似，毕竟Cloudflare Worker就是模仿Service Worker的方式运行啊😂，所以我要是想写Service Worker应该很简单。
有了执行的东西之后就是存储，在Service Worker上存储可以用Cache Storage，用它的话不仅可以保存文件的内容，还可以保存响应头之类的东西，用来和Service Worker配合使用非常的方便，不过既然是Cache，它的可靠性就不能保证了，浏览器很可能在需要的时候清除缓存内容，所以相比之下用IndexedDB应该会更可靠一些。
那么接下来就该处理我的tgz文件了，tgz的本质是tar文件被gzip压缩之后的东西。浏览器解压gzip倒是简单，可以用Compression Stream API，但它也只能处理gzip了……对于tar的处理似乎就必须用第三方库。而tar的库在网上搜了搜似乎很少，网上找了个tarjs库，文档写的也看不懂，⭐️也很少，看来是有这个需求的人很少啊，而且还要用现代JS那种开发方式，要用什么npm之类的。在上一篇文章我就说过我不是专门写前端的，对在自己电脑上安装Node.js之类的东西很反感。后来问AI也完全写不出能用的代码，估计这个功能还是太小众了……另外又想到除了这个问题之外还要处理网站更新的时候该怎么通知Service Worker之类乱七八糟的事情……所以只好作罢😅。
这么看来离线运行我的博客似乎有点麻烦，不过既然都研究了一下Service Worker，不如想想其他能做的事情……比如当作反向代理？虽然在浏览器上搞反向代理好像意义不是很大……但值得一试。我之前见过一个项目叫做jsproxy，它是用Service Worker实现的正向代理，这给了我一些启发。我在之前研究分发方案的时候发现了一些模仿GeoCities的复古静态网站托管平台，比如Neocities和Nekoweb。它们需要通过网页或API才能上传网站，不太方便使用CI/CD的方式部署。但是我又觉得它们的社区很有意思，所以想用Service Worker的方式反代到我的网站，显得我的网站是部署在它们上面一样。
这个做起来非常简单，其实就和我以前用Cloudflare Worker搭建反代几乎完全一样，遇到请求之后直接通过Fetch获取内容然后再返回就行，唯一不同的就是浏览器存在跨域策略，在跨域时只有对应网站存在合适的响应头才可以成功请求，还好我用的Pages服务大多都允许跨域。但是在我实际测试的时候发现这个允许跨域的等级不太一样，比如GitHub Pages的响应头里包含Access-Control-Allow-Origin: *，但是不允许OPTIONS方式请求，另外如果要修改请求头，在响应头里还要一一允许相应的请求头才行……当然对于这种问题解决起来很简单，就和我之前写的订阅源预览一样，用cloudflare-cors-anywhere搭建的CORS代理就可以，有了这个就可以轻松使用Service Worker反代其他网站了。
当然对我来说其实有Access-Control-Allow-Origin: *就够了，我也不需要花里胡哨的请求方式，也不需要在请求头和请求体里加什么莫名其妙的东西，所以对我来说直接请求我的某一个镜像站就可以，于是代码如下：
index.html
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>Mayx的博客</title>
</head>
<body>
<script>
// 注册 Service Worker
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
.then(registration => {
console.log('Service Worker 注册成功:', registration.scope);
// 刷新网页
location.reload();
})
.catch(error => {
console.error('Service Worker 注册失败:', error);
location="https://mabbs.github.io";
});
} else {
location="https://mabbs.github.io";
}
</script>
<h1>Redirecting…</h1>
<a href="https://mabbs.github.io">Click here if you are not redirected.</a>
</body>
</html>
sw.js
const TARGET_SITE = '被反代的网站'; //也可以用CORS代理
self.addEventListener('install', event => {
// 强制立即激活新 Service Worker
event.waitUntil(self.skipWaiting());
});
self.addEventListener('activate', event => {
// 立即控制所有客户端
event.waitUntil(self.clients.claim());
});
self.addEventListener('fetch', event => {
if (new URL(event.request.url).origin == self.location.origin) {
event.respondWith(handleProxyRequest(event.request));
}
});
async function handleProxyRequest(request) {
try {
// 构建目标 URL
const targetUrl = new URL(request.url);
const proxyUrl = TARGET_SITE + targetUrl.pathname + targetUrl.search;
// 创建新请求（复制原请求属性）
const proxyRequest = new Request(proxyUrl, {
method: request.method,
// headers: request.headers,
// body: request.body
});
// 发送代理请求
const response = await fetch(proxyRequest);
// 返回修改后的响应
return new Response(response.body, {
status: response.status,
statusText: response.statusText,
headers: response.headers
});
} catch (error) {
console.error('Proxy error:', error);
return new Response('Proxy failed', { status: 500 });
}
}
最终的实际效果： https://mayx.nekoweb.org
虽然折腾了半天没能增强我博客的可靠性……但是体会到了现代浏览器的强大之处，难怪前几年会提出ChromeOS和PWA之类的东西，原来浏览器功能还是相当强大的，用了Service Worker以后即使是纯前端也可以有和使用服务器一样的体验，在过去的浏览器中要是想实现这样的功能……好像也不是不可能😂，用AJAX加服务器使用伪静态策略其实是可以做到的……其实Service Worker的功能更多还是在离线时使用的，我这个例子好像没体现它的优势😆。
但总的来说相比以前想要实现这种反代的功能代码还是更清晰，也更简单了，也许以后如果有机会我又有心思让博客在访客浏览器上离线运行，那就可以体现Service Worker真正的优势了🤣。
2025-07-24 00:00:00
Cloudflare的功能真是越来越多了，而且还免费！
前段时间我在登录Cloudflare的时候发现Workers上多了一个“浏览器呈现”的功能（可能已经出来一段时间了，不过之前一直没关注），看介绍，这个功能可以让Worker操作运行在Cloudflare服务器上的浏览器。这功能挺有意思，而且免费用户也能用，不如想个办法好好利用一下。
一般来说这个功能可以干什么呢？既然是在AI盛行的时候出现……估计是为了搞Agent之类的吧，不过看文档对免费用户来说一天也只有10分钟的使用时间，估计也没什么应用价值……那除了这个之外还能做些什么？我发现有好多博客主题喜欢给自己的README里添加一个能查看主题在多种设备上显示效果的预览图，以展示主题的自适应能力。那么既然现在能在Cloudflare上操作浏览器，那么我也可以做一个类似的，而且这个预览图还可以自动更新。
既然打算做预览图，那么我应该用什么方案？按照不同尺寸的视口截几张图再拼起来吗？这显然就太复杂了，况且在Cloudflare Workers中处理图片也相当困难。这时我想起来曾经见到过一个工具，只要输入网址，就可以在一个页面中同时展示网站在四种不同设备（手机、平板、笔记本电脑、台式机）上的显示效果，叫做“多合一网页缩略图”，实现原理是使用iframe和CSS缩放模拟多种设备视口。搜了一下发现这套代码被不少网站使用，所以就随便找了其中一个工具站把代码和素材扒了下来，稍微改了一下，然后放到GitHub上，方便等一会用Cloudflare访问这个部署在GitHub Pages上的页面来进行截图。
接下来截图就简单了，不过Cloudflare有两种截图的办法，用Workers的话可以直接用Puppeteer之类的库连接浏览器，但用这个库需要安装，要本地搭环境……我毕竟不是专门搞JS开发的，一点也不想在本地安装Node.js环境，所以就不想用这种方式。另外一种是通过调用Cloudflare的接口，这种非常简单，只需要填几个参数请求就行，唯一的问题就是要填一个Token……我一直觉得Worker调用Cloudflare自己的服务不应该需要Token之类的东西，毕竟内部就能验证了，没必要自己搞，但是我看了半天文档貌似无论如何只要想调接口就必须搞个Token……那没办法就搞吧，其实也很简单，只需要在“账户API令牌”里添加一个有浏览器呈现编辑权限的令牌就行。
至于展示……这个接口调用比较耗时，而且一天只能调用10分钟，截图的话估计也就够30次左右，还有每分钟3次的限制😓，所以实时更新肯定是不行了，图片肯定得缓存，一天更新一次感觉应该就够了。另外次数这么少的话写成接口给大伙用貌似也没啥意义，所以我就把地址写死了，于是以下就是最终实现的代码：
export default {
async fetch(request, env, ctx) {
const cache = caches.default;
const kv = env.SCREENSHOT;
const url = "https://mabbs.github.io/responsive/";
const date = new Date().toISOString().split("T")[0];
const cacheKey = url;
const datedKey = `${url}?${date}`;
// 工具函数：构建 Response 对象
const buildResponse = (buffer) =>
new Response(buffer, {
headers: {
"content-type": "image/png",
"cache-control": "public, max-age=86400, immutable",
},
});
// 工具函数：尝试从 KV 和 Cache 中加载已有截图
const tryGetCachedResponse = async (key) => {
let res = await cache.match(key);
if (res) return res;
const kvData = await kv.get(key, { type: "arrayBuffer" });
if (kvData) {
res = buildResponse(kvData);
ctx.waitUntil(cache.put(key, res.clone()));
return res;
}
return null;
};
// 1. 优先使用当日缓存
let res = await tryGetCachedResponse(datedKey);
if (res) return res;
// 2. 若缓存不存在，则请求 Cloudflare Screenshot API
try {
const payload = {
url: url,
viewport: { width: 1200, height: 800 },
gotoOptions: { waitUntil: "networkidle0" },
};
const apiRes = await fetch(
`https://api.cloudflare.com/client/v4/accounts/${env.CF_ACCOUNT_ID}/browser-rendering/screenshot?cacheTTL=86400`,
{
method: "POST",
headers: {
Authorization: `Bearer ${env.CF_API_TOKEN}`,
"Content-Type": "application/json",
},
body: JSON.stringify(payload),
}
);
if (!apiRes.ok) throw new Error(`API returned ${apiRes.status}`);
const buffer = await apiRes.arrayBuffer();
res = buildResponse(buffer);
// 后台缓存更新
ctx.waitUntil(Promise.all([
kv.put(cacheKey, buffer),
kv.put(datedKey, buffer, { expirationTtl: 86400 }),
cache.put(cacheKey, res.clone()),
cache.put(datedKey, res.clone()),
]));
return res;
} catch (err) {
console.error("Screenshot generation failed:", err);
// 3. 回退到通用旧缓存
res = await tryGetCachedResponse(cacheKey);
if (res) return res;
return new Response("Screenshot generation failed", { status: 502 });
}
},
};
使用方法很简单，创建一个Worker，把以上代码粘进去，然后把从“账户API令牌”中生成的令牌填到Worker的密钥中，名称为CF_API_TOKEN，另外再加一个名称为CF_ACCOUNT_ID的密钥，内容是账户ID，就是打开仪表板时URL中的那串16进制数字，除此之外还需要创建一个KV数据库，绑定到这个Worker上，绑定的名称是SCREENSHOT。如果想给自己的网站生成，可以Fork我的仓库，然后把里面首页文件中的网址替换成你的网站，然后再把Worker中的url替换成Fork后仓库的GitHub Pages地址就可以了。
最终的效果如下：
Cloudflare实在是太强了，虽然这个浏览器呈现免费用量并不多，但是有这么一个功能已经吊打很多Serverless服务了，毕竟浏览器对服务器资源的占用也不小，小内存的服务器甚至都不能运行，如果要自己搭的话成本可能也不小，而现在Cloudflare能免费提供，应该说不愧是赛博活佛吗🤣。
2025-07-13 00:00:00
即使是被入侵了也可以学到一些知识！
前几天，我闲来无事登录了一下一台之前一直闲置的服务器，登录上去后，乍一看似乎没有任何问题，然后习惯性的执行了一下top命令看了一眼。从进程列表来看，似乎没有什么明显异常的地方，但是服务器的load值很高，cpu的us值也很高。
以前我倒也遇到过几次load值很高的情况，一般是硬盘或NFS等网络存储挂了但是依然有程序在读写挂载的目录会有这种问题，但那种情况一般高的是cpu的wa值，而不是us值，us值是软件正常用掉的……但是进程列表里根本没有占CPU的程序啊……看来服务器是被入侵了😰。
虽然说是要查，但其实我根本不知道进程隐藏的原理😂，虽然听说过有恶意软件会这样做，现在遇到了一时半会又想不出来怎么找。还好这是台闲置的服务器，上面什么东西都没有跑，所以正常来说除了ssh连接之外，这个服务器不该有任何其他的连接，于是我执行了一下netstat -tanp看了一眼，发现有个奇怪的进程使用一个境外的IP和我的服务器建立了连接，用ps -ef查了一下这个 PID，结果进程名显示为[kcached]……这下给我整不会了。
后来查了些资料知道了可以用lsof -p查看进程读取的文件，才看到木马的本体：/usr/bin/gs-dbus。不过如果我只是杀掉这个进程然后删除文件，那攻击者肯定会重新回来，所以我得排除一下是不是还有别的木马文件。
一般来说攻击者权限维持的方式大多是crontab，不过我看了一下配置文件里似乎没有，root下的authorized_keys倒是有个陌生的公钥于是顺手删掉了……也没有其他文件夹下有gs-dbus文件……难道没有别的木马文件了吗？后来我仔细找了一下，发现有个很可疑的文件/usr/local/lib/libprocesshider.so，一看就不是什么好东西🤣，后来在GitHub上搜了一下，是libprocesshider这个项目，就是它让我在top中什么也没找到的，看文档中应用是添加一个/etc/ld.so.preload文件，所以解除隐藏效果我也只需要删掉这个文件就好啦。
不过感觉还是不够……所以我全盘搜索了一下libprocesshider.so文件，果不其然还有，通过那个文件在/usr/games里找到了木马的大本营，里面有一堆这个入侵者的工具，于是就顺手保存了一份然后从服务器上删掉了。
另外还有自启动到底是怎么实现的？既然不是crontab……应该是systemd。看了一下果不其然有个服务在保持gs-dbus的运行，不过程序我已经删了，所以它现在只会不停尝试重启，接下来只需要停止并禁用这个服务就行了。
至于为什么会被入侵……我也很清楚，其实并没有什么漏洞，单纯是设置的密码太简单了，被嘿客扫到啦！所以解决起来也很简单，把这些垃圾清除掉之后设置个稍微复杂一点的密码就行了。
既然这个嘿客都不删他的工具，留下来就是给我分析的吧？那么我就像上次一样分析一下他使用的工具吧～首先里面有个deploy-all.sh文件，看起来应该是登录服务器之后最先执行的程序，在这里面有个压缩包，解压出来之后搜了一下里面的文件，发现是Global Socket项目，看起来应该是包含反弹Shell、伪装以及权限维持之类功能的一个小工具。看了下源代码才知道原来用exec -a就可以伪装进程的名称，而且那个gs-dbus就是这个项目里的程序……这么看来挖矿的操作应该是入侵者远程执行的代码，所以在查找进程的时候发现了它吧。
除此之外里面还有个logclean项目，看了一眼是mig-logcleaner-resurrected项目，看起来应该是清除日志用的，不过我根本没从日志找它🤣，即使入侵者用了对我来说也没起到什么作用。不过倒也是个挺有用的项目，也许在某些扫尾工作很有用。
最后就是libprocesshider这个项目，也许还有其他隐藏进程的方式，不过知道这个项目之后最起码以后再遇到类似的情况我就会优先去看/etc/ld.so.preload文件了。
至于其他的就是一些爆破SSH的工具，估计是用来横向渗透的，看起来有点原始……也没啥用处，另外还有连接XMR矿池的一些配置文件，以及我也看不出来的玩意，应该就这么多有用的东西了。
虽然被入侵是没有预料的事情，但还好这个服务器是闲置的，装完系统之后上面什么有用的东西都没有，所以除了入侵者让它不太闲置赚了点小钱之外对我倒是没什么损失，另外还了解到了一些不错的小工具，这么看来入侵者赚的这点小钱就当是给他的学费吧🤣。
2025-07-01 00:00:00
虽然XML是机器读的内容……不过加上和主题一致的XSLT样式也算是一种细节吧～
在上一篇文章中，我提到在提高订阅源兼容性的时候给博客的订阅文件增加了一个XSLT样式。当时使用的样式是从About Feeds下的一个Issue中找的，里面有个基于Pretty Feed修改成能同时支持RSS和Atom格式的样式。虽然那个样式倒也说不上难看，但总觉得与我的博客整体风格有些割裂，所以这次打算制作一个和我博客主题完全一致的XSLT样式。
虽然想搞这么一个样式，但是我用的Jekyll引擎不能在引用的布局外添加额外内容……如果我要自己写，要么把我的默认布局拆成头和尾两部分然后用include引用，要么把默认布局的代码直接复制一份到XSLT样式中。这两个方案我都不太满意，第一种我以后在修改默认布局时需要同时从两个文件检查上下文，很不方便；而第二种方案违反了DRY原则，也会增加以后修改的难度。所以要怎么办呢？
后来我想了想，如果不能通过直接引用默认布局在外面增加XSLT的代码，那干脆让默认布局引用一个XSLT布局吧！这样我就能在不复制默认布局也不进行过多修改的情况下在外面套XSLT的代码了。于是我就在最外面写了个符合XSLT格式的XML布局，让默认布局引用它。然后再写一个布局引用默认布局，让最外面的布局根据这个布局的名字来判断是否需要使用XSLT的布局，具体的实现可以看我的layout目录。另外有一些地方需要注意一下，作为XML，内容中不能包含未闭合的标签，所有自闭合标签结尾必须添加斜杠，属性必须有值，以及所有标签和属性大小写要一致……还好我平时修改布局文件以及编写内容的时候基本上都遵循了这些规则，所以没什么太多需要改动的地方。
当时修改时，是模仿之前的那个样式进行的，原来那个样式在html元素上加了XML命名空间，但是xsl:output配置的输出却是按照HTML的方式输出，结果导致内容中用于换行的br标签在实际转换中全部变成了两个标签……我猜应该是转换器看到XML命名空间后，先按照XHTML的规则把br解析成了一开一闭的一对标签，然后又根据HTML的转换规则把这对标签当作两个单独的标签输出了吧……但奇怪的是，只有br标签出现了这个问题，像hr等其他自闭合标签则没有……既然如此，只要把XML命名空间删掉就OK了。
在改完之后虽然整体看上去和其他页面似乎已经很相似了，但总感觉还有些样式不太对劲……我猜应该是和文档类型声明有关系，我平时写的是HTML5，而XSLT默认转出来是HTML4.0……但是我不太清楚怎么解决这个问题，于是问了问AI，AI说在xsl:output中加上doctype-system="about:legacy-compat"就行。最终改完试了下确实有效😂，样式上也没有出现奇怪的偏移了。
最后把写好的布局应用到/feed.xslt.xml中就可以了，之所以是这个路径是因为我用的jekyll-feed只支持这个位置，至于我自己搞的RSS格式的订阅只需要在开头用xml-stylesheet指令声明一下就行了。
在写好给订阅文件用的XSLT样式之后，我发现XSLT样式本身也是个XML文件……既然我给订阅文件做了样式，那么也得给XSLT样式文件本身做个样式才对，但如果我单独写一个给它的样式，那岂不是要给样式的样式再写一个样式😂，所以肯定不能这样做。不过仔细想一下，还有个办法，可以让XSLT样式文件自引用自身的样式，这样就能避免之前担心的套娃问题了。所以接下来我应该在XSLT中写一个检测应用样式的XML文件是不是XSLT样式文件的代码，方法很简单，既然XSLT样式中肯定包含xsl:stylesheet这个元素，那么我可以判断如果存在这个元素，就可以确定这就是XSLT样式了，如果有人点开看了我就可以展示一个提示信息告诉访客这是一个样式文件，这样访客就不会看到那句“This XML file does not appear to have any style information associated with it. The document tree is shown below.”了😝。
既然给XSLT样式也加了样式……那我博客还有其他XML文件需要处理吗？似乎还有个Sitemap，我的Sitemap是jekyll-sitemap插件生成的……那它支持加样式吗？虽然文档上没有写，不过看了眼源代码发现可以通过创建/sitemap.xsl文件添加，所以就顺手套用之前的样式搞了一个（虽然应该没有访客去看Sitemap😂，毕竟这是给搜索引擎用的）。可惜这些地址都是插件硬编码的，如果可以自己修改位置我就只写一个XSLT样式文件就可以了……
折腾了这么多整体展示效果还不错，虽然这些文件也许根本没人看😂（本来就不是给人读的），但也算展现了一下博客的细节之处吧，而且在折腾的时候至少还了解了不少关于XML和XSLT的知识（尽管在现代这些好像没啥用了）。当然重要的也许不是了解这些知识，而是这个过程吧……总的来说还是挺有意思的。
2025-06-02 00:00:00
在修改博客的时候也能学到不少新知识啊～
在两个月前，我写了一篇针对博客搜索功能优化的记录。在写完之后没几天，有位名叫@xymoryn的大佬看到了我的博客并且进行了吐槽，内容很值得参考。不过我自从用minimal主题以来从来没有改过样式的原因主要还是写不来CSS😂，并不是真的不想改，但其中提到可以让AI优化，我觉得也很有道理，现在AI这么发达实在不会用AI改就好啦～
虽然大佬给出了参考的CSS，但我不太喜欢那种风格，尤其还把之前的左右布局改成了上下布局。我当年之所以选择minimal主题就是因为它是左右布局的，如果选择上下布局的话我还不如用hacker这个主题，另外那个参考的CSS可能是因为AI写的，有很多没有考虑到的地方，比如主题自带的CSS鼠标放到链接上字体会变粗，然后可能会变宽，导致影响整体的布局，而参考的CSS选择直接让所有的链接放到上面都变细，即使原来是粗字体也变细，比如标题之类的，这就更难受了。像这种情况要怎么改呢？我还是希望能用minimal主题的CSS，但让链接变粗的体验确实不太好，所以我选择问问AI。
最后AI给出的答复是使用font-weight: inherit;，看起来确实解决了问题，不过如果鼠标移到链接上没有任何反应也不太好，所以就学GitHub在鼠标移到链接时加上了下划线。
除此之外就是字号、行高和布局，字号和行高我也不希望改的太激进，所以就稍微加了一点点，看起来没那么密就好。至于布局，之前minimal主题的宽度是写死的，左边是270px，右边是500px，对于我的MacBook看起来也还好，因为MacBook的屏幕比较小，屏幕的利用率还是比较高的。不过对于更大的屏幕总共860px大小的区域确实不太够，尤其是4K屏幕可能只有中间一点点的区域有内容，会看着很难受，所以我想了一下还是改成百分比布局比较好，这样无论屏幕有多宽也能利用得到。
还有一点就是分段，虽然我也知道在Markdown中两个换行是分段，但是感觉在文本中两个换行隔得太远了，所以一开始写文章的时候就选择只换行。不过在中文里确实不分段也不太好看，但是又不想去动之前写的文章，那该怎么办呢？思来想去干脆把换行全部替换成分段好啦，在Jekyll中可以用replace过滤器把所有的“<br>”替换成“</p><p>”，因为Markdown解析本来就会有一个段落，所以直接闭合加开始就能分割成多个段落了。那么加了分段是为了什么？其实主要是为了首行缩进，有首行缩进对阅读还是有挺大帮助的，至于怎么做也非常简单，直接给p标签设置text-indent: 2em;就可以了。
最后就是评论授权的问题，我用的Gitalk也有人问了这个问题，我仔细看了一下GitHub官方文档中OAuth可以授权的作用域发现确实是没办法限制只写Issues😥，至于其他的评论系统对后端的依赖又太多了，尤其是Giscus，居然是直接用iframe引用Giscus网站中的页面😅，如果Giscus哪天挂了，那评论系统不也挂了（虽然GitHub也不可靠……），至于自托管就更不可能了，我能让服务器持续运营可比不上大厂😆。所以最后我选择给Gitalk加个提示，不想登录也可以跳转到GitHub上进行评论，至于怎么加？还是让AI来吧，最后AI给我写了这么一串CSS：
.gt-btn-login::after {
content: "如果不想登录，请点击上方评论数跳转至对应ISSUE进行评论";
position: absolute;
top: 100%;
left: 50%;
transform: translateX(-50%);
background: #333;
color: #fff;
padding: 8px 12px;
border-radius: 4px;
font-size: 12px;
white-space: nowrap;
opacity: 0;
visibility: hidden;
transition: opacity 0.2s, visibility 0.2s;
z-index: 10;
}
.gt-btn-login:hover::after {
opacity: 1;
visibility: visible;
}
.gt-btn-login::after {
margin-top: 8px;
}
.gt-btn-login::after {
box-shadow: 0 2px 8px rgba(0,0,0,0.15);
}
至此，关于博客样式的部分我觉得已经提高不少读者的用户体验了，也感谢大佬提出的建议。
最近由于某些原因我又用起Windows 7了。其实我觉得Windows 7是一个很不错的操作系统，有很多人性化的东西，比如桌面小工具，自带Feed订阅，还有Windows Live Essentials等等，可惜后来全部被微软砍掉了🤣。考虑到Windows 7如此优秀，那要不然兼容一下它旗下的Internet Explorer 8浏览器吧？
其实GitHub给的那些Jekyll主题本身都是兼容IE8的，包括我在用的minimal主题也一样。但随着我这么多年加了许许多多的功能，绝大多数功能都没有考虑兼容性，只想着能用就行。不过我写的功能基本上都非常简单，如果想改得让它兼容IE8也并非难事，只要理论上可行就可以。当然也有些理论上不可能的东西，比如WebGL。因此，我的Live2D看板娘就没有任何可能性被支持了，至于其他的……也许有一些理论上可以支持，但是改起来比较麻烦的就也算了吧（比如Gitalk之类的）。
其实我的文章点击计数器从之前改成用jQuery调用自己的接口以后就没有什么兼容性的问题了，因为jQuery本来就是处理浏览器之间差异的库，而且也是兼容IE8的。只不过有个问题是IE8不支持用XHR跨域请求，只能用“XDR（XDomainRequest）”进行跨域请求……还好有个现成的库能让jQuery在遇到这种情况时使用XDR请求，于是我就用条件注释让IE9以下的浏览器引入这个库，这样在IE下也能正常显示文章点击数了😆。
在IE8中的CSS是不支持媒体查询的，所以在修改窗口大小时也不能根据情况使用合适的样式。本来我没打算解决这个问题，结果恰好看到了一个库：Respond.js，所以就直接拿来用了😝。
其实从功能的角度来说这种东西肯定是在IE8下可以实现的，但是我用的那个库有点迷，到处都用的是const关键字结果还莫名其妙判断XHR搞的好像是在兼容旧浏览器？改起来有点麻烦懒得搞了……不过除此之外还有个取巧的方式，既然我搜不了，干脆让谷歌来搜吧，至于谷歌支不支持IE8就不是我的事了🤣，所以直接给搜索框外面套了一个form表单，这样甚至可以在不启用JS的情况下搜索（假设谷歌支持没有JS的情况）。
之前我的博客对订阅的支持是使用的官方的jekyll-feed插件，它只支持Atom格式的订阅，一般的阅读器也是支持这种格式的（即使是IE8也是完美支持）。但是我发现有非常少数的某些网站没办法解析Atom，只支持RSS……所以我只好特地加了对RSS格式的支持，还顺带搞了支持Atom和RSS格式的XSLT模板来预览。既然RSS也支持了，那干脆连JSONFeed也一起做了吧😆，虽然意义不是很大……
既然要兼容IE8，那当然是能用的都用啦，在IE8订阅网站源的地方，有一个‘添加网页快讯’的功能。因为没有可以参考的网站，我甚至都没理解这个功能展现的效果是什么样的。我看这个网页快讯好像是抄了一部分hAtom Microformat的规范，我还以为是每个条目都单独需要一个entry-title和entry-content，结果发现并不是😅，一个hslice只能有一个entry-title……
这个功能其实非常简单，主要作用就是把网页的一部分切出来单独展示，当这一部分发生更新的时候IE浏览器就会提示用户。然后在这之中hslice要包裹所有需要处理的元素，写到最外面元素的class中就可以，entry-title是希望用户订阅时展示的名字，而entry-content是被切下来展示的网页。具体的内容可以在微软官方文档中看到。
既然说到Microformat，那就要提到IndieWeb了。虽然这个东西网络上也没几个人搞，但看起来有点意思就整下玩玩呗。
根据他们的入门教程来看，成为IndieWeb最重要的一点就是有自己的域名。看到这一点我都怀疑这是不是卖域名的用来忽悠人的玩意？我一分钱也不想给域名注册商，虽然DNS这套系统确实维护需要成本，但是能有多大成本呢？绝大多数不都让ISP摊了？另外他们所说的大公司的服务可能会消失，那么域名就不会吗？注册商和注册局完全有能力让你的域名用不了，这也是我们不可控的东西，因此尽管这对于IndieWeb很重要，但是我不打算搞，于是我的博客就不是IndieWeb了🤣。
没有域名也不影响接下来的步骤，大公司的域名也是域名（虽然不属于我）。根据教程来看，支持IndieAuth非常简单，只需要在head中加一个rel=me的link标签，指向IndieAuth支持的个人主页，并且那个个人主页有一个反链指向自己的网站就可以，比如指向自己的GitHub主页，那么就可以使用GitHub登录来验证这个网站属于我。这一步可以使用IndieWebify.Me来验证。
在发布前，为了更好的让其他软件读取网站内容，需要用microformats2来标注网站内容，这个倒也不复杂，可以根据这个教程按照上面所说的东西用class名去标注对应的元素，标注完之后就可以用IndieWebify.Me验证了。
除此之外还需要用h-card标注网站的身份，解析完之后可以当网站名片用，具体可以看这里。
另外还有一点就是Webmentions，在网站上声明Webmentions可以让别人引用你的文章时通知一下你。不过对于静态博客不是很友好。一是要收，收完还要展示，二是要发，引用了别人的文章如果对面支持Webmentions要把自己引用的文章链接发给对方。虽然Jekyll有插件可以支持，但是我用GitHub额外装插件还得自己写Actions，而且我发布一次要在一堆Pages上更新，也不太适合，所以我打算光收不发（只需要在link标签中添加Webmentions的端点就可以），也不展示了，而且国内根本没几个人用Webmention🤣。如果有人对谁给我发了Webmention感兴趣，可以在这里查看（不过绝大多数都是我自己手动发的🤣）
如果谁有兴趣给自己的网站添加完整的Webmention，可以用Webmention Rocks!进行测试（如果使用了WordPress是自带的，只需要打开相关的功能就可以）。
在IndieWeb中有一个很重要的事情就是相互交流，搞这个比较重要的目的是为了避免大公司的服务炸了，所以要替代比如推特，Facebook之类的服务，但是在这些服务还没炸的时候仍然可以在上面发自己的网站，也算是引流吧。他们把这个行为叫做POSSE。对我来说，我在微信、QQ之类的上面发自己新写的文章就算是POSSE了，毕竟我又不玩国外的社交平台😆。
除此之外似乎还要把别人的评论同步到自己网站？我能做到的顶多就是Gitalk了，更多的就算了吧～
既然已经支持了IndieWeb，那么不妨加入IndieWeb Webring吧。在IndieWeb Webring 🕸💍中的大多数网站都是适配了IndieWeb的，加入他们也算是证明自己适配IndieWeb的努力了吧😊。
以前为了应对GitHub的不可靠，我仅仅是在各个Pages上部署了我的网站，但是后来我想了想Git本身就是分布式的，分发是一件很简单的事情啊，我要是想提高博客的可靠性，不如直接用Git分发到各个Git托管商就好了啊～因此我就利用GitLab镜像仓库的功能，一键把我的网站同步到数十个知名的Git托管商，提高了网站的可靠性，具体的列表可以在这里查看。
在这次的博客优化中，了解了不少新的东西啊，不仅学习了CSS，还有了解如何提高网站兼容性，以及提高了博客的可靠性和曝光度。果然折腾博客本身也能提高自己啊，还能写文章分享一下折腾的经验😆。虽然折腾的内容不一定能在未来的生活中用得上，但是有意思就足够了😁。
2025-05-07 00:00:00
使用最强的Macintosh是一种什么样的感受？
在两个月前苹果公司出了一款可以选配超大统一内存（512GiB）的Mac Studio，那时候我还想着如果市场反应好就整台玩玩，现在从网上的各种反应来看这确实是一个很不错的产品，所以这次我就整来啦！所以这次就来谈谈初上手的体验吧～
虽然Mac Studio理论上拿来剪电影之类的应该是更好的选择，但是显然我不会剪电影🤣，而且也没有合适的屏幕给它用，所以拿到手之后我需要让它可以远程使用。
macOS配置远程还是挺简单的，只需要在设置 -> 通用 -> 共享中打开远程管理就可以了（似乎现在Ubuntu也可以像这样轻松地配置远程桌面），配置好之后需要启用“任何人都可以请求取得控制屏幕的权限”选项，不然可能会连不上……
另外如果需要配置SSH也只需要打开远程登录即可，最好把“允许远程用户对磁盘进行完全访问”也打开，免得使用时还需要额外的操作。
其实开启远程没什么特别的，不过我发现在远程Mac Studio时和我远程Intel芯片的Mac mini 2018以及黑苹果有一个不一样的地方，那就是屏幕共享类型可以选择“高性能”，在这个模式下远程的屏幕就可以变成一块虚拟屏幕，不受Mac连接的屏幕分辨率所影响，可以配置动态分辨率。即使连接的屏幕不支持HiDPI，只要远程的客户端支持那就可以支持，这一点和Windows的远程桌面有点像，但是体验好太多了，使用起来和本地几乎没有差别，当然代价就是对网络要求特别高，基本上如果不是局域网内远程，就不能使用这个模式。
在我配置好远程后我就可以拔掉屏幕，然后把Mac Studio放在阴暗的角落里为我服务了😆。
买这个设备的当然也不为别的，主要就是为了能在本地跑完整参数的DeepSeek-R1，或者类似的MoE模型。至于KTransformers方案考虑到按照正价买要更贵（当然有便宜的购买方案，但是太不可靠了），而且这个框架也不够成熟，所以就算了。
在Mac上运行LLM有很多框架，最开始我选择的是Xinference，因为看它的文档中特地提到了苹果的MLX框架，而且可以使用命令启动，方便维护，另外看它支持的模型种类也比较多，所以就先考虑了它。
按照官方文档安装后就可以配置模型了，虽然它可以直接一键下载并运行模型，但是我已经提前下好了模型，另外……如果光运行DeepSeek-R1感觉也没啥意思，不如试试Perplexity AI的某个Finetune模型😆？所以我需要手动注册模型。配置好之后在MaxKB中配置好地址就可以使用了。
刚开始测试的时候倒是没啥问题，吐字的速度确实是挺快，但是用了几下就发现有不少问题，比如每次调用LLM的时候会发现内存压力会上升，APP内存会变成联动内存，在这个期间GPU并不会工作，需要等几秒钟，在生成结束的时候内存压力又会下降，联动内存会变回APP内存，每次生成都是这样。另外如果上文很长就要等几分钟，而且如果上文特别长的情况爆内存程序会直接卡死，还有并发也会导致程序卡死……总的来说这个框架根本不适合生产环境使用，而且文档也写的极其糟糕，看来是我看走眼了，不应该选择Xinference。
在抛弃Xinference之后我想了想还是随大流吧，选择了LM Studio，虽然它需要远程桌面操作，但是配置好之后应该也没有什么太多需要修改的地方，主要是社区相对要活跃得多，出了问题也好解决。
在我安装好LM Studio后发现这个支持的功能要多不少啊，还支持KV Cache量化，有了这个就可以支持更长的上下文了，另外它还支持超出上下文之后选择截断还是滚动，看起来使用非常的友好。
当我对LM Studio充满期待的时候问题就来了，我随便问了些问题，然后它回答的时候不知道什么情况会随机莫名其妙的冒出“<｜begin▁of▁sentence｜>”，出现这个之后后面的内容就会胡乱生成内容，怎么调都没法解决……后来看了一下DeepSeek的Issue里提到了似乎需要在模板中添加“<think>”标签才可以……但是这样的结果就是输出开头没有“<think>”了，MaxKB解析会出问题……这个问题的话回头看怎么解决吧，至少在模板中加上这个能正常使用了。LM Studio不会每次请求都重新加载一遍模型，输出第一个字的速度比Xinference快了很多，后面生成的速度也很快，输出的速度能接近20T/s，相比来说还是更有用一些。
在我测试完DeepSeek-R1的某个微调模型后，最近阿里又出了一系列新模型：Qwen3，支持根据问题进行推理，据说它的235B参数的MoE模型比DeepSeek-R1还厉害，如果是真的，那就不需要用DeepSeek-R1了，虽然Mac Studio可以运行DeepSeek，但是512GiB内存也只能运行4位量化的DeepSeek-R1，而235B的Qwen3则可以用8位量化，还能空出不少内存用于上下文，想来应该效果会比DeepSeek好很多吧？于是我就下载试了试，然而刚下载好之后居然不能运行😅，首先是这个模型太新了，运行前需要把运行库的版本更新到最新，另外默认的模板有问题，解析会报错，需要根据这个Issue修改一下才能正常运行😅。在一切准备好之后，就可以进行测试了。
首先我试了试一些比较简单的问题，Qwen3回答的都还不错，例如24点、内容填空之类的，效果比QwQ-32B好了不少。测试的时候输出的速度和671B 4位量化的DeepSeek-R1基本一致。随后我让它用Mermaid绘制我以前写的AI摘要脚本的流程图，Qwen3绘制的结果是：
graph TD
A[开始] --> B{解析URL路径}
B -->|/summary| C1[查询内容]
C1 --> D1{是否存在内容?}
D1 -- 是 --> E1[构建AI摘要提示词]
E1 --> F1[调用Qwen模型生成流式响应]
F1 --> G1[返回SSE流]
D1 -- 否 --> H1[返回'No Record']
B -->|/get_summary| C2[查询内容]
C2 --> D2{是否存在内容?}
D2 -- 否 --> H2[返回'no']
D2 -- 是 --> I2[计算内容SHA-256]
I2 --> J2{哈希匹配?}
J2 -- 否 --> H3[返回'no']
J2 -- 是 --> K2[查询摘要]
K2 --> L2{是否有摘要?}
L2 -- 是 --> M2[返回现有摘要]
L2 -- 否 --> N2[调用Qwen生成新摘要]
N2 --> O2[存储摘要到数据库]
O2 --> M2
B -->|/is_uploaded| C3[查询内容]
C3 --> D3{是否存在内容?}
D3 -- 否 --> H4[返回'no']
D3 -- 是 --> I3[计算内容SHA-256]
I3 --> J3{哈希匹配?}
J3 -- 否 --> H5[返回'no']
J3 -- 是 --> K3[返回'yes']
B -->|/upload_blog| C4{POST方法?}
C4 -- 否 --> H6[返回'need post']
C4 -- 是 --> I4[获取请求文本]
I4 --> J4[查询现有内容]
J4 --> K4{是否存在?}
K4 -- 否 --> L4[插入新内容]
K4 -- 是 --> M4{内容是否改变?}
L4 --> N4[返回'OK']
M4 -- 是 --> O4[更新内容并清空摘要]
O4 --> N4
B -->|/count_click*| C5[计算ID的MD5]
C5 --> D5[查询计数器]
D5 --> E5{是否含路径_add?}
E5 -- 是 --> F5[更新计数器+1]
E5 -- 否 --> G5[保持原值]
F5 --> H5[返回最新计数]
B -->|其他路径| I6[重定向到GitHub]
DeepSeek-R1的某个微调模型的结果是：
graph TD
A[接收请求] --> B{解析URL路径}
B --> |路径为/summary| C[获取查询参数id]
C --> D{id是否为null?}
D -->|是| E[返回错误响应]
D -->|否| F[查询数据库内容]
F --> G{内容存在?}
G -->|否| H[返回'No Record']
G -->|是| I[构建消息,调用AI生成摘要流]
I --> J[返回流式响应]
B --> |路径为/get_summary| K[获取id和签名参数]
K --> L[查询数据库内容]
L --> M{内容存在?}
M -->|否| N[返回'no']
M -->|是| O[计算SHA-256签名]
O --> P{签名匹配?}
P -->|否| Q[返回'no']
P -->|是| R[检查是否已有摘要]
R -->|有摘要| S[返回摘要内容]
R -->|无摘要| T[调用AI生成摘要]
T --> U[更新数据库]
U --> S
B --> |路径为/is_uploaded| V[获取id和签名]
V --> W[查询数据库内容]
W --> X{内容存在?}
X -->|否| Y[返回'no']
X -->|是| Z[计算SHA-256签名]
Z --> AA{签名匹配?}
AA -->|否| AB[返回'no']
AA -->|是| AC[返回'yes']
B --> |路径为/upload_blog| AD{方法是否为POST?}
AD -->|否| AE[返回'need post']
AD -->|是| AF[读取请求体数据]
AF --> AG[查询现有内容]
AG --> AH{记录存在?}
AH -->|否| AI[插入新记录]
AH -->|是| AJ{内容是否相同?}
AJ -->|否| AK[更新内容并清空摘要]
AJ -->|是| AL[直接返回OK]
AK --> AL
AL --> AM[返回'OK']
B --> |路径为/count_click| AN[计算MD5哈希]
AN --> AO[查询当前计数]
AO --> AP{记录存在?}
AP -->|否| AQ[插入新计数]
AP -->|是| AR[增加计数]
AR --> AS[更新计数器]
AQ --> AS
AS --> AT[返回当前计数值]
B --> |其他路径| AU[重定向到GitHub页面]
style A fill:#f9f,stroke:#333,stroke-width:2px
style E fill:#f96,stroke:#333
style H fill:#f96,stroke:#333
style Q fill:#f96,stroke:#333
style N fill:#f96,stroke:#333
style S fill:#9f9,stroke:#333
style AC fill:#9f9,stroke:#333
style AM fill:#9f9,stroke:#333
style AT fill:#9f9,stroke:#333
style AU fill:#99f,stroke:#333
subgraph 函数调用
O -.->|调用sha函数| SHA[计算SHA-256]
AN -.->|调用md5函数| MD5[计算MD5]
end
subgraph 数据库操作
F --> DB1[SELECT content]
L --> DB2[SELECT content]
R --> DB3[SELECT summary]
T --> DB4[UPDATE summary]
AG --> DB5[SELECT content]
AI --> DB6[INSERT新记录]
AK --> DB7[UPDATE content]
AO --> DB8[SELECT counter]
AQ --> DB9[INSERT计数器]
AR --> DB10[UPDATE counter]
end
subgraph AI处理
I --> AI1[构建系统提示]
AI1 --> AI2[调用Qwen模型]
T --> AI3[调用Qwen模型]
end
这下就高下立判了🤣，同样的问题Qwen3只绘制了基础流程图，而DeepSeek-R1不仅包含子流程图，还通过颜色区分了响应类型，这么看来Qwen3还是不太行啊～当然我的测试非常的片面，仅仅根据这几次测试分析的结果。至于Qwen3到底有没有使用价值，回头再让其他人测测看效果如何吧。
在上次在UTM上用苹果虚拟化框架安装Windows的测试中我用的是Intel芯片的Mac，那时候已经说了打算等Mac Studio到了之后尝试一下用VZ框架安装Windows。那么经过我的测试结果如何呢？想不到居然失败了😭，相同的操作流程在重装脚本执行完后，再重启就没有任何反应了。在活动监视器中虽然可以看到虚拟机的CPU占用是100%，但是内存只占用了100多MiB，而且CPU占用没有任何跳变，显然系统没有正常启动。随后我又尝试在QEMU中安装好Windows然后把VZ虚拟机的硬盘替换掉，结果依旧一样，内存还是只占了100多MiB……看来ARM处理器和x86处理器还是有很大区别啊……
不过这个虚拟机到底有什么区别？为什么会无法启动呢？想到我在Intel芯片的Mac中测试用VZ框架是可以看到CPU型号的，再看看Mac Studio中的Linux虚拟机……似乎没有任何与CPU型号有关的信息，用QEMU至少也能看到类似“virt”之类的CPU型号，用VZ框架就什么信息都没有了……看来Apple芯片和正常的ARM处理器还是有不少区别啊……
不过除了这个以外还有什么有意思的东西可以测试吗？这时候我就想到了Asahi Linux，Apple芯片下的UTM有一个多出来的选项就是可以安装macOS虚拟机，那我能不能在macOS虚拟机中安装Asahi Linux呢？根据我的实际测试，结果也是不行的……因为Asahi Linux不支持M3 Ultra芯片😞，至于M2芯片能不能在虚拟机中运行Asahi Linux……虽然我的MacBook是M2芯片，但是不太想在我常用的机器上搞测试，所以也不知道实际上可不可以。另外Asahi Linux这个项目也基本上停了，估计以后新出的芯片也不会有机会安装Linux了，就像在macOS上运行Windows程序的Whisky项目也停了……真是太遗憾了😢。
从这次体验来看，512GiB内存的Mac Studio M3 Ultra确实很厉害，本地跑LLM速度非常快，20T/s的速度已经很厉害了，而且风扇声音很小，在GPU满载的时候也完全听不到风扇的声音。当然这个前提是跑MoE模型，虽然我没测Dense模型，但想来根据M3 Ultra的算力，跑70B参数的模型肯定是达不到20T/s的，至于更大的模型估计速度就慢的不能看了……不过不影响，这已经够我用了。
至于除LLM以外的用途……我似乎没有什么能用到这么强性能以及这么大内存的地方了……其实还是挺浪费的，但是也没办法，毕竟我又不会剪电影啊🤣。
