李华是一个生电服的玩家，他总是在想，要是服务器里面有创造实验室就好了。 小叶是一个喜欢 PvP 的玩家，他总是在想，要是服务器里面有一个能干脆利落开启决斗的地方就好了。 作为这个服务器的 OP，这些场景对你来说不陌生。如果把这两个问题抛在 Minecraft 服务器社区里，相信绝大多数的回答都是「开一个新的子服务器并且建立跨服群组」，但是，这真的值得吗？ 显然，这不值得。如果只是为了这两样功能启动一个跨服群组，你将会面临以下问题： 额外的维护成本： 使用群组服则基本排除了面板服务器部署方案的可能性，并且一个没有适当配置过的群组服务器会引起诸多问题，例如：玩家使用 /server 跳过验证关卡，子服务器的端口意外的暴露在外网等等。 资源需求上升： 启动额外的子服 + 代理程序则意味着你需要更多的资源。Java 主流 GC 的策略通常都会为了速度而将堆所占的空间悉数预分配，这导致即使程序使用的内存并没有那么多也会造成较高的 RSS. **资源分配不灵活：**上一个问题并不能简单的通过减少堆的大小解决。就以创造实验室为例，平时服务器内的人并不多，但一旦到了演示/大型机器实验时，较小的堆空间将会给 GC 带来相当的压力，并且无法利用到分配到其他（类似情况的，比如 PvP 竞技场）子服的空闲资源。 …… 光是想到从单端变群组，大多数服主就已经汗流浃背了。那么，本文所述的基于 transfer 机制的方案是如何规避这些问题的呢，他与其他类似方案又有何优劣之分呢？ 基于世界的子服划分方式 这个情境中使用群组方案，归根结底是为了做服务器区域之间的划分。而 Minecraft 自带的多世界机制就已经很好的解决了活动空间的划分问题：没有传送门的情况下，玩家并不能随意大小跨。 早在 2013 年，PerWorldPlugins 就已经实现了将插件的生效范围降级到世界层次。通过切割插件在整个服务器中的作用域，这些世界得以模拟「服务器的子服」，使用此插件的用户可以通过限定不同世界里启用的插件来模拟多服务器的效果。而在约 2020 年，Valorin 的 DuelTime / Dantiao (付费) 将这个概念进一步推进，完全实现了本文引入部分时提到的「干脆利落开启决斗的地方」的设想。 然而，这样实现引入了许多需要额外维护的状态：生存服的玩家不能将物品带到创造服，他们也不希望在 PvP 服丢掉自己一身的好装备。插件需要小心翼翼的维护好这些状态，在跨世界转移的时候将他们的背包数据暂存起来，甚至有必要储存到硬盘上以防 崩服/断电/插件自身异常 导致数据丢失（数据无价！）。 并且，除了物品数据，还有许多问题需要考虑，比如玩家身上的 scoreboard / team 数据，其他插件储存的玩家相关的状态数据都可能会导致数据切割不干净。甚至如果这些插件涉及到储存功能，例如类末影箱类插件，邮箱等，被滥用的后果不堪设想。 而本文所述的方案使用 transfer 特性解决这些问题。 Transfer 是什么 /transfer 命令 是一项在 1.20.5 才被加入的新特性。如果你不知道他，只需要看这条命令的语法就可略知一二： /transfer <hostname> <port> [players] ...

放眼大海，望过对岸楼宇林立的城市，望到高中生活的尾声。 … 我好像落了些什么在学校里。 开完毕业典礼之后，回到教室，大家收拾东西，呼道「有缘再见」就各自拉着行李箱走了。再见，又会是什么时候呢？缘分，未来还会再聚一堂吗？ 再聚一堂，「他」最终会放下成见吗？「我们」又将成为什么样的人，做着什么样的事情？ 这些曾经遥不可及的未来的憧憬，正在越来越近。我有些惶恐。 即使走之前再怎么慢慢的收拾，一遍一遍的检查，或者是给高一高二在黑板上留言，我们的脚步仍然朝向校门。办公室里面不知道什么时候已经收拾的干干净净的，只有几台电脑还留在那里，似乎这间办公室本来就是这个样子。教室里狼藉不堪，地上，走廊里，桌上都是曾经灌注了心血的书籍和文具。 我在黑板上写了个大大的「快跑」，简单收拾一下就走了。本来想把之前打印的几篇论文放到学校图书馆的，奈何图书馆锁了，就只能放在楼道里的某个柜子上了。 期待下一个人得到那份资料，看到背后写着的入群地址，把这些知识传下去。 走出校门，我没有回头。 … 好像是太阳撞上了这个省，那天下午很热，我披着汗水走到家里一样样的清点行李里的东西。行李里的东西很多，但是漏了点什么。 书… 似乎落了一本知识全解。 别的东西… 似乎之前某人送我的 3D 打印狐狸忘记带回来了，之前买的一本 Arduino 入门也不见踪迹。 …还有一张毕业照，好像我没带回来。 虽然很可惜，但我没有带回来毕业照。 这三年以来，这所学校从未给予我任何归属感。每当有人盘问起我的学习状况，考到了什么学校，我总是会糊糊涂涂的搪塞过去。我以在这所学校里为耻，更别提毕业照了。但即使我怎么惋惜那些落在学校里的东西，我也没法做什么了。因为学校的规定是今天就要清理干净我们的所有东西，所以即使清点的这个时间回去也只能见到环卫阿姨们忙忙碌碌的身影和一干二净的教室了。 这所教室里每年都要重复上映着一样的场景，只不过没想到这么的快，令人想起来刚刚搬入这间教室的时候，墙上还画着学长给我们画的一幅画。 画里是学校的轮廓，上面题着几个字：「剩下的，你们来完成」 时光飞逝。 … 六月九日，多么美妙的日子。 在下午最后一科收齐卷后，大家就已经是高中毕业生了。那些在漫漫长夜里偷偷许下的愿望，数不清的「考后我要做什么」在这个时候重新变得明亮起来。我们就像一群刚刚降生的雏鹰，终于破开蛋壳，贪婪的呼吸着这个世界的空气，感受到无限的可能性正在奔涌而来。 晚上，我们迫不及待地回到教室里，但不再为所谓的复习。大家拿起手机只在玩，似乎十八年来从未这么自由过。但比起自由，更让人感到舒适的是某种所属感。 即使在那一天，宿舍的阿姨还是要求我们八点半回宿舍，办公室的老师们还是让我们尽快回去。到十一点半了，宿舍的阿姨来央求我们回宿舍。 我和几个人点了一大份外卖，有人抱了一大箱啤酒回来，有人在教室里开黑，最后几个喝醉了痛快谈心，聊感情，炒粉又端了上来。我夹起来别人的吃了几口，似乎还留着一股锅气。 形而上的「班级荣誉感」和「集体主义」早已被这样热情洋溢的一群人化为碎骨，即便只是昙花一现。楼道里的其他房间早就熄了火，唯独我们班灯火通明。我喝了两杯酒，头晕晕的，那时候已经是凌晨两点了，遂回宿舍睡觉。只不过宿舍里也是灯火通明的，从前被「分班」分离开的同学们又重新聚集了起来。 这里没有所谓的一二三四五六七八九班，只有一群刚刚毕业的学生。 但是，我的行李箱落下的不只是这点。 高考前一天晚上，大家已经弹尽粮绝了，可能没几个吃饱饭的。想到饭堂里抠搜的大叔，想到那些冰箱里的文物，总是让人不禁有些可惜自己的钱包被宰。 于是大家都在省着度过最后几天，生怕抠门的学校食堂不给我们退饭卡钱。但我还是忍不了了，偷偷的溜到了食堂买夜宵。夜宵？夜宵只是把泡面往牛腩汤的卤水里面洗一遍，加点咖喱汁便乘在碗里。没有人会说自己喜欢这样的东西，但是饥不择食。 等我到了食堂门口的时候，夜宵还没开始卖。两个阿姨坐在椅子上。我坐在另一边，静候开卖。过了一会儿又来了几个初中生。 坐着坐着，有一位阿姨注意到我，便跟我聊起来。 「你是高三的学生吗？」 … 「既然是高三的学生，就提前给你打一碗面吧。」 说着，她走到窗口后面，拿起一碗面递给我，又往里面加了点鱼蛋，沉甸甸的。 我接过那份沉甸甸的面，连忙应了几句谢谢之类的话，在一旁吃起来。面还是以前的面，没有因为是高三的原因分量多起来。 「阿姨，能给我们也来一份吗？」旁边的初中生问。我当着他们的面刷的卡，自然是咽口水了。「你们明天也要去考试吗？」阿姨问着。 「我们明天要周测」其中的一位初中生说。 「周测是什么？」阿姨好奇的问着。 「周测..周测就是每周都会有一次的考试」 阿姨似乎有些困惑。「噢…那是高考吗？」她说。或许在她的 18 岁里也曾经憧憬过成为高中生，但在那个年代，人们总是为饥饿所困扰。 放下勺子，呆呆的，她似乎在等待着什么，又好像在想曾经的时光。 … 吃完面后，已经流进来一些人了。我连忙去跟阿姨说了一句谢谢，阿姨一怔，叫我把碗递过去。 「阿姨祝你明天考试顺利啊…」 更早一些，我又想到了曾经的语重心长的班任，又想到了那些不在学校的吹着空调的夏天。 想到了这三年来刮过学校的暖暖的晚风，这三年来蓝紫色的天空和红黄相间的夕阳，还有总是停在宿舍水渠对岸的那只白鹤。 我恍然大悟。 我终于想起来，我三年的青春留在了这所学校，永远地留在了那里。 它不会因为我厌恶这所学校而遗弃它，它站在过去的暖洋洋的晚风之中，倒映在蓝紫色的天空和红黄相间的夕阳下。它是我的背影，我留在学校的背影。 我的背影啊！它一直默默的注视着我。三年里，我与他形影不离，但在这一天，背着行李回家的这一天，我却忘了与他告别。 即使这些记忆最终会被蒙上尘埃，但这才是我高中三年来，真正宝贵的东西——不是课本上的知识，不是我投入进去的经历，而是这三年里我经历的一切，人与物，与自己。 渠水如泣如诉。 暖洋洋的晚风依旧地在校园里奔跑，也必然还会有人去追寻它们。我的背影，或许正坐在某个我曾经坐过的位置，回忆着美好的事物，期待着我再一次走进校门。 但在再一次跨入校门之前，我的帆必将要往更远的地方驶去。

笔者观望 Minestom 已经有一段时间了. 以前他的线程模型还不够成熟, 曾经联系 @TheMode 想帮他翻译那块的文档结果鸽了. 正好, 今天摸鱼的时候看了一眼 Minestom 官方, 发觉现在或许是时候上手尝试一下了. 简中圈子里吹 Minestom 的很多, 然而真正上手 / 普及 Minestom 开发的很少. 官方文档已经足够详尽, 因此本篇博文只作引路贴, 希望对 Minestom 感兴趣的你自己上手尝试. 配置环境 Minestom 主要托管在 JitPack 上. build.gradle: repositories { maven { name 'JitPack' url 'https://jitpack.io' } } dependencies { implementation 'com.github.Minestom:Minestom:VERSION' // 版本号自己去 JitPack 上面找 } 静静等待依赖图下载完成, 下载的过程中, 我们不难发现一些老熟人. 启动 Minestom 启动实现很简单, 只需要两行就搞定了. public static void main(String[] args) { var mc = MinecraftServer.init(); mc.start("0.0.0.0", 25565); } 一个空的 Minestom 实现在一秒钟内就能初始化完毕. 打开 Minecraft, 添加一个 localhost 到服务器列表中就能看到你的新 Minestom 服务器. 注意: Minestom 语境下的 实例 和 实现 可能和你想象中的不一样 例如: 实现/Implementation 是基于 Minestom 开发的服务端软件, 而 实例/Instance 不只指对象. ...

在今年六月的时候，SCF 发了一篇关于放弃 GitHub 的长文，把人煽的热血沸腾的。 正好，这篇文章提供了一些 GitHub 的 “代替品”，我打算试一试。 SCF 推荐了两个服务： CodeBerg – 公开的 Gitea 实例，前身是 Teapod. SourceHut – 貌似很久以前就有了，但是成为 Maintainer 要花钱订阅，Collaborator 不用。 因为只是尝鲜，就没有去看 SourceHut 了，所以用的是 CodeBerg. 登陆 估计是因为 Gitea 的原因，Codeberg 很多地方都和 GitHub 相似。此外，他们还提供了类似 GitHub Pages 的 CodeBerg Pages 服务，这点要点个赞！ CodeBerg 访问起来快很多，大概是因为还没受到 GFW 的恩爱吧。不过 Pages 服务对比起绑定了域名的 GitHub Pages 就有点不够意思了。 还支持暗色主题！ … 整体来说体验和自建 Gitea 其实差不多，自己建的 Gitea 也有 WebAuthn 支持这些有意思的东西，无非 SLA 问题。 官方还提供了一些文档，貌似写得很详细，而且还考虑到了不会使用 Git 的人群。虽然 GitHub 也有，不过我还没去看过，就不做比较了。 项目迁移 登陆后做的第一件事情就是迁移项目到 CodeBerg 上。支持的迁移来源很多，其中也包括 GitHub。 但是没有那么简单，由于项目体量稍微大了一点点，很快就触发了 Rate-Limit 导致无法顺利迁移。用多几个 UserToken 也无济于事 ...

写了上万行 Java 代码，相比你已经对 Java “木纳呆板"的语法恨之入骨了。 那么，有没有一种可能，我是说可能，我们可以给 Java 编译器写插件？ 如果你要在面包店里买面包，你最好跟店员说你要买哪块面包。本文所指的 Java 编译器 均为 OpenJDK 自带的那个 javac，而不是其他的前端编译器实现。 前言 自从 Java 8 起，Oracle 就将插件系统引入了 javac 中，因此是可以写 Javac 插件的。 虽然写一个 Javac 插件并且修改代码是可能的，但是这方面的资料很少（国内就更少了），并且大多内容重复（教你写个 HelloWorld 然后就结束），其次 javac 的东西也不是很好摸，毕竟不是公开 API（ JDK 9+ 开始已经不暴露在外了）。 恰逢今年还没写技术类的博客，就拿来磨磨刀吧。 先从插件说起 上文刚刚提到了一个词，插件。它其实正是 com.sun.source.util.Plugin。通过这个类，我们可以让 Javac 在编译时加载我们的代码。 加载了代码，那么做什么呢？所以我们立一个目标：给所有 @Jsonized 标注过的类都生成一个可以输出 json 的 toString() 方法。 什么意思呢？就比如说这样一个类： public class MyResponse { private final String message; private final boolean success; public MyResponse(String message, boolean success){ this.message = message; this.success = success; } } 然后你想把它序列化成 Json。 var response = new MyResponse("\"Success!\" Took me 114514 yr 1919810 m",false).toString(); response.equals(""" {"message": "\"Success!\" Took me 114514 yr 1919810 m", "success": false} """); 又快又便捷，还不需要第三方类库，这就是我们的目标。 ...

在「如何请求到他人的帮助来解决问题」上已经有许多优秀的指导文章，但在如何有效的帮助他人上似乎还是少了那么点东西。 授人予鱼不如…? 「帮助他人」自然算不上是什么难事，至少相比如何高效的提问来说是非常简单的了。但能够并不就代表着高效，很多时间我试着去帮助其他人解答他们的问题——无论难易或是问题给予的信息有多少，我总是将答案说的尽可能详细，想着以这样的方式来解决问题。 不得不承认这种方法有时相当有效，只需要告诉对方「啊，先这样，然后那样」他们的问题就被解决掉了。但是随着时间推移，我在社区里解答过的问题越来越多，渐渐的我感到疲倦。这种手把手的解答方式当然非常有效，但对方能得到什么，我们持续的输出知识又能得到什么？带着这样的想法，我开始不把话说的那么详细。 举个例子。 以下是在另一个群内发生的，相同的问题不同的答案： 我觉得我成功让对方思考了一番，而不只是我在唱独角戏。 所以说，有时候解决问题应当是引导提问的人寻找思考的方向，而不只是告诉他答案。正所谓 授人以魚不如授人以漁 问句应使用问号而不是句号 如果提问者的态度令人发指，自然应该拒绝它。 就我所在的圈子里而言，我经常能见到一些人是这样问问题的: 遇到这样的提问者，我通常会猜测两种人。 语音输入用户 日常聊天说什么话末尾都要用个句号，连问句和感叹句都不放过的人 当然，语音输入用户没有做错任何事情。我无法理解的是第二种人，为什么日常聊天什么都得带个句号呢？对句号的执念是如此的深… 当然，以上是我的个人吐槽，若有冒犯请多见谅。本段的重点不在于用问号还是句号，而是提问的态度。没有任何人有义务在社区里为了各自的问题来逐一解答，大家的时间都很有限，所以正确的提问方式（而不只是态度）尤其重要。试想一下如果遇到了这样的问题： 那么如何解决？一不知道用的是什么权限组插件，二不知道他是要干什么，这样的问题必须要有人来进一步引导才能解决，然而他甚至可能已经在群发这种问题，根本看不到你的反问。 由此，纠正错误的提问方式尤其重要，每个人都应该学会如何正确的提一个问题来尽可能快的得到帮助，对你好也对我好。 正如上文所说，在「如何请求到他人的帮助来解决问题」上已经有许多优秀的指导文章，但直接把这玩意扔出去多半也没有什么人会看。 但我们有别的做法。 还有一种是“问题类型收费表”，把最差的问法放最贵，最好的问法放免费，这也不失为一种巧妙的做法。 唯有问问题的人学着去问问题，解决问题的人才能把时间花在真正有用的地方上。 不要太多厨师 这句话其实出自英语里的 too many cooks in the kitchen，意思是这里有太多的人工作在同一件事情上，而这样会导致不好的结果。 正如上文的一个反例： 自由讨论当然好，但不适用于解决问题上，其实也很可能会演化成情绪倾泻的垃圾桶，每个人都在坚持自己的意见，甚至可能还会出现人身攻击。 当然，这种极端情况是后话而且并不多见。但一个问题确实不应该有太多的人上去解答，尤其是比较泛的问题。如果你已经看到有别的"厨师"正在解决这个问题，那么你只要纠正他的说法就好，而不是他说一套你也要跟着说一套，那样只会让提问的人更加混乱 「我 TM 到底听谁的」 找出真正的问题 有一种问题，我们管它叫做 Y 问题，为什么呢？ 因为 Y 问题是 X 问题的一个分支，解决了 Y 问题自然可以解决 X 问题，但不代表必须解决 Y 问题才能解决 X 问题。 这就是 XY-Problem ，大家都经常犯的错误。如果你遇到了一些比较不合理的需求，不妨问一问提问者「你的原始需求是啥啊」，或许你会得到一个新的看问题的视野。 举个例子: 「Q：有没有什么插件可以替换任意 GUI 里面的文本啊，我只找到替换聊天信息的」 「A: 你要替换什么文本？」 「Q：XX 插件的菜单里面都是英文的，我想通过替换来翻译一下」 「A: 直接在 plugins\XXX\gui.yml 里面改就好了，用不着找那种插件，况且也没有。」 ...

2022 早就来了，但是我的年终总结推迟了好些时候才开始写。如果是在之前的话，我大概新年一到就很迫切的把去年发生了什么事通通写下来的。 说是年终总结，不如说是对于去年发生的事情碎碎念。真要说起来的话，其实我感觉去年好像也没fa发sheng生le什da么shi事qing情。开了不少坑，虽然后面也没有完成几个坑。一是没时间，二是大多时间都用在摸鱼上了。 技术力仍然在提高，除了认识到了新的人，也对以往认识的人有了更深的认知。 今年猫猫还是没有回来，想它。 抑郁后的那段时间貌似有开始写小说… 不过写了几天很快也暂停了，最终还是没有想好我要写一个什么样的故事啊～还是多加沉淀再下笔吧。 虽然说从初中开始就总是想写点什么东西。但是写什么呢？ 透过窗外看到一些新鲜事物的时候，我总是能代入一个新鲜的故事环节里。如果细挖那些故事的设定肯定很不错的吧。 vape 还是没有破解掉。两年了，从初三到高二，但我已经把进度推进到了我暂时无法触及的领域，也算是比较骄傲的一件事情（也有朋友们的帮助），不过也没什么兴趣了 暑假结束之后分配到了新的班级，算是远离之前那一帮人了。新的班级里也表现的不太自在，然而我无法允许自己跟他们同流合污，我也有想坚守的行为底线。 心理变态，三观不正以貌取人的极端主义者难道不应该被教育淘汰或拯救吗？然而他竟在学校里成为一种典型。 更新的班级里是更旧的班主任。他不是童话书里的园丁，只不过有的老师是。 现实刺穿了我的后背，但我宁愿相信那里没有血迹。 又比去年浮躁了许多，可能是自从上了高中天天在学校留宿便也无处享清净以修身养性了。宿舍里是浮躁的人，班级里也是浮躁的声音，谈何学习？ … 年终总结，过去，现在，未来，亦如此。大概会是我最后一次写这东西了 感谢 4d3b2d63a26f50fd6eaa243921f37b459448fe91e9f86bb624eb084dacd895d6 。Powerful friendship 本来想更新几篇和泛型相关的文章的，还是看时间吧。写一篇年终碎碎念也得花不少时间呐

Java 作为一门 VM 语言，它的垃圾回收机制确实帮我们省了很多事情，我们不再需要去"手动管理内存的分配和释放"，只需要交给 VM 来做就好了。 然而，真的是这样吗？即使有神一般高性能的垃圾回收器，我们写代码时仍然需要注意它是如何标记垃圾对象的，因为垃圾回收器并不是万能的，仍然有一些工作需要程序员自己完成。 本文试图通俗易懂的讲解 JVM 上标记垃圾的方法，如有错误请在评论区指正。 两种标记垃圾的方式 或许你曾听闻过 引用计数法，也就是 一个对象被引用时计数器 + 1 ，解除引用时计数器 - 1，当计数器为 0 时将会被 GC，看起来非常可行。 但是这种方法没有被 Java 采用，因为他有两个显而易见的问题： 循环引用问题 如果一个对象内部引用了另一个 引用这个对象的 对象，那么计数器将永远不会为 0 计数器的维护问题 引用计数器的值会以极快的速度更新，更新任务变得繁重 或许因此，Java 采用了 可达性分析 的方法对垃圾进行标记。 可达性分析 可达性分析的思路很简单。 他从一组叫 GC Root 的引用出发，递归搜索出所有能被到达的节点作为存活的对象，而此外那些没有被搜索到的对象就会被标记 将被清理。 途中，被蓝色尖头指向的对象将不会被清除，因为他们间接或者直接的被 GC Root 引用。而旁边没有被 GC Root 引用的两个对象将会被清除，无论他们之间有什么关系。 不久，因为 Garbage F 和他的朋友 Garbage E 没有来自 GC Root 的直接/间接引用，他们就会被 gc 回收掉了。 想想看，如果在这个图中 Object C 建立了到 Garbage F 的一个引用，会发生什么？ ...

深夜了。 大家早早的闭上了眼睛，期待着黎明的光芒把他们重新唤醒。 窗外，大风呼啸着。我躺在床上静静地聆听风的呼声，应该是冬天来了。 闭上了双眼，就仿佛置身于世界之外，只有风的声还在耳边回荡。想到在几千年前风也是这么呼的，于是又觉着和过去的人有某种声息相通的联系。 像是凄凉的呼唤，又像是愤怒的咆哮——不过只是人主观给他添加上的情绪。风大抵是没有感情的，只是咆哮，从地球之初到现世皆是如此，毫无忌惮的咆哮着。想着，风又是一屑不顾地刮过窗外的小河，引起阵阵波浪，也刮的树叶动燥不安。 它试图撞进窗来，但是终究还是被挡住了，便在窗外向天公申冤。 我听着他们的声音安稳的睡了一觉. … 一觉醒来，世界又好像被大风改造成一番新景色。可能是拜前几天的台风所赐，夏日的痕迹荡然无存。大风划过我睡的迷迷糊糊的脸颊，让我打了一哆嗦。 大风天！每当到了这样的大风天，我总是能亢奋起来。大风吹过我的身体，就好像给我换了新的血，换了新的气。 我敞开胸怀，让大风使劲地吹。与夏日那股闷燥的气息不同，冬天的大风清爽怡人，它不仅能卷走一切，也能让我打一喷嚏。 吹着大风，往事爬上我的背脊。它们不断的提醒我，似乎，我喜欢大风天，不只是为了凉爽。 … 曾经，可能是很久以前吧，也是同样的大风天里，我给我的猫洗了个澡。 别人家的小奶猫，放个手就过来蹭，使劲的蹭，就怕你下一刻要离开，巴不得让你把它端在手里，放在心里。但我的猫从来不是，它知道自己是只有个性的猫，所以也有个性的活着。 它的个性也体现在洗澡里。跳出澡盆，大喊大叫，扒拉门把手… 我们费了好大劲才把它洗干净。大风在窗外呼啸，它冷的发抖，大抵是身上的水还没有沥干。正好明天还要上学，于是我抱着它到被窝里，头对着头睡了一觉。 猫没有逃跑，只是依偎着，暖暖的，房间里黑漆漆的，就好像世界上只剩下我和猫，以及窗外的大风。 … 曾经的一个没有寄宿的大风天，我走在回家的路上。 大风肆意穿过校园，视树们为标耙，刮的它们好不安分，就连太阳也慢慢的被压了下去。我悠闲自在的走在小路上，想着今晚吃什么，回家之后先做点什么。 有时，还能在路边发现流浪猫。我总是忘记带上水和猫粮——偶尔会带一些水，不过不知道猫愿不愿意喝，它也不出来，便放在它可能出现的地方许个愿就走了。 可怜的猫啊，我希望它能找到住所。 睡觉的时候，我躲在被窝里，任凭窗外大风呼啸也找不着我。 … 也是曾经，在一个大风天里，我淋着大雨回到了家，锁上门，瘫坐着只是哭出来。 还没哭一小会，角落某堆衣服里悉悉索索的冒出点声音。是猫吗？它听闻到我的声音，从它熟睡的地方跳出来，用身体贴着我走来走去，像是哭一样叫了起来。 我看着它忧心仲仲的样子，感觉傻傻的，又笑了起来。虽然阴云密布，但我有小太阳。 … 再后来，又是新年，又是一番喜庆的景象。追着人家的小牛在院子里绕着圈跑，在院子里玩玩具枪，在乡下体验"探险"，那时候还没有抖音，快手。 我坐在院子里，享受着晚风悄悄地吹过。 … 时光飞逝。 再后来，我上了初中，又上了高中，还住了宿，再也没有看夕阳和闲情雅致的时间，陪伴猫的时间也越来越少。 后来，家姐把它领了回去，再后来见他时已然过了两三年，但它仍然记得我，不禁让我万分感动。然而猫还是活不过人，只好在他现存的时候尽可能陪陪它，也算是让我不留缺憾了。 大风天卷走一切，也卷不走回忆和温暖。我吹着大风，听着大风，然而我却不觉得冷，就好像幸福的事情即将发生，就好像我还是曾经在床头旁哭的我。 大风天。每当想起这些事情，我就仿佛有了屏障，有了一个小太阳，不仅仅是挡住了大风，也烧掉了我的痛苦，我的惆怅。 2021.10.12 回忆。