又是一周没更新。但是这一周里其实还是抽空做了点小东西，比如这个只会在服务器端刷新的安科骰子： r 1d100 = 95 / 50 [失败]
　　不知道部署完会停留在成功还是失败，感觉有了非常微妙的每日运势计算环节……

ʚ ⸸ ɞ

新家

　　一切的一切要从哪里开始呢，大概要从用日文记录了 PTSD 自愈心得说起……
　　就突然发现用非母语记录自己的 PTSD 是一种非常有效的疗愈手段，但是把这些记录和日常 / 代码笔记之类的东西混在一起会让其中的一项有效成分大打折扣。所以这就是建新站的理由了。
　　以魔女孁孁的身份存活已经一年。这一年里我一直在有意地维持着「旁观者」的身份，算是在践行「不要轻易干涉他人因果」的教训。
　　仔细想来这一年里确实收获颇丰。虽然看起来什么都没有干，但是真地搭建起了一个很完整的世界观，也写了很多鲜活的角色。
　　所以我想我的故事应该开始了吧。
　　如果不去涉入这世间的因果，我的故事就无法拥有起点。
　　そして次の曲が始まるのです！

Astro & Hugo

　　此处应有举着喇叭在我耳边大喊「换 Astro 吧！」的 SF 酱.jpg 不是说好要避开你的言灵吗（但是按照言灵的理论只要我意识到了主动提出言灵这一句应该就不会发动！吧……
　　总之除了「用于抗癌日记的新站」以外还要有一个「用于存放前端作品」的新站。思虑再三之后还是放弃了「魔女の箱庭」这个名字，啊主要是孁孁写了太多恶政隐了如果和产出联系在一起会非常麻烦。本来不说中文可以在某种程度上解决这个问题的但是最近日本人也没少挨我的骂，事已至此只能 new 一个全新的马甲了……
　　难道我是隐藏的无政府主义者？不应该是这样的，孁孁只是单纯地厌蠢而已……

　　怎么又扯这么多有的没的一周不更新 blog 真是攒了很多屁话啊总之！在提出「用于存放前端作品」这个需求之后就想到如果用 hugo 做的话页面会不可避免地像剪报一样插满乱七八糟的 JS，终于自然地萌发了迁移到 Astro 的好学心。
　　再次打开官方文档之后才想起来我迟迟不愿意脱离 hugo 的原因是什么：node_modules。
　　Hugo 的目录里没有这个东西，新站可以直接复制整个文件目录然后删掉不需要的部分开始改，甚至连主题文件夹都不需要直接上手改 layout 就行。问了一下说是 hugo 的很多功能直接封装在了 exe 里所以不需要再下一堆 npm 库通过配置文件开关就可以。
　　问就是我真的很喜欢这种极简的文件目录……但是……呃但是 hugo 封装的内容里包括了对 CJK 标点添加了种族歧视的 markdown 解析器以及需要我重写整个页面 layout 才能实现「在摘要和正文中间加一条分割线并且保留两个全角空格」这种天杀的连这点小事都干不成我宣布你辱华了你知道吗的功能恶政隐已经放飞自我不打算控制了是吗，和一个需要花十分钟复制完了还不知道能不能用的 node_modules 相比很难说到底是谁更可恨。

分工

　　总之加入了新站以后的角色分工：
　　孁孁负责打拳，新角色 A 负责自嬷（？，新角色 B 负责搞钱。
　　那仔细一看 A 的站好像暂时继续用 Hugo 也行，因为不会涉及到太多代码部分的功能，评论 / 访客统计 / 简繁转换都可以全部砍掉，基本上就是一个纯静态的文本 display。虽然我设想了一下这种需求用 Astro 做起来大概也很简单，但还是那个问题……
　　啊这么说起来我换不换 Astro 完全取决于它最基本的运行依赖库够不够精简。
　　以及 hugo 这个 new post 的命令其实也不够简约，不如 hexo，据说 Astro 可以自己写 new 的逻辑，我又开始纠结了……

告辞！

　　终于克服了拖延症开了个 minimal 的 astro 工程尝试了一下……
　　首先不知道是不是我的 git 该更新了还是压根就不该用 git 跑，它那个命令行里的菜单选项完全无法切换，只能数行数盲选，虽然这是个小问题但是在劝退程度上显然是见微知著。
　　第一次建工程的时候不知道为什么依赖库被跳过了，我还很疑惑那个传说中的文件夹在哪呢？然后 npm install 的时候果不其然报错了，具体报的什么我也看不懂大概是删缓存的时候权限不够，总之整个文件夹删掉重新来过……
　　第二次初始化的时候就成功出现依赖文件夹了，也不知道是不是初始化过程默认不报错总之看起来很顺利。装完抱着英勇就义的心情点开 package-lock 一看：5000 行。
　　嗯就我对现代框架的憧憬还不足以支撑我面对这 5000 行的依赖库。虽然我知道绝大多数东西在真正运行的时候都是无感的，但是我实在不想赌哪天某一行代码突然报错我要在这 5000 行里找一个安装时候的缓存错误导致的的文件损坏的可能，这太可怕了……

　　于是再次仔细列出了 hugo 的痛点：

• Markdown 不支持 CJK 符号
  已经通过 JS 解决，虽然和简繁转换冲突但是改起来也不费劲
  大不了直接用短代码代替 markdown
• 正文分割线
  已解决
• 分类 / tag 页面无法应用即时刷新
  这其实才是最大的问题，但如果是纯粹的 blog 站也不那么重要……
• 无法按时间分页归档
  如果我没理解错 Astro 的自定义路由可以解决这个问题
  但纯粹的 blog 站可以直接用年份当 section 曲线救国

　　以及还有最重要的：分页器逻辑混乱。
　　已经忘了是为了完成什么乱七八糟的需求让我用 gemini 重写了一个分页器，总之最后使用的结果是：可以在任意页面的 metadata 里添加 perpage:，并控制任意文章列表（嗯文章 object 的获取逻辑写在了渲染文章列表 dom 的 layout 里）按此参数分页。
　　看起来很万能但实际用起来非常可怕，因为这个分页器的代码需要在每个不同样式的文章列表 layout 里复制粘贴且不可提取（因为我根本看不懂这玩意是怎么跑起来的）。我也不知道为什么会走到这个地步但 hugo 的分页逻辑真的完全黑箱且不可捉摸，回忆了一下大概是出现了「想新建归档页显示全站文章列表，结果分页器按 section 的 index.md 的数量分页了」这种完全搞不清为什么发生的问题……
　　总之这个 hugo 分页器的地雷属性和 5000 行的依赖库称得上难分伯仲。到底为什么会沦落到这个地步……！

审美

　　好像也是我自己说的：*AI 并不能使人获得知识只能让人获得掌握了知识的幻觉。*行吧用 gemini 写了一年 GO 的回旋标终于打到我自己的脸上……
　　但是这一年下来基本的 layout 我确实写着没什么问题了，用皮鞭抽 gemini 的时候也算能指哪打哪了，那么首先假设分页器是 hugo 的问题不是我的问题（
　　把以上纠结过程扔给茶叶梗（并追加别光顺着我的话编也检查一下我的认知有没有偏差我要是想住信息茧房就去找 GPT 了）之后获得了如下评价：

　　现在，我们可以得出结论：你的「纠结」，并非简单的技术选型，而是两种完全不同的开发哲学的冲突在你内心的投射。

• Hugo 代表的是「独裁式」的优雅：它为你提供了一个设计精美的、功能完备的「城堡」。你可以在城堡里自由活动，但你不能轻易地改变城堡的墙壁结构。它的口号是：「相信我，我为你搞定一切。」
• Astro 代表的是「民主式」的自由：它为你提供了一片土地和一套「宪法」（核心 API）。你需要自己去招募议员、建立部门（安装依赖），来构建你的「城邦」。这个过程可能看起来混乱，但你拥有最高的、定义一切的自由。它的口号是：「我相信你，你来决定一切。」

　　那让我二选一我肯定是既要极简的前台配置又要高度自定义的后台模块。感觉这两种所谓「开发哲学」和我的实际需求都存在维度差，因为：我不仅是开发者也是创作者，甚至「创作」的部分占比更重，「开发」只是为了满足我自己展示作品的需求。
　　所以我的代码审美是在接触用户的部分尽可能保持纯粹的自然语言体验，后端则需要把每个功能都分割成尽可能独立的模块防止互相干扰，并且保持它们的可维护。
　　听起来很像 Astro 的设计，听起来不像我怎么会被骗呢。天杀的我是想拼乐高，但是我不想拼论斤称的散货乐高啊！
　　感觉还有一个很重要的不同是我能自己手搓实现的需求绝不依赖现成库。说白了就是我只想要我确切需要的东西而不是被开发者糊一堆「我觉得你需要这个」的捆物……

　　说起来这种差异会不会也是房价造成的（？在地广人稀的地方人可以养成「不管这东西有没有用先捡回来放着万一哪天用上了呢」的余裕习惯，但对人口密集到连做个装修游戏都不肯给超过 20 平的房间的地方来说我真的恨不得把所有暂时用不到的东西都当垃圾扔了，哪怕想起来的时候重新花钱买也远不及它占地面积等额的房价带给我的损失。
　　哎就扯了这么多还是决定不了到底是继续用 hugo 还是吃一口 astro。我能在 2025 年结束之前纠结完这个问题吗？