Posts

官方 Telegram群组 Telegram: Join Group Chat [2x.nz] QQ群 为什么仅QQ群需要赞助？因为QQ作为国内平台，很容易被内鬼举报致使封群，但相对的，门槛更低，交流更方便。当然，如果您是高级用户，可以加入非QQ群。 请先 赞助 至少 10 CNY 后加群。赞助时建议留备注，加群问题填写你留的备注或者交易订单号 点击链接加入群聊【2x.nz】： QQ群 非官方 粉丝自建 Telegram: View @blog2x

引言 曾经我写过一篇文章，记录了从零开始研究AI绘图的经历——当时把Stable Diffusion WebUI、Stable Diffusion Forge WebUI、ComfyUI全装了一遍，各种找教程、实操、试错。好在凭借着仅剩的记忆也是顺着这些蛛丝马迹把丢掉的知识找回来了。 但那篇文章从现在看来，配置还是太麻烦了，并且有很多深层的东西没有讲清楚，只是教授了如何画 Danbooru 里已收录的角色。那么如果我想要画的角色很新或者没有收录呢？这期带你吃透AI绘图！ 在纯小白的情况下，你可以跑出类似下面的图！（跑不出来你打死我！） 简单的思维风暴 在正式开始前，我们将会用到以下术语，这里会简单介绍都是做什么的： ComfyUI：一个软件，是AI绘图控制台，你只需要在这里点点即可出图 checkpoint：一个底层的，作为基底的模型。可以直接用它开始绘图又或者搭配下面的Lora模型来绘图 LoRA：一个控制角色/风格的模型。可以通过载入不同的LoRA去画出不同的角色或风格 prompt：提示词，用以告知AI你想要画出什么样的东西 简单来说，这一切并不复杂，我们只需要首先挑选一个基底模型，如果你不挑或者你想画的角色正好就在其中，可以直接使用该角色的提示词作画。如果你想画不在其中的角色，只需要再载入一个LoRA模型即可。 正式开始 下载ComfyUI 尽管ComfyUI支持AMD显卡以及纯CPU绘图，但还是建议使用 NVIDIA Cuda 进行绘图，更快，兼容性也更好！ 方式一：官方版（推荐） 前往 ComfyUI | 用AI生成视频、图像、音频 下载并安装，记得打开魔法或在设置中更改镜像源 点击右下角的开始运行，先让他进行初始化，直到它自动打开你的浏览器并且可以正常进入ComfyUI的界面 下载基底模型 大部分LoRA一般都需要这两个基底模型。其中 WAI 支持直接通过 Danbooru 里已有的角色直接作画，无需其他LoRA： WAI-illustrious-SDXL - v16.0 | Illustrious Checkpoint | Civitai 点击下载即可 如果你需要下载LoRA 首先你要知道你想画的角色的英文名，如 Cartethyia （鸣潮 - 卡提希娅） 然后前往 https://civitai.com/ 进行搜索，选择你喜欢的LoRA 在详情页你可以看到该LoRA所需要的基底模型。有些时候模型的简介也会写 下面的 Trigger Words 是推荐的 正向提示词 一般来说仅导入LoRA不写专有提示词也会有一定的效果 放置模型 [!warning] 这里有一个坑点，对于桌面版安装的ComfyUI，请将模型放到你当时安装时选择的文件夹中，如： C:\Users\af\Documents\ComfyUI ，而不是形如 C:\Users\af\AppData\Local\Programs\ComfyUI\resources\ComfyUI 的地方，更多请参见官方文档： 重要提示：请勿修改 resource/ComfyUI 文件夹 - Windows桌面版 - ComfyUI ...

为什么要重构为纯Svelte？ 这实际上是个复杂的问题。在2024年选择Fuwari作为本站框架实际上只是一个巧合，当时并没有顾虑到后续开发的问题，我当时甚至是从 Hugo/PaperMod 这种明显比Astro高效的框架迁移过来的。当时选择Fuwari只有一个原因：好看 我们可以来简单看一看Fuwari Demo Site 放眼望去，第一个感觉就是大。相比于传统的博客站，Fuwari的设计语言明显是更现代，更灵动的，因为Fuwari还采用了Swup来做SPA页切，这使得网站从一开始的进入，再到用户主动切换页面，都是非常丝滑流畅的 另外，由于它基于Astro SSG，这使得它的SEO也是非常棒的，所有页面都是静态的HTML，无需服务端介入，即可同时实现：美观、SEO良好、快速 的博客站 可见，我一直都在夸Fuwari，那我为什么要换掉它呢？ 实际上，并不是Fuwari不好，而是本站渐渐从一个 纯静态博客站 逐渐变为了 重客户端的全栈 ，尤其是2026年上半年，我们添加了非常多根本不属于静态博客的东西 如果说在博客上扔个课表还是一个方便自己的快捷方式，勉强算合理 那么在博客上扔一个 论坛 则是一个完全改变项目定位的做法，Astro SSG并不擅长处理全栈，所以便使用了 @astrojs/svelte 来实现这种重客户端交互的页面 但是做着做着便发现不对劲了。由于 Fuwari 使用 Swup 来操作页切，而经过我们长达2年的魔改，Astro 引以为傲的 island 我们根本没用，大部分页面都是采用的传统的监听器，页面上哪些是全局JS？哪些是只需要加载一次的JS？哪些又是持久化的JS？ 我不知道，所以这导致在后续开发十分痛苦。经常会出现新做了一个页面，第一次进去正常，然后被Swup接管后，来回切几次，页面布局就崩了，某些关键DOM被抽走了 这并不是一个新问题，而是一个遗留问题，由于在2024年我刚使用该项目的时候并不具备这些基础，慢慢的，聚沙成塔，聚史成山。如果现在想要将这些诡异的写法通通移除，无异于重写Fuwari的渲染器，需要分析并重构200+文件，近w行代码 我改不动，于是在忍无可忍的时候，我采用了头痛砍头，脚痛砍脚的方式。 既然没法重构，那直接不用Swup了，全部删了，这总很简单吧？ 的确，就像脱衣服简单穿衣服难，删除Swup非常简单，如果你不追求工业级剔除，只需要在Astro中禁用Swup，并全局拦截Swup的load即可 但是…代价是什么呢？代价就是一旦没有了Swup，网站将不再是SPA，所有的页面切换都需要 完整重新拉取 一份新的HTML替换当前页面。就像大学编程课写的那些 1.html 2.html 然后使用 a 标签跳转那样 这会导致两个问题，第一个问题是显而易见的，用户会发现，在页面切换的时候好像变得古典了，点完超链接跳转后会有一瞬间白屏，然后内容才会慢慢加载出来，而且我单页上的JS本来就很多，这会导致你无论前往何页面，都会看到页面上 砰砰砰 逐步加载出：文章，课程表，直播状态，访问量 它十分割裂，且用户体验极差。同时，它也会导致第二个问题，那就是资源浪费。假设用户只想点开一篇文章阅读，无SPA的页面会将新HTML完全替换旧的HTML。这不仅会导致页面重新加载拖慢了浏览器的性能，由于我们接入了访问量回显以及各式各样的客户端探针。这些东西本身只需要在一个用户会话中加载一遍，但由于无SPA，会导致重复加载这些内容，这无疑隐性提高了后端服务器的负载 想一下你进入首页，加载首页8篇文章的访问量，加载一个课程表组件，再查询一下二叉树树当前是否开播，好，加载完了。接下来，点进一篇文章，那么就又要加载一下这个文章的访问量，同时，加载一个课程表组件，再查询一下二叉树树当前是否开播，好，加载完了。最后，你看完文章了，想回到首页看其他文章，你点击了首页按钮，跳转到首页，此时页面又会重新加载首页8篇文章的访问量，加载一个课程表组件，再查询一下二叉树树当前是否开播，好，加载完了。 是不是光看着就要力竭了？实际上浏览器和后端服务器比你更力竭。这些内容原本应该遵循 按需加载 。如课程表组件加载完成后就持久化，当你点进某篇文章浏览量应该是立即显示的，因为上一个页面是文章列表，肯定已经得到浏览量了，无需再次获取… 诸如此类的问题导致后续的开发虽然很爽，但是用户体验很烂，调研问卷有大多数反馈国内网络加载慢的问题。这就是因为没有SPA，所有页面都需要完整拉取HTML，由于我们的服务器在Cloudflare，尽管已经优选，但可能还是较慢。如果是SPA，只需拉取新的内容，并且也不会触发浏览器的重加载。不管是在实际资源加载还是用户体感都是更快的 然后，便是Astro臭名昭著的内建图片压缩，我曾经在 禁用Astro跟弱智一般的静态构建图像优化 - 《二叉树树》官方网站 写过如何禁用它，因为它不仅将所有压缩压力都传递给了CICD，而且它的结果也不尽人意，有时候，甚至会反向压缩 如何禁用它呢？可以，但很诡异，要不你将图片放到 /public 目录，Astro就不会管他了，但是编辑器就不认图了。要不你就写一个补丁，在源码层面将Astro图片压缩的代码剔除（旧站就是这么做的）。总之，Astro就是强制爱，就是不管怎样都想看看你的图片，顺便用Shrap一压，欸！一不小心压少了，压多了2kb 再接着，经过这几个月的超级周边功能开发，我们实现了一堆奇奇怪怪的功能 而这些功能无一例外都是 Svelte 。这更代表了整个项目已经被 Svelte 架空了，那么，不如贯彻到底，直接把Astro丢了吧？ ...

引言 众所周知，目前我们用的是基于一个本来非常优雅的静态博客生成器 Astro 和一个本来非常优雅的博客主题 Fuwari 来制作的该网站 在这长达2年的魔改中，我们加入了一些神秘的功能和页面，比如： 访问量统计，论坛等等 这无疑会导致项目变重，最近我们每一次冷启动开发服务器的时间都长达 几分钟 。这显然是不正常的，因为 Astro 本着 0JS，按需加载，按需水合。就算我们有几百万个页面，dev也不应该需要这么长的时间来启动。所以，是时候来看看astro dev都干了些什么了 正式开始 我们观察到运行 pnpm dev （与 astro dev 等价）时，Vite在准备就绪后，日志会卡在这里很久 16:40:06 [astro-icon] Loaded icons from public/icons, fa6-brands, fa6-regular, fa6-solid, material-symbols, material-symbols-light, mingcute, simple-icons 不难看出，这是Astro在收集并加载站点中的所有图标，并且在很长一段时间后，站点第一屏出现，时长为… 16:40:53 [200] / 37527ms 这显然不合理，就算图标再多，他也只是一个不超过10MB大小，不超过几百个的小文件而已。astro dev在默认情况下显然隐瞒了一些东西 那么我们就需要使用 --verbose 标志，来事无巨细的获取开发服务器究竟被什么东西卡了这么久 显然，我们会发现 Astro 在 Vite 准备就绪后就开始加载schema了，最典型的就是图片，由于图片在 /src/content/assets 下，Astro会将其当作内容集合去处理，而我们的项目总共有 1000+ 图片，这会导致所有图片都会走一遍Astro的处理，哪怕我们在 astro.config.mjs 声明了 no-op 透传 export default defineConfig({ image: { service: passthroughImageService(), }, 而我们最终上线的时候，图片会被替换为CDN源，尽管这个问题并不影响云端构建（因为 src/content/assets 目录下在构建前就会被清空）。但是它大大拖慢了本地启动开发服务器时的速度 实际上，我们只需要让 Vite 将图片映射正确即可，我们既不使用 Astro 图片压缩，也不使用响应式图片 那么，如何让 Astro 不再碰我们的图片呢？ 我们可以将图片从 src/content/assets 目录移动到 public/assets ，由于Public文件夹内的所有内容会被原封不动复制到 dist ，Astro自然也不会对其操作，我们只需要确保图片路径映射正确即可 ...

引言 你是否有一个Linux服务器？你是否曾经使用过各大IDE的远程开发？你是否被巨大的 vscode-server trae-server … 占用巨额储存空间？ 实际上，当我们进行远程开发的时候，我们只需要 在Windows上操作Linux的文件 即可 那我们为什么不尝试 将Linux上的目录挂到Windows上 呢？ 正式开始 首先我们需要安装SSHFS，你可以前往Github下载发行版： libfuse/sshfs: A network filesystem client to connect to SSH servers，又或者通过Scoop安装： scoop install nonportable/sshfs-np 接着编写一个批处理脚本，方便我们每次的挂载 SET PATH=C:\Program Files\SSHFS-Win\bin "C:\Program Files\SSHFS-Win\bin\sshfs.exe" -f root@192.168.124.14:/ X: -o workaround=rename -o idmap=user 第一行命令的作用详见： https://github.com/winfsp/sshfs-win/issues/401#issuecomment-1968129241 C:\Program Files\SSHFS-Win\bin 你的SSHFS二进制文件所在的目录 -f 前台挂载，关闭CMD窗口后则失效 root@192.168.124.14:/ 你要连接的SSH主机（192.168.124.14），登录用户（root），挂载目录（/） X: 要挂载到的Windows盘符 workaround=rename 自动修复Unix文件名 idmap=user 以SSH登录的用户权限来访问挂载目录，这里为root，避免访问权限问题 最后，我们就可以在Windows文件资源管理器中看到被挂载的Linux盘符了 同时，我们也可以使用任何软件来直接打开Linux上的文件来远程开发 需要注意的是，和其他IDE直接通过SSH连接服务器进行远程开发不同。SSHFS仅是通过SFTP协议将Linux上的 文件系统 映射到Windows上来。并不包含整个Linux环境 所以，SSHFS上的终端解释器为你的 Windows终端解释器 ，而其他IDE的远程开发的终端解释器为 目标Linux上的终端解释器。 如果需要调用Linux上的原生命令，则需要另开SSH

前情提要 因为最近搞了甲骨文，有俩1c1g的甲骨文机子，但是不知道能拿来干嘛 然后最近偶然发现甲骨文上托管HTML很绿 于是就想着是否能在我的俩甲骨文上托管我的静态博客？ 思路 首先，我们需要一个Web服务器，用来提供HTML内容，因为我是静态博客。所有我们不需要高级功能，故选择最快的 static-web-server/static-web-server: A cross-platform, high-performance and asynchronous web server for static files-serving. ⚡ 其次，我们还需要为它配置SSL，这里使用最简单的 https://acme.sh 最后，我们需要让他实时更新。嘛，最简单的就是写个定时任务，按照固定频次强制拉取远程仓库的最新更改 所以流程图最终大致如下 flowchart TD 用户 --> 2x.nz --> |DNS解析|cdn[oraclecdn.2x.nz] --> 1[Oracle1] cdn --> 2[Oracle2] 1 --> s1[SWS1] 2 --> s2[SWS2] Acme1 --> |签发SSL|1 Acme2 --> |签发SSL|2 cron[定时任务] --> |拉取更新内容|1 cron --> |拉取更新内容|2 s1 --> r[静态博客] s2 --> r 正式开始！ 首先，使用 MobaXterm free Xserver and tabbed SSH client for Windows 连上两台机子并且启用 Multi Shell！ 这样我们就可以输入一次命令，让多台机子同时执行！ ...

免费优质线路2c4g VPS + 免费GLM无限用 前往 https://open.claw.cloud 默认会给你个龙虾 你可能会觉得这没什么？那如果我说… 不过，试用只有7天，并且没有公网 如果你凑巧 财力雄厚 可以每个月付 70 CNY 即可得到 2c4g 优质线路150G大硬盘不限制流量的VPS + 无限制的 GLM-5 另外，这个 GLM是可以逆出来的 只需要前往以下路径，即可得到 API Endpoint 以及 API Key 。不过是内网，接个CPA转出来即可 /home/openclaw/.openclaw/agents/main/agent/models.json 免费 Opus 前往 https://replit.com 再前往 Linux.do 二级贴 https://linux.do/t/topic/1904533 https://linux.do/t/topic/1899899 让 AI 自己逆向自己获取 Claude Opus 4.6 ，可接 Claude Code 用的实际上是你的号上的份额，蹬完了可以开新号继续蹬~

视频（非教程） https://www.bilibili.com/video/BV1H4DuBWEes/ 原理 我们都知道，NAT类型测试非常简单就可以实现，我们可以使用类似如下Python库在客户端本地跑一个脚本测试 MikeWang000000/Natter 但如果我说，我们根本就不需要下载一个程序，只需要打开一个浏览器就可以测试你的NAT类型呢？ 稍微深入一点，大部分的客户端测试你的NAT类型一般都是 主动请求STUN服务器 分析返回的 公网IP:端口 判断NAT类型 但是，在浏览器中，我们无法发送原生的UDP（STUN）请求，只能使用一个包装过的UDP接口： WebRTC 该功能设计初衷是让浏览器也可以进行P2P连接 但我们也可以将它拿来测试NAT类型，不过我们的后端需要富裕一点：用两个不同的IP来探测 实际上，它的原理简单来说就是： 浏览器请求STUN服务器，将自己的 公网IP:端口 发送给后端A（HTTP/WS） 后端A收到浏览器的 公网IP:端口 后，发送回包，拿取凭证（因为浏览器不允许陌生源直接发包）。此时，后端A已经是可信源了 接下来，后端A将自己的凭证告知后端B，让后端B拿着这个凭证去请求浏览器。如果可以收到浏览器的回包，则是 全锥型 如果收不到，则让后端A换端口请求浏览器。如果可以收到包，则是 IP限制型 ，如果不行，则继续测试 最后，再让后端A用同一个端口请求浏览器。如果可以收到包，并且浏览器源端口与之前一致，则是 端口限制型 ，如果不一致或压根收不到包，则为 对称型 详细的技术文档参见： webrtc_check_nat/nat_detector_explanation.md at main · afoim/webrtc_check_nat 实现 最终，我们只需要写好后端，再创建一个HTTP端点，即可实现 完整的、全状态、纯浏览器的 NAT类型检测 afoim/webrtc_check_nat https://2x.nz/nat-check/

视频 https://www.bilibili.com/video/BV1hpDKBbES9/ 正式开始 众所周知，目前如果你想订阅本博客，可以采用以下几种方式 瞪眼法 在多次浏览中通过大脑的逻辑中枢来判断有哪些新文章，或有哪些文章更新了 简易瞪眼法 在多次浏览中，若文章状态变化，右下角的小铃铛则会显示相应通知，点击后甚至可以看到高级的DIFF RSS 通过RSS订阅器订阅本博客的RSS XML文件，由第三方告知文章更新状态 加入群组 通过置顶文章加入群组，群内会有Bot在文章更新时广播一条消息 催更法 想办法要到我的联系方式，催更，大概率我会在你要求的新文章发布后踹你一脚 emm，看似很多，的确很多，但是由于多多益善，可得还不够多，所以我们准备再添加一个古法订阅 那就是 电子邮件通知 实现它在现在其实非常简单，由于我们已经有了一个 论坛 ，可以直接在用户个人中心添加一个选项卡，勾选后即可接收后续的文章通知 我们甚至无需担心垃圾邮件，因为在注册论坛时已经有了相对严格的验证 那么接下来就是架构的设置，正如上文提到的，我们有一个提醒文章更新的Bot 实际上，最终的电子邮件发送的东西和这个东西差不多 也就是说，我们只需要让Bot在发送消息的同时，将要发送的内容推送给我们 至于Bot是如何做到文章更新推送消息的，请参见 这里 那么不难想象，我们只需要在后端创建一个WebHook端点，接受Bot发送的WebHook消息，然后将正文作为邮件正文发送给订阅后的用户 最终，架构如下 flowchart TD A[Git Push 特殊事件posts: / update:] --> B[GitHub WebHook] B --> C[Bot WebHook 接收端点] C --> D[延迟队列 / 定时器] D --> E[Bot 向群内推送消息] D --> F[二次 WebHook 请求] F --> G[论坛后端 WebHook 端点] G --> H[封装邮件正文] H --> I[异步邮件发送服务] I --> J[所有订阅用户] ok！思路清晰了，实践就简单了 ...

引言 经常做全栈的小伙伴们都知道，写完后端看效果要dev，写完前端看效果也要dev，那么有没有一劳永逸的解决方案呢？ 比如说我的项目： afoim/acofork_forum_backend 前端是一坨React 后端是一坨 Typescript 而前端要用 Vite 来 Dev 那么后端还要使用 Wrangler 来 Dev 那么如果我们想要测试，就需要把前后端的dev一起拉起来，对吧？ 但是不知道为什么，在今天之前，我都是用一种很奇妙的方法来做这件事的，那就是 我先Build前端，然后让后端把前端build后的产物作为静态路由 这会导致一个问题，由于最终是 Wrangler 起的 Dev，那么后端自然是可以热重载的了，那么前端呢？ 在曾经，我改一次前端，就要 rebuild 一下，但是现在，我们有一个更好的解决方案，那就是： concurrently ! 它是一个能给前端 + 后端的 Dev 同时拉起来，这样，我们就同时得到了前后端的热重载，我们只需要专心的去改代码，网页会实时呈现效果 正式开始 首先，安装 concurrently 的 npm 包 npm install -D concurrently 接下来配置 package.json 。意为：调用 concurrently 工具同时运行 npm run dev:frontend 和 npm run dev:backend dev-remote 是用来连接远程 D1 SQL 进行开发调试的 "scripts": { "build:frontend": "vite build --config frontend/vite.config.ts", "dev:frontend": "vite --config frontend/vite.config.ts", "dev:backend": "wrangler dev", "dev:backend-remote": "wrangler dev --remote", "deploy": "npm run build:frontend && wrangler deploy", "dev": "concurrently \"npm run dev:frontend\" \"npm run dev:backend\"", "dev:remote": "concurrently \"npm run dev:frontend\" \"npm run dev:backend-remote\"", "start": "npm run build:frontend && wrangler dev", "test": "vitest run", "cf-typegen": "wrangler types" 最后，我们需要设置一下 Vite 的 Proxy ，将 /api 也就是后端的请求转发给 Wrangler ，配置 Vite 配置文件的 server 块 ...