Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feedermabbs.github.io
Mayx的博客
Get the latest updates from Mayx的博客 directly as they happen.
Follow now 35 followers
Latest posts
Last updated 3 days ago
近期LLM的部署与应用经历(3)
3 days ago
用更多的方式探索AI！ 起因 在一年前，我整了张RTX4090 48GiB魔改版用来跑DeepSeek-R1 70B的4bit量化模型，不过都已经过了这么长时间，这个模型也已经是过时的东西了……我之前在Mac Studio M3 Ultra上试了一下OpenAI在半年前出的gpt-oss-120b模型，感觉效果还挺不错，只不过因为M3 Ultra的GPU实际性能比不上正经高端的独显，所以它在上下文很长的情况下还是有点慢，因此我又整了张RTX4090 48GiB，想整个双路试试更快的GPT-OSS模型，总共96GiB的显存应该够跑这个模型了。 在两张RTX4090 48G上运行GPT-OSS...
在Google杀死XSLT之后的XML美化方案
24 days ago
即使没有了XSLT，也不能让读者看到光秃秃的XML！ 起因 在半年前，我写了一篇用XSLT美化博客XML文件的文章，自从那以后，每次我在浏览其他人博客的时候，都会看一眼对方博客有没有给自己的订阅文件做美化。不过就在前段时间，我在浏览某个博客的时候，发现他博客的订阅文件，甚至连最基本的XML文档树都没有显示出来。这时候我打开开发者工具看了一眼源代码，发现他也并没有使用xml-stylesheet之类的指令……而且控制台貌似报了些错，好像是出现了什么CSP错误……于是我就想，浏览器显示XML文档树的本质，会不会其实也是一种XSLT？之所以报错也有可能是浏览器在自动引用内置的XSLT时违反了CSP。所以我就问了问谷歌AI，结果似乎真的是这样，比如火狐浏览器就内置了一份XSLT文件，IE浏览器也有。正当我为XSLT的功能感到强大时，谷歌AI随后提到，Chrome浏览器决定弃用XSLT，所以以后不要再用XSLT了😰…… 我给我的订阅文件加美化功能才半年，怎么就要不能用了？XSLT出现这么多年都还能用，结果等我加上就要废弃了？当时为了增加这个功能，还是费了不少劲的，怎么能让谷歌说没就没？于是我就开始对这件事进行了调查。 Google杀死了XSLT 从上面Chrome的弃用XSLT文档中，可以发现，这件事的始作俑者是Mason Freed，他在WHATWG中发起了一个Issue，因为XSLT用的人很少，以及实现XSLT的库很老而且容易出漏洞，所以建议把XSLT从Web标准中删除。在这个Issue中可以发现，有很多人表示不满，毕竟这个功能对想要给自己订阅做美化的博主来说还是很有用的。为了对抗谷歌，还有人做了个网站： https://xslt.rip 。 而且XSLT虽然用的人占比也许不高，但从总量上应该还是挺多的，除了用XSLT美化博客订阅的，甚至还有用XSLT作为博客框架的，另外还有一些人提出一部分政府网站也有使用XSLT。 不过Freed看起来对这件事早有准备，他做了一个Polyfill库，通过WASM的方式让XSLT可以正常工作，为了方便大家使用这个库，我顺手给CDNJS发了个PR，以后可以用CDN引用它了。不过使用这个库的前提是需要在订阅中加一段引用JS的代码，像我博客中的Atom订阅，用的是jekyll-feed插件，里面的格式都是写死的，就用不了了…… 只不过现在已经没办法阻止谷歌了……而且其他浏览器也表示会跟进，看来我们唯一能做的就是去适应了。...
年终总结
2 months ago
0 error(s), ∞ warning(s) 2025年的状态 在2025年，感觉状态不如去年……由于没能做出正确的选择，还是有点糟糕。不过总的来说还没有引发关键性的错误，至少还能继续坚持下去。 在这一年中，感觉记忆和思考能力都有所下滑，看来是没把自己照顾好😂，不过看看这一年写的文章，看起来似乎比以前更流畅了，这也许是因为和AI聊得多了，以至于思维有点偏向AI了吧。 总的来说感觉自己的稳定性还是有点低了，但这可能不是我能独自解决的，也不知会有什么转机…… 2025年发生的事情 回顾了一下去年的年终总结，发现自己还是没能做到知行合一，在这一年里全球各类资产突然开始大幅升值，也就是说钱真的开始不值钱了……那时候想着买黄金，这一年下来却没能下定决心，最终错过了资产保值的机会。至于现在，似乎什么也做不了了……当然这对我的生活并没有造成什么严重的打击，只是感受到环境对自己的影响罢了。 至于AI……依然是一天比一天强，而各个公司对AI的投入相比去年也是极大的提升，当然出来的效果也是非常强，那时候的AI还是挺容易出错，但是现在AI解决问题的能力已经可以替代很多人了，不只是文本生成模型，今年的图像与视频生成模型也真的是发展到了以往完全不能想象的地步，真的可以做到一句话想要什么就有什么了。 另外，今年写的博客内容过于围绕博客本身了，以至于似乎不太跟得上时代，虽然我的博客也确实有点老旧了😆。只是看看以前的文章，都还有一些面向未来的趋势，而今年就有点“考古”了。相比于考古，去展望未来显然是更有意义的事情，只不过……真的感觉脑子不太好使，未来会发生什么，已经完全无法预测了。...
在浏览器中运行Linux的各种方法
3 months ago
浏览器已经无所不能了！ 起因 前段时间跟网友交流时，有人展示了他博客里的一个Linux终端模拟项目：jsnix，看起来挺有意思的，里面甚至还藏了一个CTF。不过我感觉他这个终端和博客本身并没有真正联动起来，本质上只是一个模拟了Linux Shell行为的交互界面。除此之外我还发现了另一个风格类似的个人主页，它虽然也走了终端风格，但功能更简单，还原度也不算高。不过它至少和博客内容做了一些基础联动——尽管目前也只是做到列出文章这种程度😂，当然有这类功能的博客应该也不少，只是我发现的不太多……于是我就想，不如我也给自己的博客加一个类似的“命令行访问”功能，应该会很有趣。当然如果真要做的话，我肯定不会满足于只实现几个模拟指令——既然要做，就要追求真实感，至少得在浏览器上运行真实的Linux终端，才不会让人觉得出戏吧😋。 在浏览器中运行Linux 虚拟机方案 纯JS虚拟机 要说到在浏览器上运行Linux，最先想到的应该就是Fabrice Bellard大神写的JSLinux吧，这可能是第一个在浏览器中实现的虚拟机（毕竟是最强虚拟机QEMU的作者编写的）。现在他的个人主页中展示的这个版本是WASM版本，而他最早写的是纯JS实现的。那个JS实现的版本现在在GitHub上有一个去混淆的版本可以用作学习和研究，于是我顺手Fork了一份在GitHub Pages上部署作为演示。 作为纯JS实现的x86虚拟机，性能估计是最差的，但相应的兼容性也最好，在Bellard当年写JSLinux的时候，还没有WASM这种东西呢，所以即使是在不支持WASM的IE11中，也可以正常运行。假如我想把它作为终端用在我的博客上，似乎也是个不错的选择，即使我完全看不懂代码，不知道如何实现JS和虚拟机的通信，它也预留了一个剪贴板设备，可以让我轻松地做到类似的事情，比如我在里面写个Bash脚本，通过它和外面的JS脚本联动来读取我的文章列表和内容，那也挺不错。 当然Bellard用纯JS编写虚拟机也不是独一份，他实现了x86的虚拟机，相应的也有人用纯JS实现了RISC-V的虚拟机，比如ANGEL，看起来挺不错，所以同样也顺手搭了一份。只不过它似乎用了一些更先进的语法，至少IE11???不能运行。...
让博客永恒的探索
4 months ago
Mayx Forever Project – Phase II 起因 在前段时间，我通过Ecosyste.ms: Repos找到了不少Git平台的实例，也在探索的过程中发现和了解了Tilde社区。当然仅仅是这样显然还不够，里面的实例太多了，显然还有一些其他值得探索的东西。 在我查看这里面的某些Gitea实例时，发现了一些奇怪的事情，有些实例的仓库数和用户数多得离谱，正常来说除了几个大的平台，绝大多数应该只有几十到几百个仓库，这就让我有点好奇了。于是当我点进去之后发现，里面有一大堆仓库都是空的，而且用户名和仓库名都非常有规律，看起来都是一组单词加4位数字命名的，显然这不是正常现象，应该是一种有组织的行为。 被SPAM滥用的Git实例 于是我就简单看了一下这些异常的仓库和用户的规律，可以发现每个用户都填了个人主页地址，然后个人简介里大都是一段广告词。另外这些个人主页的地址看起来很多都是利用公开可注册的服务，比如开源的有各种Git平台、Wiki，以及论坛，还有一些允许用户写个人主页的新闻网站。在这其中，Git平台大多都没有广告文章，基本上都是通过个人主页地址链接到网站，而Wiki之类的就会写一些篇幅比较长的广告文章。...
一次找回GitHub上被删除仓库的经历
5 months ago
在GitHub中寻找踪迹也许是非常简单的事情…… 起因 前段时间，有人和我聊天的时候提到了Brainfuck语言，让我回想起了高中时写的演讲稿。那时候我在演讲时也介绍了Brainfuck语言。对于Brainfuck的解释器，各种语言都可以实现，不过我当时为了方便理解用了一个在GitHub Pages上的网站，用可视化的方式演示了它的运行过程，效果很不错。现在既然聊到了，自然就想分享一下这个演示的网站，但我正想打开时，发现网站已经404了😰。 在GitHub Pages上的网站都有对应的仓库，现在不仅原仓库消失了，连作者的首页都打不开，看样子是完全退出GitHub了……那么我想找到这个网站的想法就无法实现了吗？不过GitHub有些有意思的特性也许能帮助我找回这个网站。 GitHub的特性 在GitHub中，一个普通的仓库可能没有什么特别的，也许就是服务器上的一个文件夹。但是当仓库被其他人Fork的时候就不一样了，在执行Fork时，显然GitHub不会完整复制整个仓库。否则，同一个仓库在服务器上会占用双倍空间，这显然不合理。另外，想想Git的结构：它由提交对象和分支指针构成，每次提交都有唯一的Hash值且不会冲突。因此可以推测，GitHub在实现Fork时，所有被Fork的仓库可能共享同一个对象库，而每个用户仓库只保存指针，这样所有仓库只会占用增量空间，而不会存储重复内容。 但这样也会带来一个问题，首先因为很多人可能要共用一部分对象，所以也很难确认对象的所有权，而且也因为这个原因所有的对象要能被所有人访问。因此在整个Fork网络中，只要有一个仓库存在，GitHub就必须保留所有的对象，而且每个仓库都能访问这个网络中所有的对象。为了验证这一点，我们可以用最知名的Linux内核仓库做个示例。 首先对Linux仓库进行Fork，然后我们可以随便做一些改动，比如在README中写“Linux已经被我占领了😆”之类的内容，提交到自己的仓库，并且记下提交的Hash值，接下来就可以把自己的仓库删掉了。如果上面的猜想是正确的，那么在这个Fork网络中的任何一个仓库查看我刚刚的提交应该都可以，于是我直接在主仓库拼上了提交的Hash值（顺便一说只要值唯一，和其他的提交不冲突，短的Hash值也可以），果不其然能找到刚刚修改的内容，这样一来，只要GitHub和任意一个Linux仓库的Fork还存在，这个提交就永远存在了😝。 找回仓库 那么接下来找回之前网站的方案就很简单了，我只要找到网站仓库的任意一个Fork，然后只要知道最新的提交Hash，我就可以还原最新的仓库了。Fork倒是好找，随便搜一下就能找到一个。这个Fork的最新提交是2016年，但要想找到我当年演讲的版本至少到2018年之后。不过这个Hash值也不太好找，虽然理论上爆破短Hash值也可以，但是感觉太麻烦了，没有那个必要，所以我干脆直接去互联网档案馆看看能找到的最新的仓库页面吧，这样我就能找到它的Hash值了，然后我再把Fork仓库的地址和Hash拼到一起，就看得到最新代码了。...
关于ZIP Quine与自产生程序的探索
6 months ago
描述自己的代码……是一种什么样的感觉？ 起因 前段时间我在折腾博客部署的时候，回顾起了好久以前写的部署脚本。对于全站打包的这个步骤，本来我打算利用这个压缩包结合Service Worker做离线浏览，但因为没有合适的方案所以放弃了。而现在对于这个压缩包，我又有了一个特别的想法。事实上在这个下载全站的压缩包中，里面的内容和实际的网站并不完全相同，因为在这个压缩包里缺少了压缩包本身。所以把这个压缩包解压之后直接当作网站打开，会发现下载压缩包的链接是无效的，除非在解压之后把压缩包移动到网站里才行…… 于是我就在想有没有一种可能可以让压缩包解压之后里面又包含了这个压缩包本身？似乎是个不太可能的事情，但我以前听过类似的东西，也许并非不可能？所以这次就来探索一下吧。 自包含压缩包的探索 在很久之前，我见到过一个很知名的自包含压缩包（又称为ZIP Quine），叫做droste.zip，是由Erling Ellingsen在2005年制作出来的。当时我只知道它很神奇，原理什么的并不清楚，另外在网上也基本上找不到类似的压缩包。现在再回看时发现介绍里包含了一些相关的链接，甚至还有一篇能自己制作类似压缩包的论文，所以接下来就可以看一下这些链接来理解这种压缩包是如何制作的了。 关于原理方面，先看Will Greenberg制作的一个示例，在这里面有一个谜题，使用“print M”（原样输出接下来的M行输入内容）和“repeat...
在Tilde社区的游玩体验
7 months ago
Tilde社区，如“家”一般的感受😝 起因 在上一篇文章里，我说到给我的博客增加了不少网站镜像，也在这个过程中发现了不少Git平台实例。顺便一提，我找到了个不错的仓库，可以全网搜索各种Git平台实例。在这探索的过程中，我发现了一种神奇的社区——Tilde社区，体验之后感觉非常有意思，所以来分享一下。 什么是Tilde社区 Tilde社区之所以叫Tilde，是因为在类Unix系统（如Linux、BSD）中，波浪号（Tilde）“~”代表家目录。因此，Tilde社区就是基于类Unix系统环境，并且可以公共登录的服务器，又被称为pubnixes。一般这些社区的管理员会预装很多软件、开发环境以及一些公共服务，比如聊天室、邮件、BBS论坛等，这些构成了社区互动的基础。不过并不是所有类似这样提供Shell访问的公共服务器都可以被称作社区，比如知名的免费网站托管商Serv00虽然也提供可以登录的FreeBSD服务器，并且在服务器上安装了非常多的工具和环境，从表面来看和Tilde社区提供的服务几乎一模一样，但是它少了一个很重要的东西，那就是社区，它的权限管理非常严格，不允许服务器的用户互相串门，也没有互相交流的平台，而且它的本质是商业服务（尽管是免费的），所以它不算Tilde社区。 至于Tilde社区的加入方式，一般可以通过填写在线申请表、私信或发送邮件申请，有些比较有特色的社区会用SSH交互等方式。审核通过后，管理员就会在服务器上为你创建账户，即可获得属于自己的“家”，一般的Tilde社区在这个过程中不需要付一分钱，因为他们通常都是反商业化的，如果遇到了需要付钱才能激活账户的公共服务器，那就不是Tilde社区，即使它历史悠久，可能是别的什么东西😆。 那么在哪里可以找到它们呢？有一个不错的网站，叫做tildeverse，这不仅是一个Tilde社区的集合，它自身也提供了很多服务。不过总的来说各个社区之间也是互相独立的，tildeverse只是提供了一个平台让大家可以互相沟通，所以这个网站叫做“loose association”，就相当于博客中的博客圈一样。 于是我在tildeverse的成员列表中随便挑选了几个Tilde社区提交了注册申请，过了一段时间申请通过了，那么接下来就来说说我在Tilde社区的体验吧。 Tilde社区的体验 虽然我加入了不少Tilde社区，不过各个社区提供的服务都差不多，首先最重要的就是个人主页，一般Tilde社区基本上都会提供一个像~/public_html这样的目录存放个人主页的网页文件，并且可以通过类似example.com/~username这样的地址访问，还有些社区会允许通过二级域名的方式访问，类似username.example.com这样，像我博客好多地方写的都是从根路径开始，就很适合用二级域名的方式。这些主页大多也支持使用PHP之类的网页，不过不像虚拟主机那样有个面板可以轻松安装扩展和切换版本，有些可能要自己写配置文件，有些可能要管理员才可以操作，毕竟是社区，所以不太注重用户体验。 当然除了HTTP协议的个人主页，通常他们还可以创建一些Gemini协议和Gopher协议的个人主页，这些协议不支持普通浏览器访问，需要用ELinks之类的文本浏览器才能打开，这个浏览器甚至可以在终端里用鼠标操作😆。不过因为协议非常简单，所以内容也就只能整些文本内容了。...
用Service Worker实现一个反向代理
7 months ago
现代浏览器真是强大，可以替代一些服务器的功能了！ 起因 前段时间在和群友聊天的时候，提到了我博客的分发方案，这么多年过去之后我已经在很多平台上分发了我的博客，不过这只是多重冗余，并不算去中心化（虽然我也有向IPFS同步，不过IPFS还得pin，也不太可靠）……所以这么看来，我的博客似乎还不算极其可靠😂？但其实不完全是这样。因为除了向不同平台的分发，我的博客还有一个全文搜索的功能。更重要的是，之前做文章推荐功能时，会把整个博客所有文章的文字存到访客浏览器的localStorage中。这么说来，只要有人访问了我博客的文章，他们的浏览器中就会保存一份我博客文章的完整文本副本。从这个角度看，可靠性应该算是相当高了吧？ 不过我之前的分发方案里还记录了一点，在GitHub Pages以外的平台我还打包了一份全站生成后的代码，之所以要全站打包，也是希望我的博客能尽可能的分发，考虑到几乎所有的Linux发行版一定有tar，而不一定有zip，所以我最终打包成了tgz格式。如果能让访客下载这个全站打包好的副本，相比于浏览器里只存储了文章文字的全文数据，这应该是一个更好的备份方式吧？毕竟我的博客本身也是我的作品……所以这个压缩包到底有什么地方可以用到呢？ 这时候我想起来，现代的浏览器功能已经非常强大了，甚至在浏览器里直接运行一个Web服务器也完全没问题。如果能让访客在浏览器里下载那个压缩包并运行一个Web服务器，那就相当于在他们本地设备上部署了一份我的博客副本。这样一来，除了我自己搭建的网站之外，这些访客的本地也运行着一个我的博客实例😆（当然，这份副本只有访客自己能看到）。 研究实现方案 想要在浏览器上运行Web服务器其实很简单，那就是使用Service Worker，它可以完全离线在浏览器上工作。格式的话和以前写过的Cloudflare Worker非常相似，毕竟Cloudflare Worker就是模仿Service Worker的方式运行啊😂，所以我要是想写Service...
使用Cloudflare制作自动更新的网站预览图
7 months ago
Cloudflare的功能真是越来越多了，而且还免费！ 起因 前段时间我在登录Cloudflare的时候发现Workers上多了一个“浏览器呈现”的功能（可能已经出来一段时间了，不过之前一直没关注），看介绍，这个功能可以让Worker操作运行在Cloudflare服务器上的浏览器。这功能挺有意思，而且免费用户也能用，不如想个办法好好利用一下。 一般来说这个功能可以干什么呢？既然是在AI盛行的时候出现……估计是为了搞Agent之类的吧，不过看文档对免费用户来说一天也只有10分钟的使用时间，估计也没什么应用价值……那除了这个之外还能做些什么？我发现有好多博客主题喜欢给自己的README里添加一个能查看主题在多种设备上显示效果的预览图，以展示主题的自适应能力。那么既然现在能在Cloudflare上操作浏览器，那么我也可以做一个类似的，而且这个预览图还可以自动更新。 制作自适应的网站预览 既然打算做预览图，那么我应该用什么方案？按照不同尺寸的视口截几张图再拼起来吗？这显然就太复杂了，况且在Cloudflare Workers中处理图片也相当困难。这时我想起来曾经见到过一个工具，只要输入网址，就可以在一个页面中同时展示网站在四种不同设备（手机、平板、笔记本电脑、台式机）上的显示效果，叫做“多合一网页缩略图”，实现原理是使用iframe和CSS缩放模拟多种设备视口。搜了一下发现这套代码被不少网站使用，所以就随便找了其中一个工具站把代码和素材扒了下来，稍微改了一下，然后放到GitHub上，方便等一会用Cloudflare访问这个部署在GitHub Pages上的页面来进行截图。 使用Cloudflare浏览器呈现进行截图 接下来截图就简单了，不过Cloudflare有两种截图的办法，用Workers的话可以直接用Puppeteer之类的库连接浏览器，但用这个库需要安装，要本地搭环境……我毕竟不是专门搞JS开发的，一点也不想在本地安装Node.js环境，所以就不想用这种方式。另外一种是通过调用Cloudflare的接口，这种非常简单，只需要填几个参数请求就行，唯一的问题就是要填一个Token……我一直觉得Worker调用Cloudflare自己的服务不应该需要Token之类的东西，毕竟内部就能验证了，没必要自己搞，但是我看了半天文档貌似无论如何只要想调接口就必须搞个Token……那没办法就搞吧，其实也很简单，只需要在“账户API令牌”里添加一个有浏览器呈现编辑权限的令牌就行。 至于展示……这个接口调用比较耗时，而且一天只能调用10分钟，截图的话估计也就够30次左右，还有每分钟3次的限制😓，所以实时更新肯定是不行了，图片肯定得缓存，一天更新一次感觉应该就够了。另外次数这么少的话写成接口给大伙用貌似也没啥意义，所以我就把地址写死了，于是以下就是最终实现的代码： export...
一次服务器被入侵的经历
8 months ago
即使是被入侵了也可以学到一些知识！ 起因 前几天，我闲来无事登录了一下一台之前一直闲置的服务器，登录上去后，乍一看似乎没有任何问题，然后习惯性的执行了一下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文件，所以解除隐藏效果我也只需要删掉这个文件就好啦。...
使用XSLT为博客XML文件编写主题一致的样式
8 months ago
虽然XML是机器读的内容……不过加上和主题一致的XSLT样式也算是一种细节吧～ 起因 在上一篇文章中，我提到在提高订阅源兼容性的时候给博客的订阅文件增加了一个XSLT样式。当时使用的样式是从About Feeds下的一个Issue中找的，里面有个基于Pretty Feed修改成能同时支持RSS和Atom格式的样式。虽然那个样式倒也说不上难看，但总觉得与我的博客整体风格有些割裂，所以这次打算制作一个和我博客主题完全一致的XSLT样式。 制作订阅文件的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样式自己的样式...