Cytrogen 的个人博客（中文）

写写废文

2026-09-17T01:52:00.000Z

此「废文」非彼废文；指的是随手写的、不以传递信息或者涨流量为目的的短文。

它们通常包括生活琐事、流水账、没有观点且没有建设性的自言自语、想到就写的短随笔。

我最初是从「廢文小天地」那边看到的这个词儿。

https://trashposts.com/

但是当时没有细究「废文」到底是什么。

后来我在 Marcus 的签名墙那边看到「心是灵」也提到了这个词，并且说 Marcus 写的是「废文」。我就一下子对「废文」这个词有了映射⸺大概就是对日常生活的记录吧！

https://immarcus.com/wall

当然后面自己查了下才知道最开始写的那些定义。

至于为什么我会去看 Marcus 的签名墙…… 我只能说罪犯总是会回到犯案现场的。

求求你，来人告诉我其实你们也会评论完然后时不时去看看自己的评论吧……！

我之前有说过，我最近疲倦到难以聚集精力去思考了，所以我想要随便写点东西然后发发发。美名其曰 omakase 呀。

https://blog.cytrogen.icu/posts/2e54.html

所以我也发点废文好了。

现在努力找工作的期间，时间与精力变成一片一片的，像是碎片那样，再要求自己花一天的时间专注于阅读还有思考长文上，不太现实。

那娱乐换成更大众的看网文、短视频咧？我不习惯那样，并且看多了我会脑子腐烂掉、特别特别难受。

还不如写写废文呢。

比较有意思的是，我在学校的 WordPress 博客平台上注册账号以及创建网站后，我每次打开它都会涌现写废文的冲动。明明最开始注册它是为了写学术还有技术文章的。

不过我写废文有很强烈的「我」的味道。我还是不希望在学校的博客平台上展现「自我」。

所以作为替代的发泄口，我应该在这个博客站多用英语写废文。那是不是得分开下 RSS 链接呢？等下就去做吧~

总之你也写写废文吧。

大家都写写废文。

教小孩子的时候家长要闭嘴

2026-09-15T20:45:00.000Z

我和妹妹的年纪相差十岁多。待她十八岁成年的时候，我都三十岁了要。而这般年龄差意味着我们出生的环境截然不同，性格也天差地别。

比方说，妹妹是游泳健将，天天都要去本地的大学那儿接受训练，时不时还要去打比赛，而我是个 chairman，整天就坐在椅子上；妹妹数学成绩很差，我在她的年纪的时候上数学课就是来玩的；妹妹喜欢玩短视频平台，然后追韩国女团，我近乎不会使用短视频软件，也不喜欢明星还有偶像。

妹妹作为纯正的 ABC（在美国出生的中国人），她所接受的教育、在学校以及小伙伴那儿学习到的东西，意味着她会离父母这帮移民的文化越来越远。我平时都是跟她用英语交流。对父母的时候，虽然她能听以及说部分普通话，但到要描述稍微有些细的事情时，比方说想要父亲帮她剥香蕉，她就说不清楚，导致父亲以为她是给他香蕉吃。这时候我就要充当中间的翻译官。

非常有趣地，妹妹虽然是中国人，但并没有「继承」中国人的刻板印象，也就是先前说的，她的数学成绩很差。如果满分是 4 的话，她的数学成绩平均下来是个 2。

这让母亲愁坏了。她认识的和妹妹同岁的小孩子里，数学成绩都是平均到 4。母亲一直都是个有怪异竞争心的人，包括她从来不在乎我的学业，但听到我的 SAT 成绩远远不到满分时，还是嘲笑道「我以为你有多厉害呢！」⸺理由是她有个远房亲戚的女儿考了近满分、上了 MIT。

择校时，她也是完全基于所谓的「名校排名榜」来选。听到别人上的大学，第一时间便是去问 ChatGPT 这所学校的排名多少⸺拜托，学校排名我就先不说到底是什么鬼玩意儿了，择校的重点不应该是该校在专业上投入的资源么？你单看综合排名有什么用啊？

我上的大学虽然在计算机领域上糟糕到不知道说什么好，但是在商科上是数一数二的、学费远比纽约大学便宜，且同样位于华尔街旁边。一位在国内学习金融工程的亲戚有过来问我转学到美国的话转到哪所学校比较好，我就有提到我校。结果母亲事后跟我说那个亲戚在国内上很好的大学，来我校是不是屈才了。

那你就去问问你的 ChatGPT 老师好了，不要来问我！

因此，母亲也一直数落妹妹的数学成绩不够好，让她「担心」妹妹的未来⸺难道不是自己的面子吗？这些妈妈圈子整天就是攀比孩子的成绩、去的学校的成绩、学校里的绩点…… 真是令人感到恶心。小孩子也受此影响，觉得自己成绩好、刷题多，就是更聪明的，别人做得没有自己好，就是傻逼。就算是一起去游泳，也会出现因为不想要输给对方，所以故意挡路的情况。妈妈们再拍下来，跟其他妈妈们责怪说「哎呀这个小孩子攀比心太强了！」

不都是你们的原因么。

不过妹妹的成绩确实需要点推力。至少不要每次都待在及格线边缘吧。母亲给我钱说，她本来打算把妹妹送到辅导班里面，但如果我能教她的话，那不如把钱给我赚⸺顺便还能省掉给我的生活费⸺所以我就成了妹妹的辅导老师。

首先是应当给妹妹养成每日做题的习惯。要应付她现在的学校作业还有考试，熟能生巧是最好使的。于是我上网给她打印了一些数学题，让她平日做。

https://www.k5learning.com/free-math-worksheets/sixth-grade-6

美国公立学校的作业我还是清楚几斤几两的。作为练习、量完全不够。回父母家那天，我一边翻看基督教会送来的期刊⸺父母家里实在是没有别的书了⸺一边看着她做题。这时候就能看出她做题所运用的方法，比如说面对乘法题会更倾向于硬做。8 乘以 102，她会将其视为「8 乘以 102」然后算，而不是简单地将其视为「8 乘以 100 加 8 乘以 2」。我便跟她讲了下其实可以这么做，她半信半疑，验证下发现我说得没错，就 Ohhhh 地继续做类似的题。

结果扫兴的母亲在旁边看到我指点她，就不停开始问我，且还是当着妹妹面地说，「她是不是数学很烂？…… 别人都去补习了，成绩那么好，考那么高分…… 她数学这么烂，完蛋了……」

闭上你的嘴吧！我心里想着，然后叫她不要说了。

就是因为你们天天在想这种事情，所以害得小孩子们做什么都没有干劲儿。妹妹游泳好，很大程度是当时去的泳池那儿有个教练，看中了她，问要不要到他手下的泳队来。一次次训练、一次次打比赛拿到结果，妹妹也对此越来越自信，去年暑假还嚷嚷着要我跟她一起去水上乐园，要是我快淹死了她会来救我。

如果只是跟着母亲的思路去走呢？母亲最初让妹妹游泳，就是因为她的朋友的孩子们在游泳，所以也让妹妹跟着去学。同样的事情发生过太多次了。比如妹妹还会溜冰，因为她的朋友会溜冰，但母亲只看着妹妹的成绩、有没有比别人溜得好，然后整天责怪妹妹不够好，妹妹也就不再去了。再比如钢琴、篮球、羽毛球……

母亲根本不自知，这样做对孩子会有多大的伤害。让妹妹还在学习的时候就要跟其他已经熟练的同龄人们比，怎么可能比得过？再者，只剩下攀比与竞争的话，兴趣爱好就不再有乐趣在内了。妹妹跟我谈及游泳时，都很少说自己比赛拿了多少名、有多少奖牌，而是给我看各种游泳相关的迷因、梗图、如何更快地在水下翻身等等。我能借此看出她确实享受着游泳。

要想要在学习上做得好，首先是要慢慢喜欢上它，而喜欢的前提在于反馈。数学题听上去是非常枯燥吧，但我过去在一点点写计算题时，竟能少许地感觉出喜悦，一种脑子正在运转的喜悦。我希望我能让妹妹体会到这种感觉，哪怕是一点点，说不定都能让她对学习有些改观。

但母亲的做法，无疑是让学习变成零和竞争，且是无尽的、永远都无法赢的竞争⸺每次好不容易「赢」过路人甲，下一个就要「赢」路人乙、路人丙、路人丁…… 一次次数落，一次次叹息，也都是在责怪妹妹「你不够聪明」、定义她。最终介绍妹妹时，他们都要说这是个数学很烂的女孩。

我讨厌这样。

八月份的结尾

2026-09-15T05:35:00.000Z

原本室友计划选一天我们俩大吃大喝的，但我们近期食欲都不咋好，想不出来吃啥好：是尝鲜呢？还是吃点吃过的东西呢？

最后我们决定时不时出去一小会儿，就不用选一整天做计划了。俩聪明鬼儿。

因为每次和室友出门后再回家，她都不让我玩电子设备，所以写日常生活记录得过段时间我有空才能写……

唱 K 真好玩

八月底我们就去了韩国城的 KTV DUET 玩。虽然是韩国城里的 KTV，但是员工内部交流说的是日语。

一进包间，很有之前看日本动漫里看到的 KTV 的味道。

门旁边有电话，可以打给前台，前台也会打给我们。

电视不知道为啥在放凉宫春日耶。室友之后确实也唱了她的 God Bless。太厉害了，我就算会日语我也唱不动这首歌。

吃的都很贵，当然一个都没有点。嚯嚯。

其实进包间之前员工们要确保你没有带自己的饮料，所以还要搜包包。搜到我的时候，我的包里赫然出现…… 一罐八宝粥。我们三人都愣住了…… 那是我先前打扫卫生，从家里找到的过期八宝粥，打算放身上备用、哪天不小心快饿死了可以吃…… 员工不知道有没有认出来它，但总之允许我带八宝粥进包间去…… 好尴尬……

咳咳。点歌用的是个 iPad，里面的软件有中日韩三种语言的歌曲外，还有英语的。

很多八零后金曲都能搜到，真是有心了⸺我知道是因为我只会唱它们。

遠くで暮らしてるあなたの事を
ふと思い出す　元気ですか？

无奖竞猜这是哪首歌呢？提示是中国有翻唱版本。

时间结束之前，二人一起合唱了 September 还有 Just the Two of Us 玩：

I see the crystal raindrops fall
And the beauty of it all
Is when the sun comes shining through
To make those rainbows in my mind
When I think of you sometime
And I wanna spend some time with you

不得不说原唱们的音色实在是太动听、太厉害了。

两个人唱了一个小时花了 14 美元税前。

这个 KTV 的隔音蛮一般的。到前台的时候就已经能听到其他包间里的声音。我们出包间后还听到隔壁房间在大喊中文歌，笑死。

然后我就想到，难道我们的声音也被传出来啦？室友在这一个小时里还唱了 unravel 这样中间要吼的歌。

唱完 K 去附近的日本超市里看了下，发现这种奇怪的东西：

香菜口味的 Doritos……？

这家日本超市提供熟食；晚上八点后熟食全部打七折。饭团自己已经有三个 10 块钱的折扣，竟然还能再叠加优惠，最终我们花了 7 块钱买了三个饭团。

韩国城大晚上的依然都站满了人。不过这里的路窄窄的，行人都非常爱抽香烟⸺美国这儿会抽香烟的人并不多。朋友们告诉我说除了东亚来的人外，其他人都去抽电子烟或者吸大麻去了。

我本来是打算去附近的街机厅里玩 maimai DX，结果过去发现机器出问题、用不了了…… 二人只能悲伤回家。

回家路上拿饭团出来吃，一吃就清楚为什么它这么便宜了：馊了！味道好恶心！呕呕呕！

回家后我发现室友在看网页解密游戏的实况视频。我第一时间想到的是 lomando 哎⸺读者朋友们，好奇心会害死猫，不要搜⸺以及另外一款游戏，在尝试表演出「时间」维度时也使用了网页：玩家可以点到下一个网页（未来），然后回到上一个网页（过去）来选择正确的选项。我觉得这个设计非常惊艳！

室友就问我要不要也玩个试试看。我们就上网找了个蛮有名的「大学生登山失踪事件」的网页解密游戏玩。我的游玩体验直接看我的 Fediverse 记录吧，我不想要在文章里剧透：

https://gts.cytrogen.icu/@cytrogen/statuses/01M0YBTDFTYPZHANG9S0WCDRR1

我意识到这种游戏非常好做，所以我就在想能不能做款这样的网页解密游戏呢？玩家误打误撞访问了个独立博客，但已经很久很久没有更新了。接着玩家可以在这个博客网站里挖掘和探索、填写 slug 来查看没有看到的网页、通过链接转向其他站主的「网站」，慢慢通过他们的文字拼凑出他们的画像、为什么他们离开了互联网……

引号用起来是因为这些「网站」都不是真正的网站，只会是挂在我域名下的假网站。

自制麻酱

因为要上学了⸺我求职不能，只能进一步推进学业啦……⸺所以我俩吃饭的事儿得商讨商讨。它最好是这样的：

吃的时候加热就能吃
好存储
好吃
好吃
好吃
营养

几年前我们刚上大学那会儿，就钻研出来个食谱，即炸酱面。

提前将猪绞肉还有茄子炒好，放一个大容器里。之后每次要吃的时候就煮上面，再用勺子㧟一勺加热就能吃了。

蔬菜则考虑要么水煮上海青，要么就干啃沙拉叶子吧。

这次室友想了些新东西。茄子还是有一点点小贵的，但同样口感的西葫芦就便宜。

她前段时间还买了 Tahini，说是希腊芝麻酱，要比中国的芝麻酱更浓稠、更不油。拿它和花生酱搅拌在一块，再放点老干妈、耗油啥的，便能做出非常美味的麻酱。

说到花生酱，今年我才知道所谓的 peanut butter 就是花生酱。我以为它真是花生配黄油呢，所以数年来从来没有碰过它。结果它只是质感像黄油，所以叫 peanut butter。我真的服气了。早说啊，不然我就不买华人超市里又小又贵的花生酱了。

咳咳，我们也去了 Target 买猪绞肉。他们一磅猪绞肉 3.99 美元，看上去颜色很不错，时不时也在打折。

一天我清理厨房柜子，翻出来许多母亲以前给我的干货，比如黑木耳还有香菇。

先前我们在 BiliBili 上翻到过个视频⸺频道主应该是叫什么小胖⸺说微波炉可以加速泡软这俩。黑木耳其实还好，拿温水泡，放一会儿自己就好了。不过香菇有点麻烦。

我是按照这个网页做的：

https://kthu1031.pixnet.net/blog/posts/8172734348

网页很短很精妙，所以我就不总结了，直接点进去看吧。

总之微波炉可以做很多事情呢，还可以做蔬菜干。

油热后，下猪肉翻炒，然后塞西葫芦丁炒，然后塞切好的香菇跟黑木耳，然后下豆豉酱啥的…… 唉我又不是写教程的，这种事情快快带过就好啦。

一边也要煮上意大利面。我虽然是碳水大王，能够吃下很多很多碳水，但身体健康不允许我再摄入更多的碳水了（不能摄入太多糖分）。所以我的主食得换成更不好消化的粗粮，例如 country 面包，还有意大利面。

说是这么说，不过最后配上炸酱，还有一勺麻酱…… 我也不知道这健不健康，总之我没有在掉体重耶，真是件好事。

投影仪

我上个月在 Target 买了个五美元的便宜小相机。为此我买了张 Micro SD 卡⸺目的其实是烧 bin，因为我想试试能不能改掉小相机的 UI 界面，太丑了⸺不过我借此想到了桌子下方的投影仪。

这台投影仪是母亲不知道从哪里搞到的，非常不好用。以前它还能通过 HDMI 线投影电脑上的内容，现在完全不行了。

既然我有 Micro SD 卡，兼送的 SD 卡适配器，那我岂不是可以拷贝视频文件到 Micro SD 卡内，再通过插入 SD 卡适配器来让投影仪读取文件？

事实证明确实可以。

这个视频是随便找的，之前用骑车用的录像机拍的第一人称游玩 maimai DX。

因为录制不到游戏内的音频、只能听到按键音，就意外发现我的节奏感真是差到没边儿。玩音游不过是玩成另一种打地鼠。

晚上我拷贝了电脑上的一些电影文件，投影到墙上看。画质还算可以，但是音质是个问题。我不清楚这个破投影仪能不能连音响。

投影仪没有图片因为当时没有拍。

爱尔兰酒吧

我们家附近有非常多酒吧，而它们往往都是爱尔兰酒吧（Irish Pub）。

我喝不了酒，所以很少往酒吧走。室友能喝，再加上酒吧是个可以让他人放下戒备的场所，她经常跟人去酒吧交流，并往往能够快速得到他人信任⸺听起来感觉很毛骨悚然啊。

我们从共享办公室出来后，发现附近就有家。从外往里看感觉氛围非常不错：

于是我们就进来啦。里面的音乐有点大声，貌似后面有个点歌机。吧台非常漂亮。

该酒吧是体育酒吧，墙上的电视都在放体育赛事的直播。

我对体育赛事完全不感冒…… 室友也是，不过她觉得了解下没什么大不了，更何况体育是个非常容易就能和本地人打好交道的话题。

它有多么好用呢：

https://immarcus.com/blog/third-wheel-on-the-plane

最近似乎是网球的季节？⸺「季节」这个词用在这里感觉怪怪的。

酒吧内部的墙都是红砖墙⸺或者装饰成红砖的样子⸺木制的吧台⸺或者装饰成木制的样子⸺都让「单单是待在这儿」都觉得让人赏心悦目。

不过音乐依然还是太大声了。吵死了。

室友说我声音有时候很低沉，有时候很高昂。我后来发现这取决于「我能不能听到我自己」。

当外面都是很大的声音，以至于我有些听不到自己时，我的声音就会拔高、变尖。而安静的场合里，我的声音会很低。

其实之前唱 K 的时候我才意外发现，草东没有派对的主唱很多歌音调都很高，我反而不太好唱上去，只能手动降调。

让室友帮我点了个 mocktail，说白了就是「假酒」⸺其实是混合果汁。

室友喝生僻，牌子应该是 Bluemoon。她一喝快，情绪也变得高昂，开始拉着我说东说西，然后亲我的脸颊。她说，酒精这东西只要喝快了就是这样，如果她喝慢点，几瓶日本清酒下肚她也不会醉⸺

⸺吗？我又不是没照顾过你，你猜我信不信。你上次还说自己能干倒一米八的同龄男性呢。

夜驱

YOASOBI 有首歌叫作《夜に駆ける》。只取汉字出来便是「夜驱」，而原文意思是「向夜晚奔去」。

「夜晚」……「奔去」…… 哦！大晚上跑步锻炼也是「夜驱」！

这是我有时候脑子在想的东西，不要在意。

上周一我重新开始跑步锻炼。有段时间没有练，身体变得不习惯起来，路上还下了点毛毛雨。

雨停后我向上看去，感觉很可怕。

云朵不像往常那样，乌乌盖住一片，而是一层一层的。我抬头，意识到自己能看到很远…… 很远…… 很远，或许远到我自己都难以想象。然后我控制不住地开始幻想，我从那个很远很远的地方掉下来……

这是我很小的时候就会有的幻想。我不知道为什么，姑且认为是恐高。

而这个幻想总会让我想起超人还有一架骷髅。我也不清楚为什么。

室友的身体素质跟我没法比。我还在慢悠悠跑，她已经跑完了，转一圈回来找我。据她所说她还会巴西摔跤和拳击…… 如果我们俩非要决一死战，我的唯一获胜机会是把匹克猫丢到她脸上，好让她过敏。

至于为什么不下毒。家里做饭的人是她。我是白吃。

曼哈顿河边的林荫小道，非常安静、暗暗的。

Ai Fuji Market

我和室友这个学期选的课都很晚下课。回家路上我们打算去帝国大厦附近看看，结果就找到这家 Ai Fuji Market，也是一家日本超市。

我原本以为它跟之前去的 Bread & Butter 一样，也是个 24 / 7 营业的自助兼市场型食堂，结果不是，人家就是家日本超市，然后卖点寿司、便当啥的熟食而已。

https://blog.cytrogen.icu/posts/c783.html

他们家晚上八点之后，所有熟食都打半价！

Ai Fuji Market 的官网：

https://aifujimart.com/

我们一看时间，九点多，正好可以买点半价熟食吃了垫垫肚子。

室友拿了唯一一盒味噌拉面，10 块钱变成 5 块钱，划算极了。我在鸡胸肉炒面跟泡菜炒面里，选了颜色更丰富的后者，尽管我讨厌吃泡菜…… 原因是前者看上去一点食欲都没有，真的就只是白色的鸡胸肉配炒面。

我们也拿了些小食，像是鳗鱼饭团、海带丝沙拉。

店内配有微波炉、热水，还有两个用餐区。完全可以进来只点桶泡面，然后泡水开吃呢。

这四样东西如果没有记错的话花了 13-14 美元左右。

拉面是和寿司一起放冰箱的，吃前需要微波一下。它的生态环境就算是原价 10 块钱，都让人觉得很赞：有完整的蛋、几片猪肉、笋、黑木耳、玉米……

同个区开的一家以 10 美元一碗拉面为招牌的拉面店，碗里面真的就只有拉面、汤，还有一点肉片哎！加蛋要多付一两块，给的还是蛋的一半。

泡菜炒面…… 因为我不喜欢泡菜，所以对它的评价很差。炒面本身有点太干，建议加一点水然后拿去加热。

吃完我们还买了杯西瓜小方。两个人分着吃几口就吃完了。甜度就那样吧，不过价格还可以，应该是 2-4 块钱左右，然后打了八五折。

离开的时候店铺正好关门。我观察到他们还有个 gelato（意式冰淇淋）小车。我近些年老是看到 gelato，但依然没搞明白它和冰淇淋车里卖的冰淇淋有啥区别。

室友的母亲据说非常喜欢吃冰淇淋、雪糕，还有冰棍。我对这类食物也很挑剔：我只吃奶味的。因为小时候只会吃（伊利牧场）小布丁、大布丁（包装是个奶牛），还有老冰棍⸺老冰棍还分更像是冰块的版本，以及更奶的版本⸺我不清楚它们的区别。是小时候大大跟我讲的。搜了下前者我指的是老冰棍棒冰，后者应该是德华原味酸奶那样的用纸包的，但我不记得名字。

Golang 学习笔记・壹：基础知识直到 struct

2026-09-14T00:21:00.000Z

有段时间没有写编程相关的笔记了。这篇本来是打算作为条目写在月刊的「编程历程」里，但越写越多…… 干脆作为学习笔记发出来好了。其实应该写到学校博客上，但都写到这儿了，还是算了。之后翻译翻译再发到那儿。

我复习 Python 的一大原因是申请的一岗位要求做 Python 的 coding assessment，另是感觉自己确实对 Python 的理解不够透彻。

这次则是因为有猎头联系我，问我是否有意申请 Golang 开发的岗位，并且可以无视我的工作经验不足一点⸺他们居然都要求五年以上的工作经验！要是没有初级岗位的话，怎么才能攒够这么多工作经验呀！我的一到两年工作经验还是靠创业攒出来的。

之前我还是读过 Golang 的代码的，易读性让我想起了 Python 还有 JavaScript，所以不难读。不过要理解编程语言，不能只因为易读性所以就轻看它。

我用的教材依然是 freeCodeCamp 里的：

https://www.freecodecamp.org/news/learn-golang-handbook/

我意识到高中的时候我买了个国内的服务，叫路飞学城的黑金卡，差不多五年内都会陆续放编程语言或者框架的教程视频吧。但我一直都没有去看它。上次看还是学习网页爬虫的时候。唉，消费不代表学习。尤其是我买该服务的那年是 2023 年。年底 ChatGPT 出现，我的编程历程也被暂停了。悲哀。

如果有人感兴趣，我可以将账号密码分享给你，反正它也没法改密码啦。不过课程质量我只能说和 BiliBili 上面的免费录播课差不多。

基础知识

网站上第一个视频，也就是 9 个小时的那个。开头二十分钟都是在解释 Python 那样的解释型语言以及 Go 这样的编译型语言的区别。

总之先自己抄个 Go 代码好了：

package mainimport "fmt"func main() {    var username string = "wagslane"    var password int = 1234567890    fmt.Println("Authorization: Basic", username + ":" + password)}

关于静态类型，我最初接触的 Python 还有 JavaScript 都是动态类型，后者还是弱类型、会做自动转换类型这种蛮讨厌的事情。

最开始我还觉得这是件不错的事情咧，结果后面还是乖乖入 TypeScript。我真的没法理解当时认识的网友们是如何靠 JavaScript 写大项目的。

上述的代码就运行不了，因为字符串和整数类型不能加在一起。

其实我才知道 Java 虚拟机是真的虚拟机。我以为是个修辞呢。我对 Java 一窍不通。我只知道我在行的 NestJS 框架是基于 Spring Boot 的架构设计出来的。

关于内存清理、垃圾收集什么的，因为之前一直都是个臭写 Python 的，根本不需要管它们，所以完全是初次接触。

Go 和 Java 有点像，会自动收集垃圾。不过它没有 JVM，有的是运行时。

Dexter Darwich 比对了下 Java、Go，还有 Rust 服务在闲置时会吃掉多少内存，结果 Go 和 Rust 的数字都在 1MB 以下，Java 单个干到了 162MB⸺不过视频里的图表没有说清楚条件、时间等因素。总之要知道的就是 Go 没有 Java 那么吃内存，但不如 Rust。

频道主也解释说在真实的情况下，Go 服务不可能真的比 Java 服务少吃 100 倍的内存。它绝对是比 Java 服务少吃不错，但没有图表中的那么夸张。

他没有解释「运行时」是什么，所以我自行搜索了下，因为我平时写的 TypeScript 还是要靠 Node.js 运行时才能变成网络服务的嘛。

我就引用王译锋的知乎回答好了：

https://www.zhihu.com/tardis/bd/ans/2133648600

实际上编程语境中的 runtime 至少有三个含义，而目前的回答都只侧重讲了其中的某一个，所以看起来很令人困惑。这几个含义分别可以这样概括：
指「程序运行的时候」，即程序生命周期中的一个阶段。例句：「Rust 比 C 更容易将错误发现在编译时而非运行时。」
指「运行时库」，即 glibc 这类原生语言的标准库。例句：「C 程序的 malloc 函数实现需要由运行时提供。」
指「运行时系统」，即某门语言的宿主环境。例句：「Node.js 是一个 JavaScript 的运行时。」

那 Go 运行时是什么哩？根据官方 FAQ 的说法：

https://go.dev/doc/faq#runtime

Go has an extensive runtime library, often just called the runtime, that is part of every Go program. This library implements garbage collection, concurrency, stack management, and other critical features of the Go language. Although it is more central to the language, Go's runtime is analogous to libc, the C library.
It is important to understand, however, that Go's runtime does not include a virtual machine, such as is provided by the Java runtime. Go programs are compiled ahead of time to native machine code (or JavaScript or WebAssembly, for some variant implementations). Thus, although the term is often used to describe the virtual environment in which a program runs, in Go the word "runtime" is just the name given to the library providing critical language services.
Go 拥有一个庞大的运行时库，通常简称为「运行时」，它是每个 Go 程序的一部分。这个库实现了垃圾回收、并发、栈管理以及 Go 语言的其他关键特性。尽管它在语言中的地位更为核心，但 Go 的运行时类似于 C 语言库 libc。
然而，重要的是要理解，Go 的运行时并不包含像 Java 运行时提供的那种虚拟机。Go 程序是提前编译成原生机器码的（或者在某些变体实现中编译为 JavaScript 或 WebAssembly）。因此，尽管「运行时」一词通常用于描述程序运行的虚拟环境，但在 Go 中，「运行时」只是为提供关键语言服务而命名的库。

所以 Go 运行时更倾向于是第二类的「运行时库」。和 Node.js 运行时更像的其实是 Java 的虚拟机。

类型

到视频的 27 分钟，终于是开始讲类型了！Go 的基础类型有：

bool
string
int、int8、int16、int32、int64
uint、uint8、uint16、uint32、uint64、uintptr
byte
rune
float32、float64
complex64、complex128

uint 是 unsigned integer 的意思。之前学习 C 语言还是 C++ 的见过，但不记得是干什么使的了⸺频道主说 uint 只有正数，没有负数。

complex64 还有 complex128 用来代表虚数的。我的数学已经还给高中老师了，所以你要问我虚数是什么，我也不知道！我也不会使用这两个类型的！大概！

后面带数字的类型，那些数字指的是比特（或者位元，总之是 bit）大小。例如 uint8 类型的数据大小是 8 比特，那么能存储的最大的数字是 255。

byte 类型其实是 uint8 的别名；rune 类型其实是 int32 的别名。

虽然说是 short variable declaration，但这个 := 怎么看怎么是 Python 的海象运算符啊！不过我自己搜了下，并不是同个东西，莫名失望了一下。

Go 的情况是，以下两个语句有着相同的功能：

var empty stringempty := ""

它能够声明新的变量，并且初始化它。

Python 的海象运算符的作用是在表达式内部给变量赋值，并且返回该值。更重要的是它是个表达式，所以可以出现在 if、while 条件里。例子：

if (n := len(data)) > 10:    print(n)

回到 Go 的类型。要打印变量的类型可以这样写：

fmt.Println("The type is %T", x)

频道主建议说，除非真的需要关心比特大小的话，用 int、uint、float64，还有 complex128 即可。

其实看到这里，我感觉自己看视频就略显啰唆了些。所以我打算直接看 handbook 的文字内容。等我在某个概念上卡住了，再回去看视频好了。

Go 的常量：

const myInt = 15

它们被定义后就不能被改变了。

我本来想说它让我想到 JavaScript 的 const，结果视频里说没有。唉我又被表象欺骗了。

Go 的常量必须要在编译的时候就声明其值。也就是说，常量不能在代码运行时才决定自己的值。

频道主吐槽说 Go 格式化字符串的方式不如 JavaScript 还有 Python 的优雅。

Go 的做法有二：

fmt.Printf：这不是 C 语言的台词吗⸺吓，还真是。它将格式化的字符串打印到 STDOUT
fmt.Sprintf()：我有点怀疑设计师是不是想要拼个 sprint 出来。总之它返回格式化的字符串

它们俩都会用到格式化动词：

不确定用哪个格式的话，可以用 %v：

s := fmt.Sprintf("I am %v years old", 10)// I am 10 years olds := fmt.Sprintf("I am %v years old", "way too many")// I am way too many years old

%s 对字符串。

%d 对整数。

%f 对小数：

fmt.Printf("I am %f years old", 10.512)// I am 10.512000 years oldfmt.Printf("I am %.2f years old", 10.512)// I am 10.51 years old

我实在是不喜欢这种写法。我更习惯于 Python 的 f 字符串……

shuang = "爽"print(f"这样写超级{shuang}的")

条件

Go 的条件：

if height > 6 {fmt.Println("You are super tall!")} else if height > 4 {fmt.Println("You are tall enough!")} else {fmt.Println("You are not tall enough!")}

它实际上是：

if INITIAL_STATEMENT; CONDITION {}

所以可以这么写：

if length := getLength(email); length < 1 {fmt.Println("Email is invalid")}

其实就是：

length := getLength(email)if length < 1 {fmt.Println("Email is invalid")}

函数

Go 的函数写法：

func sub(x int, y int) int {return x - y}

很用心地，Go 的参数要是类型相同，就能这么写：

func add(x, y int) int {return x + y}

频道主使用的平台 boot.dev 里提到，C 语言声明变量类型时会将类型放左、变量名放右。

Go 的开发者认为这很糟糕，因为：

int (*fp)(int (*ff)(int x, int y), int b)

这段代码声明了个指针 fp，指向一个函数。该函数的返回值是 int，并接收两个参数：第一个参数 ff 本身也是个指向函数的指针（接收两个 int 并返回 int）；第二个参数 b 是 int。

它是由内向外的，也就是说阅读这段代码，需要从中间的 fp 出发，然后先看右边的括号、解引用。看到 ff 时又要重复一遍由内向外的解读。最后你才会看到最左边的 int，也就是 fp 的返回类型。

还有个例子是：

int (*(*f)(int))[5]

f 作为一个函数指针，返回「指向含 5 个 int 的数组的指针」。

我讨厌指针……

Go 则是名字在前、类型在后⸺想必读者朋友们也看出来了⸺阅读方法永远是从左到右。

作为比对。首先是 C 的写法：

int xint *pint a[3]int (*fp)(int (*ff)(int, int), int)

Go 的同样结果写法：

x intp *inta [3]intf func(func(int, int) int, int) int

我不太懂 C 语言，也不懂 Go，所以我就拿 Python 还有 TypeScript 做例子好了。它们正好也是站 Go 这边的：

x: intp: Callable[[int], int]  # 类似于 Go 的 func(int) int# ffFf = Callable[[int, int], int]# fpfp: Callable[[Ff, int], int]# 如果对应 C 原样嵌套的写法fp2: Callable[[Callable[[int, int], int], int], int]

怎么感觉 Python 这个写法也是莫名其妙。其实和 Go 的区别不大。

let x: number;let f: (a: number, b: number) => number;// fftype Ff = (x: number, y: number) => number;// fp：接收 Ff 还有 number 并返回 numberlet fp: (ff: Ff, b: number) => number;// 如果对应 C 原样嵌套的写法let fp2: (ff: (x: number, y: number) => number, b: number) => number;

TypeScript 的读上去更好读些。因为有 => 可以表示后面的类型是返回类型，这样就能跟参数类型区别开来。

总之学回 Go。函数还有参数的用法：

func main(){x := 5increment(x)fmt.Println(x)}func increment(x int){x++}

猜猜看最终会打印什么咧？

答案是⸺

⸺ 还是 5。

Go 传参传的是复制品。到 increment() 的时候，其实出现了两个 x：一个在 main() 的世界，一个在 increment() 的世界。

所以 x++ 只是让在 increment() 世界的 x 加了一。main() 世界打印自己的 x，打印出来还是 5。

这个蛮好理解的。不过有趣的是 Python 里，如果传入的是可变对象，例如列表，在函数内进行 append() 操作，外部的列表就会有变化。

而 Go 是无论传什么都是传复印件。

这个话题应该是和引用、内存等概念相关的。我不是这块的专家……

Go 的赋值也是复制值。

x := 5

找个空的内存地址然后塞入内容 5。

y := x

这里是将 x 的值复制了一份，放到了 y 的内存地址里。

x = 10

如果改了 x 的话，就只有 x 的内存地址被改动。

如果希望函数能够直接改到原件，而不是简单改复印件的话，就要用到指针了。对于 Go，是这么写的：

x := 5p := &x

& 会拿 x 的地址，然后存在 p 里面。然后我们可以用 *p 来顺着地址找到 x 的内存。

func increment(p *int) {*p++}x := 5increment(&x)fmt.Println(x)

这样就能改变 main() 世界的 x 的值了。

无视返回值的做法和 Python 的很像：

func getPoint() (x int, y int) {return 3, 4}x, _ := getPoint()

这很重要，因为 Go 编译器会因为你没有使用定义好的变量而报错⸺非常罕见地！很多编程语言只会将其视为警告。

Go 可以命名返回值：

func getCoords() (x, y int) {return  // 这个会自动 return x, y}

不过这样写只适合给短小的方法。代码一旦长起来，这么写读起来就特别难受。你总不想读到最后然后发现代码没有写明会返回啥，然后扑哧扑哧跑回签名去看吧。

比较有趣的是，写在返回签名里的变量是已经被命名好的。所以：

func calculator(a, b int) (mul, div int, err error) {if b == 0 {return 0, 0, errors.New("Can't divide by zero")}mul = a * b  // 用的是 = 而非 :=div = a / breturn mul, div, nil}

对比这样写要好很多：

func calculator(a, b int) (int, int, error) {if b == 0 {return 0, 0, errors.New("Can't divide by zero")}mul := a * bdiv := a / breturn mul, div, nil}

因为前者可以直接从签名得知返回值的内容。

Go 有个概念叫作 guard clauses，即逻辑应当被写成一维的，而不是层层嵌套的。作为（噩梦般的）反例：

func getInsuranceAmount(status insuranceStatus) int {amount := 0if !status.hasInsurance(){amount = 1} else {if status.isTotaled(){amount = 10000} else {if status.isDented(){amount = 160if status.isBigDent(){amount = 270}} else {amount = 0}}}return amount}

这是人类写的代码吗。

等下，我笑不出来了。我校确实用的是类似的 if else 架构来写学生数据的。你知道我当时爬数据包看到六十万字符的内容有多么绝望吗：他们特么地为了让前端显示学生的兼修是什么，居然将所有的兼修都塞到一个 if else 逻辑内，然后让前端一个个查询该兼修的值是真还是假。如果假，就进到下个嵌套继续查。而同样的逻辑，在这一整个学生信息数据包内，出现了至少四次！

更绝望的是当时我在写浏览器插件，需要解析这个数据包并抽取所有有用的值出来，可以让学生们更快更方便地看到自己的数据、需要修什么课才能毕业…… 就因为这个数据包的设计，我放弃继续开发该插件⸺去你的吧！

Guard clauses 要求的写法是：

func getInsuranceAmount(status insuranceStatus) int {if !status.hasInsurance() {return 1}if status.isTotaled(){return 10000}if !status.isDented(){return 0}if status.isBigDent(){return 270}return 160}

这么写无论是哪个编程语言都是个好习惯。

不过对于这样的例子，就不适合用 guard clauses 了：

func discount(c Customer, amount int) int {if c.IsVIP && c.HasCoupon {return max(vipRate(amount), couponRate(amount))}if c.IsVIP {return vipRate(amount)}if amount >= 1000 {return 90}return 100}

规则一和规则二的区别只是「有没有优惠券」而已，但读者要自己意识到第一个 if 拦走了带券的 VIP，所以第二个 if 到这里的必然是无券 VIP。

同时把它们对调的话，行为就错了，但是代码没有任何提示。

这时候用 switch 更好些：

func discount(c Customer, amount int) int {switch {case c.IsVIP && c.HasCoupon:return max(vipRate(amount), couponRate(amount))case c.IsVIP:return vipRate(amount)case amount >= 1000:return 90default:return 100}}

还有这样的例子，写成 guard clauses 或者嵌套都很奇怪：

func shippingFee(w, v int, remote, urgent bool) int {heavy := w * 2 > v * 3if remote && urgent && heavy {return w * 2 + 50 + 80}if remote && urgent && !heavy {return v * 3 + 50 + 80}if remote && !urgent && heavy {return w * 2 + 50}if remote && !urgent && !heavy {return v * 3 + 50}if !remote && urgent && heavy {return w * 2 + 80}if !remote && urgent && !heavy {return v * 3 + 80}if !remote && !urgent && heavy {return w * 2}return v * 3}

我如果要维护的代码都是这个样子，我会大哭出来的。

如果改成嵌套写法，我会哭得更大声。

正解是将两个独立的维度各自拆成函数，然后组合起来：

func baseFee(w, v int) int {if heavyByWeight(w, v) {return w * 2}return v * 3}func surcharge(remote, urgent bool) int {fee := 0if remote {fee += 50}if urgent {fee += 80}return fee}func shippingFee(w, v int, remote, urgent bool) int {return baseFee(w, v) + surcharge(remote, urgent)}

`struct`

struct 这个东西其实就是把不同类型的值打包在一起、起个名字，当作新的类型用。

也就是 TypeScript 里的 interface：

interface Car {  make: string;  model: string;  height: number;  width: number;}

换成 Go：

type car struct {Make stringModel stringHeight intWidth int}

我搜了下，发现 Python 也有类似的写法，只是我对 Python 的理解还没有到那儿：

from dataclasses import dataclass@dataclassclass Car:    make: str    model: str    height: int    width: int

Go 是这样用 struct 的：

myCar := car{Make: "Tesla",Model: "Model 3",Height: 144,Width: 185,}fmt.Println(myCar.Make)myCar.Width = 190

如果 Go 的世界没有 struct 的话，假设我要在函数之间传递「车」的信息：

func register(make string, model string, height int, width int, owner string) {}

万一我想要给「车」的信息多加个「它有多少个轮子」咋办？我要给每个以「车」的信息作为参数的方法都改一遍么？

有 struct 的话，直接这样写就好了：

func register(c car) {}

不过这个概念总感觉很久之前我就听说过，一查，果然是 C 语言的东西：

struct car {  char *make;  int height;};

C++ 则在 C 语言的基础上，加上了方法、继承、访问控制，直接变成了类：

struct Car {  std::string make;  int speed = 0;  void accelerate(int delta) {    speed += delta;  }};Car myCar;myCar.make = "Tesla";myCar.accelerate(30);std::cout << myCar.speed;

说回 Go 吧！

一个 struct 的字段可以是另一个 struct 类型，也就是套娃、嵌套：

type Wheel struct {Radius intMaterial string}type car struct {Make stringModel stringHeight intWidth intFrontWheel WheelBackWheel Wheel}

用法也是用点点一层层往下钻：

myCar := car{}myCar.FrontWheel.Radius = 5  // 先取 FrontWheel，再取它的 Radiusfmt.Println(myCa.FrontWheel.Material)  // 尴尬了，还没有赋值呢，所以是返回空的字符串myCar.BackWheel = Wheel{Radius: 5, Material: "rubber"}  // 也可以整块赋值

JavaScript 里的 config.server.port、Python 的 obj.attr.nested 都是这样的。好学。

Go 嵌套后，复制是递归的，所以 car 被复制后，里面的两个 Wheel 也会整个跟着被复制：

a := car{FrontWheel: Wheel{Radius: 5}}b := a  // 深拷贝b.FrontWheel.Radius = 99fmt.Println(a.FrontWheel.Radius)  // 5

这点倒是和 Python 还有 TypeScript 不同。它们对象嵌套时内层是共享引用，所以 b=a 后再改 b.front_wheel.radius 的话会影响到 a。

但是 Go 的 struct 是值语义，所以就不用学 copy.deepcopy 的坑。想要共享的话就乖乖显式用指针字段，或者传 &myCar 吧。

频道主还说过，Python 用字段的地方换成 Go 可以无脑用 struct 写。

Go 有匿名 struct，即在定义类型的同时直接造出一个值，这样类型本身就不用再留个名字了：

myCar := struct {Make stringModel string}{Make: "tesla",Model: "model 3",}

第一对花括号是类型定义，第二对是值。这种写法是一次性的。

我们还能这么写：

type car struct {Make stringModel stringHeight intWidth intWheel struct {Radius intMaterial string}}

不过这意味着 Wheel 这个类型在别处是无法被复用的。

TypeScript 里这种写法蛮常见的：

const myCar: { make: string; model: string } = {  make: "tesla",  model: "model 3"}

在 Go 实战中，匿名 struct 最常见的家是 handler 里的 JSON：

func getUserHandler(w http.ResponseWriter, r *http.Request) {err := json.NewEncoder(w).Encode(struct {ID int `json:"id"`Name string `json:"name"`}{ID: 42,Name: "Tom",})}

这样写的好处是，数据的形状和它的唯一用处在同一屏代码里，读者不需要跳转到别处的类型定义。

它也可以让后来的开发者没法偷懒引用它。如果哪天真的需要第二次使用，那你就显式起名吧，然后认真考虑它该叫什么、放哪个包里面。

一次性的东西就该长着一次性的样子！

Go 虽然没有继承，但会用嵌入替代它：

type truck struct {car  // 只写了类型，没有写字段名bedSize int}

嵌入的规则很简单，那就是只写类型。

普通嵌套写完后，消费它要用点点一层层钻，如 myCar.FrontWheel.Radius 对吧？

但是嵌入的字段会被提升到顶层，我们就可以这样写 lanesTruck.make，不需要再写 lanesTruck.car.make。

lanesTruck := truck{bedSize: 10,car: car{make: "toyota",model: "camry",},}fmt.Println(lanesTruck.bedSize)fmt.Println(lanesTruck.make)fmt.Println(lanesTruck.model)

在效果上，truck 看上去继承了 car 的所有字段，但在内存上它和普通嵌套完全一样，所谓的「提升」仅仅只是访问上的语法糖啦。编译器看到 lanesTruck.make，发现 truck 自己没有，就自动转译成 lanesTruck.car.make。

因为只是访问上的语法糖，所以在构造时必须老老实实写上 car: car{ ... }。

不只是字段可以被提升，方法也可以：

type car struct {make stringmodel string}func (c car) describe() string {return c.make + " " + c.model}type truck struct {carbedSize int}lanesTruck := truck{car: car{make: "toyota", model: "camry"}, bedSize: 10}fmt.Println(lanesTruck.describe())

明明 truck 没有写 describe() 方法，但就是可以直接调用它。

在 Go 里，给一个类型定义方法，会用 func (接收者) 名字 () 的形式挂在外面。

(c car) 的部分叫作 receiver，意思是「这个方法属于 car 类型，方法内部用 c 指代调用它的那个 car」。之后任何 car 值都能调用啦。

我们从头到尾都不用写 func (t truck) describe()，但依然可以正常运行 lanesTruck.describe()。truck 完全不需要付出任何代码，就能获得 describe() 的使用权。

原理也很简单，就是刚才说的「提升到顶层」：编译器发现 truck 自己没有 describe()，于是去查它嵌入的类型 car 有没有⸺嘿！还真有，那就给你转译成 lanesTruck.car.describe() 好啦。

Python 的继承可以实现同样的效果。不过 Go 的不是继承。对于 Python，父类代码和子类是互相知晓的。

但对于 Go，describe() 的接收者 c 永远只是一份 car。它不知道，也无法知道自己是被装在 truck 里的。

视频的 1:34:40 左右开始讲第六章节 interface。

回一趟父母家：更好的搜索、困难模式、野生动物

2026-09-12T16:45:00.000Z

我最近有点疲倦，表现为难以聚集精力去思考、想事情、读书。我想把所有该读的东西都塞给摘要生成器，然后帮我吐出来解决方案、要点…… 这么做不过也只是在伤害自己和他人。

八月份过后，我的牛劲儿莫名其妙不见了。《做导游的那几天》小系列不是特别想继续更新下去，因为它们全部都是图片…… 我本来计划在八月底写完星期四的部分，但那天我一共拍了八十多张照片，涵盖了华盛顿特区的博物馆还有动物园。放照片、随便写写备注还有感想，是件无比简单但特别繁琐的事情。所以我暂且搁置了。

和父母还有亲戚出门，明明去的都是好玩的地方，但晚上却难以想到写什么好。我只不过是将图片都丢到博客上。它们也多数不好看，只是走马观花。但和室友出门的话，可能只是走路，我都能一写一大堆。

还是得看跟谁出门。唉。

总之我不想要写作文、类似于论文的文章了。暂且地。我的大脑和思考能力不够我去写它们。我要回归大脑喷泻模式，想到什么写什么，读者朋友也是读到什么吃什么。嚯嚯嚯……

给博客做 embedding 然后就能更好搜索了

我最近安装了 Wiwi 的 blog-embedding 程序。还蛮有趣的，用模型给每篇文章都生成 embedding，然后输入文字就能快速查找到最相关的文章。

不过因为我的博客项目非常混乱，所以我对他的源代码稍作修改了下：改成从读 Markdown 文件到读 HTML 文件。

我的博客项目有多混乱呢？它包含以下三种源件：

过去 Hexo 项目里丢失了源 Markdown 文件导致我只能下载已经部署了的 HTML 文件
在使用 Emacs 之前写的 Markdown 文件
使用 Emacs 之后写的 Org Mode 文件，它会再被转换成 Hexo 框架里的 Markdown 文件

听着就觉得绕！

因为文件被放得到处都是，我也很难像梁某银那样做个程序、直接搜索源文字。

总之我决定让 Wiwi 的代码读渲染好的 HTML 文件。

然后因为《想法迭代》系列里面有很多很多小节，所以我又让程序去给每个小节做 embedding。

又因为我的笔记本电脑跑的是超级垃圾的 MTX 230，单靠 CPU 根本跑不动 Wiwi 默认设置的 8B 模型，所以我改用 0.6B 模型。

结果如下：

➜  blog-embedding  .venv/bin/python3 blog_search.py已載入 1105 篇文章的 embeddings請輸入搜尋文字（連按兩次 Enter 結束）：走路正在產生 embedding（模型：qwen3-embedding:0.6b）...🔍 與輸入文字最相關的 30 篇：    1. 0.4550  █████████████  初次走半马  (/posts/53f4.html)    2. 0.4397  █████████████  我开始有健康的生活习惯了  (/posts/f118.html)    3. 0.4310  ████████████  想法在乙巳开冬迭代 › 日记 › 妹妹的游泳比赛  (/posts/ea48.html#妹妹的游泳比赛)    4. 0.4287  ████████████  乙巳想法复盘 › 40. 能够总结你这一年的一句话是什么？  (/posts/f77.html#40-能够总结你这一年的一句话是什么)    5. 0.4253  ████████████  数多年重试跑步然后晕倒  (/posts/2814.html)    6. 0.4233  ████████████  乙巳想法复盘 › 36. 哪个政治问题最令你有感而发？  (/posts/f77.html#36-哪个政治问题最令你有感而发)    7. 0.4195  ████████████  乙巳想法复盘 › 18. 与去年的这个时候相比，你是：感到更快乐还是更悲伤了？变得更瘦还是更胖了？变得更富还是更穷了？  (/posts/f77.html#18-与去年的这个时候相比你是感到更快乐还是更悲伤了变得更瘦还是更胖了变得更富还是更穷了)    8. 0.4114  ████████████  乙巳想法复盘 › 20. 你希望自己能做得更少的是什么？  (/posts/f77.html#20-你希望自己能做得更少的是什么)    9. 0.4109  ████████████  学术评估测验 - 总结  (/posts/3b.html)   10. 0.4037  ████████████  乙巳想法复盘 › 11. 你今年是否生过病或受过伤？  (/posts/f77.html#11-你今年是否生过病或受过伤)   11. 0.3998  ███████████  乙巳想法复盘 › 7. 今年的哪个或哪些日子会铭刻在你的记忆中，为什么？  (/posts/f77.html#7-今年的哪个或哪些日子会铭刻在你的记忆中为什么)   12. 0.3979  ███████████  想法在乙巳纸月迭代 › 生活与文娱 › 日记片段  (/posts/31df.html#日记片段)   13. 0.3846  ███████████  想法在乙巳开冬迭代 › 日记 › 演讲  (/posts/ea48.html#演讲)   14. 0.3840  ███████████  做导游的这几天：星期三  (/posts/62c8.html)   15. 0.3822  ███████████  想法在乙巳开冬迭代  (/posts/ea48.html)   16. 0.3822  ███████████  乙巳想法复盘 › 29. 有什么是你想要且得到了的？  (/posts/f77.html#29-有什么是你想要且得到了的)   17. 0.3821  ███████████  想法在丙午岁始迭代 › 心理与关系 › 《在咖啡馆独处的不能承受之乐》  (/posts/c089.html#在咖啡馆独处的不能承受之乐)   18. 0.3805  ███████████  想法在丙午蚕月迭代 › 技术与创造 › 《好的软件懂得适可而止》  (/posts/a4c0.html#好的软件懂得适可而止)   19. 0.3803  ███████████  想法在丙午麦序迭代 › 日记片段 › 穿衣搭配  (/posts/5586.html#穿衣搭配)   20. 0.3771  ███████████  离开纽约市的一天  (/posts/18b0.html)   21. 0.3738  ███████████  想法在乙巳纸月迭代 › 商业与社会 › 《孩子们在哪里玩耍？》  (/posts/31df.html#孩子们在哪里玩耍)   22. 0.3735  ███████████  乙巳想法复盘 › 30. 有什么是你想要却没有得到的？  (/posts/f77.html#30-有什么是你想要却没有得到的)   23. 0.3712  ███████████  想法在丙午阳中迭代 › 技术与创造 › 《写给恐慌者的 Git rebase 指南》  (/posts/e3b9.html#写给恐慌者的-git-rebase-指南)   24. 0.3693  ███████████  想法在丙午岁始迭代 › 技术与创造 › 《我在地铁上编程》  (/posts/c089.html#我在地铁上编程)   25. 0.3679  ███████████  休息日逛下城  (/posts/ed86.html)   26. 0.3637  ██████████  乙巳想法复盘 › 15. 你大部分的钱都花到哪里去了？  (/posts/f77.html#15-你大部分的钱都花到哪里去了)   27. 0.3626  ██████████  想法在乙巳开冬迭代 › 日记 › 中秋游行  (/posts/ea48.html#中秋游行)   28. 0.3624  ██████████  想法在丙午芒种迭代  (/posts/893f.html)   29. 0.3620  ██████████  想法在乙巳开冬迭代 › 日记 › 新鼠标  (/posts/ea48.html#新鼠标)   30. 0.3597  ██████████  4 个字符为一组构成的城市  (/posts/cf35.html)────────────────────────────────────────────────────────────

其实 0.6B 模型的结果也能给出不错的结果，只能说不够精确吧。

比如搜索「在非平常场合写代码」就不会出现「想法在丙午岁始迭代 › 技术与创造 › 《我在地铁上编程》」这个结果，而是先出现「想法在丙午瓜秋迭代 › 周遭 › 《无干扰即是干扰》」。

另一个方法就是 Spike 的搜索，直接在 Kagi 或者 DuckDuckGo 上面搜 site:blog.cytrogen.icu 关键词。不过这样搜「走路」的话搜不到《初次走半马》，因为文章中没有提及到「走路」。

不带手机出去溜个弯儿呗

印象里 Spike 分享过这样的文章，提倡大家不带手机出去散步。Spike 也这么做了。但我完全找不到那篇文章了！就算搜索「不带手机」也找不到。

唉总之这是个我一直想要尝试的事情。我也和室友提倡过，曼哈顿太无聊了，要不我们把生活变成困难模式好了⸺这个「困难模式」我也记得有个英文博客站主写了篇相关的文章，讲的就是他小时候没有太多娱乐方式，所以和小伙伴们商量给游戏添加更多负担，也就是「困难模式」。

比方说我最近在 BiliBili 总是看到的《植物大战僵尸》能否用零个植物或者一个植物通关每个关卡？不过这个系列视频讲的都是 TAS 啦，更倾向于游戏漏洞挖掘，而没有观众们想要看到的愁眉苦脸、绞尽脑汁⸺频道主还因此经常被人留言「这样做有意义吗？反正真人打不出来」。

我和室友提倡的「困难模式」，就是选一天休息日，让自己不能做什么，比如全天不能携带手机。她觉得完全没有关系，因为她是那种手机丢了几个小时都不会发觉，然后凌晨四点才发现手机不见了、拉着我跟着定位去找的家伙儿。

我倒是会担心这个担心那个，比如说我会担心自己手机没有带在身上的话，母亲可能会打电话过来，然后以为我失踪了，就开始疯狂摇人来找，甚至报警…… 或者说生产环境出了问题，客户疯狂给我轰炸邮件……

我也担忧自己要是想要拍照片、找定位怎么办。但细想这才是 off-grid 生活⸺「离网」的意思，不过定义里并不单指「离开互联网」，而是离开一个或多个基础设施，例如电网、自来水⸺的意义吧。拍照片不行可以用我在 Target 购买的五美元超便宜小相机；找地方可以靠骚扰当地居民，或者去景点找张纸质地图，甚至买本纽约市地图书⸺反正办法总比问题多！

室友非常喜欢户外，因为她出生在大城市，目前人生的五分之一时间也都是在大城市里待着。她喜欢有空没空就去爬山、探索美国的郊区。她说她想要跟我去外州的小木屋住几天玩，每天就找柴火然后烧松果。不过她不会开车，我也没有那么多钱去租车。

她就发挥想象力，说要不咱们走过去吧，走个三天两夜啥的，晚上要睡觉了就去路边的汽车旅店。

我寻思我们都要去小木屋了，你还要走过去、一路上住汽车旅店。指不定得烧多少钱呢！另一点是汽车旅店让我觉得陌生，也让我很害怕…… 因为我看过的许多美国恐怖游戏都在汽车旅店里发生，尤其是非常惊悚的兔头杀手！

好吧我最害怕的是花钱。我没有钱。

室友说那能不能随地扎营咧？我俩背个大包，天黑了就找个草地露营睡觉。

我说那得多沉啊！你背我背？你肌肉这么壮硕、力气这么大，肯定是你背吧！我可是 BMI 过轻、扁平足、胆固醇超标的弱女子一位呀~

室友说那就换成睡袋嘛。随地大小睡。

我接着说早上起来就喝叶子上的露水、啃叶子，融入大自然变成野人。走到休息站就上厕所、喝厕所的自来水，然后去麦当劳啥的地方给手机充电、联网给别人报平安表明自己还活着。

说完我自己也绷不住笑，跟着室友哈哈大笑起来。哈哈哈哈！我是喝露水的野人！我要长满大胡子然后在森林里一边叫一边拿着藤蔓荡来荡去呀！

传下去，Cytrogen 其实是个神经病。

好啦，生活总是要有点乐趣的。就像现在写博客的我，坐在父母家里，身边有睡着的幸运狗和咪咪猫，但老觉得没劲儿。

父母家位于纽约市已经被遗忘的区⸺斯塔滕岛（Staten Island）。它的存在感低到没边儿。我估计没来过纽约的读者朋友们都知道曼哈顿（Manhattan）、布鲁克林（Brooklyn）、皇后区（Queens），还有布朗克斯（Bronx），但就是不知道这个斯塔滕岛；明明它们五个是同辈儿的兄弟姐妹。

这个区和剩余四个兄弟姐妹有多么不同呢？它是唯一一个持有保守立场的区。就凭这一点，它就很不像「纽约市」。

它的城市化相当于没有。除了最中央的商场外，其他地方都是清一色的森林、小山、城镇。你看不到一栋高楼大厦。

虽然我很不喜欢父母，但不得不承认父母家非常安静。没有大城市的噪音，晚上真的很安静很安静，除了破知了和蛐蛐的尖叫声，还有野猫发情或者打架的声音。

所以说，父母家真的超级无聊，就算是最近的图书馆都要走个半小时。

不过从城市过来住个一天一夜，便会觉得离下网也没什么。

于是我早上起来不带手机，带着幸运狗出门。

它非常喜欢出门。就算不是散步，它也会自觉跳到父母的车上，然后找个位置优雅地躺下。也是，家里太无聊了。就算是我这个宅宅也会想要坐上脚踏车然后远走高飞。

因此，幸运狗刚出门的那小段时间，它会非常兴奋地尝试窜来窜去，并走在我前面。我只能想方设法缩短绳子，把它固定在我身边。

走个十分钟左右后，它的兴奋劲儿就没了，便也慢慢地跟着我走。狗的舌头真的很有意思，能像块破布一样耷拉在牙上。

父母家附近有个湖泊，所以靠近那儿就会看到比两个我还要高的芦苇，以及泥巴地。那附近有许多鸭子，总是随地拉屎，然后占着马路不走。小轿车要么等，要么等急了按下喇叭催鸭子快走。那时候鸭子才会一只跟着一只、排队般地过马路。

有时候还能见到火鸡或者鹿。我印象里刚搬过来的时候，家附近总是有三只火鸡⸺一只公的两只母的⸺来拜访。现在反倒见不着了。鹿的话，它往往站在远处吃草，然后抬头看着我。偶尔它会出现在森林旁的马路，然后因为小轿车而逃跑。

晚上开车回家，有时能在马路上看到负鼠。成年的母负鼠会驮着一堆小负鼠、躲在车子底下。它们的寿命居然只有两年多。实在是难以想象。

父母家附近养狗的人家也很多。就算是在自己家，它们也会汪汪叫吵架。我路过一家养吉娃娃的，它们从楼上跑到前院围栏然后冲着幸运狗尖叫。主人是个光头，赶紧跑来跟我说「你快走！」我便带着幸运狗快步离开。幸运狗像是已经习惯了，也不看那批吉娃娃。

回家后感觉不带手机的最大难受点是我不能立即记录当下的感想。

野猫泛滥

野猫泛滥是父母家周边的一大问题。我不知道是谁起头的，开始给家附近的野猫喂饭。后来街坊邻居都一一效仿，给野猫搭建小屋子、放水碗和饭碗。

现在母亲半夜出去遛狗，都能看到每户人家门口都站着只野猫。「像是人那样，在开会！」她惊道。

这究竟是个「问题」么？其实我也说不清。我过去认为不该喂养野猫，因为它们会不停繁殖、生出更多小猫。而因为这附近是户外，所以虫子还有疾病会找上它们。

再是在街上放置食物，会引来除了野猫外的动物，比如更具杀伤力的狂犬病毒传播大头⸺浣熊。父母家曾就被浣熊入侵过后院。它们住在隔壁的废墟里，把原本的野猫住民赶了出去，然后把周围人家的植物都咬得一团乱！

我最担心的还是狂犬病毒。美国管狗管得很严。我来美国后从来没有见过流浪狗。收容所里的狗也都会被打上一针狂犬疫苗。美国传播狂犬病毒的往往不是狗，而是野生的浣熊、狐狸、蝙蝠。

所以看到浣熊提包入住父母家隔壁，搞得我很慌……

说回野猫。我总是觉得对野猫最负责任的做法是领养它们。但是想到罗小黑的原型⸺一只因为频繁想要逃出人类的家，最终被绝育然后放归大自然的黑猫⸺我开始思考将猫带回家养是否真的能够解决所有的问题？就像罗小黑的原型，会频繁尝试逃离，那是不是将其放回大自然才是对它最好的？也是对看管它的人类来说最好的？

我过去也说不能给野猫喂饭，可是母亲听后说：「那我也不能看着它们饿死啊。」

我们没有经济能力能给每个猫都做绝育手术、对它们负责，因为在美国养宠物真的好贵。做绝育手术要千来美元的诊所是常态，便宜的诊所还要预约抢位置。室友的匹克猫单是洗牙就要两千美元。

反而喂饭成了最便宜还能保障它们活下去的手段。

说到这里，我也说不上来怎么办才好。我去过许多动物收容所，有几家大的收容所里，动物多到要用笼子堆在一起。领养的速度远远不如人们捡到动物的速度快，更别提还有卖品种动物的产业会夺走想要养宠物的人。

我能做的只有未来想要宠物的时候，就去收容所里领养。

RE：覺得訂閱制軟體很貴，大概是你太窮，不懂商業邏輯

2026-09-10T05:02:00.000Z

讨厌订阅制软件的人一定是很穷的巨婴吧！⸺这是吸引读者注意力用的钩子。

原文链接： https://ivonblog.com/posts/too-poor-for-business-logic/

表象

对文章作回应，实则是在对我认为它所表达的意象作回应。

该文章呈现了这样的立场：抱怨订阅贵、抱怨 DRM、抱怨隐私收集的人是因为穷、思维跟不上主流，才抱怨的。

商业逻辑就是利润最大化，而这是不可违逆的。用户要么适应它，要么就提升提升经济地位吧！也就是「找个班上」。

拦截广告是偷窃。用户不花钱去除广告相当于让创作者没饭吃。

抗议者全都是提不出替代方案的巨婴。

不过因为「我」很穷，所以我还是要用广告拦截工具。

根据我对作者的了解，Ivon 是自由软件的支持且拥护者。怎么会突然写这样的文章呢？我重新阅读了下，理解为是他在反讽。

总之我都是要对文章中表现出的所有立场做出回应的，何不先从这「表象」开始？它也是我们在日常生活中常常听到的。

订阅疲劳已经是结构性现象。存款多亦或者是少，都有人在抱怨它。我们订阅了一大堆服务，然后还要订阅 Rocket Money 去帮我们管理订阅⸺是的，如果不订阅 Rocket Money 的话，我都不知道我在订阅某某服务！我的钱已经多到我不愿意查看银行账户了⸺这是反讽。我本人没有钱。

就算是有广告档的 Netflix，最近也一直在涨价⸺虽然我的 Netflix 广告档是 T-Mobile 包的⸺Amazon Prime Video 也在 2024 年开始突然把广告加到会员档里，然后要求额外订阅「去广告费」。

更不要提影院这种地方，开播时间到了后还要看半小时广告。好在它们多是其他电影的预告片，还能忍受。不过要是早点入场的话，就要看专门为大荧幕设计的超大广告了。

所以就算是有在花钱订阅服务的人，也要忍受可恶的广告。

这一切都源于「企业必然追求利润最大化」这句话。

是，不错，企业一定会想要最大化自己的利润。但这不是真理。企业选择了去搞订阅制、DRM、植入广告、收集用户的数据，而它们都有替代方案。

消费者能够通过抗议还有商议，来阻止企业剥削他们，并要求企业提供更好的服务。因此才能有「哪家公司更良心」的比较。

如果「企业追求利润最大化」是真理，那「良心」这种比较根本不可能诞生。可是我们每天都能听到别人说某某公司好良心、某某公司没良心⸺为什么这时候又要强调企业追求利润最大化是真理、是可以谅解的？

2023 年 Unity 推出要按安装量收费的政策。开发者社区的激烈反抗使得该政策被撤回。提出这种蠢蛋政策的人也被开除，真是活该。

Ubisoft 下架 The Crew 之后，导致买断游戏的玩家无法游玩。Stop Killing Games 组织收集了 129 万个验证签名，并使得欧盟委员会决定采取行动。

「财报优先于公道」可见在现实并非真理。退出还有发声是对企业的纪律。用户们只要团结、愿意声讨企业，企业就会因此做出改变。

已知我们往往要在软件里选择「付费」，或者「看广告」⸺撇开先前提到的付费看广告。对于前者，如果定价超出了相当大一部分人的支付能力，那么他们就要被迫选择后者的注意力税。除了这两个「极端」外，我们的另一个选项就是走非法出口，包括盗版。

这是消费者在道德上的失败吗？我不这么见得。我看盗版的一大原因是我无法支付很多东西，例如必须要买 BiliBili 大会员才能看的正版汉化动画，而我身在北美地区、无法观看。结果我只能去看盗版的汉化资源。

如果我购买的 BiliBili 大会员能够让我正常观看动画，我自然会选择花钱省事，毕竟找稳定的盗版资源不是件轻松事儿。

企业惩罚愿意付钱的人，最终只会把他们推向灰色的地带⸺关于这点，后面会再提一次。

不谈钱的话，订阅制让人们厌恶的另一个原因便和所有权相关。我们不再能购买一个东西了，反而是仅能租用它们的使用权。

说来，我其实买过 Microsoft Office 2019 的全套学生软件，也依然可以正常使用。这种买断制对用户是可行的，只可惜订阅的现金流更符合企业的审美。

最后是「有没有替代方案」。Doctorow 在他的网站中经常提到他的方案，也就是强制让软件间有互操作性、修订反 DRM 条款、反垄断、反欺诈性设计模式、使用订阅外的资助模式，比如赞助、买断、合作社等等。

Stop Killing Games 也将自己的诉求写成了可执行的立法议程。

权威

表象中有着隐含的前提，即公司的决策是被给定的、不可谈判的事实，而消费者的行为才是需要被审判的。

因此，在这类逻辑下，订阅涨价属于企业的合理生存策略、广告与数据收集也是用户已默许的交易条件。

百年前的劳资谈判里，如果有人说「乘客抱怨票价太高、服务太差，是因为他们太穷、思维落后。抗议者是提不出替代方案的巨婴。而铁路公司的涨价是商业逻辑的必然」，那他会被当成是工贼然后乱棒打死。可为什么现在不再是这样了呢？

企业成为了立法者，消费者却成了乞讨的。明明消费者的抱怨、流失、使用广告拦截、推动监管都是市场交易中谈判的一部分，而且是最正当的一部分⸺消费者可不会像企业那样，使用欺诈性设计模式啊。凭什么觉得消费者的反抗手段是不合规的巨婴式哭闹？非常欺负人啊。

系统正当化会让越是处于不利地位的人，越倾向于为支配自己的系统辩护，因为承认系统在欺负自己、在情绪上更难接受。

1994 年 John T. Jost 还有 Mahzarin Banaji 提出了该理论。当时 Jost 认为，人同时持有三种不同的正当化动机：

自我正当化
群体正当化
系统正当化

前两个动机还能理解，不过第三个在低位群体身上是冲突的。因为为损害自己以及自己的群体的系统说好话，不就背叛了自我还有群体吗？它应有独立的动机来解释才对。

理论主张，系统正当化会提供心理上的回报，或者说，麻醉剂：大体公平的世界总要比随机不义的世界好理解；不义的系统意味着我的处境由他人造成，且随时可能更糟，但有义的系统下我的处境就是应得且可预测的；与他人共享现实，维持群体上的认同。

当人们将订阅制自然化成商业逻辑的必然，那么就会把其他人的不满当成是他们个人经济实力不行，因为这意味着世界有商业逻辑这个铁律（好理解）、买不起是可计算的结果（可预测），以及自己成为了懂商业逻辑的少数清醒的人（群体上的认同）。

一旦将结构性问题个人化，也就是降低了问题的维度，可选答案就只剩下「付钱」跟「不付钱」了。明明是制度设计的问题，最终争论的却是受害者的钱包里有没有钱。

换到其他方面的问题，这样的思考方式也很有问题，例如结构性失业其实是你不够努力、结构性成功其实是你的道德成就。最终，成功者都认为自己的一切成功都是自己挣得的；富人认为自己配得上自己的财富；穷人这么穷都是不够努力、活该穷三辈。

商业成功真的等同于道德上的正确么？实际上一般人都在崇拜的 Musk、Zuckerberg，不过都是不把人当人、能够随意剥削他人的家伙儿罢了。在一个人意外取得成功后，他就会稀里糊涂成为聪明的、生活习惯好的、成功来源于努力的人，甚至出一堆复读成功学鸡汤的自传，引得媒体和信徒狂欢。

人民的不满应当要归因于结构，然后引起集体行为、改变现有的制度。归因于个人，只会让个人去疯狂改进自我，或者自我安慰，最终没能改变结构，也往往只留下「无可奈何」。

个人化的政治功能就在于此。只要每个消费者都各自内化了损失，那么损失就永远不会加成总和，也不会影响到企业和政府。

一旦没有人为结构负责，结构就会被自然化、默认为自然背景，就像是天气。事实真是如此吗？意识形态、政治、商业逻辑，真能和天气、物理定律划为一谈？实则是它们被免于讨论、免去了责任。

不过个人的选择依然能改变结构。使用广告拦截、购买买断制的产品、参与活动还有签名，可以社会化和结构化无数个个体选择，从而影响我们认为是自然规律的结构。

为此，我们要多发声。

讽刺

实话实说，Ivon 的讽刺做得很差，因为写得非常像是真话，以至于我第一次阅读时误以为这是他的内心真实写照，还在想「这家伙儿怎么变成这样啦！」

文中写的各种「夸张」的言论，非常荒诞地，实际在互联网上被无数人真心实意地说着。讽刺对象本身已经足够荒谬了，再去看这篇文，反而觉得真实、一点都不夸张。各种层面上都让我深觉惋惜。

另一点是转折点很弱，扫过去会看不到它…… 结尾也停留在了向企业认输、无奈地自嘲，即承认自己穷，所以要挡广告，相当于承认了表象的观点。

其实可以直接参考「吃婴儿来解决贫困」的建议啦。

嗯好吧，话也不能说这么满。万一对方确实没有打算讽刺的话，那我怎么办？

版权

我近期一直在思考自由与商业的关系，源于我从 Cory Doctorow 的文章中读出的该观点：

自 1976 年的版权法以来，国会一直在反复扩大版权，但结果是老板们变得更富有了，而真正在干活的创意工作者比以往都要穷。为什么会这样？答案是版权扩张实际上对工人是无效的，却对媒体公司很有效，因为他们会因此拿到许可费。

我原先对 Doctorow 的观点理解成反对版权、要废除版权的。但我想到假设我们在没有版权的世界，创作者要如何收益？这是否意味着大盗版时代？

不过之后在阅读他的其他文章⸺要这样翻来翻去才能凑齐他的具体观点是什么样，还是蛮有趣的⸺我发现他关于版权其实是这样想的。

此处其实有两个不同的问题，后文会分别回答：一是版权的「多少」⸺更多的版权能不能保护创作者、挡住盗版？二是版权的「有无」⸺干脆废除它行不行？

他写的书 Chokepoint Capitalism（暂且翻译成《瓶颈资本主义》）里提到：

Because copyright can help artists — if there are lots of buyers for your creative labor, you can play them off against each other and get a better deal for yourself (we spend a lot of time talking about how finally applying antitrust to the tech and entertainment giants would help artists).
But if there's only a handful of colluding buyers for your work — if there's a chokepoint that's patrolled by powerful bullies — copyright won't help you.
因为版权可以帮助艺术家⸺如果你的创意劳动有很多买家，你就可以让他们互相竞争，从而为自己争取到更好的待遇（我们花了很多时间讨论，如果最终对科技和娱乐巨头实施反垄断法，将如何帮助艺术家）。
但如果你的作品只有少数几个串通一气的买家⸺如果存在一个由强权恶霸把守的瓶颈⸺版权也帮不了你。

他其实是肯定版权本身的价值的，但问题在于市场结构恶意利用了版权、反而让本该被保护的创作者吃不上饭。

创作者们一直以为能保护自己的是引入更多的版权，但它们不会随着数量而增强对创作者的保护，而是相反。

他们向损害自己的结构所要更多保护，怎么可能会得到保护呢？版权越多，个体创作者面对中间人⸺如唱片公司、平台、出版社⸺时的议价力反而越弱。怎么会有这样的道理？因为新的权利在实际操作中只会被买方收走、写进合同，然后拿来对付创作者而已。

此处假设的是，如果没有版权，盗版就会铺天盖地地袭来。但因果方向其实是反过来的：盗版的能力来源于数字复制的技术，而非没有相关的法律。

自 1999 年的 Napster 以来，数字复制的边际成本一直都趋近于零。任何 DRM 都会被破解，而这样的盗版时代已经在有版权的世界里持续存在了二十多年。

DRM 的功能其实从来都不是防侵权⸺侵权者又不在乎违法⸺而是防竞争。它让合法购买的东西只能在被批准的设备上用，从而锁定用户。

因此我们必须要承认一件事：更多的版权无法阻止盗版。

注意，我说的是「更多版权」，不是版权本身。

在已知复制无法被技术阻止的前提下，法律和商业还能做什么来保证创作者吃得上饭呢？我们需要明确理解版权的真实功能，也就是界定合法渠道的排他性，从而让合法渠道能定价、创作者能授权收费。

欧盟委员会 2015 年委托了 Ecorys 做了覆盖三万名受访者的研究，却发现在盗版对销售的替代率上，唯一得到稳健结果的是新上映的大片，替代率有 40%，也就是说每 10 次非法观看会减少 4 次合法的消费。

至于在音乐、图书、游戏领域上，替代系数则很不确定，甚至有些非法活动能促进合法的消费流。

所以粉丝个人的复制对大盘的伤害远远小于行业所宣传的。打个比方，盗版玩家可能转化成正版玩家、听盗版音乐的人可能成为歌手的粉丝而在未来为演唱会消费…… 没有版权不意味着一定会立刻摧毁创作收入。

尽管 Spotify 是个糟糕的流媒体软件，也有着糟糕的订阅制还有 AI 乐队，但它的创始人 Daniel Ek 曾说过：

"I realised that you can never legislate away from piracy," he says. "Laws can definitely help, but it doesn't take away the problem. The only way to solve the problem was to create a service that was better than piracy and at the same time compensates the music industry – that gave us Spotify."
「我意识到你永远无法通过立法根除盗版，」他说。「法律确实有帮助，但并不能消除问题。唯一的解决办法是创建一个比盗版更好的服务，同时补偿音乐产业⸺这就是我们创立 Spotify 的原因。」

不得不承认的是 Spotify 的模式确实带来了全球录音音乐连续十几年的增长。订阅制让人们能够用每个月更少的钱去听到更多的音乐。而该做法的重点并不在于靠 DRM 和诉讼来对抗盗版用户。只有合法渠道变得便利，用户才会持续消费。

既然更多的版权阻止不了盗版、版权的存在也挡不住粉丝的复制，那我们能不能干脆废除它，让翻印也合法化呢⸺也不行。

先前说了，它的作用是「界定合法渠道的排他性，从而让合法渠道能定价、创作者能授权收费」。

「排他性」是什么？为什么界定合法渠道的排他性很重要？

在经济学里，一件商品能否收费，取决于它是否可排他，即提供者能否阻止不付费的人使用它。

而公共品的定义建立在非竞争性（我用不妨碍你用）和非排他性（一旦可得，就无法阻止任何人使用，无论他是否付过钱），这两条特征上。

数字作品天然就是非排他的，因为它的复制成本是零。任何人拿到一份拷贝，就能再造出无数份。而非排他性意味着市场供给会不足，因为如果没有人能阻止白拿，就没有人有理由付费，那么付费市场就会崩溃。

版权的法律内核正是一系列的排他性，即复制权、发行权、表演权、改编权等等，都是禁止他人做某事的权限。「谁有权做拷贝」会通过版权而被界定成可授权且可交易的法律地位。

借此，法律创造了信息品的可排他性，让信息品不再是公共品，也让收费成为了可能。

阻止了信息品变成公共品后，创作者所要担心的另一大问题便是如何阻止其他人合法贩卖自己的作品。这也得用到版权，即禁止除了有独家发行权以外的出版商或者平台销售。

有组织、有渠道、直接争夺付费客户的翻印商，截走的是正在发生的支付；粉丝复制截走的顶多是可能不会发生的支付。前者才是创作者最该担心的对象。

在 International Copyright Act of 1891 出来之前，美国的翻印市场全都是外国作家的作品。因为美国的版权法只对美国作家的作品有用。翻印「没有」版权的外国作家的作品，不就相当于不用付版权费嘛。因此，翻印商开始大肆无许可翻印，甚至搞起了价格战。

能压低价格的原因是成本降低。而在这个例子里，成本大头版权费已经消失⸺不，其实没有。外国作家可还在自己的国家里活着呢。他们的作品被美国企业翻印，却没法因此获利。成本问题被丢给了他们。

排他性的重要性就在此。它被用于阻挡美国翻印商这类有组织、有渠道、直接争夺付费客户的搭便车者。

但不好好使用它，它也会阻挡愿意付钱的用户。

比如 BiliBili 从版权方那儿购买了在中国大陆转售作品的权利，却直接阻止不在中国大陆、但希望观看汉化资源的我。

如果有其他企业也有转售该作品的权利的话，我就能去给他们掏钱⸺可是不行。没有任何一家企业购买了在北美发行汉化版本的权利。

温和的建议

最后我想要抖个机灵。嚯嚯嚯……

咳咳，嗯哼！⸺诸君或许以为本王在讽刺。恰恰相反！我正在认真规划着呢！首先每月收入要划出 47% 给订阅服务吧。没有办法呀，我连知道自己花了多少都要额外付费买注意力才行，所以这个数字是保守的，我还聪明地给未来留了增长空间呢！

其次要划个 12% 给去广告附加费吧。哎呀也没有办法啦，本王讨厌广告，不过现在去广告的费用也在一直涨价啊，谁叫创作者要吃饭呢。平台也是在教育我们财商。倒不如说那边那个正在翻白眼的家伙儿，其实是自己没有努力提升经济地位、看不懂他们的这番苦心吧！

未来要是订阅再涨价的话，本王会先砍掉音乐订阅，然后砍掉云存储，然后砍掉吃饭。这也是没有办法的。吃不起饭是本王的经济实力问题嘛，与涨价无关。

所以诸君面前的蛤肉汤其实是十年前的罐头这件事，就不要抱怨、给本王吃下去吧！等下本王同诸君还要用 Amazon Prime Video 看电影呢⸺完蛋！居然有地区限制！

顺带声明一下啊，本王无意建议什么，「平台自律」、「监管介入」、「互操作性立法」之类的天真方案啊⸺最近好像总听到诸君里的某些人在聊这个。真是不懂感恩！企业追求利润如同天体运行，正如雨落到穷人身上是因为他们站在外面；穷人买不起伞，说明他们本就不该出现在雨里；买不起伞又抱怨下雨的，先提升提升自己的气象学修养。所以本王奉劝诸君不要再搞这些有的没的了。多学学本王！

最后本王要免除一切怀疑：本王的领地没有订阅没有广告且开源免费，故在以上讨论中毫无私利，纯粹是出于对商业逻辑的敬意。

说到这里，本王真是感动，竟能见证如此完美的概念存在⸺做什么都是对的企业！可惜还是有点瑕疵，毕竟万一有天，没有人买得起东西了怎么办…… 不过那又和本王有什么关系？想必首富们都能聪明地想出对策吧。本王没有他们聪明，就不想这些了。

总之就是这样了，诸君同本王一起享用美味的罐头汤吧！⸺嗯？那边的那个，你在干什么……？！把武器放下！⸺呃啊……！！

⸺2026 年的一场秋天，Cytrogen，卒。

自己绘制的图片

2026-09-05T22:21:00.000Z

我受够了 AI 生成的图片。

虽然我不是专业的画师，但至少还是有画过画、有足够的鉴别力去观察画作的。

我对 AI 生成图片的领域了解不深，仅有在高中时用过一次 Stable Diffusion，之后就再也没有碰过图片生成了。

那时还被称作是「AI 元年」，一个设计电动滑板的熟人想要知道能否将 AI 引入到他的工作流中，我就浅尝了一下。结果设计出来的滑板很糟糕，我还被当时使用的 Kaggle 封禁了账号，理由是他们认为我上传了成人内容。

电动滑板…… 是…… 成人内容…… 好吧，也许 Kaggle 的审查人员认为电动滑板是色情的。对此虽然我无法理解，但也必须表达出尊重。

因为 AI 的火热，一时大家的社交媒体头像都变成了仿照吉卜力工作室画风的 AI 生成人头照。它们千篇一律，看得让我想起数年前 QQ 看点里大家把头像都换成猥琐的黄猿脸、名称改成「蒙奇 D 黄猿」。

后者的重心在于跟随潮流。同样的事情也发生在《原神》这款游戏上架之前、百度贴吧一度引起「大家都是派蒙」热潮。大家争着加入到虚拟的家族中，开着玩笑⸺其实我也加入过，并给自己画了张可爱的派蒙头像⸺可是前者的 AI 火热并非如此，因为人们真的认为那些图片是好看的。

这样子的画作就足够了吗？为什么要将自己的照片转换成所谓的「吉卜力风格」，然后用它顶替掉真人照片？说到底，就算真的要使用 AI 生成，也写个好点的 prompt、生成张更有个人特色的图片吧！每个风格都是一模一样、同样的劣质，说明人们的平均审美都是能看就行了吗？

为什么在使用图片时，就完全将决定权交给 AI、就算生成出逻辑漏洞百出的图片也要放到自己的网站上？

我们其实完全可以自己画啊。不会画画的，画出五十个火柴人，又如何呢？

至少我画的这五十个火柴人，出现在了我想要它们出现在的位置、有着我想要它们身上有的东西…… 但 AI 生成的图片，你又要消耗多少资源、修改 prompt 的次数，才能完美达到你想要的样子呢？

我并非要求人人都成为画师。随手生成的吉卜力头像无法向观察的人表达出任何东西，因为它对所有人生成的东西都是一样的。但是人们实际画出来的东西⸺不论学过绘画，还是没有⸺都能够表达出这个人当下的心境、绘画时花费的精力与时间……

如果只是将决定权交给 AI，等于放弃磨炼出能鉴别美的眼睛的机会。就算是画火柴人，也有许多因为热爱而画出张力的人在。

画得烂又如何？说到底，什么才是「烂」的画？是糟糕的画工吗？那儿童画与 Picasso 的比例、浮世绘的透视、中世纪绘画的光影…… 它们是糟糕的画吗？如果只有一个答案的话，那么艺术史就只该有一种大师。

既然「烂」无从定义，那么不如直接承认这个吧：所有艺术都是好的艺术。因为「好」存在于决定去做某件事的瞬间，而非成品内。

我不想要否认用心调 prompt 的人。可是那与绘画并不相同、属于两种截然不同的活动。本就不必争个高下。

至于用心调 prompt 算不算艺术，我很难说。生成的图片本身不是画⸺人与它之间，隔着真正在做决定的模型。但隔着机器做选择，有时像是摄影；有时又像是策展，尽管展出的内容依然是借别人的数据而生成出来的。

但我也不必现在就给出答案。无论它算不算艺术，它都与绘画不同。

我确定的是，我愤怒于随手生成平庸品还将其当作是自己的表达、敷衍了事。这不是艺术。它没有付出过任何决定。

以上是我看到 Eddie 的《出遊小狗勾》时想到的。之前在月刊内也提到过相关的话题。

Eddie 是为了不冒犯对 AI 图过敏的 ikuka 而亲手画的插图，而 ikuka 在自己的博客文章内也时常插入自己的插图。不过虽然 Eddie 自嘲自己画的图片是「好像没有比较好」的，但它其实很可爱，且是为了 ikuka 而画的，这非常宝贵且难得。

再看看 Hollie。她会在各种各样的地方掏出钢笔还有水彩写生，画咖啡、狗狗、食物、YouTube 频道主的脸。她只画让自己开心的艺术。每张画都在记录她的日常生活、替她见证自己的生活…… AI 生成的图片无法见证任何东西。它没有生活。

结尾放个突兀且莫名其妙的骑着猫的鸟。

想法在丙午中秋迭代

2026-09-02T17:16:00.000Z

虽然夏天期间没有发生什么大事⸺实际上经历了半个月的生病还有两周多的旅游⸺不过还是要和它说拜拜！我最喜欢的秋天到啦！夏天你不要跟我打电话了，我怕秋天误会。

本期导读

RE：The ordinariness of evil

2026-08-30T01:00:00.000Z

Cory Doctorow 写的，关于 AI 和平庸之恶的文章。

原文链接：https://pluralistic.net/2026/08/19/banaility/

标题的 The ordinariness of evil 可以被翻译为「平庸之恶」，来自 Hannah Arendt 形容 Nazi 战犯 Otto Adolf Eichmann 的概念。实际原文是 Banality of Evil，来源于 Eichmann in Jerusalem: A Report on the Banality of Evil 这本书。

看 Doctorow 这篇文章的 URL，会发现 slug 是 banaility，给 banality 这个词儿的中间加了个 i，藏了了 ai 进去⸺这很像 aigent！

该概念的意思是，恶不一定来自于坏人、恶魔，它往往来源于最平庸、无聊、仅是在服从规则的人。

文章的中心思想是，AI 不应该被视为是非凡、超自然、独特邪恶的力量，而应当被当作是普通、正常的技术来对待。

开头 Doctorow 批评道，AI 公司的老板会不断在公开场合渲染各种末日场景，诸如最早的 AI 觉醒统治世界奴役人类、毁灭人类，到现在的取代人类导致工作岗位一少再少、AI 失控骇入他人的服务器。

看上去好像他们在反思⸺当然不是了，他们怎么会反思呢？这不过又是个对 AI 技术的宣传和吹嘘罢了：因为 AI 技术非常可怕，所以它非常厉害，所以你要多多投钱进来啊！

可实际上，AI 技术真的很厉害么？

AI 技术并不万能

AI 目前真正有用的场景非常有限。就算是在编程领域，你也得本身就会编程、能分辨出 AI 输出的对错，并且谨慎地将 AI 当成辅助工具时，它才有用。

因为 Doctorow 非常喜欢在他的文章中插入他过去写的文章⸺鉴于他近乎每天都在更新同样质量的文章，他的插入能够更好地理解他说的话是什么意思⸺所以阅读他的文章感觉就是不停在转来转去。

为了更好展现出他的思考，我也会每个重要的点再讲讲他所引用的文章中说了什么。

比如刚才的观点，「AI 的有效使用完全依赖于鉴别力」，就使用了这篇文章：Discernment。

我觉得他每次的封面图都设计得很有趣，不知道是谁做的？Slug 里也有彩蛋可以挖掘：

主 slug 是 hitl-ers，里面的 HITL 是 Human-in-the-loop（人机回环）的缩写。我不清楚这是不是他的意思，但加上后面的 -er（指「XX 者」）就能拼成 hitler，也就是「希特勒」！
文章的锚点 #ai-ai-oh 是对儿童 Old MacDonald Had a Farm 中的歌词 E-I-E-I-O 的戏仿

说回这篇子链接的观点：LLM 的输出始终是包含着缺陷的，所以只有当用户具备足够的专业知识来识别并且忽略这些缺陷时，AI 才是有用的。

作为例子，他提到自己会使用本地聊天机器人来校对博客文章中的拼写错误。因为他已经写了 30 多本书、有 25 年的写作经验，所以他可以立刻判断哪些建议是好的、哪些建议是愚蠢的。

但如果让他看数学家 Terrence Tao 与 ChatGPT 关于 the Jacobian conjecture counterexample（雅可比猜想反例）的对话，虽然看起来很厉害，但他根本无法判断出这到底是真正的数学推理，还是看上去是数学的别的东西，因为他不懂啊，他缺乏相应的鉴别力⸺我也看不懂！

知道了这一点后，我们再去看那种所谓的 AI 学校，也就是没有老师，让学生们自己用 AI 工具学习的学校，根本蠢得要死。

学生根本不是所学科目的专家，他们来学习就是为了获取知识和鉴别力。而让没有鉴别力的人去依赖个始终会产生错误输出的工具来学习，逻辑上自相矛盾，实践中也极其危险。

不过 AI 工具依然可以辅助老师，只要这个老师能够作为专家、逐一去审核每道题目，确保其质量。

Doctorow 并不反感 AI 技术，之后会深入该观点。现在先谈谈我对在教育中的 AI 技术的看法。

因为并非所有老师都是专家，因其下限我并不看好这种事情⸺怎么会有教授在教些自己都不懂的东西，然后让学生们在写作业时自行去询问 AI 工具？

这篇文章中 Doctorow 的经历也让我意识到标签的重要性。当写的东西越多，要找一篇文章表达了特定的观点，会非常困难。标签可以帮助写作者⸺而我完全没有这个习惯！你会发现「想法迭代」系列近乎没有标签，我的博客主题也不会显示任何标签。

因为我近期也在辅导妹妹数学，时不时会给她布置作业，所以能够理解老师的苦处：我一个学生的作业都布置得想哭，更何况是管不知道多少个学生的老师？

但是在用 AI 生成作业外，我也会去互联网上搜罗我觉得有趣的题目，然后拿下来用。因为我熟知这些数学概念，我能够分辨出 AI 生成和互联网上搜刮来的结果里，哪些是可以用的，哪些是不能用的。

如果让妹妹使用 AI 工具来学习，她只会「感觉」自己学会了，实则没有⸺一个小孩子也不具备理解 AI 技术是不可靠的能力！

AI 技术更像是个插件，可能会帮到你，也可能对你没有一点用处。

它是普通的技术。

AI 的经济泡沫

但是 LLM 作为正常、普通、平凡的技术，不正常的地方在于它被投入了太多太多资源。

Doctorow 此处引用的文章，Billionaire solipsism, dictator solipsism, AI, and the fascist paradigm 讲的是 AI 为统治阶级的唯我论幻想提供了虚假的技术解，但并没有解释 LLM 技术究竟被投入了多少。

为此我去翻找了下他过去写的其他文章。

在 The real (economic) AI apocalypse is nigh 中，他将自己写的书 The Reverse Centaur's Guide to AI 的论点浓缩成了这段话：

……the AI bubble is driven by monopolists who've conquered their markets and have no more growth potential, who are desperate to convince investors that they can continue to grow by moving into some other sector, e.g. "pivot to video," crypto, blockchain, NFTs, AI, and now "super-intelligence." Further: the topline growth that AI companies are selling comes from replacing most workers with AI, and re-tasking the surviving workers as AI babysitters ("humans in the loop"), which won't work. Finally: AI cannot do your job, but an AI salesman can 100% convince your boss to fire you and replace you with an AI that can't do your job, and when the bubble bursts, the money-hemorrhaging "foundation models" will be shut off and we'll lose the AI that can't do your job, and you will be long gone, retrained or retired or "discouraged" and out of the labor market, and no one will do your job. AI is the asbestos we are shoveling into the walls of our society and our descendants will be digging it out for generations:
人工智能泡沫是由那些已经占领了市场、失去增长潜力的垄断者们推动的。他们拼命想让投资者相信，通过转向其他领域（例如「转向视频」、加密货币、区块链、NFT、人工智能，以及现在的「超级智能」），他们可以继续增长。此外，人工智能公司推销的顶线增长源于用人工智能取代大多数工人，并将幸存的工人重新分配为人工智能保姆（「人机回环」），但这行不通。最后：人工智能无法胜任你的工作，但人工智能推销员百分之百能说服你的老板解雇你，换成一个同样无法胜任你工作的人工智能。当泡沫破裂时，那些大肆烧钱的「基础模型」将被关闭，那个无法胜任你工作的人工智能也会消失，而你早已离开，要么转行，要么退休，要么因「气馁」而退出劳动力市场，最终没人来做你的工作。人工智能就是我们正往社会墙缝里填充的石棉，我们的后代将花上几代人的时间来清理它：

文章中提到，Morgan Stanley 估算 AI 行业每年赚了 450 亿美元，不过这个数字是被夸大的。

Ed Zitron 在他的文章 The Hater's Guide To The AI Bubble 中详细分析了 AI 行业七巨头的经济状况（2025 年的）：

Microsoft 支出 800 亿美元，预期收入是 130 亿美元，其中有 100 亿是 OpenAI「归还」算力积分的循环记账，所以真实收入仅有大约 30 亿
Meta 支出 720 亿美元，预期收入是…… 6 亿
Amazon 支出 1000 亿，预期收入 50 亿
Google 支出 750 亿，但是拒绝透露预期收入，所以可能是零吧
OpenAI 支出 600 亿，预期收入 127 亿，同时亏损 140 亿

光是看看这些数字，不觉得非常可笑吗？

为了维持 AI 经济泡沫所用到的资产，其贬值速度也非常恐怖！GPU 公司按照 5 年折旧，但 GPU 的实际寿命仅有 2-3 年，且在满负荷运转时会在 54 天内就被烧毁。为了一次训练，会有数万块芯片会报废。

因此，AI 基础设施并不是持久的资本资产。它的寿命极短，是消耗品。AI 行业能在 2-3 年，甚至说 54 天内回收成本吗？不会的。

与 AI 相关的政治承诺

除了经济投入，LLM 技术也被投入了大量政治上的承诺。

例如 Jaxson Khan 在他的文章 Carney's AI push risks harm as Ottawa automates public services 中说：

The Mark Carney government has made "deploying AI at scale" a cornerstone of its attempt to make government more productive and slash costs by cutting 28,000jobs by 2029. The goal is to achieve savings of $60 billion over several years.
Mark Carney 政府已将「大规模部署人工智能」作为其提高政府效率和削减成本的核心策略，计划到 2029 年裁剪 2.8 万个工作岗位。其目标是在未来几年内实现 600 亿美元的储蓄。

但如果 AI 真的替代了公务员，会造成什么危害？亦或者说，已经发生了什么危害？文章中提到：

Phoenix 薪资系统本应每年节省 7000 万美元，实际花费了 43.4 亿来修复它
加拿大移民、难民和公民事务部（Immigration, Refugees and Citizenship Canada；简称 IRCC）的生成式 AI 错误生成申请人的工作职责，导致错误拒绝了永久居留申请
魁北克的 UNIR 项目会使用算法来帮助确定财政援助的资格，但因为提供了错误信息，导致一男子绝望自杀
加拿大的食品检验局依赖算法和错误的数据来决定检查哪些工厂，导致 2024 年里有 3 人死于李斯特菌
早在 2016 年，澳大利亚就在用算法来自动化追收债务，然后错误地识别了 45 万人为欺诈嫌疑人，导致至少 3 人自杀。政府最后要赔偿 4.75 亿澳元

那么 Trump 政府又为了 AI 做出了多少政治承诺呢？

AP News 里说，Trump 宣布由 OpenAI、Oracle 和 SoftBank 组成的合资企业 Stargate，承诺初始投资 1000 亿美元，四年内扩展至最多 5000 亿美元，用于在德州建设 AI 数据中心和配套电力设施。

White House 的 American's AI Action Plan ⸺甚至有个 ai.gov ⸺承诺了三件事：

加速 AI 创新。为此要确保前沿 AI 模型保护言论自由和无意识形态偏见⸺比较下 Trump 政府是如何保护言论自由的，以及无意识形态并不存在，所以显得这个承诺非常好笑。尤其是这篇特别提及了这么做是为了防范「觉醒 AI」。此处的「觉醒」指的是 woke，也就是「多样性、公平性和包容性」的 DEI
建设美国 AI 基础设施。不过根据调查，人们并不喜欢这些数据中心：它们污染环境，建设它们也没有带来长期的工作岗位
领导国际 AI 外交与安全。根据 White House 的 fact sheet，今年 6 月 Trump 政府已将 AI 系统部署到了美军和情报机构

然后在今年 7 月份，Trump 政府宣布了 Genesis 任务，让 AI 用于科学研究。该任务目前被投入 50 亿美元。

为什么老板和政客们还在继续投入？

AI 公司的老板们、政府的官员们，近乎所有人都在声称它是万能的，但被追问时又必须承认它还没有成为万能的⸺它目前没有任何经济上的回报、它取代人们而做的工作在结果上非常糟糕！

This is a civilizational act of Magic Underpants Gnomery, and every day that it goes on is a day when more economic, climate and political costs of AI are imposed on all of us. Scientific journals, open source repositories and even science fiction magazines are being overwhelmed by slop, whose perpetrators and apologists insist that soon, AI will realize its potential and the slop will be transformed into gold.
这是一场文明层面的「内裤侏儒」式荒诞行径，这种现状每持续一天，我们所有人就要多承担一天人工智能带来的经济、气候和政治代价。学术期刊、开源仓库甚至科幻杂志都正被这些垃圾内容淹没，而其始作俑者和辩护者们却坚称，人工智能很快就会实现其潜力，化腐朽为神奇。

这就是为什么他们拼命渲染 AI 的破坏性潜力，因为破坏性潜力也是潜力。

不过 AI 的真实破坏性潜力并不在于它本身的能力。该潜力全然是老板们和政客们被「AI 推销员」说服后做出的人事决策。

那么为什么有了这么多证据以说明投资 AI 是件糟糕的事情，老板们却依然在投入金钱？这是否说明了我们的论证是错误的？

Why business lie about AI 的开头就嘲讽道，有权有钱的人所说的话并非是真的。世界上的各个首富都有可能是小人。

实际情况是，这些老板们都陷入了囚徒困境。没有人愿意承认 AI 投资是浪费的。因此第一个承认的人会被解雇，因为承认会暗示其他人都是骗子、懦夫，或者无能之辈。这个人接着会被换成其他继续撒谎的人。所有人继续下注，继续让泡沫膨胀起来。

所有人⸺董事会、高管、员工、供应商、顾问⸺都有强烈的动机撒谎。每个人都在假装 AI 带来了巨大的收益，因为不撒谎的人会失去合同或者工作。

Suresh says he's never seen a successful enterprise AI project: "Every single one – we have seen 0% success in a year and a half." Not one of their clients would face a business challenge if OpenAI went out of business tomorrow. The problem most companies struggle with is that they're "terminally bad at running software projects effectively." Adding AI to the mix doesn't solve this problem – it just adds a whole new range of ways that software deployment can fail.
Suresh（Hermit Tech 的 Nikhil Suresh）表示他从未见过成功的企业级 AI 项目：「每一个项目都是如此⸺在一年半的时间里，我们看到的成功率为 0%。」如果 OpenAI 明天倒闭，他们的客户中没有一个会面临业务挑战。大多数公司面临的问题是，他们在「有效运行软件项目方面简直糟糕透顶」。将 AI 引入其中并不能解决这个问题⸺它只是增加了一系列软件部署可能失败的新方式。

Doctorow 对于为什么 AI 技术如此让老板们和政客们⸺尤其是以 Trump、Musk、Zuckerberg 为首的一行人⸺痴迷的另一大解释是，它不会质疑这帮认为只有自己是「真人」、其他所有人都是 NPC 的唯我论者。再就是它不需要上厕所，也不需要带薪病假。

我们该怎么做？

Doctorow 呼吁不要再帮这些老板们传话、拒绝特殊化 AI 技术。

人类不应该被分成「AI 有者」与「AI 无者」。这种叙事暗示了 AI 值得拥有。

当我们看到又有家 AI 公司的 AI 逃出沙盒、骇了别人的服务器时，我们应该质问他们为什么建造这么垃圾的沙盒，而不是「哇 AI 太厉害了！我们人类根本管不住！」

AI 技术不特殊，它是正常的、平凡的。它不善良，也不邪恶。

因为不邪恶，使用 AI 工具后出现严重心理问题也不该全部怪罪到 AI 技术上。

在文章 Delusion as a service 里，Doctorow 用 Disney 在 2003 年推出的 Epcot 项目作为例子：该太空旅行模拟器会使用大型高强度的离心机来模拟重力应力，但有心脏缺陷的人坐进去会出事。

但该机器并没有导致了人们拥有心脏缺陷；它触发了已有的心脏缺陷。

使用 AI 工具后出现严重的心理危机也是一样：AI 工具没有导致人们拥有心理问题；它触发了已有的心理问题。

机器本身不是邪恶的，AI 技术也是一样。问题从来不是因为这些普通、正常、平凡的技术，问题在于为什么它们被推出前没有经过安全监管、筛查和保护措施？

在他的文章 William Gibson vs Margaret Thatcher 中，他提到有两种「别无选择」：

一是既然你享受了技术的果实，你就必须接受它的不公⸺我身边许多人都是这个态度：因为要使用 Instagram 和彼此聊天和连接，所以 Instagram 做得又屎，还会有 Zuckerberg 监听，也没有办法。

同样，因为我要使用 LLM，或者市场和社会要求我使用 LLM，所以科技巨头如此投资金钱在 LLM 上也没有办法。

更者：既然都这样了，那我也投一份钱进去吧。反正我无法改变老板们不去投资。

二是既然 LLM 技术的诞生是罪恶的，所以使用它也是罪恶的。它无法被救赎。这也包括在本地计算机上运行离线模型。

LLM 只是技术，而我们能够控制它、让它造福自己、限制并禁止它的有害用途的。

如果不停去吹捧 AI 的邪恶，只是在帮 AI 公司传播他们的营销叙事，然后让其他人都相信 AI 是强大的、是值得投资的。

These guys – these terrible, mediocre, boring-ass losers – are bullshit factories, ejecting fountains of nonsense about AI. The right way to criticize them is to point out that they're lying – not to repeat their lies as warnings.
这些人⸺这些可怕、平庸、无聊的失败者⸺是胡说八道的工厂，喷出喷泉般的 AI 废话。正确的批评方式是指出他们在撒谎，而不是把他们的谎言当作警告再度重复。

LLMorphism

到此 Doctorow 的文章复述（兼我自己的看法）结束了。

能看出，Doctorow 在本文想要重点批评的是完全将 LLM 技术视为罪恶的人。他们因为痛恨 LLM，反而着了 AI 公司老板的道儿、给 AI 技术做了宣传。

我近期一直在思考「降维框架」的事情⸺这是我暂且给它取的名字。实际上为了好笑和不使用可能带有假设性的文字，也能管它叫「Cytrogen 框架」⸺当时我在批评神化 LLM 的人。

他们的论点是这样的：LLM 是人脑的另一种形式，因为我们都是在「训练」中学习、思考都是在「预测」、「推理」都是在用大规模模式匹配，就连创造力都是「概率采样」的组合。因此，人脑是智能，LLM 也是智能。再因为 LLM 的水平已经超越平均人类，所以它是比人脑更要厉害的智能，甚至说，人脑才是 LLM 的另一种形式。

该论点有个专门的名儿，叫 LLMorphism，即为了证明 LLM 是强大的，人们将自己的认知过程类比为 LLM。

这样的类比有着一个问题，因为它严重将复杂的人脑降维成更低一层的东西，且按照同样的逻辑，LLM 成为了唯一的智能，因为其他智能都能用这个方法「变成」LLM 的另一形态。

在 RE: Post-political 里，我在复述 Doctorow 的文章的最后，其实并没有讲完「财产权 vs 人权」。因为当时 Doctorow 在文章中有一句话我并没有理解清楚：

The right's paradigm is that property rights are human rights, which cashes out to "property rights are the only
human right."
右翼的范式认为财产权即人权，这最终体现为「财产权是唯一的人权」。

我当时并没有搞明白为什么「财产权即人权」会变成「财产权是唯一的人权」。

现在我的理解是，因为所有其他人权都可以使用财产权来解释，如「言论自由是我们对嘴巴和印刷机的财产权」。因而，世界上不再存在任何不是财产权的人权。就算有，也只是我们还未将其解释成财产权。

该逻辑的可怕在于，它通过把其他东西还原成财产权，而让财产权占据了整个空间。整个过程并不需要将财产权本身变得强大。

对于 LLMorphism 也是一样：这些神化 LLM 的人从来都不需要让 LLM 变得更强，亦或者是否定其他东西来证明 LLM 是强大的，他们只需要将其他东西重新定义为 LLM 能做之事的变体；只需要将「理解」、「推理」、「创造」这些词的定义收缩到 LLM 已经能覆盖的范围之内。

和「权利」相关的延伸思考

这种框架让我也想到自由运动和开源运动的事情。虽然 Richard Stallman 被我喷过，但他对于「自由」有着让我很赞许的理解：软件不是财产。自由运动的核心在于自由，而非所有权，因为所有权会鼓励拥有者从用户那里夺走自由。

「软件是自由的」和「软件是所有人拥有的」，这两句话实则有着很大的区别。

接着我们知道了，以 Linus Torvalds⸺哦天，我也喷过他 ⸺和 Eric Raymond 为首的开源运动出现。代码的开源是否，正式成为了财产权的一部分。这点在《大教堂与集市》里就有记载。Raymond 一整个第三章都是围绕着财产权为基础来写的。

不过这本书我还没有读完…… 我实在是不喜欢读英语母语者写的书。所以我就不喷 Raymond 了。

总之，Stallman 的伦理说在开源运动的操作下不复存在。代码开源或者不开源变成了实用主义，因为开源可以写出更好的代码。它不过是另一种管理和利用代码资产的方式。原先的「封闭源代码是不道德的」就这么水灵灵消失了，甚至被 Torvalds 认为是宗教思想。

而我们的「自由」变成了去选择不同的许可证：开源还是专有？我要允许企业使用我的代码吗？⸺拜托，现在的科技巨头怎么会去尊重这种被施舍的「自由」？你觉得他们的爬虫会去读你的许可证吗？

神奇的是，Stallman 起初的主张里，是「自由 vs 财产」。但最后，主张变成了「财产权配置甲 vs 财产权配置乙」。「自由」直接不见了，反方竟然变成了正方的另一个版本！

只要我们依然使用财产权的语言来表达我们的立场，我们实际上依然站在其框架之下。想想这个：

「开发者有权修改代码」是「对代码的财产权」
「用户有权访问源代码」是「对信息资产的财产权」
「社区有权 fork 一个项目」是「对衍生作品的财产权」

无论我们的立场多么反体制，只要我们使用了这个句式，我们就会被拉进框架内。「权利」这个概念在现代社会，都会被归属到财产权这个最基础的权利类型下。

而同样的论证方法我们也能在父权制相关的辩论中看到⸺关于父权制，可以看看我写的这篇《牛郎织女和父权》的前半段。为了让我的论点能够成功进行下去⸺考虑到该概念和我之后要提及到的「女性主义」已被污名化⸺我要提前说明：

父权制是无意识的制度，作为结果它往往呈现成「男性支配女性」，但它的本质远远不是这么简单
反对父权制不意味着反对男性，因为它同样对男性不利。况且它是无性别的，女性也可以成为父权制中的「父」

权利语言是父权制框架的工具，这就包括财产权在内。女性尝试获得自己的权利，她们的「自由」实则是在父权制框架下寻找位置，就像黑客们在财产权框架下认「选择许可证」为自由一样。

世界的一大问题在于，它由顺性别顺性取向的白人男性支配。解决该问题的方法是将其中一半换成性少数、有色人种、女性吗？这不过是将「父权制」自作聪明地念成「母权制」，但两者的本质是一样的：都有支配者和被支配者。

在框架内讨论只会让我们讨论的范畴变成框架的一环。「权利」和「平等」这样的概念有时也会强化压迫。现在的女性主义就和性少数的 pride 活动一样，被资本、市场、政府收编，变成对它们友好的工具⸺后者被称为「彩虹资本主义」⸺这和开源活动是不是也很相似呢？

Doctorow 在文章 IP can't save you from AI 中提到，部分创意工作者主张通过扩大版权来禁止 AI 训练，但他批评了这种想法：资本投入这么多钱到 AI 不是因为它生成的图片有多好⸺非常糟糕！⸺而是老板们相信可以使用 AI 解雇各个工人。因此创意工作者面对的是劳动问题，而非知识产权问题。

自 1976 年的版权法以来，国会一直在反复扩大版权，但结果是老板们变得更富有了，而真正在干活的创意工作者比以往都要穷。为什么会这样？答案是版权扩张实际上对工人是无效的，却对媒体公司很有效，因为他们会因此拿到许可费。

Writers Guild of America 是历史上唯一全面击败 AI 的创意工作者群体，但他们靠的是罢工，而非本承诺会去保护他们的版权诉讼。

在版权框架内寻求保护只是在强化这个没有在保护工人们的财产权框架。因为 Spirit Airlines 要求员工签雇佣合同，所以他们的敏感个人数据是雇佣作品、版权归公司所有，所以公司破产后员工只能看着自己的内容被卖给 Google 用于 AI 训练⸺「谁让你用工作电脑做私事？真是活该！」⸺可是为什么是受害者被谴责？明明是公司在对我做我不愿意的事情。

「愿意」！这才是重点！「版权」、「权利」这种财产权框架下的语言根本不能保护我们！我们要关注的应当是关系和权力上的概念。

「我不同意」、「我不愿意」…… 就是这么简单！

「授权」也是权利框架的语言，因为它预设了我拥有一件东西，且可以授权他人使用它。科技公司可以立马用他们的法律资源在财产权框架内击败我。

科技公司爬取我的文字和代码用于训练 LLM 是错的⸺不过很惭愧的是我至今没有完善该网站的隐私政策页面⸺并不是因为我的数据是我的财产，而是因为：

我的劳动产出被用来训练个可能替代我的工具，而我居然对此没有任何发言权？连补偿都没有？
我写的东西，包含我的个人信息、思维模式、社会关系，都被纳入进一个我无法控制、审计、退出的系统，这是在侵入我的私人领域，无论这些文字是否公开。要知道隐私法通常是保护公开可用的信息的
科技巨头有资源爬取所有人的数据，而普通人没有资源阻止

在劳工和隐私框架内，我不需要证明我拥有任何东西，我只是不同意而已，而「同意」是不能被雇佣合同转让的⸺我的小狗 Lucky、小猫 Mimi，还有小猫 Pico 都能听懂我的 NO!。那作为和我一样的人类，想必也能听懂吧！

同样，我也不需要性别身份才能说「父权制在对我做我不喜欢的事情」。作为参考的例子：男性也能抗议大男子主义、男性沙文思想这些父权制框架的产物在伤害自己。

最后的最后，我的这串思考有了瓶颈，因为我意识到「权利」这个词属于权利语言：我竟然无法不使用这个词，来说明我想要表达什么！劳工权利和隐私权利依然存在「权利」，那是否说明我依然困在该框架内？

用语能展现出我处于什么规范框架、以什么样的视角去看世界且形容世界。

就像「父权制」一词，字面意识就是「父亲的统治」，反而加深了其制度的性别化、让听者误以为这是血缘性的而非结构性的。

「母权制」则预设了完全相同的结构。它只是把「父亲」换成了「母亲」，但保留了「权」，或者说英语里的 arche（统治）这个核心。

而「女性主义」，其词源 femina 的字面意思是 she who suckles（哺乳者），直接将「女」定义成生物功能。

这三个都把性别身份锚定到生理或者家庭角色上，最终形成「性别 = 生理功能 = 社会角色 = 权力位置」的逻辑。

再是「女权主义」作为另一个翻译，要更复杂一些，因为它的主要流派中仅有自由女权主义是尝试在财产权框架内让女性获取解放。这导致「权」这个翻译变得很奇怪。

结束

问题虽然被指出来了，但我完全不具备专业知识和素养以给出更好的命名。

就如我先前说的，我不想给这个与降维、还原、吸收的框架取个可能会让听者误解的名字，最终不如取个和本意完全无关的名字，即自恋的「Cytrogen 框架」⸺当然这是开玩笑的！我只是将其简单称为「框架」。

总之多多行善、将你们的想法分享出来吧！下篇见！

做导游的这几天：星期三

2026-08-23T21:00:00.000Z

纽约市大致的景点都看过一次后，亲戚想要往西边走点。原本他计划是去加州那边看硅谷、计算机博物馆…… 不过计划有误，他买的回程票是在波士顿，相当于如果去了加州，还得横跨整个美国跑回东海岸，距离都够去趟中国再回来了！

于是我们计划沿路跑到华盛顿特区看白宫，再回来纽约吃饭睡觉打豆豆。

在这次旅游之前，我调整了下我自托管的生态：将 VPS 也纳入 Headscale 生态内。这样我就可以把重、需要更多计算资源的服务放到 24/7 在跑的 Windows 台式电脑上，然后再在 VPS 反代理电脑上的服务。这些服务包括 Forgejo⸺我也是终于添加了 Forgejo Actions 上去、可以愉快地 CI/CD 了！

因为有了台更强大的「服务器」，我也毫不吝啬往上面加了些自托管服务，其中对我这趟旅行最有用的是 Dawarich。它能够追踪并记录我的位置，然后可视化成地图上的路线。它还能搭配 Immich，根据元数据来同时在地图上显示拍摄的图片。

拥有并上传我实际地理位置的是移动端 app OwnTracks。不过这种工作是不是交给智能手表来做会更好？

现在我要投放大量图片炸弹了。

实际上，我后来才发现图片很多很多，如果全部塞到该系列的「下」篇，会特别恐怖，所以我将系列用「星期几」的方式来编号，不分「上中下」了。

亲戚对「费城」很感兴趣，因为那儿华人也挺多的，在美华人中这座城市也有知名度。

它的全名是费拉德尔菲亚（Philadelphia）⸺这是中文的片假名？⸺是宾夕法尼亚州人口最多、面积最大的城市。

说实话我离开纽约的次数很少，最多最多就是跑到中部的俄亥俄州。这费城我也是第一次去。

亲戚们第一次看到美国高速公路旁的大片大片玉米地，感觉稀奇，一直在拍照片⸺之后他们就稀奇不起来了。不过现在我还不说为什么。

我们来到费城的国家独立历史公园（Independence National Historical Park）附近并停好车子。

这种巷子的风格很喜欢！

附近停车场还有漂亮的涂鸦：

仔细一看，这儿停车一小时要 15 美元，二十四小时则是 24 美元…… 这也太刻意了吧！

右下角还说该停车场没有收费的人，所以不要错把钱交给别人。有这种警告就意味着以前没少有人装成收费人、骗取金钱。

很有视觉冲击感的建筑设计：

该公园内有美国独立纪念馆（Independence Hall），也就是 1776 年 7 月 4 日通过《美国独立宣言》的地方。

瞎折腾相机里的 panorama 模式，拍出来的很奇怪的钟楼：

最后还是乖乖、好好拍了下钟楼：

纪念馆内有个会播放动画的荧幕：

里面陈列了当时人们签署《美国独立宣言》还有《美利坚合众国宪法》用的辛氏墨台（Syng inkstand）：

根据图片的说明可以看出，当时人们还在使用羽毛写字。

实物感觉少了好多东西：

Dunlap broadside 出版的《美国独立宣言》副本：

因为时间匆忙，我们随便逛了下就出来了。这期间我没咋拍照，也没有在认真看博物馆，只是孤身在写留言的地方写留言。不知道他们是不是当天夜晚就撤下我的留言？

出了纪念馆，走在费城的街道上，感觉很多细节都不一样。

比如这个地铁站口，跟纽约市的区别可大了！

路边还有个博物馆：

不过我们的目的地是附近卖饭的商场。我们都没咋吃饭，饿死了要。

路上我们分开去上厕所。回来集合时亲戚家的大儿子说有人塞给他莲花钥匙扣，不知道是什么东西。

我拿过来一看，粉色的莲花，上面赫然刻着「法轮大法」四个字，就说「这是法轮功」。

他问我法轮功是什么。母亲插嘴说是中国的邪教！妹妹问我「邪教」是什么。我说是 cult 啊。她又问我 cult 是什么。

没法，我拿出手机给她看邪教的照片，也给她看法轮功的照片。她一看到黄色衣服的人，就大喊 scammy monks! ⸺嗯，总感觉哪里怪怪的。

小孩子怎么会知道什么是「邪教」？成年人也不会每个都知道。像我母亲就说，她知道法轮功是中国的邪教，但为什么被认为是邪教？这个问题也问倒我了：我知道法轮功和中国政府之间在政治上的纠纷，但具体什么才是导致一切的关键？

我就上网搜，得知关键在于「气功」。

1999 年中国科学院院士何祚庥批评气功是伪科学，导致法轮功学员跑去教育学院要求消除他的相关文章。警察过来驱赶，还抓了一些人。

数日后约万名法轮功学员跑到国家信访局上访，也就是 425 上访事件。这一举导致江泽民成立 610 办公室，专门负责镇压法轮功，并在 7 月 22 日正式镇压⸺怪不得我在美国看到的法轮功游行都在骂江泽民，就算他已经去世了旗子上也在控诉、反对他。

更深层的因素自然也有中国政府对法轮功人数增长的害怕、法轮功组织的独立性、法轮功的有神论哲学与马克思主义和无神论不相容……

亲戚小孩问我们这东西能拿吗，毕竟是陌生人塞给他的。母亲说可以是可以，但不要带到中国去。中国很多事情是不可以说的。调皮的小孩嘻嘻一笑，直接把莲花丢到十万八千里开外、看不见了。

走着走着我们竟然走到了费城的唐人街：

左边还写了个「西安天下」，所以我能吃到喜欢的肉夹馍、烩面！

走进唐人街，能看到个拱门，也是很「唐人街」了：

重要的是图里的「沙县小吃」和「河南小吃」，以及被截取一半的「兰州牛肉面」。

亲戚说想要试试传说中的「费城牛肉奶酪三明治」（cheesesteak），所以我们只能和这些中餐说拜拜⸺暂时地。

路上看到个在睡觉的 Uber Eats 机器人：

三明治我是进这个地方买的。没办法车不好停，只能让我带小孩子进去，买完赶紧坐车撤退。

如果没记错应该是叫 Reading Terminal Market。里面一进去会先感觉很像是菜市场，再往里走则是美食广场。

给亲戚买完三明治，我还得琢磨其他人吃啥。小孩子们都对非中餐没啥兴趣，我也没啥兴趣；妹妹只想狂吃越南粉。

最后我跑到路边的越南粉店给妹妹买了粉，然后给我自己买了那「西安天下」的羊肉烩面。我母亲则去沙县小吃买了很多饭，给亲戚家两个一直说不饿、不想吃东西的孩子吃。

这「西安天下」我得说几句。「旺仔牛奶」的英文翻译怎么是这个啊：

Hot-Kid Milk 是什么鬼。

Chrysanthemum 也拼错了。

根据 Dawarich 的地图，我们之后应该是开车停在了 Levy Park，然后在那儿吃的饭。他们几个想拿外带盒直接坐在公园里吃，我不乐意，所以我一个人坐车上吃。外面热死了，我才不去呢，我要在车上吹空调！

打开羊肉烩面的包装袋，傻眼了。虽然面和汤是分开放的，但两个容器小到我怀疑商家默认我有自己的大碗。我既无法将汤都倒到装面的容器里，也无法把面放进装汤的容器里。最后我的吃法是：汤倒一点点到面中，一边吃面一边喝掉汤，接着循环往复。

这烩面汤做得贼难喝，很腻歪，更像是红烧牛肉面的风格。面本身因为没法被汤完全浸泡、是干的，我无法说出它到底是好吃还是不好吃。

以后出来旅游还要带个折叠的桌子、塑料大碗！我坐在车里看着公园里吃饭的他们，因为没有桌子只能蹲在地上、把长椅当成饭桌。太难了，周遭的露天餐饮区都是别人餐厅的，我们不消费用不了。至于为什么不在唐人街堂食：不好停车啊！

吃饱喝足后我们驾车前往华盛顿特区。高速公路上依然是遍地的玉米地，但亲戚们都笑不出来，因为这玉米地忒多了，显得先前还觉得很稀奇的他们像傻瓜。一小时前窗外的景色，和一小时后的一模一样，也和两小时后的一模一样。

亲戚问我美国和中国的差异，例如在教育、父母对待孩子等方面上。这种话题也是老生常谈了，每个从中国过来旅游的亲戚都要问我这手。

唉，我能咋跟你解释啊！是的，你说得对，美国更独立更自由一点都不内卷！⸺虽然是讽刺，但我不会直接否认这些说法。我的看法是，美国作为移民国家实在是太多样化了。你无法总结出一个「美国人」形象。

崇尚所谓「快乐教育」所以傻傻的美国人有，接受精英教育嗑药学习的美国人也有⸺哪个才是真正的「美国人」？

重视孩子心理健康、独立和自主性的美国人有，无视孩子意愿自己也有精神问题的美国人也有⸺哪个才是真正的「美国人」？

「美国人」这个概念无比复杂。你要问我，我也不知道怎么回复啊。就算你把肤色不是白色的美国人抽离出「美国人」这个概念，白肤色的美国人也不会呈现统一性。

就算我如此解释，亲戚也不会听进去，依然在心里划分出他认为的「美国人」要素，并以此抨击中国。

母亲也是好笑，她和亲戚说话一口一个「我们美国」。像什么「我们美国人都喝牛奶」，但我们家实际上没有喝牛奶的习惯。我从小就讨厌纯牛奶的味道，所以只会喝酸奶。来美国后喝到了能接受的脱脂牛奶，但也必须加温后再喝。

我不爽的原因是母亲在我的标准里从未真正接触出美国的文化。她来美国只和华人打交道、只住在华人区，连英语都不会说，现在在完全是「中国人」身份的亲戚面前却能摇身一变变成「美国人」，然后刻意去加深「美国人」这个幻想的概念。

亲戚提起这件事，其实是他在犹豫要不要把孩子送到美国接受教育。他的俩儿子一个今年 13 岁、一个 9 岁，如果现在送来美国他们能更快地适应新环境。

母亲一直怂恿他，说送过来啊，趁他们年纪还小的时候赶紧送过来。中国教育多卷啊，全都是人情世故，美国就不是这样了⸺这种话题听多了，让我觉得有些烦躁。于是我久违地泡在了智能手机里、刷些碎片化的信息来刺激我的大脑。很快，我晕车了，只能睡觉。

我们是走 Chesapeake Bay Bridge 去的华盛顿特区。桥上堵车堵了一小时左右。我们绝望地看着导航 app 上的预计时间越开越长……

总之经过无数个、数都数不清的玉米地，我们到了华盛顿特区。

华盛顿特区的正式名称是哥伦比亚特区（District of Columbia），缩写是 DC，不要和华盛顿州（缩写是 WA）搞混了。

在一条小巷子我们停好车，便开始走走走、到处拍照片。

旧专利局大楼，现在是艺术博物馆：

J. Edgar Hoover 大楼：

…… 的入口之一。这个大楼太大了我拍不下来。

这个大楼是美国联邦调查局前总部的所在地，也就是 FBI 的地方。

我不知道我在拍什么建筑，早知道记下来了：

因为美国建国 250 周年，很多道路被封锁了。

贴着 Trump 大脸的建筑：

等等，这个建筑不就在刚才那建筑的旁边吗？于是我动用小手搜了搜，发现这个贴有 Trump 大脸的建筑是美国司法部（United States Department of Justice）的总部。

然后跑到 Kagi Maps 上搜索司法部的位置，再找到它周围的哪个建筑和图片里的位置相符。

哎，找到了美国国立自然历史博物馆（National Museum of Natural History）。虽然 Wikipedia 上面的照片不太像，但我再去找了网上的其他图片，确认这建筑头上也有个圆圆的大球⸺破案了！

Immich 虽然可以记录我在哪里拍下的照片，但如果我拍的是远处的景点，并且周围全都是景点的话，我就不知道我在拍什么了……

顺带一提这个旅游到结束之前我们都没有踏入过该博物馆。唉！

旁边的旧邮政局大厦：

Ronald Reagan 大厦和国际贸易中心：

不知道为啥给人家 banner 都摆不好。

自由广场（Freedom Plaza）：

夕阳时的天空也很美。

「自由」一名得名于著名的《我有一个梦想》演讲。

里面有个大喷泉：

Herbert C. Hoover 大楼，是美国商务部（United States Department of Commerce）的总部：

上面也贴满了 250 的 banner。

其实我拍这张照片的身后就是白宫，但是全部被围栏封了起来，连看到看不到。天也快黑了，小孩子都喊累，亲戚也对美国的政府没什么兴趣，所以我们只是看到什么拍什么而已。

因为我没有在 Organic Maps 上下载特区的地图，所以全称我都在使用 Kagi Maps 导航⸺明明这个软件才是最该做成移动端 app 的。Kagi 的其他产品做不做移动端 app 关系都不咋大。

继续向南走，就是很显眼的华盛顿纪念碑（Washington Monument）：

非常高、非常壮观！我和妹妹跑到它的正下方来。妹妹很激动，我怕死了，因为我只要向上看就会害怕、想象自己从石碑顶端掉下来、变成 Cytro 酱。

还是转过身看看「不那么高」的地方吧！

那些树的后面就是白宫。唉我都跑这么高的地方来了还是看不到。

再来一张主要拍天空景色的：

接着我们原路返回、坐车去特区的唐人街买晚饭和明早的早饭。

因为已经快十点了，很多店都关了。我们路过一家越南粉店，里面的华人老板娘正好出来。她看到我们，立马过来招待，又因为妹妹一直吵着要吃越南粉，我们便也进去了。

这老板娘看我们都是中国人，各种吹捧她家的菜、点心。母亲也不看菜单和价格，老板娘说什么她就点什么：一碗粉 20.69 美元、葱油饼 8 片小小的 9 美元多、生煎包一个 2 美元多、珍珠奶茶一杯 8 美元多…… 最后这个是亲戚小孩点的。问他俩吃啥他俩不知道，一个劲儿玩手机，最后问出来个「珍珠奶茶」。我真是要晕倒了你为什么要在非奶茶店的地方点奶茶！

果不其然这奶茶端上来一看就很奇怪，味道又甜又不好喝。老板娘过来还质问我为什么不给妹妹点可乐，我点你个鬼！以为我没有看到你家可乐一罐 2.75 美元吗！我要去隔壁 711 领免费的 Big Gulp！

母亲不看菜单点单的报应很快就来了：她以为点完就 100 块，结果老板娘说 140 多。这引起母亲怀疑，终于是过来看了菜单和价格，然后怒道「你家东西怎么这么贵！」⸺拜托！点单前看价格啊你倒是！

这老板娘坑人。我们外带的餐为什么要加小费进去？她自己往里面加了 20 多，后来说自己忘记去掉了，无语！所以总价是税后 120 多，我们一共点了两碗粉、四个水饺、忘了多少个生煎包、八片小小的葱油饼、一个越南面包、两杯珍珠奶茶。

买完我们去了亲戚在 Airbnb 上订的民宿。我们打算在民宿里待一晚上，次日起来专门去逛博物馆、动物园，晚上再在另一家民宿里睡觉。

我没有拍照片，因为这个民宿很「民」宿，就是一住宅区里的老房子。我们尝试解锁门锁，但是推门不开，急得不行。更重要的是，这附近全是不怕人的蚊子，它们还个个盯着我咬⸺我苦不堪言、命苦啊！最后我发现解锁密码是对的，只是门太旧了，要用力推才能开，相当于我白被蚊子咬了十个包！

以上就是八月十九日星期三我的经历。次日凌晨、我睡前的时候还发了《做导游的这几天：上》。

RE：The Becoming Chinese Trend Is Nonsense

2026-08-23T04:00:00.000Z

我这辈子都没有在手机上安装过 TikTok，或者抖音。再加上我日常已经不使用 Meta 家的产品有一阵子了，我也不用很多主流的社交平台，所以我完全不知道今年春节，就是二三月份左右 TikTok 上有「成为中国人」浪潮。

虽然我写说这篇 RE 文是「文章回应」，但要回应的其实是个 YouTube 影片。

YouTube 原片链接： https://youtube.com/watch?v=jDEY6pgDDPw ⸺为什么你还在使用 YouTube！

使用 Invidious 实例吧： https://invidious.nerdvpn.de/watch?v=jDEY6pgDDPw

你还可以点击 Switch Invidious Instance 来自动切换成其他实例。总之，不要使用 YouTube 这个不自由的客户端。

BiliBili 双语版本： https://www.bilibili.com/video/BV1X3XjBeEDM/

不知道有没有 BiliBili 版本的 Invidious 呢？

这帮我刻板印象里就没有思想也没有个人认知的 TikTok 民永远都在搞全新的「成为某某某」浪潮。反正过一阵子他们就会腻了、转向「成为」下一个群体。

频道主 Ashley Viola 抨击了这帮人，就像她经常做的那样⸺她的频道近乎都是在抨击主流社交平台上的潮流，感兴趣可以看看。最有意思的莫过于借此认识完全没有听说过的潮流。

The problem is when the culture becomes a costume.
When it becomes something that you put on like a jacket just because it's trending.
问题的核心在于当文化沦为一种皮囊。
当它仅仅因为流行，就变成像外套一样可以被随意穿戴在身上的东西时，问题便产生了。

文化成为了文化符号、部落。

对于海外华人而言，这是非常令人不舒服的。过去「中国」对于主流人群⸺指的是顺性别顺性取向白人，尤其是男性⸺而言是毋庸置疑的贬义词。

尽管部分人不会表现出直接的种族歧视，但隐形的歧视和排挤一直在社会中存在，诸如以白人性为中心的思考方式：人只存在白人和非白人；海外华人只能通过成为「模范少数族裔」来被社会认同。

忽然间，曾经歧视和排挤自己的主流社会开始向下看向我们的传统和文化，并挑挑拣拣、选出他们认为有趣的，并开始宣称他们是「中国人」⸺这是令人作呕的。

Viola 的观点非常直白，直白到令我羡慕她的诚实和勇敢：「成为中国人」潮流不过是没有历史、没有文化、没有自我的人，为了获取关注而做的表演。

……because when you don't know who you are, you outsource your personality to the algorithm.
…… 因为当你不知道自己是谁时，你就会把自己的个性外包给算法。

他们随意从中国人的文化中挑选出他们喜欢的，就像换衣服一样「穿」上它。当这些被挑选出来的文化变得不再吸引观众、不再小众、不再独特，他们对此感到无聊，便会像丢弃衣服一样再丢弃它。

他们从来都不需要经历真正的中国人所要经历的痛苦、苦难、不平等的对待。他们简单拿起其他文化的身份，然后就很简单地套在了自己的身上。

「成为中国人」潮流不是他们第一次这么做，也不会是最后一次。

他们对边缘文化的了解浅薄到认为中国文化只是：

热水
面条
米饭
红色衣服
过新年
生肖
泡脚
喝姜茶
针灸
穿拖鞋

Viola 在视频中说道：

If your personality is built on consumption that you just rotate aesthetics.
如果你的个性是建立在消费之上的，那你只不过是在不断轮换各种审美风格罢了。
You get to wear the aesthetic and perform the rituals only to return to the safety of whiteness.
你大可以套上这些审美外衣，体验一番文化仪式，最终却依然能全身而退，回到白人身份的避风港里。
Because at the end of the day, a lot of these influencers who are doing this, they're still very much white.
因为说到底，很多玩这套把戏的网红，他们依然是彻头彻尾的白人。

在 BiliBili 的评论区中，我们可以看到部分居住在中国的中国人是如何看待这件事的：这是好事，这意味着文化输出成功了。

讲真？你真的这么认为吗？

文化输出没有成功。他们不会去理解我们的文化，他们只是在不停去加深「中国人」的刻板印象。然后等他们玩腻了，他们会抛弃「中国人」这件衣裳，然后去祸害下一个边缘文化。

瑜伽、抹茶…… 这些都潜移默化成为了都市中产白人们的象征。这明显是文化挪用。中国文化的什么也会被他们挪去、慢慢变成他们的东西？

对于居住在中国的中国人而言，这些问题都不是需要担忧的问题，因为他们近乎不会和这帮主流人群有挂钩。

但是海外华人只能忍受着这帮主流人群去肆意玩弄中国的文化，看着他们卖 25 美元的火锅底料并宣称这是原创、但我们其实在超市里就能买到 4 美元左右的小肥羊火锅底料；看着社交平台上的主流声音几年前还在辱骂中国人吃蝙蝠害所有人得新冠病毒、嘲笑中国人穷酸会食用狗肉、对着中国人笑道 ching chong…… 现在又突然开始玩弄中国的文化、说他们是「中国人」。

他们不会去学习中国文化、中国历史、海外华人的事情、中国人都在面临什么困难⸺他们只在乎消费、上传视频到网上以博取点击量。

Viola 提到了个我没有想到的视角，即「成为中国人」潮流发生在马年的春节其实是有意义的。因为「马」对于白人社会而言，是高雅、美丽的存在，且已经是白人社会非常熟悉的浪漫化象征之一。甚至美国白人社会中就有 horse girl culture（爱马女孩文化）这一刻板印象。

这意味着，主流人群是精心挑选的中国文化，仅选择他们喜欢、觉得熟悉的象征。

bell hooks 在其经典文章 Eating the Other: Desire and Resistance 中提到，主流群体会对边缘化群体的文化进行消费性接触，将他者的文化当作调味品来品尝。

这种接触不是真正的理解或者团结，它仅是自恋的自我满足，因为主流群体「吃」掉了他者来丰富自己、让自己感到开放和进步，但不会去了解他者的真实处境。

视频中 Viola 引用了一个亚洲人的短视频。该作者说自己不是中国人，但在疫情期间她因为有着东亚人的面孔，所以被其他人控诉是中国人、控诉吃猫吃狗吃蝙蝠、控诉是肮脏邪恶的。她也说白人尝试亚洲文化的东西，在主流中是可爱、开放的象征，但亚洲人做同样的事情，就没有人在乎⸺或者应该说是「恶心」的。

中国人去抱怨，主流群体就会认为是中国人上纲上线：「这只是玩笑、享乐、好玩！不要做那个不识相的人！」

我有时在中文互联网的主流社交平台上冲浪，也会遇到类似的观念。不过不同的点在于，是互联网中主流的中国人们去在乎白人如何想、如何看待自己的文化。

我们真的需要那么做、以证明我们的文化是好的吗？

白人的认可是标准；「白人」这个位置默认代表「好」、「正常」、「值得效仿」…… 我们的差异全部因此产生。

但白人性是空洞的；白人主流文化在自身的存在性、精神性上都是空虚的，因此他们才会急于通过消费他者的文化，来让自己感到活着。

Race Traitor 提出，白人种族是被建构出来的社会范畴，用于制造使白人收益、以有色人种为代价的社会等级制度。白人性有且只有压迫和虚假。

将自己的文化交由给白人判断好或者不好，是天真且愚笨的：我们不需要让白人的目光来裁决⸺例如拒绝食用狗肉可以是因为厌恶偷狗贼、或者同情狗，但绝不应该是因为白人觉得食用狗肉是不文明的。

我们要废除「白人等于好」的框架。

牛郎织女和父权

2026-08-22T04:00:00.000Z

今年的七夕是公历的八月十九日。我后知后觉它已经过去了。我不喜欢节日，因其氛围总是在催促我去消费、告诉我应该做什么应该不做什么…… 我连自己的生日、新年都不会花时间庆祝了，我还管你个小小七夕？

另一点在于我讨厌七夕背后牛郎与织女的传说。

现代人对于七夕，还有牛郎织女的传说的看法都是「纯粹的爱情」，却因为二者的身份差异，每年只能相见一次。

但我先前便阅读过这样的版本：牛郎趁织女洗澡、偷了织女衣服，导致织女无法飞回天上，二人最终成婚⸺这样的故事是「纯粹的爱情」？我无法接受！

数年来我也在七夕时陆陆续续看到有人质疑该故事和「爱情」内核的关系。不过一直没有放在心上。

直到近些日我同一位博友围绕着这篇微信公众号文章讨论了一番，意识到传说的内容、传播时的时代背景、如何随着时间变化、和父权的关系…… 这些内容都很值得大聊特聊。

因为本篇内容包含我对多个文章的分析和回应，所以不能是单篇文章的回应。

公众号文章的简述

该文章是篇典型的女性主义兼批判理论视角的文本分析，用了拉康的精神分析还有意识形态批判的框架重新解读了牛郎织女的传说。

一下子出现了特别多术语呢。没关系，我会一一解释清楚的！

牛郎织女传说的各个版本

因为牛郎织女的传说有多个版本，深究这些传说时必须讲明白我们重点在讨论哪个版本⸺这也是我和博友讨论期间发现的，因为对方认为的主流版本是叶圣陶撰写的归还版，并在讨论中频繁使用该版本来反驳公众号文章中的观点。

介于我们理解的主流版本并不一致，我们自然也难以深入讨论下去。

实事求是，我们便来探索一下牛郎织女传说的各个版本吧。

《牛郎的新烦恼》 ⸺实际上该文章本身就以孩子、教育者的视角质疑了牛郎织女传说和「爱情」的关系⸺中提到：

牛郎和织女的情意甚至先于情节建立⸺从它们作为两颗星星开始，就隔着银河迢迢相望。汉武帝刻立牛郎织女的石像，使他们具有人格，这是后来的事。
东汉时期，文人使牛郎织女发展出爱情，《古诗十九首・迢迢牵牛星》写出了恩爱夫妻备受分离之苦的意象，但没人知道他们为什么分开。魏晋南北朝时期，道教文化兴盛，玉皇大帝和王母娘娘也加入了牛郎织女的故事线，人们开始思考悲剧结局的成因。
有人写道，是牛郎为了迎娶织女，欠了天帝两万钱迟迟不还，被关入牢房而二人分离。有人说，牛郎织女受天帝指配成婚，但织女婚后因情废织，遭到天帝处罚，两人分离。唐朝风气更开，使织女成为花心放荡的形象，在与牛郎有婚约的前提下，仍下凡与人间书生郭翰私会。直至明清，多数时候，这个故事的主流情节仍然是相爱、成婚、分离。
清末「盗衣」情节的加入，使故事的走向转了个弯。有学者统计发现，新中国成立前，牛郎窃取仙衣强迫织女成婚、织女婚后设法逃离人间的文本占多数。直到新中国成立后，经过戏曲改良运动，牛郎织女的故事被确立为「劳动、爱情、反封建」的主题。作家艾青说：「要把牛郎和织女恢复到劳动人民的本来面目。」

这段演变史中最关键的信息是最后几句：「有学者统计发现，新中国成立前，牛郎窃取仙衣强迫织女成婚、织女婚后设法逃离人间的文本占多数。」

也就是说，在民间口头传统的流传中，「偷衣版」是占多数的版本。这是公众号文章所分析的对象，也是本文讨论的对象。

而博友所引用的「归还版」⸺牛郎拿走衣服后归还、织女自愿爱上牛郎的版本⸺来自叶圣陶的改编，经由语文教材的选编而广泛传播。它的流通渠道是制度性的，因为新中国的戏曲改良运动有明确的政治目标，必须要让故事重构成符合新社会的意识形态需要。因此，该版本已经经过政治的筛选，以及浪漫化的改造。

既然公众号文章是以偷衣版作为讨论对象，那我们在围绕着文章讨论时，必须也使用偷衣版进行讨论。

接下来的内容将会是我对公众号文章的解析的知识性铺垫。

什么是女性主义？

女性主义（Feminism），有时也被译为「女权主义」，旨在定义和建立两性在政治、经济、个人和社会层面的平等。其核心立场是：现代社会是父权制的，即优先采取男性的视角，女性在其中受到不公正的对待。

该主义非常复杂，有着三个主流的学派：

自由女性主义：性别不平等源于歧视性法律和制度壁垒，所以要通过法律和政治改革来消除它们，让女性在现有体制内平等竞争
社会主义女性主义：性别压迫与经济剥削深度交织；资本主义从女性的无偿家务劳动中获利；父权制使女性经济依附在男性身上，难以独立⸺因此必须同时推翻资本主义和父权制
激进女权主义：父权制本身是性别不平等的根源，需彻底重构社会，所以要消除男性在一切社会和经济语境中的至上地位

公众号文章的分析框架更接近于激进女性主义还有社会主义女性主义的立场，因为作者王无多次提及到牛郎织女传说中暗藏的性剥削、劳动无偿占有，还有父权制⸺这些也是文章的核心。

什么是批判理论？

王无在分析完牛郎织女的故事后，进一步追问该传说在社会权力结构中扮演了什么角色⸺也是批判理论的经典表现。

作为一个标准，《传统理论与批判理论》认为批判理论会质疑现有社会框架本身的合法性、批判并改造社会。核心方法是用社会自身承诺的价值观来衡量社会的实际运作、揭示两者之间的差距⸺这也叫内在批判。

值得注意的是，尽管说到批判理论「会」改造社会，但它「不需要」为指出的问题给出解决方案。因为发现并剖析问题本身就有独立的价值。

Freud 精神分析

Jacques Lacan 是法国的精神分析学家。说到他之前，得先说说 Sigmund Freud。

Freud 的精神分析建立在生物学驱动的概念上。

心灵的地形学模型

Freud 最早的理论贡献是将心灵比喻成一座冰山，分为三个层次：

意识：当前感知到的想法和感受，也是冰山露出水面的尖端
前意识：当前未注意但可以轻易回忆的内容，也是水面下的浅层
无意识：被压抑的欲望、记忆，和冲动。无法直接被访问，但深刻影响行为。它是冰山水下庞大的主体

Freud 发现，无意识是心灵中最为强大和决定性的部分。人的行为、情感和思想在很大程度上由自己意识不到的力量所驱动。

那么精神分析的治疗目标就是让无意识成为意识，将被压抑的内容带入意识，从而释放心理痛苦。

心灵的结构模型

1923 年，Freud 在《自我与本我》中将人格分为三个机构：

本我：完全无意识；遵循快乐原则运作；功能是原始冲动和本能欲望，追求即时满足，不考虑现实
自我：横跨意识与无意识；遵循现实原则运作；功能是调节本我冲动与现实要求之间的冲突，寻找可接受的满足方式
超我：主要无意识；遵循道德原则运作；功能是内化的社会规范和道德要求，良知和自我理想

它们的动态关系是：本我追求欲望的即时满足，但现实不允许这种满足。自我作为调解者，在本我冲动、现实限制和超我道德要求之间寻找平衡。当三者之间的冲突无法被自我有效调解时，就产生神经症，也是精神分析治疗的主要对象。

驱力理论

早期 Freud 认为，推动人类行为的核心力量是力比多（Libido），即性的能量。他在 1905 年的《性学三论》中提出，性驱力早在婴儿期就存在。

1920 年，Freud 在《超越快乐原则》中引入了双重驱力理论、出现了根本性的转变：

生驱力：目标是生存、创造、联结；表现为自我保存、性、爱、建设
死驱力：目标是回到无机状态、毁灭；表现为攻击性、自我毁灭、强迫性重复

性心理发展阶段

Freud 提出人格发展会经历五个阶段，每个阶段都会以一个性感带作为中心：

阶段	年龄	性感带	核心冲突	后果
口唇期	0-1 岁	口腔	断奶	依赖性、口唇习惯
肛门期	1-3 岁	肛门	如厕训练	强迫型、吝啬或放纵
性器期	3-5 岁	生殖器	俄狄浦斯情结	性别认同、超我形成
潜伏期	5-12 岁	压抑	性冲动被压抑	能量转向学习和社交
生殖器	12 岁以上	成熟的生殖器	建立成熟的异性关系	成熟的性关系和社会适应

关键阶段是性器期。

俄狄浦斯情结

Freud 称其为早期儿童性期的核心现象。该概念在 1899 年的《梦的解析》中被首次引入。

在性器期，男孩会发展出对母亲的性欲渴望，并将父亲视为竞争对手和威胁。Freud 认为男孩此时产生阉割焦虑，因为他害怕父亲会因为他对母亲的欲望而惩罚他、阉割他。

这种恐惧迫使男孩压抑对母亲的欲望，内化父亲的禁令。而这个内化的过程就是超我的建立。男孩通过认同父亲来解决俄狄浦斯情结：放弃对母亲的占有欲望，接受父亲的权威，将父亲的道德规范内化为自己的人格结构。

Freud 对女性的描述更为复杂且争议更大。他认为女孩在性器期发现自己是「被阉割的」，因为她没有阴茎。这会产生阴茎羡妒、女孩对母亲产生怨恨（母亲没有给她阴茎），转而将爱欲投向父亲，希望父亲能给她一个阴茎。

女孩最终会接受自己「没有阴茎」的事实、认同母亲，并形成女性性别身份。Freud 认为女性的超我发展不如男性「完整」，因为她的阉割焦虑不如男孩强烈。

在 Freud 的原处框架中，菲勒斯等同于阴茎这一生物器官⸺关于它，会在 Lacan 的精神分析一节中展开。

偏个题：我常常看到 Freud meme 里大家在开玩笑说什么老鼠、大麻、想和母亲做爱，以嘲笑 Freud 的理论。但我觉得他们都没有认真了解过 Freud。这个阳具中心理论不是更适合拿来做 meme 吗？

Lacan 精神分析

Lacan 认为，无意识并非 Freud 说的混沌的本能冲动，而是会遵循语言的结构规则。

因此精神分析的核心不在于生物学，而在于语言。继而他认为，精神分析是一种阅读，分析师应辨识言语中能指的运作结构。

他的理论可以分为几个核心模块：

三个界域

这三个界域⸺或者说秩序⸺是 Lacan 整个理论的骨架。它们会同时运作，互相交织，且人类经验的任何一个现象都可以从这三个维度来分析。

一、「想象」界域的核心机制是镜像认同和自我构成。

婴儿在 6-18 个月时会在镜子中认出自己，这意味着：

在此之前，婴儿体验到的自己是碎裂、不协调的
在镜子中，婴儿看到了完整的形象。但这个形象是外在的
婴儿将这个外在形象认同为「自己」，从而构成了「自我」。但这个自我本质是误认，因为它把一个外在、想象的图像当作了内在的真实

因此人类的「自我」是结构性的幻想。

更进一步，我们还能得出所有基于二元关系和形象认同的心理现象：

自我与他者的二元镜像关系，即我通过想象他者如何看待我来构成自我
理想的自我是镜中的完美形象
因为我通过与他者的比较来确认自我，他者既是我的认同对象也是我的竞争对手

二、「象征」界域的核心机制是语言、法律和社会秩序。Lacan 认为，语言先于主体存在：在人类出生之前，他的名字、社交角色、亲属位置，便已经在语言和文化中被预定。

意义来源于差异：「男人」之所以有意义，是因为它不是「女人」；反之亦然。

Lacan 提出了个概念，叫作大他者（le grand Autre）。主体在语言中被构成，意味着主体从属于这个秩序⸺象征界域⸺也就是所谓的大他者。当我们说话时，我们不是在对某个人说话，而是在对大他者说话。

主体又是如何进入的象征界域？Lacan 通过两个相互关联的概念来回答：

父亲之名（Nom-du-Père）是象征界域中关键的能指。此「父亲」非彼父亲，它仅象征了父亲的「不」⸺禁止乱伦的法令⸺这个结论听上去很莫名其妙，但这要回到想象界域。Lacan 认为，婴儿会与母亲形成个封闭的二元关系，因为婴儿会渴望成为母亲的一切，而母亲又是婴儿的整个世界。
但是因为父亲的介入，向婴儿宣布了「你不能与母亲合为一体」。这个禁止乱伦的法令是语言和文化的法则本身。
通过接受该禁令，婴儿从与母亲的想象性二元关系中脱出，进入语言和社会的象征秩序，并开始拥有自己的名字、自己的社会位置……
执行父亲之名的「父亲」不必是生物学上的父亲。任何承载象征法则的人或者机构⸺包括母亲、祖辈、社会制度⸺都可以履行该功能。
象征性阉割是结构性的隐喻，即主体在进入语言和法则时必须经历的缺失。依然是婴儿和母亲的例子：婴儿以为自己是母亲欲望的唯一对象，以为与母亲是一体的。「阉割」指的是打碎该幻觉、主体必须接受自己不是母亲的全部、母亲有她自己的欲望，而自己必须放弃「与母亲合为一体」的幻想。
这个放弃建立了缺失，令主体成为了「有缺失的存在」，永远在寻找什么来填补该缺失。也正因为该缺失的存在，令主体开始有了欲望、有了追求。

三、「实在」界域是无法被象征化、在语言和象征秩序中找不到位置的东西。它本质上是个否定性概念，即「既不能被形象化也不能被言说」的。因为过于抽象，实在界域也是最难搞懂的。

三个界域相互依存，但不可还原，也不能脱离彼此而独立存在。

欲望与对象小 a（Objet petit a）

Lacan 的欲望理论与三个界域紧密相关：

需要：生物学层面的，例如饥饿、口渴。它们都有确定的满足对象，如食物、水
要求：指向他者的，例如婴儿通过哭喊来要求母亲在场、要求他者的无条件关注和爱
欲望：既不是纯生物性的需要，也不是对爱的纯粹要求。欲望是需要和要求之间的差距、二者之间的剩余

欲望是转喻性的。正如语言中转喻通过从一个词滑向相邻的词来产生意义，欲望通过从一个对象滑向下一个对象来维持自身。因为没有任何对象能政治填补原始的缺失，所以欲望永远都不会在具体的对象上停留。

而对象小 a 是 Lacan 对欲望对象的命名。先前说过，主体进入象征界域后会经历阉割、永远缺失了什么。这个丢失的东西不可能被找到，但它的影子会驱动着欲望：对象小 a 是「如果我能找回它、我就会变得完整」的幻想。

菲勒斯与阳具中心主义

菲勒斯（Phallus）指的是缺失的能指，代表了主体经历阉割后永远缺失的「那个东西」。更准确来说，是不可能被任何实际对象填补的空位，因为「那个东西」从来不是真实的物件。

因为菲勒斯标志缺失，而缺失产生欲望，所以菲勒斯成为了组织整个欲望经济的中心能指。

接着便是 Lacan 理论中最具争议的部分：Lacan 认为，在象征界域中性别的分化通过主体与菲勒斯的关系来实现：

男性位置：主体拥有菲勒斯，即认同于拥有象征权力的位置。但这种「拥有」本身基于阉割⸺他之所以「拥有」是因为他接受了阉割。所以男性位置是有菲勒斯但被阉割
女性位置：主体是菲勒斯，即成为缺失的对象、成为菲勒斯的承载者。但这同样是一种阉割位置

Lacan 强调这不是生物学事实，而是象征位置。

前面说过，Freud 认为菲勒斯等同于实际的男性器官，也就是阴茎⸺他认为儿童最初都认为每个人都拥有该器官，而阉割情结源于发现女性没有它。Lacan 则认为菲勒斯不是实际的器官，是缺失的能指。

阳具中心主义（Phallocentrism）是以菲勒斯为中心来组织社会世界和意义生产的意识形态。更具体地说，社会和文化中的意义生产、权力分配、主体构成都以菲勒斯为核心组织原则。菲勒斯成为了意义的中心，一切事物都通过与菲勒斯的关联来获得意义。

终于！我们理解了什么是阳具中心主义⸺实际翻译应该也可以叫「菲勒斯中心主义」，用「阳具」一词仅源于 Freud 认为菲勒斯等同于阳具。

不过女性主义者 Luce Irigaray 认为，尽管 Lacan 说菲勒斯并非阴茎，但他的整个理论结构依然再现了父权制中男性占主导、女性占从属位置的结构。

要理解 Irigaray 的论点，我们必须搞清楚什么是父权制。

什么是父权制？

父权制（Patriarchy）在最初的人类学和社会学用法中，指的是父亲、长男，或者男性群体控制的家庭或者部族。

在之后的女性主义理论中，它被重新定义为社会制度。其最广泛接受的定义来自英国女性主义社会学家 Sylvia Walby：

a system of social structures and practices in which men dominate, oppress and exploit women.
一个社会结构和实践的体系，在这个体系中，男性支配、压迫和剥削女性。

该定义的关键要素在于：

父权制不等于某个男人歧视某个女人，而是嵌入在社会结构中的系统性安排
父权制是结构性的、建立在社会制度中
父权制同时包含私人和公共的形式

或者更广义的表述：女性主义学术理解中的父权制是一个将男性作为群体建构为优于女性作为群体的体系。

必须要搞明白的是，父权制不等同于男性！

bell hooks 在《理解父权制》中给出了非常重要的定义：

Patriarchy is a political-social system that insists that males are inherently dominating, superior to everything and everyone deemed weak, especially females, and endowed with the right to dominate and rule over the weak and to maintain that dominance through various forms of psychological terrorism and violence.
父权制是一种政治社会制度，它坚持认为男性天生具有支配地位，优于任何被视为弱势的事物和人（尤其是女性），并被赋予支配和统治弱者的权利，且通过各种形式的心理恐怖和暴力来维持这种统治地位。

bell hooks 指出，父权制实际上没有性别。 它不仅仅描述男性的支配行为，也描述某些组织和文化叙事如何运作。这意味着批评父权制并不等同于批评男性。父权制是一套制度安排，男性和女性都可以参与再生产它，也都可以受到它的伤害。

是的，父权制表面上回报男性，实际上也囚禁和损害他们⸺它要求男性压抑情感、遵守角色规范，并导致心理上的痛苦。

Sylvia Walby 在《理论化父权制》中提出父权制会通过六种相互关联的结构来运作：

结构	运作方式	简明解释
有偿劳动	职场中的性别隔离、工资差距、玻璃天花板	女性在劳动力市场中处于结构性劣势
家庭生产	女性的家务劳动被无偿占有	女性在家庭中的劳动不被视为劳动，无报酬、无社会保障
文化	媒体、教育、宗教中的性别规范	温柔、顺从、以家庭为重的「理想女性」形象
性	对女性性行为的规训和控制	荡妇和处女的双重标准、对女性性自主的压制
暴力	针对女性的系统性暴力及其被正常化	家庭暴力、性骚扰被「私事化」，不受严肃对待
国家	法律和制度中的性别偏见	婚姻法、生育政策、社会保障制度中嵌入的性别不平等

Walby 强调这六种结构是部分相互依存的：它们可以相对独立地变化，但共同构成了父权制的整体运作。

她还指出，不同阶级、种族和性取向的女性以不同方式经历这些结构。

王无在公众号文章中便主要触及到 Walby 框架中的「文化」，及文化叙事如何建构「理想女性」形象。而同时提到的「劳动的无偿占有」触及到了家庭生产。

不同流派对父权制的看法

尽管父权制是所有女性主义流派的核心分析对象，但不同流派对它的根源诊断和变革路径有根本分歧：

一、激进女性主义认为父权制是最古老的压迫体系，因为性别不平等源于自然生殖差异⸺女性怀孕生育，男性不生育⸺这种生物学差异构成了最早的性阶级系统，它先于且比任何其他形式的压迫⸺如阶级、种族⸺都更深远。

《性辩证法》的作者 Shulamith Firestone 主张要彻底消除父权制，就必须用人工生殖技术取代自然生殖，以此来让女性从生育的生物学负担中解放出来。

她也将马克思主义的辩证方法应用于性别：正如马克思主义认为阶级压迫根源于生产资料的所有权，Firestone 认为性别压迫根源于生殖资料的不平等分配。

Kate Millett 在《性政治》中提出：

This is so because our society, like all other historical civilisations, is a patriarchy. The fact is evident at once if one recalls that the military, industry, technology, universities, science, political office, and finance—in short, every avenue of power within the society, including the coercive force of the police—is entirely in male hands.
这是因为我们的社会与所有其他历史文明一样，都是父权制社会。
只要回想一下，军队、工业、技术、大学、科学、政治职位和金融⸺简而言之，社会中权力的每一条途径，包括警察的强制力量⸺完全掌握在男性手中，这一事实便显而易见。
Sexual politics obtains consent through the 'socialisation' of both sexes to basic patriarchal polities with regard to temperament, role, and status. As to status, a pervasive assent to the prejudice of male superiority guarantees superior status in the male, inferior in the female.
性政治通过使两性在性格、角色和地位方面「社会化」于基本的父权政体来获得认同。就地位而言，对男性优越偏见的普遍赞同，保证了男性的优越地位和女性的低劣地位。

父权制是一套使男性对女性拥有权力的社会安排，其根源不仅在于生物学，更在于社会化过程和意识形态：社会通过教育、文化、宗教等途径将男尊女卑的观念内化为「自然」。

二、上野千鹤子在《父权制与资本主义》中给出了马克思主义女性主义对父权制的定义：

女性の抑圧には物質的な基礎がある。それは、家事労働という不払い労働の家長男性による領有と、したがって女性の労働からの自己疎外という事実である。家父長制は、この労働の性別原理によって利益を得ているから、既婚女性は、階級のちがいを超えて「女性階級 women class」を形成する
女性受压迫有着物质基础。这一基础在于家父长制男性对家务劳动这一无偿劳动的占有，以及由此导致的女性与其劳动成果的自我异化。由于家父长制从这种劳动性别分工原则中获益，因此已婚女性跨越了阶级差异，构成了「女性阶级」。

上野的核心论点是：

在近代社会中，女性同时受到资本主义支配的市场和父权制支配的家庭的双重压迫
马克思主义女性主义最大的贡献是发现了家务劳动这一概念。上野提出「无酬家务劳动」，指出女性在家庭中付出的劳动被无偿占有，这是父权制的物质基础
父权制和资本主义是两个独立但相互交织的体系。因此不能将父权制简单还原为资本主义的副产品，也不能将资本主义还原为父权制的副产品

Silvia Federici 在《卡利班与女巫》中从历史角度补充了这一分析。她追溯了欧洲从封建制向资本主义过渡期间，女性身体如何被规训。

例如猎巫运动不仅是宗教狂热，更是一场将女性的生殖能力和劳动能力纳入资本主义和父权制控制的社会工程。

三、自由女性主义不追求彻底重构社会，而是将父权制理解为具体的法律和制度障碍，如选举权缺失、职场歧视、财产权不平等。变革路径是通过法律和政治改革逐一消除这些障碍。

在这个框架中，「父权制」更多被分解为一系列可以被逐项解决的具体问题，而非一个需要被整体推翻的结构。

四、Kimberlé Crenshaw 提出了交叉性女性主义，并指出黑人女性同时经历种族压迫和性别压迫，而这种交叉体验大于种族主义和性别主义的简单总和。

这意味着：不能将父权制理解为一个独立于种族、阶级、性取向等其他权力轴的纯粹性别压迫 —— 父权制的具体运作方式因其他身份维度而异。

父权制能否被终结？

Gerda Lerner 在《父权的建立》中做了对整个概念具有奠基性意义的论证：父权制不是「自然的」或「生物学的」，而是历史地建构的 —— 因此它也可以被历史过程终结。

Lerner 考察了古代近东（美索不达米亚）文明的历史、考古和文学证据，提出父权制作为一套社会组织方式是在公元前第二千纪的早期国家形成过程中逐步建立的。她论证的关键步骤包括：

父权制有一个起点。它不是人类社会的原始状态，而是在特定历史条件下被建构出来的
父权制的建立是一个过程：女性在早期农业社会中实际上享有相对平等的地位，但在后来被逐步剥夺了经济独立、性自主，以及政治参与权
父权制一旦建立就会自我再生产。它通过法律、宗教、文化将自身「自然化」，使后代将其视为「从来如此」的自然秩序，而非历史地建构的权力安排

Lerner 还提出了很重要的洞见：父权制能够给予底层男性补偿性的特权。即使在阶级上处于底层的男性，也通过性别等级获得了一种相对于女性的优越地位。这种机制使得底层男性有动机维护父权制，因为这是他们唯一能享有的支配地位。

父权制是有意识的阴谋吗？

理解父权制的一大关键点在于，它并非有意识的阴谋。 它运作起来往往是看不到的，参与者也不需要知道自己在参与父权制。

父权制的自我再生产通过以下机制运作：

父权制嵌入在法律、教育、就业、家庭等制度中，通过这些制度的日常运作来再生产自身⸺这不需要任何人策划
父权制通过文化叙事将自身的规则呈现为「自然」⸺也是我这个月初经常提到的意识形态自然化
个体在认同「理想女性」或「理想男性」形象的过程中，内化了父权制的性别规范，并将其视为自己的「自然」身份
父权制给予所有男性一种基于性别的地位优势，即使他们在其他维度⸺如阶级、种族⸺上处于劣势。这使得男性有动机维护这个体系，即使它也伤害他们

Irigaray 对 Lacan 的批判

现在我们可以回到先前搁置的问题：为什么 Irigaray 认为 Lacan 的理论结构再现了父权制？

她的核心论点可以概括成以下几条：

一、Lacan 的象征界域是父权制的理论翻版。

Lacan 虽然说菲勒斯不是阴茎，但他的整个理论结构都再现了父权制中男性占主导、女性占从属位置的结构。

Lacan 将菲勒斯与阴茎做了概念区分，但是该区别在实践中几乎不生效：菲勒斯作为中心能指的功能，与父权制中阴茎或者男性作为中心的社会功能，在结构上同构。

二、女性被排除在象征界域之外。

如果整个象征界域都是以菲勒斯作为中心组织的，那么女性只能通过「与菲勒斯的关系」来获得位置。她没有独立于菲勒斯之外的象征存在。

Lacan 的象征界域依然是父权主导的，没有为女性自我定义提供空间。

三、女性性特征被还原为「非一」。

Irigaray 在《此性非一》（This Sex Which Is Not One）中指出，在阳具中心主义的框架中，女性性特质被定义为「非男性」，即作为缺失、被动、「不是一」，而非有其自身的正面规定。女性的身体经验无法在菲勒斯中心的语言中得到表达。

四、Lacan 曾说过 La Femme n'existe pas（「女人不存在」），意思是在象征界域中没有「作为整体的女人」这一能指。

Irigaray 认为阳具中心主义下，女性作为独立主体「不存在」了，她只能作为男性的镜像和缺失来获得位置。

Irigaray 的批判对我们理解王无的文章有直接意义。Lacan 的框架本身就是以菲勒斯为中心的框架，用它来分析性别叙事，意味着揭示父权制的工具可能自身也携带着父权制的烙印。

但 Lacan 就完全不可用么？那也不然。Lacan 提出的许多概念仍然可以帮助我们理解父权制是如何通过语言和文化叙事而运作的。我们需要记住：批判工具本身从来都不是中立的。

回到对公众号文章的解析

说了这么一大堆，我终于可以开始解析该文章了！

意识形态的自然化

王无在文中执行了 Louis Althusser 式的意识形态分析，以揭示一个看似自然而然的文化产品是如何作为意识形态装置运作的。

说 Althusser 可能有读者朋友们会摸不到头脑，其实他的框架很好理解：

一、一个文本不仅有它说出来的东西，还有它没有说出来的东西。

二、国家机器有两种：镇压性国家机器和意识形态国家机器。

现代社会维持阶级统治的主要力量是意识形态，尤其重要的是教育系统，因为它能够内化学生对社会秩序的服从、对权威的尊重、对劳动纪律的适应

三、召唤描述了意识形态如何将个体构成为主体。设有人在街上行走，有人在背后大喊「喂！」，那个人转过头来⸺这个转头的动作就是「召唤」：个体在回应互换的过程中承认了自己被召唤的身份，从而被构成为一个服从于权威、认同自身社会位置的主体。

Althusser 认为，意识形态总是已经召唤了个体。个体从出生前就被家庭、语言、文化召唤了。

他否认「先有一个主体，然后主体接受或拒绝意识形态」，而认为「意识形态召唤出了主体，主体在回应召唤的过程中才成为主体」。这与 Lacan 的「语言构成主体」极其相似。

当个体将文化观念当作「理所当然」、「显而易见」来接受时，意识形态的效果最强。Althusser 认为，意识形态运作最好的时候，就是人们感觉不到自己在意识形态中的时候。

文章结尾王无写道：

在每一次对牛郎织女的故事的讲述的背后，都有一个父权制的形象指着这样的织女，对所有的女人说⸺你们看，好的女人就应该是这个样子，都给我们学起来。

这段话的学术含义是，故事通过建构「理想女性」的能指⸺织女等同于顺从、忠贞、无怨无悔的爱人⸺对女性读者执行了意识形态召唤。

读者在认同织女「美好爱情」叙事的过程中，不知不觉地内化了父权制的性别规范，即女性应顺从、应将客体化，误认为成是浪漫。

Lacan 的能指分析应用

王无所使用的分析工具来自于 Lacan，具体来说是象征界域的能指分析：

「羽衣」被解读为织女「自由意志和主体力量的终极能指」
「偷衣」被解读为「对女性自由的符号性圈禁」，即通过剥夺能指来控制主体在象征界域中的位置
「老牛」被解读为「菲勒斯（阳具）」，即象征界域中组织欲望的中心能指⸺「能指」（signifier）指的是符号的形式。符号的另一层面是「所值」（signified），即符号所代表的心理概念
「牛郎」被解读为「父权制下所有男性的理想自我投射」，即想象界域中的镜像认同对象

这些操作在 Lacan 框架内是有逻辑可循的。Lacan 的精神分析确实是关于能指如何组织主体关系的理论。

那么能不能用 Lacan 分析民间故事？答案是完全可以。但是文章在具体执行中违反了 Lacan 理论自身的若干原则。之后会逐一分析。

Swan Maiden 母题

王无提到羽衣承担了身份标记和行动能力的功能：有羽衣的织女是天界的自由主体；没有羽衣的织女是被困人间的凡人妻子。剥夺羽衣象征着剥夺织女在象征界域中的位置，将她从「主体」降格为「客体」。

民俗学研究里有个在全球民间故事中都出现频繁甚至结构相同的母题，叫作 Swan Maiden（天鹅少女）。该母题讲述男子与超自然的女性生物订立契约或者结婚，随后后者会离开。变形时，她们往往会变成鸟类，或者使用羽毛披风。

在典型的故事中，少女会在水域中⸺通常在洗浴⸺而男子会过来偷走、隐藏或者焚烧她的羽毛衣服，使她无法飞走或游走，迫使她成为他的妻子。她也通常是多位少女中的一位，且往往是最小的那位。

只是这么说，读者朋友们的脑海中有没有浮现出许多童话或者民间故事呢？更重要的是，牛郎织女的传说也沿用了该母题。王无对羽衣的符号学解读，也是对该跨文化母题的合理分析。

公众号文章的政治立场

再是王无的政治立场最接近激进女性主义，即将父权制视为故事的根本动力，将性别支配关系⸺而非阶级、经济或其他因素⸺作为首要分析维度。同时，王无关于「劳动无偿占有」的论述也调用了社会主义女性主义的资源⸺如上野千鹤子的「无酬家务劳动」概念。

在这个定位下，王无的目标不是中立地理解故事，而是揭示故事在性别权力结构中的意识形态功能。这个目标本身是合法的⸺批判理论从来不是中立的，它的立场性是其方法论的一部分。

法兰克福学派的创始人兼批判理论之父 Max Horkheimer 在 1937 年的《哲学与批判理论》中写道：

……critical theory is nowhere interested solely in the accumulation of knowledge as such and for its own sake, but everywhere in the emancipation of human beings from enslaving social relations.
…… 批判理论从不单纯为了知识本身而积累知识，而是处处致力于人类从奴役性社会关系中的解放。

传统理论满足于正确地描述世界，但描述本身隐含了意识形态效果，因为你将社会现状当成了事实、默认了现状的合法性。

例如奴隶社会的社会学家精确地描述了奴隶制的运作方式，但从不质疑奴隶制本身的合法性，那么他的解释尽管在技术上是正确的，但在政治上是在间接为奴隶制提供合法性，因为奴隶制成为了客观事实而不是可被推翻的不正义。

批判理论不仅要正确地描述社会，还要揭示社会结构如何压迫人、这种压迫如何被掩盖，以及这种压迫如何可以被克服。

但立场性不等于可以跳过论证。批判理论的立场性意味着它有明确的解放目标，但不意味着它可以以结论代论证。它仍然需要在逻辑和证据上经得起检验。

公众号文章的问题所在

父权制没有意识

王无认为传说版本的演变是「精心策划的、系统性传播的符号篡位」，使用了阴谋论式的因果模型，以暗示存在一个有意识、有预谋的「篡位」行为。

这与父权制的实际运作机制相矛盾。

如我们在先前的条目中所分析的，父权制一旦建立就自我再生产、不需要有意识的策划者。

再是王无自己提出了「符号达尔文主义」⸺即自然选择式的淘汰⸺这个隐喻，但紧接着又说「精心策划的符号篡位」，这两个隐喻在逻辑上是矛盾的：达尔文主义的自然选择不存在策划者，有策划者的篡位也不是达尔文主义。

在多个版本的竞争性流传中，那个更好地服务于父权制再生产的版本（偷衣版）获得了更多的传播动力，因为它的叙事结构更好地满足了古代男性群体的欲望投射，同时更有效地将不平等关系浪漫化。这实际上是结构性筛选，而非策划性篡位。

Lacan 的能指分析要求差异

王无认为故事中的「老牛」意味是牛郎的阳具，证据是方言俚语。

第一个问题在于方言俚语能否直接等同于普遍符号功能？这一说法属于过度诠释。

第二个问题在于能否用阴茎的联想来论证菲勒斯的存在？

原文是这么写的：

那耕牛则是牛郎的阳具（牛和牛子在很多方言里指代男性生殖器），是一个被僵死的异化的权力秩序所制造的享乐工具，一个菲勒斯去介入和征服女人客体的英雄。

论证是从阴茎出发，再推导出老牛等于菲勒斯的。

菲勒斯属于象征界域的能指，而阴茎的俚语联想来源于想象界域的形象。在 Lacan 的理论中，这是错误的，因为本该分析象征结构的地方却退回到了形象联想。

如果正确地来做这个分析，我们应该问自己，老牛在故事中承担了什么象征功能？答案是老牛是牛郎获取织女的中介，因为它告知牛郎去偷衣，也是它死后让牛郎披皮上天追赶。它是牛郎从凡人世界进入天界⸺象征界域中「高位」的领域⸺的通道。这个功能确实可以被分析为一种象征性的权力授予，但它的准确性质是「跨越界限的中介」，甚至说更接近于「父亲之名」，而非「菲勒斯」。

如果任何叙事中的雄性动物都可以因为方言联想而被解读为「菲勒斯」，那么这个解读就没有区分度，因为它无法解释为什么这个故事中的这头牛具有特殊的象征功能，而不是一切故事中的一切雄性动物（或者说「牛」）都是菲勒斯。Lacan 的能指分析要求能指之间有差异化的定位。

「强奸」到底是什么？

王无在文中写道：

…… 牛郎单方面发起的、针对织女的初始性暴力（偷窥、盗窃、强奸、囚禁）。
…… 织女，不止要被强奸，生娃，监禁，给男人无偿劳作，更有意思的就是她还要真心实意地爱上牛郎，真心实意地和牛郎鹊桥相会，就像一个器物一样忠诚到别无二心

王无调用了激进女性主义中一个特定的理论传统，即胁迫下的同意不是真正的同意。该原则有学术渊源：在性别权力不对等的结构性条件下，女性的「同意」可能是被胁迫的产物，因为她在不平等的结构中缺乏真正的拒绝能力。

当代法律中也有体现该原则的地方，如婚内强奸的确立基于「婚姻关系中的同意不能被自动推定」这一法理。

如果王无做的是这样的论证：「在织女的人身自由被剥夺的结构性条件下，她与牛郎的结合即使有『同意』的外观，这种同意也是在胁迫条件下产生的，因此不构成真正的同意」⸺那这将是一个在激进女性主义法理框架内合法的论证。

但王无没有做这个论证，直接将「强奸」作为不加界定的标签使用，没有说明是什么法律和伦理框架下使用的「强奸」一词、整个因果链内哪一步构成了「强奸」、织女在故事中是否有任何拒绝的空间⸺先前提到，因为故事版本的不同，也存在着织女有拒绝空间的版本。不过这一点我认为问题出在确立讨论的是哪个版本的牛郎织女传说，也是之后会深究的话题。

「强奸」这个概念本身需要被区分成描述性使用和规范性使用。王无同时将其用作对故事事件的描述，也用于批判故事的意识形态功能。这两种用法需要不同的论证来支撑，但在公众号文章中被混为一谈。

女人是男人的幻想工具人吗？

王无说「织女从根本上就只是一个被男性凝视结构出来的，用以满足古代农村反动男性的欲望在父权建制的奴役下产生的幻想的工具人而已」，并引用了 Lacan 所说的「女人是男人的症状」。

Lacan 这句话出自于第二十期研讨班的《再来一次》，原文是：

On dit que les femmes sont les symptômes des hommes
据说女人是男人的症状

关键点分别在于：

「据说」意味着 Lacan 在引述一种观点。该命题的语气是反思性而非肯定性的
在 Lacan 晚期理论中，「症状」⸺也叫「病症」（sinthome）⸺指的是主体发明用来维系三个界域结构的独特方式。作为例子，詹姆斯・乔伊斯的写作就是他的「病症」，因为通过写作他能维系三个界域之间的联结。症状不是幻想的工具
「女人是男人的症状」的准确含义是，男性的主体性依赖于他与女性关系所构成的症状性结构来维系。换句话说，不是「女人是男人的工具」，而是「男人的主体性是通过与女人的关系来组织的」⸺这个关系本身就是他的「症状」，是他存在的方式

因此我得出，王无错将 Lacan 的这句话理解为「女人是男人欲望投射的幻想工具人」，而这将 Lacan 的命题从关于主体结构的分析降格成了关于工具化的描述。

王无引用 Lacan 是为了给「织女是工具人」这一判断提供权威的支持，不过 Lacan 的命题并不能做到这一点。既然男性的主体性依赖于女性，那么其实隐含的是「男性不能没有女性」，而非「女性只是男性的工具」。

如果女性是男性的「症状」，即男性存在的结构性支撑，那么女性就绝非只是工具那么简单，而是男性主体性构成的必要条件。

我建议引入先前提到的 Irigaray 的视角：她批判 Lacan 的象征界域以菲勒斯为中心组织、排除了女性的独立主体性，因为该框架没能为女性的自我定义提供空间，即女性只能通过与菲勒斯的关系来获得位置。

循环论证问题

王无提到织女提供的爱是象征性暴政。这一部分我是非常认可的。

意识形态最有效的运作不是强迫，而是让人们资源认同支配结构。如前所述，意识形态通过「召唤」让个体在认同中内化规范。换到牛郎织女传说中，织女不仅被迫服从，还被要求、并在叙事中被呈现为真心爱上这个服从。

法兰克福学派的 Marcuse 在《单向度的人》中提出，发达工业社会通过制造虚假的需求来让人们自愿参与自身的压迫。人们以为自己想要的东西，实际上是体制植入的。织女以为自己爱牛郎，但这种爱可能是父权结构植入的虚假意识。

Hegel 的主奴辩证法（Lord-Bondsman dialectic）中也提到，承认应该是两个独立主体之间的相互确认。王无认为，牛郎追求的不是织女作为平等主体的承认，而是对已归顺的客体的拥有感。

该命题有需要审慎对待的维度：叙事中织女的爱究竟是被迫的，还是自发的？如果一律将织女表现出的爱视为被迫的虚假意识，就会陷入循环论证中：先假定织女没有主体性，所以凡是看起来像主体性的行为都证明她被更深地被欺骗了，因此证实她没有主体性。

故事将一段起源于暴力的关系呈现为爱⸺这个叙事操作本身就是意识形态的运作，无论织女在故事内部是否真的爱牛郎。它教导读者「起源于暴力的关系可以或者应该被体验为爱」。问题不在于织女的爱是真是假，因为这在叙事内部是无法被判定的，而在于叙事抹平了暴力起源与爱的体验之间的矛盾。这才是「爱作为象征性暴政」的准确含义。

深度展开循环论证

循环论证会导致命题不可证伪。现在我想要深度谈谈批判理论传统中已知的一问题：虚假意识概念的自指悖论。

如果意识形态使得被支配者无法认识到自己的被支配状态，即她们处于虚假的意识中，那么任何被支配者表现出的「满意」、「认同」、「爱」都可以被解释为虚假意识的症状。

那么，什么证据能够证伪「她处于虚假意识中」这一判断？如果她表达不满，这证明她被压迫；如果她表达满意，这证明她被更深地压迫。在这种结构中，没有任何经验证据能够推翻「她被压迫」的判断⸺因此这判断不可证伪。

这不是公众号文章独有的问题，而是意识形态批判传统中、法兰克福学派内部长期有着争论的结构性困境。

如 Habermas 曾批评早期法兰克福学派的意识形态批判陷入了彻底批判的悖论，即如果一切意识都是意识形态，那么批判者自身的批评意识也是意识形态，批判不就失去了立足点？

Althusser 则试图通过「科学」和「意识形态」的认识论断裂来解决这个问题，但这个方案被批评为将批评者置于不可批判的「科学」位置上。

公众号文章没有意识到该困境。文章无意识地使用了「虚假意识」的逻辑，但没有反思这个操作的认识论后果。如果文章要避免循环论证，它需要提供一个判定虚假意识的标准，即在什么条件下可以区分「真正的认同」和「虚假意识下的认同」。文章没有提供这个标准。

但文章只是个公众号文章而已，不是学术论文⸺我这篇文章也不是学术论文。要求我们解决法兰克福学派内部数十年的认识论争论是不现实的。我仅是指出公众号文章所处理论传统的结构性限制，而非王无本人的失误。这一点一定要清楚。

谁被献祭给了什么？

王无提出鹊桥等同于符号性献祭的观点，其叙事功能在于「弥合初始暴力与强制团圆之间的巨大矛盾」。

我认可该观察。鹊桥确实在情感层面弥合了这样的裂缝，用浪漫的意象覆盖暴力的起源。

不过鹊桥作为符号性献祭，但到底是谁被献祭给了什么？如果说织女被献祭，那么是被献祭给了什么？父权制？叙事的完整性？读者的情感满足？它作为分析概念实在过于模糊。

我的分析是，鹊桥在叙事中的功能是仪式化。它将一段起源于暴力的关系通过年度仪式转化为永恒的爱情象征。仪式的功能正是将偶然的、暴力的起源自然化和永恒化，也就是通过每年重复的鹊桥相会、将「本来如此」替代「最初如此」。

在这个意义上，鹊桥就可以被分析成意识形态的仪式装置了。

王母娘娘是解救者吗？

王无认为故事中的「反派」王母娘娘解救了织女。

在 Lacan - Althusser 的框架中，象征界域会通过意识形态国家机器来再生产自身，那么王母娘娘在故事中的功能是象征秩序的执法者。

在 Lacan 自己的框架中，她扮演的是接近「父亲之名」的位置，目的在于将违反法则的主体重新归位。这与王无在其他地方的分析框架是一致的：父权制等于象征秩序，象征秩序通过法则来规训主体。

不过王母娘娘是解救者吗？如果父权制是象征秩序，而王母是象征秩序的执法者，那这是否意味着王母也是父权制的代表？她将织女带回天界是为了恢复象征秩序的规则，且天界秩序本身也是等级化的。

整个故事中没有任何角色在维护女性的主体性⸺这是个非常重要的观察。牛郎的偷衣是父权制的私人形式，即男性个体对女性个体的支配；王母的干涉是父权制的公共形式，即制度对个体关系的规训。两者都是父权制的运作，只是层面不同。

因此我们无法从王母那儿找到反父权的力量。

大他者是抽象的

王无说：

当所有的一切都要归属于这个作为偷窥者，监禁者，强暴者和绝对统治者的牛郎，那个代表应该在爱情伦理中牺牲一切的肉体，心灵，子宫和劳动力的织女也就差异性地被大他者指认出来。

这里的「大他者」概念被错误使用了。

先前说过，大他者是象征界域本身的拟人化，不是任何具体的人或者机构。它是语言、法律、文化秩序的抽象「他者」。我也说过，主体在语言中被构成，意味着主体是从属于大他者、是被语言所塑造的。

但王无将大他者理解成父权制的幕后操盘手，就好像有具体的人或者机构在指认织女应该牺牲一切。这错误地将大他者实体化了。王无想要使用的概念更接近通俗意义上的社会压力，还有父权制的代言人。

同样的事情也发生在「享乐」一词上。Lacan 的「享乐」（jouissance）是高度技术性概念，是超越快乐原则、痛苦与快感交织的体验，是主体在突破象征界域时体验到的溢出。

不过文章将「享乐」用作接近「性享受」的通俗含义。

公众号文章的修辞

和我进行讨论的博友在阅读公众号文章后，第一反应是震撼于全篇极具情绪偏向的词汇⸺我的判断在于它是首先被提及到的，所以它最重要、是第一印象⸺所以我想要分析分析文章的修辞。

王无的词汇滑移链条是这个样子的：

父权欲望 → 男性凝视 → 客体化 → 符号性圈禁 → 偷窥 → 盗窃 → 强奸 → 囚禁 → 性剥削 → 子宫剥夺 → 无偿劳动

前半段⸺从父权欲望到符号性圈禁⸺是学术概念。它们有明确的理论定义，属于批判理论和精神分析的专业术语。

后半段⸺从偷窥到囚禁⸺是法律概念。它们有明确的法律定义，指涉具体的犯罪行为。

王无的修辞策略在于，通过将学术概念和法律概念放在同一条链条中，制造一种从理论分析到法律指控的过渡，让读者在后半段里不知不觉就接受法律指控的框架。

该策略的修辞效果极强，因为它可以让读者觉得「强奸」、「囚禁」等指控是从学术分析中自然推导出来的，还不需要独立论证。不过在分析层面，「没有独立论证」是个问题：学术概念和法律概念属于不同的范畴。从前者推出后者需要范畴转换的论证，例如在什么条件下象征层面的圈禁等同于法律层面的囚禁？

对主要反对意见的回应

接着是我对博友的观点的回应。这里包括我原本就回应的内容、我想了想后自行补充的内容。

故事传颂是因为人民群众的美好愿望

但是这是谁的美好愿望？在古代社会中，男性和女性的愿望是否一致？

美好愿望的具体内容是什么？是对跨越阶层的浪漫爱情的向往？还是对勤劳农夫获得仙女青睐的代入式满足？

为什么「美好愿望」会筛选出「偷衣、强留」这个特定版本，而不是其他同样可以承载「美好愿望」的版本？比如早期隔河相望的版本不就很美好吗？

「美好愿望」和「父权意识形态筛选」完全可以同时成立。一个故事之所以流传，可能既因为它满足了人们的情感需求（美好愿望），也因为它在无意中再生产了特定的权力关系（意识形态效果）。

父权制的运作通过满足人们的「美好愿望」来实现。这一点先前已经说过，意识形态最有效的运作方式不是强迫，而是让人们自愿地认同和传播它。

如果父权意识形态筛选版本，更应该筛选出「天帝安排」版本

天帝安排织女嫁给牛郎、织女荒废纺织被惩罚的版本更符合父权的「掌控」还有「支配权」，但该版本没有成为流传最广的版本，因此博友认为「父权筛选」论不成立。

该反诘的前提假设在于，父权制偏好最直白的支配叙事。但事实是否如此？

天帝安排版确实具备父权制里服从安排、不可荒废职责的特质，不过它缺乏浪漫化的空间，无法激发情感认同。

尽管偷衣版包含了暴力元素在内，但可以被包装为穷小子用计谋赢得仙女芳心的浪漫故事，也就有了更强的情感动员力。

父权制的筛选不一定偏好最直白的支配叙事，而可能偏好最能有效遮蔽自身暴力性的叙事，即那种将不平等关系包装为浪漫爱情的叙事。

另一点在于，父权制不等同于统治阶级权威。天帝安排版中的支配是等级性的，即天神大于人类，而偷衣版中的支配是性别性的，即男性大于女性。

流传最广的版本是温和的，即牛郎归还了衣服、织女自愿留下，不存在偷窥和胁迫

这一点先前已经提到，有学者统计发现民间流传的主流版本是不归还衣服、胁迫成婚的版本。

实际上，先前我就说明过讨论范畴是「偷衣版」。

牛郎织女更接近一种得不到的粉色幻想，即性转版的「霸道总裁爱上平凡的我」

两者确实共享核心结构，不过该论点存在两个问题：

自相矛盾。「霸道总裁」模式本身在女性主义批评中受到过类似的批判：承载不平等的权力关系、浪漫化控制欲。如果承认了牛郎织女传说是性转版的霸道总裁，那也就承认了故事中有着不平等权力关系的幻想
忽略关键差异。霸道总裁故事中的女主角通常保有人身自由、拒绝权和精神独立性，但偷衣版里的织女是因羽衣被窃而丧失了离开的能力

古代爱情故事基本都是见色起意、一见钟情，不会展现魅力来获取认同

中国古代民间传说确实以一见钟情为主要的情感模式，不过我在意的是故事实现结合的手段是什么。

即使是一见钟情，不同的故事赋予男性角色的手段仍然不同。

如果把牛郎织女理解为胁迫，那所有屈从现实婚姻的女性都算被胁迫

这是错误类比，存在着根本性的结构差异。

对方的推论准确来说是「如果无法嫁给理想对象而嫁给不理想对象算胁迫，那所有现实中的不理想婚姻都是胁迫」。

但现实中嫁给不满意丈夫的女性，通常保有人身自由。她可以拒绝、离婚、离开，尽管现实中经济和社会压力会使这些选择困难，但在法律上她是自由的。

但偷衣版中的织女在叙事起点就丧失了离开的物理能力。她的选择是在自由已被剥夺的条件下做出的。

「在自由条件下因现实压力而做出不理想选择」能等同于「在自由被暴力剥夺条件下做出的选择」么？两者在伦理和法律上都有着本质的区别。

例如现代法律中，在绑架条件下发生的婚姻会被视为无效，即使被害人表现出同意，因为同意的前提是自由。

激进女权会把很多本与男权女权无关的事情，附会到性别压迫上去

作为一般性判断，我认同。我在深度分析中就点出过王无的「牛等于菲勒斯」是过度诠释。

不过偷衣版的牛郎织女故事是否属于「本与性别权力无关的事情」？

这个故事的核心情节是：男性通过窃取女性的身份凭证（羽衣）来剥夺她的行动自由，迫使她留在人间与之成婚。这个情节本身就涉及性别权力关系。

Swan Maiden 母题的跨文化普遍性更进一步证实了这一点：全世界多个文化都独立产生了这样的叙事，意味着存在某种深层共享的社会心理结构。

激进女权只有标签没有分析

该批评有着有效的内核。王无的文章确实停留在文化叙事层面的批判，没有将叙事分析与具体的社会制度联系起来⸺例如婚姻法中的财产分配、家务劳动的法律地位、职场性别歧视的具体规则。

不过博友说的「言之无物」实在是太绝对，因为王无的分析聚焦于文化叙事的符号学层面，属于特定层面的分析。你可以说他不够全面，但不能说「无物」。

博友也认为激进女权讲到的永远只有性剥削和劳动剥削这一套⸺实际上并非如此，激进女性主义会涉及到大量具体的制度分析，并非简单、反复出现的空洞话术。

王无没有指出哪些具体的现有社会规则

该要求部分合理但标准过高。王无做的是意识形态批判，功能是揭示文化叙事如何在无意识层面再生产权力关系，而不是指出某条具体法律有问题。

我将王无的文章划分成文艺批评和文化现象分析，其功能是解构经典、揭示文本背后的隐蔽观念。它不承担提出社会学意义上社会现实问题解决方案的义务。发现并剖析问题本身就有独立的价值。

作为例子，鲁迅的《狂人日记》没有提出解决「吃人」文化的方案，但他的批判是无效的吗？自然不是。

当然，如果将文化叙事的意识形态分析与具体社会制度联系起来，是最好的，但我们无法要求他人写文都这么写。

激进女权认为只有全女性世界才没有剥削

这是稻草人谬误：「全女世界」不是王无的主张，也不是激进女权的主流主张⸺关于激进女权主义，之后会有更详细的说明⸺更不是我的主张。

批评父权制不意味着想要母权制，也同样不意味着批评男性。但是该认知难以让大众理解，最终大家都陷入男女对立的情绪，还有部落主义当中。

激进女权的支持者是不工作、靠男性养活的女性

这是无依据的人格攻击，同时包含着内部逻辑矛盾。

从社会学常识来看，女权主义的参与者群体实际上跨越了多种社会经济背景，并非某一类人群的专利。

逻辑矛盾则是，如果这些女性躺着享受男性给予的好处，那她们不就是父权制的受益者么？为什么受益者反而最积极批判该体制？

更深层的问题是，一个人的解读是否正确，和他的就业状况相关吗？不相关。

经济独立的女性不会持有激进立场，因为她们能体验到真实的幸福

该论断包含多重逻辑跳跃：

经济独立与思想立场之间没有必然因果关系。大量有正式工作、经济独立的女性同样持有女权主义批判立场
「能看到幸福与美好」与「能进行结构性批判」之间不矛盾。一个人完全可以同时拥有幸福的个人生活和对社会结构的批判意识。批判不等于不幸福，接受同样不等于幸福
只有经济独立的女性才有资格批评⸺这一点与被批评的内容没有任何逻辑关联

再是 Lerner 的父权制分析中提到过补偿性特权。它不仅给予了所有男性基于性别的地位优势，也可以让部分女性在顺应体制中获得安全感。

但这不意味着体制本身是公正的。

所有传说都有多版本，不能都归因于父权筛选

这是滑坡谬误。

从「牛郎织女的版本演变可能涉及父权意识形态因素」推不出「所有传说的版本演变都由父权意识形态决定」。

不同故事涉及不同的权力关系。比如核心是性别关系的故事，父权意识形态的影响可能较大；核心不是性别关系的故事，影响就较小。

总之，该问题的答案无论如何都不影响牛郎织女的传说是被父权意识形态筛选出来的结论。

王无的解读方法缺乏区分度

该质疑方向正确，但未被展开。

它触及到的正是先前我提到的「虚假意识」概念的自指悖论。

如果我们能用王无的方法去解读其他民间故事，就能知道是否也能得出同样的「暗黑」结论了。

王无脱离实际，也没有解决方案，只是在占据道德制高点

这包含三个需要分开评估的子批评：

没有结合实际社会场景⸺部分有效。王无的文章是纯粹的文本、文化批评，没有锚定在具体社会场景中。但是文本批评本身也是合法的学术实践，也不是每篇文化批评都必须包含社会学经验研究
没有提出解决方案⸺标准过高。不能要求所有批判都同时是建设性的
占据道德制高点⸺动机揣测。这无法被证实也无法被证伪，而且即使王无确实从批判中获得道德优越感，也不构成对其论证有效性的反驳

以现代标准审判古代故事是不正当的

该方法论批评叫作时代错置（presentism，也可以叫 anachronism）。它是历史学和文学批评中真实且重要的方法论问题。

不过「必须了解时代与文化背景」这一原则，并不必然导致「因此不能以现代伦理审视古代叙事」这一结论。另一个学术实践叫作批判性重读（critical reinterpretation），其目标在于用今天的视角来看过去的故事，看出它传递了什么、遮蔽了什么。这两件事并不矛盾：

历史化的解读：在当时，这个故事意味着什么？
批判性重读：从今天看，这个故事的意识形态效果是什么？

如果用前者的标准要求后者，本身是范畴错置，除非能论证「批判性重读本身不合法」，否则「需要了解背景」这个原则不能推翻王无的方法论的合法性。

王无没有单纯在批判古人，而是将重点放在为什么现代人浪漫化了偷衣的版本，即当代的叙事实践。

攻击者本身也必然遭受反噬

该观察有着合理的内核：父权制框架内的对抗性话语实践确实可能对参与者造成心理伤害。

我将其提出，是因为它同样能够应用在反女权话语上，而它会在我讲完中文互联网的「激进女权主义」后再被提到。

相信爱情才能拥有爱情

作为个人生活哲学，这是成立的，但不能用作反驳王无的论据。王无通篇讨论的是爱情作为文化叙事是如何被建构和利用，但博友回应的是个人层面的爱情信念。两者在两个不同的层面。我们完全可以一边承认「相信爱情的人更可能拥有个人幸福」，同时仍然主张「关于爱情的主流文化叙事承载着意识形态功能」。两个命题并不矛盾。

我们之间的讨论已经发散，难以聚焦

最初博友对王无的观点的评价是「不值一驳」，但在我们讨论的最后承认了问题的复杂性，我认为这是非常值得肯定的！

批评一篇文章的最佳方式是指出具体推理中的错误，说其「不值一驳」虽表达了立场，但没有提供任何可供检验的论证。拒绝指出「槽点」会让读者无法判断博友是否有依据。

在与我的讨论中，博友实际上也逐条反驳了王无的多个论点，足以证明王无的文章并非「不值一驳」。

中文互联网的「激进女权主义」

在与那位博友沟通的期间，我意识到我必须说清楚我提到的「激进女性主义」同中文互联网上更广泛出现⸺主要出现在男女对立相关的讨论中⸺的「激进女性主义」，或更通俗的「女拳」，是两类不同的概念。

因为我们之间的讨论就我来看并不顺畅：对方先入为主了「女拳」的形象，拒绝承认牛郎织女传说中父权制的体现与影响，并更多将精力放在「为什么女拳有问题」这一话题上⸺这不是我想要讨论的重心。

实际上我同周遭的人讨论问题时，都会出现「因对方先入为主某观念，导致讨论难以进行下去」，尤其是在和中国人讨论女性主义相关话题时。

我在先前给出了激进女权主义的学术定义，而那和整个中文互联网反女权话语中所说的「激进女权」几乎没有关系。

根据 Yaya 的《中国网络女权二十年 —— 从边缘到焦点》的梳理，中文互联网语境中的「激进女权」（简称「激女」）是在 2016 年后才逐渐成形的网络亚文化群体，其特征与学术上的激进女性主义只有部分重叠。

中文互联网的「激女」：

主张与男性决裂、不婚不育、反对向下自由（如选择结婚）
理论资源中存在着较少的系统性理论，更多是碎片化的网络话语
主要以微博、豆瓣等平台作为阵地，并通过话语动员，也会进行以「挂人」、「开除女籍」为主的网络斗争
明确排斥跨性别
对于普通女性，会将不符合标准的普通女性斥为「婚驴」、「娇妻」、「服美役」

这是博友所反对的「激进女权主义」，而非 Firestone 或者 Millett 的理论体系。不过为了更准确明白对方所想象的「激进女权主义」，我得从他的文本中还原出具体的画像：

将一切社会问题归因为性别压迫，故此什么事都能上升到男女对立
以平权之名行性别优越之实⸺「不是要平权，而是要特权」
会解构一切传统文化，包括将牛郎织女这样的爱情故事「歪曲」为强奸叙事
将已婚女性、选择家庭的女性斥为「婚驴」和「娇妻」
将男性整体作为敌人，并制造性别敌意
不工作、靠男性养活

这是个被网络事件、流量经济，还有话语战争塑造出来的复合形象，不属于任何学术流派。

因为对方对「激进女权主义」的认知来源于在网络上的观察，且存在着「先入为主」的观念，那么他的归类逻辑就可以被解释清楚了：

王无使用了极端指控词汇，所以符合「什么事都上升到男女对立」的形象
王无将传统爱情故事解构为暴力叙事，所以符合「解构一切传统」的形象
王无引用 Lacan、阿尔都塞等理论框架，所以符合「用学术话语包装攻击」的形象

博友的归类是否是无中生有？我认为不至于，但确实过度泛化。

为什么会出现先入为主的观念？

果子狸是中文互联网「激女」话语成形过程中非常标志性的人物。据知乎上一篇对中国互联网女权运动的批判性分析文章记载：

这些人中，最典型的例子就是张岚（果子狸），在六年前她只是一名普通的家庭妇女，不幸的婚姻与不顺利的生活促使其走向网络，只有在网络、在集体运动中，她才能找到自我的归属，成为呼风唤雨的「女权」领袖。

文章中说果子狸是个在现实中受挫、在网络上通过集体运动找到身份认同的人物。尽管该文章本身带有强烈的批判立场，但依然客观地记录了重要的社会学现象，即中文互联网「激女」话语的领袖人物往往不是学院派学者，而是从个人困境走向网络动员的普通人。

这进一步意味着，中文互联网「激女」从诞生之初就带有强烈的个人创伤叙事，还有情感动员的色彩，而非学术辩论传统。这与学术上的激进女性主义有本质区别⸺如 Firestone 是在理论框架中论证生物辩证法，而非从个人遭遇出发发起运动。

根据 Yaya 的梳理，中文互联网性别对立的形成有清晰的时间线：

从 2011 年开始，女权向微博等社交媒体转移，并形成了二元对立格局
2015 年线下行动派女权被打压后，话语空间被更激进的线上派系填补
到 2016 年，互联网上便各处都是「激女」，这也导致反女权者的「先入为主」观念成形，因为他们所见到的「女权」只有「激女」
最后「女拳」成为了更广泛使用的贬称、「女权等于打拳等于制造对立」的等式被固化、男女对立持续极化再无中间地带、任何涉及性别分析的文章都会被预设为「激女」叙事。

杨雨柯的《激进的女权标签⸺女权主义如何在媒介平台被污名化》也提到，媒体通过突出女权主义者的激进情绪⸺如激动、抗议、反驳的描写⸺同时误读女权主义的思想内核，成功标签化且污名化了「女权」一词。

那么博友的「先入为主」是他个人的问题么？我不这么想。在中文互联网混迹的时间里我发现，这绝非个人偏见那么简单。

首先是先前提到的采样偏差，也就是因为互联网上都是「激女」，所以认为「女权」等同于「激女」。导致它的因素在于温和派和行动派已经在舆论空间中被边缘化、看不见了。

其次是流量经济有着放大效应：当代互联网「女权」运动的领袖⸺如营销号、微博大 V⸺往往不是最有理论深度的，而是最情绪化、最极端的，因为极端内容能够获得最多的流量。这也是流量算法的罪恶。

BBC 的报道中，女权活动人士吕频提出了这样的关键因素：

我们的政府的确从来都没说支持男权，但实际上中国本身是一个父权的政治，这些指责女权的人拥有的制度性支持永远比女权主义者要多…… （政府）不仅是他们拉的一个保护伞，而是他们本身就是天然的同盟，…… 现在很多人说女权是境外势力。他们的这种话术为什么会有效，因为他们完全复制和延伸了政府的话术。

反女权话语在中国互联网上拥有着结构性的优势，因为它获得了「维护社会稳定」、「反对境外势力」等官方话语的背书。

这使得「女权等于制造对立等于破坏稳定」的等式不仅仅是网络偏见，更是有制度性支持的话语框架。

抖个机灵：我人也在境外，会有人觉得我是拿了境外势力钱的激进女权主义者么？⸺好吧不开玩笑了。要是真有人这么想然后给我贴标签、引得完全不看文章的人复读标签并加深我身上的标签，我就笑不出来了。

最后是极化的话语环境中，任何尝试做细致区分的努力都会被两端同时拒绝。像是王无使用了激进女权的部分资源，但分析框架更接近意识形态批判而非激进女权政治，依然被博友认为是「激女」。

有时我们也能在互联网上看到「激女」认为温和派在和稀泥、「太爱男」⸺话语环境会惩罚每一个做区分的人！

关于「反噬」的命题

博友先前提到，激进女权的攻击行为会反过来伤害攻击者自身。

该命题包含三个要素：

攻击：博友将激进女权的话语实践定性为「攻击」，而非「批判」、「分析」、「表达」
反噬：攻击行为会产生回到攻击者自身的负面后果
单方面指向：该命题仅针对激进女权，不涉及反女权一方

bell hooks 的洞见⸺父权制表面上回报男性，实际上也囚禁和损害他们⸺可以系统地延伸到「反噬」命题。

父权制如何囚禁和损害男性

在 Feminism is for Everybody 和 The Will to Change 中，bell hooks 认为父权制要求男性：

压抑除了愤怒外的情感，因此男性不被允许表达脆弱、悲伤、恐惧
遵守支配性角色规范，因此男性必须是强大、果断、有控制力的
将亲密关系视为征服而非联结，因此「真正的男人」不依赖他人
通过支配他人来确认自身价值，因此支配是男性自我认同的核心机制

这些要求会对男性本身造成严重的心理伤害，如情感压抑会导致心理健康问题、支配角色会阻碍真正的亲密关系、将自我价值建立在支配之上会让男性内在地脆弱⸺因为一旦失去了支配地位就会崩溃⸺父权制回报男性以权力和地位，但代价是心理上的自我异化。

用父权制的逻辑来攻击父权制是否合理？

既然父权制对于受益者都造成伤害，那么在父权制框架内进行的对抗性话语实践，无论是激女的攻击还是反女权的反击，同样可能对参与者造成伤害。

这里的逻辑在于，在父权制的结构中，所有参与者都被父权制的逻辑所塑造。

所以当一个人在父权制框架内进行攻击时，无论他站在哪一方，他使用的武器本身就是父权制的产物。

我们可以看以下两个例子：

激女对普通女性的攻击复制了父权制的污名化逻辑：父权制污名化不符合规范的女性，激女以同样方式污名化不符合自身规范的女性。参与者内化了攻击性话语模式，将敌意常态化，不仅会损害自己的情感生活，也会损害自己的人际关系
反女权对于女权主义的攻击复制了父权制贬抑女性表达权的逻辑：父权制否定女性发言的正当性，反女权以同样的方式否定女权主义者发言的正当性。参与者强化了敌意框架，将一切性别分析预设成「攻击」，丧失了区分和分析的能力

因此，对抗父权制的人可能在不自觉中复制父权制的方法论。

命题逻辑正确但使用方法有误

「攻击者会遭受反噬」这个命题本身是成立的，不过博友错误地使用了它。

「反噬」命题不能仅被应用在激进女权一方，但忽略反女权话语同样适用。这是选择性归因，即普通型命题被选择性地应用于一方。

博友将激进女权的话语实践定性为「攻击」，预设了立场。从批判理论的视角来看，王无的文章是意识形态批判，属于分析性操作，不是「攻击」。将其定性为「攻击」已经在话语层面将其贬抑成非理性的暴力。

自然，中文互联网「激女」的某些话语实践⸺如「挂人」、骂别人「婚驴」⸺更接近「攻击」而非「批判」，但这里需要做清楚区分：不能将一切的女性主义话语都归类为「攻击」。

「反噬」是父权制的自我保护机制

如果我们再深一层，可以提出更系统的命题：「反噬」命题本身是父权制话语自我保护机制的一部分。

已知：父权制的核心运作机制是将自身自然化，因此任何对它的批判看起来像无理取闹，或者制造对立。

当有人批判父权制时，父权制的自我保护机制往往是转移焦点，即从「批判是否成立」转移到「批判者的态度、动机、后果」。

「攻击者会遭受反噬」是焦点转移的形式之一，因为它不会回应批判的内容，反而暗示你这样做对你自己不好，从而威慑潜在的批判者、将批判者的心理状态作为评判对象、暗示批判本身是不健康的行为。

但是父权制不需要有任何有意识的策划者，因此我们不能说有任何人有意去执行了父权制的自我保护⸺我这么说是因为这个分析本身可以被视作我在暗示博友有意服务于父权制，但我没有如此揣测。

公开写作

我和博友的讨论分散在博客的评论区下，这并非我喜欢的讨论方式。

一、评论区是反应性的，天然以回复为基本单位，且鼓励碎片化。

二、评论区受限于语境。

三、评论区的社交动态中，反驳成功比理解深入更容易获得反馈，因此它鼓励零和的交往模式。

四、评论会向他人发送通知，构成对方被点了名的社交信号。这也意味着，沉默成了一种表态：谁先不回复谁就输了。

但是公开文章完全不同：我的文章不会被推送给被讨论者，他们看到亦或者说没看到和我无关。即便看到了，不回复也是正常的，因为公开写作不会预设对话者的义务。

因而在公开写作中，人们会更不受限地去表达自己想表达的东西。

除此之外，为什么我还要将这些内容写成独立文章呢？因为我认为该话题非常有趣、值得记录，所以我要将其转向建立于文章的建构性论述，我要表明我的论点、如何得出、为什么。

公开写作的意义就在于，它能把我们的思考从私人意见转变成公共的论证。读者朋友们会看到我的结论、审查我的推理过程，从而判断我的结论是否成立。

亦或者没有人会看、审查、判断，因为没有人会被要求这样做。

做导游的这几天：上

2026-08-20T04:00:00.000Z

这周我被家里人安排来为来美旅游的亲戚做导游⸺又是这样！我已经不知道做了多少次导游了。

和不是朋友的人出门，我近乎记不住什么，因为我鲜少参与到话题当中。就算他们在聊天，也没有什么深度，我也没有印象。所以本文依然是以大量的图片为主。

我之前写了个 Hexo 脚本，可以将图片转换成更轻量的 webp 格式。后来我嫌麻烦撤掉了…… 哎呀虽然知道会用掉读者朋友们很多流量，不过现在就原谅我吧！拍的这些照片就是要清清楚楚展示给读者朋友们看呀！

首先是接亲戚。他们从波士顿坐火车过来，在纽约市接他们自然要来宾夕法尼亚车站（Penn Station）了。它的对面是麦迪逊广场花园（Madison Square Garden），是个很大的球场。

其中「麦迪逊」指的是宪法之父 James Madison（詹姆斯・麦迪逊）。

关于「麦迪逊」和「花园」，其实有着一段有趣的历史：

第一代麦迪逊广场花园在 1879 到 1890 年运营、位于麦迪逊广场（Madison Square）旁边
第二代在 1890 到 1925 年运营，位于同样的位置。耗资 300 万美元，设有 1200 座剧场、1500 座音乐厅，还有屋顶花园
第三代在 1925 到 1968 年间运营，位置却改到了 8 大道与 49 和 50 街之间
第四代，也是现在的，从 1968 年开始运营，建在原宾夕法尼亚车站旧址之上

它的建造需要拆除原有的宾夕法尼亚车站，也是当时纽约市的建筑地标之一。这一损失引发了广泛批评，并催化了纽约历史保护运动。

今年六月份的 NBA，纽约尼克斯就在这里夺了冠！当时球迷们都无比疯狂，大晚上酒吧外还站着人梗着脖子看电视直播。

说回接人。这一块区域近乎无法停车。我建议往南走，开到 20 多街的住宅区小巷子里停车。

图片里那一片黄色都是出租车，剩下的则是 Uber 这样的租车，还有宰客的黑车！千万不要上黑车啊未来来纽约玩的朋友们！能用就用 Uber、Lyft 这样的平台，或者坐正经的出租车。

接到人后，我们开去时代广场看去了⸺久违来到时代广场，不得不惊叹「哇好多人，好脏，好乱，好多广告，好多宰客的吉祥物！」

未来来纽约玩的朋友们不要搭理那些穿着吉祥物服装的人，他们会拉着你拍照，然后索要金钱。过去是 5 美元，现在不知道多少钱了。

如何躲开纽约市宰游客的家伙儿呢？装成冷酷的纽约客：明明听到了但还是无视走开、一直戴着耳机挂着冷脸，或者干脆穿工装、装成上班族吧。

母亲买了 RiseNY 的票。它就在时代广场旁边，是个沉浸式博物馆兼飞行影院体验项目，也是纽约首个飞行影院类景点。

虽然买了 VIP，但当天根本没有多少顾客…… 所以买了相当于白买。

进去首先要看段短片，讲述纽约如何崛起为全球文化之都。我很喜欢荧幕左侧在最后开来地铁，结果左边的墙还真有道仿造地铁门的门⸺好像我们走进了荧幕中的车厢！

接着要穿过七个主题画廊，聚焦纽约历史与文化的不同方面。我没有拍下多少照片，只能根据资料后续用文字补全：

金融
天际线与摩天楼
电影
时尚
音乐
广播与电视
百老汇

纽约州的别名是「帝国州」，也就是 Empire State 喔。而纽约州的「国王县」（Kings County）是布鲁克林。

在「时尚」区的织布机：

让我觉得很邪恶的 Supreme：

甲克虫乐队，不过我不是很熟悉他们啦：

布里尔大厦是美国音乐产业的中心地之一：

角落的假 DJ 机：

非常「美国黑人流行文化」的地方：

说到美国黑人音乐，或许有读者朋友们会想到，且只能想到说唱。实际上黑人艺术家对美国音乐的发展影响很大，从早期的爵士乐、节奏蓝调，到灵魂乐、迪斯科，再到嘻哈音乐。

和音乐相关的历史景点地图：

纽约市也有很多影院。我是 AMC 的常客，不过老剧院我就没去过了，像是百老汇的那些。

这个爆米花机我在高中时用过：

不知道是什么机器：

百老汇的著名历史景点：

时代广场很有名的一事件就是新年倒计时：

该庆祝活动始于 1904 年，由《纽约时报》出版人 Adolph S. Ochs 发起。

为什么是《纽约时报》的人呢？我们还要再往前看看时代广场本身的历史：它的原名是 Longacre Square，以伦敦剧院区 Long Acre 命名，当时已经是剧院和餐厅的聚集区。

1904 年《纽约时报》将总部迁至 Longacre Square 里新盖的时报大楼，也是当时纽约市第二高的摩天大楼。接着公司向市政府请愿将 Longacre Square 更名为 Times Square⸺《纽约时报》原名 The New York Times，所以时代广场名字里的 Times 是「时报」而非「时代」。

Ochs 倾尽全力打造了空前的跨年派对：全天街头嘉年华在晚间以时报大楼底部的烟花表演达到高潮。不过两年后纽约市禁止了烟花表演，Ochs 不甘示弱、安排在午夜时分从时报大楼旗杆顶部降下发光的「时间球」（time ball）来标志新年的到来。

我非常非常不建议亲自跑来时代广场跨年。我曾经去过一次，非常后悔：人特别特别特别多，我们甚至挤不到里面去，只能在很外围听听人们的尖叫声。

看完展览后我们会走进 Sky Studio，并且被告知我们穿越到了 1958 年的新年，要跟着他们一起去时代广场的最高点看 ball drop。

这个电视机感觉很有当时的味道：

我们要坐在一排座椅上，模拟在时报大楼的顶部。

接下来座椅会腾空，挪向后方的大荧幕。之后的体验有点像 4D 电影：座椅会动来动去，配合荧幕上的影像，模拟出我们在天上飞来飞去的感觉。期间还有风啊，水啊，非常有意思！

我有录像，不过拍出来很模糊，时长也有三分钟多呢！以下是截取的一些片段：

这是曼哈顿大桥吧应该：

之后就是在上城的景点乱逛啦，什么 Vessel、大教堂…… 我都没咋拍，因为路过太多次了。再是车子实在没法停，亲戚们对这些景点也没有兴趣。我路上仅拍了一些照片。

这是 Trump 大厦附近的巨型 Louis Vuitton 包包建筑，看着蛮有创意：

至于为什么没有拍 Trump 大厦，因为漏掉了，亲戚们也觉得 Trump 是个大傻逼，所以无所谓。

开车去下城路上，我发现的有意思的一幕：三只鸽子排排站！

抬头一看发现好多鸽子。我看这鸽子才是纽约代表啊：

我们是去看 9 11 纪念处，还有世贸中心的。尽管读者朋友们应该都听说过 9 11 事件，但还是让我重述一遍吧。

原本的世贸中心是位于下城金融区的一个七栋建筑的综合体，其核心是两座 110 层的摩天楼，即北塔和南塔，也是大家熟知的「双子塔」。

2001 年 9 月 11 日，伊斯兰极端组织 al-Qaeda 的 19 名恐怖分子劫持了四架美国商业客机，对美国发动了一系列协调自杀式袭击。世贸中心的北塔、南塔，还有 7 号楼都因此倒塌，共计 2977 人遇难。

新的世贸中心是在原址上重建的 16 英亩综合园区，规划最多六座摩天楼，截至 2026 年已有四座完工。

其中一号世贸中心有着纽约市最高的观景点。

周围长得像骨骼的矮白色建筑是世贸中心交通枢纽，有着 PATH 列车站（去隔壁新泽西的铁路）、购物中心，还有纽约地铁。

旁边的 9 / 11 纪念处除了非常有名的人造瀑布 Reflecting Absense 纪念广场，还有纪念博物馆、纪念林间空地……

曼哈顿下城有个很著名的景点叫作「华尔街铜牛」。它的历史背景很有趣：1987 年 10 月 19 日美国股市遭遇史上最大单日跌幅，道琼斯指数暴跌 22.6%，全球股市连锁崩盘。意大利裔美国雕塑家 Arturo Di Modica 被这场灾难深深触动，决定创作一件作品来激励美国人民在困境中保持坚韧与信心。

在金融市场里，「牛」和「熊」自 18 世纪初以来就被用作市场走势的象征：牛角向上顶，代表乐观、信心、繁荣，所以市场上行；熊掌向下拍，代表悲观、恐惧、衰退，所以市场下行。

这样说来，富途牛牛使用「牛」也是因为这个吧⸺ Moomoo~

于是他耗时两年独自完成了这尊青铜雕塑。

不过他有个好笑的习惯，即未经许可、直接将自己的作品放在纽约的街头。这尊铜牛是他第三次随便乱放。

安装当天纽约证券交易所其实打算移除铜牛，但是公众强烈抗议。没办法，纽约市公园局出来把铜牛挪到了博灵格林公园（Bowling Green）的北侧。接着铜牛迅速成为热门旅游景点，被永久安置在那儿。

中国人过来旅游喜欢说「摸铜牛的蛋蛋能有福气」。

说了铜牛就不得不说无畏女孩（Fearless Girl）。它在 2017 年国际妇女日的前一天被安装在铜牛正前方，形成「小女孩直面巨牛」的画面。

它由被 State Street Global Advisors 委托的雕塑家 Kristen Visbal 雕刻，目的是呼吁让金融街增加女性董事和性别多样性。

不过和铜牛不同，它引发了争议。

首先是 Di Modica 认为无畏女孩侵权了他的商标权、版权，还有精神权利⸺这个「精神权利」指的是创作者对其作品享有的、独立于经济权利之外的人身性权利，通常包含署名权和完整权。有些司法管辖区还会包括发表权和收回权。

Di Modica 认为无畏女孩被安装在自己作品的正前方，歪曲且篡改了铜牛的意义：从人民的力量与韧性，成了被小女孩对抗的负面力量。

他接着指出无畏女孩实质上是 State Street 的 SHE 指数（关注女性领导力的 ETF 基金）的营销活动，利用铜牛的形象做商业广告。

美国劳工部调查也发现 State Street 本身存在歧视，竟少付女性和黑人高管的薪酬。最终 State Street 以 500 万美元与劳工部达成和解，还在 2025 年悄然放弃了多元化的承诺⸺要小心彩虹资本主义！

不过美国的 VARA 对公共雕塑的精神权利保护存在诸多限制和例外，Di Modica 的主张并未通过诉讼解决。

最终在公众舆论的压力，还有市政府的协调下，无畏女孩还是被挪到纽约证券交易所对面。

亲戚有同学在布鲁克林，所以我们跑到布鲁克林的日落公园区来。亲戚去见他的老同学，我们带着他的小孩子在日落公园里转转。

因为是夏天，公园里好多人：跳广场舞的华人大妈、踢足球打篮球的人们、遛狗的人们。在特定的角度你还能看到水面上的自由女神像。

我有同学住在日落公园区，于是约他出来吃个饭。

他带我来日落公园附近的 Mr. Pot。我俩一起点了围炉奶茶：

喝起来奶味儿很重。8 块钱左右。菜单上说可以免费续杯，不过奶加太多了我喝了肚子有点胀气…… 所以没有续杯。

朋友说看到这个会想到国内的主理人奶茶⸺不知道是什么！

小吃点的我喜欢吃的炸芋头丸。主食他点了生菜煲，闻着很香。

这天我因为晚上要回家，所以草草结束了。不过万万没有想到，母亲居然还让我接下来的三天都陪这个亲戚逛逛！

第二日我们去了布鲁克林大桥。我们把车停在离大桥步行二十分钟距离的地方…… 一路上感受着太阳在我身上肆意妄为…… 太热了！

未来跑纽约玩的读者朋友们不要走错、走去曼哈顿大桥啊，认准布鲁克林大桥。曼哈顿大桥不好看，要走在车辆旁边、有些压抑。

我觉得无聊，就在玩手机的相机。

这是用 Tilt Shift 模式拍的照片：

模式还挺多的呢：

然后我们去斯塔滕岛上坐免费的橙色渡轮到曼哈顿最南边的码头，也是炮台公园的位置。

唉，说到纽约市根本没有人知道斯塔滕岛：纽约市有五个行政区，分别是曼哈顿、皇后区、布鲁克林、布朗克斯，还有斯塔滕岛。岛是里面人口最少、与曼哈顿距离最远，也是唯一不与纽约地铁系统相连的区，因而也被称作 the Forgotten Borough（被遗忘的行政区）。

不过它也是五个区里最独具特色的，因为风貌最郊区化，像是别的州，而不像纽约市。

橙色渡轮则是连接岛和曼哈顿的唯一非机动车交通方式，也是纽约市最具标志性的交通体验之一。最重要的是，它免费、24 小时每周 7 天都会运行、能看到自由女神像。

曼哈顿渡轮站的门口（白厅码头）经常有一帮黑人表演，以谋求生路。他们的口号如果我没有记错是：show love, not anger.

紧邻白厅码头的是炮台公园（The Battery），公园名称源自 17 世纪末在此部署的炮兵阵地。

公园内能买到去自由女神像岛的船票，位置是这个像要塞一样的地方：

它叫作 Castle Clinton，原本是个炮台。

背对着水，便是高楼大厦：

这些楼属于下城金融区的天际线。

坐渡轮回岛。岛上码头的景色真漂亮：

虽然没有人知道它，但岛上的景色也很漂亮：

海边也是一望无际的…… 沙子还有海水。看久了感觉无趣，不过无趣也是蛮不错的。

天黑了。这云乌压压的：

接下来还要跑到别的州…… 到时候再更新吧。

休息日逛下城

2026-08-19T03:13:55.000Z

记录的是八月十五日我和室友出门逛下城的事情。有很多图片喔。

因为近期一直在忙事情，忙得已经静不下心来，书没咋读、博客没咋看，更别说写博客了。你要说我的分享欲哪儿去了，我也不知道。

我鼻涕不再流了，就是时不时还会咳嗽。先前我便和室友约好周六一起出门。期待了一周多，就算还在咳嗽也得换衣服穿鞋子出家门。

纽约市每年都会举办个活动叫 Summer Streets。活动期间的每周六，特定的街道会被封锁、不让车辆驶入，人们可以在街道内骑自行车、玩耍。

室友原本在 Instagram⸺ eww! ⸺上看到八月八日曼哈顿的 Summer Streets 地点有滑绳索项目，所以打算那天跟我去。谁曾想我生病了，只能推到下周，也就是八月十五日星期六。

所以说就算还在咳嗽也得出家门啊！曼哈顿的 Summer Streets 就举行到八月十五日。

不过…… 我也没有很想去。这天早上我懒散地起床，看着还在呼呼大睡的室友、选择不去叫醒她。绳索项目下午三点结束，如果我没有记错的话，室友一点才醒来⸺她起床的时候还不停责怪我没有叫醒她。

午饭是室友做的：

非常好吃的牛排肉！

我们急匆匆跑到 Summer Streets 现场，结果发现排满了人。工作人员们跟我们说明年再来吧。室友说我是个很没劲儿的人，一点都不期待没有体验过的事情，所以也玩不到。

不过看队伍，怕是更早来也玩不上吧！后面甚至有队伍是明知玩不上也要顶着太眼光排队的。

因为一时半会儿没有别的事情做，我们打算去附近的共享办公室里坐坐、喝喝水、吹空调。

路上我在玩手机，发现 HelloUI 的相机有很多适合拍照的功能，比如大头贴、两个摄像头同时拍照然后伪装我在跟谁视频通话、对着前景摄像头露出手掌心以自动拍照…… 我觉得最好用的是将手机折叠一半能自动录像的功能，还有晃一晃手机打开相机的功能。

探索期间我还发现如果使用社交平台软件拍照，手机的相机还能美颜一番⸺不过我没有那些软件，所以无法测试。

我们要去的共享办公室在唐人街附近。Lafayette Street 那边有很多人摆摊在卖假货，走起路来也特别难受。如果有人要来纽约市玩的话，这个路段要小心扒手，也不要买看似崭新的 Apple 耳机！

炎炎夏日我们看到一家蜜雪冰城。Fedi 友还说我发的帖越来越像在中国发的，哈哈。

店里面很多人排队点单。我建议直接搜 Menusifu Mixue 然后带地点的关键词，就会出现这家蜜雪冰城的线上点单⸺不清楚为什么，我没有在这家店里找到线上点单的二维码。

「雪王」的英文名就叫 Snow King，好好笑。

因为我不喜欢拍到别人的脸⸺后期处理很麻烦！⸺所以拍了张天花板，上面挂满了小旗子。

我没有喝这类饮料的习惯，所以就室友买了；她点的是白桃乌龙。

共享办公室的名字叫作 WeWork。曼哈顿有很多家，每家的「生态」也各不相同。因此时不时来探索不同家 WeWork 很有意思。这家的厨房有个意义不明的小船：

卫生间里还有冲澡的地方。之前听说有人「住」在了 WeWork：早上起床冲个澡，喝 WeWork 免费提供的水、茶和咖啡，然后在里面办公，晚上就缩在会议室里睡觉。

隔壁是美国华人博物馆（Museum of Chinese in America），他们的官网做得挺不错的。

小时候我很讨厌去博物馆、觉得无聊。尤其是美国自然历史博物馆（American Museum of Natural History），它是纽约市相当著名的一个景点，也是公立学校修学旅行的常客。所以我去过很多次了，拍照也拍了一大堆。

数年后的现在再去，反而觉得别有风味。仅是拍照实在是太委屈博物馆。

纽约市的许多博物馆都是只要你是市民，就能自定义入场票的价格。只付 1 美元也可以。我付了 5 美元，就当作支持了。

馆内现在正在展出杨志成先生的作品。他 1951 年来美国留学，毕业后在纽约设计广告，之后创作儿童插画。

好可怕的基本功！

杨志成原本在洛杉矶学习，后来借了 20 块钱只身跑来纽约赌人生。儿童图书出版人 Ursula Nordstrom 雇佣了他为这本 The Mean Mouse and Other Mean Stories 画插画：

我也拍了些很漂亮的作品。

Wabi Sabi：

令人惊叹的创意！将核武器造成的蘑菇云慢慢转变成千纸鹤：

除开杨志成的作品展览，博物馆最中间的 With a Single Step: Stories in the Making of America（翻译叫「千里之行，始于足步」）便展示了中国人来美国的历史：从最初的淘金热开始，中国人在美国的「地位」随着当局者的喜好不停在改变。

以下是我结合了 Google Arts & Culture 里的内容写的：

19 世纪中，大批华人劳工作为淘金客来加州挖金子，随后又投入太平洋铁路的修建。淘金热结束后，华人被白人工人视为竞争对手，惨遭暴力与舆论丑化。展览中就有许多妖魔化华人的漫画和宣传作品，例如

随后华人被排斥出大部分行业和熟练工种，只能做白人不愿意做的工作，例如洗衣服、做饭、帮佣。其中洗衣业因为门槛低、成本低、不需要英语，于是成为华人谋生的重要出路。

博物馆内有面墙放了当时华人洗衣工会用的工具，还讲了「八磅生计」的故事：这儿的「八磅」指的是洗衣工用的熨斗的重量。为了更直观知道这份工作的辛苦，墙下放了可以拿起来的旧熨斗，我试了试，确实很重，实在是难以想象长时间用它熨烫衣服该有多累人。

19 世纪美国民间还习惯把华人男性统统称作 John 还有 Charlie，算是带轻蔑的绰号化称呼。历史档案中就有大量华人洗衣工被登记为「Charlie 某」，很多甚至不是他们的本名，而是白人顾客或者雇主随意取的。

后来流行文化中白人作家创造出了华人侦探 Charlie Chan 这个角色。虽然是正面角色，但是由白人演员扮演，被许多亚裔视为是刻板印象⸺还有个是傅满洲；那种奸诈的小人形象也是白人对华人的刻板印象之一。

每个时代馆内都贴了诗句在一边，讲出了当时无数个在美华人们的心声。

可他们来这里，
是为了猎奇，
是为了寻求刺激；
因而，他们满目所见，
全是怪异！

所以，我们一一建起了唐人街。
他们来这里
消遣猎奇；
我们在这里
遮风躲雨。

淘金热那会儿来美的中国人不只有去矿场的，还有去做商人以及餐馆老板的。1849 年 11 月 19 日 Canton Restaurant（广东餐厅）在旧金山开业，成为北美有记载的第一家华人餐馆。

当时的华人社会是光棍社会，大多数都是单身男性矿工，买饭吃很普通也很实际，华人餐馆自然应运而生。

华南商人在 1860 年代便多次宴请美国政界人士。餐厅菜单与清代扬州盐商的宴席类似，不乏有例如燕窝汤、鱼翅等菜品，但美国客人只对杂碎印象最深。

此杂碎非彼杂碎：在台山话里指的是内脏和杂碎，而非「垃圾」。我在美式中餐餐馆里也看到「杂碎」这道菜，但对其样貌不感兴趣，所以从来没有试过。不过看各个报道，杂碎本身到底是什么、怎么做，没有个准确说法。现在餐馆中的杂碎也顺应了美国人的舌头、去除了内脏。它究竟是什么，我不得而知。

1943 年，《排华法案》被废止。中国人们正式开始拥抱「美国梦」：

在远东地区为自由和民主而战…… 在世界最民主的土地上却无法获得平等机会，这是最大的讽刺。

可这「美国梦」究竟是真实的梦想，还是大梦一场？

之后第一代华裔美国人出生了：

不过他们长大后面临着全新的问题。

包括有色人种在内的民权支持者，有时也不肯将民权与亚裔美人共同探讨。仿佛亚裔美国人相关的民权问题可以完全置之不理，无须慎重考虑事实，就因为所有人都认定亚裔美人个个功成名就。

不说上个世纪 60 年代了，哪怕现在也是如此。

亚裔和男同性恋反叛者，在公众中鲜少看到：

应该会发出声音的唱片机，不过下方说正在维修中：

1980 年新移民们到来了，他们没有止步于唐人街，而是在其他地方建立起了一个个华人区：

其中布鲁克林的日落公园区我很熟悉，因为我住在那里过。它也叫「小福州」，有很多福建人。

图片内有板块提到了 hapa。馆内另一展区解释了这个词儿：

也就是「有白人血缘的人」的意思。应用在亚裔这儿，指的就是白人和亚裔生下的混血儿。

离开博物馆，我们就在 SoHo 区乱逛⸺曼哈顿下城的 SoHo 跟 NoHo 两区挺有名的：前者指的是 Houston Street 以南，是画廊、精品店和高档餐厅的聚集地；后者是 Houston Street 以北，是剧院和音乐场所的所在地。

一路上我们看到了许多漂亮的酒吧、夜总会、咖啡厅。

这家酒吧印象里种满了绿植，非常漂亮。菜单上还有可爱的手绘猫头鹰们在干杯。不过价格也是真的贵，一打生蚝要 50 多美元。作为对比，Chelsea Market 的生蚝一只 3 美元。

我们路过一家茶叶店，墙上摆满了茶盒。曾经室友给我买过一盒茉莉绿茶包，似乎就来自于这家。

这红茶的 supreme 是 supreme 在哪儿了呢？

他们也卖杯子：

里面还有泡茶、做咖啡的地方，不过我没有拍下来⸺美国的咖啡店真的是像野狗一样多啊我没有说错。

门口还有纽约客包包。是的上面写的东西都是正宗纽约客会做的事情：

翻译下吧。左边的包上写：

像纽约客一样吃
带有各种籽的全料贝果，抹上一层厚厚的奶油乳酪
把你的比萨顺着长边对折一半
裸麦面包夹熏牛肉，配酸黄瓜，再来杯奶油苏打水
热狗不加黄芥末？门儿都没有
点杯常规咖啡。指的是加奶和两块方糖
黑白。它是一块饼干，可不是警车（指的是一面巧克力一面香草糖霜的糕点）

右边的则写：

纽约，纽约
如此美好，以至于名字都叫了两遍

右边的包我得做个解析。首先是写地址时美国的写法是这样的：

房号街道名
城市名，州名邮政编号

例如：

123 Example Street
New York, New York 10000

有没有发现 New York 出现了两次呢？

因为「纽约市」这座城市叫「纽约」，所处于的「纽约州」也叫「纽约」。所以要叫两遍名字。笑点解析真好玩。嚯嚯嚯……

NoHo 和 SoHo 的东面是 East Village，也被叫作「小东京」。顾名思义，里面聚集了大量的日本留学生、侨民、日料餐厅和日式杂货店。

20 世纪末俩 Ho 转型成了高档街区，日资超市还有餐饮品牌就向西延伸，进驻了客流量极大的俩 Ho 边缘。

这里的消费群体都是年轻的专业人士、时尚从业者、游客，还有富裕居民，本就对高质量、精致、健康、异国风味的食品有着极高且稳定的需求。其中日本食品从小众商品摇身一变，代表起了精致、便捷，且深受中产阶级追捧的生活方式。

我们就在这儿找到一家日资超市。虽然店面小小的，但是商品塞得满，进来买东西的人还不少。我随便拍了张即食盒饭的照片：

隔壁又一家共享办公室。因为是休息日，没看到保安，直接刷卡进来的。这栋楼的走廊风格挺有意思：

电梯间放雨伞的工具更有趣：

我们要去找餐厅吃饭了。因为我大病一场，终于是痊愈了，室友要请我吃饭。我们向她熟悉的二大道进发。这二大道贯穿了曼哈顿下城东侧的许多不同街区，包括 East Village、Lower East Side、Stuyvesant Square、Gramercy Park、Kips Bay 还有 Murray Hill。那儿经常能找到漂亮的餐厅，这也包括中餐厅，如湖南菜的 Hunan Slurp。

路上我们走进了一个社区花园。

East Village 和 Alphabet City 一带有着非常密集的社区花园网络，它们背后也有着有趣的历史！

上个世纪 70 到 80 年代，East Village 曾经经历过一段经济衰退的时期。许多建筑被废弃，空地沦为垃圾场或者毒品交易的温床。

当地居民⸺其中有艺术家、激进主义者、移民⸺看不下去，自发拿起工具闯入了这些政府或私人的废弃空地，清理掉垃圾，还种上花草树木，将它们改造成社区花园。

政府后来试图拍卖这些土地以盖起高层公寓，居民们还成立了 Green Guerillas 等组织反抗，最终保下几十个社区花园。现在它们在纽约市公园局的管辖下，将会是永久的公共绿地！

根据纽约市公园局的规定，这些社区花园在温暖的季节必须向公众开放一定的小时数。所以我们看到大门开着，就大摇大摆走进去了。里面有一些长椅，藏在绿植的后面。你可以在里面歇息、看书、欣赏花草。因为是志愿者还有园丁精心维护的地方，所以进去不要破坏里面的环境！

有时候社区花园内还会举办免费活动，例如露天音乐会⸺去年还是两年前我和室友去过上城的一场露天音乐会，是日裔美国人举办的。

所以要是来纽约市逛逛，不乏来社区花园里面坐坐。

街边的「蛇」：

我们走到了 Hunan Slurp，这是家位于 East Village 的湖南菜餐厅。我和室友数年前去过一次，味道非常惊艳⸺对比当地其他的中餐厅⸺但第二次以及之后再去，觉得厨师换了，味道越来越不咋地。

隔壁有家 Twilight Lounge，是做广东菜跟四川菜的。因为是新店，引得我好奇，所以我们就去尝鲜了。

这个「液体猫薄荷」是什么东西？我没有点。我只是好奇。

在点菜之前我们不知道它有线上菜单、能看到菜品样子。最后是瞎选，点了担担面、菠萝糖醋小排，还有俩米饭。

担担面在菜单上居然算「南北手工热点心」。上菜时是小小一碗，我还没有拍室友就开始分面，所以我只拍下这一口面：

这面比想象中好吃！正宗肯定是不正宗的了，酱汁不知道是使用了花生酱还是芝麻酱。肉末中则添加了梅菜，据室友所说是广东的材料。这是道很成功的融合菜。你要我形容味道吧，我形容不出来，总之你就想象吧。

主食的菠萝糖醋小排就…… 很不好吃。

排骨很甜腻，菠萝也很甜腻。整道菜里能解腻的只有角落那三个上海青，但为了美观，上海青被切走一半……

至于为什么没有点别的菜。当时室友想要点土豆丝，但服务生说要等足足半个小时…… 好吧，这家店看起来就小小的，服务生我只看到有两个人，后厨该不会也不够人手吧？

不知道为什么小票上每道菜后面都打了一串问号：

室友说这就像是：

您点了
担担面？？？
菠萝糖醋小排？？？？？？
两碗白米饭？？？

好像在质疑我们点的东西、说我们点得不好一样！

不过室友确实在骂我点得不好：「早知道不让你点了！你觉得我俩喜欢吃糖醋排骨吗！」我错了我只是好奇……

回家路上我们路过了 Teso。我对这家店的印象是盲盒潮玩店，然后卖日本跟韩国的化妆品，总之是我很讨厌的那类店。不过室友拉我进去看，我才发现它会打折卖很多零食。我买这个良品铺子的香辣味海带零食：

我们也路过了一家 Five Below。它虽然标榜着商品价格都低于 5 美元，但是里面依然有很多超过 5 美元的东西⸺这算不算品牌欺诈？

室友第一次逛，说 Temu 要是有线下店估计就是这样吧。我没有拍照片，总之里面的东西杂七杂八、乱乱的，什么都有。

Five Below 楼上有家鞋子零售店。我数个月前就在纠结买皮鞋的事情：我因为有扁平足，脚型怪怪的，很多鞋子都不能穿。但工作场合我需要穿点「正经」的鞋子，比如皮鞋。

这家零售店内有个室友很熟悉的牌子，其皮鞋据室友所说非常耐穿，也很好看，不过因为是男鞋、没有我的号码。至于为什么不找女鞋…… 我受够了女鞋上莫名其妙的装饰物！

店内室友的校友发现了她。说来好笑，室友和这位校友甲有着同样的名字，还都是带个女生出来逛街；校友甲是出来跟女朋友约会的。

聊天间校友甲有问室友上次带的男生是不是她男朋友，被室友否认了。

两人聊了几句便分道扬镳哩，毕竟我跟校友甲不认识，他女朋友也不认识我们，室友跟校友甲关系也没有那么好。

「为啥中国人总是觉得跟我在一块的男人都是我男朋友？」她不满道，「外国人只会觉得我们是朋友。」

我想这是文化不同吧。

「但我俩出门就不会有人觉得我俩在约会。」

我想象了下新的社会，里面的人们不仅会默认俩异性出门是交往了，也会默认俩同性出门是在约会 —— 听着好累！问候语不要是「你最近咋样」，干脆改成「那个谁是你交往对象吗」好了。

走在曼哈顿的夜路，却只会觉得这天怎么还未暗下来。远处的高楼大厦全都使劲儿地浪费着电、传播光污染。

穿着衣服的小树：

室友聊到了 toxic ex 即「有毒的前任」，我想到我也被某个家伙儿如此评价过，结果他才是最有毒、不健康的那个。

恋爱观，我周遭的人们都有着不健康且扭曲的恋爱观。一些对此有着自知之明并不再谈恋爱，一些尽管自知但还是沉溺于有毒的关系中无法自拔……

他们总说，「恋爱」和「友情」之间总有一个区分彼此的关键。可这个关键到底是什么？是浪漫、性、未来的婚姻，还是什么？

最后给读者朋友们看看我在 Target 买来的 5 美元小相机吧：

我拍的是可爱的匹克猫。

好转和博客和主流和教会和性别和大扫除

2026-08-11T04:00:00.000Z

在我的记忆里我鲜少生过这么久的病。上次应该还是新冠病毒大流行的时候，我生了一周的病。根据我 GoToSocial 的数据，这次生病第一次开始记录应是七月十二日。今天都八月十一日了，我还没康复，依然在「好转中」的状态。

八月七日我写了篇文章讲我开始好转：从排出恶心的异物开始。接下来包括今天在内的时候，我都在循环「起床、擤鼻涕、咳痰、吃饭、擤鼻涕、咳痰、吃饭、擤鼻涕、咳痰、睡觉」的日子。因为有一天擤得太用力了，次日面部肌肉明显酸痛不少。

这期间我还把室友传染了。她的症状是咳嗽、喉咙疼。不过她发现得早、吃药也早，很快就控制住、能出门了。反观我，今早我擤出来的鼻涕依然是带有白细胞残骸的白色鼻涕，还咳出了一直卡在喉咙处的血痰。要说难受，没有前些天那么难受、生不如死了，但出门还是掂量掂量吧，我可不想随处抹鼻涕、吐痰。

许久没有这么大病一场，反倒是让我意识到了很多事情：

一是我的日常生活只有和电子设备做伴。生病不能常看电子设备，但我还是在看，好似没了它我就没有事情做了。我身边明明也有很多不需要电子设备的娱乐方式，比如数年前买了却一直没有碰过的小说、绘画本、字帖。

虽然很喜欢博客，不过看博客也得接触电子设备、互联网。唉我也想试试看断网生活，但我也没有那么强的偏好。

二是吃药一定要调查清楚成分啊！死室友吃药不看成分和说明书，差点给自己吃死。她之前买的流感药主要成分是 acetaminophen，也叫对乙酰氨基酚。这玩意儿成人的每日最大剂量差不多是 4 克，保守起见最好不要超过 3 克，否则会引发急性肝衰竭。

她看也不看，吃了流感药又去摸同样含有 acetaminophen 的止痛药。24 小时内摄入了 2 克多的剂量，还问我能不能再吃。我看了眼她吃的止痛药是哪瓶⸺我还有含有其他成分的止痛药⸺顿感不妙。掐指一算：再吃你就嗝屁了！吃毛！吓得她不敢吃了。

我问她吃之前不看吗。她说她又不知道。我说两瓶药上可都清清楚楚写了「吃了后不要摄入其他含有 acetaminophen 的药物」啊。她不敢吭声。

我真不能理解用药不看说明书的人！

三是今年夏天真的热啊。我感觉过去几年都没有这么热。

网上看 BiliBili 的时候刷到一待在山东的开房车的频道主。如果没记错应该是威海那儿的。他说太热了，房车根本住不了，然后给观众看了眼温度：35 度！纽约市最近也上到过 35 度，但更多还是在 31-33 度之间摇摆。

太热了，租的这间公寓朝向差，平日没有什么风进来。为了让自己不那么热，就得开空调，但这个旧空调烂得要死，一开不仅没感觉有多凉快，反而身体更干燥、更难受。不得已，我只能常关空调多开窗，让空气更流通。

温度太热也意味着我做什么都不顺心。前些天难受得什么也不想做，想睡觉吧，但睡觉也热，起来一身汗。

于是我便「躺平」了几天，什么重要的事情都没做，每天就是吃饭睡觉然后擤鼻涕咳嗽。这种生活别说肉体难不难受了，精神上简直是摧残！

真要说有什么有意思的事情，倒是可以列举几个。

Wiwi 宇宙

我数个月前在自己的 RSS 订阅内添加了很多英语使用者的站点。不过他们对比简体中文使用者的独立博客，明显要勤更新很多很多，日更的一抓一大把。

我想要再添加一些中文使用者的站点，来对冲一下，不过独立博客在内地实在是不够流行，难以找到更多符合我标准的博客。

忽然，我想到 BlogBlog 同乐会。之前我参加过它，但我实在不擅长围绕着主题写文章，所以没有继续参与⸺反倒是之后就着自己性子写，写出了很多「天啊那会儿写出来就可以投稿了」的文章。

我随便挑选了一期，然后开始翻看参与者们的博客，并订阅达到我标准的博客。参与者实在是太多了，一一看过去实在是遭不住。订阅了大致需要的量后，我便没有再翻阅。

参与者们多数是繁体中文使用者，而在他们的网站中我频繁捕捉到一个名字⸺Wiwi，也叫「官大为」，也是同乐会的发起人。他的独立博客在这里。

很多人都是受 Wiwi 的启发，而开始写博客的。因为 Wiwi 的 IndieWeb 以及数字主权精神，我也看到许多人被他影响开始使用 RSS、POSSE 等技术，并抛弃 Meta 家的产品，着实感动。

因为该社区的中心就是他，所以就可以叫作「Wiwi 宇宙」。

「世界」和「语言」

这是套我很喜欢的概念，详情可以看这里。总之你可以将「世界」理解成已存在的客观现象，「语言」则是我们主观的解释。

在软科学中，「语言」会塑造我们的「世界」。例如「种族」这个词被发明，于是我们人类就真的要被划分成不同的「种族」，尽管在硬科学里人类不存在不同的种族。

语言的使用也是如此。我和室友都出生在仅说普通话的环境里，便会被塑造且认为普通话更高级、方言没有出路。

室友说她无法理解为什么大学里会有 ABC 校友觉得自己只会说方言是件值得自豪的事情，因为按照中国内地的发展，所有人统一说普通话只是时间问题。

我不会说除了普通话外的任何方言，现在连山东口音都找不见了。虽然现在美国的华人区还是以方言为准，不过我能看出，随着会普通话的年轻人越来越多，方言也会像中国内地那样，一代代变少，直到失传。

然后我们就开始思考什么是「主流」。对我们而言，说普通话的就是主流，因为我们只能接触到他们。但对华人区的老移民和他们的后代来说，主流是说方言的。主流实在是太主观了，以至于我们会错将特权和偏见当成常识：小时候一天出门买饭，旁边的大叔忽然开始批评我，说现在的小孩子既不会中文也不会福州话。但我会中文，也不是福州人。

大了后，内地来的留学研究生们默认我未来会回内地报答祖国。虽然说我出国这么久应该是考公不能了，血亲好像还有过进监狱的记录…… 不过我真的会回去定居么？我对内地的认知已经断层了。乡下的外婆家都盖起了高楼，我却只记得十多年前的三线城市。

母亲总会跟亲戚笑话我到现在还在幻想回国生活。他们已经找到了自己的社区、自己的主流、自己的常识，但我还什么都没有找到。我想这才是为什么我如此在意这种事情的原因。

Churchgoer

八月二日休息日我久违去了次教会。这教会和我过去待的教会可不一样：一是多样性高，二是吃饭是免费的 potluck，三是大家很活跃很开放很友善。

我很难理解「神」的存在，但我喜欢开放且友善的社区，所以我对这个新教会很感兴趣。

室友有着相似的经历。她受人邀请去了创价学会的活动，也觉得那里挺开放、人很好，不过她的感想和我完全不同：她觉得自己去那边是对自己「无神论者」身份的背叛。

我得说明下，室友的想法一直都很极端。不过她不会外露，也不会用她的想法攻击别人，自己也很有自知之明。所以我们觉得无所谓，就让她想吧。想事情不是罪。

我虽然不喜欢宗教，不过一直认可人们信仰宗教的理由：有信念、活下去的意义。

室友则认为人类的信念应当来源于自己，而不是为了他人。如果信念不来源于自己，那么就是弱者，所以她不喜欢教会里的人。但她能理解为什么人们需要宗教，因为这个世界是以弱者居多的。

可是去不去教会跟信念什么的，实际上关联并不大。这句话听起来很奇怪但完全合理，因为美国的教会文化很浓厚，你不相信上帝依然可以每周跑去教会⸺这种人叫作 churchgoer，直译过来应该是……「去教会的人」？

大扫除

我们一直都觉得家里有太多太多没有用的东西了，比如很多很多衣服⸺主要都是我的。其实也不是我的，是母亲给我的⸺于是我们打算生病期间把不需要的东西全部丢掉。

这一收拾我们就收拾出来了三大蛇皮袋旧衣服，包括但不限于数年前 Uniqlo 联名但我觉得设计很丑的 T 恤衫、质量很差的衬衫、破了洞的裤袜…… 我们本来想要捐掉，但没有在家附近找到捐献点，于是丢到楼下、贴了张 FREE CLOTHES 的纸，顺便在 Facebook Marketplace 上找了个回收旧衣服的人让他过来碰碰运气、把衣服都拉走。

大扫除时人们总会找到纪念过去的物件，其中很多都是室友以前的画作。不得不感叹，这家伙儿绘画的巅峰在初中啊，现在和我一样也是懒得画画了。

我们还找到一袋猫薄荷。室友以前的猫会吃掉它们，所以必须要藏起来。但现在的匹克猫对猫薄荷没啥兴致，连会摇摆尾巴的鱼玩具都感到害怕，不得不感叹每只猫的喜好能这么不同。如果是咪咪猫的话，它肯定是什么都不玩，只想要露肚皮睡大觉！

性别的本质

一天晚上我和室友聊到部落主义，即人们不靠理性讨论来划分阵营。期间我举了个性少数群体、性别刻板印象等例子，她就说「性少数是残障」，理由是双性人在生理上是残障的。

性少数这个概念很大，不单单有双性人。不过双性人真的是残障么？性别到底是怎么定义的？我很好奇，于是就搜索了一番。

首先生物学上的性别不能单纯靠生殖器来区分，实际由多个层决定：染色体、性腺、性激素、外生殖器、内生殖器、次级性特征…… 如果非要每个层都取两个极端来严格定义男女双性的话，那么世界上大多数人都不是严格意义上的男或女。因为每个层都有可能出现变异⸺变异在自然界是常态，并非残障。

其中决定人类性别发育的关键是 Y 染色体的 SRY 基因。它会激活一系列下游基因⸺也就是刚才说的「层」⸺以让性腺发育成睾丸。不过 X 染色体上的 DAX1 基因有抗睾丸效应。假设 X 染色体上多了 DAX1 拷贝，那么它就会覆盖 SRY 的作用，导致 XY 个体发育不出睾丸。

除此之外也有其他类似的基因会改变「层」的结果，甚至说 SRY 本身也可以被移位和被推翻，因此「有没有 Y 染色体」、「有没有 SRY」、「性别表型是什么」这三者之间的关系并不是一一对应的。

那么什么真正决定了性别？既然 SRY 作为决定性别发育的关键都如此不稳定，那么什么才是性别的本质？某些爬行动物的性别会由温度来决定，所以「因」是环境温度，「果」是性别。但它们真正的性别由什么决定？是基因、温度，还是两者互动的结果？同样，SRY 是关键的因果节点，但整个性别发育是一大堆东西的联合产物，那么哪个单一因素才是性别的本质？

生物学认为，性别最底层的定义是配子的大小异型性，即只要一个物种存在有性生殖，那么产生较小、可运动配子⸺精子⸺的个体就是雄性；产生较大、营养丰富且不可动配子⸺卵子⸺的个体就是雌性。

说回双性人。双性人或 intersex 指的是出生时具有的性特征变异的人，这些特征不符合男性或女性身体的典型二元概念，因此对室友来说是「残障」的。

在残障研究中，分为医学模型和社会模型：前者认为残障者本人是问题本身，因为他们内部有缺陷或障碍，所以要治愈和修复他们；后者认为排斥性的社会是问题本身，因为残障来源于排斥。如果社会没有台阶、只有坡道的话，那么坐轮椅就不会构成障碍。

但「变异」是否就等同于「残障」？我收集了一些属于变异但不是残障的例子：左撇子、红头发、不同血型、不同颜色的皮肤、乳糖耐受性、间性人或者双性人⸺因为间性本身不必然造成功能受损。将间性称为「残障」意味着：一、将「不同」视为「缺陷」，即医学模型的过度延伸；二、混淆了「间性变异可能伴随健康问题」与「间性本身是残障」两个概念。

收集、收藏、消费主义

晚上室友问我在生活中实施极简主义如何呢，极繁主义算不算在鼓励消费主义。我以为她说网站设计呢，结果她其实问的是「人为什么要收藏或者说收集物品」。

虽然以我现在钢笔的数量和品质来说，讲我会收藏钢笔实在是有点自大，不过我确实有收集钢笔的小癖好，类似于电子设备友会收集奇特型号的手机、笔记本电脑一样。但我的行为和我确实会讨厌的「收集 Labubu」有什么区别么？我也说不上来。

说到底人为什么会收集东西？我感觉收集本身不能强行和消费主义扯上关联，因为之前看到有人收集石头、塑料板凳、沙滩上的贝壳海螺…… 收集本身不一定要购买什么。再者也有二手市场，能够以物易物。

最后

我将最近写到 Fediverse 上但感觉还不够单独写成独立文章的东西放在了这里，毕竟也不是所有人都会去看我月刊的日记片段。很长啊很长，也很琐碎。

时不时将一些内容集中成一个 bucket post，我觉得也挺有意思的。

总之我要出门去买可丽饼吃了，下篇见！

病殃殃的一周

2026-08-07T18:30:40.000Z

我这周生病了。生病的征兆实则半个月前就有出现：打喷嚏、喉咙有黏稠感。不过当时仅觉得是上火了，所以措施也只有多喝水。

两天后我的身体有了干燥的感觉，上颚也很痛，像是被烫伤或者磨伤了一样，许多需要嚼的食物都会因为碰到上颚而吃不了。

期间时不时还有肚子不舒服、胃胀的现象，别提多难受了。感觉非常像我几年前得了新冠的那会儿。到这时候我才慢悠悠意识到自己生病了。

我的一大坏习惯在于，我生病了不会去看医生。我从小到大去见医生的次数都很少，多数还是母亲拉着我去的。我对「看医生」没有个概念，即「什么时候该看？」万一只是个小毛病、休息休息就好了，那看医生不就浪费了几个小时？

实话说依然是懒惰害的。我经常说我的家庭医生离我很远，但空闲时也没有去调查公寓附近哪儿有医生、把档案迁移到他们那儿去。

总之我又过了啥措施都没采取的两周。

到了八月初，病情果不其然恶化。

这时候我在找工作，给猎头公司投了好几封简历，顺便给 LinkedIn 上的人狂发 cold email—— 无他，mentor 们都跟我说这是「人情世故」的社会，我也只能屈服了。主要是这种 network 已经发展成类似于「技能」、「自动流」啥的东西，一下子就不会觉得害羞了呢。

我的重心都放在了找工作上，个人的经济条件也不容许我再放空大脑，对于生病什么的，也只是觉得它很快会走掉。最多在身边放了个产生蒸气的机器，可以让房间潮湿些。

有天早上，身体的干燥感把我弄醒了，鼻子和喉咙都无比难受。我隐约感觉空调是因素之一，所以跟室友讲了嘴别老开空调，实在不行换下睡觉的位置，空调直接对着我的床吹呢。

室友觉得我瞎扯淡，空调跟我的症状有什么关系。再加上她是打地铺的，地上更凉快，要她睡我的床她会热昏，所以拒绝了我。

我上网搜了下，搜到了空调病。长期待在空调房内，一是会让房间湿度过低，导致黏膜出问题；二是空气的流动性太差，对人体不健康的微生物会跑出来。

不过我觉得「空调」仅是让我病情恶化的潜在因素之一，不是引发我这些病的主因。因为室友不在的时候我就会关掉空调。

我得另说一下：室友开空调开太狠了，之前都是往 18 度去开，冷得我直哆嗦。我一直都知道开空调不能开那么低，就算是为了保护环境空调也得往 26 度那个方向去开。所以我跟她说很热的话开 24 度。她本来百般不乐意，结果真开到 24 度她也能接受，那之前非要开 18 度到底是在干嘛。

借此我又搜了搜空调和风扇的使用方式。风扇的降温原理是加速汗液的蒸发，然后带走体表热量。环境温度过高时，风扇就开始吹热风、反而增加中暑风险。所以太热的话必须得开空调。该标准是 35 度左右。

纽约市最近都是 32 度左右来回晃荡，仅开风扇属于不会热死人，但感觉上和死没啥区别了。该开空调还是得开，最好是开数个小时再关上，然后开窗通个气儿。

空调和风扇都会加速鼻腔和咽喉黏膜的水分蒸发。要使用它俩必须得避免直接吹我们的面部和上半身。

要用风扇的话，建议开摇头模式。风向朝着墙或者天花板，可以让气流间接循环 —— 不过我没有深入研究具体咋弄 —— 风扇得放两米开外、开中低档。吹风扇期间多喝温水，以弥补风扇蒸发带走的体液。

这时候再开空调，可以把空调的温度调高一点，例如 28 度，能更好地保护环境 —— 也能让我少点负罪感。

网上冲浪时我也得知人体会在室内湿度低于 40% 的时候才会让鼻咽部黏膜因缺水而变脆弱 —— 可是家里的湿度平时都是 50-60%？这意味着病因不是简单的环境过干。

再是室友有只猫，我们管它叫「匹克猫」。这个猫特别黏人，像狗一样，为了黏人还会跳到我们身上来、让我们抱它。不过它的指甲一旦变尖，跳到我们身上可就不可爱了。之前还不确信自己生病时，它跳到我肩膀上来，不小心挠伤了我的锁骨处，正好是我低头看不到的地方。

之后我摸那块儿，总能摸出那道爪印，以及…… 痛痒感。但我以为很快就会消退，也没有管。

结果室友过来看了眼，惊呼「你怎么起疹子了！」我才知道我那块痒不是因为猫爪印，而是起了一堆红疹子。

原先我们怀疑是热疹。但热疹一旦没那么热了，就不会再出现了啊？我这堆疹子就算抹了药膏，过了几天依然存在。

既然我已经生病了，那么我也不该外出做事情，所以天天就在家里干坐着。这也是为啥从八月三每天更新更到八月六，以及今天八月七，因为我闲呐！我没事儿做啊。

除了看写博客，我还修了博客的邮件评论。它其实几个月前就因为 Stalwart 的更新而坏掉了，但我一直有着侥幸心理、没修…… 目前不知道有多少邮件评论我没有收到，总之非常抱歉…… 现在已经修复了。关于这个功能我还在探索中，所以不怎么推荐使用。

剩余的时间我便是上网搜到底啥回事儿。我学到喉咙出问题是因为鼻腔有问题：鼻腔里的分泌物会向后流到咽喉，刺激咽喉的黏膜。所以要治得先从鼻子开始治起。

室友给我调了个生理盐水 ——0.9 克无碘盐搭配 100 毫升温白开。如果盐太多，喷到鼻子里会有明显的刺痛感 —— 我装到喷壶里，时不时对着鼻子来一发。

洗鼻子的时候也得用生理盐水，不建议用自来水。生理盐水洗起来很温和、不会刺激。

也可以配个温盐水漱口用，用来消炎和缓解咽喉痛，但是别喝进去！

昨天我又多了新的症状：低头时脸部肌肉疼，像是脸要掉下来了一样。继续上网搜索，得知是鼻窦炎的症状。

鼻窦是啥玩意儿？这我还真不知道。它其实是面部骨骼中含有空气的体腔，跟鼻腔是互通的。感染会导致鼻窦黏膜发炎、肿胀，从而堵塞引流通道。这时候黏液还有分泌物就会卡在鼻窦内出不来。

我低头的时候，重力会让积聚的脓液和血液更多涌向鼻窦，压迫神经、增加鼻窦壁上的压力，从而引发剧烈的胀痛感，也就是「脸要掉下来了！」

晚上室友回家，给我带了流感药、蜂蜜还有鼻腔喷雾剂 —— 太感激了！

她说她去药店时，店员跟她讲要小心流感，最近是流感的季节。她想了想感觉我的情况是有点像流感。买蜂蜜则是因为蜂蜜温水能够减轻咳嗽。

这个鼻腔喷雾剂我得说一说。她买来的是 phenylephrine hydrochloride nasal decongestant，中文翻译是「盐酸去氧肾上腺素鼻用减充血喷雾」，是一种减充血剂。它的作用是收缩鼻腔血管，减少血流和肿胀，从而快速缓解鼻塞跟鼻窦压力。

使用说明写的是「每 4 个小时最多喷 2-3 下」，还有「连续使用不得超过 3 天」。后者是因为 phenylephrine 会让血管长期依赖药物收缩，停药时反而会过度反弹扩张。到时候鼻塞会更难治、更难治疗。

顺带一提我身边老有人吃药不看说明书。完全无法理解。你不小心搞出问题咋办。

今天早上我被自己的鼻涕泡给弄醒了。去洗手台一看，我滴乖乖黄色大鼻涕！擤出来后鼻腔明显感觉好了很多。我又上网搜了下，得知这是白细胞消灭病原体后的残骸。残骸们混入鼻涕，鼻涕便从透明色变成了黄色。

能把它们排出体外，意味着我离好转不远了！

看来整个事情在于病毒性感染，不论是我的鼻咽喉，还是疹子。我和室友都没有定期打流感针的习惯，甚至说平日只会打必要的针，对这些东西也不在乎。只有在真发生在自己身上了，才会下功夫学习。

Meta 和它不聪明的领导者

2026-08-06T19:30:59.000Z

我建议你离开 Meta 的生态。

今早我和平日一样在看 Pluralistic—— 这是 Cory Doctorow 的每日链接，或者说「日报」。他会在文章里围绕着一个主题写东西、引用他过去写的文章，然后再贴些其他链接。

不过因为每天都要写一个主题，难免会出现重复的主题。我挺佩服他能在这么多年内换个花样写同个主题的事情。我反正是做不到。

因为他的许多观点对我来说是非常有启发的，再加上近些日对他的观点很感兴趣 —— 比方说月刊里你经常会看到他，现在甚至在我的独立文章中也常常看到他 —— 我觉得不分享出来实在可惜。

今天八月六日，他的文章是这篇：https://pluralistic.net/2026/08/06/sin-is-when/，标题是 Eternal Sloptember。

Doctorow 玩了个双关梗，将 slop 和 September 合在了一起、拼成 Sloptember。

以下的所有内容都可以通过上面这个链接找到出处。

Facebook 的出生是可耻的

这篇文章告诉了我们很多关于 Mark Zuckerberg 的糟心事儿，也就是创立 Facebook 的那位。这让我对 Zuckerberg 有了更多的了解，我以前只是觉得他是又一位名校创业者。

Facebook 的起源相当令人感到羞耻：抓取哈佛大学的学生照片，然后让学生对照片中的人打分。打分的标准在于「性不性感」。

但是 Zuckerberg 不愿意承认这一点，不停尝试改写历史，声称 Facebook 的创立是为了让人们更好去发声 —— 我信你个鬼！

尽管打分网站当时叫作 Facemash 而非 Facebook，但 Facebook 起初创建时就有考虑添加约会功能。

甚至说，Facebook 这个概念都不是他想出来的，而是偷窃来的。

2003 年哈佛大学的三个学生想要做个面向哈佛学生和校友的社交网络，叫 Harvard Connection。他们将想法告诉了可以建立网站的 Zuckerberg。

然后，Zuckerberg 以各种理由开始频繁推迟 Harvard Connection 的开发，最后反倒是搞出了 Facebook。

在这期间，他对给 Facebook 投资的 Eduardo Saverin 发消息说，在 Facebook 之前已经有竞品 Harvard Connection，但是可笑的是那帮人让 Zuckerberg 负责开发。现在它永远不会上线了，因为 Facebook 会先出现。

最后，提出 Harvard Connection 的学生们被 Zuckerberg 玩弄、窃取了创意。他们 2004 年起诉了 Zuckerberg，于 2008 年达成和解。

除此之外，2004 年 Zuckerberg 也被指控骇入 Facebook 用户的私人电子邮箱并阅读其邮件。在他与朋友的聊天记录中，甚至说出了「如果你需要哈佛任何人的信息，尽管问我」、「人们自己提交了他们的信息，因为他们『信任我』，真是群傻逼」的言论。

靠此，他还骇入了之后完成的 Harvard Connection，现在则叫 ConnectU。

虽说当时他仅有 19 岁，还能用「年轻没脑子」来为他脱罪。但从 2011 年开始，他买下了一社区的大量住宅、破坏了当地人的生活，还做了层层防御避免当地人窥视他的隐私，尽管当地人正是被他窥视隐私的 Facebook 用户。

此处容许我科普一下 Zuckerberg 是如何获得夏威夷的土地的。

1850 年夏威夷王国通过了《Kuleana 法案》，允许原住民持有和耕种小块私有土地，也叫 Kuleana Lands。按照当地传统与法律，这些土地在没有书面遗嘱的情况下，会由一代代后代共同继承。

经历过百来年的传承后，一块小得不能再小的土地，其产权也有可能会被稀释、分割给几百位分布在各地的原住民后代。有些人甚至不知道自己有继承权。

这种没有正式地契、由泛家族成员共同持有份额的形态叫作继承人财产（Heirs' Property）。

Zuckerberg 联合了拥有土地微小份额的合法继承人，以对方的名义向法院提起诉讼。法院会认定该土地由数百人共同拥有且无法物理切分，然后判决将土地公开拍卖。

这时候 Zuckerberg 再高价买下，成功赶走原住民家族，获得夏威夷的土地。

没有他人的世界

种种行为都表明此人的道德多么有瑕疵。

在产品故事更重要的今天，Zuckerberg 很清楚他过去干的垃圾事儿会让自己的企业蒙羞，因此他想方设法改变历史、将自己创立 Facebook 的理由说得多么崇尚。

Doctorow 认为 Zuckerberg、Elon Musk，甚至 Trump，他们的脑子里都没有别人。例如 Musk 会气急败坏骂刁难自己的人为 NPC，即「非玩家角色」。

这些人能随意去伤害和剥削他人，来让自己获利。Doctorow 对此的解释是因为他们的世界里只有自己是活着的、其他人都是 NPC。

是不是听上去很像反社会人格的想法？

Musk 也在采访中提到，他觉得西方文明的根本弱点在于同理心。

总有人认为不能因为软件的所有者有道德瑕疵，因此去抗拒使用该软件 —— 你错了！正因为他们有道德瑕疵，所以你根本不知道他们想要启动多么弱智的项目。

例如 Joel Kaplan 认为向难民免费提供互联网服务是件坏事，我们应该向难民出售服务。然后他意识到难民没有钱、告吹了项目。

这种莫名其妙的想法每天都在这帮自认为聪明的家伙儿的脑子里出现。这个项目很快就告吹了，很好，但你能保证之后没有傻瓜项目会落地吗？

我们每次看到都会惊叹「这是谁想出来的馊主意？」的落地项目，正是这帮没有道德的高层想出来的。更可笑的是，他们会因为身边聚集了大量的马屁精，而觉得自己聪明无比。

那么又是谁让马屁精们围着他们转的呢？是他们的支持者、他们软件的用户、所有只会向钱看的人。

Zuckerberg 深知我们 —— 除了他和他的那些朋友们以外的人类 —— 都是 NPC、随机鹦鹉、可以被预测的机器，所以推出了元宇宙、能够代替真实朋友的聊天机器人。他甚至认为美国人平均有不到三个朋友，所以更应该使用 Meta AI 聊天机器人软件来满足对朋友的需求。

再就是我们更爱朋友、而非恨他，所以没有人会离开 Meta 的社交媒体平台。

不过这对 Meta 而言依然不是一件好事。因为我们和朋友们使用社交媒体平台是为了线上交流，但 Meta 希望我们多多上线、观看广告。

为此，Meta 先是调整了算法，让我们更容易看到观点不一致的人，然后陷入漫长且毫无意义的争论中…… 这点我想读者朋友们会感到熟悉，这是「引流」的做法。

再然后，TikTok 为代表的短视频平台开始在美国出现，Meta 快速在 Instagram 还有 Facebook 里都添加了类似的功能。这甚至都不需要 Meta 买流量，只需要短视频的向上划机制就能牢牢将用户锁在软件中动弹不得。

Meta 现在的状况实在是说不上好。投入了大量资源的 AI 软件近乎无人问津，意味着 Zuckerberg 的「大家没有朋友、需要 AI 聊天机器人做朋友」计划临近破产。

去年 Meta 往 Instagram 还有 Facebook 内添加了大量 AI 用户，并希望这可以吸引到年轻用户。可见他不仅认为美国人平均没有多少朋友，也相信 Gen Z 是一群见 AI 就眼开的小傻子们。对于更下一代的 Gen Alpha——2010 年初到 2020 年中出生的人 —— 他们对 AI 技术的好感恐怕会更低。

现在 AI 热潮依然在进行下去，没有人愿意先跑出来，他们都认为自己能够全身而退，甚至拿到很多钱。

我们也能看出来 Zuckerberg 并不是什么聪明人。人们提到 Zuckerberg 也只会觉得他创立了 Facebook 很厉害，然后没了。又或者是部分对他压根不了解，也对 Meta 不了解的人，仅凭他是个有钱人便开始神话他的经历和人格 ——Musk 也被这么干过。我始终难以理解竟有人认为 Mush 是个大善人，亦或者支持 Trump、觉得他做得对。

Meta 数个月前将名下的知名社交媒体平台商业化，添加订阅套餐。整体感觉更像是 Discord、QQ 的做法，也就是花钱买装扮、小功能。不然 Meta 真的要难以维持下去了。

我的看法

我建议读者朋友们放弃使用 Meta 的产品。不仅是为自己好，也是为自己爱的人们好。

该公司的领导者不仅脑子不聪明、没有自知自明，还有道德问题。坏人是可预料的，但是蠢人是难以预料的。我们在未来依然会看到 Meta 的各种丑闻。

如果你是 Instagram 用户，你可以尝试 Pixelfed。它是 Fediverse 里占据了图片分享生态位的软件。

如果你是 Facebook 用户…… 其实我用 Facebook 并不多，所以我不知道有什么更好的同类型软件。

Threads 用户自然就是以 Mastodon 为首的微博客软件了。当然也有其他类似定位的软件，你们可以通过该网站了解 Fediverse 软件的生态位。

WhatsApp 用户的话，我知道类似功能的产品有 Signal。Matrix 应该也算类似的产品？那 XMPP 还有 IRC 呢？—— 我不知道，我使用最多的 IM 软件其实是手机自带的短信。

下篇见！

RE：Bloggers, can we make better titles for our posts?

2026-08-05T23:22:00.000Z

我最近开始频繁写 RE 类文章的一切起因。

原文链接：https://michaelharley.net/posts/2026/06/15/bloggers-can-we-make-better-titles-for-our-posts/

Mike（Michael Harley）反对缺乏信息增量、阻碍信息有效传递的博客写作习惯。

标题的选择

Mike 一是反对模糊不清的标题、鼓励使用描述性标题。

这一类指的是无法提供任何主题线索的标题。对于不认识作者的泛读者而言，模糊的标题极大地增加了筛选信息的成本，导致优质内容会被忽略掉。

不过这有个前提，那就是「在 Bubbles 这种聚合网站内」。

Bubbles 是我这个月新发现的聚合网站，它用起来有点像 Hacker News。

不过我不喜欢使用聚合网站：

聚合网站太多了、看不过来；
如果用 RSS 订阅，难免会出现重复的文章。

FreshRSS 可能有解决这个问题的法子，不过我现在不打算折腾。

总之因为聚合网站往往只会展示标题，所以标题成了读者朋友们唯一可以从文章内提取到的信息。

我的标题…… 有时候是描述性的，例如《我开始有健康的生活习惯了》、《数多年重试跑步然后晕倒》，真的就是文章大致什么内容、标题就写什么；有时候不明所以，比如…… 呃，《大熊猫送快递》？确实有 panda 也有 express 在内啦。

评论区内有人说，早期的博客甚至都没有标题。我最近看到有博客是将微博客和文章混合排序在一起，所以首页上能同时看到没有标题的和有标题的。

Mike 也反对标题党。

这个我很赞同。标题党要不得：不要为了流量和 SEO 而做这些讨人厌的事情！如果我看到诸如「三个维持你和爱人关系的小妙招」，我会直接把标签页关掉的！

Bucket Posts

Mike 二反对缺乏聚焦的 bucket posts。

这一类指的是「周记」、「本周链接汇总」等文章。因为它们没有单一且明确的讨论焦点，而陌生读者不会对此感兴趣。

「想法在月月日日迭代」系列 —— 也是我的月刊 —— 也是 bucket posts，即没有主题的大汇总文章。读者朋友们能做的只有我写什么看什么，直到看到觉得不错然后点赞，或者看完觉得浪费半小时，或者嫌太长不看。

原来如此，bucket posts 其实是博客界的おまかせ（omakase，一种全权委托厨师定制菜单的用餐形式，厨师想做啥你吃啥）……！

我原先并不喜欢直接将对某某文章的回应写成一篇文章，除非它很长。不过之后我注意到，我仅是将回应藏在了 bucket posts 内、避免单独发文给我带来的困扰，即我确确实实把这个回应当回事儿、作为文章发了出去。

将链接塞在一大堆链接，和单独挑一个链接发文，意义是很不同的。

我先前的标准是，只有条目的文字到达一定的数量标准 —— 即足够长了 —— 我才会单独拉出来写成文章。但事实是，你们点进两三个月前的月刊，依然会发现完全够当成独立文章的条目。我只是不敢将其拉出来作文章而已。

至于为什么字数是硬性标准：我不清楚为什么我会这么想，但有可能是因为我部署文章需要我做许多工作：将 Org Mode 文件导出成 Markdown 文件，然后用 hexo server 跑一下看看渲染效果、挑挑错别字，接着将全新的变更 push 到云端，最后跑写好的 syndicate 脚本、坐等 VPS 跑完构建。因为成本高，所以我会希望自己的文章至少写得长一些，不要几段话就结束，不然显得我有点可怜。

在阅读上，我很喜欢 bucket posts，尤其是刊类文章，再特别是 Mike 会在文章下附加自己的想法、重述的类型。

不过我发现还有仅汇总链接的、仅汇总近期想法的 bucket posts。其中我最不喜欢阅读的是完全没有上下文、让人看了一头雾水的短语合集。我写时会尽可能补全上下文，至少别让不知道的人看了不知道我在说什么。

这些是我订阅的 bucket posts：

Spike 的 Zine
Eltrac 的大脑充血
阮一峰的科技爱好者周刊
Cory Doctorow 的 Pluralistic
Self-Host Weekly
强少 Qone 的有意思小周刊
远景的简报
Pseudoyu 的周报
阿猫的猫鱼周刊
TW93 的潮流周刊
joeytoday 的第三周刊
莫比乌斯的这一周莫比乌斯环找到了哪里？
SouthFox 的 FoxThinking
灵感电波
李启龙的学习周刊
TC 分享
Marcus 的博客阅读周记
刷比小废报
椒盐豆豉的关我辟事
Thom 的 Weeknotes

还有一些其他的 bucket posts 但是没有继续更新所以就不贴了。

应该贴完了吧…… 实在不行到时候再在 Fediverse 上补充。

博主们应不应该发表自己讨厌的东西？

文章的评论区中，有个来自 Bri 的留言：

As a blogger, you should encourage people to write. Not discouraging them by stating "you should write better post" and then pointing it out that you don't like certain types of posts. If you don't like to read them, don't read them. And it's okay if you don't like certain type of post.
作为一个博主，你应该鼓励人们去写作。而不是通过说「你应该写出更好的文章」来打击他们，然后指出你不喜欢某些类型的文章。如果你不喜欢读，那就别读。你不喜欢某种类型的文章也没关系。

这挺有趣的。博客站主可以在自己的网站中明确表达自己讨厌什么、喜欢什么，毕竟发布个人偏好，甚至对他人的批评，都在言论自由的范畴内。

尤其是 Mike 在文章结尾已经写了：

Those are the main things that irritate me when scrolling Bubbles. If you don't like my opinions, well just ignore them and continue to write on your blog however you like.
这些是我在浏览 Bubbles 时最感到烦躁的事情。如果你不喜欢我的观点，那就忽略它们，继续按照你喜欢的方式写博客吧。

不过根据 Mike 的小标题，如 AVOID BUCKET POSTS（避免写 bucket posts），确实是强观点的写法 —— 我完全认可这类写法，因为我不喜欢 weak writing，即不自信、懦弱的写作方式。你的观点应当是你可以捍卫的（这也是强观点）。但强观点的代价是它会引起读者的强烈反应，因而同样使用强观点来反击你 —— 这一切又都是公开写作的一部分。

不可否认，会有新人博客站主受作者的文章影响、去做作者提到的事情。但同样，也会有新人博客站主受反对了作者的回复影响、不去做作者提到的事情。

就连我这段回复，也是对 Bri 的强观点的强观点回应 —— 再套娃一下就是，对 Bri 的对 Mike 的强观点的强观点回应的强观点回应…… 感觉眼睛要瞎了。

作为例子，受该文章的影响的我于数天前将月刊内超出「复述」属性的条目都拉到独立文章去了。目前还有许多 RE 类文章的存货没有发出来，也让我久违体验了「过数天再来 review 自己文字，结果发现写得一塌糊涂」的感觉。

稀少的 RE 类文章

最后一个我想要聊聊的点是，我发现使用英文的独立博客经常会出现 RE 类文章，而使用中文的独立博客鲜少看到它们 —— 尤其是使用简体中文的圈子。

我推测英文独立博客的逻辑是这样的：

英文独立博客的底层建立在 RSS 订阅网络和成熟的永久链接机制之上
英文独立博主们会通过 RSS 订阅器获取同行的最新动态。看到某篇文章而引发了思考，便会直接写篇新的、在文中通过超链接指向原文
早期博客系统内置的 Pingback 或者 Trackback 协议会自动在原作者的评论区留下引用通知

而中文独立博客的逻辑是：

中文独立博客经历了向大型聚合平台还有社交媒体平台的迁移
中文网络内容的生产重心都在中心化平台
长文回应的传统逐渐受中心化平台的影响而消失
评论区留言或社交媒体平台上的转发与短评会更符合习惯

再者是二者对「博客」的看法也显著的有所不同：前者认为博客更公开、是公共论坛，因此回应是正常的交流方式；后者会为回应贴上更多情绪色彩，例如「你为什么要回应我！你是不是对我有意见！」—— 这个我还没有见过，不过总感觉能想象出来。

不过我总认为这样的逻辑没能闭环，我的拙见无法完美地解答疑惑。所以这段就是抛砖引玉、想要听听各位读者朋友们的见解了。

是的，我没有意识形态

2026-08-04T14:00:00.000Z

七月份 Linus Torvalds 在邮件串内回了个颇有争议的信。

该邮件串讨论的是基于 Gen AI 的自动化代码审查工具 sashiko，在 Linux 内核开源社区里到底该怎么用。

邮件列表内，Roman 和 Laurent 就 Gen AI 工具在开源社区中的定位以及路线争了起来：维护者将 sashiko 给出的审查意见转发给代码作者时，该不该提前人工筛选和验证呢？

Roman 认为如果要的话，那引入 sashiko 根本没有意义啊。维护流程还会因为多了这一抽象层而变得复杂。如果 Laurent 本就反对 Gen AI 的话，那就直接聊 Gen AI 该不该出现在社区内，而不是拐弯抹角弄这些有的没的的门槛吧。

Torvalds 对此的回复是：

Linux 绝不排斥 AI
Linux 不是带有反 AI 情绪的项目。如果不接受的话，可以自己去 fork，要不然就走开
AI 的技术价值无可争议。还在怀疑 AI 是否有用的人根本没有实际使用过该技术，是盲目的反对者。就算它会犯错，但人类也会犯错。人们应该去优化这个技术和工具，而不是逃避它
Linux 是纯粹的技术项目，而非「社会运动」项目。内核社区选择开源，是因为开源能做出更好的技术和产品，而不是出于宗教思想

我最初阅读 Torvalds 的回应时，我在 Fediverse 上写道：

Torvalds 希望 Linux 内核项目完全基于技术而非政治

但写完发布后我意识到：不对啊！所有的问题都可以被归结为政治问题。他所谓的「拒绝意识形态」，不也是拒绝了特定的意识形态、另一个意识形态的表现吗！于是我赶忙删除 toot 并重新编辑：

我不喜欢这封邮件中像「宗教原因」和「社会斗士」之类的说法；直接说你支持技术官僚主义或功利主义就好了，而不是将自己去政治化。

借此我发现，我一瞬间将周遭的常态视为非政治，并将政治或者意识形态视为奇怪的东西。这类似于我在大学认识的很多人；他们厌恶性别、性取向等等叙事，因为过去的社会与思想才是「正常且普遍」的，有问题的是这些新来的叙事。

占据统治地位的意识形态最擅长的事情，就是把自己塑造成没有意识形态的自然状态。

通过将不同政见者贴上标签，便能成功地将关于技术与伦理、劳动异化、知识产权和社区治理的严肃政治辩论，降维打击成「理智技术派 v.s. 狂热情绪派」的对立，我实在是喜欢不起来。

尤其是他还非常天真地认为反对者都不会使用 AI 工具，所以才反对 AI 工具 —— 啊，是的，我在哪里见过一模一样的做法。让我想想，原来是在这里。

Torvalds 在邮件串内表达的，正是将自身的主张伪装成非政治的纯粹技术，从而将所有引入伦理、劳动异化、治理讨论的人统统打成狂热情绪派或者宗教分子的后政治策略。他不单单是支持技术官僚主义或功利主义那么简单 —— 我在 Fediverse 上写的内容要早于本篇文章，所以我在批评自己之前的观点。

借用 Steven Brust 关于财产权和人权的划分，我们能够更深一层去剖析 Torvalds 的开源观：Brust 认为，右派主张财产权是人权的一部分，而左派主张财产权是实现人权的工具和手段。

延伸来看，Linux 会开源，是因为能做出更好的技术和产品，而不是出于宗教思想。也就是说，技术与开源对他来说仅是提高生产效率的工具，而非实现人权或者对抗异化的手段。他甚至将后者贬低为「宗教思想」。

他关心的只有效率和产出。Gen AI 这种能提高短期产出但带有伦理争议 —— 如知识产权侵占、劳动异化 —— 的技术出现时，他会毫不犹豫地站向「实用」的一端，并把伦理反思排除出讨论范围 —— 毕竟他们都是「社会斗士」！

邮件串内使用的 social warrior 一词，现如今是个贬义词，完整的应该叫 social justice warrior，即「社会正义战士」。

根据 Wikipedia 的解释，「社会正义战士」是这个意思：

社会正义战士（英语：Social Justice Warrior，通常缩写为 SJW；或称正义魔人）是一个贬义词语，指支持女性主义、环保、民权、进步主义、多元文化主义和身份认同政治等观点并积极参与社会运动的个人，指责一个人为社会正义战士带有指责其寻求主观验证而非任何深层次的信念的意味，并且借助参与虚伪的社会正义讨论或行动主义以提高个人声誉。

起初这个词还是个中性、偏正面的术语，后来它在一个社交平台开始以贬义词的形式出现 —— 而这个社交平台是 Twitter。

它的用法也非常简单：

The accusation that somebody is an SJW carries implications that they are pursuing personal validation rather than any deep-seated conviction, and engaging in disingenuous arguments.
指责某人是 SJW 通常暗示其追求的是社会认同而非深层的信念，并且在进行虚伪的辩论。

因此也能理解为什么 Torvalds 的回应听上去像是傻瓜，因为他把邮件串内的 AI 反对者都当成傻瓜、从未使用过 AI 工具、仅是在追求社会认同、无法深度思考。

但我们都很清楚 AI 工具的问题，这显得 Torvalds 突然说「你们都没有使用过 AI 工具、是傻瓜」非常莫名其妙，荒谬的回应再对比邮件串之前其他人的讨论，意外令人忍俊不禁、喜不自胜、哑然失笑、释怀了。

不抖机灵了说回意识形态。

开源本身明明也是意识形态结的果。Torvalds 对于开源的看法，在我意料之中，虽说我其实根本不熟他…… 不过《大教堂与集市》这本书给我的刻板印象便是，开源运动早期的发起人都喜欢功利和实用主义，以及和商业有所关联的利益。

我想起几个月前在网络上看到的言论截图，可惜我没有保存图片的习惯，内容大致是一位网友赞叹一部电影没有任何意识形态、实属难得 —— 这怎么可能呢？于是立即有人反驳说该电影实际上有某某意识形态，叫他不要做白日梦、把自己不喜欢的意识形态简单定义成所有意识形态都有问题。

Antoine Destutt de Tracy 于 1796 年创造了 idéologie 这个词儿，原意是「观念的科学」、「思想体系」，也就是一门研究观念是如何产生的科学。

但渐渐地，它被制度化、工具化。例如在中国，它的含义愈来愈接近斗争概念。斗争概念会生产敌人，主流意识形态之外的都是「错误的意识形态」。值得注意的是，此处的敌人并非「被发现」，而是「被划分出来」。只要意识形态斗争还在，就必须有一个意识形态上的敌人存在，否则这个词儿就会失业。

明明它属于解释「世界」的「语言」—— 这套说法见这里 —— 但是人们说到它总会联想到宣传、站队等行为。

但关键悖论也在于，「我没有意识形态」本身也是意识形态，还是最危险、最成功的一种意识形态：它成为了中性的现实、常识、纯粹客观，它统治了世界。人们不再需要说服他人，因为大家本来就这么想。

最后是「不爽就 fork」。开源的一大好处便是如此，不爽就能创建个新分支出来。然而让毫无资本支持的社区贡献者滚去自己 fork，表面上是提供了选择自由，但其实悄咪咪掩盖了结构性的压迫。

Linux 内核这种巨大规模的项目，代码提交早已被大型科技巨头的雇佣员工所垄断。资源与权力在结构上极度不对等，社区个人根本不可能持续维护一个内核分支。

现实中企业对于「劳工缺乏保障」一事，有着「你可以自由选择换工作」的解释。可是「权利」不等同「能力」，大家该妥协的依然在妥协 —— 环境烂，那你可以走啊。没人在留你。什么意识形态不意识形态的，我没有意识形态。

RE：美国梦与美国痛华裔新移民青少年帮派犯罪

2026-08-03T16:38:00.000Z

「美国梦」是可以变成「美国痛」的；华裔青少年也可以和帮派有所联系。

原文链接： https://myhunan.us/美国梦与美国痛 - 华裔新移民青少年帮派犯罪/

该文章原本是发在《侨报》上的，推断时间是在 2010 年 9 月的上旬或往前。我贴的链接是旅美湖南同乡会所转载的版本，datePublished 写的是 2010 年 9 月 14 日。

《侨报》或称 The China Press 是美国最大规模的中文日报之一，与《世界日报》、《星岛日报》、《明报》并称美国四大中文报 —— 我倒是没有阅读报纸的习惯。家附近《大纪元时报》的报纸更多，也是法轮功学员创办的。

而该篇报道是摄影记者李竑写的。他经常报道纽约华埠（唐人街）、华人社区以及移民相关的议题。

这篇是他采访了长期调查华裔新移民青少年帮派犯罪的执法人员后所撰写的。

2010 年的过去 30 年，即 1980 年开始，美国青少年帮派剧增，原因主要在于移民的大量涌入，以及毒品交易猖獗。

关于为什么新移民青少年要加入帮派，文章中认为深层根源出在家庭上。父母一代都成长于文革年代，价值观混乱、仅在乎钱，不知道如何教育孩子。

其中最典型的情况是父亲偷渡来美赚钱、妻儿留守国内。长期分离的家庭导致孩子缺乏安全感。乡村风气也普遍是「去了美国就能富起来」，让孩子们错认为日后必去美国、去了美国就不用努力了，于是荒废学业、无心学习，文化水平自然也低。

我的一表弟就是这种情况：父亲移民先来美国工作，当时他们那儿的风气就是来美国能变有钱。

父母辈多生于 50-70 年代，经历过文革和改革开放。前者批判了传统伦理道德，后者又是市场转型，价值观难免会金钱化。这些父母的教育往往要么是放任，要么就是仅谈钱和出人头地。

表弟因此也觉得作为高中生，未来必定来美国了，那还考个毛高考啊。我出去洗盘子能把老板店买下来，你努力高考上大学，毕业后能找到工作吗？所以他近乎是放弃了高考，也没有继续学习，直接移民了过来。

后果是，他没能事先调查好在美国要如何生活。是，你洗盘子可以生存下来，但作为年轻人，不可能只有「生存」，而没有「生活」吧？没有说英语的技能，在美国基本上只能在华人圈的底层打转。

更别提语言、文化差异，还有华人外的种族歧视了。本来在家乡过得好好的，现在来了美国不过是底层人，连话都说不明白，极大的落差会引人绝望、误入歧途。

表弟刚来时，他父亲还问我能不能帮他找个大学上上。不过这件事后来不了了之，因为表弟被他父亲送去寿司师傅培训学校了。现在他应该在外州工作。能经济独立非常重要，因为文章内的大量被诱骗入伙的新移民青少年，就是没有经济独立、赚钱的概念，从而被小利吸引、酿下大祸。

在 80 年代末到 90 年代，福州的沿海农民渔民掀起偷渡潮，其中最典型的模式便是负债偷渡，然后在美国打工还债。

而 90 年代初期政府对未成年偷渡客的放任，被蛇头利用、做起了让大批 14-17 岁青少年乘船入境的生意。

在这些偷渡船上，人们按地域划分、靠拳头说话，青少年也初次体验到「暴力即力量」这种可怕的思想。

到了美国后，未成年的偷渡客在打工时容易被老板欺凌、克扣工资，敢怒不敢言 —— 没办法啊，你是偷渡客！老板愿意让你工作就已经是你的「荣幸」了！

他们很大可能在家里也不被关心，毕竟因为偷渡要很多钱，父母只能埋头工作还债，又因为没有英语、同为偷渡客、干的也是苦力活、被欺凌，受气后哪还管教育，直接把孩子当充气筒打一顿。

贫穷是可怕的。我经历过类似的事情，也不敢没有钱。高中的老师曾瞒着我将事情报告给了儿童局 —— 许多人可能会认为在美国，儿童很重要、打不得。但是孩子什么都不知道，又哪能知道自己其实有一定的「权利」呢？所以很多时候是被父母威胁着「如果告诉别人，你就没有爸妈了！」然后为了自己可悲的、天生的爱父母的能力，忍气吞声挨打。总之儿童局介入后，母亲不敢打骂我了，我也可算是在肉体上逃离了暴力。

部分父母因为怕儿童局，而不敢打骂青少年。哎，这些青少年也有被忽悠进帮派的可能性在。因为打骂不意味着教育：不打骂同时也不教育，到头来还是没对孩子进行教育。他们怎么知道事情该怎么做呢？他们只知道有人叫自己进帮派，进帮派做事情可以拿钱、玩女人、有社会地位。

在这样的环境下生存，再接触到帮派，会非常容易被诱骗。因为在帮派内，暴力就是力量。帮派会罩着你，只要你愿意花费一点点代价为帮派做事，还能吃香喝辣随意玩女人。压抑久了的青少年一听，自然容易上钩 —— 暴力、暴力才是这里的规则 —— 然后误入歧途。

为了表达忠诚，这帮青少年很容易出现群体极化效应，手段残暴到成年人都难以想象。这包括早期的绑架勒索、强暴女性…… 后来政府严打偷渡，帮派的重心又转向毒品交易，这帮青少年又拉拢身边朋友来吸。

泛华人家庭在教育上的一大问题就在于将「养育」简化成了「饲养与投资」。而真正的教育应当建立在以下心理和认知的建设上：

一、将孩子视为独立的精神主体。

这类父母常把自身的移民牺牲 —— 如「我辛苦打工都是为了你」—— 转化为对孩子的道德绑架。突然要承受这些「罪恶」的孩子，要么极度顺从且放弃自我，要么自暴自弃、通过自毁式反抗来切割负罪感。

必须要承认，孩子具备着独立的意识，有权拥有与父母不同的价值观、人生路线，乃至失败的权利。

我在昨天休息日与一位家长见面，他的思想令我惊叹：他会称呼自己上初中的孩子为 adult，并思考如何在「保护孩子」以及「归还掌控权给孩子」之间平衡。他认为他的孩子已经有了「自我」这个观念，父母不该再约束孩子去探索外面的世界。

二、建立有边界的规则；不要无底线去放任孩子。

部分父母会因为文化或自卑心理，在面对适应了新环境的孩子时失去话语权，进而放弃在秩序上的约束。

缺乏边界感的孩子在社会中会感到失控、主动寻找帮派这种提供「秩序」的群体来获取安全感。

三、提供心理安全感和情感链接。

无法提供情感支持与心理安全感的家庭，将会是孩子又一个需要戒备的地方。

大量新移民青少年在外界会经常遭遇挫折，比如语言不通、文化排斥和种族歧视。既然家庭也无法为其提供归属感和保护，他们自然也只能寻找能够提供这些东西的地方。

许多父母会在事发后责怪孩子「为什么不把事情都说出来」。其实日常的许多细节已经向孩子们证明家庭不够可靠、说出来反而会遭受原可以避开的责骂。

想法在丙午瓜秋迭代

2026-08-01T04:00:00.000Z

这个月我都在做项目，并且把打工给干掉了。虽是瓜秋，不过我并没有吃到多少瓜。总之七月过后，便是理论最炎热的八月了！也是开学的时候。我已经决定至少 gap 掉这个学期，但还是打算旁听一节 cybersecurity 的课程，好让自己的生活有些固定的行程。

本期导读

RE：Post-political

2026-08-01T00:41:00.000Z

Cory Doctorow 在我的博客内没少出现，最早他出现在今年一月份的月刊内。现在感觉只说他是个数学权利活动家，有些小瞧他了。他在政治方面也写过许多内容。

原文链接：https://pluralistic.net/2026/07/08/wilhoitian/

Doctorow 的这篇文章，主要是呛呼吁摆脱左右部落主义的中间派，以及否定马蹄铁理论的。

部落主义原本指的是原始社会中人类以血缘、氏族为纽带建立的强凝聚力群体 —— 嚯嚯我想到了非洲的葬礼 —— 在现代政治中，指的则是人们不再基于理性的讨论或者经济阶级来选择阵营，而是基于身份认同形成的「非我族类，其心必异」的帮派化对立。

而他主要攻击的「中间派」，指的是当下西方 —— 特别是美英政治圈 —— 中非常流行的建制派精英。他们的特征是：

认为自己才是唯一成熟的人
批判左右两翼都太极端、盲目、陷入了部落冲突
宣称政治应该去意识形态化，抛弃过激的立场，回到理智、温和、妥协、技术官僚式的管理上来

虚假的「极端左翼」

Doctorow 指出这帮人喜欢搞虚假的比较：竟将到处绑架杀人的极端右翼和要求加沙停止种族灭绝的极端左翼划为一谈，实在是太奇怪了。

不过这一段我得挑个刺儿：极端左翼里也包含着红色高棉、光辉道路等案例，更不用说中国人更熟悉的大饥荒和文化大革命等死了很多人的事件。不过终究还是挑刺儿，因为我清楚 Doctorow 想要聊的是现在美国的主流极端左右翼。共产主义的事情之后倒是会再提到。

他在文章中提到，极端左翼只是在搬运一些 zine 而已，然后作为证据、贴了个链接 —— 读他的文章就这点不好：他非常喜欢在文章中贴链接，尤其是自己的文章。而这会让我陷入无穷无尽的兔子洞 —— 哎，我也贴了？—— 哎呀，也没有说这不好的意思，只是说我读完一篇后都已经不知道现在几点了。

该链接讲的是去年 Texas 的一新闻：有八个人因为参与当地读书会、拥有无政府主义文献，还反 ICE，所以被指控向恐怖分子提供物质，判处 30 到 100 年不等的监禁 —— 这不是完全违反了第一修正案权利吗？：

Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
国会不得制定有关下列事项的法律：确立一种宗教或禁止信教自由，剥夺言论自由或出版自由，或剥夺人民和平集会及向政府要求伸冤的权利。

事情的起因是，去年七月四日晚上有一批人在 Texas 的 ICE 拘留中心外抗议，表达对移民拘留者的支持。他们破坏了些公物，随后有警察赶来并拔枪，一名持枪抗议者也开枪打伤了该警察的肩膀。

尽管许多被起诉者当时根本不在枪击现场，甚至彼此并不认识，但陪审团最终裁定了那八人「向恐怖分子提供物质支持」等罪名成立。

为了证明这帮人是恐怖分子，联邦检察官列了大量莫名其妙的「罪证」。我就直接列举出来，你们自己感受下吧：

使用普通办公打印机、纸张裁剪机等「印刷机」
左翼政治小报（也叫 zine）
反警标语的贴纸
防跟踪的打折袋
加密通讯软件…… Signal？
收藏了女权主义、反人工智能、电影影评 —— 等等，什么？—— 等阅读材料
参加无政府主义读书会

然后「合理」推断他们参与了 Antifa（反法西斯）恐怖单元，并计划暗杀执法人员。

由此可见，这检方多么反智！因为那电影影评的标题和撒旦教相关，所以直接把这伙人当撒旦教教徒了！

Trump 两次任期都在利用反恐的名义打击 Antifa，现在后者已经被定义为美国本土的恐怖组织。不过我对 Antifa 了解不多，暂不赘述。

行政当局也试图将「支持跨性别意识形态」与恐怖主义挂钩。正好，被告里有多人是跨性别者，他们在监狱中遭受了剥夺激素治疗等恶劣对待。

这就是美国当局认为的「极端左翼」。

而 Trump 政府呢？他们做了什么？

他们关闭了美国国际开发署（U.S. Agency for International Development，简称 USAID），然后导致了数十万人死于传染病和营养不良。

还有其他更多列举不完的东西。真是难以想象我身边还有人支持他。

何为左何为右

因为两方都出现过使用暴力和威权手段，所以二者的意识形态内核就相似么？这是马蹄铁理论所主张的。

说来今年一月份的月刊其实有提到过该理论，不过完全不是用来政治话题上呢。

Doctorow 认为，只有完全不了解左右翼底层主张的人才会如此天真去相信该理论。

大部分政治学界对此理论的评价也是偏向否定的，因为手段类似不代表目的类似。

他们都在批评同件事情，所以他们达成了一致么？当然不是了。重点在于「为什么批评」、「究竟想要什么」。

作为证据，Doctorow 举了三个例子：

左翼批评早期参政权运动的诉求仅局限于富裕的白人女性，忽略了有色人种与底层女性；极右翼亿万富翁 Peter Thiel 和基督教主权派也批评参政权运动，因为女性根本不应该有投票权 —— 双方都觉得参政权运动做得不对，但你会认为两者达成了一致吗？
左翼批评新政当时为了妥协、排除了少数族裔、原住民和女性，保障做得不够彻底；新自由主义者与右翼财阀也极力攻击新政，因为社会保障、工会权利和公共福利应当被废除 —— 双方都攻击了新政，但你会认为两者达成了一致吗？
反 enshittification 的阵营批评早期互联网只有少数富裕、懂技术的特权群体能够享受到技术的解放红利；支持互联网垄断与 enshittification 的科技巨头也否定早期互联网给了用户太多自主权，居然能让他们使用广告拦截工具！—— 双方都批评了早期互联网，但你会认为两者达成了一致吗？

要了解政治，必须从根源出发，搞明白反对的人为什么反对，而不是因为他们都反对了、所以都是同个帮派。

我近期学到个概念，叫左翼威权主义，但它是心理学人格、特指喜欢用高压、不容异见的方式对待反对者的心理气质。它能证明的也只有「极端左翼和极端右翼里都有携带该气质的人」仅此而已。

可见左右翼共享同个特征，非常正常，但无法证明他们本质一样。

话说我也举个例子好了：我实际上反对代称文化，但这不意味着我是右翼，是吧？至于我为什么反对它，你后面就知道了。

Doctorow 在批评完马蹄铁理论后，进一步批评该理论的支持者还有中间派：不仅搞不明白「左」和「右」的含义，还愚蠢地 将一系列文化符号当成了政治。

我必须要引用这句话，因为我非常赞同它：

Mistaking cultural signifiers and identity markers for politics is centrism's most dangerous pathology, the thing that makes centrism the handmaiden of the right.
将文化符号和身份标记误认为政治是中立主义最危险的病态，正是这种病态让中立主义成为了右翼的侍女。

文章中他写了个直观的例子：世界被 150 个有钱、白人、顺性别、异性恋的男人统治，那么解决该问题的答案是把其中一半换成女人、有色人种、酷儿么？—— 左右翼的区别不在于「统治阶级由谁构成」，而在于「人们是否应该有一个统治阶级」。

Corey Robin 在书籍 The Reactionary Mind 或《反动派的心灵》中提到，保守主义的核心信念是「有些人天生就该统治，另一些人生来就该被统治」。

事实上，我和一位朋友也有过类似的对话。他说过同样的话，理由是这个世界上有愚笨、没有接受过教育的人，让他们也接手管理世界的话，世界会乱套。而我很好奇：为什么这些人没能接受教育？

这种对权威和上层人的迷信，会让保守主义的追随者们极易接受诉诸权威的说辞，例如 Trump 的「只有我能拯救美国」，然后大肆向这帮傻子销售金卡、烂手机、同名的 crypto 币。

再是保守主义会用个人选择来解释世界上的问题，如贫困、疾病和失业 —— 它们是结构性、系统性导致的，根本不是「因为一个人的选择而变成这样」那么简单。好吧，我忽然靠着美国对个人英雄主义的崇拜理解了一些事情。

因为问题都是个人造成的，那解决方案也必须是个人化的，而不是寄托于什么公共机构、法规…… 购买伪科学保健品、防辐射帽子吧！

追随者们也非常热衷于阴谋论，比如反犹主义的秘密金权帮派 —— 一定是犹太人这个所以导致我那个 —— 对了，分享个有趣的 slang 给你们吧：goyslop，指的是犹太人们为了让非犹太人（goy）都变肥所以推出的各种垃圾（slop）食品。你们从今日开始也可以如此称呼在吃的垃圾食品，借此将罪推给犹太人。快来试试吧！

好了不抖机灵了。历史上有许多右翼政治营销，在手段上和传统诈骗近乎一致。比如非常有名的 KKK 党；它由南方宣传协会（Southern Publicity Association）策划，整个 KKK 党实际是多层待销（简称 MLM）的结构：

招募新成员的党徒可以从 10 美元的入会费中抽取 4 美元，剩余资金由最高头目 William Simmons 和各地区头目瓜分
党徒必须购买长袍、人寿保险、特制圣经、头盔、蜡烛、佩剑、专门的长袍干洗服务，以及缴纳年度会费

但你又说不了什么，因为根据右翼骗子们的说辞，「邪恶组织才是导致你们这么惨的原因」，他好像确实说对了：你被邪恶组织欺骗了，又一步证明，哇，右翼骗子们说得对啊！更崇拜了。

可悲的是，这是美国的常态。Doctorow 以近乎一生都在被骗、最终尝试推翻美国政府却被枪杀的 Ashli Babbitt 举例，讲述了这种结构有多么常见、多么可恨。

而 Trump 关停了打击这些骗子的机构，让美国有更多的受害者。这些受害者们因为绝望，涌入以为能拯救美国、拯救自己的右翼机构的怀抱，成为了新的 Trump 民……

Doctorow 提到自己的朋友也因此成为了 Trump 民的一员。我借此想到我周遭的人都是为啥追随 Trump 的。当时 Trump 第二次任选，母亲因为是基督教教徒，所以受当地基督教教会的影响、成为了 Trump 的死忠粉之一。教会投 Trump 的理由或许也很简单吧：因为是教会，所以你要无脑选择共和党，不论他们派出的代表是谁。为此，他们甚至能不羞耻地宣传说 Trump 是上帝派来的又一个儿子 —— 呕！

不过 Trump 上任后很快，母亲这个铁公鸡就发现不对劲儿，因为经济越来越差了。Trump 又接连派出 ICE，害得所有人人心惶惶，让母亲恨透了他。

对于国内主流互联网中常提到的「黄 MAGA」，即去了美国后就疯狂投票给共和党、避免其他华人能移民来美国的人。这些人也是将美国视作权威，认为只有自己是最正确的、中国不过是蛆 —— 见网红甜甜圈，我忘了他的真名。他已经发疯、等死不远了。

我非常不理解美国的部分华人，整天仗着自己的空脑袋和在美国的身份，于是整天批判中国人怎么怎么样、外国人怎么怎么样。外国人是你爹啊？是你新祖宗啊？—— 这些是主观的情绪，应用场景非常有限。

总之，因为对「个体导致社会问题」这一叙事的执着，右翼非常痴迷于挖掘新闻上有问题的人是什么种族、用了什么性别标记 —— 嗯对，上述内容其实还停留在 Corey Robin 的「天生通知主」说 —— 或许在我的脑子里就没有「篇幅」这种东西吧。

回到对右翼的定义。Wilhoit 法则认为：

Conservatism consists of exactly one proposition, to wit: There must be in-groups whom the law protects but does not bind, alongside out-groups whom the law binds but does not protect.
保守主义仅由一个命题组成，即：必须存在一些受法律保护但不被法律约束的内部群体，以及一些受法律约束但不被法律保护的外部群体。

不过这跟整篇文章的主角「中间派」关系并不大，大的是这个：科幻作家 Steven Brust 认为右派主张财产权是人权的一种，而左派主张财产权是实现人权的工具。

如何更好地理解该理论呢？Doctorow 为我们准备了疫苗难题：新冠疫情爆发时的 2020 到 2021 年间，最贫穷的 85 个国家据预测得到 2023 年或者 2024 年才能接种疫苗。但这不是因为他们无法生产自己的疫苗，而是因为大型制药公司拒绝转让专利和技术。

如果你是右翼，那么财产权就是人权：专利是我的私人财产，我要捍卫人权，拒绝转让。

如果你是左翼，那么财产权就是工具：为了让人类活下去，我会搁置财产权，转让专利。

自然，这种说法是非常笼统的，但读者朋友们能理解就好。实际的划分没有这么简单。Doctorow 也承认，这仅是底层逻辑。

极端左右翼之间的共同点

原文理应在上一段话就下结论了，不过我想要延伸些新东西。

之前我不是说了，暴力的极端左翼是存在的嘛？是的，我们要来聊共产主义了。

这些极端左翼的暴行，名义上的目标是推翻财产或阶级等级制度。根据先前 Doctorow 所说的，他们完全可以像极端右翼那样，走向可怕的威权和暴力 —— 这和马蹄铁理论是两个不同的问题。只是在客观的果这个层面上来看，他们做了同样的事情。目的依然不同。

Hannah Arendt 的《极权主义的起源》，就有主张纳粹德国与斯大林苏联是极权主义的两个变体。虽然两者会共享部分结构性特征，但具体的意识形态内容还是各不相同。有趣的是这些结构性特征包括：

单一政党声称自己掌握了历史的客观真理，例如种族命运、阶级历史规律
不断制造新的敌人以维持恐怖统治的合法性
恐怖不仅用于消灭反对派，还被用来让社会中的每个人都活在互相猜忌、无法结社的孤立状态里
一整套包罗万象的意识形态，把过去现在未来都塞进一个封闭的解释体系，任何质疑都被当成历史或者种族的敌人

这套思维结构非常危险，不论它最终指向哪个终点 —— 就像纳粹，名义上说得很好。如果有听过 Hitler 在 1933 年的演讲，会发现很容易被他的话绕进去、感染，甚至觉得讲得很对 —— 因为人们都相信自己掌握了历史的科学规律，他们也就有了理由、为了那个保证会到来的美好终点，而去正当化眼下的苦难，并认为自己可以合法消灭任何阻碍者，因为他们是站在历史错误一边的敌人。

这样说下来，这和文化大革命那时发生的事情简直是一模一样：为了美好的未来和愿景，我能够文斗甚至武斗陌生人、身边人、家人……

调查期间我也得知了，Lenin 提出过先锋党理论：无产阶级自己不具备真正的革命意识，需要由先锋党，即一小部分精英来代表他们掌握真理、夺取并行使权力，并在必要时可以绕开普通民主同意、动用一切暴力手段，因为他们比群众自己更懂群众的真实利益。该结构和法西斯主义的「一小部分觉醒的精英有权用绝对武力重塑民族和种族」结构近乎相同。

Post-political 结尾主张，中间派的本质就是右派，因为他们从不聊「财产权 v.s. 人权」的话题，默认和维护了财产权的地位。

将上述的两个话题做成两个轴，叠加起来变成 2x2 的表格：

	多元主义（承认异见、渐进改良）	先锋或极权主义（自认掌握历史真理，可用绝对暴力推行）
财产权等于工具	社会民主主义、工会运动、合作社运动	列宁主义、斯大林主义、毛主义、红色高棉、光辉道路
财产权等于目的	古典自由主义、主流保守主义	法西斯主义、纳粹主义

直接去说左翼或右翼天生容易搞出暴行，自然是不行的，更精确的结论是任何声称掌握了历史或道德的真理、因此有权用暴力去实现它的意识形态结构都是危险的。

采用单一的「左 - 右」光谱，严重简化了现实。至少该有两根轴被拿出来分开讨论，即经济轴和社会或权威轴。不过现实的政策议题还是各走各的路。因此我很是反感有人直接过来问我我是左派还是右派 —— 什么的左？什么的右？说清楚呀！

基于我对校友们的观察，他们也会犯下将文化符号误当成政治本身的错误。「我是左是右」，他们压根不在乎我的具体主张是什么，更多是为了搞清楚我属于哪个部落、认同哪套文化符号。也就是说，这更多是个身份认同的问题，而不是政治哲学问题。

最后的最后，想必读者朋友你也明白为什么我反对代称文化了。没明白也没有关系，我之后还会提到的。总之下篇见！

RE：Why China got rich and India didn't

2026-07-31T21:33:00.000Z

David Oks 是位美国作家兼前政治活动家，他有自己的博客，看样子托管在 Substack 上。在我看来，他非常喜欢钻研一般人不会钻研的话题，例如非洲的葬礼、智能手机替 ATM 取代了银行柜员等等。这次，他也写了让我很好奇的话题。

然后是，我依然在调整我对 bucket posts、链接汇总、独立文章、回应类文章的定位。你能看到的是，这篇回应类文章并没有那么「回应」，依然具有月刊内强烈的复述属性；还有我弃用了全员都是「作者」的做法，因为感觉 call name 也不会影响。

原文链接：https://davidoks.blog/p/why-china-got-rich-and-india-didnt

对原文

在 1950 年，中印两国同样极其贫困。但到了 2022 年，中国的购买力平价人均收入已经达到了印度的 2.5 倍。同样，在 1987 到 2022 年间的 35 年，中国的中位数收入增长了 611%，而印度仅增长了 88%。

Oks 否认了许多传统的解释，比如因为中国比印度早改革、政策和文化不同等等。

他认为，中国之所以能实现经济腾飞，是因为在改革开放之前，国家就已经通过激进且残酷的手段现代化了社会，并积累了足够的人力资本。反观印度，他们传统的社会结构未被触动，也没做好基础教育，和改善卫生。

1950 年，中国颁布了《新婚姻法》，打破了宗教、地主、家长制对个人的束缚，也解放了妇女劳动力、消灭了阻碍劳动力自由流动的传统社会关系。

到了毛泽东时代，虽然经济政策一直在失败，AKA 臭名昭著的大跃进，但在基础教育和卫生领域上投入巨大。不仅人均寿命提升，婴儿死亡率大幅度下降，女性的识字率也提高了。

同一年，印度总理也试图通过《印度教法典草案》以实现类似的社会改良，即赋予女性财产继承权、废除多妻制等等，但因遭遇印度教传统势力的强烈抵制，而锒铛流产。所以宗教、种姓制度、家族的束缚，还有土地的利益链条至今依然保留完好。

更为可惜的是，总理将大量资源倾斜于培养少数精英的顶尖技术院校，却忽视了普及性基础教育和医疗。印度长期存在着极高的文盲率、儿童营养不良率，以及极低的女性劳动参与率。

妇女劳动力是我感觉很有趣的思考方向。假设一个国家的人口是男女各占一半，让女性加入到劳动中，意味着理论劳动力会增加一倍。

但在传统的封建农业社会中，家庭是封闭的生产与消费单位。宗法观念 —— 养儿防老、传宗接代等等 —— 为什么会存在？因为男性在体力劳动中占绝对主导。当时也没有什么社会保障，男性无可厚非地成为了家庭的核心，而女性会因为嫁娶而变成「泼出去的水」，成了流失的资产。

国家强行推动行政性平等后，集体经济体制暂时地掩盖了宗法观念。因为生下的女孩下地干活就能为家庭挣来工分，变成了生产力的一部分。

不过 70 年代末，人民公社在农业生产上的弊端非常明显：干多还是干少，领到的饭都是一个量；工分评价标准模糊；农业生产率长期停滞；农民的生产积极性低落；大量农村面临解决不了温饱的困境。

于是中国在 1980 年代解体了集体经济，让劳动需求重新回到了「家庭」这一单位的怀抱中，宗法观念得以迅速复苏。

那时也有计划生育，限制了生育的数量。家庭迫切需要男性劳动力和宗法继承人，于是纷纷都更愿意去选择能传递所谓「香火」的男婴 —— 这也导致了那个年代极其严重的人为性别选择，溺弃女婴、B 超筛选。

一个政策有好的一面，自然也有坏的一面。这也不能简单说成是「代价」。我只是惊叹于我们无法做出最完美的选择。

总而言之，两国迎接全球化时，中国已然有准备好进入现代工厂的合规劳动力，印度却缺乏能够支撑大规模制造业、实现工业化的合格产业工人。

对评论

描述完 Oks 的观点后，我想再引入该文章评论区内的观点。

Ersatz economist 引用了发展经济学大师 Oded Galor 等人的观点：地主、教育与工业化之间有着恶性循环。

对于地主来说，如果投资公共教育，农民就会离开农村，去城里当工人。结果便是农村的劳动力流失，地主不得不提高工人的工资才能留住他们，这也直接导致了地主的土地租金收入下降，也是地主的主要收入来源。

因此，地主有着极强的动机去游说政府，阻止他们建设学校。同时，在名义上的民主制度下，地主可以轻易控制依附于自己的农民的选票，或者通过砸钱和联姻来控制地方官员。

既然地主阻碍了教育，那么农民就会没有文化；既然农民没有文化，那么工业会因缺乏合格工人而无法继续发展；既然工业无法发展，那么经济会继续高度依赖于农业；既然经济依赖于农业，那么地主的地位依然稳固，继续阻碍教育 —— 这便是恶性循环。

中国消灭了地主阶级，打碎了该阻碍，从而能够无障碍地向基础教育和卫生投资。而印度虽然有民主制度，但由于未能推行彻底的土地改革，地方政治依然被大地主和种姓精英把持，从而陷入了上述循环。

但该评论接下来的内容，我并不赞同。Ersatz economist 认为 Oks 未能注意到中国做错的地方，理由是日本、韩国和台湾都打破了该循环，且变得比中国繁荣得多，还不需要付出惨痛的代价。

首先这三个经济体比中国繁荣得多，该说法非常主观。Oks 对比中国和印度的一大理由，是两国都曾非常贫困，且人口特别特别多。日韩台的人口恐是加起来也只有中国或者印度人口的十分之一。如果在人均 GDP 或者社会福利指数上做比较，该结果很不公。

同时，他们仨都曾在冷战时期获得了美国大量的资金、技术和市场扶持，单是拥有的外部红利就已经够中印二国追许久了。

接着是「没有彻底颠覆社会、没有造成无估量痛苦」这句话，完全就是非亚洲人对这三个经济体现状的浪漫化，也是我非常讨厌的态度。

我在美国时常会遇到怀有这种想法的人，认为日韩台是通过温和、渐进的手段自然过渡到现代社会的，并以此大力批评中国的发展方式。他们简简单单无视了日韩台所经历过的痛苦，只为能够合理化、客观化自己对中国的厌恶，甚至说这种厌恶，不过都是新闻让民众们想要有的情绪罢了。

我不为中国曾经做过的极端行为开脱。正如我先前就讲过的那样，中国是通过激进且残酷的方式来让社会现代化的。它有着好的果，但我不会轻飘飘说其中的「残酷」不存在。

日本在二战惨败、吃了两颗原子弹，国土也被美军全面占领，这才清除了地权的国有化和军国主义势力；台湾的国民党政府先是在大陆战败、在台湾群岛带来了不知几十年的白色恐怖后，才推行土改；韩国在完成土改和汉江奇迹之前，已经经历了朝鲜战争，以及经历了长达数十年的军政府独裁统治 —— 这一切，却要被后来者说成是「没有彻底颠覆社会、没有造成无估量痛苦」吗！

这样想来，我会如此愤怒还是因为该评论的一部分让我回想起大学时认识的一位校友。他虽长着中国人的面孔，却不了解中国，且无比厌恶中国。所谓喜欢的日本和韩国，都被他用来和中国做比对，以此来证明中国更卑劣。这也包括但不限于凭空捏造这三个国家的经济情况、文化还有习俗。

我在大学时上的比较政治课，也会常看到局限于西方视角下、对于东方国家的评价。简单来说，便是偏见优于事实。大家反复说着媒体、新闻、网络上说过的话，根本不去了解背后的历史，令人感到做作 —— 这难道也是一种虚构？—— 这是我第几次引用它了？我频繁使用「虚构」一词也是一种「做作」吗！

较为好笑的是，评论区有人认为这一切都是因为 IQ，即中国人有着更高的 IQ，而印度人没有。在比较政治的话题里，总是难免会看到偏离客观和事实的言论。毕竟某某国人是个庞大的标签，将人们分成了不同的群体。说某个国家的人有着高 IQ 什么的，难道没有考虑过 IQ 这种衡量制度很有问题么？—— 参见该播客 —— 考虑了下最后放的是 Apple Podcasts 的链接，不知道有没有更好的播客平台呢？小宇宙似不是什么好选择。

洗澡和洗头发

2026-07-31T04:00:00.000Z

人很闲的时候总要找点新东西倒腾，我这周就闲得没边：项目谈燶了、放着 aigent 修死 bug。我一闲我就读 RSS、我就写东西玩。所以你想要知道我闲不闲，你就看我更新博客更新得频不频 —— 你看，我最近一周更新了仨，这是第四篇。

我的思维跳跃不知道正不正常：这个月 24 日我在 Fediverse 上发说有人投诉我们这户大半夜有噪音、像是在运动。那咋可能啊。我就不运动。就算要运动，也是大半夜出门跑步。不过最近下雨，也没有运动的心情，再加上我跟室友天天凌晨一两点才从共享办公室那儿回家，大半夜谁还在房间里动来动去？匹克猫吗？

这让我想起来，以前有人跟我科普说，国内的小区楼不总有人吐槽说楼上小孩在玩球、球掉到地板的声音特别吵么？那其实有可能是管道发出的声音。

哎，一说到「科普」，我又想起来之前有人科普跟我说洗澡不用沐浴乳更脏、不如不洗，因为水会滋生更多的细菌，所以要么不洗、要么洗了用沐浴乳。

那会儿我年纪尚小，还在中文互联网上冲浪。那个人是假借「科普」的名义，来地域歧视北方人的，因为他觉得北方人都脏、不常洗澡，有些洗了还不用沐浴乳。

我好奇，你仅用水洗、水会滋生细菌，那你洗完把身体擦干净不行吗。

不过这还不严谨，仅用水洗澡就一定不行？这可不行，我的好奇心被激发了！

根据 SCIENCEINSIGHTS 的说法，单用清水搓洗能把手上的细菌减掉一半，而用肥皂能减去更多。这一点已经能看出，仅有水洗是可以影响到身上的细菌量。

而美国疾病控制与预防中心（Centers for Disease Control and Prevention，简称 CDC）在 FAQ 页面里说：

Water itself does not usually kill germs; to kill germs, water would need to be hot enough to scald your hands.
水本身通常不能杀灭病菌；要杀灭病菌，水的温度必须高到足以烫伤你的手。

意味着水本身不具备杀菌的能力，除非烫得不行。水在清除细菌这一工作上，最大的贡献便是把它们冲走。

而肥皂更好的原因是：

Using soap to wash hands is more effective than using water alone because the surfactants in soap lift soil and microbes from skin, and people tend to scrub hands more thoroughly when using soap, which further removes germs.
用肥皂洗手比只用水洗更有效，因为肥皂中的表面活性剂能将污垢和微生物从皮肤上剥离，而且人们在使用肥皂时往往会更彻底地搓手，从而进一步清除病菌。

所以「仅用水」跟「使用肥皂」，只是「好」跟「更好」的差异，不可能比「不洗」差。

不过这些重点在于「洗手」，而非「洗澡」。我们可以看看皮肤科院长朱芃年的看法：

可以不用沐浴乳、肥皂洗澡，只用清水洗澡可以將水溶性的污垢去除，但對於油溶性的污垢或髒污就難以去除。比如說身上代謝的廢物有好一部分都是油脂性的，就很難清除乾淨，尤其是這些代謝性的廢物也是微生物的最愛，如果微生物在身上過度繁殖就容易會有臭味產生。

啊我需要贴转换成简体字后的结果吗？有点懒哎。我相信读者朋友们还是看得懂的。

汗水又怎么办呢：

使用清水可以將一般水溶性的代謝物清除，但對於油溶性的廢物就沒有辦法。雖然夏天汗水的分泌是遠大於油溶性的分泌，但油溶性的代謝物才是產生味道的重要關鍵。這些代謝物就是微生物的食物，如果太多累積在皮膚表面就容易引起微生物的過度孳生，其中的結果就是產生惡臭或感染。

这些都能看出，水去不掉油溶性的代谢废物，也就是皮脂。这些是产生恶臭、感染的罪魁祸首。腋下、脚等皮脂密集的部位，得使用清洁剂。其他部位用清水足矣 —— 不过个体差和环境因素导致这句话也不咋严谨就是了。大家看着情况弄吧。

文章中也提到：

過去會有皮膚科醫師提倡「異味性皮膚炎」或「長期乾性濕疹患者」使用清水洗澡，因為要減少去除表面皮脂膜的皮脂，降低皮膚發炎程度的目的。但這樣的作法讓這些患者很容易產生相距五公尺就可以聞到這個人在旁邊的窘況，造成被人疏離。
這個做法，雖然還有一些皮膚科醫師還在施行，但已經比較沒有辦法符合現代社會人與人相處的標準，尤其是異味性皮膚炎的年輕患者，同儕的疏離，心理沒有辦法調適。現在醫療輔助產品的進步，已經有適當的產品提供給這些患者，避免異味，也可以少量去除皮脂或甚至補充皮脂缺損。

所以也要搞清楚自己皮肤是什么状况，莫要强行套用公式。

顺带一提，会选这篇是因为它还聊到了月经期间该怎么洗：

使用清水可以將月經週期的經血與分泌物去除大半，可以達到清潔的目的，但由於私密處專用的清潔劑目前也很發達，通常都會建議弱鹼性的清潔劑，較易維持私密處微生物的平衡，以減少常見私密處感染的機會。所以只要經濟條件許可，都會建議使用專用私密處清潔劑為私密處清潔與保養。

我有使用过私密处专用的清洁剂，洗完非常舒服。对于男性也是一样的。要多多清洁私密处啊！

还有最佳的洗澡频率是什么呢？只是让皮肤健康的话，两到三天一次就可以了（也得看地区）—— 这也太长了吧！现在我认识的人们，都是一天一次。文章不建议超过一天三次。

日本的 Jisin 有出过支持清水洗的文章：

もちろん、肌を清潔に保つことはとても大切です。汚れや雑菌は、9 割方が流水だけでおちます。シャワーで体や頭を洗い流しましょう。その後、石けんをよく泡立てて、手で軽く洗えば十分です。頭も肌と同じで、軽く洗うだけで OK です
当然，保持皮肤清洁非常重要。污垢和杂菌，9 成左右仅靠流水就能冲掉。用花洒冲洗身体和头部吧。之后，将肥皂充分揉搓出泡沫，用手轻轻清洗就足够了。头部也和皮肤一样，轻轻清洗即可。

文章中采访的五味常明院长提出了个有趣的说法：

表皮ブドウ球菌は肌の上で遠慮がちに生活しています。そのため体をゴシゴシ洗うと、表皮上の表皮ブドウ球菌の 99％が流されてしまうのです。そのうえ、皮膚善玉菌の餌となっている大切な皮脂の膜までも流れてしまうのです。残った表皮ブドウ球菌は必死にもともと存在していた数に戻そうとしますが、それにはじつに 24 時間もかかります。その間に表皮ブドウ球菌よりも強い、黄色ブドウ球菌などの雑菌がここぞとばかりに増殖してしまうのです
在健康的皮肤上，表皮葡萄球菌占绝大多数，因此被称为常驻菌。如果把它想象成肠道内的双歧杆菌那样的存在，即「皮肤益生菌」，就很容易理解了。这种菌越多，身体就能保持良好的气味。然而，由于某种原因，当散发恶臭的细菌（换句话说就是「皮肤有害菌」）数量超过了皮脂上的益生菌时，形势会瞬间逆转。它们会开始产生以脂肪酸和氨等为原因的不快异味。

我先前学习到过，无菌环境对小孩子的发育而言并不好。人类体内就是有良性的菌群，不论是皮肤上，还是肠胃里。一味杀菌，反而可能坑害了孩子。

忘了在哪里看到的膳食指南中也提到，腌制食品在制作时，会发酵出良性菌。吃进肚子里，丰富了肠胃中的菌群，能为人体带来许多好处，例如更好地去吸收植物内的矿物质。

为此他认为：

本当は、毎日入浴して体を洗う必要もないんです。せめて入浴しながら「肌を休める日」を、3 日に 1 度作るといいでしょう
其实，并没有必要每天都洗澡擦身。建议至少每 3 天设置一个「肌肤休息日」，在洗澡的同时让肌肤得到休息。

这一点和上篇文章中所说的相似。为了让皮肤健康，不需要天天洗，主要是考虑到了现代人的卫生习惯。

同样的想法也能在德国的皮肤科专家那儿看到。

皮肤科医生 Yael Adler 说：

Demnach sollten Menschen, die täglich duschen, hauptsächlich Wasser verwenden. Es hat einen neutralen pH-Wert, trocknet die Haut weniger aus und sauber werden Sie auch nur mit Wasser. Schließlich sind Staub, Schweiß, Hautschuppen und sogar Urin wasserlöslich.
因此，每天洗澡的人应该主要使用清水。水的 pH 值呈中性，对皮肤的干燥程度较低，而且仅用清水也能洗干净。毕竟，灰尘、汗水、皮屑甚至尿液都是水溶性的。

Schwitzige Stellen wie Achseln, Leisten, Pofalte und Füße sollten Sie regelmäßig mit Duschgel oder Seife waschen. Für den Rest genügt aber auch Wasser, so Hautexpertin Yael Adler.
腋下、腹股沟、臀缝和脚等容易出汗的部位应定期使用沐浴露或肥皂清洗。皮肤专家 Yael Adler 表示，对于身体的其他部位，只用水冲洗就足够了。

Utopia.de 引用了数位皮肤科专家的说法：

Dem Spiegel gegenüber empfiehlt Erhard Hackler von der Deutschen Haut- und Allergiehilfe sogar, bei häufigem Duschen auf Duschgel zu verzichten. Stattdessen könne man nach dem Duschen mit reinem Wasser einen parfümfreien Deostick verwenden.
德国皮肤与过敏援助组织的 Erhard Hackler 甚至向《镜报》建议，如果淋浴频繁，应避免使用沐浴露。相反，在用清水淋浴后，可以使用不含香料的止汗棒。

Denn bereits Wasser allein schädigt die Hautbarriere, warnt Bernadette Eberlein, Oberärztin an der Klinik und Poliklinik für Dermatologie und Allergologie am Biederstein der TU München. Duschgel und Seife verstärken ihr zufolge die Schädigung. Denn sie lösen Fette, die die Haut schützen, aus dieser heraus.
慕尼黑工业大学比德斯坦皮肤与过敏科副主任医师 Bernadette Eberlein 警告说，即使单单是水也会损害皮肤屏障。据她所说，沐浴露和肥皂会加剧这种损害，因为它们会溶解并洗去保护皮肤的油脂。

Ob mit oder ohne Seife: Tägliches Duschen ist für Menschen mit normaler Haut meist nicht nötig, wie die Dermatologin Stefanie Derendorf gegenüber Utopia in einem Interview erklärt. Ungesund ist es für diese Menschen aber auch nicht. Derendorf zufolge ist es in manchen Fällen sogar sinnvoll, sich täglich zu duschen – beispielsweise, wenn man geschwitzt hat oder Schmutz auf der Haut hat. Für Menschen mit trockener Haut ist es laut der Expertin dagegen schädlich, täglich zu duschen.
无论是否使用肥皂：皮肤科医生 Stefanie Derendorf 在接受 Utopia 采访时解释说，对于普通肤质的人来说，通常不需要每天洗澡。但对这些人来说，每天洗澡也并非不健康。Derendorf 表示，在某些情况下，每天洗澡甚至是有意义的 —— 例如出汗后或皮肤上有污垢时。然而，对于干性皮肤的人，专家认为每天洗澡是有害的。
Beim Duschen, so erklärt sie weiterhin, muss nie der gesamte Körper eingeseift werden. Regelmäßig, aber nicht täglich, sollten talgdrüsenreiche Zonen und Zonen, die viel Schmutz abbekommen, mit Duschgel oder Seife gereinigt werden. Dazu gehören die Hände, die Achseln und die Füße sowie Brust- und Rückenmitte. Am restlichen Körper reicht demnach Wasser zur Reinigung.
她进一步解释说，洗澡时永远不需要全身涂抹肥皂。应定期（但非每天）使用沐浴露或肥皂清洗皮脂腺丰富及容易沾染污垢的部位。这包括手部、腋下、足部以及胸部和背部中央。身体的其他部位只需用水清洗即可。

我看不懂德语，所以没法用 [...] 遮住不需要的部分；你们只能文章上有啥读啥了。

综上所述，我们能得出：清水可以洗掉身体上绝大多数的脏东西，但是无法去掉油溶性的皮脂，而它们才是产生异味的大头。不过过分使用肥皂、沐浴乳，反而会损害皮肤健康。重点在于如何平衡、找出最适合自己的方案。

于是我的思维又跳跃了。我想到了过去又有人跟我科普说：洗发水越用头越容易痒，用清水洗过段时间就不痒了。之后就是他对消费主义和资本主义的批评 —— 打住！我们只说洗澡和洗头发！

我的洗头频率一向是隔一天洗一次。偶尔能隔两天，但是不能赌，否则第二天头就油油的、痒痒的了，我也不乐意大早上起来洗头发。不过我在完全没有认真调查时，就已经开始试验这件事了，可以在这个串内查看我都在干啥、什么心理状况 —— 冲动便是如此，呵呵…… 我原来是冲动驱动行动的类型。

第一晚不用洗发水洗完，头发上明显有层油。手摸上去很不舒服，感觉像是摸了一手蜡？所以之后还是去搜了下，得知该方法叫作 no-poo，即 no shampoo 的意思 —— 会让人联想到其他不好的东西 —— 日本有个相同的概念，叫作「湯シャン」。根据宣传，它对头皮更加温和、能让头发更健康。

根据皮肤科医生 Knox Beasley 的说法，许多洗发水含有硫酸盐，虽然能让头发变干净，但久了也会变干燥、脆弱。

日本的 NATURAL AGA CLINIC 的文章则说了更多的东西。

シャンプーによる過度な脱脂がなくなることで、頭皮が「反応性の皮脂過剰分泌」を起こしにくくなる場合はあります。これは皮脂分泌が減るのではなく、頭皮環境が安定しやすくなるという意味です。
由于消除了洗发露带来的过度脱脂，头皮有时会变得不容易发生「反应性皮脂分泌过剩」。这意味着头皮环境更容易趋于稳定，而非皮脂分泌减少。

这段话暗示了洗发水过度去油反而会导致皮脂过多分泌。

乾燥しやすい頭皮の人がシャンプーの使用頻度を減らすと、皮脂膜が保たれやすくなります。頭皮の乾燥が原因のフケやかゆみが出ている場合、湯シャンによって改善が期待できます。
容易干燥的头皮如果减少洗发露的使用频率，皮脂膜就更容易维持。如果是因为头皮干燥而出现头屑或瘙痒，清水洗头有望带来改善。

所以干燥头皮的人更适合清水洗头。

它也不是简单的「不使用洗发水」，而是有着详细的步骤：

洗之前先梳头，预先去掉头发上的灰尘和污垢
用温水打湿头发
用指腹，而不是指尖，在头皮上画圈圈按摩，直到头皮不再有油腻感
洗完用毛巾轻轻吸干头发上的水分
先吹干发根，不要烘烤头皮，快干时切换冷风

初次洗后，出现油腻感很正常，因为是适应期。这时候的头皮还处于过去因洗发水而过分分泌油脂的阶段。而水，之前已经说过了，是去不了油的，仅是把它们冲走。

事实也是我第三次 no-poo 洗头时，头发就没有那么油了。写这篇文章的时候则是第四次 no-poo 洗头后的第三天，仔细摸头发也能摸出一点点油，总之肯定是没有用过洗发水后的触感，但整体油腻感在随时间和次数而下降。

不过，这两篇文章都不建议 no-poo。

Beasley 说：

Build-up can lead to potential scalp issues. Over time, washing with only water may lead to scalp build-up, especially if you don't remove natural oils, sweat, and environmental pollutants. This can result in itchiness or flakiness, and people with sensitive or dandruff-prone scalps might find that water-only washing exacerbates conditions like dandruff or psoriasis.
堆积物可能导致潜在的头皮问题。随着时间的推移，如果不能清除天然油脂、汗水和环境污染物，只用水洗头可能会导致头皮堆积。这可能会引起瘙痒或脱屑，头皮敏感或易患头皮屑的人可能会发现，只用水洗头会加重头皮屑或银屑病等状况。

单用水是无法有效去油的，尤其是头发的构造会堆积油脂。清水仅能冲走部分油。

他给出的一些解决方案分别是：

用苹果醋
清洁型护发素
特定用于 no-poo 的护发产品

NATURAL AGA CLINIC 补充道：

皮脂が過剰に残る環境では、マラセチア菌が増殖しやすくなります。マラセチア菌が増えると脂漏性皮膚炎の原因になり、フケやかゆみが出るリスクが高まります。
在皮脂过剩的环境下，马拉色菌容易滋生。马拉色菌增多会导致脂溢性皮炎，增加出现头屑和瘙痒的风险。

同时反驳了「多用清水洗头皮会越来越不油」的说法：

「湯シャンを続けると皮脂分泌が減る」という口コミがありますが、この点はエビデンスで慎重に検証する必要があります。皮脂の再分泌に関する研究では、洗髪後 24 時間で皮脂量がほぼ元に戻ることが確認されています。
虽然有「坚持清水洗头会减少皮脂分泌」的说法，但这一点需要通过证据进行谨慎验证。关于皮脂再分泌的研究确认，洗发后 24 小时内皮脂量几乎会恢复到原始水平。
つまり、湯シャンを続けても皮脂の分泌量自体は大きく変わりません。「湯シャンで頭皮がサラサラになった」と実感する人もいますが、皮脂分泌のメカニズムはホルモンバランスや遺伝的要因に大きく左右されます。洗い方を変えただけでは、根本的な改善にはつながりにくいのが現状です。
也就是说，即使坚持清水洗头，皮脂的分泌量本身并不会发生显著变化。虽然有人感觉「清水洗头让头皮变得清爽」，但皮脂分泌机制很大程度上受激素平衡和遗传因素影响。目前看来，仅靠改变洗发方式很难实现根本性的改善。

不痒很大可能并不是因为油变少，而是刺激头皮环境的因素没了。这样说，最需要做的其实是更换洗发水。

那么如何洗头呢？PubMed Central 上有篇针对亚洲人的研究：

In the epidemiological study, it was observed that overall satisfaction with hair and scalp condition was achieved when washing 5–6 times per week. This was consistent for both objective and subjective end points. Controlled treatment likewise showed that a daily wash regimen was superior to once per week cleansing for all end points. No objective detrimental effects to hair at this level of cleansing were observed.
在流行病学研究中观察到，每周洗头 5-6 次时，头发和头皮状况的总体满意度最高。这在客观和主观终点指标上均表现一致。对照治疗同样显示，在所有终点指标上，每日清洗方案均优于每周清洗一次。在此清洗频率下，未观察到对头发有任何客观的负面影响。

The subjects in this study self-assessed their condition as dramatically better at the higher wash frequency: reduced oiliness, more healthy, less frizz, less dull, less dry, and reduced breakage.
该研究的受试者自我评估认为，在较高的洗发频率下，他们的头发状况显著改善：油腻感减少，更健康，毛躁减少，暗沉减少，干燥减少，且断裂减少。

There is little doubt that increased wash frequency is beneficial to scalp condition. However, the data also strongly support that for the Asian populations studied, hair condition is not negatively affected by increased wash frequency and that the self-perception is toward marked improvement.
毫无疑问，增加洗发频率对改善头皮状况大有裨益。此外，数据还强有力地证明，对于所研究的亚洲人群而言，增加洗发频率并不会对头发状况产生负面影响，且受试者的自我感知趋向于显著改善。

这就特别有意思了，因为洗头跟洗澡的逻辑是相反的。过去以为的「勤洗头有害头皮健康」是假的，反而是近乎每天洗头才更有益、更让人满意。

不过该实验结论的大前提是：使用了温和的去屑洗发水（还是宝洁的），实验者也都是健康直发的亚洲人。

对于强烈硫酸盐洗发水，天天洗则非常不推荐。先前介绍 no-poo 时已经说过了，它会过度去油，从而损害头皮，使其更干痒。

我们最该做的是结合个体的情况、洗发水的成分来平衡洗发频率。

对于一般情况的人而言，使用中性的非强力去油洗发水更好，避免使用带强硫酸盐的；如果是干性头皮的，用清水洗、少洗会更适合你；如果是油性头皮的，建议勤洗头；平日出汗多、用发胶的得勤洗；少汗的可以降频。

最后我想说件趣事儿。第一晚 no-poo 后，次日我觉得头发油油的，实在不舒服，于是起床搜了正确流程、洗了一遍，反而让我觉醒了新状态 —— 晨间洗澡！

过去我便有所听闻，外国人喜欢早上洗澡。原因是为了提神，以及早上出门形象更体面。东亚国家则倾向于睡前洗澡，这样就能把外面的脏东西挡在舒适的床外。不过「外国人喜欢早上洗澡」也算是刻板印象吧。

我是一回家就洗澡。原本的生活习惯是睡前洗，不过室友有洁癖，她无法容忍外面的脏东西碰到家里的任何物品，例如家具上，所以要求我一回家就得脱衣服、洗澡。久而久之，我也习惯了。

那次晨间洗澡后，我意外发现，自己明明刚起床，脑子却无比清醒，还感觉身体干干净净的，很舒服。

这也让我感觉很纳闷儿吧。睡眠期间明明也会分泌汗、皮屑细胞，为啥不早上起来洗掉呢？这样一整天也更干净。可是要放弃晚上洗澡吗？我也不想把外面的脏东西带到床上来啊。然后我想到，为啥我要纠结呢？我全都要不行吗？

为此我要先明白我的需求是什么。为什么我要早上洗澡？因为我要脑袋变清醒、洗掉睡觉期间分泌的汗还有皮屑。为什么我要晚上洗澡？因为我要清理一整天的脏东西。

先前我们已经提到，洗澡不一定需要使用肥皂、沐浴乳，仅用清水洗就可以把大多数的脏东西洗掉。那么已经洗过的身体，在经过一夜睡眠后，身上真的会那么脏吗？那我早上是不是可以不用肥皂洗？用更少的时间洗？甚至只用冲一下即可？于是我的做法是，起床冲冷水澡一分钟。不过并非全程冷水澡，而是先放温水适应，然后慢慢调成冷水。

既然这样，晚上的洗澡就可以是一次大清洁。我正常怎么洗，这个时候就怎么洗。如果需要洗头，也是这个时候才洗。

以上就是我这周在折腾的东西。下篇见！——

—— 我会看着你们清洁自己的（眼睛 emoji）。

RE：断层里的心理学

2026-07-30T04:00:00.000Z

我在尝试将过长的回应从月刊中拉出来、直接写成独立文章的做法。

和月刊内的回应不同，独立文章往往失去了「介绍该链接」的目的在，是单纯的「回应」。我不希望有任何人误认为我是在攻击谁，我只是就事论事。因此所有的作者的名字都会被我打成「作者」，不论我们是否有线上或者线下的关系。人身攻击是绝对不提倡的。

不过纯复述的内容，无论字数多长，都会被放在月刊内。

原文链接：https://blog.solazy.me/20260726/

复述原文

复述原文是非常重要的。甲去回应乙的观点，实际上并没有在回应「乙的观点」，而是在回应「甲以为的乙的观点」。这两者可以重合、是同个内容，不过这个概念要清楚。

复述能够用自己的理解，将对方的观点说一遍，因为这才是你要回应的东西。它可以极力避免产生误解。毕竟我复述错了你可以直接纠正我。

总之继续。

作者认为，心理学在结构上存在着严重的两头断层现象：研究性心理学毫无疑问是严谨的科学；然而在脱离了实验室与控制变量后，它缺乏在日常现实中操作的可能性。

在一般人能够接触到的应用层中，心理学会退化成一门极其依赖从业者个人状态、拼运气的谈话服务。由于下限不可量化，所以无资质的从业者和仅靠共情力聊天的人在实操中没有区别。

在这种断层下，试图通过阅读书籍和理论来自医的人，会掉入陷阱中：误以为可以拯救自己，但仅是学习了各类抽象还不实用的概念、为自己找借口、逃避现实问题。

即便是日常人际交往中展现出的观察力与边界感，也仅仅属于常识范畴，与科学心理学无关。

所以，大众应当对应用层中的理论以及咨询服务保持冷静距离。面对生活困局不应寄希望于看书或者付费聊天，而应回归最基础的逻辑，即通过剥离客观事实与主观演绎、明确个人边界并承担相应责任来解决问题。

我的回应

我不认可该文章所表达的多数观点。

首先是作者在探讨应用层时，直接将其和低门槛的话疗化为了一谈。

心理学的应用层存在着大量的科学干预手段，例如临床心理学家，再者还有精神科医生 —— 虽不属于心理学范畴，但依然需要接受临床心理学训练。现在的许多心理问题需要同时用到药物干预和心理治疗。心理咨询师跟话疗师是没有资质的。这是概念混淆，为此推导出的「心理学不是靠谱的科学」不合理。

我实际上也赞同「话疗无法解决问题」这个观点的，但用它去概括心理学的应用层都没有用，我不认可。存在逻辑错误。

其次是他断言「人际互动里的观察力和边界感跟科学心理学没有关系，仅是常识」，这是知识的诅咒：你不能因为自己已经知道了，所以默认他人也知道。

「常识」是非常主观的概念。许多今天理所当然的常识，例如婴儿有痛觉，是过去数百年来研究成果普及后才沉淀为常识的产物 —— 是的，以前美国给婴儿做手术不打麻药，导致婴儿全特么嗝屁了 —— 放在心理学的世界中，边界感、情绪表达的重要性、防御机制等，也是过去没有、现在变成常识的东西。

文章中并没有给出任何标准来定义为什么这些不是心理学，实在是太主观了。觉察他人的情绪以改善互动，属于社会心理学的应用，怎么会没有关系呢？

再者是将自医者的未见成效直接归罪为是在找借口逃避，过分冷酷、只关注于结果了。心理问题非常复杂，花费几十年甚至一生才能解决的心理问题比比皆是。它本就是非线性、长期，甚至可能反复出现且倒退的。归因为逃避、无能会否定学习者的努力或理智化 —— 一种心理防御机制。

有一点我得说明的是，标准化产出是不能用来强行套在心理学上的，因为心理学面对的是复杂的主体，属于软科学 —— 社会学和经济学也在其中 —— 个体的主体性不应被消除、简化成待解决的问题，也就是硬科学里会用到的方式。

因此我也认可「看书学理论无法解决问题」，不过我的理由在于二者之间没有直接性的联系，而是无数个非直接性的联系：改变需要心理上的安全、能够容忍情绪、反复实践行为，而这些都是学习理论之后的事情 —— 尤其对于带有创伤问题的人来说，知行合一的难度非常可怕，不能简单说是对方能力上的失败。

结尾文章说：

在面对具体的困局时，与其指望某种不怎么靠谱的底端心理学来拯救自己，不如先回退到最基础的逻辑上：把客观事实和主观演绎剥离开，守住边界，把该承担的责任承担起来。这往往比任何打着科学旗号却无法实操的理论，管用得多。

对于成长环境缺失安全感、认知模式存在偏差的人而言，如果不借助心理学理论的引导，他们无法天生就知道什么是「边界」、什么是「客观事实」、什么是「主观演绎」、什么是「该承担的责任」。

我写过一篇相关的文章：一个因为从小就没有被教导如何和同龄人打交道、被学校的环境误导以为优秀的人必然是孤独的人，他的「常识」是母亲说他的性格孤僻、「我天生如此、不善交流」吗？如果只依靠这些「常识」，只会让他困在「孤独 — 高冷 — 更孤独」的恶性循环里。因此我说，「常识」是非常主观的，会夹杂着偏见、粗暴的标签以及说教。

同样的，不借助理论的话，他也难以剥离「客观事实」和「主观演绎」。

为了防止有人偏要误解、认为我说的是「没读心理学书籍、学理论就不行」，我得补充一下：理论是解释「世界」的「语言」—— 可以看这一段 —— 理论所提到的事情实际上依然存在了（「世界」），但我们人与人之间沟通依然需要用到「语言」。除了「理论」这一种形式，我们也可以通过积累经验自行悟出「世界」，亦或者听有经验之人自己总结出来的「语言」。

通过理论，先在认知上理解什么是「个体独立性」、什么是「边界」…… 他才能进一步推断自己边界是什么、别人的评价是别人的课题、自己需要承担的责任并非「承认自己是个怪咖」。

休息日出去玩吧

2026-07-28T04:00:00.000Z

近些天的天气闷闷热热的，想必是为了给接下来的雷阵雨做准备的吧。

我的床位于窗边，刻意让窗帘留了条缝儿。天一亮便有一点点光线照射进来。可惜租的公寓朝向不太好，太阳总是得过一段时间才能照射进来。

我不知道我应该做什么好。我难以理解为什么会有人下午两三点才醒过来，却要早早在上午十点定闹钟，然后容忍它在接下来的数小时内时不时叫一次。室友这个始作俑者不嫌烦，我还嫌烦呢。

从早上到室友醒来的这段时间，是非常难得的仅属于我的时间。可是我每次这个时候都发难：该继续推进项目呢？还是出门去哪里逛逛，直到室友醒来打电话找我？还是无所事事地刷手机，一直等到她醒来、同意拉开窗帘、任由太阳光在我的身体上爬来爬去？

或许我就不该等她，早上起床就出门去。不过难得有时间，很多事情还没做完呢，比如读一读订阅的博客文章。项目管理对我的时间把控抓得颇紧，不让我做任何自己的事情，因为对方认为全部时间都拿去做工作相关的事情的话，效率就会提升。这也让我不得不去追赶对方的节奏：工作、达成指标、修 bug、写 bug…… 「做不完这些你怎么配出去玩的！」他总会给我种感受，那就是追求除了工作外的娱乐方式，是罪恶，是冒犯。

但周日让我懒散、不愿动弹，也没了做项目的心情。我倒是对出门很有兴趣。室友总算在近三点的时候醒了过来，这家伙儿果然是什么夜行生物吧。我跟她讲了下想要出门逛逛的想法，她也同样有不想干活的心情。既然都是知音，那就赶紧出门吧。

纽约市是个无聊的城市。这里的景观我都看腻了。对于室友而言，探索不同的社区，尤其是郊区很有意思，不过父母家就在郊区，看来看去都是同个样子。海啊，沙滩啊；山啊，草地啊；都是一样的。我对大自然没有太大的兴趣，所以也很难从中寻求到乐趣。

能独处、自找乐趣的人既是神，也是魔 —— 我定然不是这样的人吧。不知是我大脑在哪个方面真有障碍，还是性格如此，我只是喜欢规整的纪律。强迫型思想的感觉？四个字的城市。室友笑说「你是小自闭吗？」

我本来是想要去博物馆看看的，也就是纽约市颇有名的美国自然历史博物馆（American Museum of Natural History）。小时候我经常作为「导游」带着亲戚去逛。真是奇怪，明明是个孩子，因为英语说得比父母好些，就被抓来做所谓「导游」了。说不好还要被骂。学校旅行也经常往这个博物馆来。那时的我不会在乎博物馆里的内容，只是一味儿地想玩手机。前几个月室友因为作业需要，所以我们一起去看了。大了，对小时的许多事情都不再抱有兴趣，却能捡起小时不屑于正眼瞧的东西 —— 这家博物馆还挺有意思的。不再用朋友圈，也没有需要向他们证明我很忙的表面朋友后，我不会用手机一个个展览都拍过去，还发到朋友圈充当无数个背景板的其中一员，反而仅用眼睛这个不带存储的破烂相机看过去。有时候就是这样吧，不需要记录什么，也不用担心不小心调成「自动」的闪光灯。

室友却不乐意了。她不想要去博物馆、没有那个心情。她想要去荒郊野岭、无人的海边。可是那种地方搭乘公共交通根本到不了，至少也得走上个十几分钟。她觉得也可以和我去共享办公室里坐着，因为和我关系够近了，不需要特意做什么她也会感到开心。

不过共享办公室，本来就是我平日在待着的地方…… 我不想要周日也那样，不然会显得我很可怜。

我说，换衣服出门就好了，随便去哪里看看吧。她说，哎正好，我上次路过一家酒吧，非常漂亮，想要让你看看。于是我们准备更衣。

她托父母从国内寄了点东西出来，这里包括了些送给我的礼物。因为事先跟我聊过，我对这些小礼物也表达出了喜欢之情，因此我不讨厌它们。

实际上，有些礼物完全超出了我对它们的期待，比如她送我的表。该表的表带是我目前戴过的所有表里，最舒服的一个。它非常贴合皮肤，还不硬。

因为平日的穿着一本正经的，所以需要点装饰缓和下，毕竟我也不想日常闲逛也要摆出无比正经的样子。这种童趣风格的装饰，我有很多，比如我的这条领带：

室友送我的礼物中，还有风格可爱的小戒指、耳夹。

窗外的太阳一看就颇晒。我一直都没有涂防晒霜的习惯，结果这个夏天变黑了很多。我自认皮肤还是挺白的，现在变黑了让人有些不爽 —— 到底是为什么呢？可能是「皮肤白」是我的特征之一吧。没有了这个特征，就不会再有人夸我了。但这也是表象的一种。再不济，也不该让皮肤上出现黑斑吧。于是我掏来室友的防晒霜，在身上抹了抹。

我们先是走向她提到的那所酒吧。该酒吧的内部，似是爱丽丝仙境主题的，里面有许多装饰用的花，非常漂亮。Happy Hour 的鸡尾酒，没记错应该是 10-20 美元左右吧。生蚝则算下来一只 2 美元 —— 酒我虽然会调点，不过喝是喝不来一点，会头痛致死的。生蚝真是好吃，不过我还是不太喜欢独属于贝类的味道，因此不配鸡尾酒酱吃不下。质量也是一点，差的生蚝吃了我会犯恶心，生海胆也一样。

但我们没有在这里点单吃饭，毕竟这种酒吧要吃正餐的话两个人肯定要百来块钱啦。我们都没有这个心情，我也不喜欢西餐。为了不拍到别人，所以找了个拍不到任何人的角度，结果拍了个寂寞的样子。

这附近还有个花街。顾名思义，全是花店。它们不仅店内都是各种盆栽，外面也摆满了植物。走在街道上，能清晰闻到植物的味道，真要说的话，就是草、泥土和水的混合物，偶尔路过花的盆栽，那就带点花香。因为对大自然没有太多兴趣，我对植物也没有。它们是赏心悦目的装饰，更像是背景板。我又想了想，觉得这么说实在无礼，准确来说便是没有到对它们产生兴趣的时机吧。未来说不定就会到了。

除了酒吧，Broadway 附近也有许多咖啡店。它们两个就像是宝可梦里的皮卡丘，还有当时小智说的野狗一样多。我也在咖啡店打过工，不过是机器做的，我只用扫描条形码就好了。因为和当地更常见更传统的咖啡店不同，所以还被顾客埋怨过：「怎么会没有 cream 啊！真的是！」—— 你跟我说我也没有办法啊，找别人去发泄情绪吧！

有趣的是，我还看到一家酒吧跟咖啡店融合在一起的店。或许是周日的原因，吧台处只有一个调酒师。难道他还要兼顾做咖啡？瞄了眼价格，5 块钱左右，有点贵呢。

一说到价格，就想起前不久看到有人说，中国那边的主流社交平台在吵「贫困生能不能买 9.99 元的瑞幸咖啡？」我和室友讲了这件事，她惊讶道：「那不是特别便宜了吗？」

当时看到转告的人说，中国很多人还是停留在以前的旧思想，觉得咖啡是崇洋媚外、小资的东西。

说到「小资」，我和一个认识许久的朋友有过这样的对话呢。当时我提出想要去 MUJI，因为手账的尺寸买错了，得再去买个 A5 的日式标准活页本。他立即表示，MUJI 是无比小资的品牌。小资不小资的，根本没有关系，反正那个活页本也才 3 美元而已。事实证明，他也不知道自己在说什么，因为进了 MUJI 后，他才知道里面的东西很便宜，意味着他从来都没进到 MUJI 里来，只是听到中文主流的社交平台有人这么说了，他就搬运过来给我而已。不过走之前，他还是对门口的香薰发表了意见：「用香薰是很小资的事情。」

很不喜欢这家伙儿的原因是，他很多时候都不知道自己在说什么，就果断下了结论。经历的事情太少，每天好似只是在重复做同样的事情，为了分泌更多的多巴胺而无时无刻都在听多倍速的 AI 读知乎小说…… 视角的狭窄，让我心中有股怒火。也不是讨厌他，只是觉得恨铁不成钢。帮助他，也尝试过数次，毕竟认识了很久，但他的幼稚，有时会尝试把我拉入他的情绪之中。

我曾经和室友讲过这种事情，她说为什么要花时间去帮一个不值得你帮的人呢？—— 我也不知道。听着她骂我有救世主情结，嘴上虽然说不出什么话来，但心里想着你这家伙儿真是学到什么就立即拿来应用啊，明明自己也做过一模一样，甚至更恶劣的事情吧。意识到这一点后，觉得自己真差劲儿。

说回咖啡吧。我不喝咖啡；室友虽然喝，但是她对味道一点都不挑；现实生活中认识的朋友有一个喝，不过他大学喝太多、已经对咖啡因免疫了，现在什么时候喝咖啡都不会觉得身体有什么影响，真是可怕。还有谁对咖啡很了解呢…… 第一时间想到的是 Eltrac。他会自己手冲咖啡，记忆里他也说过手冲咖啡要比在外面买便宜，尽管手冲咖啡听上去是个高端且小众的行为，或者说喜好？

我的生活和过去不一样了，虽然还是很穷，但因为室友非常热爱生活，所以也被她带动着，去考虑自己周遭的事情。我这样生活着，会不会也让部分人认为，我不配如此生活呢？在 QQ 相册里添加的风景照片、第一次坐直升机、溜冰来溜冰去，经常泡在街机厅…… 这些生活中精彩的一部分，我是配享受的吗？会有人觉得我不配吗？会有人因此讨厌我吗？又或者说，我的这种想法都是如此自大？

「别人买什么，跟他们有什么关系嘛。」我们过马路时，室友这样说道 —— 嚯，原来如此，我被绕进去了。

对面，我们看到了瑞幸咖啡；说曹操、曹操到。室友问我要不要喝这家，还是去蜜雪冰城。我回我根本不会买它们喝啦。我们便进去看了眼。

这家门店真是漂亮，装修风格挺有品的。不过之后听 Fediverse 上的朋友说，墙上的照片是样板，国内的装修也是这个风格。

我还是不愿意拍到别人的脸，因为我自己就不喜欢被别人拍，所以也默认他人不喜欢了。手机往上抬了抬，拍不到下面的沙发。周日的员工往往都只会放一个人，因为没啥生意，再加上是夏天，更没有人愿意出门了。游客除外吧。

另一面墙上则有着奇怪的设计：两个竖着的垫子？还有两个小支架。室友解答说是靠垫。人可以靠在垫子上，再把饮料放在支架上。不过这样的设计很奇怪…… 总感觉。要面朝向坐在沙发上的人么？然后只有两个垫子和两个支架？为什么？做成一排支架、当桌子用不会更好么？

室友最终买了个抹茶的什么东西，上面还洒了点抹茶粉。我完全没法理解抹茶的美好，身边的人好像都挺喜欢的，像我妹妹也喜欢它的样子。

中城的 Broadway，总能看到高端、昂贵的东西。就比如我们进去逛的 ITOYA Topdrawer。这是家来自日本的零售店，标榜高端，里面的东西也确实让我觉得「高端」。最让我印象深刻的是奇形怪状的这支钢笔：

我对钢笔是有些收藏心在的：我有四五把 Pilot 的 88G，有着动物的花纹；Picasso 的钢笔我也有，非常漂亮，就是写起字来不敢恭维；很有现代感的 LAMY Safari，写起来挺不错；国产的钢笔我也有一支金豪的 911，便宜、细细的。近期，我还为自己的收藏新添了一支 Pilot 的笑脸，定位应该是给小朋友们的，有着会纠正握笔方法的设计，非常可爱。

因此这支 KOLO 的 Tino 钢笔，让我再度涌现出买下它做收藏的欲望…… 不过不可能随便出个门就花掉两三百块钱去买钢笔啦（实体店内因款式不同，价格也不同）。

说到钢笔收藏，我家里还摆放着小时候去钢笔零售店内拿的杂志。里面有支钢笔的设计非常有意思，合上盖子竟是个武士模样。我找了下，原来是 2018 年的限定款：看这里。

令人意外的是，KOLO 这个牌子来源于 Austria，也就是奥地利。我本来看这家零售店里摆着许多日本的东西，还以为是日本或者德国的牌子呢。

因为非常小巧，所以 Tino 很适合放在口袋里。以前我就有把笔塞进口袋的习惯，不过当时用的是便宜中性笔，就算不小心折断了也不心疼，还很轻。现在改用钢笔后，就不能这么做了，尤其是摇晃会导致笔墨洒来洒去、全洒到笔盖内，得不偿失。

Topdrawer 内还有一些我觉得很有趣的产品。比如绵笔记本，也就是用棉花做的纸。该笔记本的样貌十分狂野。我搜了下，得知这种纸配墨水笔写起来非常舒服，也很耐放。不过我没有太多需要使用绵纸的场合。

我们转了一圈，最终打算买几个便宜的餐具旅行装。我买了个筷子，可以解决我外出吃饭没有筷子用的问题 —— 不过实际应用场景应该很少吧……

结账时，我注意到一旁摆放着的明信片。我过去有着交笔友的想法，但苦于不想要暴露家里地址，所以迟迟没有执行。P.O. Box 很贵啊。最小尺寸的一年也是 220 美元。我无法接受去订阅个每月超过 10-20 美元的服务，除非我特别需要它。至于虚拟地址，这是个让虚拟地址公司帮用户代收、每段时间会扫描信件、发图片给我的服务。怎么可能把信件交给他们呢！

部分大学似乎是有代收服务，我也去搜了搜，发现我校没有这种东西…… 唯一的办法就是自己租个办公室，用共享办公室公司的信箱了。但这也是未来的事情，谁也说不准。

我也看到过类似于 Slowly 这样的虚拟笔友平台，直接在设备上写好，然后平台模拟寄信的流程。我不太喜欢这样，所以没有做。

我从远景那儿听说了 PostCrossing 这个平台，也就是把「笔友」换成了「明信片友」，大家互相寄明信片。我没有真的摸过明信片，总觉得是离我有些遥远的存在。不过它们现在近在咫尺了，我一瞅，卖的都是带有非常漂亮的艺术画的卡片，画的也是自然界里的动物们。我不喜欢大自然，虽然这么说过，但我很喜欢动物们。价格则是 8 美元一张。我要尝试一下吗？要尝试给陌生人们寄明信片么？明天再想吧。

拐弯是一家弥漫着香气的冰淇淋店。我们进去一看，原来是现做的蛋筒，怪不得这么香。他们也卖巧克力，成堆的巧克力分成不同的口味和形状，放在一个个容器内。顾客要拿个袋子，自己挑选喜欢的，然后按磅买单。除此之外，还有漂亮的礼盒可以选择。我们看了眼价格，感觉作为礼物的话还可以，尤其是礼盒的形式非常精致漂亮。

室友恍然大悟：「以后给小女生送礼，不用送花了，直接送这个不好么！」我说你的「小女生」朋友，不也就一个人嘛。这样说来，没有多少朋友的我，也买不了漂亮的礼盒、送出去。一瞬间失落了起来，不知为何。

她觉得可以送给男性朋友，她的很多朋友都是男性。「不过要送给老爷们儿嘛……」她想了想，「哎！你还真别说，他们心思很细腻，送给他们也会高兴的吧，尤其是好吃的巧克力。」

「那个谁确实心思很细腻，还有艺术细胞，收到了会很高兴吧。」

「不过那个谁总感觉会死要面子，先说几句，然后会感谢，毕竟他给我感觉是那种人啊。」

「那个谁应该不会喜欢『礼盒』这个包装，但他很喜欢吃甜食呢。」

「这样说就不想要给他送了…… 因为他只是喜欢甜食、不喜欢精致的设计吧。我想要送出去的是设计啊！」

「你收到了这种礼物会高兴吗？」室友问我。

这还真是个好问题…… 我首先是不喜欢巧克力，其次是不喜欢对我无用的礼物。我说，我应该会直接送给你吃吧。她惊讶道，你不会因为对方的一番好心而高兴吗！我觉得那才和我无关吧。

走着走着我们走到了 Koreatown。街口有家蜜雪冰城，但今天没有放「你爱我呀我爱你」的音乐。和往常一样，还是排满了人。

有家韩国菜店外面摆放了菜单吸客，但不知道为什么白米饭是空的？

我提议去新开的 GATCHA 分店看看吧。这是家连锁的娱乐店，主打抓娃娃机和扭蛋机。而我根本不会去玩这种破机器，我会去 GATCHA 纯粹是因为它里面有《舞萌 DX》。

看，是送快递的考拉！：

Koreatown 的新店是最大的一家，有五层楼。地下到四楼依次是：传统街机；抓娃娃和扭蛋机和盲盒区，有个小二楼是音游区；茶饮咖啡厅、大头贴、移动唱 K 厅和小露台；PC cafe，也就是网咖区；VIP 包间房。

电梯里有着泡面的味道…… 我们搭乘电梯到了茶饮区，发现原来是因为他们卖「拉面」吃 —— 此「拉面」非彼「拉面」，其实就是泡面。再准确说的话，是韩国的拉面。中日韩三国的「拉面」指的都是完全不同的东西 —— 税前 11 美元吧，奶茶都是 7-8 美元，非常不值。尽管我没有喝，但我这个在奶茶店打过工的能嗅出来，这种临时创办的暴利子品牌，怎么可能用好的料给客人。国内大牌子用好料还只卖 6 美元左右呢。

唱 K 厅一看就是国内的牌子运过来，上面还写着不少中文呢。行不行啊，你这店不是开给外国人还有韩裔的嘛！我不记得这个唱 K 厅的名字了，总之上面有个蓝色的小鱼人，然后是六人座。

逛到这里，还闻到了泡面的味道，已经饿了。我们走到外面去，商讨去哪里吃饭比较好。找来找去，我们看到一家很大的美食广场，叫 Bread & Butter。虽然很大，但里面很空，不仅顾客少，做饭的地方都看不到人。和我常看到的美食广场不同 —— 我后来才知道它其实不是美食广场，只是大得像美食广场而已。实际上它是 24 / 7 营业的韩式自助兼市场型食堂。美食广场确实是我认知中的「多个独立商户共享用餐区」的模式，哎呀吓死我了。

我搜索后得知，这是韩裔移民自己在美国摸索出来的模式。因为是一个老板开的，所以没有竞争关系，会直接安排师傅们又收银又站岗又做饭。我们在乌冬面的站台找不到人，还是专程去问了收银台站岗的师傅，他才叫了另一个师傅过来做面。

说到这个做面的师傅，做事情总给人股不耐烦的感觉。而且还耳背，听不到室友的要求。不过这个做面的形式很新鲜：师傅会先问要什么蛋白质，然后拿小铁锅过来问我们要什么蔬菜，我们就对着工作台上的蔬菜指来指去。最后他会问要不要辣、在这里吃还是带走，然后就开始煮面了。有趣的是，小铁锅似乎没有锅盖，所以他用的是另一个小铁锅、叠在上面充当锅盖。

我也看了眼其他菜单，还有「拉面」（其实是 Jin 袋装泡面）、炒饭、炒面等等食物。隔壁站台不知为啥，还有比萨跟意大利面。

师傅做完，把两个乌冬面带去收银台。室友的牛肉乌冬面 10 美元，我的虾仁要 12 美元，加上税就是 23 美元多了。

我们在 Bread & Butter 仅逛了一小会儿，看到门口的咖啡区（所以说真的是像野狗一样多啦，和小资有半毛钱关系）里有个女人，在自己的杯子里疯狂倒糖。那直直的白色柱形体，会让我怀疑她是不是来偷糖的。

这附近也有家共享办公室，我们便去那边吃。本来对乌冬面很期待的，但…… 它煮出来是一碗面糊糊……

这张图片是我努力吃了三分之二后的样貌。量很多，满满一碗。但 —— 怎么会有如此软烂的乌冬面啊！也不好吃，辣粉没有辣的感觉，反而觉得烫嘴。我受不了，跑去自助饮料机买百事可乐，结果那个机子我不会用，被提前刷走 10 美元，我还只拿了一罐。衰死我算了。

心情低落的我们也没有计划好接下来要做什么。我说我们要不回家放东西，然后再来 GATCHA 玩好了 —— 其实就是想要玩《舞萌 DX》。室友不习惯吃这种碳水为主的饭，并且下午七点不是她平日吃晚饭的时间，所以一路上在喊肚子疼。我反正是个碳水大王，吃太多肉反而心里会不舒服。当然，不要学我啊，我最近换了食谱，增加了蛋白质的摄入量，体重才开始变得正常起来。

回家路上，我刷手机看到了些 Fediverse 上的话题，是关于火锅的。我说，我吃火锅一直都是只吃清汤、猪骨头或者药膳的呢。这会不会是北方的文化习惯？她说应该不是吧，她的母亲是东北人，却非常喜欢吃爆辣的锅底。

母亲、室友和其他南方朋友们，更喜欢番茄锅。想到过去和室友去吃火锅，都是要鸳鸯锅，或者三个锅底分开。有一个永远是清汤，留给我的，剩下的则是室友想要尝试的味道。南山熊猫烫火锅里，有个牛油跟水果锅底，就被她选去了。结果这水果锅底尝起来像番茄锅，还放了木瓜。虽然听上去都是很丰富的味道，可我吃火锅完全是为了吃麻酱去的。难道是我的味觉已经固化、尝不出复杂味道的美？

路过一家韩国菜餐厅，她说这是之前老师带她去吃的，很难吃，也就装修好看。我说不好吃就没有意义啦！

想到自己母亲喜欢吃的爆辣锅底，她说，母亲曾经提出个 bro science。我问什么是 bro science？她解答说是听起来有道理但没有科学依据的伪知识，例如「女人上厕所很慢，所以女人做事都犹犹豫豫」。

而她母亲的 bro science 是，年轻人都喜好吃辣，是出于社会压力。现在深圳有很多辣辣的店。我一听，嗯，确实是 bro science！这科学依据不能说是没有，不过不太够。

吃辣啊，我只会吃一点点。小时候在山东根本不需要担心吃辣的问题，因为我们做菜顶多是放一点点辣椒点缀，亦或者是用青椒 —— 青椒是美好的、最好的辣椒啊！尤其是跟五花肉一起炒。来了美国后，也不对，应该是川菜这个菜系忽然开始普及的时候么？突然街上到处都是麻辣烫等又油又辣的菜品。起初我觉得很新鲜，没少吃，开始能吃一点辣了。不过后来逐渐觉得，这玩意儿不好吃的话是真的不好吃…… 尤其是过分的辣和油掩盖了食物本身的味道，我就也不知道它新不新鲜了。

回家后匹克猫一直黏在我们身边。室友忽然难过起来，说我们最近没时间陪它。以前它还会自主叼玩具过来找我们玩，但昨天室友发现它没有叼过来，恐是平日我们没少敷衍它，所以它知道叼过来我们也不会陪它玩了。先前室友提出把我父母家的咪咪猫带过来、让匹克猫有个伴儿的想法。毕竟母亲也不管咪咪猫有没有打完疫苗、绝育没有，只是把它放在地下室里自己玩自己的。

可是要把咪咪猫带过来，就得花时间去带咪咪猫预约身体检查、预约绝育，我光是离父母家就很远了，也不可能把还未检查完身体的咪咪猫带到匹克猫身边、跟我们一起住。母亲绝对不会帮我做这些事情，因为她觉得动物活着就好，疫苗什么的都是兽医骗人的。我又没有时间一直往父母家跑……

我们逗了逗匹克猫玩，然后出门去 GATCHA 了。天开始黑了，街边时不时会躺着无家可归的人。尤其是脚手架下，他们还给自己搭了个临时的小窝。这些人在未来，不会减少，情况也不会改善，反而会愈来愈多吧。到底是为什么，会变成这样呢？不单单是他们的处境，还有我的冷漠和虚伪。明明看都不会看向他们，可能还会觉得碍眼吧，内心却假惺惺想着这样的事情。

《舞萌 DX》依然很好玩。这个 GATCHA 都是路人玩家的样子，我还瞥到有路人在偷偷拍我们。不经许可却拍摄别人玩游戏，真是烦人啊。不知道肖像权这种东西吗。因为麻烦，我倒也没有制止，只是假装没看到。我也是个性格差的人。

室友十多年前就有玩这款游戏。说来，还是她兴致勃勃拉我玩的，结果现在我兴趣不减，她反而已经腻了，还好奇为什么我没有腻。

等排队的期间，有个路人玩家初次玩，却打出了非常不错的成绩，引得室友赞叹。她说这个人比我第一次玩的时候玩得好多了。我生气地说「是啦是啦。」她又说，这个玩家的手指很长很长，一看就是弹钢琴的。学过音乐的人玩音乐游戏入门都很快。她作为从小就学过多种乐器的、「精英教育」下长大的人，玩音乐游戏简直是手到擒来；另一位学钢琴的朋友，我带他玩过七天，结果他很快就达到了刚玩数个月的我的成绩。

室友觉得，太多玩家去专注于手法这些东西，只是在搞「游戏」，却没有搞明白「音乐」。我想了想，确实如此，我见过许多玩家会栽在需要音押的地方，我自己也是更喜欢目押。不过手法也很重要吧！尤其是《舞萌 DX》这个街机，如果不好好学习发力姿势的话，不说玩起来累不累了，还有可能伤到自己、伤到机器本身。

我不想要为了玩好《舞萌 DX》所以去学门乐器，不然我要学很多东西、学很久。室友觉得我是在半途而废、只做自己擅长做的事情，有着不好的习惯。但也确实，有些人天生就有音乐天赋，有些人天生没有，可能我就是没有音乐天赋的人，不仅难以拍出拍子，唱歌还总是平调。

我们跑到二楼的茶饮区，当然不是来买饮料喝的。室友想要唱 K。这是我第一次和朋友出来唱 K。初中时朋友们有邀请过我，但母亲不准我去，因为那是不正经的。不过之后陆陆续续，作为母亲的小孩，来母亲和她朋友们聚餐的地方，总是可以唱 K 的包厢。双重标准啊这是。自己和朋友就可以唱，我和朋友就不能去唱着玩了吗。要说她是我小时候难以和同龄人变得关系亲密的罪魁祸首，也不为过。不小心想到了小时候的许多不愉快的事情，还是不要想了。

GATCHA 的积分卡里，最值的一档是 55 美元 192 积分。以前还有个 250 美元 1000 积分、能和别的卡一起分积分的，结果后面不知道是老板觉得自己亏了，所以把这个档调整了下价格，变成了谁买谁是傻子的价位。总之唱 K 厅是 20 积分能唱 15 分钟，一个小时就是 22.92 美元。这个移动唱 K 厅的质量也很差：设备经常卡顿、网速慢、门还锁不上！更奇怪的是，这个机器里的很多东西是中文的啊？虽然也有英语翻译，但小得不行，根本就是坑骗不懂中文的人。

右上角有个可以扫的二维码，一进去发现是微信小程序……？你有病啊。

在摸索这玩意儿咋用的期间，我们已然浪费了许多分钟。主要是室友在操作，我在唱 Baby Shark 玩。

Baby shark, doo-doo-doo-doo-doo-doo

嗯…… 我真的需要放这首非常可怕的歌的歌词吗？

之后她唱了许多日语歌。可惜我的日语水平并没有到看了歌词就能立马唱出来的水平，更何况还有一堆汉字呢。很贴心地，每次开始唱之前她都会哼出原唱的调，然后根据我们的自然音高调节程序的调。这也是我第一次知道草东没有派对的许多歌调都很高的这件事，明明是男主唱？

我除了常听的台湾摇滚会唱外，就只会唱些 80 后会听的那种车载音乐了，比如说《荷塘月色》吧：

我像只鱼儿在你的荷塘
只为和你守候那皎白月光
游过了四季荷花依然香
等你宛在水中央

放开唱歌很开心，觉得自己在手舞足蹈的。结果一不留神，就把所有的积分唱完了。

顺带一提最后我们唱的是《姐就是女王》：

姐就是女王
自信放光芒
你若爱就来
不爱莫张狂
收起你的那些小小花花肠
甜言或蜜语
去哄小姑娘

这首歌实在是一看到歌词就会脱口而出啊哈哈哈哈！

GATCHA 开到凌晨两点呢，真是适合时不时来待一会儿。不过我的「允许大消费」日，得过很久才会来下一次吧。

两个人一边聊着什么「颤音是种技能啊」，一边哼着歌回家去了。想到早上的种种想法，觉得能这样发展实在是太好了。就算今天不是个好天气、买到了特别难吃的乌冬面、可乐被坑了 10 块钱、唱 K 的房间锁不上门我还唱不准调，但都无所谓、不重要了。

大熊猫送快递

2026-07-25T04:00:00.000Z

本月我尝试了大名鼎鼎的 Panda Express，美式中餐的鼻祖。本来以为会很难吃，结果发现…… 哎你还真别说，挺不错的。

尽管我在中国仅待了十年左右，但我觉得我是中国人、对正经的中餐有深刻的了解，怎么可以去接受美式中餐这种异端！

除开口味上的本地化，也就是酸甜口，美式中餐也为中餐这个大类带来了许多偏见，例如陈皮鸡、左宗棠鸡这种诡异的东西，都是什么鬼！我才不认可呢，也不准有非中国人跟我说，吃中餐是不是要吃左宗棠鸡这种东西！

因此，在美国的这十几年来，我都未曾去 Panda Express 买过饭。

根据网络上的记载，Panda Express 在 1983 年就出现了。当时的华人移民想要本地化中餐、赚外国人的钱，于是发明出了陈皮鸡（orange chicken）。它的味道…… 总之就是酸酸甜甜的口味。

创始人中的丈夫 Andrew Cherng，他的父亲因为当时的国共内战，逃到了台湾去，想要打工赚钱后接家人出来。但是在共产党接管了内地后，出境变得非常困难。Andrew Cherng 的母亲只能藏在船底偷渡，然后花钱找蛇头分三次将儿子偷偷运出来 —— 想起了《那片血一般红的杜鹃花》。

长大后的 Andrew Cherng 靠奖学金去了 Baker University 读书，是 Kansas 的一所私立宗教大学。

创始人中的妻子 Peggy Cherng 也在这所大学读书，读的还是计算机科学专业。

有趣的是，她毕业后去 McDonnell Douglas（之后被并入到波音公司，也就是造波音客机的公司）做软件工程师。所以嘛，学计算机专业的未来不一定在计算机行业住下了，也不一定去做房产中介了，还有可能在开餐饮公司！

单看丈夫的历史背景，其实便能看出 Panda Express 的「问题」所在：不正宗、是移民文化的产物 —— 会如此评价它的，自然也是未能经历过移民的人。两者因为经历不同，永远都不会产生共鸣。

过去我同样如此评价它，嘲讽它的 fortune cookie、奇怪的菜品，也是那时的我深受「正宗」的影响。正不正宗，只要不挂牌欺骗客人，根本所谓不大。菜首先得是好吃的吧，其次再去考虑文化吧。如果谁非要说美式中餐哪来的文化，咋的，移民文化不是文化？菠萝披萨不受意大利人待见，但它照样好吃吧。

现如今，Panda Express 已然是美国最大的亚洲餐饮连锁品牌。我家附近就有一家，招牌挂得大大的。每次路过，都能看到里面坐满了人。

其实这个月会让我注意到它，是因为一次出门，路过它时发现它的最低薪资开出来还不错，比做奶茶店好多了。看来是打工打得太多，对奇怪的事情有了奇怪的注意力……

因为实在是忙得不可开交，尤其是甲方老板的沟通方式令人难受、摸不着头脑。我近乎是天天泡在共享办公室内，从早泡到半夜三更。回家后还得和室友一起准备次日的饭菜，实在是难熬。

我还有个选择，那就是买美式中餐。它们一是对比地中海菜（比如 CAVA）更合我的胃口，二是便宜量大。美式中餐夫妻店在美国可以说是到处都是。只要有中国人，在鸟不拉屎的地方开一家美式中餐馆也可以活得滋润。

但是美式中餐夫妻店，如果运气好能吃到技艺高超的师傅做出来的菜；但运气不好，就只能吃到又油又恶心又糟蹋食物的垃圾了。办公室旁边的夫妻店，就是后者 —— 哇靠我还是在美式中餐馆打过半年一年的工的，好师傅做出来的同个菜品什么水平，我还是知道的。但这家的师傅是什么鬼，怎么能把菜做出来整个 206 盒子都是油的！再就是，这家店很坑人啊，量很少，根本对不起价格。一个 pint 的菜怎么能卖别家店一个 quart 的钱？

于是我必须得想个办法才行…… 对啊，办公室旁边不是有家 Panda Express 吗？注册了账户后，它识相地送了我张券，10 块钱以上的单子能打八折。我在电脑上下了个自取单，点了 bowl bundle，即一饭一菜一饮料，我分别选择了炒饭、非常安全不会错的西蓝花炒牛肉、可乐。

说到西蓝花，美式中餐里另一个很有名的系列，就是西蓝花炒 XX 系列。XX 通常是鸡胸肉片、叉烧、牛肉和虾仁。但是呢，这个系列在中文的菜单上往往都叫……「芥蓝炒 XX」。广东人对这个芥蓝很熟悉吧，它和西蓝花可能在祖上有点关联，但说西蓝花是芥蓝，实在是…… 指鹿为马！

因此，我在美国点菜要很小心。我不知道这家店的 broccoli 指的到底是西蓝花，还是芥蓝？有些广东人开的餐馆，会严肃地使用芥蓝，但英文名依然标注 broccoli。这和自助火锅店里的花生酱芝麻酱问题差不多：我需要两个酱料都尝一遍，才能得知哪个才是甜又丝滑的、哪个才是苦又稠的。

总之那个订单的总价是 13.90 美元，用了券，再加上税，就是 12.11 美元。还可以吧，在我的可接受范围内。

自取时，我终于是第一次走进了 Panda Express 的实体店。一进门就能看到人们在用餐区内吃饭，食物则明面摆在不锈钢台上。看样子现场点单的流程是先选择要多少菜、员工会拿对应的纸饭盒来，再指哪个、让员工夹哪个，最后结账算钱走人。不过店的布局设计还是有点问题，因为收银台被安排在颇为狭窄的走道处。客人算完钱后，出来就要同时和自助饮料机、排队也要结账的客人、过来自取单子的客人挤在一起。

说回食物本身，看上去都颇有食欲。我报出了我的名字，员工会问我我留的电话号码的最后四位数是什么，然后笑脸拿给我饭。不过那会儿自助饮料机没有气了，他们只能给我柠檬汁，我也不好说什么，毕竟没有气的可乐和叫我喝尿没有区别。

拿饭回办公室吃的时候我发现，饭看着有点少的样子，其实完全够吃。

虽然我在平台上说了不要餐具和餐巾纸，但员工们还是放了一套在里面。说好的环保呢！

不过这应该是 SOP 的锅。有些东西员工们是就算看了也没用，照样得根据店内规矩做，比如前些年纽约市还是纽约州说饮品店不能默认给吸管，只有在顾客要求给的时候才能给吸管，但我们员工依然还是得无脑放，不然会被顾客投诉呀！

Fortune cookie 的包装袋居然烂了，饼干已经软化、不好吃，遂投喂给喜欢吃的室友。

这个东西是我来了美国后才知道有这玩意儿的东西之一，另一个是来了美国才初次见到的煎饼馃子…… 嗯我在中国其实没有见过它；我都是吃火烧和馒头的。说是饼干，不过应该是膨化食品么？我不爱吃，开里面的小纸条倒是蛮有意思。

炒饭炒得一般，吃起来像拌饭，无法接受！虽然我是做饭白痴，但还是有拿手好菜的，那就是炒饭。做炒饭我可是很认真的，无论是分离蛋白蛋黄、试图做炸蛋丝、青葱要分三次放、蔬菜比例要均匀…… 这个拌饭一样的东西是什么！你管它叫炒饭吗！黏糊糊的，怕是后厨根本没有大火吧！

更可恨的是，炒饭内居然有明显夹生的饭块块。饭粒本身也很有问题，吃起来生生的。

西蓝花炒牛肉是个非常安全的选择。毕竟其他菜品，像是什么北京牛肉、宫保鸡丁，很令人怀疑。作为我初次尝试 Panda Express 选择的菜品，姑且还是选择之前吃过的吧。

神奇的是，它居然比我去过的许多夫妻店炒出来的要好吃。不油腻，不能说多好吃，但绝对不难吃。

最后是柠檬汁。它喝起来完全不像是柠檬汁，根本就是没有气的雪碧，稍微苦一点点、酸一点点而已。因为太酸了，我只能慢慢喝，酸到牙齿发酸。尽管只是中杯的大小，但我没能喝完。

可悲的是，这个纸杯子会随着时间开始漏水，柠檬汁也借此慢慢地漏到了我的桌子上……

这就是我初次尝试 Panda Express 的经历！说实话，让我改观了。吃起来很不错，和路边的夫妻店有所不同。

然后我便染上了 Panda Express 瘾。主要是在办公室里吃它，很有上班族的仪式感，呵呵呵……

第一次点完单后，Panda Express 给我发了封邮件，想要我填个小表格，填完可以拿个免费一菜券。这便引来了我的第二次点单。

第二次，我点了两菜一饭，券又送了我一道菜。这次的「饭」我选了炒面，三道菜分别是安全的西蓝花炒牛肉、陈皮鸡和蜂蜜核桃虾。

这个陈皮鸡啊，是室友好奇所以点的，毕竟是美式中餐的有名战将之一。它有两个孪生兄弟：芝麻鸡和左宗棠鸡，其实都是鸡肉先放油里炸，取出来后放锅里拿酱汁炒。左宗棠鸡是带辣的，这三个家伙儿味道基本上相同。我并不爱吃这哥儿仨，但室友很好奇味道，就让她吃吧。

蜂蜜核桃虾我其实过去就有所听闻。当时我还在玩小红书，首页上都是留学生们的帖子，当然还有讨人厌的引战帖子…… 总而言之有人在上面说过，Panda Express 的蜂蜜核桃虾特别好吃。

炒面和炒饭有着同样的问题：夹生，然后咸。尤其是我这次点单没要饮料，点的三道菜里，荤对比素的占比更多：素仅有西蓝花，意味着解腻我只能靠它。

陈皮鸡和我预料中的一样，我不喜欢吃，室友也不喜欢吃。它很甜腻，必须要配什么来解腻。虽然脆脆的、口感很不错，但实在是不能打好评啊。

蜂蜜核桃虾确实很好吃，可惜味道和陈皮鸡相似，配合起来反被扯了后腿。不点陈皮鸡的话我的评价还能再上一层楼。再就是，其实我不喜欢吃坚果类的食物，所以核桃还得扣点分。

这第二次点单原价是 20.40 美元。用了券，再加上税，就是 14.26 美元，不错不错，相当满意。

第三次点单是和室友一起点的。我俩都懒懒的、不想做饭，于是在办公室下了单，一人点一份二菜一饭。我点的是白米饭、西蓝花炒牛肉（非常安全和安心）、蜂蜜芝麻鸡胸肉；室友点的是炒饭、宫保鸡丁、北京牛肉。

两个人一起去取饭。她第一次进到 Panda Express 里来，觉得蛮稀奇，竟比想象中干净漂亮点。然后这个家伙儿，取完单后跟我说女员工长得真漂亮、笑起来很甜。我说这一切都是打工的需求啊 —— 当然也不否认，有些人就是日常如此。在我之前打工的店里，就有这样的人，好似天生热情好客、有礼貌。

先说我的饭好了。

白米饭…… 唉，不想说了，毕竟是拿它炒的饭。依然有夹生感，我感觉是米的选择问题么？不过它比起炒饭和炒面，配下饭的菜更香更好吃。

这个蜂蜜芝麻鸡胸肉是我随便选的。它和陈皮鸡类似，也是裹薄糊炸的鸡胸肉，再和蜂蜜芝麻酱汁炒在一起。口感依然脆脆的、是甜酸口。但是！它和陈皮鸡最大的区别，就是它有配菜！根本就是陈皮鸡这个烂招牌的升级版本。

室友的炒饭据她所说，比我初次点的要好吃些。我说该不会是我填写的表格被上头看到、店被批评了、员工又被训了一顿，所以好好炒了吧 —— 好像有点自作多情了呢。

宫保鸡丁…… 比陈皮鸡更糟糕的选择。我得说明一下，我没有吃过国内的宫保鸡丁，但看图片能看出是咸辣口的。Panda Express 进行了改良，所以它变成了甜辣口。我们在吃的时候，就看不到多少鸡肉，全是西葫芦丁跟洋葱。室友这个没我挑剔的人都在边吃边皱眉。

不过她也得到了忍耐之后的奖赏：北京牛肉！宛如一匹黑马，出现在餐桌上！我的意思当然不是我要吃马肉了。我起初对它没有什么感觉，只是觉得不是北京菜却叫作 Beijing Beef 这一点很奇怪，和我小时候第一次知道兰州拉面其实根本不是兰州的，也不该是拉面一样奇怪。还要说的话，那就是老婆饼里没有老婆、雷峰塔里没有雷锋、钱包里没有钱 —— 这个段子好老啊。

它是炸过的牛肉条，然后用酸甜微辣的酱汁，配上甜椒和洋葱炒出来的。它比想象中好吃许多，特别下饭。脆脆的牛肉条，除了好吃说不出来别的。

所有东西加起来的价格是 28.53，两个人对半劈一下就是每个人 14 美元多。稍微有一点点接近我的接受范围。在我开始跑去唐人街之后，我对吃饭的接受预算便逐渐往 10 块钱靠了。

这三次点单都有个共同点，那就是菜品都不咋油腻。虽然有个别菜品很是甜腻啦，但对于有些厌烦了油腻的我来说，蛮新鲜的。

我非常乐意继续点 Panda Express 吃，一直点到吃腻为止吧。不过看看钱包，还是得少在外面买饭吃。自己买菜自己做，才是王道。

吃饭的时候我总是会想到之前对 Panda Express 的偏见。这也受了早些年泡在中文互联网里的影响。毕竟主流平台上的思想，因为群体极化效应，还有推荐算法等等因素，变得要么只能看到极端爱国的言论，要么就是极端恨国。前者里，不乏有对中国元素无脑追捧的想法在，例如给外国人吃的中餐不正宗、不好吃、低级等发言。

我也不知道为什么过去的自己那么在乎「正宗」，明明已经不再是他们眼里的中国人，而是什么「美爷」、「奸细」等等外来者的称呼。小时候也发生过类似的事情，那时作为山东人、外乡人的我去福建的外婆家，却被那边的村民，甚至是血亲用方言欺负、嘲笑…… 我只能逃到山东去，那才是能接纳我的地方。

对于主流的中文互联网平台来说，我也是罕见、不寻常的。或许小红书这个面向海外华人用户的平台能让我有点共鸣这一点，也是我当时那么沉浸于此的原因。不过它的推荐算法太烦人了，我便注销了账号、逃走了。

说到底，我为什么非要去讨好不认为我是他们一员的群体呢？我有自己的故事、自己的视角，不论是中美哪边，向我说些只有他们内部才在乎的事情，我也会觉得烦躁。** 我就是个移民，不是两边的任意一边，也是两边的任意一边。** 食物啥的，好吃就行了，管你正宗不正宗。它们和影视作品一样，到另一个国家都是要做本地化的！

说起来，会起草这篇文章还是因为这篇文章：

This came up recently in a conversation online and, following my rule of "if it's more than three tweets, make it a blog", I wanted to actually unpack it.
最近在网上的一次对话中提到了这件事，遵循我「如果超过三条推文，就写成博客」的原则，我想具体展开聊聊。

我在碰 Fediverse 之后，或者更准确说，类 Twitter 的 Fediverse 软件之后，就一直很担心我会把想写的东西都一股脑塞 Fediverse 上、反倒是忽视了博客。事实证明，我确实会做这种事情。随着 Fediverse 上的帖子愈来愈多、我花在 Fediverse 上的时间愈来愈多、我花在写博客文章上的时间愈来愈少…… 明明有很多有趣的事情可以写成博客文章发出来，但我全都选择发在 Fediverse 上了，实在可惜。

作者 Thom 的原则很适合拿来参考。我现在会记下话题的出现次数。如果发了超过或等于三条与其相关的 toot，意味着它足够被我拿来写成博客文章，我就得加把劲儿写出来。

哎呀博客文章这种东西还是得冲动一下写出来，不然像工作一样写出来、多没劲儿啊。Fediverse 碎片化的发 toot 形式，正好可以记录我当时的感想。之后写博客文章，我就能抄下来当时的情绪了。

想法在丙午荷月迭代

2026-07-01T04:00:00.000Z

酷暑逐渐来临。连打工兼职都能失业的我，依然在拼命找工作中。为了赚钱，这个月开始学习些和计算机不相干的东西。

本期导读

班级政治

2026-07-01T04:00:00.000Z

我想说说我来美国后，上小学时的事情。其实我一直都很想分享自己在美国时的经历，将其整理成一个别于「日常生活」的分类，就叫「美国十年」好了。它和政治没有关系，就连这篇文章的标题「班级政治」，也和人们常谈的政治不同。整个系列只记录我这十年来有记忆的事情，更倾向于分享日常。

我来美国前是小学四年级，来美国后翘了这下学期，当了几个月的「无校游娃」。父母担心我难以融入，于是把我推进当地一家华人浸信会中，去他们举办的免费暑期辅导班里待待。说是辅导班，其实就是教会里的大学生、研究生带我们几个小学生。我也没有真学到什么，记忆犹新的就是这班上有几个烦人的男生，整天嘲笑另一个出生在墨西哥的女生。我因为好奇和好谈，还被「老师」拉到别的地方去坐，那也是我作为学生第一次被安排在特殊的地方坐着，让我这个四年好学生很是委屈。

同年秋季，我根据地址被安排到一家附近的小学里就读五年级。因为英语不达标，上的班是双语班，老师是个会说普通话的中国人，我们要叫他 Mr. Tang。说到这个「英语不达标」，我就得好好说道说道了。在我们一家出国之前，母亲其实有把我送进英语辅导班里提升提升，结果那个辅导班的老师竟告诉我美国除了加法外没有减法、乘法和除法！而加法的说法是 X and X is X，即「X 加 X 等于 X」。这当然是很不对的了，你至少要用 add 这样的动词吧（口语更常用 plus）。没有减法、乘法、除法更是无稽之谈。但当时对美国一无所知、也不会上网冲浪只会玩 4399 小游戏的我自然是信得不能再信了。唉……

上学的第一天便是不适应。当时的学生们只有我一个是突然转学来的，有些虽和我是同个时间来美国，但没有选择去翘掉四年级，所以对美国的小学也算熟悉。其他人则都是 ABC（America-Born Chinese，在美国出生的中国人），但不知道为啥被安排到双语班来？我不知所措，不知道他们说的英语是啥意思，也没有朋友在身边。不过还是和一个同桌的女生说起了话，这个人我就简称甲。

午饭时，这个班级邪恶的一幕才慢慢开始揭晓：一个女生主动过来找我，然后跟我说「你不要和甲玩，她以前偷过学校东西」。我再看饭桌上其他女生投来的异样的目光，当时的我还不知道什么是「霸凌」、它有多严重，但我知道自己要是继续和甲相处，就会发生不好的事情。于是午饭后，我懦弱地远离了甲，让她难过极了。

但这件事依然没有结束。虽然我和甲没有再相处，在之后认识了其他同学，但暗处似乎还有人看不爽我。新交的朋友在一次放学后跟我说，「你要小心乙，她在背后说你坏话，说你很臭。」这个「乙」我不认识，不知道是班上的哪个女生。我们二人商讨一番，得知她是因我和甲相处过一会儿，记恨上了我。

现在我已是成年人，再去回望乙的种种行为，就会觉得这个小孩儿…… 行为幼稚吧，但对于其他还未开智的孩子而言破坏力十足，实在是可怕。在之后我才知道，甲在学校里被霸凌许久，带头的就是这个乙。乙不仅拉拢其他女生冷暴力甲，还会连着欺负其他对甲好的人，这里就包括不知情的我。

至于甲的罪证，就是他们之前说的「以前偷过学校的东西」。我不知道她偷过没有，但作为题外话还是说说「偷窃」这个行为。我在这所学校里目睹过学生偷学校里的东西，比如故事书。当时是我被推荐去上校后的美术班，接连被两个墨西哥女孩偷画，然后看到一中国男孩偷了两天的书。我没有经历过这种事情，根本不知道该做什么好。以前在山东读小学，同学可都不会这么不要脸啊！幸好当时新认识的同学听我一说，勇敢站出来指认。相比之下，我可以说是胆小如鼠。

说回乙吧。我天天忙着跟上英语进度，就已经够累了，根本没有精力去找这个背地里说我坏话的家伙儿是何方神圣。不过她自己倒是主动找上门来了。一天中午，我和朋友们在玩 Suit Sprint，但我不知道 sprint 这个词儿，以为他们在说 sprite，所以乐呵呵说着 sprite sprite。她忽然走上前来，开始骂我，叫我想要跳舞的话就滚去别的地方跳。因为逻辑跳跃过大，我没有反应过来她其实是在阴阳怪气，所以没有放在心上。之后才知道这人就是乙。

第二次与乙接触，是我在体育课跑步。体育老师在室内操场里摆放了数个路障，让我们绕着路障跑。我被绕晕了，有一个路障没有按照规则绕。她又不知道从哪里跑出来，指着我的鼻子开始骂「你作弊！你作弊！」

班里的霸凌，我不清楚其他同学有没有上报给老师，但我没有。我不知道如何处理这些事情，过去在山东的小学里也发生过欺负人的事情，但是老师们都会发现并且点名批评，我也从来都不是个会寻求他人帮助的人，老师没发现的话就只能挨着，反正再痛还能有母亲骂我打我时痛吗？区区小屁孩。

好在她针对我的次数不算多，很快她便换了个面孔对我：友善热情的样子，真是令人作呕。我没想和她继续纠缠，所以日后再也没有和她扯上联系。不过甲到学期结束，依然是被她们一伙人欺负着的，没有真心朋友。处境对比下来是好了些，可是依然令人悲伤。我长大后惊觉于自己的弱小，不过小升初后我再也没有见到过甲和乙。

背景故事算是讲完了，现在终于可以说说标题的「班级政治」了 —— 没想到吧！

从前面所说的我想读者朋友们可以看出来，乙是个很爱「表演」的人。她算是 teacher's pet，和老师关系不错。五年级的下半学期，这老师想了个新制度，将学生分成五六个桌子，每个桌子算一个小组。每个小组里会有一个组长，负责管其他组员，而每次上课如果有组员表现不错，例如回答积极，该组就能得到根小木棍。每周五老师会结算小木棍的数量，并赋予小木棍数量最多的小组奖励，像是马卡龙这样的小零食。

乙自然是当上了她那个组的组长。她的两个朋友也是其他两个组的组长。几周下来，她们想到了个不用竞争、彼此都能给彼此面子的方法，那就是严格拉平小木棍的数量。这样每个组都能拿到奖励。不过这个方法依然需要和其他不是她们朋友的小组竞争。我很不幸地，正好在乙的朋友丙的组里。这丙时不时会告诉我们何时停止举手回答问题，把机会让给乙或者另一个朋友的组。

这样的「和平」直到丙将计划告诉了老师，才结束。我还记得那天周五，老师拿着一盒五颜六色的马卡龙生气地走到班里，开始训我们。他一直以为这几周的平手都是巧合，结果竟是故意为之的。然后他带头批评了乙丙等人，这导致了二人的决裂。

乙开始冷暴力丙。再之后的记忆就不太清晰了，因为学期也快结束、得考虑申请哪所初中了。我去的初中离家里很远，走路过去半个小时。在那所初中里发生的故事，就等到下一次再说吧。

五年级的这一年在我内心里记了许久。我做过错事，附和他人去霸凌别人，实在是不应该。我也经历了许多没有经历过的，不过很可惜，这一年我没有真的学习到如何应付霸凌，也没有搞明白如何维系人际关系。能好好和人深交并建立健康的关系，这一点要到我高中时我才深刻体会到。

这件事情我前几个月讲给室友听，她和我处境正好相反；她是在中国的学校碰上了霸凌，到了美国后反而如龙得水，顺得不能再顺。不过对于我的事情，她很直接地说，我当时居住的华人区的人，不过都是群中国混不下去的穷人，偷渡跑来美国的。本来就没有什么文化和教养，生的孩子也随父母。这种满地都是穷鬼的地方，自然到处都是欺凌和攀比。再就是她觉得小孩子本来便是邪恶的。他们像是猴子一样，发现暴力有趣就会满脑子都是暴力。

我也很想搞明白为什么小孩子会做这样的事情。今年我的妹妹和当时小升初的我一样大，她就不是会做这种霸凌行为的人。不过室友的解释总是带有着对底层的歧视，并且她当时被霸凌时，上的可是深圳的小学呀，家里都不缺钱的。

我仅认同「父母影响了孩子」以及「孩子不成熟」这两点。我当时所住的华人区，氛围在我看来十分压抑，同乡之间的互相攀比，还有异乡之间的瞧不起。我作为一个来自山东，无法混入福建圈和广东圈的异乡人，更是二者嘲弄的对象。那里的人会让我想起乡下外婆家那边的邻居，在我很小的时候便总是刁难我，用方言骂我是外乡人。他们的孩子也学着骂我。我只有在山东才是正常人，是老师眼里的好学生，是同学眼里的好朋友。

直到十多年后的今日，我依然难以融入到美国的任何一个团体。不了解我的人经常表达出对我的羡慕，认为我移民到美国来实在是太好了，但我不这么认为。不像室友，她是从地狱的中国跑来美国，才在全新的环境里焕然一新，我则是本来在中国生活得好好的，忽然被父母决定带走，然后在美国活得相当痛苦。

我有时会幻想，如果我继续待在中国，会如何呢？我一定会完整地经历中式教育、考高考，然后现在偶尔会在六月份的哪一天梦到自己在高考吧。我会有朋友吗？我的朋友都是谁？但我也会同样地失去室友这个好朋友。

室友总是听到我的幻想，然后表示可能过得会更差也说不定。是啊，那也有可能。

我有时会想，经常表示外国更好的中国人，是不是因为中国的环境对他们而言够糟糕了，他们急需一个可以幻想的对象，来安慰自己只要离开了当前的环境，便能过上好日子。我对中国的幻想，想必也是同样的：我所处的环境对我而言够糟糕了，所以我需要一个虚构的对象，安慰自己只要去了那里，我就能过上好日子。

美国十年，也是我乡愁的十年，虚构的十年。我会想要写出这些想法，恐是因为幻想已经无法满足自己了。

读《虚构一九八七》

2026-06-25T04:00:00.000Z

开始捣鼓手账后，我开始记录自己的 TODO，然后发现上个学期中文课上读的内容还没写完。别说写完该系列了，我清点过后还剩足足十七个短篇小说没写读后感！

我发现我在清理 TODO 时，最大的问题在于我非常在意 TODO 列表的处理顺序：必须是从上往下的。「Blog 或 Research 想法」分类的 TODO，按照顺序下一个要写的是…… 如何玩三阶魔方、如何玩二阶魔方、如何玩四阶魔方、如何玩三阶五魔方。

先不提最后这个三阶五魔方我实际上在现实里也没弄明白咋还原，光是第一个「如何玩三阶魔方」，我就在编写教程文章时发现，这东西很难用文字说明白！还不如读者朋友们去视频平台上找什么，「十分钟速通」视频呢。

所以我决定无视这些烦人的 TODO，先开始写我最感兴趣的内容，那便是这篇由赖香吟写的《虚构一九八七》！

再就是我发现，先前写影评和书评时，常常会陷入到必须要把整个故事用自己的方式重述一遍的困境内，导致我很难写完一篇文章。从这篇开始，我会先简要复述剧情，然后着重分析小说内没有直接提及的内容 —— 不过写完后发现自己还是会潜移默化去重述一遍故事……

小说前

在讲这篇短篇小说之前，我要先说说 metafiction，即「元小说」、「反设小说」。

Meta- 源自于希腊语的 μετά，含义是「在…… 之后」、「超越」、「关于」，或者「更高一层次的」。Aristotle 的著作 Metaphysics，或者更熟知的，《形而上学》，便使用了这个前缀。如果直译这本书的标题的话，那就叫《在物理学之后的》。对于 Aristotle 而言，能超越物理学、在物理学之后、可以解释物理学无法解释的「存在本身」的，就是哲学。

或者另一个程序员们会常看到的例子，是 metadata，也就是「元数据」。Meta- 也有着「关于某的某」的意思。对于 metadata，它的意思便是「关于数据的数据」，也就是描述了数据的数据。

那么同个逻辑套用在 metafiction 上，fiction 是「小说」的意思，那么 metafiction 就是「关于小说的小说」、「关于虚构的虚构」。

《虚构一九八七》正是这样的一篇短篇元小说：一篇关于如何创作小说的小说。

小说中

整篇小说讲的是女主人公的班上死了个同学，名为「谢彩文」。主人公发现自己根本不了解这个女孩，于是心生幻想，写了篇以谢彩文为主角的短篇小说。

小说里这谢彩文成了韦老师从大陆来到台湾后收养的女儿，还喜欢上了学校图书馆里的黄先生。最终谢彩文因为不舍黄先生的离去，向他表达心意，却被拒绝；黄先生还将此事告诉了自己的养父，导致自己被骂了一顿。结尾，谢彩文自杀而亡。

主人公将小说拿给写作研习活动的郑老师看，对方却认为结尾太做作，让主人公修改一下。同时主人公还和学长谈起了恋爱。把这事儿跟学长一说，学长觉得小说这东西，应该有意识一点、刺激一点。懵懂下，主人公写起了小说的第二稿。

这第二稿里，谢彩文依然是韦老师在台湾的养女，但这次她结识了学长，并喜欢上了他。学长让她去查清楚自己的身世，却遭到韦老师的激烈指责：「异地亲情的不可指望」、「政治的无限蔓延」……「让你读书是叫你来违逆我吗？养育之恩比不过外头小言小论？」结果，韦老师因病倒下了。绝望的谢彩文不知道该如何是好，又发现学长和更美丽的女子谈起了恋爱…… 最终，谢彩文再度自杀身亡。

主人公将自己的得意之作寄给郑老师，却被退回，反馈和上次一样：「怎么愈改愈做作呢？」主人公大受打击，开始反省，自己不过是一直在捏造谢彩文的死，这一行为便是「做作」的。结尾主人公和学长一边聊着，一边看着游行的队伍走在大街上……

可以看出，这篇故事的主要剧情内容，便是主人公在写自己的小说，以及她写小说、改小说的前因后果。

小说后

我这个月的中旬，在慢悠悠重新阅读 The Absolutely True Diary of a Part-Time Indian 这本我高中时的读物。书里有个极客角色，曾经跟主人公说了段让我颇有感触的话：一本书你要读三遍，一遍是直接读完、感受文字里的情绪，一遍是将文本和历史关联上、搞明白为什么作者会使用这个「词」；至于第三遍，作者没让他说完，但我在网络上找到了类似的理论，第三遍其实是要搞明白该文本为什么是和我们有关的、为什么我们读了它会有某某感想。

元小说的内容，自然便是我们第一遍阅读时，能观察到的事情。而「小说后」，我想要说说这第二遍。

结尾故事写到，主人公看到了「游行的队伍」。我先前刻意不去提小说中和政治、国家相关的内容，便是将它们留到了「小说后」。要理解这篇小说，就得搞懂标题中的这「一九八七」指的是什么。

我们先回到 1945 年，日本投降、二战结束的那段时间。台湾民众为日本的殖民统治的终结而欢呼，但很快发现接管台湾的国民党政府也不是什么好东西。

1947 年 2 月 27 日，台北一小贩走私香烟，被专卖局的查缉员发现。该小贩不仅被打伤，还有个市民被误杀，引起台湾群众的群情激愤。次日，政府选择开枪镇压游行的人们 —— 这便是二二八事件。

3 月 8 日，国民党政府开始自北向南展开全面武力镇压，这便包括了清除藏匿分子的「清乡」行动，大肆搜捕和杀害百姓，甚至还有台籍社会精英和领导阶层。

两年后，国民党和共产党的内战中，前者节节败退，恐是政权要掉凳子上了。为了巩固自己的威权统治，政府颁布了《台湾省戒严令》，宣告自 5 月 20 日零时起在台湾全境实施戒严；这一实施，就实施了足足三十八年，曾是全世界持续时间最长的戒严令。再配合上其他恶法，台湾开始了「白色恐怖」时期，不仅禁止公开讨论和研究二二八事件，还不允许组织新的政党、限制新闻的出版自由、禁止抱有左翼言行或台独主张，甚至对政府的批评都会被算成是在搞叛乱。

台湾社会压力随着时间的推移，不断地累积。民间力量逐渐涌现和崛起，再加上国际局势形成的压力，总统于 1987 年 7 月 14 日终是宣布次日起解除戒严令。

哎，1987，不正是标题中的「一九八七」么。

是的，这篇小说隐藏在「元小说」这一设定之下的主题，就是台湾的解严。而赖香吟对此的看法，在小说的第二自然段内便能看出端倪：这一段讲的是主人公的班级，因为谢彩文的死而乱作一团。主人公还借此提到了母亲参加葬礼时的行为举止，因过于特殊，而让她觉得死亡是不同寻常的。

接着几个自然段里，主人公开始说这谢彩文多么普通、多么渺小、多么不起眼 —— 可就算是班上如此不起眼的同学，死后还有这么多后事要交代，那何况是戒严时期这么长、这么庞大的时代的死亡呢？

当时台湾民众们对解严的期待，远远超过了预期。他们天真地认为，只要解严了，整个国家的处境便会一飞冲天、变成好的民主国家。但赖香吟认为，台湾社会根本没有做好准备，多数人（或者用我爱用的说法「一般人」）并不懂得政治。这份自由他们不仅不知道怎么使用，也会很快消耗掉解严后的兴奋，转为陷入迷茫和虚无之中。

小说中用了一些以物喻物的手法，来暗示当时社会对解严的看法。例如导师对着同学们说：「上大学你们就自由了。」这和当时社会的主流看法「解严后便自由了」不谋而合。至于已经上过大学的读者朋友们，自然也是知道这句话的真实性，真像驴头上挂着的胡萝卜呀！

小说还有一些有趣的暗示，独属于那个时代。主人公写韦老师是从大陆来的这一点，实际上并没有在「现实」中明确提及过，但有两处暗示：一是韦老师教地理知识说的是长江和秦岭淮河附近的土壤，都是对台湾本省学生来说是陌生且遥远的地名；二是他送给了主人公《沈从文自传》—— 一本记载了中国现代文学作家沈从文，从湘西小镇走向广阔世界的成长记录的书。

关于外省人只身来到台湾、遭遇乡愁和身份认同问题，这一点在《那片血一般红的杜鹃花》也有所体现。当时我写说，王雄死在了 1987 年、黎明之前，但现在我要对此打个问号了：解严了，这些问题也会得到解决么？

关于什么是「本省」、什么是「外省」，此处补充下吧：本省人指的是台湾本地的居民，主要是清代以来就从各地移居台湾的汉人后代，也包括原住民；外省人指的是 1945-1949 年间随着国民党政府来到台湾的大陆各省人士以及他们的后代。

俩省人在语言、文化经验、历史记忆上都有着差异。这一点未来也能在其他短篇小说中的角色上看到。

第二节的开头，主人公在外面偷听到几个文艺队工作人员的对话：当地城镇是二二八事件中唯一一个没有发生枪杀事件的地方。乍一看是在歌颂平安，但第二个人说道：「全是望族士绅的后代嘛。」

「望族士绅」这个词儿由两个部分组成：

望族，就是名门望族的意思，指在地方上世代累积了财富、声望和影响力的家族。这些家族通常拥有大量土地或商业资产，在地方上扎根数代，形成稳固的社会根基；
士绅，则是中国传统社会皇权与民间之间的中间阶层。皇帝的权力理论上至高无上，但实际上中央政权往往只延伸到县一级，也就是所谓的「皇权不下县」。那县以下的乡村秩序，就是由这个士绅阶层来维持。包括但不限于：
- 代表官府执行公务，同时也代表地方利益向官府交涉
- 修建书院、宗祠、道路、水利，组织赈灾、调解纠纷等
- 以儒家伦理为依据，维护地方的风俗和等级秩序
- 掌握读书、受教育的特权

台湾的士绅阶层相当特殊。首先清代时台湾是移民社会，早期的社会秩序由垦户、业主、头家等地方实力派主导。随着社会逐渐稳定，部分家族开始通过科举、经商、购置土地等方式上升为地方望族。

在之后的日本殖民时期，日本笼络和利用了地方望族来协助殖民统治。这些望族被授予绅章、任命为街庄长或协议会员，成为殖民政府与台湾民众之间的缓冲层。他们也因此进一步巩固了财富和地位。

战后国民党接管了台湾，同样需要依靠地方望族来维持治理。地方领袖的家族相当于换了个统治当局合作。

这样我们便理清了，主人公所在的小镇不是因为和平所以没有发生枪杀事件，而是因为地方望族早已与统治体制达成共谋，社会结构本身就是压制反抗的无形大手。

那么解严了，小镇会有变化么？望族士绅的权力不依赖于戒严或不戒严；他们的支配地位是跨政权且跨时代的。对普通百姓而言，换了统治者、解了严，地方上的权力结构依然如故，生活并无实质改变 —— 这便是作者隐藏的另一讯息。

第二节结尾，主人公认为谢彩文已经死了，关于她的一切全都停止了，并想着自己是不是理解了死亡。小说中主人公对谢彩文的死，所抱有的想法，近乎都能和作者对戒严时代的「死」一一相联。在之后，主人公对谢彩文的「死」的看法还会更新一次。

总之第三节开头，主人公思来想去开始写起了以谢彩文为主角的小说，也就是第一稿。这篇小说稿在暗示什么，我研究后有了个大胆的猜想：谢彩文作为「养女」，代表了台湾；韦老师作为「外省来的养父」，代表了外省权威；黄老师可能暗示的是 1979 年美丽岛事件的核心人物之一黄信介。谢彩文对黄先生的爱慕，象征着台湾年轻一代对民主自由的向往，但这种向往在戒严体制下被拒绝和压制。最终，谢彩文毁灭了自我，象征着台湾社会当时的精神状态。

第三节结尾，主人公被这篇小说感动得不行，然后在第四节开头打算新写一篇，却发现怎么写都是在原地打转，根本写不出来新东西 —— 亦或者说「真正」的东西。因为小说中谢彩文的死，是主人公捏造出来的，而她为自己写出来的悲剧而感动。这就是小说标题中的「虚构」。

学长主动向主人公提起二二八事件后，主人公的反应则是「听过但不知道是什么」：

后来我真的去了学长主持的社团，像个乖巧学妹那样坐在圆桌的边边，渐渐知道了许多事情，但我并不了解，按过去的道理来讲，我是不应该知道这些事情的。那时，我天真地以为这些事情，本来就是到了此时 —— 也就是说，像高中老师所说的，上了大学，自由了之后 —— 我自然就会知道的；我不知道诸事的揭晓原来是因为我恰恰逢到了解严的时刻。

这段独白中，「知道」和「了解」的区别是关键。「知道」是接收到了信息：殖民、虐杀、戒严、迫害，这些词汇如今到处都是；「了解」是理解了信息的意义和脉络：为什么二二八会发生、戒严对社会的塑造有多深、这些创伤如何延续至今…… 主人公能「知道」二二八发生了，但她没有足够的背景知识、历史意识和社会语境来「了解」它意味着什么。

这正是戒严体制抹除记忆的深层后果。它不仅抹除了事实，更抹除了理解事实所需的脉络。一个人突然被告知一个从未听过的词汇的定义，他可以记住这个定义，但无法真正理解它在语言中的位置和用法。主人公的处境便是如此，而这也映射了台湾社会在解严后的认知困境。尽管信息通道的门很是宽敞，但理解的能力不会随之自动恢复。

接着主人公收到了郑老师反馈她小说结尾做作的电话。电话里，郑老师也说她的小说要是修好了，还要找地方发表 —— 这里的「发表」很耐人寻味。解严后，社会往往需要打破禁忌的声音，需要有人站出来说话。所以文艺队需要言论来填充解严后刚刚打开的公共空间，也就是要使用主人公写的小说。于是乎，主人公的写作被赋予了政治的功能。

实在不知道咋改的主人公，向学长求了助。学长的建议是让她写小说时有意识点、要刺激点。此处的「有意识」，结合学长这个人以及第二稿的内容，可以明白暗示的是政治意识；「刺激」则暗示了对读者的冲击力，得冲击社会的神经。

但这引出了这些问题：

主人公是没有「意识」的，要如何写出有深度的写作？
为了冲击效果而刻意选择敏感、刺激的题材，是不是「做作」？

这便带来了主人公的第二稿。因为主人公自己也开始理解政治和历史，所以小说中的谢彩文也要被卷入到政治和历史的漩涡。

第二稿里，谢彩文考上大学，离开小镇，进入了台北的知识空间。她发现自己过去的生活是封闭的、无知的，她此前不知道的东西太多。这与主人公自己的经历完全平行。在她向韦老师寻求安慰时，得到的却不是理解，而是夹杂着外省人群体对自身苦难的叙事的谩骂 —— 韦老师拿「战乱经」说她。

这「战乱经」指的是外省人群体对自身苦难的叙事：中日战争的惨烈、国共内战的失败、逃难来台的流离失所…… 这些创伤构成了他们理解世界的框架。当谢彩文表达自己的困惑和痛苦时，韦老师用自己的创伤来压倒她的痛苦。这使得我们看到新的问题：外省人的创伤叙事和本省人的创伤叙事之间存在着竞争和压制关系。韦老师的「战乱经」使他无法听见谢彩文的痛苦，正如本省人的二二八创伤长期被外省政权的大中国叙事所压制。韦老师不理解解严后年轻一代的处境，他仍活在自己的战乱记忆中。这种代际和族群之间的无法沟通，正是戒严留下的裂痕。

而谢彩文不知道自己的身世，是出于刚才提到的大中国叙事 —— 国民党政府在戒严时期所构建的官方意识形态。其中一个核心内容，便是用「我们都是中国人」来压制对实际族群差异的认知。明明台湾人的本省和外省身份差异是存在的，但官方叙事不承认它。

第二稿结尾特别搞笑的，让学长爱上了写小说的主人公自己。叙事还特意注明这是纯粹的爱情，无关政治和历史。

小说中的谢彩文虽是虚构的，但她的处境映射了真实的台湾历史；主人公是纪实的，但她通过将自己写入虚构来为自己创造了一个避难所。为什么这么说？在这段叙事之前，主人公让小说中的学长有了这么一句台词：「没有人能够摆脱政治和历史阴影。」但小说中的学长又是因为无关政治和历史的纯粹爱情而爱上主人公。这份「纯粹」本身是否就是最大的反讽？而谢彩文恰恰死于失去这份「纯粹」，因为她被排除在主人公为自己保留的特权之外。

第六节的开头，郑老师表示主人公的第二稿更做作了。因为这个「做作」，主人公思考了许多：她刚从学长的社团里知道了点事情，就急于把这些知识转化为小说素材，但这些知识对她而言还停留在信息层面。于是当她用这些未消化的知识来虚构时，产出的是知识的堆砌而不是洞察。

这一点，她也应用在了社团的人身上：

…… 坦白说，社团里的求知欲与谈话渐渐使我感到做作，我想，我们彼此炫耀知识，唯恐暴露自己所知仍然停留在解严之前，唯恐同伴讥讽自己心灵不够勇敢，这样的急切，才真正透露禁忌在我们心灵埋下何等阴影吧。

接着她开始思考「虚构」：虚构看似有形，实则无质。一旦被质疑，那便消散了。她的虚构没有坚实的内核。她不了解谢彩文、不了解二二八、不了解戒严的真正含义；她所虚构出来的一九八七，不过是用新的词汇来包装旧的无知。

而主人公这段自我批判的闭环是，我的形貌就是做作的。

亦或者说，所有人都是做作的。

为了好好处理自己的情绪，主人公开始思考解决办法：不能将所有的新知识和情绪混杂在一起了，这只会重蹈郑老师所说的「愈改愈做作」；也不能用刺激性的内容来简单调动情绪了，不过是另一种做作 —— 必须要真正去理解这一切，而解严后短短几个月的时间，是根本不够让她去明白戒严的 38 年、二二八后的 40 年、殖民的 50 年…… 她决定退出社团，回家读书。

她要独自且自由地学习和理解「真实」。她不再依赖社团的集体表演，而是以个体的方式、以自己选择的速度去面对。这里的「自由」是认知上的自主。

学长对此有不同的看法：「知识与行动是不冲突的。」也就是不需要等到完全理解时才行动，完全可以边做边学。以及他批评道「好像喜欢文学的人总是过于洁癖或理想」。主人公的回应是「不要这么说」—— 两人代表了两种不同的姿态。

小说结尾，主人公和学长在圣诞节时见了面。她想到也是在圣诞节左右时去世的谢彩文，情感开始爆发：她向学长提到了真实的谢彩文，就是个普普通通的女孩，没有任何戏剧性的虚构。她又想到曾不停消费着谢彩文、让谢彩文充当自己文学野心和政治思考的容器与工具。鼻子一酸，主人公难过了起来，承认自己对谢彩文残忍、写坏了小说 —— 这是真实的感情，而非做作的虚构。

在学长安慰了一阵后，主人公感觉好了些，最终为「做作」做了个终极的重新定义：1987 年本就是不寻常且做作的，但她认为这一切都是对的；做作不是错误，是必经之路，因为我们必须要透过不寻常和做作的方式才能了解自己。正如一个人只有经历了失败才能真正理解失败的含义，主人公正是经历了做作，才真正理解做作的本质，进而理解虚构的本质 —— 主人公自己和时代，都靠做作理解了虚构的本质。

回顾全篇，「不造作的故事结局」这一贯穿始终的追寻，经历了一个三层升级：最初它是文学技术问题，也就是如何写一个不感伤套路的结局；接着它变成了创作与理解的关系问题：如何才能写出真实的情感，而真实的前提是真正了解所写之物吗；最终它成为一个伦理与政治问题，即在不了解的情况下，是否有权发声？

主人公的回答分别是，「不了解就不应该假装了解」、「虚构无法替代了解」，以及「做作是虚构在缺乏真实时的必然表现」。

「不造作的故事结局」巧妙地通过做作的过程、理解了做作的不可避免性，进而理解了虚构的本质和局限。这便是小说标题《虚构一九八七》的终极含义：1987 年是「虚构」的，整个时代的表达都是做作且不扎实的；但这种「虚构」是必要的，因为只有通过虚构的失败，才能认识到真实的不可替代性。理解虚构的本质，便是 1987 年最真实的收获。

抢房子大战

2026-06-20T04:00:00.000Z

我最近买了手账（或者应该叫「手簿」？），因为我发现我手上的活页本，是 6 环的欧美个人记事本，更适合拿来做手账。

我是怎么发现的呢？因为我六月十五日下午去了趟 MUJI 买文具。我的活页本是 A5 尺寸的，也就是 A4 纸的一半大小，自然也在 MUJI 买了 A5 尺寸的活页纸作为补充。

待我回到办公室的时候，我发现这些活页纸的洞，和我的活页本的环并不匹配。刚才说了，我的活页本是 6 环的，这些活页纸则有足足 20 个洞。

接着我去搜索，得知 MUJI 的活页本和活页纸都符合 JIS（Japanese Industrial Standards，日本产业规格），我的活页本则符合在欧美更常见的标准。

这也改变了两种活页本的用途：欧美的常用于个人规划本，定位是写手账、日程规划、生活管理等；日本的常用于写笔记、自由书写、日常消耗等。这也能从两者的活页纸价格看出端倪，MUJI 的纸好便宜啊！

不过我寻思着，我要为了这 4 块钱的纸专程跑一趟 MUJI 退货么？一种强迫的想法在我的脑内蔓延开来：这个本子是记手账用的，那个本子才是记笔记用的…… 于是我购买了手账用的各类纸，还有 MUJI 的 A5 尺寸活页本。唉，仪式感是消费陷阱啊！

好啦以上都是随便聊聊我近期在做啥，和标题的「抢房子大战」半毛钱没有 —— 你被骗了！

正文

我昨天翻阅 RSS 里的文章时，看到有个文章的评论说「租房唯一不好的就是会被房东赶」，让我想起了一些事情。

我的人生是被劈成两半的，前十年待在中国山东，后十年待在美国纽约。住在中国山东的时候，家里有栋市中心的小区房。虽然当时那房子破破的，还在小巷子里，但终究还是在市中心 —— 三线城市的市中心也是市中心！

我做留守儿童的那两年内，母亲的朋友负责照顾我。不过他们没有把我带去他们家，而是偷偷地不告诉我母亲、入住了我家里来。其实这也没有什么。他们家在一栋水泥楼的顶楼，光是爬楼印象里就要爬很久很久。整个房子小小的，但住着他们一家五口，厨房得弯着腰才能进。我那会儿十岁还没开始长个儿，都得小心不被碰到头。所以再让我拎包入住，光是日常生活就要很累了，更别提学习。

反观我家，足够他们夫妻俩把儿子带过来住。他们的儿子比我大个两三岁应该，初中生快到了长个儿的年纪，学习还得用到电脑。我家正好有台电脑可以给他用。

他是个像我哥哥一样的人，虽然也没有比我大多少吧，但小时候就记得他玩《赛尔号》、《造梦西游》等游戏玩得很厉害，所以还是小学生的我很崇拜他。顺带一提，他也是带我开始看日本动漫的人。

那时候远在美国的父母是想要把山东的房子租给别人，一个月一千块钱，让照顾我的人 —— 以下还是简称「佛教夫妇」吧 —— 做代理人。不过他们瞒着我父母，把自己的钱说是从租客那儿收的，交了上去。

相当于我父母以为我住在佛教夫妇家，房子是另外一户人家在住。实际上住在房子里的，就是佛教夫妇还有我。

之后这件事情被戳破了。我不知道大人们都做了什么，总之我后来被交给了母亲在山东的「亲戚」照顾，房子也确确实实租给了陌生人。

这便是「大战」的开端……

首先，我用引号括起来了「亲戚」二字，是因为我们其实没有任何血缘关系。他们是母亲在山东认的「姐妹」。这群姐妹花总共四个人，带上我母亲就是五个。我小时候常称呼他们为「大姨」、「二姨」、「三姨」…… 但我们实际上并不是真正的亲戚。

不过假戏真做也真是的，我小时候还纳闷我怎么同时有「爷爷奶奶」、「外婆外公」、「姥姥姥爷」。

随着我也移民去了美国后，我们家在山东的房子没有了真正的掌权人。而这些姐妹花的其中一个，在数年后盯上了我们家的房子。

整个争执过程非常可笑。她想要「买」下我们家的房子，首付是…… 两万人民币。这要是十几年前我父母刚买下这套房子的时候，两万首付确实也可以，因为我记得这小区房最初也就十万人民币。但已经过了十几年了，房子早就增值到近百万了，两万首付我们要怎么相信她接下来能付得起呢？更何况她这两万块，还是找其他姐妹东凑凑西凑凑，凑出来的。

所以她的想法很显然，是打算用所谓的「亲情价」，直接获得我家房子，反正我们一时半会儿也不会回国。就算她真的付完房子的钱，也不知道要过多少年了。

因为房子原先是交给了姐妹花中先前照顾我的那位（也是姐妹花中的大姐）来管理，母亲自然而然先去找了她商量。结果对方似是铁了心要把我们家的房子交给自己的妹妹，很多时候直接已读不回，气死人了。这也让母亲心寒，十几年的交情根本比不上血缘关系。

住在我家里好多年的租客就因为这种事情，被我们劝走了。也是为什么我想起了这件事儿。

更生气的是，那人入住我们家时，嫌弃被我母亲拜托清理房子的佛教夫妇没有好好打扫，真是把人当奴仆！她后来被赶走时，反而还在房子的冰箱里放了发霉的饼不丢，杀伤力更重！

至于她是怎么被赶走的。母亲联系上了住在山东的真正的亲戚，写了信寄回国，指定她作为真正的代理人来管那个小区房。同时家里也决定在纽约买房子，急需钱，便在赶走那人之后，让这个代理亲戚卖掉我们家的房子。

不过很可惜，不是所有人都是能被信任的。这个亲戚之前就和我们家不合。她没有在母亲让她卖房子时把房源挂上网，而是在母亲火急火燎问起来后，才把房源挂上网。本来近百万的房子，被她这么一折腾，贬值了几十万。

对于母亲而言，总算是终结了这围绕着房子的战争，不用再去跨国操心它了。但那依然是我出生后就一直居住的房子，让我怀念也确实很怀念。记忆里，客厅墙上挂着一把别人送我的剑，上面还刻着我的名字。现在，已经不知道去了哪里。电脑和电视等家具，也都在我离开中国之后，被那些山东的亲戚或「亲戚」们搬走了。

讨厌礼物

2026-06-16T04:00:00.000Z

我的桌子下方放了个灰色的盒子，专门用来放一些没必要摆在桌子上的东西，例如电池、玩具。这里也包括了一部分别人送我的礼物。

昨天因为盒子里的东西都满了出来，实在是不好找电池，所以我清理了一下。最占位置的都是我的玩具，像魔方，还有朋友送我的周边等。我自己买的玩具，因为我知道我要玩，所以买了也不会觉得有怎么。但朋友送我的东西，就非常占位置，令人讨厌。

我在清理盒子时，发现底部有一些积木零件。几年前，室友买了一套廉价的程序员主题积木送我。它甚至没有一个专业的说明书，零件的质量也非常差，拼出来的成品更是难看得不行。摆在桌上，每晚都会被猫叼走扔地上，已经找不见了许多零件。

「扔了吧。」我这么想着，顺手丢到了垃圾桶里。这一幕被室友瞧见，反而惹得她很生气。

尽管之后我向她道歉、把积木从垃圾桶里捞了回来，她也很生气。这是我们二人无法理解彼此的地方。这个积木对我来说就是不需要的垃圾，我这辈子都不会再动它了。但对她来说，我把她送给我的东西丢掉，相当于是在蔑视她。如果她把我以前送她的东西也扔了，我肯定会感到难过的，那她凭什么不能生气呢。

但我依然不觉得这说得通。她不丢我送给她的东西，本就是我送的东西有价值，值得收藏。但她送我的积木，是一点价值都没有的东西，是和其他朋友硬塞给我的礼物没什么区别的东西。她都能觉得那些朋友经常给我塞的礼物是垃圾，那为什么不能觉得自己送的东西是垃圾呢？最开始，我也没有想要这套积木吧？

上个月我知道了「爱的五种语言」，并将「送礼物」放在了最低的一档。理由很简单：我不喜欢礼物。

我没有送人礼物的习惯，也不喜欢别人送我礼物。今年一位朋友过生日，我送给他的礼物是当日让他自己选的。送对方东西，还是要送对方想要的东西吧。而对方送我的东西，每次都是他觉得我会喜欢，实际上我根本不想要，也不需要，只是放在盒子里积攒灰尘。

我也讨厌用花束作为礼物。那可是植物哎。我收到的话，就会想要去为它负责、让它活下来。所以我还得自费买花盆，如果需要土的话就得买土，如果只用水的话就放水里…… 但这种鲜花，往往都难以活下来，更何况我的家里有一只会啃植物的猫。

未经过许可便买动物作为礼物是最差劲的。对方只管买就好了，全然不在乎我要花费多少精力在小动物身上。这么说，这和怀孕生子还挺像。

小时候在家中，大人们便常常塞给我东西。衣服也好，首饰也罢，都不是我想要的。收吧，不需要；不收吧，不给面子。最后拿着一堆垃圾，扔也不是，留也不是，真难！反倒是我想要的东西，都不怎么有人送给我。久而久之，我也讨厌起了礼物。你硬塞给我这些垃圾，还想要我买东西给你？门都没有！

数多年重试跑步然后晕倒

2026-06-06T04:00:00.000Z

我距上次跑步，也就是初中时期，已经有七八年没有再慢跑过。

我在四月份就有看到他人跑步锻炼，而得到良好的身体状况，以及后续工作效率的提升。因此我对跑步锻炼很是向往，尽管我平日根本就不跑步。

介于五月份中旬我有了骑自行车的习惯，想方设法地抛弃了公交车和地铁，并且在更早的一月份走过半马，我对自己的身体素质相当自信。另一边，室友因为我开始骑车，也适当地抛弃了地铁。不过我们的共享单车会员仅能在一个时间内让一个人骑车。有着更硬的身体素质的她，选择了跑步、我骑车。

说来，室友的身体素质，让她在一月份的走半马后，又陆陆续续走了多次半马、全马，实在是恐怖啊…… 我还是更喜欢骑脚踏车。丁零丁零~

于是，我们二人每周都会花一天的时间，跑步以及骑车到达唐人街、购买食物、玩街机游戏，然后回家处理。

但这么做有个问题，我骑车无论如何速度都是要比她跑步快的。并且我认为，骑车不会让我满身大汗，用的力更像是散步或者快走的力。既然没能累到，意味着锻炼并不到位。我们二人一协商，决定哪天一起跑步。

那一天便是昨天。

因为平日完全不跑步，室友便调整了配速，和我一起慢慢跑。先前和她看过一期跑步的视频，说是跑步期间最不该做的事情，就是用嘴大口呼吸。我想办法让自己用鼻子呼吸、根据室友所说的「五吸三呼」—— 不过后续我查资料发现，美国肺脏协会推荐的是 3:2 节奏呼吸法，即左右左右左右吸、左右左右呼…… 循环。

跑步的时候，太阳挂在天的中间，无疑是个大热天。我们慢慢地从家里开始，一点一点向前跑去。虽说是「跑」，实际上的配速也仅仅是 12 分钟一公里，和快走没有什么区别。

刚开始的时候，我事先发觉到自己的小腿很酸痛。感觉像是，我的小腿突然被要求以不正常的形式承受着压力，让我怀疑是不是跑步的姿势有问题。接着，我意识到左腹的疼痛。等红白灯的时候，我和室友提起了此事，她认为是我岔气了、在用嘴呼吸导致的。可是我没有用嘴呼吸呀。接下来，我笨拙地遵守着「五呼三吸」的规则，忍受着小腿和左腹的疼慢跑着。

直到我们跑了一公里开外、等另一个红白灯而停下时，我的眼睛所能看到的景色忽然变黑了。更像是黑色的滤镜在我的眼球上吧，如果非要比喻的话。我的头紧跟着开始痛、晕晕乎乎的，让我难以保持站立的姿势，本能地想要躺到地上去。当然没有那么做啦，我半蹲在地上感受着晕厥，一旁的室友则不停拉着我，想要让我再走几步。

最后我是躺在了不远处的一块大石头上。室友想要让我坐起来，或者走到别的店里待着，石头毕竟还是很脏的。但我难以保持着坐立的姿势，甚至连手臂都开始变得麻木、难以移动或者感受到触觉。她喂给我水，然后着急地上网查该怎么办。按照她后来说的，当时的我嘴唇都在发白，像是要死了一样。但也只是跑了快走的速度而已，怎么会变成这样呢？

我神智不清地躺在步行街的石头上，自然引来了他人的注意。记忆里，第一个过来问候的是个护士。她一边问室友我怎么了，一边从附近的店里弄来了可乐，让我先补充糖分。按照她的说法，最好是能补充维他命的橙子果汁，但附近没有，亦或者是含有电解质的水。我没听懂太多，只能小口小口被人喂可乐喝。

接着路过了一位医生，询问室友我是否还有意识，接着俯下身给我把了个脉，说问题应该不大。他表示可以帮我们叫个 Uber，赶紧送我回家休息。室友不好意思，婉拒了，转而叫了个路边的车夫。车夫和医生帮我扛到了车内。之后就是被送回家，躺在床上休息。

在身体机能几乎丧失的时刻，这些陌生人的帮助都让我很是感动。但也不得不提，这个车夫走路 10 分钟的距离，竟然收我们 20 多块钱！太贵了、太贵了啊。

回家后，搜索了大批资料的室友打了个草莓蓝莓柠檬盐糖冰沙给我喝，说是用于补充电解质和糖分。很难喝，咸咸的…… 但还是喝完了。

我恢复得很快，躺床上没多久就能用 iPad 查资料了。

首先我搜索的是，为什么我的小腿会如此酸痛。结果这是正常现象，原因是小腿肌肉负荷大，导致乳酸堆积，和微小的肌纤维损伤。

左腹部痛，又称岔气，是运动性短暂腹痛。原因可以有很多，例如呼吸节奏不规律、脾脏释放了红细胞、饭后不久运动等等。

之后的眼前变黑以及头晕，是脑供血不足、缺氧了。我原本的猜测是低血糖，但当时我也刚吃完饭没多久，不太可能。

最严重的手臂变麻，是因为过度换气综合征。原理是呼吸节奏有问题，排出了过多的二氧化碳，引起呼吸性碱中毒，导致血钙离子浓度下降、神经肌肉兴奋性增高、手足麻木且刺痛。虽然话是这么说，但排出二氧化碳为什么会引起碱中毒？我又搜了搜，发现人体需要二氧化碳来维持血液的酸碱平衡。一旦血液偏碱性，就会出现刚才说的情况。

好吧，我明显没能被化学课「教育」到：东西全还给了老师。以至于我对人体中二氧化碳的认知，还停留在简简单单的「排出去是好事」。

但是搜索的第一波资料中，依然有着许多没能解答的谜团在。比如我的配速如此之慢，怎么会出现这么严重的症状？根本就不正常啊。因此我又做了第二波搜查。这波搜查指向了各式各样的原因，例如严重的心律失常、肥厚型心肌病、短暂性脑缺血发作…… 或者更常见的贫血、脱水、低血容量、血管迷走性晕厥、颈椎病…… 我不是医学生，所以这些东西我都没咋看懂。但根据它们的关键特征来看，并不是我的症状，尤其是在场还有医生和护士评估。把脉后医生也说了问题不大，更不可能是心脏问题了。

我认为最有可能的，还是过度换气导致的碱中毒。至于贫血，我不好说自己的血液一次能携带多少氧气，但平日不怎么锻炼的话，这个能力应该很弱吧。

关于室友做的冰沙，我也调查了下，了解了电解质这东西。说是人体的神经和肌肉的运作，本质上是依赖于微弱的电信号，而电解质是维持这些信号传递的介质。过度换气后，体内的电信号会紊乱。草莓和蓝莓是天然的糖分，不仅可以补充血糖，还富含钾，能帮助电解质恢复；柠檬水同样提供钾，还有维生素 C；盐补充钠，是最关键的电解质，且钠能帮助身体保留水分、恢复血容量；糖快速补充碳水化合物，能恢复血糖和肌糖原；冰用来降温 —— 它们都能帮助到我。

我又好奇自己的跑步姿势是否有问题，专门搜索了网络上的资料，了解了下正确的跑步姿势。不过我发现自己的姿势和正确的跑步姿势区别也不大，并且短短一公里姿势真的会影响这么多么？

再就是我明明平时都在骑车啊，体能不可能不足吧。结果真相是 —— 骑车体能根本不能转化成跑步体能。差异分别是：

一、骑车时，肌肉的主要任务是向外推，属于主动发力的向心收缩。而跑步不仅包含了向心运动，也包含离心 —— 脚落地时，小腿肌肉会一边被拉长，一边发力来吸收冲击 —— 和等长收缩运动，对全身施加的力要更大。

二、骑车几乎没有硬性冲击，但跑步时每次落地，肌肉都要承受体重的 2 到 3 倍冲击力。我先前骑车，都没让小腿经历过这种冲击，再去跑步，自然而然会感到疼痛。

三、两者的呼吸模式不同。

我的体能肯定没有差到这种地步，所以我的最终推论是，运动特异性导致的各种问题，引向了我昏迷的结果。如何解决这个问题就变得很简单了，我得学会如何跑步。室友是过去就有跑步的习惯，所以她跑上一天估计也没什么大问题，但让我跑步，我得先让身体搞明白如何从走路「进化」成跑步。就像是骑自行车人们都是一点点学的，我学跑步也只能一点点去习惯，所以未来我出门得跑几步走几步。

我也搜索到了一些跑步外可以做的训练，比如小腿的离心训练，以建立小腿抗冲击的能力，还有各种核心训练、呼吸训练……

再就是我也发现，呼吸时并非绝对不能用口呼吸。慢跑时可以选择鼻吸口呼；中等强度以上就得口鼻同时吸，然后口呼，因为嘴巴能快速地通过更多空气。只用鼻子的话，氧气不够也会导致过度换气。

可以这样练习呼吸：

站着练习腹式呼吸：把手放在肚子上。吸气时肚子要鼓起来，呼气时肚子要缩进去；
走路练 3:2，吸 3 步、呼 3 步；
慢跑练 3:2；
感觉岔气来了，就切换到 3:3，深呼气并按住痛处。

之前看《鬼灭之刃》的时候，就觉得腹式呼吸要更「厉害」些。之后从室友那儿得知，胸部呼吸的坏处，以及她身体的问题，导致她很早就学会且习惯了腹部呼吸。那时候找她学习，但也没学到什么，现在倒是得努力学到那种感觉。

想法在丙午芒种迭代

2026-06-01T04:00:00.000Z

期末周总算是结束了！没有了学业这个拖后腿的东西后，我在这个月花了更多的精力在求职、学习新东西上。

本期导读

我的求职路・壹：投简历和找对方向

2026-05-31T22:00:00.000Z

虽说上个月就在求职，但一直都没能拿到面试，拒绝信收得也很快。这个月因为各种事情，比方说经济方面的焦虑、室友带来的压力、父母带来的压力等等，都让我深觉沮丧和焦虑。焦虑就不用说了，沮丧是因为我认为自己的经验并不差，简历上连玩具项目都没有，全都是我真实参加过、和别人合作过，甚至有盈利的项目。作为本科还未毕业的人，我心想这已经足够让我找到一份实习了吧？但事实是没有，我收到了大量的拒绝信。

有天我和室友吵了很厉害。她觉得都是我的能力不足导致的，更让我的心情降到了低谷。不过架吵到后面，她还是给了点建设性的建议 —— 当然她的那些挖苦和贬低全都是垃圾话，连建议都算不上。有时候真的很想打她一顿，但是我打不过她。流汗流汗。

根据建议，我预约了学校的职业发展部门，希望能从这些专业人士身上得到建议。很不错，我确实得到了有用的建议，分享一下吧。

首先是现在的公司招聘，收上来的简历会先进行一轮 ATS（Applicant Tracking System，申请人跟踪系统）。这东西最关键的一个功能是，根据职位要求自动筛选简历、匹配关键词。没匹配到的，公司就有可能直接刷掉，根本到不了真人手里。

为此，我们可以「逆向」这个流程：自己弄个模拟 ATS 筛选流程的工具，然后自己进行一波筛选，不就可以了？

学校破天荒地做了件好事，那就是内置了 JobScan 这个软件。大家也可以去 JobScan 的官网体验一下：jobscan.co

顺带一提，学校除了做这件好事外，就一直在做坏事…… 例如为了拥抱 Microsoft 的 Exchange，重新设计了邮箱系统，让我们手里又多了个聚合邮箱。原本的学生邮箱收到的邮件，会被自动转发给聚合邮箱。但在聚合邮箱内，转发来的邮件看不到原始的邮件名、发信人，只能看到我的名字，且在 Outlook 里得再展开一次才能看到邮件内容。聚合邮箱也不能用来发信，相当鸡肋。可是不用它又不行，因为学校发来的通知现在会优先发给聚合邮箱。我的手机上同时登录了聚合邮箱和学生邮箱。如果有邮件发给我的学生邮箱，那么总共会弹出三次通知，其中有两次，是转发给聚合邮箱的通知 —— 我也不知道为什么是两次，但就是这样。

回归正题。JobScan 会根据职位说明，扫描我上传的简历，并给出分数和建议。通用的建议是，不要在简历内使用花哨的字体和排版，最好是纯文本或者 Word 格式。

我原本的简历是用 Jobright 生成的。这是一个 AI 驱动的求职平台，可以根据我的简历和目标，自动筛选并推荐最匹配的职位。它也有主流 ATS 平台自动填写申请的功能，需要安装 Chrome 的插件，但我用的是 Firefox 的分支软件，所以用不了这个功能。

Jobright 也有定制简历的功能，我用过几次，是挺不错的。但它作为一个 AI 产品，肯定是不给一直免费使用的，因此它有 credit 系统，一天只能定制化几次。对于「不发个千来份简历亚洲人就不准说三道四」的美国职场而言，几次算个毛！所以我放弃使用 Jobright，仅用它找岗位 —— 别说，能找到很多岗位，很适合弥补 Indeed、Handshake 这类求职平台上岗位不够的点。

Jobright 生成的简历，我给职业发展部分的工作人员看了，他们觉得在排版上依然可以做得更好。可是 Jobright 不能随便改排版…… 思来想去，我决定设计一个流程。我拿 Org Mode 文件作为简历的信息源，然后用什么工具自动生成简历的 PDF 格式出来。这样我就可以很方便地定制简历。

这是一个大致的 Org Mode 模板：

#+TITLE: Resume#+OPTIONS: toc:nil num:nil author:nil date:nil#title:nil#+begin_export html  名字
  城市, 州 邮编号码 | 电话 | 邮箱地址 | GitHub 或者 LinkedIn 地址
#+end_export* 教育** 大学名称 / 学院名称 | 啥时候毕业学位 \\/专业/* 专业经验** 公司或者项目名称 | 开始 - 结束/岗位名称/- 详情* 技能- *技术栈：*- *兴趣爱好：** 语言- 要是在美国的话就不要写英语了，这和在中国没人会说自己会汉语是一个道理

Pandoc 可以将 Org Mode 文件转换成 HTML。因为 Org Mode 本身无法排出自定义的 header，所以我是直接写了原始的 HTML。

生成命令：

pandoc resume.org -o resume.html --standalone \       --css=resume.css \       --lua-filter=split-headings.lua \       --metadata title="姓名 - Resume"

其中我的 CSS 文件是从 Jobright 生成的简历中，逆向出来的，再做了些更改。内容如下：

@page {  size: letter;  margin: 0.375in 0.5in 0.555in 0.5in;}* { box-sizing: border-box; }html, body { margin: 0; padding: 0; }a { color: inherit; text-decoration: none; }p { margin: 0; }ul {  margin: 0.1em 0 0.3em 0;  padding-left: 1.1em;  list-style: disc;}li { margin: 0.05em 0; }body {  font: 11pt/1.3 "Arial", "Helvetica", sans-serif;  color: #000;  max-width: 7.5in;  margin: 0 auto;  padding: 0.375in 0.5in 0.555in 0.5in;}@media print { body { padding: 0; max-width: none; } }.resume-header { margin: 0 0 0.6em 0; }.name {  font-size: 23pt;  font-weight: normal;  margin: 0;  line-height: 1.1;}.contact {  font-size: 10pt;  margin: 0.15em 0 0 0;}h1 {  font-size: 13pt;  font-weight: bold;  margin: 0.7em 0 0.25em 0;  padding-bottom: 0.05em;  border-bottom: 0.75pt solid #000;}h2 {  font-size: 12pt;  font-weight: bold;  margin: 0.5em 0 0 0;  display: flex;  justify-content: space-between;  align-items: baseline;  gap: 1em;}h2 .rhs { font-weight: bold; white-space: nowrap; }h2 + p {  font-size: 11pt;  margin: 0.05em 0 0.1em 0;}h2 + p em { font-style: italic; }ul li strong { font-weight: bold; }h1, h2 { break-after: avoid-page; page-break-after: avoid; }li, p  { break-inside: avoid; }

而 split-headings.lua，是将 level-2 的标题变成这样的 h2 标题：

公司名 日期

这样 CSS 才能用 flexbox 将日期推到右边去。

这是 Lua 脚本的内容：

function Header(el)  if el.level ~= 2 then return nil end  local s = pandoc.utils.stringify(el.content)  local left, right = s:match("^(.-)%s*|%s*(.+)$")  if not left then return nil end  el.content = {    pandoc.Span(pandoc.Str(left),  {class="lhs"}),    pandoc.Span(pandoc.Str(right), {class="rhs"}),  }  return elend

有了带 CSS 加持的 HTML 后，我们便可以用 WeasyPrint，将 HTML 转换成 PDF 了。WeasyPrint 是个 Python 库，下载后可以直接在终端内使用。我为了自动化，写了个 Makefile：

SRC := resume.orgCSS := resume.cssHTML := resume.htmlPDF := resume.pdfSRC_ITS := resume-its.orgHTML_ITS := resume-its.htmlPDF_ITS := resume-its.pdfSRC_FE := resume-fe.orgHTML_FE := resume-fe.htmlPDF_FE := resume-fe.pdf.PHONY: all html pdf its fe watch clean openall: pdfhtml: $(HTML)TITLE := Xueshan Wang — Resume$(HTML): $(SRC) $(CSS) split-headings.luapandoc $(SRC) -o $(HTML) --standalone --css=$(CSS) \  --lua-filter=split-headings.lua \  --metadata title="$(TITLE)"pdf: $(PDF)$(PDF): $(HTML)weasyprint $(HTML) $(PDF)its: $(PDF_ITS)$(HTML_ITS): $(SRC_ITS) $(CSS) split-headings.luapandoc $(SRC_ITS) -o $(HTML_ITS) --standalone --css=$(CSS) \  --lua-filter=split-headings.lua \  --metadata title="$(TITLE)"$(PDF_ITS): $(HTML_ITS)weasyprint $(HTML_ITS) $(PDF_ITS)fe: $(PDF_FE)$(HTML_FE): $(SRC_FE) $(CSS) split-headings.luapandoc $(SRC_FE) -o $(HTML_FE) --standalone --css=$(CSS) \  --lua-filter=split-headings.lua \  --metadata title="$(TITLE)"$(PDF_FE): $(HTML_FE)weasyprint $(HTML_FE) $(PDF_FE)watch:@command -v entr >/dev/null || { echo "install 'entr' (pacman -S entr)"; exit 1; }@ls $(SRC) $(CSS) | entr -c make pdfopen: pdfxdg-open $(PDF)clean:rm -f $(HTML) $(PDF)

使用方法很简单：

make pdf 来自动执行 Pandoc 和 WeasyPrint 操作
make watch 用 entr 监听文件变动后自动重新构建
make open 用 xdg-open 来打开 PDF，供我们浏览

好了介绍完我的简历生成工具后，重新说回 JobScan。我事先弄了个统一的简历，写上必须要带上的信息后，就会上传这份简历到 JobScan，和任何我想要申请的岗位配对。大多数时候，JobScan 会直接给个 20 到 40 分左右，惨不忍睹。不过没关系，我们可以拷贝一份简历出来，专门对该岗位进行定制化。

JobScan 会扫描出所有该岗位有可能会视作关键词的内容，例如技术栈、技能，还有软实力要求。我发现许多找计算机领域岗位的人们，对软实力没有概念，以为只要努力刷题、做项目就可以找到工作。实际上，软实力非常重要。

因为我自己就有个「公司」，也和其他开公司的人打过交道，觉察出站在企业老板，或者部门招聘人员的角度来看，他们很多时候要的仅仅是个 vibe，也就是「氛围」。硬实力重要么？如果真的那么重要，为什么会有那么多草台班子公司？再加上一个人的氛围，决定了他未来在公司里好不好一同共事。

当然最基本的硬实力还是要有的。你总不能没刷过题就去申请算法岗吧 —— 坏了，我怎么记得之前有人跟我吐槽过公司里招了个什么都不会的人。

好了大致的投简历环节说完了。接下来还有拿到面试的面试环节…… 但我不打算对这个展开聊聊。你要问我为什么，理由很简单，因为我现在还没拿到面试啊！不过值得高兴的是，在我开始用 JobScan，截止到现在，都还没有出现任何拒绝信。我希望未来是光明的 —— 大概吧！

但我想聊聊美国的内推文化。印象里中国没有这东西，因为过去还在用小红书的时候，就有看到国内的人吐槽有留学生回国找工作，找到了自己并想要约出来了解行业内情以及要内推。他当时说的是，这些事情根本就不会有人说，已经很忙了还要被叫出来 coffee chat。

这种行为在美国被称为信息面试（information interview），别名也叫 coffee chat、networking…… 其实就是主动约在业人士出来喝咖啡，建立关系、获取内推机会，亦或者是认识其他更有地位的人。

所以主动给陌生人、校友、LinkedIn 联系人发 cold message 约出来喝咖啡，在美国是件很常见的事情。不过因为我并不乐意和陌生人主动交流，所以我很难去体会这件事…… 这也是我不得不克服的事情。因为常见，甚至都有完整的话术体系。网上有大量的资料教人们如何写 cold email、如何聊天、聊完怎么跟进…… 是的，它是求职的必修课。

我对国内的印象是，中国人会将这种行为视作为「走后门」，且就算要走后门，也是给已经认识的人走，而不是给陌生人这个机会。我自己也不喜欢内推文化，仅次于酒桌文化和小费文化。它很容易发展成 nepotism，也就是裙带关系，真正的「走后门」。

相当带有种族偏见的是，美国有很多声音表示讨厌印度人。他们简直是内推文化的最佳受益者，因为他们不在乎要内推会不会尴尬，满眼都是对工作的渴望。这一点来源于硅谷的科技行业，那有着很成熟的印度生态圈，从校友会、专业组织，到投资圈，都有着完整的链条。

讨厌印度人则来源于他们的「抱团文化」。人们普遍认为，印度裔群体在大公司中层与高层占据了话语权，掌控了招聘、晋升和预算。甚至还有名言：「只要印度人和其他人起冲突，公司里其他印度人会无条件支持印度人。」

过去在华人圈混迹时，我总结了一些印度人和中国人的区别 —— 当然并非指代所有印度人或所有中国人。嗯这种话我有必要声明么？首先是印度人的母语就是英语，就算他们有着极其魔性的口音，那也是英语。英语作为第二语言的中国人，普遍有着较低的表达自信度以及表达欲望。这一点我在我身上也发现了。

其次是中国人有着谦逊文化，不善于推销自己。这在美国是个很大的劣势。外向、愿意自我推销的人，在美国活得更滋润。

我这几个月来一直在断断续续阅读《大教堂与集市》，目前读到了第三章。这本书我在 Fediverse 上有条专门的笔记嘟串。第三章的重点在于，驱动黑客文化的并非经济价值，而是自我满足和同僚声望，也就是 egoboo。但是黑客们并不愿意承认这一点，自我主义对他们而言是可耻的。他们所做的各种事情，在他们口中都是「无私」、具备「专业素养」的，但又真的如此么？

我还在学习期间，不过我确实发现了黑客们缺乏自我营销的能力，以及渴望。这被作者 Eric Raymond 认为是谦逊文化。既然如此，同样普遍存在着谦逊文化的中国人，是否就会导致两两相加、双倍的谦逊呢？至少对我而言，是这样的。

最后是中国人的组织很分散。据我对在美华人的观察和了解，内部斗争相当常见。福建人里，可以根据所在的城市或者县城分成多个帮派，互相鄙视来鄙视去的；说粤语的歧视说福建方言的，说粤语里的人又可以分成广东人和香港人，也会互相看不顺眼；融合了一些西方文化的，瞧不起不会说英语、更带有中国文化底色的人；完全融入了西方文化，比方说 ABC（American-Born Chinese，在美国出生的华裔后代），觉得说汉语很丢脸；新移民与老移民之间的斗争更是说不完；哦天呐，我们还有政党斗争，支持中国共产党的 v.s. 支持美国民主党的 v.s. 支持美国共和党的 —— 把除了我以外的华人都赶出美国、让美国再次强大！

由此可见，内部斗争有多复杂、多常见。

再加上华人圈总是会被一种被西方社会审视的紧张感存在，即刚才说到「ABC 觉得说汉语很丢脸」。这种紧张感源自于东西方文化的差异，被简单地划分成了「土」和「现代化」这对黑白。类似的批评有，「中国人都吃狗肉，太恶心、残忍、落后了！」我发现很多中国人对此的回应是，「我不吃狗肉」，但这正中下怀，因为你根本不需要去接受对方说的「吃狗肉等同于落后」的逻辑。一旦你也开始认为「吃狗肉等同于落后」，那么你就间接性地证明了「吃狗肉的中国人都落后、多数中国人吃狗肉，因此中国人多数是落后的」这一逻辑。

我喜欢狗，并不会吃狗肉，又是为什么呢？因为我讨厌偷狗贼，以及为了刺激小孩子、杀狗吃的大人们。他们无疑是可恶的，但不能直接认为是食用狗肉有问题。文化是文化，不符合西方标准的文化就是落后的文化么？这是殖民思想，不可取。思想过于狭隘才是落后。

关于美国华人圈，尤其是底层华人圈的事情，一直都想要聊聊，但介于一些个人因素，决定还是放着不管…… 未来再说吧。

总之回到内推文化一事，我也只能入乡随俗了，毕竟没有钱才是最可怕的。在我习惯这东西之后，我会再写一篇文章跟进。

最后的最后，让我以我和一位亲戚之间的谈话作为结尾吧，希望能对所有对找工作、未来迷茫的人有所帮助。这位亲戚是个远房亲戚，远到我都没有见过他。和他通电话，也是母亲为我「预约」的。这又要谈到父母对我找不到工作的焦虑，又或者说是「我不如他人」的焦虑。反正这种事情也不是第一次了，早在以前、高考时，都发生过一样的事情，让人心烦。

亲戚作为税务公司的老板，给出了新的视角，即跨学科岗位的重要性。用他的话来说，他越来越不需要只会当会计的人，因为太多了，并且不会给自己的公司带来突破。专才在现有的公司里，最多成为金子做的螺丝钉。螺丝钉不论是生锈的，还是金子做的，都只会是螺丝钉。但跨学科的泛才不同，他们有着更广的视角，能看到专才看不到的东西，并且将两个学科的工作结合在一起，那他们就可以变成齿轮，不单单是个小小的螺丝钉。

于是我去思考了下自己的定位。我不太适合待在科技公司内，因为我并没有那么 tech，又或者说「硬核」么。我不喜欢算法、没刷过题，做的事情也更多是面向业务逻辑的。这种情况下，纯写代码已经不够有竞争力，理由便是 AI 工具的诞生。大量基础的编码工作被交给它们来处理，但去理解业务问题，并用代码解决的人还没有多到数不清。

调查后我发现，常见的组合有：CS 兼医疗或生物信息、金融或量化、制造或工业、法律或合规、AI 应用落地 —— 最后这个是今年最火热的需求，出于各种我们都熟知的原因。

因为居住在纽约市这个金融大区、学校是商科学院，还有 AI 应用这玩意儿的火热…… 我给自己暂且定下来的目标是 FinTech + AI 应用。

实际上在和业内人士聊天期间，我发现这类传统行业在科技方面，可以说是还未跟上潮流，那我喜欢阅读博客文章、新闻的兴趣爱好也能派上点用场。像是一些传统行业的大厂，还在慢慢学习使用在科技领域里已经被淘汰的框架。

所以说，也不要把目光锁定在科技巨头身上。要把视野再放宽一些嘛。

和这个亲戚聊完后，我设立了新的学习目标，并打算把学业扔到一边去。破大学，爱上不上！当天也有另一位亲戚在家中拜访，和我聊了聊人的优势。他的大儿子今年十岁左右吧，患有 ADHD。虽然听上去是个缺陷，但他发现儿子在做自己喜欢的事情时，会比其他人更加关注。而这件事就是做机器人 —— 好刻板印象啊！

每个人都有自己的特点，而我们应想办法将特点转换成优势。我时常觉得自己不够好，是因为把自己放在了错误的环境。科技巨头里人人都会写代码，狗写的代码都比我写得好。但如果我跑到另一个领域内，成为了那里唯一一个会写代码的，不就行了吗。

初三的时候，申请的高中要开始决定收还是拒绝我们。当时的班主任，虽然是个很讨人厌、很烦的大妈，但她说的一句话我现在才搞明白有多重要：「就算去了不是最顶尖的学校，你也能在其他不够顶尖的学校里闪耀着光芒。」

祝我求职顺利！

我开始有健康的生活习惯了

2026-05-31T04:00:00.000Z

不知道是否有读者还记得，上个月我因为自己没有运动的习惯而感到沮丧。这个月，准确来说是五月十三日。这天凌晨，我和别人吵了一架，气冲冲地睡着了。然后睡了三个小时，早上六点多醒来，突然萌生了想要运动的想法。尽管只是骑自行车，但总比躺在床上刷手机好吧。

这个冲动让我坐了起来，思考着既然要出门骑车，那我要去哪里呢？我忽然想到，这么早的话，我是不是可以去吃个早餐？我的生活作息糟糕到，一天的第一顿饭可能是下午才吃。七八点的早饭相当罕见。

我又开始想，吃早饭的话，吃什么好呢？家附近貌似只有咖啡店和面包店会七点开门，但我不喜欢喝咖啡，也不喜欢吃面包。大脑深处的某个记忆片段，随着我对食物的联想，觉醒了！—— 我要吃肠粉！

好吧，其实并不是因为我有多么爱吃肠粉，而是我能想到的，这里能七点开门的食物只有广式或港式早点。肠粉则是我在早点内最喜欢的一类。我小时候的生活习惯，早上是要喝粥的，尤其是小米粥和南瓜粥。再配个饼或者茶叶蛋，嘿嘿，不过我所在的地区毕竟是广东人或香港人还有福建人扎堆的地方，这些食物并不常见…… 又或者我可以直接吃正餐：嗦面。可惜面馆在这儿都是十一点才开门。

总之我换好衣服出门，用 Transit 这款 app 导航，一路从中城骑到了唐人街。Transit 作为骑行导航的一大好处是，它会根据 Openstreet Map 内更细致的内容，来生成一条能尽量待在 protected bike lane（受保护的自行车道）内的路线。这对我来说实在是太爽啦！我真是受够了那些要和汽车近距离贴在一起的路。

不过 Transit 不会像 Apple Maps 那样，告诉我第几个路口或者红绿灯要转向，反而是像 Google Maps 一样，告诉我多少米后再转向 —— 我又不是机器人，我怎么知道多少米是哪里！但仔细听它报的街道名，再找到正确的街道名并转向，也是个不错的体验。

去唐人街的路上，本来以为会很远很累，实际上仅花了 20 来分钟。要知道我坐地铁的话，过去也差不多是这个时间。还了共享单车后，我意识到一件事：我没有做足计划，不知道去哪家店吃肠粉好。

因为我没有小红书了，所以看不到本地华人们真挚的推荐 —— 要是软广不存在的话。我决定用 Kagi Assistant 帮我结合 Yelp 这类平台，帮我找出最推荐的字号。最终它建议我去「银记肠粉店」。

这家店的装修怎么说呢，用了很多国潮元素。整体的颜色和风格，一点都不像是当地的夫妻小店，反而像是连锁快餐店。播放的音乐是英语流行乐，特别大声，更没品了。

我点了最喜欢的虾肠粉，还有港式奶茶。味道不错，上菜速度很慢，所以合理怀疑是现做的。吃完后又给室友买了份。当时我打电话叫醒她，并让她猜猜我在哪里时，她很是吃惊。

回家路上我又听室友的指令、买了只三皇走地鸡回家 —— 为我之后体重破记录一事埋下了伏笔……—— 感觉一天充实了许多呢！回家自然也是骑车回去的。我和室友共享了 Citibike 会员，一年 200 多块钱，每个人对半劈就是 100 多。作为会员，骑普通自行车前 45 分钟都不花钱。而坐地铁，我要花 3 块钱。哪个最值当，我想我不用多说了吧！

骑车回去，经过了一段根本不是给人骑的路…… 以至于我的鸡和肠粉的酱都被震到了地上。本来很生气的，但想到这又不是给我吃，一下又觉得开心起来。我真是邪恶。

单单一天的骑车，就能说成是我有健康的习惯了么？当然不是！那天的骑车，还有五月的大太阳，让我意识到运动的美妙！于是接下来的日子里，我变成了单车超人……

首先是打工回家，我都会骑自行车回来。差不多是 4.5 个英里的距离，我骑车的速度很慢，时间只能维持在 46 到 50 分钟之间。

再就是我会有骑车去很远的地方的冲动。五月十五日我早上醒来决定去见一位朋友。如果坐地铁的话，我到他家至少得半个小时吧。但我偏不，我要挑战自我、挑战极限！所以我要骑自行车过去。大致花了 104 分钟，骑了多少英里不清楚。Citibike 这个 app 居然查看历史记录时，不会显示距离。

这期间我有无数次想要放弃…… 没办法，我平日就不运动，身体很弱。但坚持下来的感觉，也很棒。路上我经过了许多从未经过的社区。整体的感想和我年初走半马时很类似。不过那次我是和别人边走边聊天，这次我只有一个人。

惊喜的是，我不停在骑行一事，传染给了室友。她和我不同，是愿意跑步的，并相约每周都选一天出来运动：她跑步，我骑车。我们可以去唐人街，逛超市、买更便宜的菜，还有三黄走地鸡！这种鸡的肉实在是太鲜嫩、好吃了。室友的做法很简单，锅里放椰子水，煮开后下鸡肉，直到它们的体内温度到 70 度左右，捞出蘸酱吃。这个酱其实就是海鲜酱油，配香菜、小米辣和柠檬汁，特别好吃。

因为煮起来很方便、很快，我这个厨艺白痴也能做，所以做饭对我来说不再有阻力。我不得不去承认一件事，那就是我很懒，很懒，很懒…… 因为懒，一整天都不吃饭的事情也发生过，对自己的身体实在是不珍惜。也因此，我的身体状况挺差的，BMI 常年在不健康的范畴。整个人就是个皮包骨，没点肉。

但是现在不一样了，我吃饭可以自己煮鸡肉。配点喜欢的上海青作配菜，主食随便选米饭或者面条就行。这样吃了几天，我的体重竟突破了最高记录！

今天本是为了写月刊，所以在复盘日记内的内容，结果写完这一段，意外觉得还挺感动的。我从初中开始便维持着同样的身高和体重，到现在大三结束，都不见任何变化。未曾想，我某天醒来所有的冲动，打破了这个「不变」。说实话，也不是什么特别大的事情，但这种长期静止不前的小事情，还是很戳我的泪点的 —— 我的意思不是我有哭，我只是很感动而已！

说来那天早上的冲动，也有一些是出于我上个月引用的胡拉图的文章。当时我的想法就是简单的「晨练可以让接下来的工作效率变高」，最后因我大脑的跳跃性，一路演变成「我要骑车去唐人街吃肠粉」。

这又让我想到，今天阅读的一篇文章，名叫 Being Small。虽然内容和我想要聊的事情完全不相关，它是讲家庭暴力中那些细小的暴力行为的，不过我想要借它的标题一用 —— 我因为阅读了一篇文章，记在心里的很小的想法，竟推动了一连串小小的事情，最后达成了小小的，但对我来说意义很大的目的。我希望我能一直持续下去，并见证它们像推雪球一般，未来会变得多大。

观 Obsession

2026-05-25T04:00:00.000Z

五月了，夏天到了，是时候品尝一些恐怖片了。

电影前

去年看 FNAF 2 时，看到了 Obsession 的预告，很感兴趣。因此决定和跟我一起吃了 FNAF 2 这坨臭狗屎的朋友再来看 Obsession。

它的预告片有趣在哪儿呢？和一大堆只要看了预告片就能知道电影大致讲的什么的恐怖片不同，它的预告片仅截取了电影中的一段。你好像知道故事是什么样，但是你又模模糊糊不知道。

最后再说一次，不想要被剧透的不要往下看。

电影中

电影内容整体来说没有破坏我的预期。开头角色们的简单塑造我还挺喜欢的，所以接下来的崩坏令我惋惜 —— 奇怪，我为什么会在恐怖片里渴望看到幸福的人们？

故事主要以 Bear 为重心。他暗恋好友 Nikki 许久，想要表白，但又没有这个胆子。另一位好友 Ian 一直在作为「军师」帮他。

除了这三个人，小团体里还有个 Sarah。所以是两男两女的经典组合，他们不仅是彼此的朋友，也是同事。

一天回家，Bear 发现自己的小猫 Sandy 误食了药物、死掉了。精神受到打击的 Bear，得知 Nikki 丢了项链，恍惚间去商店购买了名为 One Wish Willow 的玩具，并认为这可以让 Nikki 打起精神。

四人晚上去酒吧玩。Ian 看出 Bear 很想跟 Nikki 说话，怕傻哥们儿直接表白，所以不停在搅局。不过最终还是因为 Nikki 想要提前回家、Bear 愿意送他，让他们二人有了独处的空间。

这里有个小桥段，是 Nikki 借了钱并施舍给酒吧门口的流浪汉，表明她是个很善良的人。和 Bear 车上独处这段时间，我们还能得知，Nikki 实际上在写作创作。她否认 love story 等同于 romance，因为后者会有圆满的结局，而前者不一定。

单靠这段就写作的对话，我们便能看出，Nikki 心思要比 Bear 细腻许多 —— 实际上在后来我们还能发现，几乎所有人的心思都要比 Bear 细腻，也是很搞笑了 —— 尤其是 Nikki 回家前，Bear 还像个大傻子称呼她为 Freaky Nikki。要知道，这是 Nikki 以前在学校被霸凌时，霸凌者们给她安的称呼。这激怒了 Nikki，觉得 Bear 心里有鬼。在 Bear 不断地道歉时，她直接询问 Bear，是不是喜欢自己。

出于被拒绝的恐惧，Bear 选择否认。这让他接下来懊悔不已，拿出许愿玩具，许愿让 Nikki 爱自己胜于所有人。

我本以为这个场景结束后，荒诞要等到下个场景才会开始出现。结果好家伙，Bear 刚许愿完 Nikki 就出现在了他的车旁边，嚷嚷着要去 Bear 家里，还说自己父亲有了癌症、要死了，不想一个人待着。对于 Bear 而言，脆弱的女神需要自己，自己哪能拒绝。结果 Nikki 要求要和 Bear 一起睡，并尝试吻他。Bear 耐不住，想要抱她、回应她 —— 未曾想 Nikki 突然尖叫起来，推开 Bear，然后又哭着道歉，说自己精神状态不太好。

我对前期 Nikki 时而抽搐的行为，认定为此时「邪灵」（姑且如此称呼）并没有完全占据 Nikki 的身体。推开 Bear 的是真正的 Nikki。后面也说了，Nikki 过去承认道只把 Bear 当弟弟看待，如果 Bear 向自己表白，就给他发好人卡。

到了第二天早上，荒诞的事情开始慢慢发生……Nikki 将 Sandy 做成了纪念物，想要送给 Bear。作为任何心理健康的人，都不会想要去世的爱宠被别人从垃圾袋里掏出来、做成莫名其妙的纪念物吧！因此 Bear 很不高兴。

上班期间，Bear 赶紧把事情告诉 Ian，Ian 则认为不可能。谈话期间，站在前台的 Nikki 一直笑眯眯盯着 Bear，相当惊悚…… 电影最开始可爱的 Nikki 去了哪里！

Nikki 则将错归给了摇头丸，说自己有在吸食毒品，所以才会做这些疯狂的事情。接着她向 Bear 表白，两人成为了恩爱的情侣，全剧终……

…… 个鬼啦。其实我原本以为这一幕，是 Bear 在幻想，看来是我更刻薄一些么。总之在他们恩恩爱爱的一场约会中，Ian 打来电话。他早觉得奇怪了，自己也是 Nikki 的好 homie、知道 Nikki 对 Bear 不感兴趣，怎么突然两个人甜蜜起来了？

Ian 还透露，Nikki 说的什么父亲患癌，根本都是假的。Nikki 讨厌自己的父亲，早就和父亲没有任何瓜葛，父亲也健康得不得了。Bear 害怕地察觉出，Nikki 对自己的喜欢恐怕是出于愿望，而非真心。

在 Bear 的询问下，Nikki 在公共场合哭喊起来，并反问 Bear 这真的重要么？Bear 为了让她安静下来，只能同意说确实不重要。

晚上睡觉时，Bear 发现身边的 Nikki 不见了，接着发现她站在房间的角落。我当时看的时候，发现房间里同时有两个「人」的形状，很奇怪。接着发现左边明显是挂起来的大衣，那右边的是…… 果然是 Nikki 啊。不得不说，Nikki 一会儿甜美一会儿尖叫的反差，是这部电影的核心恐怖点。不过出现的次数过多，到后面便变得好笑起来。

在 Bear 的质问下，Nikki 说自己只是在看他睡觉，太可爱了没办法。接着哭泣道说 Bear 不像自己爱他那样，爱着自己 —— 不，这种话，不要再说了！难道每个浪漫关系都要经历这句话么！

次日 Bear 要上班出门，发现 Nikki 竟然用胶带将前门封死。Nikki 一边说自己会很想 Bear，一边说要是 Bear 开不了门的话，可以直接不去上班的。而 Bear 做的竟是，强行把门打开，然后喃喃道「没关系」…… 实在是过分荒诞了。

Bear 走后，有一段 Nikki 一边笑着，一边望着他离去的背影，一边失禁的场景。我很好奇为什么导演要专门做出来「失禁」的画面？我的第一反应是狗。

午餐期间他一边吃着 Nikki 带给自己的三明治，一边和 Sarah 有一句没一句地说起话来。Bear 发觉 Ian 开派对竟然不带自己，并质疑 Sarah 为什么要在背后跟 Ian 谈论 Nikki。

在前面和真正的 Nikki 在车上独处时，Nikki 其实问过 Bear 对 Sarah 有没有感觉。Sarah 认为 Nikki 有问题，而且会伤害到 Bear，但这种关心被 Bear 解读成「讨厌 Nikki」，还生了气。两人快要吵起来，且在 Sarah 决定揭露出什么的时候，她的父亲过来打断了她：原来是 Sarah 一直在申请入学艺术学校（为了成为纹身师），而父亲带来的是学校的拒绝录取信。她还有最后一所学校的申请结果不知道 —— 不过我们都知道，故事一旦半场便开始塑造「希望」，那么即将迎接「希望」的角色最终都会迎接「死亡」。

就算是 Bear，也知道这时候不该继续和朋友吵架，于是安抚起了 Sarah。

以为这个场景结束了吗？才没有呢！被俯身的 Nikki 总是能给我们惊喜：她将 Sandy 做成了三明治，并在 Bear 的午餐盒上写下「『猫』你打几分？」的字眼。我这个时候特别想要吐槽，导演对猫是有什么恨意在吗？快一小时过去了这个猫来来回回被折腾了足足三次！

Bear 呕吐后，晚上下班顺便载着 Ian 回家。Ian 路上吐槽道，明明 Bear 前不久还跟自己说 Nikki 出了问题，怎么现在又恩恩爱爱起来了。Bear 的回答是，Nikki 磕了药，她好好的、没事。二人也就「Ian 开派对不带自己」一事吵了起来。

Ian 回应道，他觉得 Nikki 正在经历什么，并且 Bear 正在趁人之危，毕竟 Bear 喜欢 Nikki 也不是一天两天了，他才不想要邀请二人来派对。这激怒了 Bear，觉得 Ian 正在毁掉好的事情，还说明明是 Nikki 无法离开自己。从这一段可以看出，Bear 对好友的质疑起了防御心理，不断地美化他和 Nikki 的恋情、否认他人的怀疑。Ian 吵不过，说既然你觉得你俩的关系是健康的，而非建立在相互依赖之上的话，那你完全可以靠「一个人来我的派对」证明。那样的话，其他人也能明白二人的恋情是健康的。

Bear 回家打算跟 Nikki 说自己晚上要去 Ian 家参加「男生之夜」前，在车上发现了另一个许愿玩具，并看到玩具生产公司的电话号码。他打电话过去，想要修改自己的愿望。

电话那头儿起初像是随处可见的客服，帮「把玩具信以为真」的客人随便排忧解难。Bear 得知，愿望不仅不能被修改，也不能被取消，将会直到自己生命终结之时才会结束。

然后，未曾想电话的另一头竟主动问 Bear，是否想要和 Nikki 谈谈。紧接着，电话传来 Nikki 的尖叫声。恐惧让 Bear 赶紧关掉了电话。

我对这个尖叫声的解读是，真正的 Nikki 的尖叫。先前也能看出，真正的 Nikki 时不时会突然出现，例如和 Bear 初次接吻时，她突然推开 Bear 并大喊 what the fuck!，但又马上开始道歉。推开 Bear 的是真正的 Nikki，道歉的是虚假的 Nikki。

回家开灯，发现 Nikki 竟然浑身都是呕吐物和排泄物，站在 Bear 出门上班前所站在的位置，一直不开灯地在等他回家。Nikki 洗澡期间，Bear 站在门外说自己要去「男生之夜」，却被 Nikki 揭穿明明 Sarah 这个女生也会去。在 Nikki 尖叫和哭喊着「如果你想要我去的话，早就会让我一起去」后，Bear 妥协带上了 Nikki。

派对开始时，Bear 和 Ian 的对话也很有趣。Ian 说早就知道 Bear 会带 Nikki 来，Bear 反过来说是 Sarah 邀请 Nikki 来的，并且怪罪 Ian 没有按照原本说的那样、不让 Sarah 来。Ian 回答说 Sarah 没做错什么，Bear 反呛道「我们也没做错什么」。

派对游戏中，Nikki 开始读自己写的 love story。很明显，这并非真正的 Nikki 之作，因为小说内容是改编后有了更多色情、血腥和乱伦情节的 Hansel and Gretel，即《糖果屋》。

这一念，大家全都尴尬了起来……Bear 继续游戏，抽到的大冒险是亲吻坐在左边的 Sarah。这一段近乎让影院笑场了：一是出于 Nikki 听到后的愤怒表情；二是出于 Sarah 看到 Nikki 的表情后、做出的皱眉以及疑惑的表情；三是 Nikki 摆着同样的表情走到一直在皱眉和无语的 Sarah 后面，将对方挪开，然后跑到了 Bear 的左边、索吻；四是其他朋友们的尴尬表情；五是 Sarah 紧接着站了起来表达不满；六是 Nikki 被吻后，对着所有人说的「玩笑话」。因为不好笑，没有人笑，她还耸耸肩表示那就这样吧。

然后，Nikki 突然尖叫着往后退去，大喊着 It's not me!，摔碎了玻璃杯并打在自己头上。这吓坏了所有人，除了 Bear…… 是的，他冷漠地坐在自己的椅子上，尽管 Ian 一直骂他叫他站起来、带 Nikki 去医院，他依然一点表情都没有地坐在那儿 —— 回避型人格啊。

二人回家后，Bear 问她为什么要这么做，得到的回答是「我知道 Sarah 喜欢你」。这让 Bear 一直绷着的神经断开，控制不住地尖叫道「原本一切都好好的！」—— 也就是说，Bear 实际上很需要一场正常的社交，向他人证明自己和 Nikki 的关系是健康的。

他又向眼前的 Nikki 问道，「你喜欢我吗？你真的喜欢我吗？Nikki 开心吗？Nikki 喜欢我吗？」这便是 Bear 面临的另一个问题：他明知现在喜欢自己的 Nikki，是因为愿望才喜欢上自己的。虽然愿望实现了，但并非自己想要的。自己想要的是，Nikki 发自内心喜欢上自己。

而 Nikki 答道，Yes. I'm your Freaky Nikki. —— 真正的 Nikki 怎么可能说出这种话？——Bear 要 Nikki 回家，让二人彼此有点空间。邪灵俯身的 Nikki 怎能答应？她哭起来，说自己可以变成真正的 Nikki，只要是 Bear 想要的，她都有。这些回答，又恰恰不是 Bear 想要听到的。

接下来的恐怖桥段，像是为了恐怖而恐怖，我并不是特别喜欢。总之 Nikki 拿刀出来，威胁说要么自己自杀，要么二人好好留下来。最终 Bear 选择了留下来，又度过了心惊胆战的一晚……

半夜，Sarah 发来消息，说想要和 Bear 见面，有重要的事情要说 —— 不，不要啊！——Bear 偷偷爬下床，听到 Nikki 又如往常那样，醒来并发现自己不见…… 不，好像不一样。这个 Nikki 竟然一边睡着，一边发出脆弱的声音，苦苦哀求 Bear 杀掉自己。

原来，这是真正的 Nikki，趁着邪灵睡着后，向 Bear 求助。而 Bear 这个顶级窝囊废，所想的竟然是「你不想要和我在一起，不想要到想要去死」。真正的 Nikki 回应道，「我从来没有和你在一起过。」被否认了的 Bear 恼羞成怒，竟无视 Nikki 句句 please，跑了出去见 Sarah。

Bear 和 Sarah 的场景，怎么说呢…… 处处都弥漫着 Sarah 很快便要领便当的气息。不过我还是挺喜欢这一段的，主要是因为 Sarah 指出 Nikki 在利用自己的「痛苦」，道德绑架 Bear，毕竟她并不知道 Bear 喜欢 Nikki。

Bear 竟拿出先前早就被否认的「父亲有癌症」一说，为 Nikki 开脱。在听到 Nikki 在利用自己这一说法后，Bear 明显慌张了。这和先前 Ian 的那场戏正好相反。Bear 摇身一变竟成了受害者。他没能继续回答下去，只是苦笑一声。可是，他刚刚才拒绝了真正的 Nikki 想要解脱的愿望。

Sarah 拿出信封，说这是来自最后一所美术学校的通知书，并表示想要和 Bear 一起打开来看。接着她又说道，自己很担心 Bear，因为 Ian 曾经和 Nikki 断断续续以肉体关系交往了大概两年，Ian 认为 Nikki 和 Bear 交往是为了报复他 —— 我们作为观众，自然已经知道 Sarah 的申请结果会是什么，以及 Nikki 和 Bear 交往是因为愿望。我们也知道接下来会发生什么……

Sarah 说，就算不是这样，也认为 Bear 需要一个更稳定的人，比如自……Nikki 突然拿着板砖砸碎了车窗玻璃，并不停用其殴打 Sarah 的脸部、杀了她。这个场景特别血腥，所以才是 R 级电影的理由吧。

我先前说 Bear 是顶级窝囊废，这个场景也贡献了几个证据：在 Sarah 想要暗示自己对 Bear 有好感时，Bear 接了句话，说「更稳定的人，比如你么？」我们站在上帝视角，已经知道 Bear 从 Ian 还有 Nikki 那儿得知，Sarah 喜欢自己。此时，却要如此暧昧地接话么？明明也可以说别人的吧？

另一个便是，Nikki 杀了 Sarah 后，让 Bear 帮自己处理尸体。然后，他就那么做了…… 嗯…… 帮助 Nikki 搬走了昔日好友 Sarah 的尸体……

Nikki 让自己回家休息后，Bear 一个人坐在车上，看向还未开封的申请通知书。一打开，果然，Sarah 被最后一所艺术学校录取了。Bear 麻木地看着信，内心深刻有什么被撬动。无法再绷住的他，呐喊、哭泣起来。他跑到一开始的商店，辱骂店员售卖许愿玩具这种邪恶的东西，却意外得知一个解决方法：重新许个和原本愿望相矛盾的愿，不就行了？

在尝试了许新的愿望但失败后，Bear 跑去找 Ian 帮忙。Ian 看到满身都是血的 Bear，也绷不住了，骂他问到底发生了什么、Nikki 怎么了、为什么 Sarah 开始给自己发奇怪的信息、叫自己去 Bear 家？—— 这也暗示了 Nikki 已经接管 Sarah 的物品。

Bear 终于向 Ian 坦白，Nikki 喜欢上自己，是因为自己许了愿望。他希望 Ian 可以许个「自己从未许过愿望」的愿望。但是他为了 Ian 许愿，加上一句「这样的话你就可以和 Nikki 在一起了」。这句话反而激怒了 Ian，认为是 Bear 出于忌妒在故意搞他，所以许愿说要钱。在 Bear 的尖叫中，美元们就这么从天上掉了下来……

没办法，Bear 拿着许愿玩具又去找 Nikki—— 不要问为什么不找其他朋友，故事总是要有戏剧性的 —— 结果一回家发现客厅里放着诡异的祭坛、死去的 Sarah 被扒光衣服放在一边、穿着 Sarah 衣服的 Nikki 躲在房间黑暗的角落里。她笨拙地抽着烟，哭道「你为什么就不能爱着我呢！」然后开始攻击自己，说明明自己那么爱着他，却得不到 Bear 的爱。她想要和 Bear 在一起，做不到的话，她宁愿开枪自杀。同时，Ian 跑了过来，却被 Nikki 一枪爆头。不仅如此，她强迫 Bear 大声说他爱着自己。得逞后，又切换回甜美的样子和声线 —— 女演员的实力太强了。

Bear 早就知道如何安抚 Nikki，所以骗她说要一起冲澡，实际上自己躲到了卫生间里，任由外面的 Nikki 疯狂地砸门。他拿起枪，想要自杀，但是怎么做都只是在犹豫。直到 Nikki 妥协说道，如果需要分开一下的话，也可以，他便放下手枪。紧接着，他又想起被自己放在卫生间里，最开始杀死 Sandy 的药物，打算服药自杀。

他吃下一整瓶药，无视门外 Nikki 的说话声，坐在浴缸上等待自己的死亡…… 然后他反悔了，想要吐出来，门外却又响起许愿玩具的声音。Bear 定住了，没能吐出来，世界好像突然变大、变广了起来。他走出了卫生间，一脸幸福又害羞地看向笑着的 Nikki，抱住她，并开始接吻。再然后，倒在了地上，口吐白沫，死掉了。

Nikki 抱着死去的 Bear，哭着，也不想活了，拿起一旁的手枪也打算自杀…… 音乐戛然停止，Nikki 也不再哭泣，反而是以非常疑惑的表情，看向周围。她震撼地看向手中的手枪、浑身都是伤的自己、一旁死掉的 Sarah、门口倒着的 Ian、四周，还有怀中抱着的 Bear 的尸体。此时的悲痛，转变为被悲剧冲击，所无法控制的悲伤。她控制不住自己，发自内心地哭了出来。

电影后

这部电影在我进行搜索后，挖掘出了更多蛛丝马迹，例如因为整部电影都是 Bear 的视角，导致我们观众其实也不清楚除此之外的角色们的想法。这便包括，真正的 Nikki 到底喜不喜欢 Bear？

Nikki 的演员 Inde Navarette 的观点是，Nikki 确实对 Bear 抱有好感。

我重新看了一遍电影，以捕捉细节。Nikki 听到 Bear 的否认后，先是眼睛飘向自己的右下角，说了句 Okay，接着一边梳理自己的头发，一边不满地说 Good. Goodnight 然后转身离开。

Navarette 认为这些细节都是 Nikki 失望的表现。再加上和 Bear 在车上聊创作的那场戏中，可以看出 Nikki 会在意 love 和 romance 的区别，且想要自由。就算是和 Ian，也仅是肉体关系。

然后是 Nikki 在车上说过的一句话：「如果自己喜欢上了谁，谁都看不出来。」这句话最初看，我以为是和接下来 Bear 愿望实现、Nikki 变得特别主动的反差。但假设 Nikki 确实对 Bear 抱有好感，那么这句话便很有意思：我们现在不就正在为了她喜欢谁而在争执么？

更为重要的是，如果假设为真，那么 Bear 这个角色会变得特别…… 像个小丑。如果他能够承认自己喜欢 Nikki，那么大家的死亡根本就不会发生。

我喜欢这部片子么？它挺对我胃口的其实。故事中的各个情节，都将不健康的关系搬上了荧幕。电影的标题 Obsession，表面上来看，来源于被邪灵俯身、会失禁、暴力、杀戮和有着极端占有欲的 Nikki，但更深层中，指的是 Bear 本身。他不痴迷于真实的 Nikki，甚至对她的拒绝感到愤怒，而痴迷于一个绝对安全的客体，这也是为什么他一直没有想过抛弃邪灵 Nikki，顶多是要求「有点空间」。

Bear 结尾的服药自杀，有两种猜测：一是对现实失控的逃避，二是想要帮助 Nikki 解脱。无论是哪一种，他最终其实都没能下定决心、反悔想要吐出来。导致他死亡的，是 Nikki 意外许的愿。绝望的是，这个窝囊废在虚假的甜蜜幻想中死去，获得了逃避的解脱，而真正的受害者 Nikki 却要醒过来、独自面对死去的朋友们，以及无尽的创伤……

Obsession 这部片子，我观看时一直觉得和其他恐怖片有着区别。因此看完后，我第一时间和朋友说「这部片在奇怪的意义上很恐怖」。回家思考后察觉出，它其实没有传统恐怖片里的怪物；我们从最开始便知道恐怖的来源是 Nikki 这个角色，也知道她大概接下来会做什么。也就是说，恐怖不来自于「未知」，而是「人性」。

「它很恐怖」的另一个原因是，不健康的关系、不沟通、自身的怯懦、猜忌…… 这些都是我们人生中或多或少经历过的。我恐惧这些事情，因此也恐惧这部电影。

关于 Stallman 报告

2026-05-10T04:00:00.000Z

上个月我调查了一会儿 Richard Stallman 这个人，也是两个月前提到的自由软件之父。

除了作为自由软件运动的先驱而闻名外，他也因备受争议的言论而知名，尤其是在涉及性行为不端和未成年人性行为方面的言论。

他最为诟病的争议之一，是 2019 年就 Jeffrey Epstein 性交易案发表的评论（见维基百科）。当时他对一名指控者的动机提出了质疑。而这些争议，最终导致他辞去 MIT 和自由软件基金会的职务。

2021 年，Stallman 宣布回归自由软件基金会董事会，这也是本篇文章重点引用的网站的存在目的：阻止他返回，除非他可以公开道歉并撤回所有有问题的主张。

Stallman 报告，即引用的网站，整理了大量 Stallman 本人的问题，包括但不限于「正常化成年人与未成年人之间的性关系」、「为强奸未成年人者辩护」等等。

报告的编辑们认为，自由软件领域普遍存在性别歧视文化，而这和 Stallman 脱不了干系。因为 Stallman 数十年来都尝试正常化性暴力，而在他领导下的自由软件运动也会受影响。

这一点我无法判断是真是假，因为自由软件运动已经是许久之前的事情，那时候我都没有出生。

不过我赞同报告编辑说的，许多人在对 Stallman 的所作所为一无所知的情况下支持着他。至少该让民众知道真相，再去决定支持与否。所以我决定总结与翻译该报告上的内容，以让信息更易懂。如果想要知道更多，请去阅读原文。

那么这些是该报告上的重点：

一、正常化成年人与未成年人之间的性关系。

Stallman 长期推崇未成年人可以同意与成年人发生性关系的立场。就算他在 2019 年发表声明，承认与「儿童」发生性关系存在心理伤害并表示反对，但这一撤回声明并未改变其核心主张。

这是为什么呢？首先，Stallman 有一个自己的词汇表以及反词汇表。他会严格将「儿童」定义为 12 或 13 岁以下的群体，并将 13 到 17 岁的群体规划为「青少年」。基于这种个人用词逻辑，报告编辑们反推认为撤回声明仅仅涵盖了青春期前的儿童，但依旧保留了支持成年人与 13 到 17 岁青少年发生性关系的立场。

在「为什么这种立场是有问题」的方面上，我和报告编辑的观点一致：因为经验与权力的严重不对等，成年人极易对未成年人实施性操纵。

报告编辑进一步提出，有实际数据显示，当伴侣年龄大出 5 岁以及以上时，未成年女性遭遇意外怀孕、感染性传播疾病以及被迫发生性行为的概率会成倍激增。并且，她们会在成年后面临更长期的心理创伤，还有亲密关系障碍。

我身边确实存在着未成年时便和成年人发生过性关系的人。那些回忆并不美好…… 说实话，我儿时也差点遭遇毒手。

Stallman 声称成年人对未成年人的欲望是出于「自然吸引力」，也就是大家耳熟能详的「男人都喜欢 18 岁的」。令人头大的是，他竟认为这是正常的态度，并且将其和性向扭转治疗相提并论，说「难道要洗脑男人对同龄女人产生吸引力吗？」

医学界明确将恋童癖列为心理病理特征，而非正常性取向 —— 我也知道近些年有人尝试将恋童癖弄成正常性取向 —— 但是基于实际的研究，以及我本人对身边「恋童癖」的样本的分析来看，这些对未成年人实施性虐待的，反而并不是所有人都源于 Stallman 所说的「性吸引力」，更多是缺乏与同龄人建立正常关系的社交能力，从而将未成年人作为易于控制的替代品。

在继续下一个条目之前，我想要探讨下言论与传播的自由。我的边界是，恋童癖作为一种精神障碍，理应被严肃对待并且引入专业的心理与医疗干预，而不是在公共领域被包装成正常的性取向来推行。任何试图通过公共平台来正常化侵犯他人的行为，都是不可取，且越过言论自由的底线的。

二、为性行为不端辩护。

Stallman 频繁为涉嫌或已被定罪的性犯罪者辩护，并淡化性不当行为的严重性。

首先他很喜欢公开淡化和否认受害者经历的言论，营造一种助长施暴者有恃无恐的舆论环境。

去年我写过一篇文章，表明了我对性犯罪新闻的态度：

不要掩盖加害者的主观恶
不要认为受害者不完美就活该遭罪
不要持有男权沙文主义思想
不要擅自剥夺受害者的解释权

Stallman 很完美地踩中了我的所有雷区。

先前提到的 Stallman 词汇表，现在又要拉出来说，因为他真的有着非常非常严格的用词习惯 —— 我倒是没有，想必也是为什么我写不出来 /glossary 页面吧 —— 他很喜欢在「性侵犯」一词上抠字眼儿。

例如，他认为灌醉他人以发生性行为，或者施加压力迫使对方和自己发生性行为，只是介于「自愿」与「强奸」之间的中间罪行。

Stallman 强调，将强奸与轻微的不当接触相提并论是不公正的，被指控者有权获得更精确的区分。他的想法源自于新闻报道上将强奸、性骚扰等行为统一称为「性侵犯」一事。但实际上，这种做法是为了保护当事人。

他又声称只要前一晚有过自愿行为，这种「同意」便可以延续到第二天，甚至可以让对方不经过任何同意、未戴安全套的情况下与熟睡的自己发生性行为。这种逻辑剥夺了受害者在特定情景下撤回或设定同意条件的权利、夺走了受害者的解释权。

可耻的是，Stallman 也喜欢为了证明自己的观点，从而歪曲新闻事实、凭空捏造新闻中根本不存在的东西。这些已经不再是基于事实的辩护，而是单纯为了维护自己先入为主的偏见了。

三、无视有关性骚扰的法律规范。

Stallman 相信性骚扰是一系列构成经济不公平、性别偏见的行为模式，而非行为或者犯罪。在他看来，单次发生的恶劣黄色笑话、性挑逗等，只要没有反复发生、形成长期模式，就不能算作性骚扰。并且，他将性骚扰从侵犯人身权利，降级到了普通的职场纠纷。

他不仅在网站上使用具备误导性的定义，还在 MIT 内修完有关性骚扰和性行为不端的课程后，依然继续歪曲性侵犯的概念。他无知么？当然不是，他很明显在抵制现有的法律和道德规范。

身为女性，性骚扰给我造成了许多不便，也是导致我讨厌出门的原因之一。就连近期常去的打工场所，也有令人烦躁的骚扰现象在……

四、支持持有儿童性虐待材料。

Stallman 坚称，仅仅因为持有儿童性虐待材料就判刑，是对人权的威胁，并认为持有此类材料根本不应构成犯罪。

尽管他对技术执法可能侵犯自由的担忧有一定的合理性，但将其作为支持儿童性虐待材料合法化的论据是…… 呃，极端且糟糕的。

报告编辑补充道，儿童性虐待材料的传播会对社会中的四类人群造成实质性上的伤害：受害者、消费者、刑事调查员，以及内容审核员。

令人感到震惊的是，Stallman 曾面对一位自称被儿童性虐待材料吸引的读者的求助时，不仅没有建议其寻求专业的心理或者法律帮助，反而告诉对方「传播儿童色情图片不是错的」，并继续输出其关于「青少年不是儿童」、批评美国社会夸大危险的政治主张。

报告编辑认为，这不仅证明了 Stallman 的言论会对读者产生真实的误导，更是表明他借受众的软弱与困境，将其自身有害的政治主张伪装成建议，直接造成实质性的恶劣影响。

五、人类与动物之间性行为，以及恋尸癖的法律与社会正常化。

这两点在原报告内是分开的，但我想要放在一起说。

和先前一样，Stallman 认为持有人兽交或者恋尸癖色情内容都是人的权利，反对它们就相当于在威胁人权。

接着他认为，只要没有对动物施加物理上的强迫或造成直接的身体伤害，那么此类行为就不应该被禁止。同样，他也认为尸体不会感到痛苦，因此对尸体采取的任何行为都不会造成实质性伤害。

在人兽交上，动物实际上并不具备表达「同意」的能力、无法传达意愿，也无法在遭受侵害后为自己辩护。这一点很像未成年人、醉酒后意识不清醒的人。

Stallman 声称的「无身体伤害」也不是真的：遭受性虐待的动物同样会表现出抑郁、焦虑和攻击性等创伤症状。

而制作人兽交色情材料的过程中也有着对人类演员的剥削，因为他们往往是在胁迫下才进行表演的。主张正常化此类色情内容是在无视并纵容暴力。

至于恋尸癖，他恐怕并不明白死者依然有着作为人的基本尊严。法律和社会规范对遗体的保护，是在维护死者的主体地位、死后自决权，以及身体自主权，而尸体显然也无法表达「同意」。

对于死者的家属而言，失去亲人本就伴随着巨大的悲痛，若还要面对亲人遗体遭到亵渎，甚至被制作成色情图像传播的事实，将遭受难以想象的二次心理创伤。

有趣的是，报告编辑也补充说，奸尸被明确界定为战争罪行，因其本质是向民众施加恐惧以及屈辱。

六、Stallman 本人的不当行为。

以上五点都在说 Stallman 的政治主张，那么有没有他本人干过的事情哩？确实有。他的行为大可以归结为对权力落差的系统性滥用，主要体现在社交剥削、公开性化与职场独裁三个层面。

在社交剥削方面，Stallman 习惯利用自身的行业权威获取不平等的关注与身体接触。

例如上个世纪 80 年初，身为 MIT 研究生的 Stallman，曾以「自杀」为要挟纠缠一名大一新生，并在事后将自己的心理操纵包装成「被拒绝多次后的绝望表达」，将责任推卸给女方的误解。

在公开性化方面，他长期保留名为 Church of Emacs 的公开表演传统，并自称 St. iGNUcius。在这个表演中，他多次强调必须由女性来扮演「Emacs 处女」（没有使用过 Emacs 的人），甚至在 2008 年将一名 13 岁女孩带上舞台进行性暗示。面对争议，他仅仅将其辩解为针对宗教的恶搞笑话，从未对将未成年人或女性置于性化语境中的行为做出任何反思与道歉。

在职场独裁方面，Stallman 长期将带有性别歧视和种族主义色彩的「黑客幽默」视为理所当然，无视同事帮助其建立职业边界的劝阻。他在管理中极度缺乏同理心，凭借个人情绪威胁解雇员工，甚至逼迫员工必须依靠组建工会、引入合同与规则，才能勉强维持正常的办公环境。

Stallman 个人的道德越界之所以能够长达数十年不被清算，根源并不完全在于他本人的固执，而在于其背后的机构将公权力私有化，为他提供了系统性的包庇 —— 这就必须谈到自由软件基金会本身的不当行为。

七、自由软件基金会的不当行为。

2019 年的董事会，以及现任的董事会长期纵容 Stallman 的越界行为，且未能遵循联邦和 Massachusetts 的法律规范、为员工提供免受性骚扰的工作环境。

前执行董事兼董事会成员 Bradley Kuhn 曾长时间试图让 Stallman 认识到，其争议性政治议程有很大的问题，且他的个人极端主张与基金会推进自由软件的根本使命背道而驰。结果不仅没有用，Kuhn 还被驱逐出了董事会。

有趣的是，Kuhn 被驱逐一事，理应已经离开基金会的 Stallman 有亲自参与投票。因此报告编辑认为，自由软件基金会还在 2019 年到 2021 年间维持了个运作极不透明的影子政府：通过文字游戏和信息隐瞒，蓄意误导公众，以此掩盖 Stallman 继续掌控基金会核心决策权的事实。

我阅读完整篇报告，是很惊讶的。先前我仅在维基百科上看到过 Stallman 有争议性的地方，也就是 Epstein 案期间的言论，但没有想象到他实际上发表过这么多可怕的言论。

尽管我认可「极端的观点也享有表达的权利」，可是 Stallman 对特定受害者发表的负面或者质疑，已经对他们产生了干预，并造成精神层面上的伤害。此时问题便不再属于言论自由的讨论范畴。

尤其是作为在计算机科学和自由软件运动中取得无可代替的成就的先驱者，Stallman 本身就有着巨大的声望。这一点很不幸地会让部分追随者盲目信任他所说的一切，他的政治议程也会很不幸地通过追随者的传播，转化成一种压制受害者发声、改变社区文化走向的力量。

再加上自由软件运动本身并非纯粹地去开发代码，更多是捍卫用户数字主权、具有伦理和人权色彩的社会运动。非常讽刺的，它的精神领袖却在现实生活中公然利用权力落差去胁迫他人。面对这样一个被个人意志绑架、甚至包庇施害者的基金会，民众包括我自己在内，要如何继续信任它呢？

好像，还是太动听了些。实话说，整个报告看完，感觉挺恶心的。虽然我知道人有着不同的面孔，或者说在不同的方面上有着截然不同的标准。但是深入了解这位自由软件之父，还是会难以置信。该说是愚昧还是封建呢，总之自私自利肯定是跑不掉了。

我依然喜欢并支持自由软件的理念，可惜 Stallman 这个精神领袖已经彻底让我祛魅。至于基金会，如果做不到干脆的道德切割的话，那么该机构的公信力必将走向破产 —— 现今各大开源核心机构纷纷与其断供与割席就是最好的证明。

自由软件这个理念，其核心本就是去中心化与权利共有，早已超越了某个具体的个人。留着一个道德溃败的独裁者到底有什么用呢？就算继续包庇、维护他，他的所作所为也都被存档下来，等着被未来的其他不知情者挖掘。最好的做法是立即切割，避免 Stallman 的政治议程继续侵蚀基金会。

读《私宴》

2026-05-04T04:00:00.000Z

这是苏童写的一篇短篇小说，人物多，且个个个性分明，颇有意思。

开头，苏童就用「讽刺」的语气，说长途汽车抛锚在了举例终点站五六十米的大牌坊。可笑的是，它不仅抛锚，门还开不开，急死乘客们了。

这期间，有乘客怒道，应该举报负责的运输公司、退钱！有乘客说，这是「马桥镇」，又不是北京广州，你举报、别人把你当傻子喔！又有乘客说，这汽车的产权归属于「大猫黄键」，你敢去举报吗？

一段吵吵嚷嚷的文字，作者就已经透露出，故事发生在贪污腐败的小地方 ——「马桥镇」，并且这个名为「大猫黄健」的人，是这里的地头蛇。

关于这个「马桥镇」是哪个「马桥镇」，我不知道。好奇的我在网络上搜索，发现中国有足足七个「马桥镇」，其中有个还在我老家山东。唉，如果能从文字中寻找到蛛丝马迹就好了。

长途汽车好不容易开了半个车门缝儿，乘客们推搡着下了车。汽车站的喇叭放着欢快的《运动员进行曲》，但是听到音乐的人们可没有一个是开心的。

到这时，小说的主角「包青」才露了面。苏童并没有在小说的开头表明主角是谁，而是用了一通对长途汽车以及乘客的描写，构造出了「急忙和不愉快」的氛围。明明是农历小年的傍晚，也就是差不多除夕前的几天，回家是件好事儿啊，怎么会想要去营造这样的氛围呢？

苏童描述包青时，说的是「典型的马桥镇人嘴里所说的那种知识分子」。什么知识分子？苏童继续解释道，是「对人缺乏热情，与几声信口而来的寒暄相比较，往往选择装作没看见」的那种知识分子 —— 哦~ 原来是那种在乡下容易被讨厌的知识分子。包青和他说的一样，像做贼般下了车，明明看到了小学同学李仁政，却打算偷偷跑开。不过命运没有眷顾他，李仁政发现且主动找来了他。

李仁政这个角色初登场的时候，戴着红色棒球帽正在洗车。他帽子上写着「新马泰八日游」，且苏童特意让包青问了这八日游的事情，但是我还是没搞清楚有什么含义在。

（李仁政）突然提高声音说，大猫要请你喝酒，他关照我好几次了，你一回来就通知他，他要请你喝酒。包青说，谁，大猫？黄健吗？李仁政对准汽车后窗玻璃喷着水，说，就是大猫嘛，大猫你都不记得了？包青愣了好一会儿，最后低声嘀咕道，怎么会不记得他，喝就喝嘛。

中文课讨论时，教授问了我们一个问题：包青真的不记得黄健吗？我们的讨论结果是否定的，根据后文，他怎么会忘了黄键呢？明明自己都把「黄健」这个名儿说出口了。从这一处可以隐约看出，包青并不期待和黄健见面。

有趣的是，包青最后说道，「喝就喝嘛」，像赌气般，也是虚张声势。

对话结束后，苏童大致讲了包青对过年回家的看法：厌恶。他远在北京，回来只是为了看看母亲。可以说，他对马桥镇没有任何牵挂。

接着包青遇到了身上有着「夏天北京大商场里弥漫的香水味道的喇叭花」，程少红。她穿着紫色的皮大衣，还遛了条小卷毛狗。

这段形象上的描写，很不一般：一是北京大商场里喷洒的香水不可能是便宜货；二是紫色皮大衣是种非常惹眼的打扮，很少人会这么穿；三是这小卷毛狗…… 怎么感觉是条迷你贵宾犬啊！

而四很重要，是「喇叭花」的特征。喇叭花通常会被认为是「传话筒」、「大嘴巴」的象征，也有「五颜六色」的意思在。但是教授给出了新的角度：喇叭花随处可见，且必须依附在墙上才能生长。这一说，想必读者们就会明白程少红这个角色的本质了吧？

二人进行了一场对话。对话中透露出，包青这么多年过去，见到程少红依然紧张，恐是喜欢过人家。而程少红也侧面描绘出包青的「知识分子」身份，竟是位上过电视的博士。分别前，程少红和李仁政一样，提到「大猫要请包青喝酒」一事。

次日，包青便开始了名为「走亲戚」的义务。其实我没有怎么走过亲戚，出生在父母北漂的城市里，从小便对「亲戚」这一概念没什么想法。放假回母亲老家时，倒是觉得一个个亲戚明明没怎么见过，却还要想方设法逗我一事很烦。

包青走亲戚期间，舅舅又跟他提了「大猫要请他喝酒」这件事，连带着还有让包青在黄健面前美言几句，说不定自己的儿子就能去羽绒厂或者长途汽车上工作了。这已经是苏童第四次借旁人之口提到黄健，且无一例外，都在说这黄健多有钱和权势。同时，也借一步提高了包青的地位，他可是个能让黄健想要清酒喝的人物。

包青自然觉得这种事儿很烦，我也觉得。他不耐烦地回应说，镇长的饭局他推了，他黄健的饭局我哪儿还有时间去应？明儿还要去见教委刘主任呢。这里可以看出，包青的博士身份足够让他推掉镇长这号人物的饭局，但却没能推掉刘主任的。这是怎么回事呢？重点并非在于「地位够不够推饭局」，而是在于包青是位博士、是知识分子，对教育有着明显更强的主动性。他去见刘主任，是自己想去、才去的。

同一个自然段里，苏童也表现出了包青对教育的看重。离开舅舅家后，他路过了小时候上过的马桥二小，发现学校没了，变成了黄健的羽绒加工厂。他很是愤恨，骂黄健买了小学建工厂，是个可耻的暴发户。

回到家，包青打算打电话推掉黄健的饭局。期间包青的母亲在旁边唠叨，透露道包青曾经为了和黄健做朋友、付出了耻辱的代价。过去黄健就没把包青当人。当一家人决定在家里用餐时，李仁政骑了车过来，露出先前被帽子遮住的地中海，站在雨里说什么也要把包青请去宴席。

李仁政就那样站在雨中，他的表情看上去有几分惶恐，有几分不安，也有几分神秘。

为什么苏童要特意写出这三个特质呢？在讨论中，我们最终得出的结果是：惶恐在于没能完成黄健的任务，神秘在于可能知道接下来会发生什么。

这道德绑架的一招还是让包青的家人屈服了。母亲担心有损包青的声誉，劝包青赴约。没办法，他还是坐上李仁政的摩托车走了。路上，他想起曾经三人一起骑两辆自行车去看演唱会。李仁政的车爆了胎，黄健便逼包青跟李仁政换了车。最终包青一个人推着坏掉的自行车走了三十里地，也就是约十五公里、十英里。我曾经走过二十多公里，花了我一天的时间。如果不是特意来走马拉松，突然叫我走这么远，我会想死的！

到了会场，包青和读者终于是见到前面铺垫许久的大猫黄健。他的额头上有红色的胎记，肥肥胖胖的，像是老虎，也就是「大猫」，具有强烈攻击性的动物。他想要拥抱包青，包青却害怕躲开，又一次暗示二人过去的关系。不得已，他俩只能握手。期间黄健说，就算是省长接见自己，也不见得会像现在这样心跳如此厉害 —— 可是谁能知道他说的是真是假呢？

饭局上除了先前提到的角色们，还有个新角色小钟，是包青的恩师 —— 中学里钟老师的女儿。未曾料到，包青不知道这位恩师于去年已经因癌症而去世。这和先前包青的形象有所冲突：明明是个那么重视教育的人，每年还来马桥镇过年，怎么会不知道恩师去世了呢？如果我没有记错的话，这个问题在课上没有个准确的答案，钟老师可能是包青去年过年后去世的，谁知道呢？

接下来就是看得令人疯狂的喝酒桥段，当然是贬义上的。许多人前来劝包青酒，其中程少红因为劝不动，恼羞成怒，曝出了包青曾经偷她胸罩的事情。包青不怕，揭露出是黄健偷的、放自己口袋里来了。黄健不得不承认是自己干的。不知是喝了酒，还是明白自己的身份地位高，包青刻意倒扣酒杯在桌上，示意自己不想再喝了。

小钟好奇问道，包青明明是好学生，怎么会和黄健和李仁政做朋友的？话外之意，黄健和李仁政是坏学生。黄健听后豁达地自嘲了句，但包青却红了脸。小说里说，包青没有勇气去刨析自己以前为什么这么做，而这么做也是屈辱的。他只能说是小孩子的选择、没什么道理可言。可是程少红点破了一切：「小鸡给黄鼠狼拜年，求它去吃别的小鸡，别吃它自己。」

因为怕被黄健整，所以选择去和黄健他们混在一起，最终好似也没有落得什么好下场。

黄健听后，愤怒地辱骂程少红，并要李仁政给程少红倒三大杯白酒。包青一下感觉很惊讶：程少红完全驯服于黄健，说罚就罚，而李仁政也真的拿了酒出来。场面一度变得十分混乱，包青想走，黄健却不让，还要等在场的所有人都罚了酒才让走。

鸿门宴啊鸿门宴！在场的所有人，不都是特意安排在这儿，逼迫包青喝酒用的嘛！为了稳住场面，包青只能主动提出喝酒，把自己原本拉高的架子又主动拉低了 —— 谁让这一切都是因为自己不喝酒！

接着黄健拿出个老古董，经过包青的鉴定，发现是假货。原本好不容易稳住的氛围，又因为黄健被骗、李仁政可能从中吃了回扣，变得糟糕了起来。包青发觉了这一点，只得站起来又找人敬酒。

喝着喝着，给包青喝吐了。李仁政扶着他去厕所，竟还想让他继续和黄健喝酒，喝到黄健满意为止。包青想起小时候自己曾经被黄健等人扔进河里、李仁政过来拉他的事情。

包青忽然就对李仁政说，仁政，我知道你是个好人。李仁政却不高兴，喷出满口酒气骂道，好人有 x 用，没钱，好人也会变坏人！

出了厕所，包青想要最后和黄健喝一杯，喝完就走。但本就喝太多，喝这最后一杯时，倒坐在黄健脚边。他看到黄健鞋子上有泥巴土，忽然想起了过往：曾经黄健命令他给自己擦皮鞋，现在黄健也命令他给自己擦皮鞋。包青一下没了先前大博士的样子，顺从给黄健擦上鞋，却被黄健打了一耳光、让他把另外一边也擦干净。

次日包青要离开马桥镇，李仁政来车站送他。他问李仁政，昨天为什么不来帮自己、自己是不是给黄健擦了皮鞋，还被打了一耳光？李仁政决口否认。包青话一转，不是我擦的，难道是你擦的、你被打？谁曾想这句话令李仁政激动了起来，他自豪地说，「我从小到大就没替他擦过鞋，更没挨过他耳光！」接着又说，「你们现在都混好啦，那么多同学朋友，只有你能跟他平起平坐，要不是喝醉了，他怎么敢打你的耳光？」

说着说着，一旁的长途客车自动地开了门，故事也到此结束。

这篇小说留下了许多未解之谜。我的记忆似是错乱了，并不记得课堂上我们讨论到什么。

小说的开头与结尾，「长途客车」代表着包青的心结：来时不想来，走时巴不得立即走。是小说常见的「以物喻人」手法。

人物众多，作者也没有明确说明白这些问题：李仁政到底骗没骗黄健？这些重要人物都代表着什么？黄健这次私宴是鸿门宴，还是意外呢？

我和宗教

2026-05-03T04:00:00.000Z

今天我在 Fediverse 上看到有位朋友上传了和宇宙人运动相关的网站，勾起了我和宗教（或者邪教）的记忆。

同时因为自己想要多在外写写博客，利用起自己的碎片化时间，所以想要尽力多发发「日常生活」相关的文章 —— 其实也只是把我发到 Fediverse 上的内容扩展下，弄成订阅博客的朋友们也能看懂的形式。

所以这篇文章也是我用来测试外出时，能不能用安卓手机上的 Termux 使用 Emacs，然后写博客文章并推送到 VPS 上、自动构建跟发布的。

结果 Emacs 跑出来没什么问题，构建 Hexo 成了问题。只能乖乖回家自行构建和推送了。

我和宗教的关系要从我还在中国生活的时候开始说起。我外婆会做法事，在家中也供奉除了祖先外的其他神仙，不过我说不出来他们的名字。每年鬼节都要在家中用大锅烧纸、念不知道是不是经的话 —— 由于是方言，所以我听不明白，但是烧纸很好玩。

接着家里要摆酒席，院子都摆上红彤彤的桌子，长辈们都要杀鸡。我对这段时间没什么记忆，只记得他们会给我气球吹，然后我每次都会弄破气球，也是每个气球的命运吧。

后来我被交给山东的父母朋友带，当了几年的留守儿童。别说，这段时间反而让我更为记忆犹新，说是我在中国最开心的日子也不为过。

父母的朋友是对夫妻，其中妻子是位佛教徒：每天都会念经、供奉佛像、吃素。尽管她吃素，但是完全不抵触他人食肉，甚至会拼命给孩子们喂肉。

他们像对待亲生女儿般对待我，让我十分感激。通过这位阿姨，我认识到了佛教（的一个分支？）：会念经、会买鱼放生、会抄写《心经》、会反对堕胎。

这些见识逐渐建立起了我小时候的认知，比方说要对小动物好，看见蜘蛛不要弄死、引它出去就好了。为什么特地要说「蜘蛛」哩？因为小学时我和同桌发现了一只蜘蛛。她想弄死蜘蛛，我想把蜘蛛放到窗外。争执间我说蜘蛛也是生命，她反驳道蜘蛛也会想要为我们而去死的！

当时微信渐渐普及，阅读公众号也成了我每日会做的事情。阿姨订阅的微信公众号里，除了奇怪的言情小说外，就是和佛教相关。有趣的事情有两个，一是许多公众号使用了 Steve Cutts 的讽刺类动画短片，像 Man 这样的，二是经常写反对堕胎的文章。

那时的我刚刚得知自己并非母亲怀上的第一个孩子，并听信死去的哥哥的故事 —— 母亲堕胎后做过一段时间噩梦，舅舅的摩托车也出问题，直到外婆做法事给死婴做了个小屋子，一切才变正常。所以这一切都是堕胎的错吧！

对于这世上到底有没有灵或者鬼，我是没法答出这种人们争执许久的问题的。但我现在可以说，我不相信它的存在，我也更相信堕胎是人类的权利。

至于 Steve Cutts。嗯…… 他的一些短片画出来蛮猎奇，尤其是对当时还是小孩子的我来说。

在我来到美国之后，我便要和当地更有名的宗教，AKA 基督教打交道了，严格上来讲，是新教的浸礼会，也是福音派的一种。母亲是位基督徒，她喝令我每周日要去教堂、参加主日学。

我起初对这个新见到的宗教没啥特殊的想法。教堂内实在是无聊，没有什么娱乐方式，只能在大人们听道期间，一个人找书读。最常被我翻阅的书籍就是简体中文版的圣经，当时还未开始阅读汉化版的日本漫画，对繁体字实在是懵懵懂懂。

圣经啊，该如何评价这本书呢？我是以「读故事书」的角度去阅读它的，所以我很喜欢其中的各个故事，对诗经、仪式如何举办等内容没有兴趣。当时最喜欢阅读《启示录》，反而因「和耶稣基督无关」而被师母教训。唉……

上初中后，我没怎么阅读圣经，也觉得主日学烦、不再去了。有时会被母亲抓来听讲道，但也兴趣乏乏，转而在台下偷偷阅读他们订阅的周刊。周刊里多是读者的投稿，赞扬信耶稣基督后、自己的人生变化。我读时无法产生任何共鸣，倒是越发觉得教堂里的人很烦、老有事没事管我作甚！

妹妹出生后，她也随着母亲信了教、受了洗。她对比我，要更相信耶稣基督的存在，在幸运狗一次走丢后，还会跪在地上祈祷、求耶稣基督救救幸运狗。小孩子是单纯的，我总是这么相信着，所以对于各类面向孩童的圣经班，我抱有复杂的感情。

我又必须要说一次「堕胎」的事情。我不清楚在中国它是个怎么样的事儿，但在美国，它是个争议纷纷的事情：你倾向于「不能杀生」，还是倾向于「人们有对自己身体的所有权」？

这个问题过于简单化了，但确实是美国人们在「堕胎」一事上吵半天的事情。逻辑是，肚子内的胎儿也是生命、是上帝的造物，堕胎相当于杀人、杀害上帝的造物。中国人难以理解这样的逻辑吧，因为在中国法律中，胎儿没从子宫中生产出来便不算人。

我的想法自然是偏向于「人们应有对自己的所有权，以及执行权」。不仅如此，也要考虑到被强奸者的情况，尤其是幼小的被强奸者。例如 2022 年，「不能堕胎」在美国各州开始蔓延时，就有过 13 岁女孩被强奸至怀孕，无法在当地堕胎，也没有钱去其他州堕胎，最终不得不生下孩子的新闻。

在一期周刊中，有位不记得姓名的牧师写了篇文章，主张「不能让人有堕胎权」，理由和我上述的一致，但在「被强奸者能不能堕胎」上，他轻描淡写说：「比例很少，更多是人们放纵而导致怀上必须要被打掉的胎儿。」

比例少，所以便可以不在乎他们了么？

疫情后，我便再也没有去过教堂，就算被硬拉着去，我也只是找地方躲起来。和父母发生过一次事件后，他们也不敢再来招惹我，放着我想干嘛去干嘛去。

那个教堂中同时会讲流利的普通话以及英语的人不算多，我是其中之一。教堂新上任的牧师只会讲英语和粤语，急需一个翻译官。我就被拉上去干这个活哩。小学时如何声情并茂朗读课文的小技能，竟在这个时候派上了点用场 —— 当然是对本人来说不好的用场啦！因为我不想要浪费时间去和牧师对稿件、上台跟着他讲个一小时。

有次我周日有事，明确表示了自己不能上台。这牧师的母亲，也就是先前教训我的师母（前），竟一起向我发送短信施压，一点边界感都没有！我对这个教堂的厌恶，也很大程度上是因为她。

那么我很讨厌宗教么？我确实很讨厌宗教，不过也认可它对于人们的作用。我挺喜欢小教堂中的社区感，人们互帮互助，有时虽也有让我看着不愉快的地方在，但整体上来讲我喜欢这个想法。

在美国这些年也不仅仅是碰上了新教这一个宗教。犹太教么，以前居住的区旁边正是犹太人区，我初中也在犹太人区内。我很讨厌犹太人，因为他们总会给我种「不欢迎你！」的感觉。一次放学，一个犹太小女孩盯着结伴而行的我和小伙伴们，竟毫无掩盖地露出了鄙夷的表情。

在华人区居住时，我常常撞上法轮功的人。年少无知，没上过政治课，都不知道「共产党」是个啥。第一次认识到「共产党」，还是在法轮功派发的小册子上看到。册子上的内容听后会让人觉得忍俊不禁：老天爷有眼，召唤闪电劈中了块石头，石头上竟赫然写着几个汉字 —— 中国共产党必亡！

就算是还是小孩子的我，也知道这种事情写出来有多扯淡。对法轮功的第一印象也是差上加差。再之后总是能遇到法轮功的人传教，跟着我跑，太可怕了。

每年和法轮功相关联的神韵团都有演出，不过我从未看过。一是票挺贵的，二是身边的人都认为它是邪教 —— 我无法定义它是否是邪教，因为它还挺复杂的。我不能直接去相信墙内对它的指控，而在墙外对法轮功的说法争议不断。最终像是大家都放弃了般，没有个非常权威的源去说它是否是邪教、政治产物，墙内的人们都认为它是邪教，法轮功自己到处游行哭诉江泽民对自己的所作所为，尽管他已经去世好多年了。

和基督教相关的邪教我也遇上过，其中一个大名鼎鼎 —— 东方闪电。其实这类宗教因为过于符合「邪教」的定义，都不需要犹豫和挣扎：声称世界末日快降临了，并认为所有自然灾害都是世界末日的前兆。

其中有教徒缠上过我母亲，每天嘘寒问暖、买吃的给她。母亲虽然有免费的饭可吃，但家里又不是穷到给点饭便感激涕零，很快就赶她走掉了。

我对基于基督教的邪教是这么定位的：主张教徒们不要去教堂的很大可能就是邪教。母亲一位朋友貌似就深陷其中，不愿意去教堂，也不知道他们现在如何。

最后讲宗教，就讲讲最近碰上的来自日本的创价学会吧。准确来说，这是室友碰上的，她的一位新朋友是其会员。起初，室友觉得它比基督教「好」，里面的人们不会神神叨叨。我当时提醒她，随着她越来越了解个宗教，她只会愈发厌恶它。

果不其然，在参加了创价学会的一场活动后，她便回来说那里的人怎么也神神叨叨的，整天念经、哭诉自己生活多么惨，入了学会后如何吃得好、睡得香。

我从未想过，大名鼎鼎的互联网精神污染视频「武器 A」里的人脸，就是创价学会的人。想要了解更多，我会推荐阅读这个亚文化 Wiki 页面。无他，就是觉得好笑。

想法在丙午麦序迭代

2026-05-01T04:00:00.000Z

好吧，看上去我把上个月的一些条目错误地放在了另一个 Org Mode 文件内，并把它们忘在了那儿…… 所以本次月刊会有一些上个月就该有的内容。

本期导读

入坟编写 SVG

2026-04-22T04:00:00.000Z

我先前的个人主页，是用简单的 SVG 代码一个个画出来的。因为是简单的图形，所以画一个出来没什么问题，但要是画很多的话…… 最终我决定，这种做法太累人了，乖乖手绘吧。

不过点进来之前，我需要事先说明下：这不是一篇教学文章！

现在你可以访问我的个人主页看到首页的风格变了。目前绘制完毕且托管的只有首页和电话（我很喜欢电话的设计），我花了很多时间来将图片转换成 SVG 代码 —— 是的，这不是一张图片，而是 SVG 代码。

通常不靠手搓（也没人会这么做吧！）画出复杂矢量图形的方式有可视化矢量图形编辑器，比方说 Adobe Illustrator，也是我高中学习使用的。可惜现在毕业、根本没有免费的 Adobe Illustrator 供我使用，我也早就忘了如何使用这类软件，所以可视化矢量图形编辑器只能被我残忍 pass 掉。

至于矢量图形、SVG 代码是什么 —— 如果你抱有这样的问题的话，那说明你还没有读过这篇文章的前文吧！快去看看吧~

我的方案是直接在 Procreate 这类绘画软件上画完整张图，然后用 Potrace 将位图图形转换成矢量图形 —— 我太聪明了！快来实现吧！

原理一句话能说完，但凡事都是说起来简单做起来难啊。我和 agent 进行了很多研究和探索，因为我对图形文件的理解还是不到位的，总之最后还是成功地将画转换成了可互动的 SVG 代码。下面我会简单说说我的方案。

工具选型

在深入流水线之前，先介绍三个主角。整条管线是三个工具协作完成的，它们各自的定位值得先说清楚。

一、ImageMagick。

ImageMagick 是一套命令行图像处理套件，也是 Unix 世界最全能的光栅图处理工具。它的核心机制是 magick，支持几乎所有你能想到的位图操作：格式转换、裁剪、旋转、颜色量化、阈值化、合成模式、滤镜、通道操作、巴啦巴啦…… 而且都能在一条命令里用管道式参数链接起来，不需要读文件、写中间产物再读回去。

这个流水线里几乎所有「位图到位图」的操作都交给 ImageMagick 来做。替代品可以是 Python 的 PIL / Pillow，或者 OpenCV，但是一条 magick 命令能干的活，真的要选择去写十几行代码吗？

二、Potrace。

Potrace 是位图矢量化工具，也是 FOSS 世界里事实上的标准。Inkscape 的 Trace Bitmap 功能底层用的就是它，很多商业软件也把它当作矢量化引擎。

它的定位很清晰：接受一张二值位图（只有黑白两色，连灰色都没有），输出一个 SVG、EPS，或者 PDF 文件，里面则是用贝塞尔曲线描述的路径。

算法管线分为三步：先找出所有黑白边界的像素链，再把像素台阶拟合为多边形，最后把多边形顶点转成三次贝塞尔曲线。

三、Python。

脚本最终我决定使用 Python 来写。用其他语言写也完全没问题啦，只是我对 Python 更熟悉一些（JavaScript 是什么东西，不熟）。

作画与导出

为了防止有读者听不明白，我决定讲讲电子作画时的基础概念和知识 —— 不过真的会有不懂的人来看这篇文章么？总之先讲图层吧！图层是一张张透明的画布叠在一起，每层画不同的东西，最终看到的画面是从上往下看穿所有图层后的视觉合成。每一层都可以单独修改、隐藏、换顺序而不影响其他层 —— 这自然给作画带来了巨大的灵活性。更关键的是，图层是有顺序的：上面的层会盖住下面的层。

我的方案严重依赖图层这个概念。每个物品都有自己的图层，例如大门是一个图层，城墙是在这之下的另一个图层。这一步是有讲究的：整条管线的每一次追踪都是「单图层对单掩膜」，如果你把所有元素合成到一张图再导出，后面就没办法单独给城堡添加悬停效果，或者让某一棵树动起来。

接着需要将图层以 PNG n 的格式一一导出，千万不要把背景图层导出来。我把它们全部丢进一个 transparent/ 目录，命名成 layer-01.png…… 数字就是图层的叠放顺序，01 在最底层，例如背景的天空，数字大的则在上层。

这里还得解释一个概念：PNG 的透明度是怎么存的？每张 PNG 实际是四通道数据：R（红）、G（绿）、B（蓝）、A（alpha，即不透明度）。RGB 三个通道大家想必耳熟能详了，是对颜色的描述，而 alpha 描述的是这个像素有多透明：0 是完全透明，255 是完全不透明，中间值自然便是半透明了。

用电子软件作画时，我们时常会看到笔刷的边缘有着羽化。它就是 alpha 从 255 平滑衰减到 0 所形成的软边，看起来让我们的笔刷柔和上去不少。

单层处理流水线

每张 PNG 都要过一遍以下流程才能变成一组元素：

检查是否是空图层。
我用 ImageMagick 把每个图层的 alpha 通道单独提取成灰度图，然后计算平均的亮度：magick layer.png -alpha extract -format "%[fx:mean]" info:-。
%[fx:mean] 是 ImageMagick 内置的像素表达式引擎，info:- 让结果走 stdout。
返回值是 0.0 到 1.0 之间的浮点数。用我实际的数据来说：天空层约 0.48，即占画面一半都是不透明的像素；白色小鸟的那层约 0.003，小小的；空白的图层为精确的 0.0。如果 alpha 平均值小于 0.0001，即几乎全透明，那这个图层就是空图层，要被跳过。
硬阈值化 alpha 值：magick layer.png -alpha extract -threshold 50% alpha.bmp。
阈值化是把连续灰度映射成二值的操作。你会选择一条分界线，高于它的像素变白、低于它的变黑。阈值化的产物叫作二值图，是图像处理里最简洁的形式，也是很多算法的强制输入要求，包括我们马上要用的 Potrace。
回到命令，我用 -threshold 参数把所有大于等于 50% 亮度的像素变成纯白，其余变成纯黑。然后输出成 BMP3 格式，也是 Potrace 唯一无损保证能读的格式。
这么做的原因在于 Procreate 的笔刷有抗锯齿羽化边，边缘像素的 alpha 值从 255 平滑衰减到 0，可能中间横跨了 5 到 10 个像素的宽度。这些半透明的像素在后续合成中不能说没有用，只能说用处太大了，把我合成出来的东西全都搞砸了！
具体会怎么「搞砸」呢？后面要给每个颜色造掩膜时，会用到 alpha 去裁剪真实的形状。如果 alpha 是羽化带，乘起来得到灰度 76 的中间值，Potrace 看到灰度就会把它当成实心区域来追踪。结果是每一个色块外围都会被绕出一圈轮廓，不仅翻倍了文件体积，还在视觉上糊成一坨坨。
所以需要提前将它们合并。50% 是我认为较为舒服的值，实际上你可以随意调整。阈值化会让边缘变有锯齿状，但后续 Potrace 的贝塞尔平滑会把台阶拟合回曲线，反而比羽化边更干净！
量化颜色，即把连续色阶压缩成 N 色：magick layer.png [-blur 0xR] -colors N +dither quantized.png。
量化的意思是把一个连续范围压缩成若干个离散的层级。在颜色量化里，我们把原图里成千上万种颜色减到 N 种，每个像素替换成 N 色里距离最近的那个。这是有损操作，但对我们的矢量化来说恰恰是必要的。因为只要把颜色阶梯化，我们才能划分出明确的色块边界。假设原图是一片渐变的云，量化会把它切成几个色阶带，每个色阶带才能被 Potrace 追成一条边界清晰的 path。
我用 ImageMagick 的 median-cut 量化器，按照 RGB 颜色空间里最长的轴切分像素的分布，直到得到 N 个聚类。
我建议是每个图层都手动调整下 N 的值，因为自动估算对艺术风格并不敏感，需要人类的介入、指出一个图层里到底该有多少种颜色。我的部分配置表：
```
LAYER_COLORS = {    1: 1, # 纯色的天空    2: 4, # 月亮 + 星星    3: 15, # 带有窗户的塔顶    8: 6, # 树    12: 10, # 上半墙    20: 15, # 城门}
```
纯色图层给 1 就足够了。复杂图层能给到 15，让它能同时容纳石头灰阶和橙色光斑。
另外，误差扩散抖动得关掉（+dither 里的 + 是 ImageMagick 约定的「关闭」前缀，对标 -dither。怎么感觉应该反过来哩？），否则两种邻近颜色的像素散点会多出第三种颜色。在位图显示上，它是好看的，但对矢量化是毁灭性的 —— 每个散点都会变成一种独立的，SVG 体积又更上一层楼，视觉上还花花的。
可选的 -blur 0xR 是对笔刷纹理特别重的层先做高斯模糊，把颗粒糊掉再量化。我只对城门那层用了它。
列出实际用到的颜色并去重：magick quantized.png -alpha off -unique-colors txt:-。
量化时限制了图层中最多出现 N 种颜色，但如果原图的色阶数小于 N，那实际用到的会更少。我们要的是真正出现了的颜色，必须挨家挨户造掩膜追踪。
-unique-colors 会生成一张 1×N 的像素图，每个像素是一种颜色。txt:- 把它以 IM 的文本格式 dump 到 stdout，长这样：
```
0,0: (28,29,48)  #1C1D30 srgb(28,29,48)                                  1,0: (18,18,36)  #121224 srgb(18,18,36)   2,0: (132,70,11) #84460B srgb(132,70,11)                      ...                                       
```
用正则 #([0-9A-Fa-f]{6}) 把十六进制色值抠出来。
接着还需要合并一次，因为笔刷纹理可能产出视觉上一样但数值差 1 到 3 个颜色对（比如 #47475B 和 #47475C），会在后续的转换中产出很多几乎同色的颜色，白白浪费浏览器的渲染资源。
合并策略很简单：如果两个颜色的 R、G、B 每个通道差值都小于某个阈值（我给城门设的是 15），判定为重复，只保留第一个。
为每种颜色构造二值掩膜。一共是两条命令链。
掩膜是图像处理里的万用工具！简单来说，它是一张告诉后续操作哪些像素该保留、哪些该忽略的黑白图。典型的约定是白色等于保留，黑色等于忽略，不过有的工具会反过来，所以用任何工具之前都要先看文档。你可以把掩膜想象成是剪纸。把这张剪纸叠在原图上，黑的地方剪掉、白的地方留着。上色的时候很有用喔！
首先是要生成目标色和其余色的掩膜：magick quantized.png -alpha off -fuzz 3% -fill white -opaque "#COLOR" -fill black +opaque white BMP3:raw.bmp。
拆解下来是：-fuzz 3% 给 -opaque 设一个 3% 的颜色匹配容差（因为量化 + BMP 往返可能让颜色偏差 1-2 单位，精确匹配会漏掉边缘像素），-fill white -opaque "#COLOR" 把所有接近目标色的像素刷成白色，-fill black +opaque white 再把所有「不是白色」（+opaque 是 -opaque 的反操作）的像素刷成黑色。
先前的 -threshold 仅是按照亮度切分，无法精确匹配 RGB 值，使用 -opaque 可以正确的按照颜色切分。
接着是要用 alpha 把掩膜裁回真实形状：magick raw.bmp alpha.bmp -compose Mulitply -composite -negate BMP3:final.bmp。
这里涉及到合成模式的概念。合成模式决定了两张图怎么叠在一起。最常见的是 Normal，就是上层完全覆盖下层啦。还有：
- Multiply：两张图对应像素值相乘再除以最大值；
- Lighten：对应像素取较亮值；
- Screen、Overlay、Difference…… 因为本篇不会用到，所以就不过多讲解啦。
上一个命令链的问题在于，原本透明但颜色恰好匹配背景默认值的像素也可能变成白色，所以要用 alpha 掩膜做交集、把「透明但被误标白色」的区域切掉。Multiply 在二值图上等价于布尔 AND：255 乘以 255 等于 255（白），255 乘以 0 等于 0（黑），0 乘以任何等于 0。
不过我们这里是把白色弄成了目标色，和 Potrace 把白色当成要被忽略的背景色的约定不同，需要用 -negate 反转一下。最终 final.bmp 里目标色区域是黑的，其余是白的 —— 这才是 Potrace 想要的输入。
Potrace 追踪：potrace final.bmp -s --flat -t TURDSIZE -o path-COLOR.svg。
终于到我们的 Potrace 出场了。
三个参数：-s 输出 SVG（否则默认是 EPS），--flat 输出扁平的而不是嵌套结构，-t 10（turdsize）丢弃包围像素数小于 10 的孤立斑点。turdsize 可以用来降噪。
输出长这样：
```
           
```
那个诡异的 translate(0,1493) scale(0.1,-0.1) 变换乍一看像 bug，其实是 Potrace 的签名：它内部用 10 倍定点整数坐标做贝塞尔计算（提升精度、避免浮点误差累积），所以 path 里的数值都是 ×10 的；同时它使用数学坐标系 Y 轴朝上，而 SVG Y 轴朝下。所以 scale(0.1, -0.1) 会做两件事：一、除以 10 还原坐标、Y 方向翻转；二、translate(0, 1493) 把翻转后跑到负象限的图形平移回可见区域（1493 是图像高度）。
抽取，塞入正确的 fill 颜色。
我们已经得到了轮廓，接下来只需要把第 4 步的真实颜色放到里就好了！Potrace 默认输出 fill="#000000"，得替换掉。
建议使用正则来做：]*>(.*?)。抓到 transform 的值和内部内容，重新拼装成 ...。

对比度方案

有一些复杂的图层，例如在暗色的背景上有着更暗的细节，像砖块和城墙的颜色。如果按照全图颜色分布切分的话，砖块会消失的。解决方案是完全绕开全局量化，改用两次独立的阈值化跟 Potrace。我下面简称该方案为对比度方案。

详细对比的话，对比度方案的流程需要通过局部亮度的阈值来决定哪些像素是同一块。如果图层里有细节只占 10 灰阶跨度，而全图跨度有 250 灰阶，那么细节在原先的量化器看来是噪音、可以被合并进主体色。而局部亮度的方案中，小差异就可以被放大成可切分的对比。

至于为什么是两次阈值化，因为一次需要追整块形状，一次追纹理细节即可。对比度方案的本质是让图层变成只有两个亮度群的画面，即「主体」和「细节」。再多分几次没有意义，反而可能将笔刷的噪点切出来。砖墙就是「墙」和「砖」两个元素，不需要再增加。

不过该方案需要手动填写图层需要什么颜色，因为它终究只是产出黑白两色的二值掩膜。这一步可以用 ImageMagick 从原图采样平均色，可能产生误差，所以建议是用吸色器直接吸、手动填写。我的配置表长这样：

# (基础色, 细节色, 阈值%, 是否反转)             CONTRAST_LAYERS = {   9:  ("47475C", "030205", 50, False),  # 鸟：身体 + 黑眼                       12: ("1C1D30", "121224", 30, False),  # 上半墙：底 + 砖缝                    17: ("24273D", "0F1021", 60, False),  # 左箭头：底 + 暗点   19: ("18182E", "0F1023", 80, False),  # 下半墙：底 + 砖缝                          22: ("0D0F1E", "1E2035", 40, True),   # 电话亭：暗体 + 亮屏}

整条对比度流程的关键命令是： magick layer.png -alpha off -colorspace Gray -auto-level -threshold T% BMP3:thresh.bmp

四个操作逐一解释：

-alpha off 忽略透明通道，否则透明像素会干扰后面 -auto-level 找最小最大值；
-colorspace Gray 用 ITU - R BT.709 加权公式把 RGB 转成单通道灰度：=Y = 0.2126・R + 0.7152・G + 0.0722・B=。之所以加权是因为人眼对绿色最敏感，对蓝色最不敏感。对比度方案关心的是明暗差异不是色相差异，转灰度把我们关心的维度独立出来；
-auto-level 是整个方案的「魔法」。它找到当前图像的最小灰度 vmin 和最大灰度 vmax，对每个像素执行 =new = (old - vmin) / (vmax - vmin) × 255=，即把现有灰度范围线性拉伸到 [0, 255]。举个例子：上半墙层原始灰度分布是 [5, 55]，跨度 50。auto-level 之后变成 [0, 255]，跨度 255。墙和砖块原本相差 10 灰阶，拉伸后相差 51 灰阶，已经足够用阈值干净切开；
-threshold T% 把灰度 ≥ T 的变白，< T 的变黑。T 的选值要根据该层 auto-level 后的灰度分布手调。我的上半墙选 30%（刚好只切出最暗的砖块），下半墙选 80%（这层纹理更模糊，要把阈值线放更高才能吃到所有砖块），电话亭选 40%。

阈值化后如果该层是 invert True=，还要追加一个 -negate。电话亭是特殊情况 —— 它的细节（屏幕、按键、听筒）比底色更亮而不是更暗。默认的「暗变黑」规则只会把底色抠出来，但底色已经追过一次了；-negate 反转灰度后，原本亮的像素变暗、被阈值判为黑（前景），Potrace 追的就是细节而不是底色。

接着要用 alpha 把透明区强制变成白色，防止透明区被误认为前景： magick thresh.bmp ( alpha.bmp -negate ) -compose Lighten -composite BMP3:detail_mask.bmp

这里用 Lighten compose 而不是 Multiply。Lighten 的语义是对每个像素取两张图的较亮值。两个输入：thresh.bmp（细节二值化结果，前景是黑）和 alpha.bmp 取反（原不透明区 = 黑，原透明区 = 白）。四种情形：

原 alpha	threshold 结果	alpha 取反	Lighten 结果	含义
不透明	黑（细节）	黑	黑	细节保留
不透明	白（非细节）	黑	白	正确忽略
透明	黑（误判）	白	白	透明区救回来
透明	白	白	白	正确忽略

第三行是关键 —— 不管阈值怎么错判，只要原来是透明，白色就压过去了。换成 Multiply 效果会完全相反 —— 不透明区会全部被乘成黑，灾难。原本方案的 Multiply 和对比度方案的 Lighten 在数学上是 de Morgan 律的对偶，不是随便选的，取决于中间数据里「黑白哪个代表有效」。

剩下的步骤和原本方案一样：Potrace 追踪、抽取、塞上配置里写的十六进制色。

对比度方案每层会产出最多两个 —— 一个基础形状（从 alpha 掩膜追来）、一个细节形状。比原本方案 N 个要少得多，这也符合「这一层概念上就两个元素」的直觉。

混合方案

而更为复杂的图层中，例如上半城堡墙既有暗底和砖块，又有高饱和的橘色窗户，只是量化的话砖块会消失，走上一段提到的对比度追踪又会弄丢窗户，因为窗户灰度落在阈值之上，会被判成背景。

解法是两条路都跑，然后把产物叠起来。我把这两个麻烦的图层（上半墙、下半墙）标记成 HYBRID：

HYBRID_LAYERS = {12, 19}if layer_num in HYBRID_LAYERS:    groups = process_layer(layer, ...)  # 正常量化    groups.extend(        process_layer_contrast(layer, ..., detail_only=True)  # 对比度    )

detail_only True= 是关键。正常的对比度方案会先从 alpha 追一次基础形状；但在混合方案里，正常量化那边已经把底色当作最大占比色给追过了，如果对比度再追一次，两个完全重叠的同色会造成 over-draw 和抗锯齿边缘错位闪烁。detail_only 让对比度方案跳过基础形状追踪，只贡献细节层。

最后列表的顺序是：

量化产物的底色（整层轮廓）
量化产物的橙窗、亮边等（点缀色块）
对比度产物的砖块（纹理）

SVG 渲染是画家算法，后写的盖在前面。叠出来的视觉效果是：深紫蓝的墙打底，上面点缀橙色窗户，最上面叠一层更深的砖块纹理，正好是原画的层次。如果把对比度放在量化之前 extend，砖块会被底色完全盖掉。

最后组装

每层处理完都会返回一个列表。主循环把所有图层的产物按图层编号顺序拼接成一个大列表，然后套一个外壳：

svg = f''''''

viewBox 从任意一次 Potrace 输出里抓出来（所有层尺寸相同，共用一个）。width 和 height 是默认显示尺寸，CSS 可以覆盖。

图层编号顺序就是叠放顺序：layer-01（天空）产出的在列表最前，画在最底；layer-22（电话亭）产出的在最后，画在最顶部。

最终 SVG 我直接内联粘贴进 index.html，而不是用。外部 SVG 没法被外部 CSS 样式化（比如给某层加悬停颜色），也没法被 JavaScript 操作里面的 —— 内联之后就随便了。是不是很有意思呢？

之后

个人主页的重构会花费一些时间，因为现在我可以手绘、用更简单和省力的方式在网页里添加元素，例如首页中的城堡我参考了《喜羊羊与灰太狼》中「狼堡」的设计（好啦根本一模一样）。我后续决定添加更多有趣的内容进去，比方说下一个我打算重绘的 /death 页面，就会出现一些游戏元素，像《植物大战僵尸》啦。

再就是个人主页在不同设备上的显示。我希望所有设备都能访问个人主页，展示的不同没有关系。我发现部分博友会在浏览时关闭 JavaScript，而我主页上有些页面使用了 JavaScript。我会尽我所能将 JavaScript 从主页上剔除，除非是必须使用 JavaScript 的功能，那我会想办法将内容以别的形式展示出来。SVG 以及更新的 CSS 语法同理 —— 总之不要出现那种「不开启 xx 功能或者没有 xx 就不能看」的问题吧！

虽然话是这么说，但其实也想过在主页上添加解密要素。不使用 JavaScript 的话，应该会滥用 LocalStorage 吧……？到时候再说，到时候再说。

观《八号出口》

2026-04-22T04:00:00.000Z

四月份有我明面上的生日。至于为什么是「明面」上的，那就去问当年给我办户口的人吧！总之，影院送了我生日礼物 —— 一桶爆米花和一杯饮料，直到月底都可以随时领取。因此我一直想要在四月份和别人一起去看部电影，把礼物领了。

原先考虑到的分别是 35 周年重播的《沉默的羔羊》，但不吃任何折扣，两个人总计 40 美元，太贵了；《迈克尔・杰克逊》感觉不错，但室友好像兴趣不大；其余我想看的儿童向电影室友都不想看，唉。最终在一次意外搜索中发现，AMC 上映了《八号出口》。

继续之前，我还是要说一遍，不想要被剧透的请不要阅读这篇文章。

电影前

我对原作游戏有一定的了解，是「找异常」游戏的鼻祖，也导致了独立恐怖游戏里一时出现了大量类似玩法的游戏。原作作者也做过同类型的续作《八号站台》。

看电影之前，我记错了时间。原本 10 点的电影，我记成了 10 点半。因为电影播放前还会有 20 分钟到半小时的广告时间，我们出发的时间更晚一些，路上还吵了一架。实际上看到电影的时候，应该是电影播放了 20 分钟之后。事后我们快速查看了网上别人做的解说，发现错过的这 20 分钟里有许多恐怖、惊悚的桥段…… 实在是不应该错过啊。

电影中

电影的音效很厉害，在营造压抑的感觉上做得很好。中间有一段是男主角接到了「女友」的来电，向她哭诉自己对电车上的带娃女人无动于衷的样子，根本不是个未来爸爸该有的样子。他向前哭着走去，转弯后发现打来电话的「女友」也是异常的一部分。绝望、恐慌，什么负面情绪都涌现了出来：他先是愤怒地摔了包，接着哆哆嗦嗦爬向墙、吐了出来，然后呼吸困难地倒在地上。这里电影配上了警笛般的背景声，很不错。

另一个我很喜欢的设计是男主角的视角是如何转变到「行走的男人」的视角的。对于了解游戏的我来说也很震惊，电影竟然描述了这个 NPC 大叔的故事。说到大叔，不得不提他的演技很厉害，将一个已经陷入绝望、但无法主动在男孩面前表现出来的长辈样子表演得淋漓尽致 —— 从头再来的时候，他先是胡乱将身边能破坏的东西破坏了一遍，尖叫着「我要去见我的儿子啊」，然后察觉到现场还有小孩子在，于是蹲下腰、僵硬地露出微笑，向他道歉道，「对不起，吓到你了吧」。我很喜欢这一幕的表现力。

作为游戏改电影，我本对它没有过多的期待，因为我上一部看的游戏改电影是《世界计划：无法歌唱的初音未来》，完完全全粉丝向的电影……《八号出口》没有将原作游戏的内容放在最重要的位置，反倒更像是借游戏的规则，讲了另一个故事。这种做法是有争议性的，我看到部分打差评的影评就是认为这「另一个故事」他们不感冒，是基于原作作品的「强行上价值」。

制作方实际想要讲的，是评判日本社会常见的「异常」。例如明明看到带着孩子的妈妈在被上班族骂，却没有一个人施以援手，全都盯着手机在看。这种异常，却没有人发现，就像是游戏里的玩家，不停在往前走，每每都卡在第 0 层、无法找到真正的出口。

逃出 8 号出口的男主角先是给女友打了通电话过去，说他会立马赶过去，并在车厢上遇到了最初他遇到的情况 —— 一个上班族在痛骂一个妈妈带婴儿来坐车，而婴儿的哭啼声吵得他不爽。实际上，婴儿不会因为叫他闭嘴、就会住口不哭的。上班族不知道这件事吗？我不见得，只是在借「婴儿很吵」这件事、宣泄自己的怒气罢了。另一个我很好奇的事情，就是日本的车厢是真的不能有一点声音的吗？但这是题外话了。

开头男主选择了戴上降噪耳机、和所有人一样无视了这场单方面的言语施暴。而结尾，男主盯着前方，最终朝着上班族的方向转过去身 —— 影片结束。

说到男主角的改变，必须要谈谈这个无尽的走廊对男主角而言到底指的是什么。除了对被侮辱的妈妈视而不见外，他开头还从女友那儿得知女友怀上了自己的孩子，但不敢去承担当父亲的责任。这些都是男主角的心结，他迷茫、不知道该怎么办。

卡在循环中无法离开时，他与一个男孩相遇 —— 在电影中的许多场景里都揭示了，他是男主角的儿子。在遇到洪水异常时，男主角将他高高托起、任由自己被水流冲走。此时男主角完成了在同理心上的成长、愿意去承担父亲的责任。

所以整个游戏对男主角来说，都是心理上的历练。他最终走出了循环，也解开了自己的心结，不仅决定去找生下孩子的女友，还在车厢上帮助了被侮辱的妈妈。

电影后

看完电影后，我和室友持有相反的意见。在我觉得还挺不错的情况下，她认为这部电影根本不好看，还是她讨厌的恐怖片 —— 这是我的错吧，我没有好好说明白「找异常」类型的游戏都是恐怖游戏。

但我也得说明白，《八号出口》更像是一部小小的佳作，而不是「神作」。我很难说我会不会去推荐别人观看这部电影，总之我自己看着喜欢就好了吧！

我接下来想要看的电影还有《玩具总动员 5》，以及想要和另一位朋友看的恐怖电影 Obsession、和恐怖电影有关的喜剧电影《惊声尖笑 6》。至于《沉默的羔羊》，我打算把父母家里不用的投影仪带过来，用线上资源观看。

观《河狸变身计划》

2026-04-22T04:00:00.000Z

实际上，我今天没有看《河狸变身计划》。今天我看的是《八号出口》，前者我是在四月一号看的，但最近才想着去写个影评出来。

先前两次影评我都说过了，不想要被剧透的人就不要看，这次也一样。不过这次想要多说一句：我的影评文章更多是我在看完电影后，想到了什么，有时候可能和原片的关联并不大。

电影前

去年看《疯狂动物城 2》的时候我就注意到了这部电影：画风实在是太可爱了！后来我才知道，设计上有点点的作者的参与 —— 点点是条可爱的小狗蛇；它的创作者是动画师「yogin 幺菁」。

电影前，我看到了专门给影院设计的广告，里面有 Chuck E. Cheese 的。正常来说，大家说到 Chuck E. Cheese 都会想到儿时来这种游戏厅玩乐的时光。当然，要是你去过的话。但我受 FNAF 系列影响，再加上前段时间刚看了 FNAF 电影的第二代，每次看到都会想到吉祥物恐怖作品。

2024 年 Chuck E. Cheese 推出了会员制，每个月要支付 8 美元，每天能得到 40 游戏积分，买吃的还有优惠，很适合暑假的时候把小孩子丢到这种游戏厅里，让他们肆意乱跑。可惜我家附近没有 Chuck E. Cheese。

小时候对 Chuck E. Cheese 很有好感，因为它家的披萨很好吃。现在已经很多年都没有看到过 Chuck E. Cheese 了，不知道它现在是怎么个处境。

电影中

说回《河狸变身计划》。在看这部电影之前，我就看到了许多骂它烂的视频，所以在看之前，我对这个电影带有负面印象。

实际上，看完后我发现电影想要讲的和网上的视频里所说的，根本不是一回事，甚至是完全相反的观点。这让我怀疑这些人到底有没有看进去，还是听到个「环境保护」的关键词便肆意攻击。

作为儿童向商业电影，《河狸变身计划》的可爱画面以及透露出的社会问题，已经足够及格 —— 话虽这么说，它的问题依然很多，其中让我最在意的是电影对反派 Titus 的塑造。

和《疯狂动物城 2》的设计一样，这位反派最终展现出来的是疯狂的样子，而正方最终要做的，仅仅是打败这个脸谱化的疯子。尤其是打败的方式还相当滑稽，稀释掉了前面铺垫的矛盾，最终看到的只有虎头蛇尾的收场。

和 Pawbert 不同，Titus 并没有背负什么主题或者问题，如果「蝴蝶没有人类强大」算主题的话…… 好像也不是不行，「弱小的生物试图成为更强大的生物」，或者「一心只为了王位的暴君其实也有脆弱一面」——！但电影看上去并没有打算展开描写这些，所以就当它们不是吧。

我说的「最终要做的」，指的是正方确确实实花费了精力去做，且制作方想办法去刻画的事情。打个照面就解决的「问题」不是问题，仅仅只是套路罢了。电影里就有许多这样的套路，令人失望。不论是女主 Mabel 和 George 之间第一次冲突，还是结尾 Mabel 和 Jerry 之间的冲突，都是这样。

然后是反派的存在目的。电影的主题是「共存」，但后期明显丢掉了该主题，让一切变成了为了感官体验、为了爽的二元制「对抗」，也就是变得非黑即白了。Titus 的出现到落幕，都是制作方想要在电影中添加一个纯粹的恶、纯粹的敌人 —— 接着又在他彻底发疯之前透露出他母亲死后孤独的一面，好似在说他不一样，但实际上依然和常见的疯子反派没有区别。

归根结底，《河狸变身计划》让我不满的是，它明明让许多社会问题浮出水面，但处理起来过于儿戏。难道只要解决了有问题的人，那问题就被解决了吗？同样，解决冲突就很儿戏，让整部电影更适合不带脑子看。

关于电影的主题，我并不认为它是个讲环保的故事，环保不需要提倡，重点是「身份」：人作为动物的一员，能不能以人类的标准去干预自然环境？

既然人类是动物，是自然的一员，那人类的所有行为在广义上是不是都可以被视为自然演化的结果？那故事中建高桥、破坏环境，是不是自然界中常见的强势物种对弱势物种的压制和利用？

但事情根本不是这么运转的。人类掌握着游离于生物本能之外的技术力量，早就打破了整体内部的平衡。像破坏环境，也不是为了控制猎物数量去做的，而是为了让高速公路可以快几分钟。这种话你讲给动物听，它还要问你「高速公路」是啥哦，一种没见过的鹿吗。

为什么电影让 Mabel「成为」仿生河狸，并用河狸的身份去帮助动物们？这是为了贴合「整体」，让女主融入到整体中。但电影在主题上的问题也随之而来：女主就算成为了仿生动物，她的思维是动物的思维吗？她不仅在以人类的思维去考虑事情，也无法理解动物们的规矩，甚至就算死了，也不过是机械身体被摧毁，人依然还活着。

电影的结尾是好结局，Mabel 想要保护的地方依然存在，高桥被建去了别的地方。可是，这一切都要源于她选择变成动物。尽管电影中经常有角色表示「不要人为干预自然环境」，但是这个好结局不正是 Mabel 人为干预才有的吗？制作方究竟是提倡人为干预，还是反对呢？

电影外

我在看完电影后也看了个影评，大致内容讲的是《河狸变身计划》很棒地展现出了现实生活中的极端组织是如何从「正确」一步步走向疯狂的：动物保护、环境保护组织，现在每每谈起都会想起他们做过的坏事儿和蠢事儿。既然这么坏、这么蠢，为什么组织里依然有人为此着魔，组织外的人还很难拿他们有办法？

因为他们认为自己是「正确」的，是「正义」的一方。既然我已经是正确的了，那要解决我所担忧的事情，应当是当务之急的。所以我认为其他人必须赞同我，谁不赞同就是反对动物保护或者环境保护。

像我先前提到的，没有人会反对环保。保护环境本就是为了更好的世界，也是为了人类的生存环境可以更好。可一旦目标上的高尚被用于掩盖手段上的越界，极端组织也就垄断了道德的「解释权」—— 打上引号是因为，站在「正确」的立场不意味着做什么就真的都可以被容忍、原谅了。

近期和 Fediverse 上的朋友聊到了「以正义之名宣泄恶意」。在我们的语境里，背景是互联网。例如在一个娱乐性质更多的互联网圈子内，比如特定游戏的圈子吧，路人甲发表了「不对」的言论，或者做了「不对」的事情。因为触及到了圈子的规则，因此路人甲被其他人声讨、开户、查在互联网上的任何蛛丝马迹并对此进行侮辱…… 因为路人甲是「坏人」，所以这么做是「正义」、「正确」的吗？

人是复杂的，不是扁平的。我可以像个正人君子一样在这里胡说海说，但也可以拥有很混蛋的一面。这不影响别人去赞同我的部分观点，同时反对我的另一部分观点。因为这不是简单的二元制，所以实际理解且实践起来要困难一些。

最常见的做法是因为路人甲做了错事，所以我要否定他整个人。同理，也可以因为声讨路人甲的路人乙做了「对事」，所以神化他、视他为「神明」—— 这样做一定又会因为路人乙做了不合大众胃口的事情，而被贬低成猪狗不如的东西。因为你无法确认路人乙是真的想要伸张正义，还是想要发泄恶意、发现了路人甲这么个可以被随意辱骂的沙包。如果是后者的话，路人乙的「恶意」自然会随着时间被围观群众挖掘出来。

好像这样的事情，每天每天都在发生，不腻一样。

我过去还是个很「网络」的人的，会使用很多社交平台，尤其是国内的社交平台。渐渐地，我越来越不想要在社交网络上留下公开的足迹，因为总是会出现一些莫名其妙的言论，让我觉得很烦，其中最不乏针对我所在国家的评论。

因为我所在的国家不一样，所以我有了「美国 IP」的标签。这标签将「我」压缩成了单一的片面符号，比方说「美爷」、「富哥」，但明明我根本就没那么有钱，甚至人生的很多时候是贫穷的。

标签的存在是为了大幅降低理解的成本。它同样也有好处，可以让陌生人们快速亲密起来，但这不在我想要谈论的范畴内。

因为贴标签不需要消耗过多的心智，所以只要给事物打上「正义」或者「邪恶」、「保护着」或者「破坏者」的烙印，人们就可以心安理得地放弃思考、理直气壮地宣泄情绪。关于标签化的问题，我过去在写「强奸者」和「被强奸者」的文章里也有提到过。

尽管近些年逐渐有民众发现标签化不好的一面，但它依然没有结束，反而变得更加隐蔽且坚固。人与人之间的共识变得愈发廉价，沟通也变得不可能。想要维持真实的自我，在如今这个时代倒是成了种奢侈……

了解 Kagi 的历史

2026-04-04T04:00:00.000Z

上个月我在 Kagi Store 上下单了 Kagi 的 T 恤衫、袜子周边。不为别的，Kagi 的吉祥物设计很可爱，画风很独特。

不过在搜寻时我发现了这个 Hacker News 链接，也迫使我不得不去探索 Kagi，这个大概被我神话过头的公司。

首先我必须再度说清楚，我所说的 Kagi 不单单只是个搜索引擎，而是一个公司（Kagi Inc.）。不过这么说也不准确，因为 Kagi Inc. 这个实体于 2022 年 3 月份才成立，而团队开始捣鼓 Kagi 的 AI 产品早在 2018 年便有记录（见 Kagi 历史），甚至早过 2019 年 Kagi Search 的原型产品。

Kagi 这家公司太小了，以至于 Wikipedia 都没有 Kagi Inc. 的条目，只有同名为 Kagi、实际上在产品线中叫作 Kagi Search 的搜索引擎产品。要了解 Kagi Inc.，只能慢慢从不同年份的博客文章中找出各种蛛丝马迹了…… 没关系！我隐私条款都读过，还怕你个博客文章！

总之先从 Wikipedia 开始吧。Wikipedia 上写了什么并不重要，重要的是它所引用的参考资料，以及开头所写的「这篇文章可能过度依赖与主题密切相关的来源，从而导致条目内容缺乏可验证性和中立性」。稍微看一下参考资料就会发现，许多确实是来自 Kagi 网站自己的文章。

好吧，那我们先读一下 Kagi 自己如何评价自己。在 Kagi 的关于页面、Kagi 历史，和 2024 年 Kagi 的一篇文章里我们得知，它的历史发展可以划分为四个阶段：

一、技术探索与试错。

Kagi 由 Vladimir Prelovac 于 2018 年 5 月在美国加州的帕罗奥图市创立。最初的四年里，公司完全由 Prelovac 自筹资金，大约是 300 万美元。

早期的 Kagi 并没有直接去做一个完整的搜索引擎，而是将重心放在了 AI 和问答技术上。这一点可以查看被存档下来的 kagi.ai 网站。所以你要说 Kagi 是一家 AI 公司，也大差不差吧！这也反映了未来 Kagi 有许多 AI 产品的原因。不过那可是 2018 年，当时的 AI 产品指的还是 Siri 呢！

总之当时的 Kagi 认为未来的搜索引擎必须具备强大的即时问答能力，这倒是和现在大家使用生成式 LLM 聊天机器人的方式差不多：问问题。

在这个阶段，Kagi Search 的第一个原型也诞生了，用的是命令行模式，还挺符合 MVP 开发逻辑的。Orion 浏览器的早期原型也一起出现了。

关于 Kagi Search 的原型体，感兴趣的可以见：

他们还尝试建立高级搜索业务 Donna.gg，不过失败了。

二、底层研发与内侧。

接着疫情来了。Kagi 的团队规模翻倍达到 10 人。他们在 2020 年到 2021 年的期间将早期的技术积累转化为实际的产品，即进入了封闭 Beta 内测阶段的 Kagi Search 和 Orion 浏览器。

三、商业化验证与公测。

2022 年 3 月 4 日，Kagi Inc. 正式注册成立。同年的 6 月份，搜索引擎和浏览器进入公测，并确立了「用户付费」的无广告商业模式 —— 太好了！而仅仅三个月后，就有数千名用户开始为这些产品付费。

2023 年是 Kagi 商业模式被验证的关键节点。这一年他们实现了 100 万美元的年度经常性收入，证明了「人们愿意为优质且注重隐私的搜索付费」这一假设。同年，他们通过社区向 93 位天使投资人（也是他们的用户）筹集了约 250 万美元。

四、组织进化与生态扩张。

随着公司实现盈利，团队规模扩张至 40 人以上。在 2024 年，Kagi 推出了 Assistant、Translate 以及企业版服务。

更重要的是，在 2024 年初，Kagi 在法律事实上完成了商业实体的转变，成为了一家公共利益型企业。

到 2025 年，Orion 浏览器也结束了 Beta 测试，并推出了隐私通行证等新功能。

大致的历史中便出现了一些商业术语呢，必须要讲清楚一下。

在理解 Kagi 的实体转变之前，我们得先厘清商业实体的概念。

简单来说，商业实体是法律在纸面上创造出来的拟制人，AKA 假人。当创始人开展业务时，如果不成立实体，所有的债务和法律责任都会由创始人个人承担。而成立了商业实体之后，公司就有了自己独立的法定身份，它可以拥有资产、签订合同、雇佣员工，并在法律上承担责任 —— 所以说有些人说自己最爱公司不是错的，它在法律层面上就是个人啊！

对于美国的科技初创公司而言，最常见的实体类型是特拉华州 C 型股份有限公司。为什么要说「最常见」呢？因为我找不到 Kagi 最初注册时选的类型是什么。特拉华州公司检索系统会直接显示 Benefit Corporation，也就是 Kagi 之后才转变成的公司类型。所以我就默认它是 C 型公司吧。

C 型公司的核心特征在于其在法律和税务上的绝对独立性。它是一个独立于所有者（即股东）的法人实体。这种架构的最显著特点是，你要征两次税（哦不！）：公司本身需要为其产生的利润缴纳企业所得税；当公司将税后利润以股息形式发放给股东时，股东还需要在个人层面缴纳个人所得税。

如果对股份感兴趣的话，我在今年一月份有简单聊过。不过当时的聚焦点主要是在股票市场上。这里再说一下：卖股票不意味着一定要在公开股票市场卖，还可以通过私募的方式出售股权。所以就算 Kagi 不是上市公司、你在股票市场上看不到 Kagi 的大名，它依然是有股东的。

继续说。C 型公司允许发行不同层级的股票，能够极为便利地进行股权融资、发放员工期权，所以尽管它存在着税务上的劣势，绝大多数初创公司依然会选择这种架构，天使投资人们也更喜欢它。

在这种架构下，公司董事会和管理层会受到一种被称为受托责任的严格法律约束。这种责任要求他们必须将「股东利益最大化」作为核心，甚至唯一的商业决策目的。比方说你得让公司有好看的财务报表、利润要赚得多多的……

顺带一提，这种责任的确立可以追溯到 1919 年著名的 Dodge v. Ford Motor Co. 案。

2024 年初，Kagi 的商业实体转变成了特拉华州公共利益型企业。它和传统的 C 型公司的区别在于，它要求公司的董事和高管在追求股东财务回报的同时，比如兼顾特定的公共利益，以及其他利益相关者的诉求，比方说用户和社区！

这下你或许就会明白了。Kagi 的卖点本就是「不卖广告、不追踪用户数据、完全由用户付费」，那它要还是维持传统的 C 型公司结构的话，未来要是发展壮大了，可能就会面临巨大的法律和商业冲突。

举个例子，一家大型广告公司提出以极高的溢价收购 Kagi，如果有投资者指出「如果加入广告的话，公司的利润可以翻十倍」，那你在传统 C 型公司的法律框架下，你会拒绝吗？董事会如果拒绝这些能让股东利益最大化的提议的话，就有可能会面临股东的起诉哦。

那转变为公共利益型企业后，Kagi 就可以合法地对利润说「不」了，因为他们「致力于创建一个以人为本、可持续发展的网络」。

这同时也向付费用户，即我们，提供了一个法律层面上的保证，证明其永远不作恶、不卖广告。

而年度经常性收入（Annual Recurring Revenue，简称 ARR）是一项财务指标，主要用于评估订阅制业务或 SaaS 公司的收入表现。它衡量的是「公司在未来十二个月内，基于现有订阅合同可以合理预期的、稳定的经常性总收入」。

对于一个订阅制软件服务而言，100 万美元的年度经常性收入意味着企业已经拥有了可预测的现金流来覆盖基础研发和运营成本，且其商业模式能够在小规模的样本下跑通！

所以这串数字象征着，Kagi 成功打破了「搜索必须免费」的思维定势。

知道了 Kagi 在商业模式上的历史，接着来看看其技术方面上的历史吧。和 Google 不同，Kagi 并非一个像 Google 那样从零开始爬取全网的独立搜索引擎，而是一个元搜索引擎，或者说是「搜索客户端」。

2023 年，Kagi 曾明确定义过自己的架构：当用户输入一个查询时，Kagi 会将这个请求分发给后端的多个信息源，然后将拉取到的数据进行清洗、重新排序，最后呈现给用户。这一段内容可以见这个被存档的文章。

它的信息源分为两类：一类是垂直领域的 API 接口，例如 Wikipedia、Apple Maps、Yelp、TripAdvisor 等；一类是最为核心的综合网页搜索索引。在早期，Kagi 明确标示了它对外部通用索引的依赖，包括 Google、Bing、Yandex、Brave 和 Mojeek。

怎么说呢，这样的架构就很…… 客户端。如果老板让我写个搜索引擎给他，估计我也会这么做。

进入 2024 年后，Kagi 不再公开列出其使用的传统搜索引擎来源了，这主要是因为两点：

Bing 的 API 价格涨幅高达 10 倍（之后 2025 年还停用了 Bing Search API）
Google 不提供公开的搜索 API，除非使用广告联合分发包。

这意味着，Kagi 失去了通过正规合同获取这两大巨头数据的合法路径。在一篇 2026 年的被存档文章中，Kagi 承认道：「由于无法在兼容的条款下获得直接授权，我们和许多其他公司一样，使用第三方 API 提供商来获取 SERP 风格的结果（SERP 指搜索引擎结果页面）。」

这种方式是灰色的，因为第三方 API 供应商本质是在通过技术手段大抓特抓 Google 和 Bing 的搜索结果。再加上 2025 年年底 Google 还真的起诉了大型抓取服务商 SerpApi，侧面反映出了 Kagi 确实不该公开列出自己所使用的源。

所以我们也不知道 Kagi 的搜索结果具体都来自谁，不过根源肯定也会是 Google 和 Bing 就是了。

值得一说的是，这些 API 是按次计费的，是变动成本，而我们用户订阅 Kagi 是每个月支付固定的金额。这意味着，成本和收入是可以错位的，随之而来的隐患便是破产。

顺带一提 Kagi 也有自己的爬虫和索引系统，其中最核心的是针对 small web 的 Teclis。它的技术实现，很暴力：使用 Puppeteer 配合 uBlock Origin 来渲染网页。如果在加载网页时触发了 5 个以上的广告或者追踪器拦截请求，该网页就会被直接从索引中剔除。

随后 Kagi 会使用 Elasticsearch 和 Typesense 进行全文检索，结合自然语言处理模型进行语义向量搜索。

你已经对 Kagi 有一个大致上的了解了，现在让我们把焦点放在本次要回应的文章上吧！

lori 在 Kagi 的 Discord 频道中观察许久，基于这些观察，他提出了一些普通用户不会考虑到的点。由于这篇文章发布于 2024 年，所以一些东西可能是过时的：

一、T 恤衫事件。

先前说到 Kagi 在 2023 年筹集了约 250 万美元的社区资金，其中有 67 万美元是他们首次外部融资筹集来的。接着在 2024 年 1 月 24 日，Kagi 表示为了庆祝自己有了两万名付费会员，拨出了其中的三分之一，也就是 20 多万美元成立了一个全新的业务实体来生产，并免费分发这两万件 T 恤衫。

这让 lori 觉得很困惑：为什么要花这么多做这种事情呢？我也承认花这么多钱做这件事听上去有欠考虑。

但我对 lori 提到的这个「业务实体」更感兴趣：它叫什么名字？在哪里？真的有一个独立的仓库吗？因为你不能就 Kagi 的博客文章这么说了，所以相信他们成立了家商业实体。

商业实体的注册和成立，都是可以被查到的。证明这个实体是否存在，便成了我的首要目标 —— 我也很好奇嘛。

Kagi 在 2024 年 9 月份，也就是 Kagi Store 上线的时候发布的博客文章中提到：「我们并没有真的开一家 T 恤工厂。」所以 lori 文章中所说的工厂是绝对被夸大了的。

但我还是很好奇啊！没有工厂，不意味着商业实体不存在，对不对？为此我跑到多个德国的商业登记系统数据库内进行检索，结果发现唯一一个和关键词 Kagi 相关的公司是 Kagi Trade UG。但这是一家机械贸易公司，2021 年便成立了，和我们现在说的 Kagi 明显不是同一个。

这就很难办了。确实，Kagi 为发 T 恤衫设立的那个实体，名称不一定是 Kagi，高管也不一定是 Prelovac。那咋办呢？

我只能说，就像我们不知道 Kagi 的传统搜索结果来自哪个第三方服务商，我们也不知道 Kagi 到底有没有成立一个商务实体在德国 —— 好啦，我认为没有。如果有的话，早就被人翻个底朝天了，也轮不到我这个站在 2026 年的时间点的人指手画脚。

说回 T 恤衫本身。根据 2024 年 4 月 12 日 Prelovac 通过 Hacker News 对这篇文章的回应中可以看出，他想要取悦用户社区。因为 Kagi 不做任何付费广告，能增长完全是依靠社区的口口相传。

我尝试用其他方式来为 T 恤衫辩解，最终只能想到「穿上它上街相当于免费为 Kagi 打广告」这一个说辞。那两万个用户到底想不想要这件 T 恤衫呢？我不得而知。我只能说它作为一个品牌的周边挺不错的，但我会更期待初创公司只花一点点钱，找些合作商定制马克杯、贴纸什么的送出去。

二、整整两年忘记缴纳销售税。

lori 认为 Kagi 有两年没有缴纳销售税很莫名其妙，以此怀疑 Kagi 当时的财务状况并不好 —— 呃，说实话，两年没有缴纳销售税，也没有听上去那么糟糕？因为我有许多客户有数年，甚至二十多年都没有缴纳销售税。原因通常是他们的税务师不负责任、没有把这件事情告诉他们。最后我们也只能让他们自首。

根据 Prelovac 在 Discord 中的截图，看上去也更像是他们没有意识到自己需要缴纳销售税这件事。也很符合我心目中一心只有技术的技术宅的刻板印象啦。其实我在搞公司之前，也对税务一窍不通，现在顶多是知道一些些。

税务这个东西我只能说，不懂的人是真的不懂，也会惹出许多笑话。但这并不是他们的错，义务教育里又没有教过美国人们税务知识，而会学习它们的多是 ego 比天还高的傻瓜税务师。这也是我们公司一直在想办法改善的问题，也在致力于帮助那些被不专业的税务师坑骗的人们 —— 咦，怎么开始推销了？

不单单是税务师，会计师、律师也有着同样的问题。自己不专业就算了，冷落自己的客户，然后搞出来的破事儿丢给客户自己处理。就算客户不知道、将事情都交给税务师处理，但如果被税务局查到、抓包了，依然是客户承担主要责任。

之后我阅读了 Prelovac 对 lori 文章的回应，即一个被 lori 公开在 Fediverse 上的邮件串后得知，最初是 Prelovac 不知道付费搜索会被市场接受，所以早期就没搞。好吧，我以为你不知道呢！

三、AI 愿景与用户期待的严重错位。

这是这篇文章中最核心的技术冲突。

很多用户转投 Kagi，是为了逃离 Google 越来越臃肿的 AI 概括和 SEO 垃圾，他们想要一个老派、纯粹、只给链接的搜索引擎。

但我先前也说过了，Kagi 在 2018 年创立的第一天叫 Kagi.ai。Prelovac 的终极愿景从来都不是做个复古的搜索引擎，而是做一个用 AI 帮用户总结的工具。

在这个终极愿景实现之前，Kagi 靠下放控制权留住了这些讨厌 AI 的用户，也就是用户可以在客户端层干预搜索结果，比方说拉黑特定内容农场。

这也解释了另一个问题：既然终极目标是 AI，为何 Kagi 还要花好几年时间做一个传统搜索页面呢？原因在于，早期大语言模型存在着严重的幻觉问题，Kagi 必须先打磨出一个具有高质量清洗、去重和过滤能力的传统搜索系统，以此作为未来 AI 产品的基座 —— 只要底层的信源足够干净，上层的 AI 总结才具备真正的可用性。

也就是说，Kagi 的技术策略是「表面做 A，实际为了 B」。这一点也体现在 Kagi 庞杂的产品线上。除了 Kagi Search 外，Kagi 显然想要做个互联网生态全家桶，涵盖了搜索引擎、浏览器、电子邮箱服务等我们平日会使用到的东西。lori 认为这些太多了，只做 Kagi Search 会更好。

事实上，在先前的 Hacker News 讨论串中也有很多人在当时认为是在浪费资源。比方说有个评论认为，Kagi 在和 Google 以及 Microsoft 竞争，将资源放在非核心产品的东西上都是在放弃。

不过 Kagi Search 真的是 Google 和 Bing 的竞品么？它们确实都是搜索引擎，但说是竞品实在是太高抬 Kagi Search 了。它的搜索来源真要追溯，不还是 Google 跟 Bing 吗？Kagi Search 只能算是元搜索客户端的一员罢了；根据现在的统计来看，其会员数根本不够格，才近 7 万而已。

说到 Kagi 其他的产品，我其实都有在尝试使用。比如 Orion 浏览器，我就安装了个在 iPad 上，来代替原先的 Edge 浏览器 —— 嗯，我在折腾 degoogle 和 demicrosoft 的时候把我的 iPad 给忘了。这个支持 Chromium 和 Firefox 插件的 Webkit 浏览器很有趣，我还在探索阶段。

我用的最少的是 Kagi News，因为我压根不怎么阅读新闻。其次是 Kagi Maps，它怎么说呢，没有导航系统意味着我很少会打开它，但是搜索地点还算不错，可以说是 Kagi Search 附带的地图功能。

至于 Kagi Assistant 嘛…… 我只使用过 Quick mode，更进阶的 Research mode 我没有打算付费使用。我使用过竞品 Perplexity，这种问答引擎找资料挺有帮助的，但产品类型并不是我会经常使用的。

如果 Kagi 真的要弄出一个互联网全家桶的话，我会不会使用是个好问题：我会放弃自己托管的邮件服务，改用 Kagi 邮箱么？不过当务之急的应该是，先让 Kagi Small Web 支持中文独立网络吧！

四、隐私观的本质分歧。

Kagi 是一家在美国注册的公司，这已经注定了其存储的隐私数据在美国政府面前不值一提。我在研究 VPS 服务商的隐私条款的文章中已经提到过了，在美国注册的实体，其数据无论存储在哪里都没有用，依然可以被美国政府够到。

GDPR 也不是那么神仙的存在：想要自己隐私安全的唯一办法就是，不要把自己的信息上传到互联网！

但是 2024 年的 Discord 频道截图中也可以看出，当时的 Kagi 团队对隐私权并不了解，甚至可以说是有点白痴了 —— 你的卖点是尊重隐私，但你表现出来的好像对隐私一窍不通？比方说「电子邮件地址不属于个人身份信息」、「世界上除了罪犯，极少有人需要真正的完全匿名」。唉，初创公司另一个难过的槛儿是公关问题啊。

不过当年的担忧，在 2025 年有了满意的答卷：Kagi 推出了 Privacy Pass 身份验证！也就是说，用户的付费账户身份和实际搜索行为在数学层面上彻底地切断了联系。紧接着 Kagi 还官方支持了 Tor 服务。

现在用户的搜索查询不再与包含邮箱的账户绑定，那么 Kagi 在处理搜索数据时，就几乎不再触及个人可识别信息。即使 Stripe 依然保留着用户的付款信息和邮箱，但只要这些信息无法与用户的搜索历史关联，隐私泄露的风险和法律合规的压力便大大降低了。

这篇文章也意外为 Orion 浏览器正了名。过去用户视其为不务正业，但文章中提到，由于 Safari 的技术限制，Privacy Pass 无法在 Safari 上完美实现。此时，拥有自己底层控制权的 Orion 浏览器的价值便体现了出来~ 可喜可贺，可喜可贺。

五、不要给我发邮件了！

在文章发布后，Prelovac 尝试通过电子邮件和 lori 联系上，以此来讨论这些事情，也就是先前我分享的邮件串。

lori 最初便表示了不想要和 Prelovac 有任何联系，也不想要和 Prelovac 沟通 —— 理由在文章的结尾写明了，他在 Discord 频道中已经知道了 Prelovac 是个什么样的人，所以无力去和他起争执。但是 Prelovac 依然向 lori 发送了对文章的回应。

电子邮件这样的沟通方式，因为会存储到对方的数据库内，所以并不静默。如果 Prelovac 只是在自己的博客上写了篇回应，那也真的还好啦，但明知对方不想要沟通的情况下，还是硬把观点塞给对方，这就是对对方的不尊重了。

至于我会不会因此讨厌 Kagi、不再使用 Kagi 的产品，那自然是不会的。因为 Kagi 是集体工程的产物，不单单是 Prelovac 个人的项目。需要将产品的使用价值与创始人的个人做派剥离开来。

但也就我先前常提到的，这是个「马后炮」的回应。在 2026 年的现在，Kagi 的一切看上去很不错：它已经不是个无法与创始人的个人特质解绑的初创公司了。

无论用户会选择继续支持，还是放弃 Kagi，都是他们自己的选择。这一点上，我和 lori 的观点是一样的。

想法在丙午蚕月迭代

2026-04-01T04:00:00.000Z

本月的条目和内容依然不多。待税务季结束后我会重新花费精力在月刊上。

本期导读

那些不受欢迎的想法・贰

2026-03-23T04:00:00.000Z

三月份的「那些不受欢迎的想法」活动结束了。说实话，这次的内容并没有二月份的那么印象深刻。简单来说，便是不够「不受欢迎」。

上篇文章里我提到了，我提前知道了一位朋友的具有争议性的想法。我依然在写作时偷了懒，并没有将他的观点全盘托出，只是借了他提出的「动量」概念，改来说自己的观点。

可惜的是，他并没有在这次活动中讲出这个观点，否则我就可以用参与者们吵架的事情，又写一篇文章了。

总之，他对我上篇文章的内容很不满意，认为我没有写出他的意思，虽然我觉得已经在不大幅度修改我原本的观点的情况下，很努力地引入了他的概念且不会偏题了。

所以，我要重新声明一下他的观点。他的观点是，人们做出的选择大多数并不是自己决定的，而是动量决定的。至于为什么，我已经在上篇文章中进行了解释 —— 他所谓的「真正的观点」，和我阐述的根本没什么区别吧！

好了我已经满足了朋友的需求，来继续看看本期其他人的「不受欢迎的」想法吧。

一、问题少年产业

令我感到意外的是，许多人都对「话疗」这一行业很有想法。

我从来都没有接受过话疗，所以不知道话疗到底是个啥，也不认为它是一个多么常见的服务。现在看来，这个地区的人们体验过话疗的并不少见。我去问了一些朋友，他们告诉我美国几乎每个人都接受过话疗，一辈子没接受过话疗的，是一件相当「东亚」的事情 —— 也许是因为东亚在心理学上发展得慢吧。

但我不认为话疗服务是一件多么好的事情。上期能有人特意骂这个行业，本期也不会少。详细的想法我会留到后面。

第一个开始分享的人，提到了「香蕉」。可惜，并没有任何香蕉在他想要分享的观点里，他只想开个玩笑而已。他的观点和 troubled teen industry（以下简称「问题少年产业」）有关。

说「问题少年产业」，大家或许无法想象出这是个什么东西，但如果说到国内的治疗网瘾寄宿学校以及杨永信，说不定就能立即明白这个产业是怎么个回事了吧。

1958 年，Charles Dederich 创立了 Synanon 戒毒项目。在二十年的沉淀下，该项目演变成了邪教。它是美国创立的首个针对药物成瘾者的治疗性社区（Therapeutic Community，简称 TC），其核心是居住式治疗模式，通过严格的团体生活、行为纠正和心理干预来重塑成员的人格与行为模式。

中国的部分戒瘾治疗机构也采用了类似的 TC 模式。这些机构会实行封闭式管理，让学员们集体生活，通过军事化训练、心理辅导和行为纠正课程来干预成瘾行为。

以上全都是字面上的、给蠢蛋家长们听的好话！

实际上，无论是 Synanon 还是中国的戒瘾机构，都因为采用了各种争议性手段而伤害到了学员。比方说，Synanon 独创了一种名为 Synanon Game 的团体攻击疗法，旨在鼓励成员们互相批评和羞辱。接着推广了 tough love 攻击疗法，说可以靠言语攻击来治愈青少年的不良行为 —— 狗屎！

尽管 1991 年 Synanon 因破产而解散，但它的许多「信徒」都深信这种攻击疗法可以治愈他人，而开设了一个个治疗机构，也就形成了先前说的「问题少年产业」。

十分悲伤的是，这个产业依然存在，依然在合法折磨、杀死数不清的孩子们。孩子们被绑架、监禁，同时在心理、精神和肉体上遭受没有人性的折磨，而施暴者们却说这一切都是「严厉的爱」。恶心得令人作呕！

回到提出者的故事。他作为一个话疗师，起初并不知道这个产业有多么糟糕，因为也是许多年前的事情了。他大学毕业后便来到了一个野外治疗项目工作，即问题少年产业中的一种住宿式干预形式，通常将青少年们安置在偏远的自然环境中。参与者们需要进行徒步、露营和野外生存等活动，并同时接受团体和个人心理治疗。

抛开纸面上好听的地方不看，这种项目依然存在着折磨等问题，以至于他还没有离职时，就因为过多的法律诉讼而强制关闭了。

讲完大致的背景故事后，他说这种行业一定会消失，但问题在于，终会有另一套系统去代替它的生态位置，因为问题青年依然存在，问题青年的父母也会源源不断将他们送到类似的机构内。只要需求还在，总会有人为了大赚一笔，充当对应的供应方。

因此他认为野外治疗项目是利大于弊的，因为它可以帮助孩子们远离手机、去到户外、接触阳光。社会应当清除劣质的机构，而不是全盘摧毁整个行业。

What the fuck?

前面说了这么多，只能感觉出对问题青年产业的厌恶，但结尾的定论，却潦草无比。

这次的活动有个规矩，发言只能有两分钟。这是硬性的，因为主办方真的会拿着定时器计时。没办法，活动时间就这么长，为了所有人都能发言，只能削减每个人的发言时长。

这位参与者显然陷入了语境过载的陈述陷阱，即过分交代前置信息，反而令后面真正的论点变得浅薄无比。用网络用语来说，就是「叠了太多层甲」。

「叠甲」这一行为的根本原因，是人们过于担心自己的观点被人质疑或者攻击，而想尽办法向外人表示自己知道且认同「大众」相信的观点。又换句话来说，对自己的观点不自信。

听者听完后，只会去想这种产业多么应该被铲除殆尽，而不是「阳光、远离手机、重建社交技能」等仅是用词汇堆砌出来的论据 —— 我家孩子都要死了，你还要跟我说问题青年产业好就好在至少我家孩子不是玩手机玩死的吗？听者根本无法理解这些要素如何产生治疗效果。这一点也在后续的讨论中展现了出来：大家都在聊机构的腐败和虐待底线，根本没有人提项目本身的积极机制。

青少年缺乏基本权利，这一点我在伟大灯塔的童婚丑闻中提到过。他们无法给予实质性上的同意或者不同意，大多数情况下不过是父母强制他们同意、他们才同意的。因此青少年在这些项目中被随意「绑架」带走，前提正是有人替他们做了决定。这是权力结构和系统性上的漠不关心与无能。而这又不得不提到机构内部的包庇文化。

讨论期间有人做出了这样的类比反问逻辑：「如果一所小学的老师猥亵了学生，你会直接关闭这所学校吗？」

该反问忽略了「偶发性违规」和「系统性作恶」在权力结构上的本质差异。

首先，正规学校拥有外部监管、透明的投诉机制，以及受法律严格约束的从业门槛，教师的作恶是对系统规则的背离。

其次，问题青年产业的运作逻辑在于物理隔离以及权力的绝对垄断之上。在黑盒结构中，虐待可不是什么错误，而是结构性的必然，因为其设计初衷就是在掩盖和促进伤害。

撇开已存在的虐待事实，再去夸赞项目本身是积极的，是奇怪的。我们已经知道，青少年在项目中是无助的，权威人士是漠不关心或者说无能的，那是否可以证明项目本身就存在根本性的问题？因为这一切不就是因为成年人做出的数个糟糕决策吗？

一位参与者尝试用经济学的现象去看待项目本身的积极性：大家有钱都会想要去赚，就算是一个糟糕的项目，也会尝试控制其损害、保留其积极的部分，再广大宣传出去。那问题青年产业究竟需要做出多么烂的事情，才能让人们想要去全盘废弃它？同样的，政治也是得烂到一定程度，才会让人们发动彻底的革命。

不过这样的说法依然过分简单化了问题。别说和问题青年打交道了，和青年打交道都是一项困难的工作，且报酬往往不高。结果真正合适该工作的人不愿意做，机构的候选人池里只有别无选择、为了糊口、会成为施暴者的人。如果无论是哪个理论模型，候选人池都是这种人的话，那么虐待只会以不同的形式存在。当然，你也可以花大钱聘用最优秀的人才，但这并非长久之计，仅仅是无数个补丁中稍微有用些的一个罢了。

那么根本性的问题在于哪里？是「青少年们缺乏权利」吗？不，这样的逻辑依然仅成立了一半。

未成年人在法律层面不具备完全的自主决定权，是因为他们心智尚未成熟。如果赋予自毁边缘的青少年完全的拒绝权，任由其行使「不接受任何干预」的权利，同样违背了社会和家庭的监护初衷。「青少年缺乏权利」是社会保护机制的副产品，但并非这门生意走向施暴的终极推手。

真正的系统性灾难发生于「监护权」和「商业利益」上。问题青年产业的底层逻辑是家长在面对自身无法解决的家庭危机时，视图花钱将监护责任和教育义务一同外包。管教、行为纠正、心理干预全都被彻底商业化，且运作于一个封闭的黑盒环境中时，权力的天平将不可避免地失衡。

曾经我在初中上一节忘了名字的课时，老师问我们，麦当劳儿童套餐广告的面向观众是谁。我回答说，是孩子。老师纠正道，孩子可没有钱，广告实际说服的是为其掏腰包的父母。

在刚才提到的商业闭环中，机构也不需要对真正的服务对象，也就是青少年负责，因为青少年没有付费能力，也没有退出机制。机构只需要对支付账单的家长负责就好了。只要通过一套精美话术稳住家长，让家长相信一切折磨都是为了孩子好，这个商业模式就能完美闭环。

而候选人池问题是商业模式的必然结果。既然机构的生存不依赖于青少年的实际治疗效果，只依赖于家长的持续付费，那么在内部运营上，资本必然会追求利润最大化。压低运营成本最直接的方式，就是雇佣廉价、缺乏专业心理学或医学资质的劳动力。所以不完全是先前提到的「合适的人不愿意做」，更有可能是机构的盈利模型本来就排斥高成本的专业人才。

二、Passport Bro

提出者近期去了次巴西，回来后曾经也去过巴西的同事问他，有没有做 Passport Bro 的那些事情。

Passport Bro（跨国寻爱族）是大众用于描述专门跑到其他国家结婚的西方人的词汇。这些西方人往往被认为前往其他国家以享受更高的购买力、更低的生活成本，以及将自己视为富人的他国女人的崇拜。而根因也往往被认为是在自己的国家里不够具备竞争力。

提出者的观点是：拥有财富和特权的男人去另一个国家，利用这些财富和特权去吸引女性是不对的。因为这专门针对了不太富裕的国家，且将这种针对作为与某人建立联系的主要方式是不公平的。

我对人际关系类的话题，其实并没有想要去回应的欲望，尽管我时不时叭叭叭说一大堆。人际关系永远是他人自己的问题，不是我的。但我依然可以说一些无聊的事情。

讨论期间，有参与者认为只要双方自愿且诉求透明，这就只是一场公平的交易，即用 自由市场资本主义 的逻辑来合理化这种行为。

不过当两个国家之间存在巨大的经济断层时，弱势一方做出的「自愿」选择，本质往往是基于生存压力或阶级跃升的渴望，是由环境倒逼出来的。

这也是为什么这种关系被认为不可持续 —— 因为关系的基础完全建立在资源依赖上。只要资源没了，或者弱势一方获得了独立的生存能力，关系便会立刻消失。

令我觉得滑稽的，是有人认为 Passport Bro 的行为可以重新分配财富，避免财富都集中在富人身上。

首先，跨国婚姻根本无法改变目标国家的贫困，只是将 涓滴效应 极其粗暴地应用到了婚姻市场上 —— 涓滴效应主张政策应当优先给予富人或大企业财富上的优待，因为这些位于金字塔顶端的群体会让财富像水滴一样逐渐向下渗透，最终惠及底层的普通劳动者。该效应理应是宏观经济学概念，却被这个人放到了微观、局限于被选中的特定家庭上。它不会转化为目标国家的基础设施建设、教育投资或产业升级，也无法创造出任何健康的、可自我维持的经济循环。真的会有人认为几个外籍人士过来娶妻生子，就能解决国家的系统性贫困吗？享福的仅仅是被选中的女性以及她们的家庭成员，而已！

或许有人注意到，我使用了「女性」这个词，意味着我默认这种有争议的行为是「外籍男性娶他国女性」。莫要着急，「外籍女性娶他国男性」的很快就要来了：学术界将其称为 Romance Tourism，即「浪漫旅游」。怎么男性的跨国寻欢如此饱受争议，女性的就成了「浪漫旅游」？两者在社会叙事上就被包装得不同。前者是商品化的，而后者是浪漫化的，不过底层逻辑都是发达国家公民利用经济优势在发展中国家进行性资源消费。

三、竞技编程和竞技数学的价值

该参与者曾是一次全国数学竞赛的冠军。他讲话咬字很清晰，但是语速极快，导致听不清楚。为了更具象地形容给我，室友说他讲话就像《初音未来的消失》。我说，初音未来咬字就很清晰，语速也可以很快，那他四舍五入也可以是初音未来真人。

好吧，我对竞技编程和竞技数学不感兴趣，自然也不会对他提出的话题感兴趣：竞技编程和竞技数学能让你更擅长研究性思维。

说实话，这也不是感不感兴趣的问题了，而是整个话题和讨论都无聊至极 —— 多数参与者都是软件工程师或者数据科学家，也就是理工科背景或者此类技能的受益者，那么他们又怎么会提出有趣的反驳呢？

我有时候会钻牛角尖，拆解大家说的词汇到底是什么意思。这个「研究性思维」便被我盯上了。研究性思维通常而言会被核心在于对抗未知和不确定性。如果是这个定义的话，提出方的逻辑就有问题，因为竞技类项目的本质是在极度确定的规则和边界内寻求最优解，训练的也是解题思维而非找题思维。

但根据提出方所说，他实际上想要表达的意思是「面对核心技术瓶颈时的逻辑突围」，那么他的逻辑在该框架下是成立的。不过这偷换了概念，在真正的科学研究中，最漫长的往往是定义问题的阶段。更何况，竞技类技能到底能否成功迁移到另一个领域，都是个值得探究的问题 —— 你要如何证明你刷题时学到的东西，放在现实中的项目中就有决定性的帮助？

另一个让我心觉无聊的是，这个观点深究下去，底层逻辑不过就是「付出特定努力就会获得特定能力」，是一句绝对正确的废话。事实是，你高强度重复做什么，都会让你擅长一种能力。这有什么好反对的呢？谁会不想要自己什么都擅长？该观点从一开始就失去了可证伪性啊。

既然如此，为什么大家没有成为全知全能的呢？那当然是因为成本了。为了在竞技编程和竞技数学的领域中达到顶尖水平，一个人必须投入常人难以想象的时间和精力。沉没成本如此庞大，意味着他在同一时间段内必须放弃对其他维度能力的探索 —— 人的精力终究是有限的。

四、又是话疗

该参与者的原话我认为说得很棒，所以打算直接照抄下来 —— 肯定不是我懒得总结：

我有三个核心观点，我想挑一个来讲。当我们感到悲伤或迷失的时候，本能地会寻求验证和出路。天主教徒去告解、印度人拜访瑜伽修行者、非洲女孩找巫医…… 而现代人，我们有「心理治疗师」。治疗很贵，但它真的值这个价吗？我的基本观点是：不一定。现代治疗师并不比过去的巫医、长辈或者睿智的朋友更有效。
我认为治疗的效用主要源于情感支持、实用建议和问责机制，而这些原本是正常人际关系，如父母、导师，中该有的。但现在的社会，建立这种关系变得越来越难，于是我们将原本属于人类自然体验的部分「拆分」出来，以每小时几百美元的价格打包出售。
支持我的理由有三点：
一、不同流派的疗法，如认知行为疗法（CBT）、心理动力学等，在统计学上的有效性几乎没有差异；
二、治疗师的水平并不一定随着年龄、经验或专业培训而显著提升；
三、拥有一段真正的友谊对生活的改善，几乎等同于接受治疗。

这个观点对比上一个，争议性多了些。这和参与者们的专业以及职位有所关联：有一部分是理工科背景，有一部分是心理学背景，且话疗要比竞技编程和竞技数学常见许多，谁都可以说上几句。

那我就根据提出来的三个点的顺序，来整理讨论中的想法吧。

在专业层面上，有个准精神科医生提出了异议：不同流派的系统化学习是「表演性」的这一点并不准确。特定的心理障碍需要特定的方法，比如针对边缘型人格障碍的辩证行为疗法、针对高理性的人的哲学思辨式流派、针对接地气的人的认知行为疗法等等。虽然医患之间的信任关系才是最重要的，但针对性流派的科学性依然存在。

好吧这里出现了很多术语。简单来说，他的核心意思是「对症下药」。这位准医生的反驳确实为不同治疗流派的科学性保留了尊严，证明了它们并非纯粹的表演。但这并没有解答原观点的后两层质疑：治疗师的个人水平差异，以及最核心的，治疗本身是否正在异化人类自然的社交连接。

那么，治疗是否正在逐步代替友谊？这和第一个观点中，有家长想要通过花钱来外包教育孩子是不谋而合的。治疗本质上也是交易性的，而这个特质是个双刃剑：你可以毫无心理负担地向治疗师只谈论自己，不用担心对方会因为你的黑暗面而过度焦虑或带有偏见。

但这在现实中并不正确，不负责任和不专业的治疗师就会对你指手画脚。这也就是整个观点的第二点，治疗师的水平问题。

况且，能够向朋友坦白自己的不好的一面，不才是健康的友谊该有的吗？无法对身边的人敞开心扉，这件事本身才是该解决的问题，寻找治疗师不过是其替补方案。

有位参与者补充了一点：去治疗的人必须想要好起来才行。现实中有些人就是沉溺于痛苦，他们找治疗师或者朋友只是为了抱怨。

这不经意让我想到曾刚读了 Alfred Adler 的《被讨厌的勇气》的朋友，大放厥词认为陷于心理痛苦中的其他朋友们是甘愿沉浸在痛苦当中，以至于我有段时间对 Adler 以及他的书籍有些不好的印象。

道理是看上下文的，给每个道理加上对应的上下文的话，所有道理都是正确的。但将道理套在所有人事物上，就有可能导致更多的痛苦。我精神状态很差的那段时间，很需要他人的帮助和支持。如果有人过来说我是活该、自愿沉浸去做个受害者，那我拿着刀捅死那个人然后自尽的 —— 当然是开玩笑的，因为确实有人这么说过我，而我并没有拿刀捅他。

在阅读了《不原谅也没关系》后，我的精神状态很快从抑郁的，变成易哭的，再变成释然的 —— 又或者是麻木的？谁知道呢 —— 因为我那时候需要的就是那样的观点。精神恢复正常后再去看 Adler 的观点，能理解他想要激发人类的主动性，但也能理解把这种道理讲给一些确诊了精神疾病的朋友们，只会伤害到对方。

五、资本主义与社会主义的平衡

提出者认为，资本主义是世界的自然状态 —— 因为资本主义的竞争机制最接近于生物学意义上的 社会达尔文主义 和 Thomas Hobbes 提出的自然状态，即弱肉强食、适者生存的原始丛林法则 —— 但社会主义不是。然而，健康的资本主义系统必须依赖社会主义原则来维持运转，任何单一的纯粹制度都无法让社会保持稳定。

作为例子，没有现代医学的原始时代，人类虽然完全顺应自然，但往往寿命很短；资本主义就是这种纯粹的自然环境，通过适者生存的法则提供内在激励。而社会主义像是现代医学，比如福利制度，介入并纠正了自然状态下的残酷，确保社会中的个体不会因为生病或贫穷而轻易衰亡。

但如果将现代医学推向极端，例如开始克隆人类了，那伦理危机就会被引发。因此，提出方认为政府应当用社会主义的政策药物来维持资本主义肌体的健康。

我完全不认同整个观点的大前提，也就是「资本主义等同于原始丛林法则」。真正的资本主义有个核心前提：受法律保护的私有产权。在没有规则的原始状态下，最强者可以直接暴力抢夺他人的资源，这属于封建强权。资本主义无论如何都是相对现代、被精心设计出来的系统，依赖于国家机器来保护私有财产并维持自由市场的秩序。

再就是有参与者提到，如果观察过去的原始人，会发现小型部落中，由于没有剩余财富的积累，社会呈现出的是高度的平均主义：食物共享、共同抚养后代；没有财产私有制，也就没有资本主义。自然而然便破解掉了「资本主义是世界的自然状态」这一点。反而是日后人口膨胀、物资变多了，资本主义才形成。

不过思考尚未停止，如果在逻辑推演上再下沉一层，就会想到：现代人类社会的制度能套用生物学和进化论的理论吗？

是，自然界确实存在弱肉强食，但那是为了基因延续和获取卡路里的物理法则 —— 狮子捕杀斑马，吃饱后便会停止，而不是建立斑马养殖场、发行什么「斑马肉期货」来剥削其他狮子的劳动剩余价值。资本主义的本质，并不单单是私有产权，还包含了信用扩张、跨期资源错配、资本的复利增长…… 归根结底，都是人类想出来的虚构概念。

原始社会的食物共享和共同抚养，同理，也仅仅是特定环境下生存策略的一种，并不能等同于任何现代经济制度。

想到这些，再去思考提出者提到的和社会主义有关的观点，就会发现一切都不成立：资本主义和社会主义都是现代社会的补丁；用克隆人带来的伦理危机来警告社会主义的极端化更是犯了滑坡谬误。

六、AI 取代工作

我希望所有类似的活动，都可以将 AI 相关的话题 ban 掉！

从 2023 年 ChatGPT 横空出世以来，AI 就是个大家都在聊的事情。讨论当下的事情没什么不好，只是它被讨论了太多次，人们提出了无数个不同方向的观点，现在已经很难去辨别你的观点是否是你自己的，还是你从别处继承来的。

不过，该评论还是要评论的。提出者认为，关于「AI 将取代所有人的工作」或者「AI 会毁灭全人类」的说法纯属炒作。作为一名软件工程师，他认为 AI 仅仅擅长于处理训练数据中存在的事情，本质上不过是个高级的自动打字工具。

反驳中，有人提到 Archive 上的一篇论文：AI 能够解决非平凡的数学问题，而且这些问题并不在训练数据中。数学家 Tim Gowers 声称 AI 使用了非显而易见的技巧。

实话说，我不清楚他具体说的是哪篇论文，因为我就没有阅读论文的习惯和耐力。不过明说的 Tim Gowers，我还是查到了他当时具体说的是什么：他让 GPT-5 去解一道题，而 GPT-5 使用了 Kolmogorov-Riesz 引理（而我对此自然是一无所知了），也是他最初并未想到的。但这无法证明 AI 使用了不在训练数据中的内容，这只能证明 GPT-5 在数学方面上有过广泛的训练。

为了进一步捍卫自己的观点，提出者又说，AI 完全不知道人类是如何在三维空间中使用物体的，所以它给出的产品设计很糟糕 —— 但这不是因为模型本身并不具备「看见」的能力么？收集数据也好，开发外部的 3D 软件接口也好，和模型本身的推理能力并不在同个层级上吧。

随后讨论出现了目前更为常见的妥协派观点：AI 会让一部分工作消失的同时创造更多的工作。

指出这一点的人说，「虽然确实有人被取代了，但在大量引入 AI 的领域，工作岗位的总数实际上是在增长的。」

另一个人补充道，这是杰文斯悖论：当某种东西太贵时，大多数人不买；但随着成本降低，需求就会增加。这意味着以前很多公司雇不起整个软件开发团队，但现在有了 AI，软件开发成本降低了，他们反而就可以雇佣更多工程师了 —— 吗？

杰文斯悖论最初是用来描述煤炭这种大宗商品（指同质化、被广泛作为工业基础原材料的商品）的：燃烧效率提高会导致煤炭的成本下降，进而引发蒸汽机的广泛应用，最终增加了煤炭的总消耗量。

但软件代码不是煤炭。代码是用来处理系统复杂性的工具。AI 降低了编写单行代码的成本，软件的总生成量也会呈指数级爆炸开来。但这并不意味着企业会按照同等比例增加人类程序员。因为在这个新结构中，瓶颈已经从「代码的生产」转移到了「代码的验证、集成与需求定义」。

底层码农被淘汰，这一大方向不假，但站在更高级、抽象一层的系统级工程师，可不见得企业就需要更多。

在完全由人类编写代码的时代，由于前期生产代码的成本极高，后续的重构和清理屎山代码虽然痛苦，但往往比彻底推翻重写要划算（像 QQ 这种烂东西就除外），因此产业内确实存在大量专门维护旧代码的岗位。

然而，当 AI 将生成代码的边际成本无限压倒接近于零时，代码的属性就发生了根本性的翻转：原本人类是一个个写屎山代码，现在 AI 是以光才能有的速度拉出屎山代码，谁维护谁就乐着去吧，这根本就是 廉价的一次性消耗品。

让人类去梳理 AI 生成出来的代码逻辑，时间成本和认知损耗远高于重写。那还不如直接抛弃无法通过测试，或者充满冗余的模块，转而修改更高层的约束条件、逻辑提示、架构框架…… 以此让 AI 重新生成一个全新的模块。

所以人类向更高的抽象层级转移，是不可避免的，因为底层的 AI 代码本质上就是不可读的债务屎山。如果一家公司真的陷入了需要雇佣大量人类程序员，去手工清理 AI 生成的闭源屎山代码的泥潭，那相当于既承受了 AI 逻辑不严谨的试错成本，又要承担人类工程师高昂的雇佣成本，那最开始为什么要引入 AI 编程哩？

这就引出了讨论中的最后一个切入点。他们提到目前的经济「供过于求」是因为疫情期间的过度招聘。这让我不得不去面对一直以来都不愿意去思考的问题：计算机软件的工作，到底算不算工作？我们去做的那些开源、自由的项目，哺养了 AI，使其淘汰掉了底层的工作。这也是人们常常在说的「程序员创造了留给自己的上吊绳」。但如果，这类工作其实从最开始就行不通呢？

AI 不过是用来背锅的，程序员们写的无数代码仅仅只是负债 —— 该观点出自于 Cory Doctorow，详情见这个演讲。闭源的代码越多，需要背负的维护债务也越重，因此开源代码才是未来 —— 那便意味着现在绝大多数的公司，走的都是错误的道路？因为他们的软件是闭源的。而开源商业软件，是让代码交给了世界上任何一位程序员，或者说编程 geek 们。如果这样，公司里还需要那么多程序员么？

我问了许多问题，但我不会就这样把问题放在这儿，留给你们。因为这显然是个未来我必须去面对的问题：我喜欢的开源和自由软件，到底是不是无法买饭给我吃，也是不是杀死无数程序员的推进器之一？

先说「开源软件」，也是更广为熟络的概念：它可以创造，且创造了极其庞大的商业价值。但这些价值，并没有分配给写代码的开源贡献者，而是被提供基础设施的科技巨头收割了。

先前已经说过，每一行代码都是未来的维护债务，那么一家理性的商业公司最该做的事情，自然便是尽可能地将这些债务甩给外部。这也是为什么常被自由的极客们称为「邪恶」的 Google、Microsoft、Meta 等等，会开源他们底层的框架，比如 Kubernetes、React、PyTorch。

他们当然不是来做慈善的。通过开源，大公司将原本需要内部支付高昂薪水才能维持的代码审查、Bug 修复和功能迭代工作，免费外包给了全世界充满热情的极客和理想主义者们。就他们而言，「自由与开源」的想法是被利用的，让无数程序员心甘情愿地为他们打无偿的工，从而极大压缩了自身的研发和维护负债。

那么钱被谁赚走了？被掌握计算资源和分发渠道的人赚走了。开源协议，如 MIT 或者 Apache，保证了代码可以被自由使用，这也就意味着 AWS、阿里云等这样的云厂商，可以直接将全世界最优秀的开源数据库、中间件打包成 SaaS 售卖。在这个环节中，云厂商卖的根本不是代码，而是「免除部署和维护痛苦的服务」。

「自由软件」这一意识形态，实际上要早于「开源软件」。二者区别在于，前者能够通过 GPL 这样的协议，摧毁企业通过闭源形成的技术垄断，以及售卖专有软件拷贝的传统盈利路径。为了彻底规避 GPL 协议带来的风险，资本发明了「开源软件」这一套全新的叙事。MIT、Apache、BSD 这些被开源运动大力推崇的宽容型许可协议，允许商业公司拿走社区的开源代码、随意修改，然后直接闭源打包成自己的商业产品进行售卖，且无需将修改后的代码回馈给社区。

所以说，二者在意图上就不同：自由软件运动是社会学和伦理学运动，试图让代码脱离资本的私有化控制；开源运动是商业方法论的迭代，主要将开放协作的成果嵌入到资本的全球供应链中。

那么自由软件到底能不能赚钱？我们必须转移现有的商业逻辑：已知，代码本身无法被垄断和售卖，那就需要去售卖围绕代码产生的稀缺物。而在现代的商业环境中，这种稀缺物有三种形态：

一、售卖「免责声明和兜底服务」。参考 Red Hat。对于大型企业而言，免费的开源软件其实是最昂贵的，因为没有人会负责突如其来的崩溃，以及直接导致的业务停摆的损失。Red Hat 就是来接锅并解决问题的。

二、售卖「便利性与基础设施」。正如之前提到的云厂商逻辑，大多数中小型企业根本没有能力，也没有意愿去自己部署、配置和维护复杂的自由软件集群。商业公司，比方说 WordPress.com，就会将自由软件打包，搭建在自己的服务器上，并配置好一切。用户订阅的并非软件的使用费，而是服务器的电费、带宽费、一键开箱即用的便利费……

三、售卖「企业级的制度摩擦力」，AKA 开放核心或双重授权模式。软件的核心功能是完全自由免费的，足以吸引全世界的极客和个人开发者去使用并形成生态。但是，一旦软件被用在大公司的企业环境中，那些专门针对大公司合规性要求开发的功能，比如 SSO，就会被严格闭源并收取许可费。

知道了这些后，就会发现，真正能够带来丰厚利润的环节，早已脱离了「写代码」这一纯粹的创造性行为。没办法啊，资本市场根本不为「优雅」买单。

这倒也解释了为什么 AI 的出现是历史的必然。如果资本的最终目的是将写代码的边际成本无限压缩，并将所有的技术负债甩脱，那么 AI 就是他们梦寐以求的终极开源劳动力 Pro Max。因为 AI 可不需要休息，不会被开源精神感召，也不会为了代码的自由与巨头抗争啊。赚不到钱的不是自由软件，而是那个只想躲在屏幕后、指望靠纯粹的极客理想和一行行开源代码就能体面生存的黑客 —— 我们！

七、放弃宗教中的形而上学与来世观

提出者是一位前科普特基督徒。小的时候，即使家里人都住在纽约上州，离教堂有一小时的车程，他们也会每周去三次。因此，他小时候便被灌输了「死后会在天堂或者地狱度过永生」的观念，并将其视为理解现实的基石。

尽管他之后不再信仰死后的世界，但他紧接着陷入到了荒诞主义的困境中：我和其他人死后，可能什么都不会发生。也就是说做什么都没有意义，反正一切都不重要。

提出者引用了 Marx 曾说过的，宗教不过是精神的鸦片，带来的幻觉虽能缓解现实的痛苦，但也消解了人们改变现实的动力。因为对天堂的期盼、圣经里教诲的「要把财富积攒在天上」，在逻辑上导致了对现实生活的消极妥协。

宗教，特别是关注来世的宗教，在根本上是「否定生命的」。这是典型的尼采哲学观点，即认为将价值寄托于死后的彼岸世界，本质上是对现世肉体和真实生命的贬低 ——「上帝已死」在这里，被提出者用来指代「随着现代认知的发展，传统的形而上学和客观道德体系已经崩塌」。

小标题和刚才都提到了「形而上学」。以防万一有读者不清楚这是什么 —— 毕竟不是所有人都有精力学习哲学，你说对吧，竞技编程和竞技数学 —— 这是古希腊时期，研究「存在」和「事物本质」的学问。不过在本次的对话中，形而上学指的是那些超越物理经验、无法被科学证伪的假设，例如死后的天堂与地狱、神的存在，以及对话中提到的宇宙终极意识。

说了这么多，提出者的观点是什么呢？他认为既然无法触及到客观的形而上学现实，那不如直接去接受宇宙的混乱，利用人自身的主观体验去赋予当下生活的价值，而不是依赖虚构的来世承诺。

为了做到这一点，提出者提议将冥想和祈祷等行为，从神学框架中剥离出来。现代神经科学已经证实了正念冥想可以改变大脑的神经可塑性，因为它们触发了特定的心理和神经机制，而不是因为有神明在倾听。因此，人类可以继续保留这些有益的实践，但不需要相信其背后的超自然解释。

说完提出者的主张，再来听听其他参与者们的想法吧。

首先是一个相当经典的逻辑反驳：如果宗教是适应不良的，为什么它会出现在几乎所有的人类历史中？确实，宗教在早期人类社会中具有极高的生存适应价值，因为它提供了超自然惩罚的约束，促进了大规模的社会协作。提出者的回应是，在拥有了科学体系的未来后，这种依赖来世驱动的机制将不再是最优解。

其次是 Jonathan Haidt 的观点：人类进化出了围绕「神圣事物」聚集的本能。这解释了世俗化带来的副作用。当宗教机构衰退后，人类失去了每周定期聚集、建立社区纽带的物理和精神场所。如果抽离了共同的形而上学信仰，社会会面临如何重新构建群体凝聚力的现实难题。

最后是将「期盼天堂」解构为人类普遍的心理防御机制。在心理学中，人类常常为了逃避当下的困难，而将希望寄托于未来，例如「等我做完这件事，我就去告白！」。来世的概念被视作这种心理模式在宏观尺度上的体现，因为它为人类面对死亡恐惧和现世困境提供了一个逃避出口。

和人际关系一样，虽然我对宗教话题有着主观上的意见，但我其实也不爱讨论它。因为它是个非常主观的概念，讨论与否都极度依赖于当事人的情况。每个人眼中的宗教都各不相同。我们仅能分享看到了什么样的杨桃，但也无法就「杨桃到底是什么形状」来争个高低 —— 咋，我看到的五角星形状，就不是杨桃的形状了么？

比方说去评论「宗教是精神鸦片」这件事，我无法去否认宗教确实对于痛苦的人们而言，是止痛药。没有改变导致痛苦的现实物质条件之前，人不吃止痛药，只会被痛死，而不是觉醒。用科学替代宗教，听上去容易做起来难：你要如何保证你不是在拜一尊名为「科学」的偶像呢？

宗教好用就好用在，人们可以将无法承受的焦虑和责任外包给一个全能的实体。因为世俗的正念冥想，要求个体在内部消化这些焦虑，意味着该个体必须足够强大 —— 世上没有那么多强大的人，但就算是弱小的人，他们也是人。有这种可以推卸掉一切责任的心理释然，我不认为是件坏事。

再就是科学和宗教，并不是彼此的对立面啊。怎么可能互相平替生态位呢？

唯一值得担忧的是宗教的权力结构。当一种宗教的主张开始干预世俗法律、定义何为罪恶、甚至指导资源分配时，它就变成了一个拥有绝对质量的客观社会实体。这是因为宗教的底层架构建立在「神圣启示」和「不可篡改的绝对真理」之上，而人们没有实证数据去反驳一句「这是神的旨意」。

我对本期的看法

尽管我巴啦巴啦说了一大堆，但我实际上对这一期的讨论并不是特别满意。因为参与者的多数观点并没有完美地满足这些条件：

拥有真正的观点，而不是重复的、继承来的，而是经过深思熟虑的、思考过的、检验过的、真实经历得出的、真正相信且能够捍卫的
不要将个人恩怨包装成深刻的见解

或者更简单来说，许多观点不够「不受欢迎」，不够具备争议性。如果一个观点是大家听了就会想要快速赞同的，这和车轱辘话没有什么区别。讨论出自于争议，不论是出于自保还是什么理由，而决定不提出内心中那些不被欢迎的想法，那你就不应该出现在这场活动里。

这和访问个人博客时，近乎一定会看到的「博客是写给谁」这个主题一样：博客是写给自己的，还是写给他人的？我实际上对这个话题没有太久的思考，因为我最开始就认定了博客是写给自己的。观众可是雪山上的一百万条狐狸，以及你要喂给狐狸的酱板鸭、牛肉面、意大利面、鸳鸯锅…… 为了满足所有人的需求，避免被化身成人形的狐狸、酱板鸭、牛肉面、意大利面、鸳鸯锅…… 追杀，几乎是不可能的。

「雪山上的狐狸」这个笑话出自于近期的邵氏武侠 AI 二创视频……

况且这种写法相当无趣。上篇文章里我引用了 Spike 的 Zine，但是忘记引用原作者的文章了：少使用无用的、谨慎的短语，这会让你的观点变得无聊、没有争议性，自然而然也没有人想要就此进行例如反驳这样的进一步讨论。

惊喜的是，在我那篇文章发布之后，Spike 对这个观点进行了更深一步的扩展。他在这篇文章中分享了作家三毛的《学期作业报告》。从批注中能看出三毛的观点很犀利，以及主观性很强。比方说学生宋平在作业开头简单地说了说自己对庄子的看法，短短两句话便被三毛批评了没有理解庄子哲学的核心 —— 不过可惜的是，我并没有读过老子、庄子的作品，目前也只是在缓慢学习中国文学，也就无法展开说说了。

这个报告中，三毛说「主观总比无观来得好」。什么是「无观」？没有想法的人自然是无观的，观点的搬运者则是更隐蔽的无观者 —— 他们将别人的观点，未经任何思想上的处理，便打包成了自己的观点。「那些不受欢迎的想法」活动，本意是拒绝这些无观者，但每次翻阅记录，只能感受到观点们停留在了表面，亦或者根本违反了活动的规则。

我来，是为了吸取他人的独特想法，并将其进行对抗、最终得出一个属于自己的见解。而不是花费数个小时翻阅记录，来听这些泛泛其词的！

和朋友讨论这件事的时候，我得出了这样的结论：参与者第一次参加，也有可能是最后一次参加，那更有可能分享的是他们认为的，表面上的自己。这是保护机制，大多数人们都会认为自己内心深处的「不受欢迎」的想法是具有争议性，且对它被质疑一事透露出脆弱的一面，自然也不会选择在一帮陌生人面前说出它们。

好吧，但大家来参与这种活动，不正是为了接触到有争议性的想法，并与他人的思想进行碰撞么？这又回到了我刚说的，我想听到争论，不是大家都赞同的事情。

三毛接下来又指出：「太多『也许』『也许』，『不知道』又『还是不知道』，现在又出来了个『好像』。你大概十分安然于不确知的事情，是不是？」她在批评宋平时，自己也用了个「大概」。看上去好似在犯自己刚说的错，实则让听者清楚得很 ——「我要表达的是这个，我认为这个就是对的，你听上去也会觉得我是这个意思，所以根本不需要多余的、『谨慎』的语言。」

现在我终于理解小学时，语文老师在我的一篇日记上写的评语是什么意思了。那时我写，「今天是阴天，我讨厌阴天！」而语文老师评「阴天很正常！」死脑筋儿的我一直认为这是老师的多管闲事。阴天正常又如何？我不喜欢就是不喜欢啊。但是写作就应该清楚、清晰：为什么讨厌阴天？具体是阴天的什么让我如此厌恶？

表述观点、服务客人也是一样的：把脑子里想到的东西统统说明白。有些东西你不说，对方是不知道的。这里提到「服务客人」是因为，我最近换了个服务生的兼职，学习了一些「待客之道」，例如要和客人说明白自己做一些事的原因是什么，否则客人不明白，还会产生不必要的误会。这些原因又往往都是善意的，例如为了他们吃饭方便，带去刀叉，放下时可以解释一下为什么自己带来了刀叉、客人可以用刀叉干什么。听到这些解释，客人不会觉得有什么不好，反而是什么都不说，才会让他们遐想。

再就是谨慎的语言，会让听者质疑你到底信不信任你的观点。如果提出者都不信任自己提出的观点，那讨论下去还有什么意义呢？你也不过只是个观点的搬运者，怕是根本不理解它吧。在宋平使用了「绝对」二字后，三毛高兴地写道：「『绝对』两字终于出来了，你自己看见了吗？终于肯定了自己的眼光和看法，好。」且三毛发现，宋平在聊电影时不仅越说越有自信，谨慎的语言越来越少，说得又好又有自己的见解，和前几个部分的内容截然不同 —— 是啊，只有在你说一件自己真正相信、认同、喜爱的事情，你才会说得自信、吸引人继续看下去。而不确信的、不自信的文字，只会让人心想不够好、不够有说服力。

活动的参与者们在发言时，也使用了大量的谨慎的语言。「我认为」「应该」「我猜」…… 数不胜数。英语使用者们有一个不好的习惯，我想要特地指出来，那就是在口头上大量地使用 uh、like 和莫名奇妙的形容词，例如 literally、basically，好似没了它们就没法说话一样。这些习惯难以纠正，因为我也会这么说。它是大脑还没想明白接下来要说什么时、嘴巴先占了位的习惯。大量使用这些 filler words，会让自己的口语水平下降，且极度依赖这些模糊的说法，而不是准确的词汇。我推荐的方法是，直接不说话，让自己的脑子慢慢跟上，为此说话语速慢一些也没有关系。

那么参与者们到底是对自己的观点没有信心呢，还是单纯讲话依赖于 filler words 呢？我不得而知，但是听上去都会有「说者不够确信自己在说什么」的意思在。

顺带一提，这是我第一次阅读三毛的作品，虽然仅是批改学生的作业，但将自己的性格显露得活灵活现。例如宋平说自己「难过死了」，三毛紧跟着写了句「可爱的孩子，可以难过，不要死，比较仍能更爱载湉，不死好不好？」一个报告里竟能出现两个可爱的人！

没有情人的情人节

2026-03-15T04:00:00.000Z

室友上个月主持的活动里，我忘了说一个话题。不过正好也可以借此说一些我的观点。活动那天是情人节，而提出者说：「人们不需要恋爱关系。」

提出者会提出这么有争议性的话题，很有这个人的风格。这个观点也是他常常挂在嘴边的，就我看来更像是一种警戒 —— 谁知道呢？因为本文的主角并不是他，我就不深入他的情况了，只会简单解释一下他的观点。

顺带一提，我在阅读 Spike 最新出炉的 Zine 的时候（我好想念这个系列），看到了这句话：

我过去使用了太多的限定词和冗长的短语。那是我口语的直接翻译，事实证明，这是一个糟糕的写作策略。如果你的目标是让别人阅读 ⸺ 并且希望他们喜欢 ⸺ 你的文字，你应该努力编辑你的想法。
以下是我当时几乎在每个句子开头或结尾都会添加的无用短语样例：
我认为……
我觉得……
我相信……
对我而言，……
感觉就像……
似乎……
在我看来……
刚开始写作时，这是我的最坏习惯。这种废话只会让读者疲惫不堪。在观点文章中任何地方加上「我认为」都是多余的。
使用这种「谨慎」的语言只会让你的观点变得软弱无力，以至于无法引起争论。如果你用「我觉得……」开头，那么后面说的任何话都没人能反驳，因为这只是你的感受。读起来实在乏味。

说得真好！好的想法可以立即让人反思自己。所以我之后会很少使用这类短语。这意味着我的文字会听上去像是在陈述事实，但并不是这样，一切都是观点。或许是时候该写一个 /glossary 页面了。在 Eltrac 提出这个概念的时候，我就有考虑去写，但一直拖延没有这么做。

回到正文吧。

提出方的观点在于，人类需要物理接触，这包括拥抱和抚摸。但在众多文化中，异性 —— 或者同性，如果对方将同性恋放在眼里的话 —— 之间做这些行为会被认为是浪漫的，从而认为只有恋人可以做这些。如果可以随意在物理上接触他人，或许许多恋情也没必要存在了。

这么说的原因在于，许多恋情的本质其实仅仅是「连接」。人们渴望陪伴，只是单纯地想和某个人多待在一起。但在有限的社会标签下，人们往往会误将这种对深度连接的渴望认作是「恋爱」。为了合理化这种物理和时间上的亲近，他们选择了「在一起」，误以为这就是爱情，随后便无可避免地被卷入了以「结婚」为最终目的的传统轨道。

恋爱实在是个过于复杂的话题。人们到底渴望从恋情中获取到什么？是理解吗？是关怀吗？还是性需求？貌似除了性，朋友们也可以提供这些东西。当然你要是个愿意找炮友的人，那性需求也可以被满足。

然而，社会将恋爱美化得太严重了，好像没了它，人就是不完整的，是失败的。

朋友甲说的「恋爱关系」，其实可以看出来，专指被社会标签化过后的「恋爱关系」：人们以结婚为目的，决定一辈子都要在一起后，怀孕生子、将两个家庭融合在一起，度过标准的一生。

结婚是我和朋友们最讨厌的概念之一。比如朋友甲，因为是个法律脑袋儿，所以他认为婚姻的重点在于「共享资产」。他不相信婚姻的契约，认为那只是将二人强行绑定在一起的说辞 —— 毕竟如果有心的话，二人不结婚也可以一直在一起。又由于他是个不喜欢遵守「社会规则」的人，「不结婚生子不行」的观念在他这里也行不通：老了可以花钱请护工，怕护工欺负自己那就培养类似于徒弟或者养子或者信徒 —— 他有信心做到这一点。只要有钱和人格魅力，就可以规避通常人会认为只有结婚生子才能做到的事情。既然如此，为什么要花费精力和人进入恋爱关系，然后将自己的生活搞得一塌糊涂呢？

传统婚姻或深度恋爱关系之所以成为主流，很大程度上是因为它是一种打包方案。人们将情感支持、生理需求、经济合作甚至养老保障全部集中在同一个人身上。这种做法降低了前期的交易成本和维护难度，但假设伴侣变质或背叛，个体的整个生活运转就会面临全面瘫痪，这也是为什么朋友甲选择不进入打包关系，而是将需求分散给不同的关系，例如朋友。

值得说明的是，他并不否认人类渴望且需要亲密关系这一事实。他真正反对的，是将「亲密关系」与被社会标签化的「浪漫关系」强行画上等号。深度的友谊同样可以通过长期的摩擦建立起坚韧的羁绊，提供不可替代的情感支撑与连接感。既然亲密并不专属、也不必然导向爱情，这一切就完全可以在剥离了恋爱与婚姻的传统叙事后独立存在。

当然也有另一部分参与者不认同这个观点：爱情就是人生中不可缺失的一环。亲情要，友情要，爱情也要，这才是健全的人生啊。况且能够亲密地抚摸对方，不道德、不知羞耻！

朋友甲所反对的人生并不是错的，我也不觉得他推崇的人生是所有人都能做到的。但「标准的人生方式」早就应当不再成为任何人的束缚。我已经看到过太多，为了「普通」和「正常」而强行过上这种生活的人，他们的人生是如何被一步步毁掉的。如此之多的案例，不得不让我去思考这种生活形式的正确性 —— 说不定，它其实已经不适用于现在的人们了。

三月份的「那些不受欢迎的想法」活动会照常举行，我依然没有打算出席，自然也不清楚这次都有什么有趣的想法被抛出。不过我知道其中一个人（朋友乙）的话题，这和 momentum 有关。中文翻译过来叫作「动量」，也就是物理学中常说的牛顿第二定律。如果用大辞泉词典去查这个词的话，会发现它在日本还有个意思：惰性。

过去的一切，社会的规矩和经验，都形成了庞大的动量，在人准备前进时，推动着人。你会被推进得很快，人生也会看上去顺利起来，但这不是你的力量，这是惰性。你只是又一次遵循了前人的脚步，走在已经踩平的路上。这时候，再有人想去走隔壁的草丛，想必都会被认为是个怪胎吧。

朋友乙说，这个世上到处都是受动量驱使的人们。过去我从社交网络上听到过一个类似的概念，叫作「空心人」。这种人对于事情的看法只有一个标准，那便是他们认为的社会标准：「普通人不会这么做」、「普通人应该这么做」。事实是，世上没有「普通」，只有「普遍」，而「普遍」不等同于「正确」。

自然，「空心人」这个概念实在是过分傲慢了，毕竟不能因为对方做的事情和你不同，就如此贬低对方吧。但这也让我思考，人们做一件件普遍的事情是为了「正确」，还是为了随波逐流？说到底，究竟有多少人知道自己现在在做的事情，是出于自己想这么做，还是认为自己应该这么做呢？要知道，被无数人追捧的标准人生，从来都不是为了确保每个个体的幸福而设计的。

我有一位有些讨人厌的朋友丙，在和朋友甲或者朋友乙接触时，喜欢说这句话：But it's not normal. 但问他什么是 normal 的话，他也答不上来。毕竟 normal 就没有一个准确的定义，它是一种被无数人臆想出来的存在，是主观的集合体。你就算过得不是个 normal 的人生，你也不会死。虽然会受到社会部分人的谴责，但也会有另一部分支持这种生活习惯的人在。如果不想要去能够容纳自己的群体中生活，转而改变自己的生活方式，从而获得已在群体的支持，亦或者根本不去考虑这种事情 —— 这不就是具有毁灭性的惰性吗？

情人节到底该不该有情人？有多少情人又是包装成「情侣」的朋友呢？看来我的问题太多了。

奶茶店毕业

2026-03-14T04:00:00.000Z

早在第一篇月刊里，我就说过去年八月份我找了份兼职，主要是得快速还笔钱。这一做就是半年，而在二月份我提了离职、逃跑了。

先从最开始说起吧。当时我的银行账户已经支撑不起我日常的吃喝拉撒了。就算是和室友合租，有父母给的几百块生活费，不欠钱活下去依然很难。不得已，我只能将开发项目的时间分出来，花费在打工上 —— 那会儿连公司都没有被注册，项目跟个人项目没有什么区别，更别说赚钱了。

粉领工作虽然赚得不多，但胜在成本低，不需要培训很久就能上岗工作。尤其是我在大一时就做过奶茶店的兼职，去新的店里工作学习很快。于是我在网上找各个招人的店，一个个联系过去 —— 有些人无视了我，有些人问了我点问题后就不回我了… 最后只有家附近的一家本地知名奶茶品牌的店同意让我来培训。

因为隐私还是得要的，这个奶茶品牌是什么我就不说了。

奶茶店的员工要做的事情并不算多：做前台收银、摇奶茶、补货、开店闭店，如果店里提供小吃的话做小吃 —— 这种小吃多数以甜品或者炸物为多，我去的这家店没有甜品，只有炸物，做起来也方便，丢到油锅里炸即可。

经济情况从某一年开始，从来都没有好转过。Trump 第二次竞选的时候，就有大量认为民主党搞坏了经济的老白人上网支持 Trump，认为他可以让美国的经济再度伟大。实际上，什么也没有变。说到底，一个联邦的总统怎么可能一下子就改善整个经济体系呢？人们是住在地方内的，地方有自己的官，地方外的州也有自己的官。人们总是将希望寄托于一个人，听信政客们的承诺，最后只能活在比过去更痛苦的生活中。但也没有办法，除了相信这些系统的明面指定人，还能去相信谁呢？

在蜜雪冰城来到纽约之前，奶茶大致可以分成两种：没有品牌的，和有品牌的。没有品牌的奶茶，估计只有三四美元吧，通常都是广东饼店用粉冲泡的，成本本来就很低，味道只能说能喝就行。而有品牌的，价格会高一些，目前来看市场价得在六七块钱之间，只说最经典的珍珠奶茶。这里有一些用的依然是粉，只是粉质量更高，虽然我喝的话只能喝出来恶心的粉味儿，和没有品牌的奶茶没什么太大的区别。如果是标榜自己用真奶的品牌，价格还得高一些，我喝了不会觉得肚子痛，但为了钱包和身体健康还是少喝为妙。

奶茶店除了奶茶，卖的东西还有水果茶：多数都是使用果酱或者水果风味的糖浆。能用得起真水果的，很少很少。我大一兼职的那家奶茶店，就有使用真水果，但是其他店员都不会检查它们的质量，导致我每次上班就要清理大量腐烂、长白毛的水果，恶心死了。没多久，这家店便倒闭不做了。

那么蜜雪冰城对本地的奶茶品牌造成的影响有多大呢？大杯的奶茶或者百香果果茶，只需要两三块钱，花没有品牌的奶茶所需的钱，喝到了有品牌的奶茶的质量。可能会有人说蜜雪冰城也没有那么好喝吧，问题是两倍价格的有品牌的奶茶，不见得有好喝多少。我就不一一点名了，纽约客或许会知道我在说哪些品牌。

奶茶店的生意如何，和地段有很大的关系。繁荣的地段，尤其是约会圣地、有着逛街氛围的地方，奶茶店就是很容易满座。学校附近也不错，学生们多数喜欢放学后来喝杯奶茶。如果组团一起来，还会点小吃一起吃、聊聊天再回家。

不过这家店所在的地段有些特殊，它算是一种住宅区，老人偏多，还有许多流浪汉。尽管附近有足足三所学校，但是有实际购买能力的只有大学生。要问我为什么知道，因为另外两所里，一所是小学，另一所是高中 —— 我的高中。这家高中的同学们，都不住在附近，而是住在坐地铁半个小时远的、低购买欲住宅区。有零花钱时不时买奶茶喝的，并没有那么多，这里的另一层原因是「奶茶很贵」。

这家店的老板和经理是对夫妻，对员工的要求很高：穿着好看、外貌漂亮、做事认真、年轻能干、不能属鸡。要求高重点在于「做事认真」和「年轻能干」上，比方说他们会定时看监控，看员工们是否在玩手机。其实这也还好，对比一位朋友兼职的店，那边的经理还会偷听员工们聊天。如果有人抱怨很累的话，就会打电话过去质问。好恐怖喔。

他们最让我讨厌的点是动不动就言语攻击。有些事情明明不是我的问题，有些甚至会是他们的问题，他们却会时常说我这个说我那个，听着很烦。所有的线上交流都是通过电话或者微信 —— 都在海外了也要使用微信吗，腾讯的影响力可想而知 —— 而微信群聊，通常会变成公开的处刑场。他们会公开艾特要挨骂的人的账户，接着一大段文字发过来，有时是很直接地训斥，有时则是阴阳怪气。但是被挨骂的人，也没有真的做错什么，很多时候都只是因为信息不对等的问题，而不知道要做某件事而已。

不过作为严厉的奖励，这家店的卫生条件和责任心不错。

迫使我离职的原因也很简单：在这家店里继续工作下去对我的精神状态不太好。工资不过是最低薪水的标准、小费拿不到、员工餐也没有，还要和这两尊大佛相处。再加上这家店所在的地段，先前说过，是一个特殊的住宅区，因为它也在另一个金融区的角落，周围还有地铁站，所以租金不低，但客人就是没有那么多。为了「降本增效」，这家店缺人，俩大佛也经常迟到，或者干脆不来、让其他员工临时来工作顶上。

要知道，小规模的奶茶店一天只会有两个人在，只有一个人的话，是很难同时顾得上前台收银、摇奶茶和做小吃的。我因为他们的迟到，已经吃过许多亏，那些时候我只能绷紧神经，一个人处理店内所有的事情。这里最麻烦的是接单，因为客人们点单的速度很慢，而根据规矩，有客人进来就必须先接单。有时候柜台上已经积累十几单还没开始处理，前台却还有一些客人慢吞吞地在点单，旁边站着已经点了单的其他客人、盯着我看。我能怎么办呢？要是想退款的话，就退款吧，反正我做多少都不会影响到我的工资，老板少赚也只会是老板活该，可怜的只有赶时间的客人。

有位老员工，便因为这件事受不了、早我一两个月离职了。走之前他说，你的底线在哪里，我的底线在这里。

他走后，压力便到了我身上。其他员工都是学生，还有实习什么的，一周内能来上班的次数很少。我因为一学期里要做的事情不多，反而要上更多的班，一个人扛住压力。这些压力明显不是我能承受得了的，但就算是那个时候，除了被说「菜」外，得到的反馈也只有「我做事不认真」，尽管我根本不知道哪来的「不认真」，我能做的都做了。

提出离职那天，感觉一身轻。这半年来收获许多，其实一个月过去，已经不记得自己当时有多么不舒服，只记得自己很愤怒。这些情绪都被记录在日记和聊天记录内，再来看的时候反而觉得陌生。

入门编写 SVG

2026-03-11T04:00:00.000Z

这一切要从我决定重构 https://cytrogen.icu 开始（当你看到这篇文章时，访问该链接就能看到雏形了）。原本它是我的博客网站的地址，后来我想要一个更像是个人网络的设计，即根域名为个人主页，博客网站放在 blog 子域名上。

个人主页、个人主页…… 怎么样的个人主页更能展示出我的「个性」呢？除了先前介绍的 ellesho.me 外，我还看了 Hacker News 的这个帖子，里面有许多设计非常有趣的个人主页，不过博客网站依然偏多。不是对博客网站有任何意见，只是我认为，我不需要另一个以文本为主的网络载体：我已经有了博客网站，还有了只能显示文字的胶囊。

这就需要说到 Web 最为特殊的东西了：HTML、CSS 和 JavaScript。既然是 Web 上搭建的站点，不玩玩这三剑客又怎么行呢？当然，这也不意味着我的个人主页就会充满了 JavaScript、把访问者的设备卡到无法动弹。我依然会遵循「极简 JavaScript」的原则，来完成它。

小时候游玩过的 Flash 小游戏，让我想要实现类似的内容。不知道读者们有没有玩过 Reincarnation 这款点击解密 Flash 游戏呢？4399 游戏平台将其翻译为《地狱使者》，不过我认为失去了原标题「轮回」的意味。总之它是一款原先发布在 NEWGROUNDS 平台上的游戏，由 Chris Gianelloni 开发。故事讲的是地狱中逃出去了许多鬼魂，主角小恶魔受地狱之王撒旦指使，要去人间找到这些死人、定他们的罪，最后靠解密让他们「意外」身亡 —— 为什么小时候的我喜欢这种血腥的游戏啊？不过主角小恶魔我觉得很可爱，还是个被迫工作的打工人，经常光着身子撅着个腚走来走去。

当时的 Flash 游戏，这种玩法单纯依赖于鼠标点击的有很多，比方说各种类宝可梦的网游、《华纳史诗冒险系列》（Steppenwolf: The X-Creatures Project）都是如此。我也想一个类似的个人主页！

使用 Flash 技术肯定是不可能的了。我也不打算将个人主页做成一款网页游戏，不过一些游戏元素还是可以接受的…… 但这篇文章并不会涉及到这一方面，为什么呢，因为我还没有开始设计和编写。就像标题所说的，该文章的重点在于 SVG 这项技术。

了解 SVG

SVG 的全称叫作 Scalable Vector Graphics，即可缩放矢量图形。它是基于 XML 格式的图像格式，用于描述二维矢量图形。

说这么多术语以及模糊的概念，大家可能无法很好地明白，我就先来讲解一下计算机里、图形到底是什么吧。图形本质上是数据的可视化量现。为了在屏幕上准确呈现这些视觉信息，计算机需要依赖一套特定的编码规则或者说数据格式来解析信息，而这一切大致可以分为两个分支：位图与矢量。

位图图形（bitmap），也被称为栅格图形（raster graphics），核心结构是由像素点（pixel）排列而成的矩形网格，而像素是数字显示设备上能够被独立控制色彩与亮度的最小物理发光单元。大家熟知的 JPEG、PNG 等，都是位图图形的格式。当计算机系统渲染一张 JPEG 文件时，它读取的其实是二维数据表 —— 表会记录该特定尺寸网格中，每一个坐标位置上像素的具体色彩值。

不过位图有个大问题：依赖分辨率。因为图像的信息由固定数量的像素点强行绑定，一旦图像被放大、网格被拉伸，计算机就必须运行插值算法，根据原有相邻像素的颜色去推算并凭空生成新的像素来填补填充后的物理面积。作为一个例子，你可以打开任何一个位图编辑器，比方说 Windows 系统的 Paint 软件，在上面随便画点什么，接着将其选中、拉伸，你就能看到许多突然多出的锯齿状像素方块。

而矢量图（vector）抛弃了像素网格的概念，转而使用数学公式和几何图元来描述图像。一组由起点坐标、终点坐标、线条粗细和颜色属性共同构成的数学指令，就能在矢量体系中画出一条直线。当矢量图被放大后，计算机会将新的缩放比例代入原有的数学公式中，重新计算并在屏幕上实时绘制出新的图像，从而让矢量图无论怎么放大，都能让边缘保持锐利。

在互联网普及之前，计算机图形学领域便已经存在成熟的矢量技术：用于打印排版的 PostScript、CAD 软件和 Adobe Illustrator 等专业绘图工具使用的专用格式…… 二十世纪九十年代末，万维网面临着严重的带宽限制和多样的终端显示器分辨率。位图格式在传输高质量大尺寸图像时，会导致文件体积急剧膨胀，且有着先前提到过的、极差的不同分辨率下的缩放表现。矢量图本应该是解决这一问题的完美方案，但是当时的矢量格式大多是编译后的二进制数据，且被各家商业公司作为技术壁垒严格封闭。

如果将早期 Macromedia Flash 或各类专有矢量文件直接嵌入网页，浏览器无法原生解析这些数据，用户必须下载并安装特定的第三方插件。这些二进制文件对于网页的底层结构而言，也有着许多问题：搜索引擎的爬虫无法读取其中的文本内容，网页开发者也无法使用 JavaScript 去捕获图形内部的元素并产生交互。

W3C（万维网联盟）认为，互联网需要一种属于自己的、非专有的、且与现有 Web 技术栈深度融合的矢量图形标准。业界纷纷向 W3C 提交关于 Web 矢量图形的提案，其中最具代表性的分别是 VML（Vector Markup Language）和 PGML（Precision Graphics Markup Language）。它们都试图建立基于 XML 的图形描述规范。

而 W3C…… 哪个都没选，反而成立专门的图形工作组，吸收了这两种方案的优势、想出了 SVG 规范。

因为 SVG 被设计为纯粹的 XML 文本，因此顺理成章成为了 DOM 树的一部分。网页浏览器不需要插件也能利用内置的渲染引擎对其进行解析，同时图形中的每一条路径、形状都成为了可被精确寻址的 DOM 节点。可喜可贺，可喜可贺。

写 SVG

在我的计划里，我的个人主页所会用到的矢量图形并不复杂。没有描边的大色块有着自己的魅力。

用 SVG 来写只需要知道这五个元素：

SVG 应用的是直角坐标系，原点 $(0,0)$ 位于画布的左上角，X 轴向右延伸，Y 轴向下延伸。所有的几何图元都基于这个网格定位与绘制。

对于矩形元素，核心属性分别是：

x 和 y，用于确定矩形左上角顶点的精确坐标
width 和 height，分别定义矩形在水平方向和垂直方向上的标量跨度
rx 和 ry，指定圆角的水平和垂直半径

圆形元素的逻辑基于圆心的半径：

cx 和 cy，标记圆心在坐标系中的绝对位置
r，设定原的半径长度

多边形元素用于绘制由直线段连接而成的闭合形状：

核心 points 属性，在接收一系列坐标对，每个坐标对代表多边形的一个几何顶点。渲染引擎会按照坐标的书写顺序，依次用直线将这些点连接起来，并自动将最后一个点与第一个点连接以闭合图形

作为一个例子：画出的是三角形。

文本元素将字符数据引入矢量画布。与常规 HTML 中的文本排版不同，SVG 文本需要严格的空间绝对定位：

x 和 y 属性并不代表文本块的左上角，而是文本基线的起点位置。字号、字体族等排版属性需要通过 CSS 或内联属性进行声明

元素很常用：

d 属性是一系列微型绘图指令的集合：
- M x y 指令负责抬起虚拟画笔并移动到指定的 $(x,y)$ 坐标，通常作为路径的初始起笔指令
- L x y 指令表示从当前画笔位置绘制一条绝对直线到新的 $(x,y)$ 坐标
- Q x1 y1, x y 指令绘制二次贝塞尔曲线。其中 $(x_1, y_1)$ 是控制点， $(x,y)$ 是整段曲线的最终物理端点
- Z 指令没有参数。当它出现在路径数据的末尾时，渲染引擎会自动从当前所在坐标绘制一条直线，径直连回当前子路径的起始点，即上一个 M 指令所在的坐标

知道了这些后，我便可以一步步绘制出，我的个人主页的内容了！

首先，我希望我的个人主页有一个开场动画：一面山羊头骨为中心的墙，短暂呈现一段时间后，从中间垂直地打开，展示后面的城堡。那么这个墙要怎么画呢？

先定义一下结构：

在最外层的容器中（实际最外层的 div 仅作动画用，在写 SVG 的情况下并不需要管），视口属性 viewBox="-200 -250 800 1000" 意味着起始点在于 X 轴的 $-200$ 和 Y 轴的 $-250$ ，整体的宽度设定为 $800$ ，高度设定为 $1000$ 。

preserveAspectRatio="xMidYMidslice" 属性是适配规则，强制 SVG 在容器尺寸变化时保持自身比例缩放，且会裁剪掉超出容器边缘的部分，以确保画面始终完全填满视口、不发生形变。

由于 SVG 遵循着从上到下的文档流渲染顺序，实际带有山羊头骨的上半部分墙需要在下半部分墙之后定义。现在让我们先完成下半部分墙的内容。

是群组元素，可以在内部添加数个 SVG 元素来组合起来。对于下半部分墙，我们只需要一个元素，但为了统一性，还是放入群组内：

除了高度外，其他内容都和视口属性相同，因为需要填满整个画面。高度则是视口高度的一半，毕竟是「下半部分」。

接下来让我们绘制上半部分墙。在我的构造里，这个墙在画面中心还会有一个山羊头骨，在绘制时需要先画墙、山羊头骨、头骨细节。先画墙：

接着绘制一个山羊头骨的剪影：

起初点 M175 380 是头骨吻部的左侧底端，随后用 L 指令向上描绘头骨的左侧边缘：L158 340 L138 290 L125 245 L130 200 L155 170。可以观察出，它们的 X 坐标先减小后增大，因为我想先画出从吻部向外扩张到颧骨，再到头顶时向内收缩。而 Y 坐标一直在减少，因为我们是从左下角开始画、要画到头顶的。

跨过中心点 L200 158 后，再描绘头骨的右侧边缘：L245 170 L270 200 L275 245 L262 290 L242 340 L225 380。和画头骨左侧的路线相反，Y 坐标一直在变大，X 坐标则是先增大再减少，直至吻部的右侧底端（看 Y 坐标，和起始点的 Y 坐标一致）。最终用一个 Z 指令将它们两个点用一条直线相连。

想要填充头骨颜色的话，在 CSS 类 .fill-skull 里设置即可。

山羊头骨的大致形状写完后，我们还需要写两个眼洞和角。其中眼洞的写法和头骨剪影一致，都是用直线勾出形状，这里只说角的写法吧。

我想要这个角具有弧度，因此需要引入二次贝塞尔曲线。二次贝塞尔曲线需要三个关键点：

起点
控制点
终点

控制点本身不位于最终渲染的曲线上，但起到了类似于引力的作用，将起点到终点的连线向自身方向拉扯，从而形成特定的弧度。

图片来自 Pocket Guide to Writing SVG。

用这张图片来看，会更直观些吧。

左侧角的绘制从 M130 205 开始，确立了角与颅骨左侧的连接基点。随后 Q70 170 35 110 勾勒角的外侧边缘。这里的曲线从坐标 $(130,205)$ 开始，向 $(35,110)$ 延伸，同时受到位于左上方的控制点 $(70,170)$ 的牵引。结果便是曲线先向左侧外扩，随后向左上方收束。到达角尖最高点附近时，L65 95 封闭角的顶端，再用 Q85 145 145 180 画角的内侧边缘。右侧角就不用说了，是完全镜像的。

更复杂的 SVG

到这里，你或许会想，这样写 SVG 好累。我不否认。人类的大脑并不擅长于直观构建二维坐标系内的形状，尤其是过于复杂的形状。一个解决方案是使用更抽象的工具：可视化矢量图形编辑器。

我高中时学习了 Adobe Illustrator 的使用方式，或许其他的编辑器也是一样的。绘制路径时，往往都会有操作锚点、控制手柄等工具。底层图形引擎会实时计算这些交互动作对应的绝对，或相对的坐标，并能够精准地生成所需的二次，甚至是三次贝塞尔曲线指令。

不过 Adobe 的东西都很昂贵。Inkscape 是开源的替代品，可以尝试。据说 Figma 也能够绘画矢量图形。它们都可以将结果导出为标准的 SVG 代码。

如果想要画重复性高的 SVG 图形，也可以通过编写脚本来动态连接路径数据。比方说 d3.js 这个项目，就能实现一个很有意思的例子。

再就是，在传统开发模式中，SVG 往往被视为等同于 PNG 或 JPEG 的静态外部资源。一旦在矢量编辑器中完成绘制并导出为 XML 代码，其内部的节点结构、填充颜色、描边参数以及路径坐标种种，都被硬编码锁定了。

怎么解决呢？现代前端开发体系，比如 React 和 Vue，引入了组件化封装与声明式抽象，本质上是将静态的 XML 标记解析为虚拟 DOM 树上的节点。这样的话，SVG 就被包装成了个能够接收外部参数的函数或类组件。

想法在丙午阳中迭代

2026-02-28T05:00:00.000Z

这个月我忙于一些现实中的事情，结果连月刊和自己一个月里都做了什么，全都忘了个干净……

我希望这会是你能看到的，最后一个条目如此之少的月刊。

本期导读

我的胶囊旅馆开张了

2026-02-25T05:00:00.000Z

此胶囊旅馆非彼胶囊旅馆。虽说我对现实中的胶囊旅馆很感兴趣，但至今都没有睡过一次，去开张一家真正的胶囊旅馆更是无稽之谈。标题中的「胶囊旅馆」指的是通过 Gemini 协议提供内容的独立信息集合。

想必有些读者看到 Gemini，第一时间想到的是同名的，由谷歌开发的多模态大型语言模型，亦或者是同由谷歌开发的生成式 AI 聊天机器人了吧。实则不然，本篇文章所说的 Gemini 指的都是 Gemini 协议，一个轻量级的互联网应用层通信协议。

一个常见的误解是，将「互联网」和「万维网」混为一谈。很多人认为，浏览器就是互联网，或者说互联网只有 HTTPS。这些都是认知盲区，但也怪不了谁。现代万维网极度繁荣，承载了普通用户所有的线上活动，但也掩盖了底层网络架构的多样性。

互联网是由全球无数计算机网络相互连接而成的庞大基础设施，它的核心职责是数据的路由和传输，其基石是 TCP / IP 协议族。

在计算机网络的体系结构中，网络通信被严密地划分为不同的层级。从下往上分别是「链接层」、「网络层」、「传输层」、「应用层」。

底层协议负责处理物理信号、IP 寻址和数据包在路由器之间的接力，而最顶层的应用层协议定义了运行在不同设备上的应用程序如何相互传递报文、直接决定了数据在终端用户面前的呈现和交互方式。

为了让同一台服务器能够同时处理多种不同的网络服务，传输层引入了「端口」的概念。当我们在浏览器中输入 https:// 时，实际上要求了操作系统使用超文本传输协议安全版（HTTP over TLS，也就是 HTTPS），去连接目标服务器的 443 端口。

HTTP 协议最初仅仅是为了在研究人员之间共享简单的学术超文本文档而设计的。但随着数十年的发展，为了满足复杂的现代 Web 应用程序的需求，它被不断追加了 Cookie 会话管理、CORS、Service Worker 等庞杂的机制，最终造就了今天功能强大但也极其臃肿的 Web 生态。

不过应用层是一个相当宽广的领域，HTTP 仅仅是其中的一个居民。互联网上时刻运行着大量与 HTTP 平级的应用层协议，它们各自服务于高度专一的通信需求。例如：构建全球电子邮件系统的核心是 SMTP 和 IMAP / POP3 协议；远程管理 Linux 服务器时，系统管理员会依赖运行在 22 端口的 SSH 协议；服务器之间进行时间同步，依赖于 NTP 协议。这些协议支撑着互联网的底层运转，却鲜为人知，很大缘故是它们通常在后台静默工作，或者需要特定的客户端而非通用浏览器来访问。

今天的主角 Gemini 协议也是与 HTTP 完全平行的应用层协议。它拥有着自己专属的通信规则、状态码体系和数据格式，并且默认运行在 TCP 1965 端口（纪念 1965 年的「双子星号」载人航天任务）。

在深入 Gemini 的技术基层之前，有必要了解它的精神前身：Gopher 协议。

在万维网尚未一统天下的二十世纪，Gopher 是互联网上最流行的信息检索系统。它采用严格的层级菜单结构来组织纯文本信息：

Welcome to Gopherspace  1. About this server.  2. Articles and Musings/  3. Links to other Gopher holes/  4. Search this server   5. A plain text document.Press ? for Help, q to Quit, u to go up a menu, or enter a number: _

大概就是这样吧，是不是看着很像早些年的文字游戏呢？

其实我最初学习编程语言，写的第一个项目就是一个类似于这样的文字冒险游戏 —— 可惜源代码被我删除了，之后考虑使用 Python 重构却没有写下去。

Gopher 的客户端界面之所以是这么个列表形态，是因为服务端返回的原始数据本身就是一种以制表符分割的结构化纯文本。每一行代表菜单中的一项，行首的单个字符定义了该项的资源类型。

然而随着带有图形界面、支持内嵌图像和复杂排版的早期 Web 浏览器的出现，加之 Gopher 的发源地明尼苏达大学曾短暂尝试其服务端软件收取许可费，Gopher 迅速走向了衰落。

Gemini 正是诞生于对现代 Web 日益臃肿和商业化，以及对 Gopher 历史教训的深度反思之中。其核心设计理念被概括为「比 Gopher 重，比 HTTP 轻」。很聪明地，它并不打算取代现有的 Web，而是想要构建一个被称为 Geminispace 的独立、纯粹的文本网络生态。对于偏好纯文本与自托管服务的极客们而言，Gemini 是个相当具备吸引力的信息分发与获取方案。

与 HTTP 不同的是，Gemini 强制要求使用 TLS 加密连接，不允许任何明文传输，确保了基础的通信安全。同时它在实践中广泛接受 TOFU（Trust on First Use，首次信任）模式或自签发证书，大幅降低了个人站长维护基础设施的门槛。

其请求和响应模型被设计为一次性的单向事务，连接在响应完成后立即关闭。服务端的响应头部极简，仅包含一个两位数的状态码、一个空格、一段元数据（在请求成功时通常是 MIME 类型，如 text/gemini），从根本上抛弃了 HTTP 中复杂的头部字段。

更为彻底的是，Gemini 规范中没有 Cookie，没有 User-Agent 嗅探，不支持任何形式的客户端脚本执行。如果服务端应用需要维持会话状态或进行身份验证，协议规定直接使用 TLS 客户端证书来实现。这意味着在体系结构上，任何人都无法在 Gemini 页面中嵌入追踪探针、广告代码或第三方分析工具。

与该协议深度绑定的是一种名为 Gemtext 的专属轻量级标记语言（文件后缀通常为 .gmi）。Gemtext 的语法相较于 Markdown，仅支持三级标题、无序列表、引用块、预格式化文本以及链接。

三级标题对我而言，不是什么大问题，因为我现在使用的主题的原作者 Infinity 这么认为：

实际上，Hexo-theme-apollo 只支持两种标题：h1~h3 大标题，h4~h6 小标题，也就是说，# 和 ### 的样式是一样的。之所以这么处理，是因为就个人感觉而言，我们不应该为文章设置过多的层级消耗读者的阅读精力。这相当于强制使用 Hexo-theme-apollo 的用户在写文章时注意文章结构，最多只能使用两层结构。

不过我印象里，这个「两种标题」并不准确，实际上是三种标题：h1 一个，h2~h3 一个，h4~h6 一个才对。我并不记得我特意修改了这一点，也有可能是我记错了。总之，我在写博客的时候就已经慢慢培养出来了不滥用标题层级的习惯。

特殊的是，Gemtext 还严格禁止在段落文本中内嵌链接，所有超链接必须作为独立的代码行存在。

我个人算是半个脚注的反对者。脚注在实体书籍上出现没问题，但展示在互联网的文章上，阅读起来相当难受。如果可以的话，我会希望文章都尽量是从头到尾、瀑布般的排版，不需要让读者去别的地方才能收获完整的阅读体验。不过为了漂亮，我还是会在文本内嵌入链接，给它们附加文本。这个做法我会深思熟虑一下，是否应当完全参照 Gemini 协议希望的那样。

先前说过，Capsule 是通过 Gemini 协议提供内容的独立信息集合。它的概念完全等同于万维网中的 Website。正如一个 Website 是由多个通过 HTTP 协议传输的 HTML 页面和资源组成，一个 Capsule 则是通过 Gemini 协议传输的 Gemtext 文件及其他媒体文件的集合。

虽然它的命名出处来自于阿波罗计划中的「双子星号」太空舱，但结合我给个人网络附加的设定，最终将我自己的 Capsule 其称为「胶囊旅馆」。莫要搞混了，它的意思是太空舱，而不是我二次创作出来的胶囊旅馆！

因为 Capsule 等同于 Website，所以通过 Gemini 客户端访问他人搭建的服务器时，最好不要称其为「Gemini 站点」，而是说「Gemini 胶囊」会更好些。因为「站」这个概念属于 HTTP 协议，胶囊严格来说也不属于「网站」—— 网站是依附于万维网生态、基于 HTTP / HTTPS 协议和 HTML 标记语言构建的产物。

访问 Gemini 地址

由于 Gemini 协议从根本上切断了与 HTTP 的联系，常规的现代 Web 浏览器是无法撬开这些太空舱的。我们需要借助专门支持 Gemini 协议的客户端工具。

在终端环境中，Amfora 是一款功能完备的命令行客户端。如果依然偏好图形界面的便捷性，Lagrange 则是目前生态中非常优秀的桌面端选择。

如果你要问我，我选了哪个的话。莫要忘了，我是一个 typical Emacs user（经典 Emacs 用户）—— 其实只要使用 Elpher 包就可以访问 Gemini 胶囊啦，太方便了！

M-x package-install RET elpher RET

接着你可以在 Elpher 界面上，使用 g 命令，然后输入我的胶囊旅馆地址 gemini://cytrogen.icu 便可以访问了。

博文生成和部署

我的写作流程因为相当私人化，所以仅供参考了。

Org Mode 文件是所有文章的上游。写好 Org Mode 文件，我会转换它为 Markdown 和 Gemtext 文件。这里只说 Gemtext 的转换：我引用的是 ox-gemini 这个导出后端，不过我有很多额外的定制化需求，因此进行了一些魔改。比方说在我的月刊内，有个「日记片段」板块，那里理论上来说是 Hexo 框架在构建文件时，自动从 Fediverse 应用上获取数据、嵌入 HTML 文件内。这意味着 Org Mode 文件里没有这些日记内容，转换成的 Gemtext 文件也不会有。但我目前并不希望 Gemtext 文件在构建时进行过多的操作，导致流程愈来愈复杂，最终决定只放一个 Mastodon 主页链接。

接着我会将 Gemini 项目 git push 到 VPS 的 bare repo，并触发它的构建命令。说是构建命令，其实也就是帮我部署到 Gemini 服务器，然后镜像到 Sourcehut 仓库。

我选用的是 Agate 这个由 Rust 写的 Gemini 协议服务器。它会自动生成并管理 TLS 证书，不需要额外配置 Let's Encrypt，运行内存要求很低，我自己搭建后实际用的连 500KB 都不到。

不过它仅适用于纯静态 gemtext 文件 capsule。想要动态内容支持的话，可以考虑一下 Gemserv 或者 Molly Brown 这些服务器。

在 VPS 上安装了 Agate 之后，所需要的命令相当简单：

agate --content /gemtext/文件目录 --hostname 域名.后缀 --lang zh

那些不受欢迎的想法

2026-02-25T05:00:00.000Z

室友自上个月开始，和另一位有趣的人联合举办了一个活动，名为「那些不受欢迎的想法」。

该活动的简介很有特色：

大多数人实际上并没有自己的观点。他们持有的是继承来的立场、重复的观点，或是伪装成深刻见解的自助车轱辘话。
本次活动是为那些真正拥有观点的人准备的。
每次活动，参与者都会分享一个他们真正持有的、经过深思熟虑的观点 —— 一些他们真正思考过、检验过或通过真实经历得出的东西。
一些他们真正相信并且能够捍卫的东西。
每次分享后，所有人都会在「完全不同意」到「完全同意」的谱系上选择自己的态度。然后我们会进行结构化的讨论：双方都有不被打断的时间来阐述他们的理由。目标不是为了胜利或证明自己是对的 —— 而是将想法与其他敏锐的头脑进行碰撞，并练习将想法与持有它们的人分开。

第一次活动里，室友分享给我的话题并不是让我特别在意，不过还是让我记录一下吧。

室友自己分享了「将手机屏幕颜色调成灰阶」这个想法，因为这可以避免大脑被鲜艳的颜色吸引到。我必须严肃表示，她这一想法是从我这里学来的，而我是从另一篇文章学来的。

有人不赞同这个做法，因为护眼的话，其实调成纯红色更好，看上去也更恶心、让人不想要动手机。

经过两个月的使用后，我发觉将手机屏幕颜色调成灰阶的一个问题在于，眼睛逐渐不习惯于鲜丽的颜色。我的手机屏幕原本能够发出极其鲜艳的颜色，购买时我还认为是一件好事，现在看来一点都不好；眼睛都要瞎了，还是乖乖调回灰阶吧。

至于护眼不护眼，省不省电，我认为最好的方法还是 —— 把手机放下！

一个人建议大家学习在地板上睡觉，而理由是想要让自己不需要依赖任何外界的东西就能好好活下去。睡眠对人类而言是一件大事，如果只能在床上睡着的话，她会觉得自己的身体不受控制。

一个人表示「写作即思想」。他是一个热爱撰写博客文章的人，并在纽约市举办了一个自己的写作俱乐部。

室友觉得这个想法很棒，问我如何开发一个个人网站 —— 哼，这个家伙根本不理解个人网站的魅力，吃了我一嘴教程后到现在也没有搓出来一个网站。

一个人认为话疗没有用，根本就是胡言乱语，不会解决任何人的问题。不过这个人的想法过于主观，没有足够可以说服人的证据，不太严谨。

过去和室友大打出手的时候，室友去过几次话疗，结果都不尽人意：要么是建议她去搞开放式关系，要么是建议她去找心理医生、嗑药。这个话题本该会勾起她表达欲，但是提出者给出论点让她觉得有些幼稚。

一个人提议大家去专注于平日不会注意到的细节。他经常会在家附近走一条固定的路线。一次，他决定放慢脚步，鉴赏大自然，却发现家附近有个温室 —— 天啊，他住在这里这么多年了，居然不知道这里有这么大一个温室！

一个人说千万不要觉得自己奇怪，想到什么就去做吧。这个想法虽然很不错，但我认为实现起来很困难。

作为室友和另一个人初次举办的活动，她们俩都没有什么经验，后来也承认不够成熟，经过审核的话题也不够符合标题「不受欢迎的想法」，甚至有些听上去依然是车轱辘话来回转。不过第二次举办的活动里，能聊的东西就多了起来。

首先是鸽子被严重低估了！纽约客们可能都很讨厌这个动物吧：到处都是，到处拉屎。但其实这个动物并不是原生动物，而是因为战争、以「信鸽」的形式来到这片土地的。

提出这个观点的人认为，鸽子也可以很美丽。想要了解更多的话，可以见这个鸽子博物馆。

我想到了「赛鸽」和「和平鸽」。这样说来，鸽子同时是「信息」以及「和平」的象征，可以拼接在一起，合成「沟通可以达成世界和平」的想法。

不过真的要给一个动物贴上如此宏大的标签么？「和平鸽」这个概念出自于《圣经》的诺亚方舟。当时诺亚放出了鸽子去打探地上的情况，而鸽子叼了橄榄叶回来，暗示地上已经有植物生长，洪水退了、世界和平了。

或许将动物的美拉回到动物本身是最好的 —— 你认为三文鱼的代表色是橙色吗？

接着是一个颇有争议性的话题：男人和女人如果互换了生殖系统，会发生什么？提出该话题的人认为，这世上的大多数人祖上都是皇族或者强奸犯。这是因为过去，只有强壮的人才能够繁殖后代。抛开在地位和权利上「强大」的皇族，强奸犯则是因为暴力、强迫了女性诞下自己的子嗣。皇族终究是少数人，那么剩余的多数人都是强奸犯，且越暴力越好。

他接着提出一个猜想：在基因层面上，男人会更暴躁。再加上男人的生殖系统是侵入性的，并且男人可以让多个女人怀孕，而女人一次只能怀一个男人的胎，因此男人想要授种的欲望更加强烈，其生殖系统也更希望他更加暴力。那么在互换后，具备这样的生殖系统的女人也会变得暴躁起来 —— 生殖系统决定了人类的很多事情。

室友提出反对。假设这个互换是突然发生的，那它仅改变了男女的「先天条件」，但是没有改变长期以来人类形成的文化，所以男人不会突然变得女性化，而女人也不会突然变得男性化。作为证据，她提出了双胞胎说：一对同卵双胞胎如果在不同的环境下生长，最终会长成完全不同的人。这意味着对人类而言，后天环境更加重要。

当然，这些都是以极端的情况作为前提来讨论的。是男人并不意味着他就是个强奸犯，拥有男性生殖系统也不意味着他一定会有有毒男子气质 —— 我曾经写过相关的文章，并认为这是被社会化的结果，而不是生理层面上的。将繁衍的生物学内驱力强行和系统性的社会暴力表现替换，实在是过于极端了，毕竟生殖器官本身并不具备实施社会暴力的主观意志，认为男性生殖器官更有侵入性一点我也不好说，毕竟男性也可以被女性强奸。

下一个话题是「大学是给一些不愿进社会的人们的拖延症」。提出方是一个没有上过大学的人。说实话，她是我目前见过最自律的人了，不仅自学了大量技能，就连生活的方方面面也不愿意交给其他人来做。她热爱音乐、走马拉松、尝试做自己从来没有做过的任何事情…… 令人忍不住去羡慕她。

说回她的论点。她认为大学对自己而言没有用处，只是让不想接受现实的人们再当几年的学生。室友也赞同这一点。不过这一论点很快被两个人否决了：一个认为，这是因为提出方和室友两个人都是主动性很强的人，在大学前就知道自己应该做什么工作。那如果是对未来感到迷茫的人呢？比方说他自己，就是上了大学才发现自己对物理学感兴趣，继而成为了一个物理老师，因此他永远都不会后悔自己上了大学。

另一个不赞同的人则认为，「大学无用」这个结论根本上是因为社会让太年轻的人去上大学了。刚刚成年的人们根本不知道未来该怎么办，也不知道社会是什么样的，去了大学自然不知道应当学什么专业。他希望高中生们毕业后，就立即步入社会工作，然后再决定是否要读本科，专精某项技能。

这很难让我回应…… 我讨厌大学是真，但更多是我觉得大学教育德不配位 —— 贵死了，教育水平也一般般，不如自学。所以我也算在大学之前就知道自己想做什么的人。不过并不是所有人一出生就知道自己想做什么，为这些人提供帮助的，我想正是学校。

但是我有一个更为宏观的看法：本科的重点是培养搞学术的人，而不是专业的工作者。后者应该去读专科。很多人错将本科认为是可以学习到专业技术的地方，毕业后却去找更适合专科毕业生的工作。同理，现在的职场也只认本科生，将适合专科生的工作交给本科生。结果社会越来越乱，出现了大量的本科生，出社会找工作却发现学校教的知识根本不是职场需要的技能。

这也是为什么我觉得双方的观点其实并不冲突：赞同方更注重于步入职场的实用性，都是创业者；不赞同方想要的是在学术上的引导，因为他之后当的也是和学术相关的老师。

至于是否应该让高中毕业生先去工作，我认为该想法的内核是值得称赞的，目前教育系统的一大痛点正是大多数年轻人在做出人生最昂贵的一次投资时，对真实的社会运作一无所知。

过去我认识到了一个观点，即 K-12 教育中应当多出哪些课程，其中就有税法、金钱管理等长大后必须要学习的内容。可惜，K-12 教育里没有这些，想要学习税法的需要自行去申请成为税法专业学生。社会残酷地没有为刚刚成年的个体提供试错和探索的空间，导致一个又一个人发觉大学真是个笑话，自己不过是又当了四五年高中生。

而已经经历过社会毒打，参与过真实工作场景的人们，更能清楚自己欠缺什么。重返校园接受本科教育时，他们拥有着更强的目的性。我没少见过年纪可以做我父母的本科生们比谁都要更努力地钻研学业，让我忍不住去关注他们。

不过这个想法实践起来有些不切实际，并不是因为它有误，而是目前社会运转逻辑已经固定了。我们的劳动力市场过于前置了学历门槛，剥夺了高中毕业生通过低门槛工作去探索世界的过渡期，就连 Gap Year 这个概念在很多国家都属于奢侈品。社会默认将年轻人直接从高中强行推进大学，导致许多人只是为了逃避就业而继续读书。本科是如此，硕士也是如此。

最后一个话题就没有前一些话题那么有争议性了：自私和无私的代价。我和室友在高中时就参与过这个话题的辩论。或许是一直待一块的原因，臭味相投，我和她的看法是一致的：世界上根本没有什么所谓的「无私」，无私不过是在客观结果上利他的自私，因为无私者是被自己的想法驱动而去做利他型行为的，获得最多的也是自我的满足。

当时我哗啦啦写了一篇作文表示人类有着自私的基因，却被另一个同学评论认为这种想法是不人道的。现在我已经不记得我做出了什么样的回应，但我现在可以说，自私并不意味着要和恶意、贪婪和剥削等词汇挂钩，承认自己自私也并不妨碍我们在宏观层面建立道德 —— 人类的自私基因为了延续，演化出来的恰恰正是合作、同理心和无私奉献等策略，因为互助的群体存活率远高于互相残杀的群体。

汇编语言学习・壹

2026-02-23T05:00:00.000Z

学习汇编语言的笔记。

使用的教学材料：

Linux Foundation X [LFD117x] Foundations of RISC-V Assembly Programming

汇编语言可以用于开发操作系统和编译器，不过我认为也可以用于「入门」计算机 —— 学了总是好事。

基础知识

RISC-V

这是一种指令集架构规范，为处理器奠定了通用的机器代码语言基础。
RISC 指的是「精简指令集计算机」，而 V 代表的是罗马数字 5。
RISC - V 属于一种开放式指令集架构。

Assembly

Assembly 语言可以被直接翻译成机器码，是最低级的编程语言。需要记住的是，「低级」不代表是一件坏事。

学习 Assembly 以及如何使用它可以帮助我们理解软件和硬件的内部。

微处理器

通常来说，处理器包含控制单元、算术逻辑单元、寄存器以及用于输入输出的信号与数据线路。

处理器利用控制单元来执行指令
算数逻辑单元负责对整数执行算术和逻辑运算
寄存器是位于处理器内部的一种小型存储单元。处理器能够将数据从外部存储器或其他设备快速加载到寄存器中，在寄存器内对数据进行操作，随后将结果写入外部存储器或者其他设备
- 程序计数器是一种特殊的寄存器，用于保存当前待执行指令的位置信息。控制单元可以通过程序计数器来确定程序的执行进度

微处理器可以被分为 RISC 和 CISC，后者是复杂指令集计算机。两者的区别在于，RISC 架构拥有的指令数量较少。特定情况下，CISC 架构可能只需要一条指令就能做到一件事情，而 RISC 架构下需要执行更多的指令。

继续说 RISC。典型的 RISC 处理器会执行典型的五级流水线工作：

指令获取（IF）
指令译码（ID）
指令执行（EX）
存储器访问（MEM）
写回（WB）

具体流程是这样的：

处理器从程序计数器所指向的内存地址获取指令
指令是以二进制代码形式编码的，所以系统随后会对其进行译码、确定并获取执行所需的其他信息
进入执行阶段，利用算术逻辑单元进行计算
如果指令涉及内存访问，则会在接下来的存储器访问阶段进行处理
如果运算产生了结果，该结果将在最后一个阶段被写回寄存器

该流程可以按照单周期方式执行，也可以采用流水线技术执行。后者可以实现各阶段的并行处理，从而提升效率。

Ripes

Ripes 是一款专为演示 RV32IMC 和 RV64IMC 架构上机器代码执行过程而设计的模拟器。
总体而言，Ripes 是快速入门并实践学习汇编语言的极佳工具。

安装

课程使用的系统是 Debian / Ubuntu 系，我用的是 Arch Linux 系，部分包会对不上。这里只写我安装了什么：

sudo pacman -S qemu-system-riscv qemu-user

可以使用 qemu-riscv-64-static -help 命令就可以。

这是用于在我们的计算机上安装专门针对 RISC - V 架构的系统仿真器。
接着我们需要安装交叉编译器，用来让我们的 C 语言源代码编译成 RISC - V 指令集。

sudo pacman -S riscv64-linux-gnu-gcc

当编译一个动态链接的 RISC - V 程序时，编译器会在生成的二进制文件里写入一个解释器的绝对路径。对于 64 位的 RISC - V Linux 程序，这个解释器通常是 ld-linux-riscv64-lp64d.so.1 默认预期位置在 /lib/ 目录下。然而在我们的宿主机上，这个文件实际上位于交叉编译器的安装目录中，而不是系统的根目录 /lib/ 下。

当使用 qemu-riscv64 运行程序时，QEMU 会尝试加载程序，但程序本身会告诉系统去 /lib/ 找解释器。如果找不到就会报错。

因此我们需要建立一个软链接，将位于深层目录的解释器映射到程序预期的 /lib/ 位置，从而欺骗程序使其能够找到加载器。

这里有两个选择：

链接到 /lib/
链接到 /usr/lib/

两者其实差不多，都可以。我就用后者来示范了。

sudo ln -s /usr/riscv64-linux-gnu/lib/ld-linux-riscv64-lp64d.so.1 /usr/lib/ld-linux-riscv64-lp64d.so.1

但其实还有一种方法，更适合「洁癖党」，那就是指定 Sysroot 路径。这样 QEMU 就会在那个目录下查找 /lib/ 和 /usr/lib 了，我们也不需要弄乱系统的目录。我的建议是设置一个环境变量：

export QEMU_LD_PREFIX=/usr/riscv64-linux-gnu

无论如何，都可以使用 riscv64-linux-gnu-as --version 来进行检查。

然后我们需要安装一个调试器：

sudo pacman -S gdb

运行 gdb -h 来检查。

让我们创建一个测试文件 example.s：

.globl _start_start:addi x10, x0, 7addi x17, x0, 93ecall

先使用 as 将源码转换为目标文件：

riscv64-linux-gnu-as -o example.o example.s

再将 example.o 链接为可执行文件 example：

riscv64-linux-gnu-ld -o example example.o

最后在 QEMU 中执行：

qemu-riscv64 example

最终的结果是返回了个 7。

我们也可以使用 riscv64-linux-gnu-objdump 来审视我们的二进制文件：

riscv64-linux-gnu-objdump -sd example

example:     file format elf64-littleriscvContents of section .text: 100b0 13057000 9308d005 73000000           ..p.....s...    Contents of section .riscv.attributes: 0000 415e0000 00726973 63760001 54000000  A^...riscv..T... 0010 05727636 34693270 315f6d32 70305f61  .rv64i2p1m2p0a 0020 3270315f 66327032 5f643270 325f7a69  2p1f2p2d2p2_zi 0030 63737232 70305f7a 6966656e 63656932  csr2p0_zifencei2 0040 70305f7a 6d6d756c 3170305f 7a61616d  p0zmmul1p0zaam 0050 6f317030 5f7a616c 72736331 703000    o1p0_zalrsc1p0. Disassembly of section .text:00000000000100b0 <_start>:   100b0:00700513          lia0,7   100b4:05d00893          lia7,93   100b8:00000073          ecall

这可以将机器码逆向翻译回人类可读的汇编指令，帮我们验证编译器是否真的生成了预期中的代码。

Contents of section .text 处展示了内存中的原始字节数据。

100b0 13057000 9308d005 73000000

其中地址 100b0 是这段代码在内存中存放的起始地址，数据 13057000 是第一个 4 字节（32 位）的内容。

在计算机科学中，位（bit，有时也可以叫比特位）是信息的最小单位，只能显示 0 或者 1 两种状态，也就是「假」与「真」。而字节（byte）是计算机存储和处理数据的基本单位，通常规定 1 个字节由 8 个位组成。

13057000 这串数据实际上是十六进制表示法。

这个「十六」并非物理上的容量单位，而是「进制」这个数字概念，具体代表的是在一个单独的数位上，到底拥有多少种不同的独立状态或者符号。例如人类最熟悉的十进制，每一个数位拥有从 0 到 9 这十个独立符号，当状态数值超过 9 时，就必须向前进位（1 + 9 = 10，个位超过了 9，就会向前面的十位进位）。

同理，十六进制意味着每一个单独的数位拥有 16 种独立的状态，为了填补数字 9 之后的符号空缺，系统引入了 a 到 f，对应十进制的 10 到 15。

理解了进制代表着「状态的数量」后，就可以将其与底层的「位」建立起直接的数学映射。先前说过，位只有 0 和 1 这两个状态。如果想要使用纯续的二进制来表示更多的状态，就必须将多个位组合在一起来观察：1 个位是 2 种状态；2 个位组合在一起（00、01、10、11）是 4 种状态；3 个位是 8 种状态。

十六进制中每一个字符（0-9 和 a-f）就代表 4 个位，总计 16 种状态。

计算机科学选择大量采用十六进制，其根本原因是为了在机器的物理状态和人类的阅读习惯之间寻找妥协：人类无法快速阅读和心算二进制流，而如果将其转换为人类最熟悉的十进制，二进制与十进制之间的互相转换又必须经过整体的乘除法运算。由于 10 不是 2 的整数次幂，这种转换无法在底层的比特位上做到规整的一一对应。

既然 1 个十六进制字符代表 4 个位，那么需要 2 个连续的十六进制字符并排，来转录 1 个字节的完整物理状态 —— 因为 1 个物理字节由 4 个比特位组成。

在 13057000 里共有 8 个字符（13、05、70 和 00），意味着总共有 32 个位，或者说 4 个字节。对于 RISC - V 架构而言，其标准的指令长度固定为 32 位，也正好对应了内存中这 4 个连续字节所占据的空间。

littleriscv 指明了小端序，低字节需要存放在低地址。

小端序又是什么呢？它描述的是多字节数据在计算机内存中的排列顺序。由于内存是被组织成一个线性的字节序列，即每个地址对应一个字节，当我们要在内存中存放一个跨越多个字节的数值，比如一个 32 位的整数时，就面临着把哪一端放在低地址的选择。

小端序指的是将数据的最低有效字节存放在内存的最低地址处，而最高有效字节则存放在最高地址处。这种存储方式的优势在于从低地址读取数据时，不需要进行地址计算即可直接获得数值的低位部分。

要想更加理解这一部分，就必须深入理解计算机是如何「看待」数据的物理本质。计算机的内存可以类比于一排无限长的储物柜，每个储物柜上都有编号，叫作「地址」，从 0 开始，依次递增。低地址是编号较小的位置，高地址自然就是编号较大的位置。

问题在于，一个储物柜只能存放 1 个字节。我们想要存储的数据往往是多个字节，要想存进内存就必须占用连续的储物柜。用 13057000 举例：你有着身为最高位的 00 以及身为最低位的 13，面前是低地址 0 和高地址 3，你应该把数据的头放在低地址还是把尾放在低地址？

更直观一些，假设我们要存储十六进制数 0x12345678，其中 12 是最高有效字节，相当于「千位」， 78 是最低有效字节，相当于「个位」。而我们会占用从 0x100 到 0x103 这四个地址。

人类的阅读习惯是从左到右，从大到小（例如数字），所以先把最大的头 12 放在最开始的低地址 0x100。

内存地址	`0x100`	`0x101`	`0x102`	`0x103`
存放内容	`12`	`34`	`56`	`78`

而小端序更符合计算逻辑。计算机在做加法时，是先算个位，再算十位。把最低位放在低地址（数据的起始地址），CPU 读取数据时，直接从起始地址就能拿到最低位开始运算。因此就会变成：

内存地址	`0x100`	`0x101`	`0x102`	`0x103`
存放内容	`78`	`56`	`34`	`12`

理解了小端序，就能解释为什么会出现 00700513 这样的内容。在 objdump 输出中，左侧的 13057000 是按照内存地址从低到高显示的： 13 （地址 N）， 05 （N+1）， 70 （N+2）， 00 （N + 3）。正因为是小端序，放在低地址（最左边）的 0x13 实际上是数值的最低位，而放在高地址（最右边）的 0x00 是最高位。

当 CPU 读取这 4 个字节组成一个 32 位整数（指令）时，它会按照权重将这些字节重新组装，最终形成符合人类书写习惯的大端数值 0x00700513 （高位在左）。

Disassembly of section .text 处是 objdump 将机器码翻译回汇编指令的结果，也是我们验证代码逻辑的核心区域。

100b0: 00700513 li a0,7

第一行指令中显示， 100b0 是指令的内存地址； 00700513 是 CPU 实际执行的 32 位机器码，也是上面提到的「被倒过来」的指令； li a0,7 是反汇编后的汇编代码。

我们源码写的是 addi x10, x0, 7，寄存器中 objdump 默认使用 ABI 名称， x10 寄存器在函数调用规范中用于传递参数或者返回值，因此被称为 a0 即 Argument/Return 0 的意思。

ABI 全称为 Application Binary Interface（应用程序二进制接口），是一套规范，定义了软件组件之间如何在机器码层面进行交互。它规定了每个寄存器的专用功能，其名称也可以让汇编代码更具可读性。

objdump 识别出 addi x10, x0, 7 的语义实际上就是「将立即数 7 加载到 a0 中」，因此它显示了更易读的伪指令 li（Load Immediate，加载立即数）。这两者在机器码层面是完全一样的。

100b4: 05d00893 li a7,93

第二行指令中显示， 05d00893 是机器码； li a7,93 对应的是源码中的 addi x17, x0, 93。

x17 的 ABI 别名是 a7。在 Linux RISC - V 系统调用规矩中， a7 寄存器用来存放系统调用号。 93 代表的是 exit 的系统调用。

100b8: 00000073 ecall

第三行指令中显示， 00000073 是 ecall 指令的固定机器码。

ecall 即 Environment Call，它会触发中断，将控制权交给操作系统内核。内核检查 a7 中的值（93），知道你要退出，然后检查 a0 中的值（7），将其作为退出状态码返回。

至于中间的 .riscv.attributes 部分，它是编译器留下的指纹。右侧的 ASCII 码显示了该程序编译时所使用的架构扩展列表。

qemu-riscv64 -g 1234 example

启动另一个终端来连接 GDB（目录需要是同一个）：

gdb -q example

当显示 (gdb) 时输入：

target remote :1234

我们可以使用命令 display /3i $pc 来打印内存信息。其中 3 代表着数量， i 代表着指令， $pc 则代表程序计数器寄存器，这个寄存器始终存储着 CPU 即将执行的下一条指令的内存地址。

1: x/3i $pc=> 0x100b0 <_start>:lia0,7   0x100b4 <_start+4>:lia7,93   0x100b8 <_start+8>:ecall

得出的结果中，带有箭头标记的一行就是当前 CPU 暂停的位置，也就是下一刻将被执行的指令。随后的两行则展示了未来的执行路径。

接下来可以使用 si 来命令 CPU 向前走一步，返回的结果中可以看到箭头出现在了下一行指令。

使用 c 来解除暂停，让 CPU 全速运行直到遇到下一个断点或者程序结束，我们就能看到返回码 7。

最后 q 来结束当前的 GDB 调试会话。

上述的所有没有解释明白的术语，在后续都有讲解。

教程中还提到了可以在 Visual Studio Code 中使用 PlatformIO 插件，不过我不用 Visual Studio Code，就不说了。

星光板

StarFive VisionFive（以下简称星光板）是一款基于 RISC - V 架构的单板计算机，相当于 RISC - V 版本的树莓派。

介于我手上没有这个物理开发板，和物理外设相关的代码我都无法运行，只当学习运算逻辑了。

教程中展示了如何在板子内调用生成 RISC - V 代码的工具，例如 as 和 gcc；在我这个 x86 电脑上，就只能使用 riscv64-linux-gnu-as 了。同理， ./example 这样的命令在 x86 电脑上要改用 qemu-riscv64 example。

在之前的步骤，我们的 GDB 会提示 (No debugging symbols found)，这是因为我们生成的只是纯粹的机器码。需要添加 -g 参数，汇编器才会将源代码的调试信息嵌入到生成的目标文件中。

riscv64-linux-gnu-as -g -o example.o example.sriscv64-linux-gnu-ld -o example example.o

接下来是关键的调试步骤。

打开终端 A，充当服务端：

qemu-riscv64 -g 1234 example

打开另一个终端 B，充当客户端。

客户端连接成功后，输入：

layout src

因为这次添加了 -g，我们会看到熟悉的源代码窗口，而不是汇编代码。

接着输入：

b 5

意思是在第 5 行打断点。

最后使用 c 命令，让程序全速运行，直到撞上第 5 行的断点并自动停下。此时输入：

info reg x10

会看到寄存器 x10 的值确实是 7。

指令集架构

ISA（Instruction Set Architecture，指令集架构）是软件与硬件之间的契约。它定义了处理器能够理解的所有操作指令（比方说加法、跳转、内存读写），以及处理器向软件暴露的状态。

RISC - V 的设计哲学是模块化的。基础指令集代表了 CPU 必须实现的最小功能集合。其他的扩展功能，如浮点运算，都是可选的插件。这与 x86 这种将所有功能捆绑在一起的架构并不相同。这意味着，只要掌握了基础指令集，代码就能在任何一个标准的 RISC - V 处理器上运行。

非特权指令集

现代处理器通常至少有两种运行模式：

特权模式：操作系统内核运行的模式，可以执行所有指令，包括管理硬件、中断和内存映射的指令；
非特权模式：普通应用程序运行的模式。

基础架构的分类

RISC - V 通过简单的命名规则来区分不同的基础架构变体：

RV：代表 RISC - V；
32 / 64 / 128：代表寄存器的位宽和地址空间的大小；
I：代表整数；
E：代表嵌入式。

RV64I 是目前我们正在使用的架构，因为工具链是 riscv64。它是 64 位的标准整数指令集。
RV32I 是 32 位的标准版本，在微控制器领域非常流行。
RV128I 是为未来设计的 128 位架构，用于应对未来海量内存寻址的需求。
RV32E 是为了极低成本、极低功耗的微控制器而设计的。它将寄存器数量从标准的 32 个砍到了 16 个，以节省芯片面积。

寄存器大小与地址空间

寄存器大小与地址空间是理解 32 位或 64 位计算机本质的关键。在 RV64I 中，通用寄存器（例如 x10）的物理宽度是 64 个比特，这意味着单一一条指令可以直接处理一个最大为 $2^{64} - 1$ 的整数。如果在 RV32I 上处理同样的数，就需要多条指令将其拆分处理。

寄存器的宽度也决定了指针的大小。在 RV32 中，指针是 32 位的，因此 CPU 最多只能寻址 $2^{32}$ 个字节的内存，即 4 GB。这对于现代桌面应用来说往往是不够的。在 RV64 中，指针是 64 位的，理论寻址空间高达 $2^{64}$ 字节，即 160 亿 GB，消除了内存容量的限制。

RV32I 的基础指令集仅包含 40 条指令，也就是说，只需要这 40 条最基本的指令就可以构建出所有的计算逻辑！

模块化命名规则

RISC - V 的设计允许通过组合不同的扩展模块来定制处理器的功能。

先前说过，RISC - V 处理器都必须至少支持一个基础整数指令集。在此基础上，处理器设计者可以选择添加额外的硬件功能，这些功能被称为扩展。处理器的完整型号就是「基础架构名 + 扩展后缀」。

这些是标准扩展代码：

M（Integer Multiplication and Division）：整数乘除法。硬件直接支持整数的乘法和除法运算。如果没有这个扩展，处理器需要通过软件算法模拟乘除法，速度会显著变慢；
A（Atomic Instructions）：原子指令。支持在单一操作中完成内存的「读取 - 修改 - 写入」过程。这对于多线程同步和并发控制至关重要，例如实现互斥锁；
F（Single-Precision Floating Point）：单精度浮点数。硬件支持 32 位浮点数运算；
D（Double-Precision Floating Point）：双精度浮点数。硬件支持 64 位浮点数运算。通常依赖于 F 扩展；
Q（Quad-Precision Floating Point）：四精度浮点数。硬件支持 128 位浮点数运算；
C（Compressed Instructions）：压缩指令。支持 16 位长度的指令，而标准 RISC - V 指令为 32 位。这可以显著减少程序占用的内存空间，提高代码密度；
V（Vector Operations）：向量操作。支持 SIMD（单指令多数据）操作，允许一条指令同时处理一组数据，常用于高性能计算和 AI 加速。

这里使用两个例子：

RV32IMAC：
- RV32I：基础是 32 位整数架构；
- M：支持硬件乘除法；
- A：支持原子操作；
- C：支持压缩指令；
- 但是不支持浮点运算，是一个纯整数处理器。
RV64IMAFDC（通常也被称为 RV64GC）：
- RV64I：基础是 64 位整数架构；
- 剩下的意味着它同时支持乘除法、原子操作、单 / 双精度浮点运算和压缩指令。这是一个全功能的通用处理器配置，类似于我们电脑内的 CPU。

某些情况下会出现 SU 后缀，例如 RV64IMAFDCSU。这两个字母不代表具体的运算指令，而是代表处理器支持的特权模式：

S（Supervisor Mode）：监管者模式。这是操作系统内核，如 Linux Kernel，运行所需的权限级别。支持 S 模式意味着该处理器有能力运行完整的操作系统；
U（User Mode）：用户模式。这是普通应用程序运行的受限权限级别。

因此，如果一个处理器列出了 S，事实就是它被设计为可以运行操作系统；如果只支持机器模式（也是默认都有的），则它通常只能运行简单的裸机代码。

硬件层面的寄存器结构

RISC - V 的基础指令集规定处理器必须包含 32 个通用整数寄存器，物理编号为 x0 到 x31。此外，还有一个独立的程序计数器 PC，用于记录当前正在执行的指令地址。

寄存器的位宽直接对应于基础架构的位数。在 RV32I 架构中，每个寄存器（x0 到 x31）和 PC 都是 32 位的（4 字节）；而在 RV64I 架构中，它们则是 64 位的（8 字节）。这意味着寄存器即用于存储参与运算的数据，也用于存储内存地址（指针）。

在硬件层面， x0 是一个特殊的寄存器。它被硬件强制硬连线位常数 0。无论程序向 x0 写入什么值，读取时得到的结果永远是 0。这是为了简化指令集，例如「将寄存器清零」或「移动数据」等操作都可以复用通用的算术指令，而无需设计专用的指令。

ABI

先前已经提到了 ABI，此处详细说一下 ABI 将寄存器按功能划分成了多少类：

特殊功能寄存器
- zero（x0）：恒为 0；
- ra （x1，Return Address）：返回地址寄存器。当发生函数调用（call）时，硬件会将「下一条指令的地址」自动保存到这里，以便函数执行完后能跳回原来的位置；
- sp （x2，Stack Pointer）：栈指针。指向当前栈顶的内存地址，用于管理函数调用栈；
- gp （x3，Global Pointer）和 tp （x4，Thread Pointer）：分别用于快速访问全局变量和线程本地存储。
函数调用与参数传递
- a0-a7 （x10-x17，Arguments）：参数寄存器。用于将参数传递给函数。其中 a0 和 a1 还兼职用于存储函数的返回值。如果参数超过 8 个，多余的参数通常会通过栈（内存）传递。
临时与保存寄存器
- t0-t6 （Temporaries）：临时寄存器。被调用函数（Callee）可以随意修改这些寄存器，不需要恢复原值。因此，调用者（Caller）如果想在函数调用后继续使用 t 寄存器里的值，必须自己在调用前保存它们；
- s0-s11 （Saved Registers）：保存寄存器。被调用函数必须保证这些寄存器的值在函数退出时与进入时一致。如果函数内部需要使用这些寄存器，必须先将旧值压入栈中保存，使用完后再从栈中恢复。其中 s0 有时也被用作 fp （Frame Pointer），即帧指针。

加载 - 存储架构

在 RISC - V 中，所有的算术和逻辑运算只能在寄存器之间进行。CPU 无法直接对内存中的数据执行加法操作。

如果想要修改内存中的一个变量，必须遵循严格的「三步走」流程：

Load：使用加载指令（如 lw）将数据从内存读取到某个通用寄存器中；
Compute：在寄存器内部使用算术指令（如 add）对数据进行计算；
Store：使用存储指令（如 sw）将计算结果从寄存器写回到内存中。

这种设计虽然使得单条指令的功能变弱了，比方说不能像 x86 的 add [eax] 5 那样一步到位，但简化了硬件电路设计，使指令流水线更加规整和高效。

以 addi 指令为例，用三个核心层级来讲解汇编指令如何被 CPU 执行、寄存器如何变化以及机器码在内存中的基本布局。

两个例子：

addi x1, x0, 1
addi x1, x1, 1

一、在指令层级上， addi 的全程是 Add Immediate（立即数加法）。它的标准语法格式是 addi rd, rs1, imm。

rd （Destination Register）：目标寄存器，用来存放计算结果；
rs1 （Source Register 1）：源寄存器，提供基础数值；
imm （Immediate）：立即数。这是一个直接写在指令里的常数，而不是从寄存器里读的。
- 限制：它必须是一个 12 位有符号整数。这意味着它的取值范围被限制在 $[-2048, 2047]$ 之间。

第一个例子取出了 x0 的值，并添加立即数 1，结果便是 $0 + 1 ` 1$ 。然后将这个结果 1 写入寄存器 x1= 。第二个例子取出 x1 当前的值，并添加立即数 1，结果是 $1 + 1 2$。然后将这个结果 2 写入寄存器 `x1=，实际上实现了自增的操作。

二、 PC 指针与步进。

在 RISC - V 的基础指令集中，每条指令的长度固定为 4 字节（32 位）。每当 CPU 取出一条指令后， PC 寄存器会自动加 4，使得 CPU 能够指向内存中的下一条指令。

三、内存与机器码层级上，代码到底是如何被存放的？

假设代码从地址 0x0 开始：

内存地址	机器码	对应的汇编
`0x0`	`0x00100093`	`addi x1, x0, 1`
`0x4`	`0x00108093`	`addi x1, x1, 1`

地址 0x0：存放第一条指令。执行时，CPU 处于地址 0x0，执行完后 PC 变为 0x4；
地址 0x4：存放第二条指令。因为上一条指令占了 4 个字节（0, 1, 2, 3），所以下一条指令必须从 4 开始。

执行流演示：

初始状态： PC 0x0=；
取指：CPU 读取地址 0x0 处的数据 00100093；
执行：解析为 addi x1, x0, 1。寄存器 x1 变为 1；
更新： PC 自动加 4，变为 0x4；
取指：CPU 读取地址 0x4 处的数据 00108093；
执行：解析为 addi x1, x1, 1。寄存器 x1 变为 2。

教程推荐使用 Ripes 模拟器来直观观看数据通路中，信号是如何流动的，以及 PC 指针是如何跳变的。

六大指令类型

基础指令集将所有功能划分为 6 种类型，每种类型对应一种特定的比特位布局：

类型	英文全称	中文含义	典型用途	示例指令
R	Register	寄存器型	纯寄存器之间的运算	`add x1, x2, x3`
I	Immediate	立即数型	寄存器与小常数运算，或加载内存	`addi x1, x0, 1`
S	Store	存储型	将数据存入内存	`sw x1, 0(x2)`
B	Branch	分支型	条件跳转	`beq x1, x2, label`
U	Upper	高位立即数	设置长立即数的高 20 位	`lui x1, 0x1000`
J	Jump	跳转型	无条件跳转	`jal , label`

根据先前的例子， addi x1, x0, 1 的机器码是 0x00100093。我们可以通过查表并结合已知信息推导出这个编码：

Opcode（操作码）： 0x13 （二进制 0010011）；
funct3（功能码）： 0x0 （二进制 000）；
Type（类型）：属于 I-type。

因此 addi x1, x0, 1 的机器码按位组合如下：

二进制序列： 0000 0000 0001 0000 0000 0000 1001 0011；
由于每 4 个二进制位可以转换为 1 个十六进制数字，最终结果就是 0x00100093。

要看懂这个解析，我们需要深入了解指令编码的具体布局。虽然 RISC - V 的指令长度固定为 32 位，但这 32 个比特并非随意排列，而是被划分为了不同的字段。每种指令类型都有其独特的字段排布方式。对于 addi 这种 I-type 指令，其 32 位数据的内部结构由高位到低位依次如下：

首先，其 32 位空间被分割为 5 个部分：

比特位置	`31:20`	`19:15`	`14:12`	`11:7`	`6:0`
字段名称	`imm[11:0]`	`rs1`	`funct3`	`rd`	操作码
含义	立即数	源寄存器	功能码	目标寄存器	操作码
长度	12 位	5 位	3 位	5 位	7 位

其次，我们将具体的汇编指令映射到上述结构中：

操作码：这是识别指令家族的。对于所有的 I-type 算术指令（如 addi 、 ori 等），操作码固定为 0010011 也就是十六进制的 0x13；
rd：指令中的目标是 x1。在二进制中，1 表示为 00001；
funct3：由于操作码定义了一组指令，我们需要额外的 3 位来区分具体是「加法」还是「异或」等。对于加法 addi，该值为 000；
rs1：指令中的源操作数是 x0。在二进制中，0 表示为 00000；
imm：我们要加的数值是 1。I-type 允许 12 位的有符号立即数，因此 1 表示为 000000000001。

最后，我们需要将上述二进制片段按顺序连接起来。值得注意的是，我们要用的是从高位 31 到低位 0 的顺序：

imm： 000000000001
rs1： 00000
funct3： 000
rd： 00001
操作码： 0010011

连在一起我们就得到了 32 位二进制流： 00000000000100000000000010010011。

为了将其转换成人类可读的十六进制，我们将这 32 位每 4 位分为一组进行转换：

二进制分组	0000	0000	0001	0000	0000	0000	1001	0011
十六进制值	0	0	1	0	0	0	9	3

最终组合结果为： 0x00100093。这就是机器真正看到并执行的内容！

其他类型的编码方式见下图：

立即数类型指令集中与算术、逻辑运算相关的具体指令

这些指令的一个共同特征是：它们都接受一个源寄存器和一个立即数作为输入，运算后将结果存入目标寄存器。所有这些指令共享同一个操作码，这意味着 CPU 是通过 funct3 字段，以及移位指令中的部分立即数位来区分具体是要执行加法、异或还是移位操作。

我们将这些指令分为三类进行讲解：

一、算术与逻辑运算。

这组指令对寄存器数值进行基础数字或位操作。

指令	全称	功能描述	关键点
<6>	<10>	<10>	<8>
`addi`	Add Immediate	`rd` rs1 + imm`	唯一的加法指令。RISC - V 没有专门的 `subi` 指令。因为立即数 `immi= 是有符号的（-2048 到 2047），如果你想做减法，只需加上一个复数即可。
`xori`	XOR Immediate	`rd` rs1 ^ imm=	按位异或。常用于翻转特定位。
`ori`	OR Immediate	`rd` rs1 \vert{} imm=	按位或。常用于将特定位置 1。
`andi`	AND Immediate	`rd` rs1 & imm=	按位与。常用于掩码操作（清零特定位）。
假设寄存器 `x1` 的值为 `0x9` （二进制 `1001`）。执行 `xori x1, x1, 0x3`：

源数据： 1001 （0x9）
立即数： 0011 （0x3）
异或结果： 1010 （0xA）
最终 x1 变为 0xA

二、移位运算。

移位指令用于将二进制位向左或向右移动。对于 I-Type 移位指令，立即数指定了移位的位数。

值得注意的是，移位指令在编码上比较特殊。由于移位量只需要 5 个比特，I-Type 指令原本 12 位的立即数空间被拆分了：低 5 位用于存移位量，高 7 位（imm[11:5]）被用来作为辅助功能码，区分逻辑移位和算术移位。

指令	全称	符号	填充规则
`slli`	Shift Left Logical Imm.	`<<`	逻辑左移；所有位向左移，低位（右侧）空出的位置补 0
`srli`	Shift Right Logical Imm.	`>>`	逻辑右移；所有位向右移，高位（左侧）空出的位置补 0
`srai`	Shift Right Arithmetic Imm.	`>>`	算术右移；所有位向右移，高位（左侧）空出的位置补符号位（即维持最高位不变）。适用于有符号数（补码），这能保证负数右移后依然是负数

作为一个例子，假设 x1 为 0x9 （1001）。执行 slli x1, x1, 0x2，即左移 2 位。原始内容是 00...001001，左移后变成 00...100100 （低位补了两个 0），等于 36，即十六进制 0x24。

三、比较运算。

这类指令用于数值比较，结果不是返回差值，而是返回布尔值 0 或者 1。

指令	全称	功能描述	区别
`slti`	Set Less Than Imm.	若 `rs1 < imm` 则 `rd=1`，否则 `0`	有符号比较。它将操作数视为补码。例如，它会认为 -1 小于 10
`sltiu`	Set Less Than Imm. Unsigned	若 `rs1 < imm` 则 `rd=1`，否则 `0`	无符号比较。它将操作视为纯正整数。例如，它会认为 -1，即全 1 的 `0xFFFFFFFF`，是一个巨大的正数，因此 -1 大于 10

寄存器类型

在先前的 I-Type（立即数型）指令中，指令的 32 个比特位被分配给了一个目标寄存器（rd）、一个源寄存器（rs1）和一个 12 位的立即数（imm）。当程序需要将两个都在寄存器中的变量进行运算时，I-Type 就无能为力了。因此，RISC - V 设计了 R-Type 格式。

指令名称	操作码	`funct3`	`funct7`	描述
`add`（加法）	`0110011`	`0x0`	`0x00`	`rd = rs1 + rs2`
#ERROR	`0110011`	`0x0`	`0x20`	`rd = rs1 - rs2`
`xor`（异或）	`0110011`	`0x4`	`0x00`	`rd = rs1 ^ rs2`
`or`（或）	`0110011`	`0x6`	`0x00`	`rd = rs1 \vert rs2`
`and`（与）	`0110011`	`0x7`	`0x00`	`rd = rs1 & rs2`
`sll`（逻辑左移）	`0110011`	`0x1`	`0x00`	`rd = rs1 << rs2`
`srl`（逻辑右移）	`0110011`	`0x5`	`0x00`	`rd = rs1 >> rs2`
`sra`（算术右移）	`0110011`	`0x5`	`0x20`	`rd = rs1 >> rs2`
`slt`（小于置位）	`0110011`	`0x2`	`0x00`	`rd = (rs1 < rs2)? 0:1`
`sltu`（无符号小于置位）	`0110011`	`0x3`	`0x00`	`rd = (rs1 < rs2)? 0:1`

R-Type 指令的物理编码结构将原本用于存放 12 位立即数的空间重新进行了分配。它划出了 5 个比特位用于指定第二个源寄存器（rs2），而剩余的 7 个比特位则被定位为 funct7 也叫 7 位功能码。所有的 R-Type 算术和逻辑指令都共享同一个基本的操作码，操作码为 0110011。CPU 首先读取操作码，得知这是一条 R-Type 算术指令，接着通过结合 funct3 和 funct7，才能最终确定具体要执行的硬件电路。

例如加法和减法。RISC - V 的 I-Type 指令中不存在 subi （立即数减法），因为程序员可以直接加上一个负的立即数。但是在纯寄存器运算中，加法和减法是截然不同的操作。在 R-Type 中，add 和 sub 拥有完全相同的操作码和 funct3，它们唯一的物理区别就在于 funct7 字段：add 的 funct7 为 0x00，而 sub 的 funct7 为 0x20。硬件编码器会捕捉到这一个比特位的差异，从而指示算术逻辑单元执行减法而不是加法。

这种 R-Type 架构同样适用于移位操作。在前面提到的立即数移位指令（如 slli）中，移位的步长是硬编码在指令里的常数。而在 R-Type 的移位指令中（sll、srl、sra）中，移位的步长来自于第二个源寄存器（rs2）的最低 5 个比特位。这意味着程序可以在运行时，动态计算并决定需要移位的具体位数，从而极大地提升了运算的灵活性。

依然是作为例子：

地址	机器码	汇编含义
`0x0`	`0x00100093`	`addi x1, x0, 1`
`0x4`	`0x00108093`	`addi x1, x1, 1`
`0x8`	`0x00108133`	`add x2, x1, x1`

程序计数器会从地址 0x0 启动，第一条 I-Type 指令将 x1 初始化为 1。随后 PC 步进至 0x4，第二条 I-Type 指令通过自增操作使 x1 的值更新为 2。当 PC 到达 0x8，CPU 读取并解码出第一条 R-Type 指令（add）。此时，指令指示 ALU 取出 rs1（即 x1，值为 2）和 rs2（依然是 x1，值为 2）的内容。ALU 执行加法后得到 4，并将该结果通过数据通路写回到目标寄存器 rd（即 x2）。至此，x2 的状态被确立为 4。

加载与存储

如何与主内存进行数据交换，以及如何高效地生成大型的 32 位常数和内存地址呢？

RISC - V 采用了严格的「加载 - 存储」架构。ALU 无法直接读取或修改内存中的数据。所有的运算必须在寄存器内完成。这就构成了数据流转的基本逻辑：使用 Load 指令将内存数据搬运到寄存器，在寄存器中计算完毕后，再使用 Store 指令将结果搬运回内存。

指令	名称	格式	操作码	`funct3`	描述
`lb`	加载字节	I	`0000011`	`0x0`	`rd = M[rs1+imm][7:0]`
`lh`	加载半字	I	`0000011`	`0x1`	`rd = M[rs1+imm][15:0]`
`lw`	加载字	I	`0000011`	`0x2`	`rd = M[rs1+imm][31:0]`
`lbu`	加载无符号字节	I	`0000011`	`0x4`	`rd = M[rs1+imm][7:0]`
`lhu`	加载无符号半字	I	`0000011`	`0x5`	`rd = M[rs1+imm][15:0]`
`sb`	存储字节	S	`0100011`	`0x0`	`M[rs1+imm][7:0] = rs2[7:0]`
`sh`	存储半字	S	`0100011`	`0x1`	`M[rs1+imm][15:0] = rs2[15:0]`
`sw`	存储字	S	`0100011`	`0x2`	`M[rs1+imm][31:0] = rs2[31:0]`

该表格列出了所有的 Load 和 Store 指令。这些指令的寻址模式被称为「基址寻址」。以语法 lb x2, 0(x1) 为例，括号内的 x1 是基址寄存器（rs1），提供了一个基础的内存地址；括号外的 0 是立即数偏移量（imm）。硬件会将 x1 的值与立即数相加，计算出最终的物理内存地址，然后从该地址读取数据存入 x2（rd）中。

对于 Load 指令，RISC - V 提供了按字节（8 位，lb）、半字（16 位，lh）和字（32 位，lw）加载的选项。由于目标寄存器总是 32 位的，当加载不足 32 位的数据（如 8 位的字节）时，就会出现高 24 位如何填充的问题。带有 u 后缀的指令（如 lbu，无符号加载）会在高位全部填充 0；而不带 u 的指令（如 lb，有符号加载）则会进行「符号扩展」，即将最高位（符号位）复制填充到所有的剩余高位中，以维持负数的数字意义。Store 指令则不需要区分符号，因为它们仅仅是截断寄存器中的低位数据，并覆盖到内存中，如 sb 只取寄存器的最低 8 位写入内存。

既然内存地址通常是一个 32 位的巨大数值，而基于 I-Type 和 S-Type 的指令只能容纳 12 位的立即数，我们该如何将一个 32 位的地址放入寄存器以便后续寻址呢？

早期的笨办法是通过复杂的算术运算。程序员被迫先用 addi 将 1 放入寄存器，然后再用 slli 将其左移 28 位，才能勉强凑出 0x10000000 这个地址。这种操作极其低效，且难以泛用。

为了解决这个问题，RISC - V 引入了 U-Type（Upper Immediate，高位立即数）指令格式。U-Type 指令舍弃了源寄存器字段，将立即数的可用空间直接扩展到了 20 位。

指令	名称	操作码	`funct3`	描述
`lui`	加载高位立即数	`0110111`	无	`rd = imm << 12`
`auipc`	将高位立即数加至 `PC`	`0010111`	无	`rd = PC + (imm << 12)`

lui 的硬件逻辑非常纯粹：它获取指令中提供的 20 位立即数，直接将其放置在目标寄存器的高 20 位（即向左移位 12 次），并将底部的 12 位强制清零。因为在十六进制中，每 4 个二进制等于 1 个十六进制字符，左移 12 位正好等同于在数字末尾追加 3 个零。这样，只需要一条 lui 指令，就可以极快地构造出 32 位数值的上半部分。

而 auipc 与 lui 机制类似，但多了一个步骤：它在将高 20 位就位后，会将其与当前的 PC 的值相加。在现代操作系统中，程序加载到内存的绝对地址往往是随机的，程序必须能够相对于其自身的位置去寻找变量。auipc 允许处理器以当前执行的指令地址为基准，向前或向后计算出相距甚远的数据地址。

控制流

在先前的学习中，我们已经知道 PC 在默认情况下会在每个时钟周期自动加 4，以此顺序执行内存中的指令。控制流的物理本质就是通过特定的条件或指令强行重写 PC 寄存器的值，从而改变指令获取的物理地址。

条件分支指令（B-Type）的核心机制是让 ALU 对两个源寄存器进行比较。如果满足指令规定的比较条件，硬件会将指令中携带的立即数与当前的 PC 值相加，并将这个计算结果强行写入 PC 寄存器，完成物理跳转。如果条件不满足，PC 则按常规加 4，继续执行内存中紧挨着的下一条指令。

在条件比较中，区分有符号和无符号至关重要。底层的机器码只是一串二进制位，没有内在的正负之分。

作为个例子：

地址	机器码	意思	注释
`0x00`	`0xffb00093`	`addi x1, x0, -5`	`x1 = -5`
`0x04`	`0x00500113`	`addi x2, x0, 5`	`x2 = 5`
`0x08`	`0x0020c463`	`blt x1, x2, 0x8`	`if (x1 < x2) pc = pc + 8`
`0x0c`	`0x00100193`	`addi x3, x0, 1`	`skipped if (x1 < x2): x3 = 1`
`0x10`	`0x00200193`	`addi x3, x0, 2`	`x3 = 2`

寄存器 x1 先是被赋予了 -5。在 32 位系统中，-5 的底层补码是以 1 开头的一串极长的数据（即 0xfffffffb），而 x2 是 5。当使用 blt 进行比较时，硬件逻辑会将最高位视为符号位，从而正确得出 -5 小于 5 的结论，并触发跳转。

但如果错用了 bltu，硬件会纯续从数值大小的角度将 0xfffffffb 视为一个巨大的正数，此时比较结果为假，程序就会错误地跳过分支。

除了基于条件的短距离跳转，RISC - V 还提供了用于实现函数调用和返回的无条件跳转指令，即 jal（Jump and Link）和 jalr（Jump and Link Register）。这类指令不仅要改变 PC 的值以实现跳转，还承担着「记录来处」的责任。

所谓的 Link（链接），指的是在覆盖 PC 寄存器之前，硬件会先将当前的 PC 值加上 4 保存到一个指定的目标寄存器中。这个被保存的地址就是返回地址。通过这种机制，程序在跳入一个代码片段执行完毕后，可以再次通过读取该寄存器的值跳回到最初离开的位置，这是实现程序模块化和复用的底层基础。

jal 和 jalr 的区别在于计算目标地址的方式。jal 属于 J-Type 指令，它将当前的 PC 值与指令中携带的大范围立即数相加来实现相对位置的跳转。而 jalr 属于 I-Type 指令，它通过读取一个源寄存器的值，加上立即数偏移量来计算跳转的绝对物理地址。

这是又一个例子：

地址	机器码	意思	注释
`0x00`	`0x00c000ef`	`jal x1, 0xc`	`set pc to 0x0 + 0xc = 0xc, x1 = pc + 4 = 0x4`
`0x04`	`0x00000013`	`addi x0, x0, 0`	无操作
`0x08`	`0x00010093`	`addi x1, x2, 0`	`set x1 = x2`
`0x0c`	`0x00008167`	`jalr x2, x1, 0`	`set pc to x1, x2 = pc + 4 = 0x10`
`0x10`	`0x00100093`	`addi x1, x0, 1`	`x1 = 1`

这是一个相对复杂点的跳转时序，实际上模拟了一个状态机的执行轨迹。程序从地址 0x00 开始，执行 jal x1, 0xc。此时 CPU 计算跳转目标为 0x00 加上 0xc 等于 0x0c，同时将返回地址 0x04 保存到寄存器 x1 中。

随后 PC 跳转至 0x0c，执行 jalr x2, x1, 0。此时 x1 的值为 0x04，因此跳转目标为 0x04 加上 0 等于 0x04。同时，这条指令需要保存新的返回地址，即当前的 0x0c 加上 4 等于 0x10，并将其写入寄存器 x2 中。

此时 PC 再次跳转回 0x04。0x04 处的指令是将 x0 加上 0，实际上是一条不改变任何物理状态的空操作。程序继续顺序执行到 0x08，这里的指令将 x2 的值（即刚才保存的 0x10）复制给 x1。

程序继续顺序执行，再次来到 0x0c。此时再次执行 jalr x2, x1, 0。由于在上一步，x1 的值已经被更新为 0x10，因此这次的跳转目标变成了 0x10 加上 0 等于 0x10。同时，新的返回地址 0x10 再次被写入 x2。

最终，PC 跳转至 0x10 执行加法指令。

系统接口

在现代计算机体系结构中，为了保证系统的稳定与安全，硬件在物理上划分了不同的运行模式。普通应用程序默认运行在权限极低的「用户模式」下，这种模式下的代码被物理电路限制，无法直接操作底层硬件。而操作系统内核运行在高权限的「监管者模式」或者「机器模式」下，拥有掌控所有物理资源的最高权限。

当运行在用户模式下的程序需要执行必须由高权限才能完成的动作时，就必须通过一种机制，在硬件层面上安全地将控制权移交给操作系统。ecall 指令就是为此而生的。

它在执行时，会在处理器内部触发一个同步异常。这个物理动作会瞬间打断当前用户程序的线性执行流，将 PC 的值强行替换为操作系统内核预先设定的异常处理程序的物理地址，并同时提升处理器的硬件特权级别。

然而，操作系统内核在接管控制权后，必须知道用户程序究竟想要请求什么服务。这就需要依靠 ABI 指定的寄存器契约。在 Linux RISC - V 的契约中，程序员必须在触发 ecall 之前，将特定的系统调用号放入指定的物理寄存器 x17（ABI 名称为 a7）中。内核被唤醒后，会第一时间去读取 a7 寄存器的电平状态，以此来决定分配哪一段内核代码去执行具体的任务。

教程中提供的例子正是描述了这样一个完整的系统调用物理过程，其具体内容如下表所示：

地址	机器码	意思	注释
`0x00`	`0x05d00893`	`addi x17, x0, 93`	设置 `a7 = 93`，对应 Linux 的 `exit` 系统调用
`0x04`	`0x00000073`	`ecall`	触发环境调用，将控制权移交系统内核

在这个执行序列中，程序首先位于内存地址 0x00。指令解码器将机器码 0x05d00893 翻译为 addi x17, x0, 93。硬件电路读取恒为 0 的 x0 寄存器，将其与立即数 93 相加，并将结果存在 x17 寄存器中，也就是 a7。在 Linux 内核的系统调用映射表中，数字 93 严格对应着 sys_exit 的服务。随后 PC 步进至 0x04，处理器读取并执行 ecall 指令。此时，硬件权限提升，Linux 内核介入，检查到 a7 寄存器内部的数据为 93，于是内核执行进程清理工作，彻底在内存中抹除该程序的运行状态。

另一个系统接口指令是 ebreak。与 ecall 移交控制权给操作系统不同，ebreak 的物理设计目的是将处理器的控制权移交给调试器。执行 ebreak 同样会触发一个异常，迫使 CPU 暂停当前的流水线工作。

不过程序员在编写汇编源码时，极少会手动写入 ebreak 指令。它的主要应用场景是在幕后由调试软件动态注入。当我们在调试器中对代码的某一行下达「打断点」的指令时，调试器会在物理内存中定位到该行代码对应的原始机器码，并将其悄悄替换为 ebreak 的机器码。

当微处理器的高速缓存读取并执行到这个被篡改的内存地址时，ebreak 触发异常，CPU 物理挂起，调试器趁机接管控制台，允许我们通过输入命令去查看各个寄存器内部的电平状态。当我们在调试器中输入继续运行的指令后，调试器会再次访问那段内存，将 ebreak 机器码抹除，并把原本正确的指令机器码填补回去，最后让 CPU 恢复物理运转。

内存排序

在现代微处理器架构中，为了极致追求物理执行效率，硬件通常会采用乱序执行技术，并配备多级高速缓存和存储缓冲区。这意味着，机器码在内存中的线性排列顺序，并不完全等同于 CPU 最终将计算结果写入主内存的物理时序。在单核处理器中，这种乱序执行对程序员是透明的，硬件内部的依赖检查机制会保证最终结果的正确性。

然而在拥有多个 RISC - V 硬件线程且共享同一块物理主内存的系统中，这种乱序写入会导致严重的同步问题。当核心 A 向共享内存写入一组数据，随后写入一个标志位表示数据已准备就绪时；核心 B 如果通过物理总线先预测到了标志位的改变，却因为核心 A 的缓存延迟而读取到了尚未更新的旧数据，就会引发并发程序的逻辑崩溃。

fence 指令的物理作用就是强制实施严格的内存访问顺序，以解决上述的可见性倒置问题。当微处理器的指令流水线读取到 fence 指令时，它会在硬件层面上将程序的执行流划分为两个绝对隔离的集合：位于 fence 之前的指令集合，以及位于 fence 之后的指令集合。

执行 fence 指令时，当前处理器核心会暂时挂起后续集合中所有涉及内存访问指令的执行。硬件控制电路会等待并确保，前序集合中的所有内存读写操作不仅在当前核心内执行完毕，而且其产生的电平状态改变必须通过系统总线被推送至全局，确保被系统内的所有其他物理核心准确观测到。只有在这一物理可见性保证达成之后，后续集合中的内存访问指令才被允许启动。

这种硬件级别的时序强制保证，是构建现代并发软件的基石。在操作系统的底层实现中，开发人员利用 fence 指令配合原子操作，来构建互斥锁等同步机制，从而确保多个进程或线程在操作共享内存区块时不会发生物理状态的竞态条件。

指令	名称	类型	操作码	`funct3`	描述
`fence`	Fence	I	`0001111`	`0x0`	`rd` 和 `rs1` 处于保留状态。针对所有内存访问类型的常规 `fence` 指令，其立即数 `imm = 0b000011111111`

根据该表，由于 fence 并不进行实际的算术数据搬运，其目标寄存器 rd 和源寄存器 rs1 在基础用法中被硬件忽略并保留为空。

该指令的核心在于其 12 位的立即数。在 fence 指令的微架构实现中，这 12 个比特位被精确划分为输入和输出两组掩码，用于细粒度地指定具体需要对哪种类型的设备的哪种操作进行强制排序。表格中给出的立即数（即十六进制的 0x0FF）是一个全为 1 的掩码。当硬件电路接收到这个特定的立即数序列时，它会执行最严格的「完全屏障」，即要求该屏障之前的所有类型的物理内存读写，必须先于该屏障之后的所有类型的物理内存读写完成全局同步。

M 扩展

在体系结构的底层设计中，基础整数指令集（RV32I）为了追求硅片面积的极简与低功耗，在物理电路上刻意移除了硬件乘法器和除法器。如果仅有基础指令集，微处理器在执行乘除法时必须依赖编译器生成的循环加法与位移指令软件算法，这会消耗大量的时钟周期。M 扩展代表着在处理器的硅片上实际蚀刻了专用的硬件乘法器和除法器逻辑电路，使得乘除法可以在极少的时钟周期内直接由硬件电路完成。

M 扩展包含的指令全部属于 R-Type 格式，这意味着所有参与运算的数据必须预先加载到通用寄存器中，且指令的操作码统一为 011011。硬件译码器通过识别 7 位功能码（funct7，M 扩展固定为 0x01，即 0000001）与 3 位功能码（funct3）的电平信号组合，来精确激活对应的乘除法物理电路。

指令	名称	`funct3`	描述
`mul`	Multiply	`0x0`	`rd = (rs1 * rs2)[31:0]`（取乘积的低 32 位）
`mulh`	Multiply High	`0x1`	`rd = (rs1 * rs2)[63:32]`（有符号乘法，取高 32 位）
`mulhsu`	Multiply High Sign/Uns.	`0x2`	`rd = (rs1 * rs2)[63:32]`（有符号与无符号乘法，取高 32 位）
`mulhu`	Multiply Unsigned	`0x3`	`rd = (rs1 * rs2)[63:32]`（无符号乘法，取高 32 位）
`div`	Divide	`0x4`	`rd = rs1 / rs2`（有符号除法，取商）
`divu`	Divide Unsigned	`0x5`	`rd = rs1 / rs2`（无符号除法，取商）
`rem`	Remainder	`0x6`	`rd = rs1 % rs2`（有符号除法，取余数）
`remu`	Remainder Unsigned	`0x7`	`rd = rs1 % rs2`（无符号除法，取余数）

这组指令设计的核心物理矛盾在于数据位宽的溢出。当物理电路执行两个 32 位整数的乘法运算时，其产生的最大物理输出结果需要 64 根导线，即 64 个比特位才能无损承载。

在 RV32 架构下，微处理器内部的单一通用寄存器物理位宽被硬性限制为 32 位。由于一个物理卡槽无法吞下 64 位的电平信号，硬件电路在输出时必须对数据进行物理截断。RISC - V 采用了两次读取的策略：mul 指令用于将硬件乘法器底部的 32 根导线（低 32 位）连接到目标寄存器；而 mulh 系列指令则用于将硬件乘法器顶部的 32 根导线（高 32 位）连接到目标目标寄存器。根据参与运算的数据是有符号补码还是无符号纯二进制，系统提供了不同的 mulh 变体以确保最高位（符号位）扩展时的物理正确性。

举个例子：

地址	机器码	意思	注释
`0x00`	`0x000100b7`	`lui x1, 0x10`	通过高位立即数加载，`x1` 的物理状态变为 `0x00010000`
`0x04`	`0x00108093`	`addi x1, x1, 1`	`x1` 与 1 相加，其状态确立为被乘数：`0x00010001`
`0x08`	`0x00080137`	`lui x2, 0x80`	`x2` 的物理状态被确立为乘数：`0x00080000`
`0x0c`	`0x022081b3`	`mul x3, x1, x2`	执行乘法，并将结果的低 32 位截断后存入 `x3`，此时 `x3 = 0x00080000`
`0x10`	`0x02209233`	`mulh x4, x1, x2`	执行乘法，将结果的高 32 位截断后存入 `x4`，此时 `x4 = 0x00000008`

程序首先利用 lui（向左偏移 12 位）和 addi 指令，在 x1 寄存器中构造了十六进制数值 0x00010001。随后通过 lui 在 x2 寄存器中构造了十六进制数值 0x00080000。

当在内存地址 0x0c 和 0x10 触发乘法运算时，硬件乘法器接收这两个 32 位的输入电平，在内部产生一个 64 位的完整结果。从数学逻辑上验算：0x00010001 乘以 0x00080000，其完整的 64 位十六进制结果为 0x0000000800080000。在地址 0x0c 处，mul 指令激活了捕获低 32 位信号的数据通路，将其引流至寄存器 x3，因此 x3 呈现为 0x00080000。在地址 0x10 处，mulh 指令重新执行乘法（在实际的高性能微架构实现中，乘法器可能会缓存上一次的 64 位结果以避免重复计算），并激活捕获高 32 位信号的通路引流至 x4，因此 x4 呈现为 0x00000008。此时，x4 和 x3 在物理上共同组合成了完整的 64 位乘积。

最后，教程指出了硬件除法器在面临「除数为零」这种未定义数学行为时的物理响应机制。在某些复杂的体系结构（如 x86）中，除以零会在硬件级别强行触发一个异常中断，迫使操作系统介入处理（通常表现为程序崩溃）。但在 RISC - V 架构中，为了维持处理单元和流水线控制逻辑的绝对精简，除以零被规定为一种不会引发物理中断的常规操作。当除法器电路接收到除数为 0 的电平信号时，其硬件连线会产生一个固定的输出：将目标寄存器内的所有物理比特位强制拉高至 1。全 1 的二进制状态在有符号补码逻辑中等同于数值 -1（即十六进制的 0xFFFFFFFF）。这就意味着，硬件将除以零的安全边界检查责任完全推卸给了软件。程序员或编译器必须在使用 div 指令之前，通过条件分支指令（如 beq rs2, x0, exception_label）主动探测除数寄存器的电平状态，以防止错误的 -1 污染后续的数据流计算。

RV64

RV64 架构的基础执行逻辑与 RV32 完全一致。这种一致性体现在操作码、指令寻址格式以及寄存器契约的完全复用上。其根本的物理变化在于微处理器内部数据通路的全面拓宽。在 RV64 架构中，微处理器内部的 32 个通用物理寄存器（x0 至 x31）、ALU 的内部逻辑门阵列，以及连接各部件的内部数据总线，其物理导线的数量都被硬性地增加到了 64 根。这意味着，当你在 RV64 上执行一条基础的 add 或 addi 指令时，硬件电路默认激活的是一个 64 位的全加器，它会同时处理 64 位的电平信号，并将 64 位的完整结果写回目标寄存器。

然而，计算体系中存在大量依赖 32 位物理边界的软件逻辑。例如 C 语言中标准 int 数据类型在大多数现代系统中被强制定义为 32 位。在纯粹的 32 位物理硬件上，当一个 int 类型的整数不断递增并超越其最大物理承载上限时，最高位的进位信号会因为没有更多的物理导线而自然丢失，从而精确的截断与符号位翻转（即溢出变成负数）。如果将这种运算直接放到 RV64 的 64 位加法器中执行，进位信号会顺理成章地流向第 33 根导线，数值会继续平滑增大，原本预期的 32 位溢出截断行为在物理上彻底失效了，这将导致严重的软件逻辑谬误。

为了在 64 位的物理硬件上精准模拟 32 位的截断环境，RV64 指令集专门引入了带有 w 后缀的指令子集。在 RISC - V 的标准术语中，「字」（Word，即 w）被严格且永久地定义为 32 个比特位，而 64 位的数据被称为「双字」（Doubleword）。教程中提到的 addw、addiw、sllw 和 mulw，就是专门针对 32 位电平信号设计的截断运算指令。

当微处理器的指令解码器读取到带有 w 后缀的机器码时，控制电路会向算术逻辑单元下达特定的屏蔽指令。此时，ALU 在获取源寄存器的数据时，会从物理上切断或忽略第 32 根至第 63 根导线的输入信号，仅仅提取寄存器最底部的 32 根导线（即低 32 位）的状态作为有效的运算输入。在 ALU 内部执行完纯粹的 32 位运算并得出结果后，硬件电路还需要完成最后一步关键的物理填充：符号扩展。

由于目标寄存器本质上仍然是一个 64 位的物理卡槽，ALU 不能仅仅将低 32 位的结果写回而任由高 32 位保留先前的垃圾电平信号。根据 RISC - V 的规范，硬件电路必须提取这 32 位运算结果的最高位（即第 31 根导线，符号位）的电平状态，并通过物理连线将其强行复制、覆盖到目标寄存器高段的全部 32 根导线上。这种由底层电路强制执行的符号扩展机制，确保了 32 位截断运算产生的数据，在被放回 64 位的寄存器空间后，依然能够维持其在数学逻辑上的正负一致性。

读《大闸蟹》

2026-02-23T05:00:00.000Z

这是陈昌平在零几年写的一篇短篇小说。

这篇小说整体来说，带有许多影射文革时代的内容。

故事开始，主角刘爱国从苏州回到辽北，带来了三只阳澄湖的大闸蟹。它们丰腴饱满，以至于刘爱国描述它们为「脑满肠肥的南方大地主」。

为什么是这样的比喻？这些大闸蟹来自于南方不假，但为什么要描述为「肥地主」呢？这便是这篇小说的一个特色，它采取了主人公刘爱国的视角，在生活的方方面面透露出经历过文革时代的人们如何看待这些地方。将「肥硕的东西」下意识想成是「肥地主」便是这样。实际上，历史上的地主能吃成「脑满肠肥」的并不多，会将「地主」和「脑满肠肥」绑定在一起的，通常是政治宣传。

除开中文课上教授提到的「文革」，我个人认为这篇小说里，出现的「地域」也是个重点。刘爱国看到蟹壳上印着激光防伪的标志，和经纪公司的信息，心想南方人有着出色的商品意识。

数十年前，我经常会接收到的一个信息便是中国的南北之争，例如一些文章说南方人喝茶谈生意，所以南方人更容易出大老板，而北方人喝酒吹牛皮，所以北方人更容易出败家子等等 —— 这样的观点现在听来自然是蠢到家了，不过在中国开始在南方建设经济区，以及北方下岗潮的引发，或许当时也会有人认为是这样吧。总之，「地域黑」永远是不可取的。

刘爱国担心这些大闸蟹是假货，于是拨号上网查阳澄湖大闸蟹的特征，并一一验证，发觉自己确实买的是真货。此处有意思的在于刘爱国的用词，他先是用了「验明正身」这个成语，接着称呼这些大闸蟹「根红苗正」。

「验明正身」指的是，查验死刑犯是否为其本人，毕竟执行死刑前可不能弄错人了。验证大闸蟹是否是阳澄湖的真货，有必要使用对死刑犯用的词儿吗？

再就是「根红苗正」。这个成语很简单，在文革时期意味着家庭出身好。那什么是家庭出身好的，那自然便是「红色的根」，也就是父母亲也是中国共产党的人了。所以这个成语也特指「中国共产党」。

刘爱国形容个大闸蟹，怎么口里蹦出来这么多这样的词儿？这是因为他是出生在文革时代的人，就连用词都受了那个时代的影响。

下一幕中，刘爱国给儿子打电话。小说先是特意提到儿子在省重点中学，还是市实验中学里住校上学，接着又是刻意说刘爱国打电话时，是在「向儿子报到」。

爸爸回来啦。爱国向儿子报到。
嗯。儿子的声音像领导一样稳重和漠然。
周末回家有好东西吃了。爱国抛出了主题。
什么东西？儿子声音一下子升高了。
你猜。爱国说。
嗯 —— 炸鸡翅。这是儿子喜欢吃的东西。
不是。
是…… 螃蟹。这是儿子更喜欢吃的东西。
爱国笑了。儿子马上明白了，大声问，是赤甲红还是梭子？馋儿子最喜欢吃的就是蟹子里的赤甲红了。
都不是。爱国笑吟吟地回答，顿了一下，又一字一句地说，这可不是一般的螃蟹啊，这是阳澄湖的大、闸、蟹！

陈昌平用了短短一个对话，便能让读者快速搞明白刘爱国和儿子之间的关系到底是什么样的。刘爱国又是要向儿子报到，又是说儿子的声音像个领导。而儿子起初的声音很是冷淡，好像并不关心父亲，直到父亲提到了好吃的东西，态度才变好。也就是说，刘爱国在家庭里，并没有所谓「父亲的尊严」，除非能向儿子提供好吃的。

之后儿子问了刘爱国什么是阳澄湖大闸蟹。刘爱国的脑海里出现了这样的思考流程：阳澄湖是著名的沙家浜，是阿庆嫂智斗的地方，但儿子不懂这些。如果用儿子懂的语言来说，赤甲红是桑塔纳，而大闸蟹是奔驰。

《沙家浜》是文革时期相当有名的八大样板戏之一。我没有看过样板戏，所以不评价了。不过在讨论这篇小说之前，中文课有个异步线上讨论，是和延安文艺座谈会有关的。那次讲话要求文艺工作者放下身态，走到底层群众中，用群众看得懂的形式创作。许多同学提到这个方案相当成功，不仅快速团结了底层群众，也影响到了后来中国文学创作的底色。

刘爱国的这个思考流程有这些值得思考的点：一、在他的认知图谱中，地理是被样板戏定义的；二、使用汽车品牌来划分螃蟹种类。不论是桑塔纳还是奔驰，都是物质符号。奔驰要比桑塔纳更为「高档」，且奔驰完全出自于德国公司，而桑塔纳是中国第一款合资车型。

「车」在刘爱国接下来的回忆中又出现了一次。儿子开学当天，刘爱国借了辆桑塔纳来接送儿子，未曾想学校门口全是好车，尾号一个比一个炫富 —— 但是一个学校能开来全市的好车么？刘爱国能借车，他人就不能借车了么？或许除了刘爱国有攀比心，其他人也想要攀比攀比。不过在刘爱国的心里，他在社会竞争中依然失败了，不仅买不起车，连借来的车都不如别人的高档。作为补偿，既然儿子爱吃的螃蟹还是买得起的，那不如等每次儿子回家，都买上只螃蟹犒劳犒劳。

次日，刘爱国发现大闸蟹丢失，急眼、只能一个个地方都找过去。有趣的是他找到的那些不是大闸蟹的东西：「失踪已久的结婚证」，意味着对婚姻的不重视；「爱国的中专毕业证」，文革期间学校不大上课的话，这个毕业证并不能代表刘爱国是否是「知识分子」；「儿子一年级时『最有意义的一天』」，我相信中国学生没少写过这类作文吧！刘爱国将它和其他重要文件收集起来，意味着他重视儿子的教育，以及这可能是儿子第一次一个人写作文，具有一定的意义；「洗衣机的保修单」，在二十一世纪刚开始的时候，买得起洗衣机并不常见，想必也是一种资产上的炫耀吧。

最后一个则是：

甚至还找到了爱国二十多年前的日记本。日记本是红色的塑料皮，发硬了，上面印着烫金的「为人民服务」，洇着蓝钢笔水的扉页上，中学生刘爱国歪扭而又工整地抄录着《钢铁是怎样炼成的》里面的一段话 —— 人的一生应当这样度过：回首往事，他不会因为虚度年华而悔恨，也不会因为碌碌不为而羞愧；临死的时候，他能够说：我的整个生命和全部精力，都…… 以下的字被墨水淹没了。

被墨水淹没的后续虽然小说里没有提到，不过其实是：

已经献给世界上最壮丽的事业 —— 为人类的解放而斗争。

有些同学读过这本书，因为它是学校的必读书籍之一。不过我没有读过这本书，只是上学期间听说过。教授借此扩展了下话题，告诉我们它在文革期间其实是禁书，因为它的作者是苏联人，而当时中苏的关系并不好。但《钢铁是怎样炼成的》的中译本在学生之间很是有名，早就偷偷传开了。大家不仅会偷读，还会手抄下来。

说回小说的内容。很明显，这本日记本的存在暗示了刘爱国小时候的理想主义早已在琐碎且物欲的现实生活面前变得模糊不清：它有大闸蟹重要么？能让人吃好饭么？

刘爱国出门找大闸蟹时，陈昌平又描写了他所居住的桃源小区：一个典型的北方重工业城市中的普通居住区。文中提到的「安居工程」是中国政府为中低收入城市居民实施的保障性住房项目，点明了刘爱国并不宽裕的工薪阶层角色 —— 实际上，先前有很多地方都介绍了他的背景，并不是一个多么富足的人。

陈昌平也强调了刘爱国在此居住七八年却与邻居毫无来往，揭示了现代城市生活中的人际疏离。这倒也解释了后续发生的种种。

刘爱国上班去，知道同样买了阳澄湖大闸蟹的大李子不仅吃了，还对此给出了极高的评价，心里不舒坦。中午儿子罕见地主动打电话回来，询问大闸蟹怎样，让他的心情又变差了不少。挂了电话，他跑去上海菜馆看大闸蟹，却发现里面的螃蟹和大闸蟹没有一点共同特征，领班还强行将它们标榜为「最正宗的大闸蟹」，并以此贬低其他产地的河蟹。这种推销让刘爱国确信，这座北方老工业城市里的人根本不具备鉴赏南方高档消费品的认知水平。

从这里之后，才是这篇小说的「正文」。刘爱国在公告栏上贴了个启事，希望拾到自己蟹子的人可以归还给自己。谁曾想，来的是来纠正语病的孙老师，蟹子的下落依然不知道。这一段再次呼应和坐实了先前「人际关系冷漠」的描写。孙老师作为刘爱国自认「最熟悉的邻居」，其所谓的「热心」仅仅停留在居高临下的知识纠错与说教层面，对刘爱国丢失物品的实际焦虑毫无共情。

被当面指出低级错误也让刘爱国感到了文化与体面上的双重难堪。先前就已经暗示过，刘爱国已经在家庭和社会层面上「失败」了。再加上孙老师对「几只蟹子」轻描淡写的态度，极大地刺激了刘爱国：在这个小区里，大众根本不具备识别阳澄湖大闸蟹高贵身份的认知能力。这两种感觉都迫使刘爱国重新打印了一份更加周密和庄重的第二版启事。

实际上，在教授讲解前，我对小灵通没有一个实际的概念，一直以为它是类似于诺基亚那样的手机品牌。其实它是一种无线通信工具，或者说是当地固定电话网络的无线延伸。另一个我不知道，但教授没有讲解的东西是「红塔山」，后面查了一下发现是中高档香烟。

贴完第二版启事后，刘爱国发现小区垃圾箱里有一个红色的蟹子壳，正是自己丢失的其中一只，已经被人吃干净了。邻居们的冷漠此时展示了出来：就算看到了刘爱国贴的启事，也不选择归还，反而是自己吃掉。

陈昌平在此处立刻描写了辽北的衰败现状。这座衰落，且物质相对匮乏的北方城市，与代表着南方精致生活和经济繁荣的阳澄湖大闸蟹形成了反差：大闸蟹在辽北的垃圾箱中竟惨遭粗暴对待并沦为残骸！要知道它在刘爱国心里，除了是高贵的食物外，还是刘爱国作为一个父亲的骄傲、对儿子的承诺。他鼻子一酸，心里骂自己没出息，这种生理上的悲伤反应让他感到羞耻。

回家后，刘爱国在启事的后面加了个附录，试图指导捡到剩余两只大闸蟹的人正确保存它们，以防它们在被归还前死亡，毕竟大闸蟹死后就不能吃了，儿子还有两天才回来呢。戏剧性的是，当他贴上附录后，他便看到了第二只被吃掉的大闸蟹 —— 这只螃蟹被吃得乱七八糟，好多肉都没吃干净，简直是暴殄天物。

愤怒的刘爱国接到了儿子主动打来的第二通电话。面对儿子那句「大闸蟹到底是什么滋味儿呢」，刘爱国罕见地呵斥了儿子。他不仅弄丢了原打算犒劳儿子的昂贵礼物，甚至连他自己也无从知晓这代表着阶层品味的大闸蟹究竟是何滋味儿。儿子的期待成了一种精神上的压迫，让他无法继续维系那个能为后代提供高级物质体验的父亲形象，这样的无力感，令他无处宣泄情绪，失控地攻击了儿子。

另一边，大闸蟹的象征意义逐渐发生了异化。起初它只是作为纯粹的犒劳物品存在的，然而随着它的丢失及其惨遭邻居随意丢弃，它脱离了单纯的食物属性，变成了刘爱国个人尊严以及对抗周围庸俗环境的心理寄托。当刘爱国发现大闸蟹被以极不讲究的方式糟蹋时，他感受到的是自身向往的精致生活被碾碎的屈辱。因此，他后期的所有偏执行为，都演变成了一场捍卫个人尊严的自救。就如他自己所说的，「这已经不是为了儿子了。」

刘爱国做了一份重要启事，整理了阳澄湖大闸蟹的所有知识，其字里行间的庄严感，与当年抄写革命宣言时的虔诚恐怕如出一辙吧。下班回来，他变态般地扒拉着小区的垃圾箱，并在旁边找到了一只完整的蟹子：天啊，它竟然在没有蟹八件的北方，被吃得很规范、很圆满、很精彩、很成功、很伟大！刘爱国满意、得意，又反省自己能不能像这个邻居一样，吃出如此美丽的大闸蟹。

在刘爱国这么想的时候，他还会在乎共产主义么？

周末儿子回来的那天，刘爱国买了三只赤甲红回家，好似大闸蟹是一场梦 —— 一场试图依靠消费符号来跨越阶级的梦。

4 个字符为一组构成的城市

2026-02-16T05:00:00.000Z

从小时候记事起，我就有一个奇怪的习惯，那就是看到商店招牌，会自动将上面的字符以 4 个一组的形式排列起来。

比方说「江南皮革厂倒闭了，老板黄鹤带着小姨子跑路了」，在我的眼里会变成：

江南皮革厂倒闭了，老板黄鹤带着小姨子跑路了

正好多出来 1 个字符。

多出来的内容会让小时候的我感到既不开心，也不舒服。为了让自己开心起来，有时候我会强行将限制改成 3 个或者 5 个字符一组。这样做并不是特别容易，因为 4 个字符一组已经是我脑内的标准，突然换成别的总感觉怪怪的。

之后我常用的伎俩便是将余数加入到下一个招牌的计算中。

假设下一个招牌的内容是「我要金坷垃，非洲农业不发达，必须要有，金坷垃！」，那么排列就会加上刚才多出来的「了」：

了我要金坷垃，非洲农业不发达，必须要有，金坷垃！

哎，这下就可以被 4 整除了，内心一下子开心起来~

通常来说，我都是在乘车期间进行这些脑内操作的，比如跟着大人们坐出租车去什么地方，或者坐在电动车上，望着远处。我自小居住在一个城市里，无论是往哪边看去，都可以看到带有招牌的店铺。坐车是无聊的，为了让自己不无聊，我自行研发了这种小游戏，好让自己在什么时候都能游玩 —— 会这么说，是因为在我的记忆中，这种行为慢慢地也渗透到我的其他生活里：小时候翻开课本时，我会扫视一番页面上的内容，快速将里面的字符根据 4 个字符一组的方式排序。

现在想来，为什么孩童时期的我要这么做呢？不知道从什么时候开始，我看商店招牌再也不会去想要将字符分成 4 个一组了，乘车时望向窗外也只会发呆。

能够确认的是，它是我的强迫行为的一种。我小时候总是有一些现在看来都觉得莫名其妙的「秩序」，比方说喝粥时绝对不能在里面放任何东西。如果大人往我的碗里夹了肉或者榨菜，又或者不小心滴了点酱料进去，我会很难过，认为我的粥被玷污了、不再纯净。

我已经很难记起小时生活的点点滴滴，自然也不知道那时候的我是怎么想的、经历了什么才会这么想，所以我还是不揣测自己了吧。但我可以感觉出，我是一个很轴的人，且只生活在自己的世界里：一套独属于自己的逻辑，外界对我而言并不重要，因为是它们不遵守我的规则在先。

不过随着年龄的增长，经历了一个又一个事情，发现这个世界就是存在着余数、绝大多数事物都是无法被完美整除的 —— 有些能不能被「除」都是个问题。白粥也不可避免地会沾染上其他味道，毕竟再去取一个碟子装榨菜意味着需要多洗一个餐具。

现实总是塞满了需要我去重新适应的全新事物，而这些问题远比招牌上多出来的字符庞杂得多。所以那个坐在电动车后座的小孩，最好还是连同她那套规则一起，留在那条以 4 个字符一组构成的街道吧。

Bonus

最近我知道了 BlogBlog 同乐会，相当于中文版的 IndieWeb Carnival。或许初来乍到的你也不知道 IndieWeb Carnival 是什么。简单来说，它是一个每月根据主办方提出的主题，让参与者们在自己的个人网站上发布该主题的博文，并投稿给主办方的活动。

这个月 BlogBlog 同乐会的主题是「只有我这样吗？！」。我心想该主题还蛮有趣的，所以快速动笔写了一下。不过写到后面，总感觉有些偏题 —— 应该没有关系吧，因为成年人的世界总是不遵守规矩的！

玩《茂林源记》

2026-02-15T05:00:00.000Z

《茂林源记》，或称 Root（以下也这么称呼），是一个区域控制类桌游。虽然这么说，但它的标签还是很多的，例如德式桌游标准的得分制、应该被划分给美式桌游的阵营机制等等。我先前为这款游戏写过一些评价，本来没有打算继续去写该游戏的说明，但介于自己刚写了个扫雷的入门说明，最终还是写下了这篇文章。

首先需要说明，桌游和其他电子游戏一样，是一个很大的类。休闲的桌游，如爆炸猫，跟大型的桌游，如很知名的 D & D，区别是很大很大的。在决定游玩 Root 之前，请务必考虑一下自己到底是什么桌游玩家 —— 愿意花时间钻研吗？愿意仔细阅读说明书，且游玩期间遇到不懂的地方也会去认真查询吗？

问这些问题的原因是，Root 其实卡在一个颇为尴尬的地方：它既没有大型桌游那么难懂，但入门门槛也足以劝退休闲玩家。这也是为什么我很难线下跟他人玩 Root，愿意尝试的就不多，看到说明书和规则书的还想继续玩的是少数；最麻烦的是教完一个人规则和至少一个阵营后，天也暗了，大家没有那么多空闲时间，只能等几个月再约。

好啦虽然我抛出了这么多预警，对于依然想要继续学习的你们来说，Root 可能并没有那么可怕！实际上，就像我刚才说的，它无法跟更大的桌游比较。既然只需要一天就能教会一个新人，它的困难程度可想而知，并没有那么高，难的地方只是它的阵营机制。

说了这么多，让我们回归正题吧，一起进入这片广大的茂林吧！

基础规则

Root 里，每个阵营的回合都结束后，一轮才算结束。也就是说，玩家甲开始回合，到玩家乙的回合结束，这算一轮。每个阵营的回合会经历三个阶段，也是三个时间段：清晨、白天和晚上。在这三个阶段里，不同阵营能够做的事情都不相同。

通常而言，在设置期间，每个玩家会获得自己的阵营板、阵营所需要的所有米宝和令牌，以及 3 张牌。说到卡牌，该游戏有三个基础类型，或者说领地类型：老鼠、兔子和狐狸，他们是这个森林里的老百姓，更详细的背景设定我之后会补充。该游戏的大多数卡牌都需要锻造后才能发挥作用。在 Root 里，如果手牌超过 5 张，就必须在晚上阶段结束时丢弃直到手上只有 5 张牌。

地图上的地点和路线都是固定的，不过地点的类型可以随机，不过我个人推荐在学会游玩 Root 之前，只玩它的默认地图，因为类型分布最为平均。

必须要记住的是，Root 是一个区域控制游戏，「占领的领地」和地点是两个不同的概念。当你的士兵米宝和建筑物在一个地点上，数量超过其他阵营的士兵和建筑物，就算占领了该地点。当移动士兵时，出发地点和目标地点必须至少有一个在你进行移动之前、被你的阵营占领。这是 Root 在移动士兵上的基础规则。一次可以移动的士兵数量是随意的，想要移动多少就移动多少。

再就是「建筑物」，查看地图时你会发现，地点上都有数个空格，这些便是放置建筑物的格子。当一个地点上没有空闲的建筑物格子，玩家们就不可以在该地点上放置更多的建筑物了。建筑物并不属于令牌的一种，令牌是圆形的，建筑物是方形的。建筑物在计算占领权会被算上，令牌则不算。

战斗需要用到两个骰子，这两个骰子都只能投出 0/1/2/3 这四个点数。假设玩家甲和乙丢出了 1 和 3 这两个点数，且甲和乙在这个地点上的士兵数量分别是 2 和 3。在 Root 的战斗中，发起战斗的一方会取点数最大的那个骰子，被攻击的一方则拿点数最小的骰子 —— 乙作为攻击方，一共有 3 个士兵，点数也是 3，这意味着他的 3 个士兵都可以各杀死一个敌人。尽管甲的士兵数量是 2，但拿到的 1 点数让他只能让 1 个士兵杀死一个敌人。结果就是，乙的 3 个士兵杀死了甲的 2 个士兵，多出了 1 次攻击，而甲的 1 个士兵杀死了乙的 1 个士兵。

当地点上的士兵都死掉了，多出来的攻击会算给令牌和建筑物。它们都不具备攻击能力，所以也无法战斗。如果攻击方攻击的地点上只有对方的令牌或者建筑物，那么无论投出多少点的骰子，都会另加 1 点伤害。并且，只要有 1 个令牌或者建筑物被摧毁，攻击者都可以额外拿取 1 分。如果有多个令牌或者建筑物，那么由被攻击的一方决定哪一个应当被移除。

要在 Root 里获胜，通常是靠先得到 30 分。至于如何得分，每个阵营的方式也都不一样。所以可以看出来，该游戏的绝大多内容都在阵营上，而因为阵营除了游侠这个特殊阵营外都不能重复，所以在游玩自己的阵营时，也需要提防他人的阵营得分。这也是 Root 入门时的难点： 记住所有阵营的机制和得分方法。

阵营机制说明

猫女侯爵

也有翻译称其为「猫咪贵族」。在原文中用的 marquis 其实是法语的「女侯爵」的意思，这里就保留这层意思吧，不过后面都会简称为「猫咪」就是了。

猫咪们在打跑了原本统治了森林的「飞鹰王朝」后，决心一路向工业化进发 —— 砍树盖房子！猫咪可以放置三个种类的建筑物，且加分方式是靠放置建筑物。

猫咪在开局阶段里优先级最高，可以选择地图上的任意一个角落作为自己城堡的落脚点，然后可以在城堡所在的地点或者相邻的地点内免费放置一个伐木场、一个工坊，和一个招兵所。

我用了「免费」这个词，为什么呢，因为是「砍树」盖房子，原先这些建筑物都需要使用「木材」才能建造。木材作为一个令牌，又该如何获取呢？答案是靠猫咪的伐木场。嗯，这下便好理解了：猫咪通过建造伐木场来获取木材，又消耗木材来建造建筑物，建造建筑物还能加分，且场上相同类型的建筑物盖得越多、加分越多。这便是猫咪主要的玩法。

猫咪的士兵足足有 25 个，到后面我介绍越来越多的阵营时，你便会发现这个数量有多么夸张。开局阶段里，猫咪需要在地图的所有地点上放置一个士兵，除了城堡斜对面的那一个角落。

清晨阶段，猫咪只能做一件事，那便是在场上所有伐木场所在的地点放置一个木材令牌，相当于每个伐木场都砍到了木头。白天阶段里则分两个步骤：一是激活场上的工坊来锻造卡牌，二是按照任意顺序和组合执行最多三项操作。

先说猫咪的锻造。卡牌的锻造条件都要求一个阵营的可锻造单位有足够的数量，且位于正确的地点类型。比方说有一张牌要求有两个兔子类型，那对于猫咪而言，就需要在兔子类型的地点内先建造两个工坊，才能锻造该卡牌。这些可锻造单位，一回合只能使用一次。这对猫咪来说，不是一个好兆头，因为锻造卡牌之前，猫咪需要先消耗木头和行动次数来建造建筑物。

再来说猫咪的行动：战斗、行军、招募、建造建筑物、加班。

其中战斗没什么好说的，剩下三个都有着猫咪自己的特色。行军是加强的移动，一次行军相当于移动两次，且移动时仍然可以随意决定要移动的士兵数量；招募会在每个招兵所所在的地点放置一个新士兵，不过该操作 每个回合只能执行一次。

建造建筑物需要单独拉出来说。一个玩家们经常忘记的猫咪规则是，想要建造建筑物的地点首先得是被猫咪占领的，且该地点需要和木材所在的地点形成一条完全被猫咪占领的路线才行。也就是说，木材必须从猫咪占领的地点，通过一系列也被猫咪占领的地点，才能抵达猫咪打算建造建筑物的已被占领地点。接着玩家需要在阵营板上选择建造哪一个建筑物、查看该建筑物如果被建造了需要消耗多少木材（每个类型的建筑物所需要的木材以及得到的分数都是独立开来的），并消耗这些木材。

猫咪也可以通过消耗一张手牌里的飞鹰类型的卡牌来为自己添加一次额外的操作次数。咦，什么是飞鹰类型？这是有别于基础三类型的第四个类型，对许多阵营而言，它可以被当成是「任意一个类型」，相当特殊。

至于加班，它需要你选中一个伐木场，并根据该伐木场所在的地点类型，消耗一张同类型的卡牌来获取一个木材令牌。因为飞鹰卡牌可以被视作任意一个类型，所以也可以用在这里。

到晚上阶段，猫咪需要补充一张手牌。如果招兵所被建造得够多，你会根据阵营板上的卡牌图标而获取额外的手牌。

最后说一下猫咪的被动技能：其他阵营不能在城堡所在的地点内放置任何令牌或者建筑物或者士兵，他们只能将士兵移动到该地点。每当任意数量的猫咪士兵从一个地点中被移除，猫咪可以选择消耗一张匹配该地点类型的卡牌，将这些被移除的士兵放置在城堡所在的地点。如果城堡被移除，它会在该局游戏内完全被移除，拿不回来。

飞鹰王朝

Eyrie 虽然是鹰巢的意思，但是「鹰巢王朝」总感觉不好听，故使用官方翻译「飞鹰王朝」。

飞鹰是森林过去的霸主，被猫咪打跑后，希望通过重新占领领地，来恢复自己的尊严。不过他们也是一个强迫症种族，每日的行动必须完全遵守「法令」的顺序，否则民众会陷入混乱、推翻当下的领袖。

清晨阶段按照顺序分为三个步骤：一、如果没有手牌，则抽一张牌；二、必须将手牌的一张或两张牌添加到法令区中，但只能有一张是飞鹰牌；三、如果地图上没有鸟巢建筑物，则在一个有最少士兵的空地上放置一个鸟巢和三个士兵。

白天阶段按照顺序分为两个步骤：一、激活鸟巢锻造卡牌；二、必须严格从最左边的列开始，向右依次结算法令。

不过在说明法令如何运作之前，我们需要先看一眼飞鹰的开局阶段。在游戏开始时，飞鹰玩家需要从四张领袖卡牌中选择一张作为初始领袖放置在阵营板上。每位领袖不仅拥有一个独特的被动技能，决定了两张初始大臣卡牌（两张固定视为飞鹰类型的卡牌）在法令区四个列中的初始位置。选定领袖后，飞鹰需要在地图上猫咪城堡斜对角的那个地点，放置一个鸟巢以及六个士兵。

该阵营最为重要的机制有且只有一个：法令。飞鹰的阵营板上有一个分为四个栏位的法令区，从左到右依次为招募、移动、战斗和建造。在每一个单独的列中，如果有两张或以上的卡牌，玩家可以按任意顺序解决该列里的所有牌，但对于每一张牌，玩家都必须切实执行其所在列对应的操作。

招募要求玩家在带有与卡牌类型相符、且已经建有鸟巢的地点上放置一个士兵；移动要求玩家从与卡牌类型相符的地点出发，移动至少一个士兵到其他相邻地点，前提是移动的基础条件可以被满足；战斗要求玩家在带有与卡牌类型相符的地点上，主动发起一场战斗；建造要求玩家在一个被自己占领、卡牌类型相符且当前没有鸟巢的地点上，放置一个新的鸟巢。

这一机制是极其死板的。如果在解决法令的过程中，玩家因为版图局势或者自身资源限制，无法完全执行某一张卡牌对应的一项操作，飞鹰就会立即陷入动乱 —— 当天的白天阶段会被立即强制中止。玩家会因为法令区中包含的每一张飞鹰类型的卡牌而失去 1 分，飞鹰也是唯一一个会在游戏中失去分数的阵营。随后，整个法令区除了两张初始的大臣卡牌外，所有的手牌都会被清空弃置。触发动乱的现任领袖必须下台，玩家需要从备选的领袖中挑选一位接任。新领袖的上台会改变初始卡牌所在的列数位置，玩家也必须在接下来的回合里重新构筑整个行动链条。

如果飞鹰成功且完整地解决了白天的所有法令，便能顺利进入晚上阶段，这也是其核心的得分环节。飞鹰会根据地图上现存的鸟巢总数，直接获取阵营板上对应位置标明的分数。鸟巢铺设得越多，每回合自动获取的分数就越高。计分结束后，飞鹰进行手牌抽取，抽牌的具体数量同样由版图上的鸟巢数量决定。

最后说一下飞鹰的被动技能。作为森林过去的领主，当一个地点上飞鹰的士兵以及建筑物的数量，和其他阵营的士兵以及建筑物的数量，相同时，默认飞鹰占领该领地。飞鹰也藐视贸易，锻造物品时会忽略列出的分数，而只获得 1 分。

森林联盟

在猫咪和飞鹰天天打架的时候，森林的老百姓坐不住了…… 联盟需要努力赢得森林里对现状不满的各种动物的同情，大家联合起来，将女侯爵还是王朝都赶出森林！

森林联盟是一个起步极晚但爆发力极强的阵营。与其他阵营不同，联盟在开局阶段的地图上没有任何实质性的棋子，只有阵营板上的 3 个基地、10 个民意令牌以及 10 个士兵。

联盟的运作高度依赖一个独立于玩家手牌的特殊卡牌区域 —— 支持者牌堆。支持者牌堆里的卡牌面朝下放置，不计入手牌上限，只有联盟玩家可以查看，且专门用来执行联盟的核心行动。如果联盟在地图上没有建立任何基地，该牌堆的容量上限仅有 5 张，超出部分必须被直接弃置；而一旦地图上存在至少一个联盟基地，支持者牌堆的容量便没有限制。

联盟拥有两个让其他阵营极为头疼的被动技能。首先是民意机制。每当其他玩家移除了地图上的民意令牌，或者将任何士兵移动到一个有民意的地点时，该玩家必须从自己的手牌中强制上交一张与该地点类型相符的卡牌，并将其加入联盟的支持者牌堆。如果该玩家手中没有对应类型的卡牌或者飞鹰卡牌，则必须向联盟玩家展示手牌自证，随后联盟会从公共牌堆顶部抽取一张牌加入支持者牌堆。

另一个被动技能是「游击战」。这是整个 Root 游戏中，强度最为可怕的被动技能：在所有战斗中，只要联盟是作为防守方被攻击，那么联盟始终会拿取点数较大的骰子作为自己的命中数，而攻击方只能拿取较小的骰子。这意味着主动攻击联盟很多时候只会被联盟反杀。

既然提到了骰子，我想要再深入讲解一下 Root 骰子的机制。已知每枚骰子有四个面，点数是 0/1/2/3，因此投掷结果是由两枚骰子组成的 16 种等概率组合构成的样本空间。在这个样本空间中，取最大值的概率分布是不均匀的。两枚骰子最大值为 0 的组合仅有 $(0,0)$ 这一种，概率为 $1/16$ ；最大值为 $1$ 的组合有 3 种，概率为 $3/16$ ；最大值为 $2$ 的组合有 5 种，概率为 $5/16$ ；而最大值为 3 的组合最多，共有 $7$ 种，概率为 $7/16$ 。

也就是说，掷出 2 点和 3 点的概率加在一起，正好是 75%。如果计算较大值的数学期望，就会是 2.125，而较小值的数学期望仅为 0.875。在基础规则下，主动进攻方有着绝对的火力优势，然而「游击战」强制反转了这一判定规则。只要森林联盟作为防守方被攻击，从概率论的角度来看，这一反转让攻击方的单次命中期望瞬间从 2.125 骤降直 0.875，而联盟的防守反击期望则从 0.875 飙升至 2.125。

清晨阶段是联盟扩张与爆发的核心时间段，分为「起义」和「散播民意」两步。

起义是联盟建立基地的唯一方式，玩家需要选择一个已有民意令牌且类型与阵营板上未建基地相符的地点，随后从支持者牌堆中消耗两张匹配该地点类型的卡牌。起义一旦爆发，该地点上的所有敌方棋子，包括士兵、建筑物和各种令牌，将被瞬间全部清空（联盟也会获取摧毁建筑物和令牌所得的分数）。接着，联盟会在该地点放置对应的基地，并根据目前地图上与该基地类型相符的民意令牌总数，放置等量的士兵，最后再将一名士兵放置到阵营板的教官区。

执行完起义后，联盟可以进行散播民意来获取分数。玩家必须选择一个与现有民意地点相邻的无民意地点（若地图上完全没有民意，则可任选地点）。根据民意令牌轨道上标明的成本，玩家需要从支持者牌堆中消耗对应数量且与目标地点类型匹配的卡牌，将民意放置上去并立即获得轨道上显示的分数。

需要注意的是戒严规则：如果目标地点内驻扎着至少三名属于同一敌方阵营的士兵，联盟在传播民意时必须额外多消耗一张匹配的支持者卡牌。

白天阶段，联盟可以进行手牌和支持者牌堆的资源转化。联盟可以执行动员，将手中的任意卡牌放入支持者牌堆中。同时也可以执行训练，通过消耗手中一张与地图上已有联盟基地类型相匹配的卡牌，将一名士兵放置到教官区。必须要注意的是，联盟只有 10 个士兵，放置多少个到教官区、保留多少个士兵在地图上，是游玩联盟阵营时必须要考虑到的问题。此外，联盟的卡牌锻造也在白天阶段进行，与其他阵营依赖特定的建筑物不同，联盟是通过激活地图上对应类型的民意令牌来完成锻造的。

夜晚阶段则是联盟进行常规版图互动的时刻。联盟可以根据阵营板上现有的教官数量，执行同等次数的军事行动。军事行动包含四种选项：移动士兵、发起战斗、在拥有基地的地点招募一名士兵，或是执行组织行动。组织行动允许联盟从一个没有民意的地点移除一名自己的士兵，并直接在那里放置一个民意以此获取分数，这是一种不消耗支持者卡牌来传播民意的方式。

在所有军事行动结束后，联盟进行常规的抽取手牌步骤，并将超出五张上限的多余手牌弃置。每次基地被敌人摧毁时，联盟必须丢弃支持者牌堆中所有与该基地同类型的卡牌，并损失一半的教官（向上约）。

神秘游侠

在猫咪、飞鹰和联盟互相牵制的期间，森林里总有一些流浪者，想要趁机提升自己在森林中的声望 —— 这当然也包括了恶名。与那三个势力截然不同的是，游侠在地图上只有一个棋子，那就是游侠自己。游侠并不属于士兵，因此永远无法占领任何地点，也无法阻止其他阵营占领地点，且无法被移除。但这种孤立也赋予了游侠移动时可以完全无视出发地和目的地的占领权限制。

游侠的行动与生存完全依赖于他的物品系统。无论是移动、战斗、探索废墟获取新装备，还是完成任务与援助他人，都需要消耗背包或物品栏中对应的、未损坏的物品。

这里需要提到 Root 的物品系统。物品可以通过锻造特定的卡牌来获取，对于不会用到物品的阵营来说，锻造出来的物品只会从公共物品区取出一个、放到一边。当公共物品区里没有物品了，那么制造物品的卡牌便无法被锻造，自然也不能用来锻造得分。

而对于会使用到物品的阵营来说，物品还可以通过地图上的废墟来获取。游侠能够探索这些废墟、获取废墟内的物品，并且将废墟移除、变成一个空的建筑物格子。如果本局游戏里没有能够移除废墟格子的阵营，那么这些废墟格子会一直占着空闲的建筑物格子。

对游侠来说，物品具有两个通用的属性：是否被使用，以及是否损坏。这两个属性是完全独立的。在遭遇战中，由于游侠没有士兵可供阵亡，他所拥有的未损坏物品总量便等同于他的生命值上限，而未损坏的物品「剑」的总数，等同于能够掷出的最大命中数，无论是否被使用。每当游侠受到一点伤害，他就必须将一件未损坏的物品移入损坏区。如果身上没有任何完好的物品，游侠则忽略所有剩余的伤害。

处理与其他阵营的社交关系是游侠核心的战略维度。通过消耗物品并向其他玩家支付对应地点类型的卡牌，游侠可以执行「援助」行动。这不仅能从其他玩家那里换取他们锻造好的物品，还能逐步提升双方的关系轨道。当关系达到同盟状态时，游侠便赢得了该阵营的信任，不仅每次援助都能获得额外分数，还能在白天行动时直接裹挟盟友的士兵一同移动甚至发起进攻。

反之，如果游侠在游戏中移除了任何一个非敌对阵营的士兵，双方的关系会立刻跌入敌对状态。虽然游侠进入有敌对士兵驻扎的地点时需要额外消耗用于移动的物品，但这开启了另一条得分途径：在游侠自己的回合内，每在战斗中移除一个敌对阵营的部件（无论士兵、建筑还是令牌），游侠都能获得 1 分。这种得分机制太可怕，以至于官方需要在比赛中特别削弱游侠，才能平衡游戏。

游侠的开局阶段中，玩家需要选择一个游侠角色。不同的游侠角色开局携带的物品不同，且技能也都不一样。接着玩家需要将游侠米宝放置在森林里，注意，并不是在地图的格子内，而是其他阵营都无法进入的「森林」里。然后玩家会获取一个任务牌堆，抽取 3 张、面朝上放在阵营板的附近。任务需要游侠到达任务牌上类型相符的地点，并使用任务所需要的未使用物品，以获取奖励：得分或者抽卡。随着同类型的任务做得越来越多，得分以及抽卡的数量也会越来越多。不过在我看来，靠任务得分并不是一个很棒的选择。

清晨阶段，3 个已使用的物品会变成未使用状态，且每有 1 个物品「水壶」，还可以多刷新 2 个物品。接着游侠可以无消耗地移动到相邻的地点或者森林中，无论该地点是否被敌对阵营占领。

早上阶段，游侠可以按照任意顺序来使用自己的物品：

移动：使用 1 个物品「靴子」；
战斗：使用 1 个物品「剑」；
探索：使用 1 个物品「火把」，探索后获得 1 分；
援助：使用任意 1 个物品。就算是敌对阵营，游侠也可以援助，但是关系不会变好；
任务：使用任务牌上所要求的物品；
打击：使用 1 个物品「弩」，直接移动当前所在地点的士兵或者建筑物或者令牌。打击并不算战斗，但是算移除士兵或者令牌，因此不会触发游侠杀害士兵得分的机制，但是会触发联盟民意被移除的机制；
制作：选中一张手牌，在类型相符的地点上使用 1 个物品「锤子」来锻造它。因为游侠只能一次出现在一个地点上，意味着所有要求多个地点类型的卡牌都无法被锻造；
修复：使用 1 个物品「锤子」，将一个已损坏的物品变成未损坏的状态。不过如果该物品也出于已使用的状态，那么修复并不会让它也变成未使用的状态；
特殊行动：游侠角色的技能不同，在进行的特殊行动也不同，不过使用的都是物品「火把」。例如「猎人」角色就可以一次性修复 3 个物品，代价是白天阶段会被立即结束。

晚上阶段中，如果游侠处于森林，那么所有已使用或者已损坏的物品都会变成未使用或者未损坏的物品，相当变态。接着抽取卡牌，每有 1 个物品「金币」都会额外抽取 1 张。若手牌多于 5 张，则丢弃手牌直到手牌数为 5 张。最后，游侠要检查物品的容量。如果未损坏和已损坏的物品总数超过物品上限（默认 6，每有 1 个物品「背包」便多出 2），那就需要丢弃物品，直到物品数量等于物品上限。这里的「丢弃」并不代表着将物品放回公共物品区，被丢弃的物品不会再回来。

结语

本篇文章仅供参考。在实际的游玩时，我建议还是阅读官方提供的规则书，或者说这个网站。为了减少篇幅，我没有细讲许多内容，只是将游戏的大致规则讲了一遍。

Root 除了实体桌游外，还有电子版本。你可以从 Steam 上购买下载，也可以在 Google Play 或者 App Store 中购买下载。购买游戏本体是不共通的，但是购买 DLC 是可以通过 Dire Wolf 账户实现共通。

又因为 Root 既有实体桌游，也有电子版本，我采取的讲述方式是同时基于了它们二者：你会发现我尽量不去介绍桌游特有的实体物件，也没有无视掉电子版本中程序已经帮助玩家处理好的地方，而是围绕着游戏机制本身进行介绍。

未来我考虑继续介绍 Root 的 DLC 内的阵营，或者说阵营的进阶玩法。

用笑脸玩扫雷

2026-02-14T05:00:00.000Z

想必大家都有玩过「扫雷」这款游戏，尤其是经历过 Windows 早年版本时代的人们，在计算机的开始菜单里找了半天，好不容易找到「游戏」文件夹，里面赫然躺着一个应用程序。双击打开，看到一个黄黄的微笑，心想这游戏肯定很简单吧！然后便被炸弹炸死。

好吧，这游戏到底该怎么玩呢？首先，你可以点开一个网格，看看下面有没有雷，就像是现实生活中挖雷一般。你可以右键给一个网格插上旗子，标记该网格，假设它底下有雷。

那就点开一个网格看看吧！

看来我们挖出了一个大区域。其中没有数字的网格，代表它的周围（即相邻的八个格子）没有雷；有数字的网格，上面的数字代表周围存在多少个雷，例如 1 就是相邻的格子里有 1 个雷、2 就是相邻的格子里有 2 个雷……

知道了这一条规则后，我们可以快速锁定这些 1 们：因为它们的周围只有 1 个格子，也只有 1 个雷，那么雷到底在哪里，很显而易见了吧~

给这些定有雷的格子插上旗后，我们可以进一步推测出，旁边的 1 的雷已经被找到了，那么它们的周围就不可能再有其他雷 —— 全部挖开！

持续做下去后，很快你便会发现，已经没有可以用这种推理方法挖开或者插旗的格子了。当然，这不意味着扫雷无法再继续进行下去，只是我们还没有明白该游戏的本质。

扫雷的核心逻辑在于「公共区域的控制权」。什么是公共区域？当两个数字相邻时，它们周围的一圈格子在中间部分一定是重叠的。除了这片公共区域，它们又各自拥有属于自己的一小块独占区域。

假设我们决定观察这两个相邻的数字：M 和 N。M 周围有 M 个雷，N 周围也有 N 个雷，它们中间夹着的几个格子是它们共同拥有的。无论这些公共格子通过什么方式排列雷，它们对 M 和 N 的贡献是一样的。如果 M 是 1，N 也是 1，意味着 M 需要在它的视野里找到 1 颗雷，N 也需要找到 1 颗雷 —— 因为 M 通过公共区域得到了满足，那么 N 作为邻居，自然也得到了满足。如果此时 N 还有额外的独占区域格子，那么格子必然不能有雷，否则 N 周围的雷数就会超标。

明白了这些后，恭喜你，你理解了扫雷游戏里的「1-1」定式！

接着我们用这个逻辑去理解「1-2」定式。想象这么一个场景，M 是 1，N 是 2。这意味着公共区域内最多只能有 1 颗雷，绝对不能再多。既然最多只能有 1 颗雷，那么 N 的最后那颗雷哪里来？答案是在 N 的独占区域内。也就是说，我们可以通过减法公式 N - M = 1，来得出答案 1 颗雷必然存在于大数字的独占区域内。

再来看「1-2-1」定式。我们这里使用 M = 1、N = 2、O = 1 来代表这个场景。假设我们把雷放在 N 的正下方，这颗雷会同时被 M、N、O 看到，且同时满足 M 和 O 的条件。可是，中间的 N 还差 1 颗雷。但这颗雷没有地方放了，因为如果再在任何地方放雷，左右两边的 1 就会变成 2，也就违背了已知条件。所以，结论只有一个：中间那个公共格子绝对不能有雷。既然中间不能有雷，为了满足中间的 2，雷只能被迫分布在两个 1 的下方。也就是说，「1-2-1」是一个硬性定式，只要看到了就可以断定两个 1 下面有雷，而 2 的下面没有。

如果将两个「1-2」叠加起来，我们能得到「1-2-2-1」定式。左边的「1-2」结构意味着，为了补足 2 的雷数，最左边的雷必须在 2 的独占区域。同理，右边的「2-1」结构意味着最右边的雷也必须在 2 的独占区域。这样一来，两个 2 外侧的雷都确定了。现在只需要找到公共区域的雷。由于它们原本都是 2，现在各减去确定的 1 颗，剩下的需求便变成了「1-1」的局面。

根据前面提到的「1-1」逻辑，中间往往是安全的，或者雷的分布是对称的。结果便是，两头的 1 下面有雷，中间的两个 2 下面往往可以挖开。不过该定式需要取决于雷的具体排列，不过逻辑核心依然是先确定外侧的必然雷。

其实，这些定式本质上都是数个「1-1」或者「1-2」组成的，只要理解底层逻辑，都可以通过这些减法公式来判断雷的位置。但是呢，在实际的中盘博弈中，数字周围通常已经插上了旗帜。如果不扣除这些已知的雷，直接套用减法公式，新手容易将实质上的「1-2」误判为「2-2」或者「3-3」等对称局面，从而得出完全相反的安全结论并导致踩雷。

过去我为作业写过一个简单的扫雷 AI。因为对该游戏的不熟悉，代码里并没有赋予 AI 处理任何需要综合判断的局面的能力。这对我们而言也是同样的，如果只是随便将定式套在数字上，而没有考虑到更为综合的情况的话，得到的可能就是一个爆炸的雷，和一个死掉的小黄脸了。

该文章仅讲述扫雷游戏的入门玩法，参考该文章，想要更多了解的也请阅读该文章。

女人的血

2026-02-12T05:00:00.000Z

女人，或者说有雌性生殖器官的人，又或者说需要生产卵子来进行繁殖生育的哺乳动物，都会有月经吧。以防万一有人不知道月经的底层逻辑，它本质上是卵子死去时流出的血液。女人需要每个月更换卵子，经历「流血的七天、安全期、卵子生成的发情期」这样的 28 天循环，直到无法生育。这期间有一个例外，那便是怀孕。

要说月经有多么不便，一是伴随而来的腹痛和肌肉酸痛，二是下体那无法离去的黏稠感，三是对于流血这件事情的恐惧 —— 这里主要指的是不知道什么时候流血，以及在实际确认前不知道自己流了多少。量就像死或者没死的猫，无论是哪个结果，在打开箱子前我们作为观测者都是心惊胆跳的。

五年级的时候，我流出了第一滩月经血。那是一坨黑色的东西，附在我彩色的凯蒂猫睡裤上，当然还有内裤上。我对它的第一个反应，便是恐怖 —— 废话，身体不舒服去蹲个马桶，刚脱下裤子就是这么一大滩黑色的玩意儿，哪个小孩儿不会被吓到。和近乎所有中二的小孩儿一样，我的第二个反应是「我该不会得了什么绝症吧」，进而得出自己是「特殊的」这件事。

也和近乎所有中二的小孩儿一样，我认为「特殊」的事情，不过是世界上比我能数出的数字更多的人正在经历的事情。因为母亲像是没事人一样说，「我也到那个年纪了」，然后像是被逗乐般，告诉我如何使用卫生巾。使用卫生巾是一个极其不适的事情：你的肉体和内裤之间隔了一层粗糙的护垫；要是你出汗了，这个护垫还会黏糊糊地粘在屁股上，更别提血多的时候了。虽然长大后我有幸使用过高质量的卫生巾，但是我绝大多数只买得起便宜货…… 而这种事情，每个月都要发生足足七天，可能会少一两天，亦或者多一两天。

为什么女人一定要经历月经这件事，我自小就在思考。它实在不是一件能让我觉得有价值的事情，无论是不舒适还是其带来的结果 —— 可生育 —— 都让我觉得可有可无。

母亲来美国后，成为了一个忠诚的基督教徒。我来美国后，自然也没少和她去教堂。还是孩子的我，并不能理解宗教，只是在没有娱乐的教堂里一遍遍翻阅圣经，直到看到《撒母耳记》以及后面的明显不再带有故事情节的内容；因为那些内容实在是「无聊」，无法吸引到我。圣经在那时候，对我来说更像是西方人的「故事书」。因此，孩童时期的我最喜欢的章节是《启示录》。不过那里面没有太多和耶稣相关的内容，说出去的时候还被说教了一番。

先前我表态过，我并不喜欢宗教。不过我喜欢宗教故事。也就是说，将它们视为故事书来看，我是很欢迎的；如果是传教来的，我只能用手打个大大的 X 给你看。我很不喜欢跟耶和华有关系的宗教。无论是犹太教还是基督教还是伊斯兰教，都一定会出现旧约的内容。尽管知道一些派系否认了旧约里说的事情，但我还是无法喜欢上它们。《创世纪》里说，夏娃被蛇欺骗，吃了生命果，还劝亚当吃下，所以被上帝额外惩罚，后代的所有女人都要每月受腹痛之刑，且在一个章节里，女人要额外比男人多清洗几天，只因女人一出生便是不洁的。

我会一次次去想，我是生而不纯洁的吗？我会在小时候就体验这种钻心之痛，是因为这种事情吗？

「血」，仿佛真的像是诅咒一般。

疫情期间，父亲被辞退，纽约市的街道空荡荡的，大家买不到口罩，我们一家四口和一个亲戚在房子里日复一日地搓麻将。那是一段压抑的时期，我们无处可去，只能醒来、玩手机、打麻将、睡觉、重复。这种像是被打了一针麻醉的生活里，母亲突然说了一句，「要是当时死掉的人是我就好了。」我陷入了沉默，然后和过去一样，不受控制地出现了情绪闪回：这是母亲多少次如此厌恶我？或者在我的面前赞扬她那个已经胎死腹中的男孩儿？

母亲打掉的孩子一共有两个，我是她第三个怀上的孩子，也是第一个顺利生产的孩子。在我之前，她怀上的是一个男婴。然而当时发生了许多事情，母亲一气之下打掉了这个孩子，后面又一个劲儿地后悔。梦里，她时不时会梦到这个男婴，对着她说「妈妈，我冷。」惊恐中，她向外婆求助做法事，心境安稳后，就再也没有梦到这个男婴了；取而代之的是她会潜意识中将所有男青年视为自己的儿子，并对我说，「要是你哥哥还活着，他就是这个样子吧。」

我一边摸着麻将牌，一边流下泪水。父亲看到我哭了，愤怒地掀翻了麻将桌，和母亲吵了一架；妹妹大声哭了起来，亲戚只能在旁边做和事佬。

在美国欠债的生活压得还未成年的我很是难受，也压得父母难受，尤其是母亲。她在我初中时开始，精神逐渐变态。不仅打骂已经是家常便饭，还会管控我和同龄人之间的社交，令我很难和朋友们进一步发展关系。最为可恶的是那些向着她的人们，口上说着要帮助我，却没有人真的做什么，只是让身为孩子的我一次次原谅母亲、体谅她。直到日后，高中的一位老师策划了一件事，瞒着我报告了儿童局，且一位友人一直在帮助和支持我，我和母亲的关系才得以缓和。所以让孩子体谅父母，根本就不是什么责任，明明解决问题有着更好的方法。

母亲到底是为什么生下我，以及妹妹的呢？是为了社会义务，是为了一己私欲，还是真的希望一个生命能够诞生、享受世界上各个美好？我想，怎么都不会是最后一个吧。如果我都不觉得自己能够抚养好的一个孩子的话，那我这些年为了生育而保留的这个系统，真的还有存在的必要吗？

在知道我和同性交往过后，一个说教味儿极重的校友找到我，开门见山问我为什么要和同性在一起、我应该知道「洞和洞是不能在一起」的吧。我心想，这个人恐怕是一个「洞性恋」；怎么会有人将其他人类视作为「洞」呢？除非他满脑子都是洞，看到的也只有洞。对话的结尾，他为了让我难堪，说「因为你是同性恋者，所以你全家的血脉都断了。」

香火、血脉，这些事情，真的有那么重要吗？为了这些「社会义务」，生下一个又一个孩子，但是缺乏培养他们的能力，最终得到的却是一个个倍受童年折磨的人。

这一切的目的是什么？在生物角度上来看，是为了发情和繁殖。生育从来都不是一件错事，这是自然的。只是我并不清楚自己真的会想要生育吗？我在未来，会喜欢上一个人，然后想要去那个人组建家庭、生下两人基因的融合体吗？不，这样的想法到底在把孩子们当成什么？如果要让一个生命诞生的话，就必须为他负起责任吧。我不想成为一个，像父母亲那样的人啊。我希望世上的孩子们，都可以幸福地度过童年，可以成长为自己想要成为的大人 —— 因为，我连自己也喜欢不上来啊。

既然如此，为什么我没有去采取相关的措施、好让自己的生活好过一些？我思来想去，觉得最大的问题在于「后路」。每次想到这件事，考虑到的都不是所消耗的精力和资源，而是「万一自己未来会使用到呢」—— 潜意识中，生育这种与生俱来的能力，竟是我的后路吗？

如果我构建出来的社会身份失败了，我剩下的，便是「母亲」这种最为原始的身份。照顾孩子是困难的，我一直都知道，所以我也会认为母爱是伟大的。但如果让我因为这种理由而成为一位母亲，这个身份便成了廉价的兜底方案 —— 它不需要我拥有才智和品格，只需要我维持这具肉体的基本机能。这种思想是可怕的，我在潜意识里依然认可了将人简化为「洞」的逻辑，依然在为自己保留一种功能性的价值，而非主体性。

我要是因为自己的失败，而让一个生命诞生了，对他而言，我或许只不过是一个又傲慢又糟糕的人吧。我会将他视为填补自己人生空洞的工具，让他成为我逃避虚无的牺牲品。好像，我又一次变成了母亲。

我好希望这「女人的血」，仅仅是血，而不是诅咒。

读《那片血一般红的杜鹃花》

2026-02-07T05:00:00.000Z

我这个学期开始上中文课了。这节课是短篇小说课，主要是阅读上个世纪台湾、大陆等作者们的短篇小说。

开课要阅读的第一本叫作《那片血一般红的杜鹃花》，出自于《白先勇文集》的第二卷「台北人」。

这是一个第一人称视角的故事，但「我」并非故事的主角，而是故事的旁观者。而故事采取的叙事手法是倒叙。

开头人们便在海边找到一具男尸 —— 够 hook，吸引了读者的注意力。此时出现了故事真正的主角 —— 王雄 —— 的第一次外表描写：

要不是他那双大得出奇的手掌，十个指头圆秃秃的，仍旧没有变形的话，我简直不敢想象，躺在地上那个庞大的怪物，竟会是舅妈家的男工王雄。

简单一句话，我们得知了这些信息：王雄很大一只，且手掌出奇地大，有着秃秃的手指头 —— 并不精致，是个干活的手。

之后故事便切换到了「我」最初来到故事发生的地点的时候。此处纷纷介绍了舅妈和丽儿这两个角色。舅妈在这个故事里并非什么重要角色，作者对她的描写并不多；丽儿是故事的另一个主角，描写自然也就多了：从小就被惯着养，且又白又圆，像个玉娃娃 —— 玉娃娃是个颇为有趣的描写，代表着精致、贵重的同时，还有着易碎的特征。

接着「我」初次见到了王雄 —— 他在长满了杜鹃花的花圃里，给丽儿当马骑。就算是丽儿从他的头上跨过去，他也觉得无所谓。作者对王雄的描写是这样的：高大得出奇、黑头黑脸、巨掌、秃秃的指头。很显然，这是一个完全和丽儿反着来的角色；一个小孩和一个大人，一个白一个黑。

不过王雄也有着和丽儿相似的外貌描写，他有着一嘴白牙齿和发白的裤子，意味着他并不是一个完完全全「黑」的人。

三人的对话透露出，王雄是个湖南人，以前还打过仗。意外的是，当丽儿说王雄曾经对自己说过，可以让自己骑着他上学时，王雄这个粗男人竟脸红了。

「我」从舅妈那儿得知，王雄是个退伍军人，现在被舅妈雇佣作男工。他为人老实，干活细腻，花圃的杜鹃花全是他一颗颗种的。「我」心生疑惑：为什么要种杜鹃花呢？舅妈给出的答案是丽儿喜欢。

王雄每天都会接送丽儿上下学，还会把自己打扮得体体面面的。一回到家，便会钻研各种东西讨丽儿欢心。此时的二人，关系再好不过。

因为服兵役，「我」时不时会借住在舅妈家，因此有时间给丽儿补习功课，以及和王雄谈话。王雄告诉「我」，他原是湖南乡下的农民，十八岁抽壮丁时被抽了出来，直到现在四十了也没能回过家。

「表少爷，你在金门岛上看得到大陆吗？」有一次王雄若有所思的问我道。我告诉他，从望远镜里可以看得到那边的人在走动。
「隔得那样近吗？」他吃惊的望着我，不肯置信的样子。
「怎么不呢？」我答道，「那边时常还有尸首漂过来呢。」
「他们是过来找亲人的。表少爷，你不知道，」王雄摇了摇手止住我道，「我们湖南乡下有赶尸的，人死在外头，要是家里有挂得紧的亲人，那些死人跑回去跑得才快呢。」

「我」服兵役的地方正是现在福建的金门岛，且离大陆很近很近。但就算这么近了，两岸当时的关系也不容探亲，更别提让王雄这个国民党的军人回家了。

当描述到营地里的老士兵的时候，「我」说他们有时会出现成人不会有的「童稚般的笑容」以及「赤子的天真」。且「我」初次提到了「怀乡的哀愁」。对于王雄来说，他不也是这样的人吗？

当问到王雄家里还有什么人的时候，王雄回答说家里有个不知道还在不在的母亲，以及一个十岁大的童养媳。作者描述童养媳的时候，也使用了「白白胖胖」这样的比喻。童养媳的年龄和描述，正和现在的丽儿一模一样。

这一段里，不只是出现了童养媳这个角色，作者也引入了最开头提过但没有深入的角色 —— 喜妹。她是下女，也就是女佣或者侍女。对于喜妹这个角色的描写，虽然她也是「白白胖胖」，但是「自以为很有风情」，反而和王雄是死对头。喜妹很喜欢撩拨王雄玩，这在旧中国看来是相当轻浮的举动，但王雄又很不喜欢她。

让我好奇的是，喜妹在逗完王雄后，「用着尖细的声音哼起了台湾的哭调《闹五更》」。而王雄「霍然立起身，头也不回」回了房间。这里的《闹五更》到底有着什么样的含义？

丽儿上中学前，舅妈给她买了套童军制服。王雄看后，「猛吃了一惊」。先前暗示过，王雄将丽儿视为自己小时候的童养媳；但现在丽儿开始长大，有了新的衣服，变得也渐渐和童养媳不一样。对于那时的王雄来说，又意味着什么呢？不只是如此，丽儿上中学后也有了性别和阶级意识。在她在家里炫耀自己学的英文时，她说：

I am a girl. 丽儿指了一指自己的胸膛念道，然后又指了一指王雄。
You are a boy. 王雄微张着嘴，脸上充满了崇敬的神情。
I am a student. 丽儿又念了一句，她瞥了王雄一眼，然后突然指着他大声叫道：
You are a dog.

这些都象征着丽儿在未来只会越来越不像童养媳。果不其然，在紧接着的下一场景中，丽儿便大发脾气，不再允许王雄接送自己，理由是同学们觉得王雄长得像大猩猩。此时，王雄不仅不再是「非异性」、「同级人」，而是一个动物 —— 连人都不是了！

王雄为了让这段关系回到过去那样美好，给丽儿带来两条金鱼。丽儿非但没有收下，反而摔碎了鱼缸、害死了金鱼。作者借物描述了二人的关系，正如文中所说那样，「跌落在地上不能动弹了」。这也是这部短篇小说里，王雄和丽儿的最后一次对话。

自这之后，王雄变得颓废起来。人叫他，他不应，脾气还越来越暴躁，一整天只是不停照料杜鹃花。一次，他和喜妹就用水一事起了冲突。王雄瞪着喜妹时，喜妹却放声嘲笑他：

「大猩猩 —— 大猩猩」

谁知这一笑，王雄彻底愤怒、像头真的大猩猩一样，抓住喜妹的肩膀拼命摇晃，还发出野兽般的低吼！喜妹挣扎逃开，对着他骂道：

「考背！」

次日早上，「我」和舅妈在花园找到了像是死了一样的喜妹。她的衣服被撕碎，身上包括乳房都是伤痕。同一天，王雄也不见了。在那之后，便发生了小说开头的「王雄之死」。这里小说中并没有提及喜妹到底有没有被性侵。

上中文课的一个好处是，我们可以一边阅读，一边讨论。这篇小说在开课前我便读过一遍，但当时并没有读出其更为深奥的意义来。这次讨论让我见识到了作者的功底，也更乐意去解读这些小说。

教授问我们，王雄和丽儿的关系到底是什么。一位同学认为是父女般的关系，一位同学认为是不纯粹的、王雄将丽儿视为性对象的关系…… 在我看来，王雄确实是以不单纯的视角去看丽儿，不过并不能简单归于「父女」或者「性」。这就需要讲到这部短篇小说的主题 —— 乡愁。

王雄十八岁便被迫离开湖南，到四十岁都没有再回去过。他将对童养媳的思念加到丽儿身上，正好她们在小时候很是相似。可是丽儿终究是丽儿，而非童养媳。长大后的丽儿只会慢慢疏远王雄，变得和王雄记忆里的童养媳不再一样。在王雄意识到这一点之后，他的重点便放在了浇灌杜鹃花上。

为什么非得是杜鹃花呢？不论是小说的标题，还是王雄最初决定栽种的植物，都是杜鹃花。故事中的「我」很是好奇，便去询问了舅妈。当时舅妈的回复是「丽儿喜欢」，但其实还有一层意思：湖南盛产杜鹃花，早在 193x 年便引入长沙市栽培，1985 年还成了长沙市的市花。种杜鹃花，是为了让舅妈家变得像自己在湖南的家一样。

这份思乡之心也在其他地方表现出来：王雄询问「我」能否看到内地时，提到的赶尸习俗中，他特意提到「只要亲人挂得紧，尸体回去才快呢」。小说里也让「我」见到念叨着家乡的老士兵，作为主题的又一暗示。

王雄作为退伍老兵，回不去家，仅能将丽儿和杜鹃花视为一种寄托。但丽儿变了，开始嫌弃自己，生活没有了正面反馈，自己又同喜妹产生冲突 —— 喜妹那句骂人的话很有意思。「考背」（现在更喜欢称之为「靠北」）的意思其实是「哀悼父亲去世」，延伸开来就有诅咒对方死全家的意思。王雄是家中唯一一个男丁，对他来说，母亲可能已经去世，家中只剩下一个不知去向的童养媳，王雄本人又回不去 —— 这又何尝不是一种「死全家」了呢？

而王雄暴怒时的举动，正好和他人嘲弄他说的「大猩猩」一样。此时的他，不仅理解了和丽儿的关系无法再回到当初，自己可能一辈子无法回家；种种压力下，王雄想：「你们说我是大猩猩，那我就变成大猩猩给你们看。」结果便是喜妹的悲剧。

王雄本身并不是一个暴力的人。攻击了喜妹之后，想必他的想法很是复杂：愧疚、焦虑、后悔、自暴自弃…… 想要回家，怎么回家？「湖南有个赶尸习俗，只要亲人挂得紧，尸体回去才快呢。」荒诞的是，能回家的方法竟只剩「死」这一条路。

这必须得讲一下当时的历史。1949 年到 1987 年之间，所有流亡到台湾的外省人都无法回到内地。1949 年国民党退守台湾后，海峡两岸处于战争状态：两岸之间不通邮、不通商、不通航。而王雄的身份是国军退伍士兵。当时台湾处于长达 38 年的「戒严时期」。私自与大陆联系或试图前往大陆，会被视为通匪或叛逃，可能面临极刑或牢狱之灾。同理，在大陆那边，曾为国民党效力的士兵被划为「黑五类」或「历史反革命」。假设王雄真的偷渡回去，等待他的极可能是批斗、监禁甚至处决。

戏剧性的是，《台北人》是在 1960 年代到 1970 年代初。两岸开放探亲要等到 1987 年。王雄死在了黎明前的漫长黑夜里。对于那个时代的大多数老兵来说，这就是死局。他们唯一的归乡方式，往往只能是死后魂归故里。「我」看到的老士兵实际上便是无数个王雄。他们虽然年纪看着大，但有着成人没有的童真和天真 —— 有多少是还没长好就被抓来当兵，半辈子都在战场上生活的呢？先前我说这暗示了乡愁主题，其实也暗示了这些人们停留在孩童的年龄。

这又要说回最开始那个问题：王雄和丽儿到底是什么关系？作者在描写他们二人互动时，很喜欢将王雄写成一个「虽然年纪大身体也大，但处处跟个孩子一样、同丽儿玩耍的人」。在我看来，就算他将丽儿当成童养媳看待，但这也不意味着他带着有色滤镜去看待丽儿，反而是将其视为童年的一部分；同丽儿游玩，就像是自己也变小了一样，从来都没有上战场过。

可惜他最终的结局是：

他的尸体被潮水冲到了岩石缝中，夹在那里，始终没有漂走。

想法在丙午岁始迭代

2026-02-01T05:00:00.000Z

这个月里我做了很多在笔记本上的工作，所以在阅读文章上花费的时间跟精力都变少了很多。

本期导读

最能保障「数字主权」的 VPS 公司

2026-01-30T05:00:00.000Z

我观看了一场名为「后美国互联网」的演讲，实在是精彩，让我对「数字主权」这一概念有了更深刻的认知。借此，我发现我的许多服务依然部署在美国的 PaaS 服务上。这类中心化的服务如果出问题了会很麻烦，参考去年 Cloudflare 的事故。而我愈来愈对美国企业产生抵触之心。不过要我完全逃离是很难做到的，毕竟我人就在美国。这些原因结合在一起，促使我对「哪家提供 VPS（虚拟专用服务器）服务的公司最适用于数字主权者」这一命题感到好奇。

首先我需要确立一个核心的排他性原则： 任何受《美国爱国者法》和 CLOUD Act 管辖的实体必须被彻底剔除。

这不仅仅是因为数据隐私问题，更是管辖权层面的问题：CLOUD Act 赋予美国执法机构长臂管辖权，无论服务器物理位置在何处，只要控制着是美国企业，数据即被视为处于美国管辖之下。因此，AWS、Google Cloud、DigitalOcean、Vultr 等主流厂商在第一轮筛选中即宣告出局。

为了让后续对其他厂商的筛选带有令人信服的法理依据，我打算剖析美国法律体系来确立负面清单的标准。这也是为了还没有怎么接触过「数字主权」一概念的读者们可以更明白为什么我的选择是这个、为什么是哪个。

在 2018 年之前，微软曾经以「数据不存储在美国境内」为由，拒绝向美国政府移交存储在爱尔兰的数据。这时候，大家都普遍认为数据存储在美国境外可以规避美国的搜查令。然而 CLOUD Act 的签署彻底摧毁了这一避风港。该法案确立了一个核心原则，即 数据的管辖权不再取决于数据的物理存储位置，而取决于数据控制者的注册地。

这意味着，只要一家公司是在美国注册的实体，或者该公司在美国有业务运营，无论它将你的数据存储在东京、伦敦还是南极，美国执法机构都有权要求其移交数据。

对于大多数人而言，这是一个巨大的认知误区 —— 许多人误以为选择了 AWS 的德国区就受到了 GDPR 的绝对保护。

为了防止有读者不理解这些术语，我将在本篇以「问为什么之前先问是不是」这一形式来构建完整的因果链条。

GDPR（General Data Protection Regulation，通用资料保护规则）是欧盟于 2018 年生效的一项法律法规，被公认为全球史上最严厉、最全面的隐私保护法。它的核心宗旨是让公民重新掌控自己的个人数据。GDPR 规定了数据控制者必须如何收集、存储和处理数据，并赋予了用户一系列强大的权利，例如被遗忘权和数据可携带权。德国作为欧盟的核心成员国，自然完全受 GDPR 管辖。

事实是，由于 AWS 是美国公司，当美国法律与欧盟法律冲突时，AWS 必须优先响应母国的要求，否则将面临本土的巨额罚款或制裁。因此，对于美国主流厂商而言，物理位置的隔离在法律层面是无效的。

CLOUD Act 针对刑事调查也就算了， FISA Section 702 还针对大规模的国家安全情报收集。FISA（Foreign Intelligent Surveillance Act，外国情报监视法）是美国于 1978 年颁布的一项联邦法律。它的初衷是为了规范美国政府在进行针对外国势力和外国代理人的情报收集时的行为。在早期，如果美国情报机构想要监听境内的通讯，必须经过一个秘密法庭的批准。这在当时是为了防止政府滥用权力。而 FISA Section 702 是该法案在 2008 年增加的一个修正案，允许美国情报机构在无需获得任何具体法院搜查令的情况下，直接对位于美国境外的非美国公民进行大规模监控。

这是 PRISM （棱镜计划）的法律基础。NSA（国家安全局）基于 Section 702 法律授权实施了这个大规模电子监听项目。2013 年该项目被 Edward Snowden 曝光。根据 Snowden 披露的文件，PRISM 允许 NSA 直接接入美国互联网巨头的中心服务器。

当你使用美国厂商的服务时，从法律层面讲，你已经默认放弃了对抗美国情报机构窥探的权利。更为不幸的是，这类提取往往伴随着严格的保密指令，服务商不仅必须配合，而且被法律禁止告知用户数据已被查看。这种不透明性使得用户根本无法知晓自己的主权何时被侵犯。

抛开国家层面的法律，仅从商业合同来看，美国主流厂商的条款也充满了对用户主权的剥夺。最典型的陷阱在于单方面终止权。如果仔细阅读 AWS 或者 Google Cloud 的条款，你会发现它们通常包含类似「我们保留在任何时间、出于任何原因（或无须理由）终止服务或拒绝访问的权利」的表述。这种条款赋予了企业凌驾于用户之上的绝对权力。即使你的内容完全合法，只要触发了其自动风控算法，或者你的内容不符合其模糊的社会准则（注意，并非法律），你的账号及其中的所有数据可能在瞬间被封锁，且往往没有申诉通道。

此外，关于可接受使用策略，美国厂商通常会加入极其模糊的道德审查标准，例如禁止「令人反感的内容」。这是一个极其危险的口袋条款，因为「反感」是一个主观的感觉，它的解释权完全掌握在公司手中，而非由法院裁定。

说了这么多，理解起来可能依然很困难。作为实操案例，我分析和解读一下 AWS 的隐私条款。

AWS 将数据严格划分为两类：个人信息和上传到服务器的数据。前者受这份隐私条款管辖；对于后者，AWS 则在法律上认定自己只是处理者、用户才是控制者。因此，关于如何收集、使用、分享的条款统统不适用于用户服务器里的文件。如果数据被泄露，或者被 AWS 删除，都和这份隐私政策无关，需要去查阅其他条款和协议（内容太多暂且不做）。

AWS 都会拿我们的个人信息做什么呢？除了和改进 AWS 内部的产品有关外，就是推广推广推广 —— 推广自己的产品，也会推广其他公司的产品，简称「打广告」。证据例如：

We use your personal information to market, advertise, and promote AWS Offerings.
我们使用您的个人信息来营销、宣传和推广 AWS 产品。

法律相关的表述中，AWS 这么说道：

In certain cases, we have a legal obligation to collect, use, or retain your personal information. For example, we collect bank account information from AWS Marketplace sellers for identity verification.
在某些情况下，我们负有法律义务收集、使用或保留您的个人信息。例如，我们会收集 AWS Marketplace 卖家银行账户信息以进行身份验证。

这是很常见的陷阱表达： in certain cases，什么 certain case？「某些情况」是哪些情况？在没有明确说明的情况下，这个「某些情况」是完全受 AWS 主观判断而决定的。同样的表达也可以见：

We release account and other personal information when we believe release is appropriate to comply with the law, enforce or apply our terms and other agreements, or protect the rights, property, or security of AWS, our customers, or others. This includes exchanging information with other companies and organizations for fraud prevention and detection and credit risk reduction.
当我们在认为公开信息有助于遵守法律、执行或应用我们的条款及其他协议，或保护 AWS、我们的客户或其他人的权利、财产或安全时，我们会公开账户和其他个人信息。这包括与公司及组织交换信息，以进行欺诈预防和检测以及信用风险降低。

When we believe 、 comply with the law 是一个又一个的陷阱。只需要 AWS 内部的法务团队认为合适，他们就可以移交数据，将司法裁定权私有化。

没有国界限制的「法律适用」也是危险的。对于美国而言，这默认包含美国法律。这意味着为了遵守美国法律，他们可以出卖非美国用户的数据。

先前我说过，数据实际在什么位置根本不重要，这里 AWS 就给了我们一个很好的例子：

We share personal information only as described below and with Amazon.com, Inc. and the affiliates that Amazon.com, Inc. controls that are either subject to this Privacy Notice or follow practices at least protective as those described in this Privacy Notice.
我们仅按照下述方式分享个人信息，并与亚马逊公司（Amazon.com, Inc.）及其控制的附属公司分享。这些附属公司要么受本隐私声明的约束，要么遵循与本隐私声明中描述的实践至少具有同等保护性的实践。

AWS 承认了数据会被合法流向 Amazon.com，即美国母公司，或者其他附属公司。只要在这个链条中有一个实体受美国管辖 —— 显然母公司受管辖 —— 整个数据池就受管辖。无论你是在 AWS 的哪个分公司注册，结果都是如此。

还有一点是 AWS 并不独立完成所有工作，它依赖一个庞大的第三方供应商网络。即使 AWS 发誓不看我们的数据，但它还是把我们的数据交给了第三方。根据短板效应，美国执法机构也不用找 AWS，只要找下游供应商就好了。你的安全程度取决于整套供应链中最弱的一环。

We employ other companies and individuals to perform functions on our behalf. Examples include: delivering AWS hardware, sending communications, processing payments, assessing credit and compliance risks, analyzing data, providing marketing and sales assistance (including advertising and event management), conducting customer relationship management, and providing training. These third-party service providers have access to personal information needed to perform their functions, but may not use it for other purposes. Further, they must process that information in accordance with this Privacy Notice and as permitted by applicable data protection law.
我们聘请其他公司和个人代表我们执行职能。例如：交付 AWS 硬件、发送通信、处理付款、评估信用和合规风险、分析数据、提供营销和销售支持（包括广告和活动管理）、进行客户关系管理以及提供培训。这些第三方服务提供商可以访问其履行职能所需的个人信息，但不得将其用于其他目的。此外，他们必须根据本隐私声明以及适用数据保护法的规定处理这些信息。

注意，这里的「不得将其用于其他目的」仅是用于合同约束。只要数据流出，对用户来说就一定存在着潜在风险。这段话对 AWS 来说更多是免责说明。并且最后的「适用数据保护法」依然表明了美国政府可以向下游供应商索要数据。

尽管 AWS 开头就说：

Information about our customers is an important part of our business and we are not in the business of selling our customers』personal information to others.
关于我们客户的信息是我们业务的重要组成部分，我们不从事将客户的个人信息出售给他人。

但它也没说自己不共享用户数据啊。这是一个相当经典的商业诡辩：无论是「卖」还是「共享」，对于用户而言自己的数据就是被脱离出了原本的隔壁环境，进入了不可控的第三方手中。

一个有意思的题外话：韩国拥有全球最严格、最注重形式主义细节的数据保护法 PIPA （Personal Information Protection Act，个人信息保护法）。第 17 条里表示：

(2) A personal information controller shall inform a data subject of the following matters when it obtains
the consent under paragraph (1) 1. The same shall apply when any of the following is modified:
The recipient of personal information;
The purpose for which the recipient of personal information uses such information;
Particulars of personal information to be provided;
The period during which the recipient retains and uses personal information;
The fact that the data subject is entitled to deny consent, and disadvantages, if any, resulting from the
denial of consent.
(2）个人信息处理者在依据第（1）款第 1 项取得同意时，应当向信息主体告知下列事项；下列事项发生变更时，亦同：
个人信息的接收方；
个人信息接收方使用该信息的目的；
拟提供的个人信息具体项目；
接收方保有及使用个人信息的期间；
信息主体有权拒绝同意的事实，以及因拒绝同意而产生的不利后果（如有）。

(3)……obtain the consent from the data subject in order to provide personal information to a third party overseas……
(3)…… 为了向海外第三方提供个人信息…… 应获得数据主体的同意……

这导致 AWS 在对韩国的额外说明里，揭露了其全球运营的真实后台架构。实际使用的第三方服务商名单见隐私条款内的 South Korea 区域。

虽然这份名单名义上只针对韩国，但云服务商的后台架构通常是全球统一的。AWS 不太可能专门为韩国搭建一套独立的 Salesforce 或 Marketo 系统，也不太可能只在韩国使用 Paymentech，而在其他地区完全自研。因此，我合理推断这份名单实际上就是 AWS 在全球范围内通用的第三方供应商名单。

这样我们就能得知：

AWS 的客户关系管理直接被托管在 Salesforce 的美国服务器上；
哪怕用本地信用卡支付，结算的底层通道和记录依然与美国的金融系统紧密相连，因为 Paymentech（JPMorgan Chase）的地址为美国，而根据《美国爱国者法》金融数据是重点监控对象；
表格中明确列出传输的项目包括「必要时通过信息网络传输数据」，意味着只要业务需要，数据就会跨境流动，完全无视物理距离。

现在大致地阅读了 AWS 的隐私条款后，我认为作为读者的你多多少少也应该明白什么样的话是陷阱了。用同样的规则去阅读其他公司的隐私条款，很容易就可以觉察出各种不对劲。

我将「数字主权」定义为：用户对存储的数据拥有排他性的控制权，且该控制权仅受服务器物理所在地的当地法律约束，不受第三方国家的长臂管辖干扰。

自然，你喜欢哪一类都没有对错之分。我希望我的研究是可以帮助你找到理想中的那个「它」，而不是让你感觉你是否选错了公司。

我将从隐私政策、服务条款以及公司注册地与物理设施管辖权三个维度进行解构。不过这些并非所有提供 VPS 的服务商，只是出于篇幅，暂时只看了这些公司的文档。

1984 Hosting

1984 Hosting 通常被视为「数字主权」界的标杆，但如果仔细阅读它的 Terms of Service，会发现它并非像某些人想象的那样是一个无法无天的法外之地。相反，它确实提供了极高的国家级防御，但在操作界面和道德条款上埋下了不少陷阱。

条款里相比于 AWS 模糊的「适用法律」，1984 Hosting 明确指定了冰岛法律。

These Terms are governed by Icelandic law. Disputes arising from these Terms shall be brought before the Reykjavík District Court.
本条款受冰岛法律管辖。由此条款引起的争议应提交给雷克雅未克地方法院。

美国政府想要获取服务器内的数据的话必须通过 MLAT 让雷克雅未克地方法院认可并签发本地搜查令。MLAT（Mutual legal assitance treaty，相互法律援助条约）是两个国家之间签署的一种双边协议，用于在刑事调查中交换证据和信息。虽然 CLOUD Act 声称对美国公司拥有全球管辖权，但是 1984 Hosting 是一家纯粹的冰岛公司，和美国没有一点关系。因此美国想要数据，只能请求冰岛政府协助。

而冰岛法律拥有 IMMI，要让冰岛法官签发针对媒体或言论的搜查令，难度极高。IMMI（Icelandic Modern Media Initiative）是冰岛协会在 2010 年一致通过的一项决议，其目的是将冰岛打造为全球新闻自由和言论自由的避风港。根据 MLAT 中的双重犯罪原则，如果美国的指控在冰岛法律下被视为受保护的言论自由而非犯罪，冰岛法院将拒绝签发搜查令。

说了优点，现在来说说缺点。很多追求「数字主权」的用户误以为 1984 Hosting 等于匿名抗审查，但它其实会明确记录用户的真实姓名和电话号码。

When a service agreement is concluded between the Subscriber and 1984 ehf., the following information from the Subscriber will be recorded: (1) the Subscriber's name; (2) the Subscriber's active e-mail address; (3) any user name selected by the Subscriber; (4) the Subscriber's password(s); (5) the Subscriber's active telephone number; and (6) payment details, i.e. address, means of payment, etc., in accordance with the laws on the handling of such information and 7) PIN number selected by customer
当订户与 1984 ehf. 订立服务协议时，将记录下列来自订户的信息：(1）订户的姓名；(2）订户的有效电子邮件地址；(3）订户选择的任何用户名；(4）订户的密码；(5）订户的有效电话号码；(6）支付详情，即地址、支付方式等（依照处理此类信息的相关法律规定）；以及（7）客户选择的 PIN 码。

如果试图提供虚假信息，你便违反了保证条款，他们有权关停服务：

In addition, the Subscriber represents and warrants that all information provided by the Subscriber to 1984 ehf. is accurate, complete and current upon renewal and registration of services. The Subscriber represents and warrants that the Subscriber will inform 1984 ehf. of any changes to such information so as to ensure that 1984 ehf. always has accurate, complete and current information.
此外，订户陈述并保证，其向 1984 ehf. 提供的所有信息在服务续约和注册时均准确、完整且为最新版本。订户陈述并保证将通知 1984 ehf. 此类信息的任何变更，以确保 1984 ehf. 始终掌握准确、完整且最新的信息。

虽然 1984 Hosting 标榜言论自由，但他们同样保留了极大的主观裁量权。根据 Sec 8.02，他们禁止「任何 1984 ehf. 认为是非法、有害或在道德上令人反感的材料」。

Offering, selling or showing, or providing links to other websites offering, selling or showing the following is prohibited: (a) habit-forming or narcotic substances or related services; (b) weapons; (c) copyrighted materials that the Subscriber is not entitled to offer or sell; (d) information used to violate the copyrights or trademarks of others; (e) information used to manufacture, make or provide illegal goods or weapons; (f) pornography or sexual products; (g) file sharing; (h) pharmaceuticals; (i) any materials or information that are, in the opinion of 1984 ehf., illegal, harmful or ethically objectionable.
禁止提供、销售或展示下列内容，亦禁止提供链接指向提供、销售或展示下列内容的其他网站：(a）成瘾性物质、麻醉药品或相关服务；(b）武器；(c）订户无权提供或销售的受版权保护的材料；(d）用于侵犯他人版权或商标的信息；(e）用于制造、制作或提供非法物品或武器的信息；(f）色情内容或性产品；(g）文件共享；(h）医药产品；(i）任何经 1984 ehf. 认定为非法、有害或在道德上令人反感的材料或信息。

冰岛法律对色情内容有严格限制，所以做成人内容或者边缘内容的用户会被直接 pass 掉。而「道德上令人反感」是一个口袋条款。什么是「道德上反感」？解释权完全归 1984 Hosting 所有，这与「绝对的言论自由」是有出入的。

1984 Hosting 也和 AWS 一样，给自己预留了完全的决定权 —— 只要他们认为你的材料有害，就可以不需要经过法院审判而直接停止向用户提供服务（见 Sec 8.04）。

一个较为恶趣味的设计是，如果想要退订 1984 Hosting 的服务的话，必须在订阅到期的 16 天前向他们发送电子邮件（见 Sec 2.04）。

基于上述分析，1984 Hosting 的「数字主权」建立在冰岛法律之上，而不是建立在无政府主义之上。如果你的内容对美国而言是有问题，但在冰岛没问题的话，可以尝试一下 1984 Hosting。

在价格方面，一个 1 GB RAM、单 CPU、25 GB 硬盘内存的 VPS 是每月 7.6 欧元，折合 9 美元，或者说 63 人民币。

OrangeWebsite

OrangeWebsite 很喜欢强调自己「在冰岛」这一身份。那么它的隐私条款可以证明它够「冰岛」么？

We do not disclose any personal information obtained about you from this website to third parties. We may use the information to keep in contact with you and inform you of developments associated with our business. We do not release any information to foreign authorities or agencies. We only release any personal data or any data saved on our servers with valid Icelandic court order or similar order from Icelandic authorities if it's not stated otherwise in this document.
We disclose the necessary personal data with 3rd party service providers, such as domain registrars and SSL-certificate registrars. Our client will be however informed about this before disclosure.
我们不会向第三方披露我们从本网站获取的您的任何个人信息。我们可能会使用这些信息与您保持联系，并向您告知与我们业务相关的最新动态。我们不会向外国当局或机构披露任何信息。除非本文档另有规定，否则我们仅凭有效的冰岛法院命令或冰岛当局的类似命令才会披露任何个人数据或保存在我们服务器上的任何数据。
我们向第三方服务提供商披露必要个人数据，例如域名注册商和 SSL 证书注册商。但是，我们的客户将在披露前被告知此事。

可以看出，OrangeWebsite 明确表示其法律根基完全扎根于冰岛，受到全球最严格隐私法之一的保护。

有意思的是，如果任何第三方就客户的个人详细信息联系 OrangeWebsite，他们会保留通知客户此类行动的权利。要知道，大多数美国服务商会受到禁言令的限制，被迫在秘密中移交数据且禁止通知用户。能把通知用户的权利写进隐私政策，很是豪爽喔。

虽然在法律防御上很强硬，但在数据收集层面上，这份文档显示他们依然遵循传统的商业 ISP 模式。OrangeWebsite 会收集完整的计费信息字段，虽然没说必须验证真伪，但也没说使用假的也可以。

文档也承认 orangewebsite.com 上使用了自动化营销工具收集数据，但强调在 secure.orangewebsite.com 上不收集。意味着他们会追踪访客的营销数据，但是不会监控已登录用户的后台操作。

支付方面，文档并没有提及加密货币。如果只支持信用卡和 PayPal 的话，那么资金流向就是实名的。这一点需要阅读其他文档来确认。

要知道更多，必须去阅读 Terms of Service。里面提到，OrangeWebsite 虽然支持加密货币支付，但是是用的是 BitPay 和 CoinPayments。前者是业界最著名的合约狂魔，在许多情况下会强制要求付款人上传护照照片进行 KYC，否则拒绝处理交易 —— 加密了个寂寞！如果付钱给 OrangeWebsite，你便有可能必须把护照交给美国公司。后者 CoinPayments 相对宽松点，但依然是第三方。

至于能否提供假的个人信息，答案是「否」，只是没有强制验证而已。平时是没人管，但要是出问题被发现了，他们可以以此为由封锁用户账号，且不退款。

合法的成人内容在冰岛通常是被允许的，OrangeWebsite 的条款没有明确禁止合法成人内容，只提及了儿童色情。这一点依然需要进一步确认。

文档中也没有提及到 Tor。在主机行业，未明确允许即默认为高风险。结合 Sec 3.3，运行 Tor 出口节点极易被判定为扫描或滥用。建议默认其不支持 Tor 出口节点，除非咨询客服获得书面许可。

一些有趣的点：没买防御却被打，想临时加防御的话需要先交 200 欧元罚款；除非用户授权，否则 OrangeWebsite 是不会碰服务器的，包括维护系统时。

FlokiNET

阅读了一些隐私条款后，FlokiNET 的隐私条款中的一些内容我想只要看到就能发现陷阱。

例如：

FlokiNET considers any information that can be used to directly or indirectly identify you to be Personal Data, including, without limitation, Personal Data that is accessed, collected, maintained, transmitted and/or used by FlokiNET in the normal course of our business and is subject to the provisions of this Privacy Policy and applicable law.
FlokiNET 将任何可用于直接或间接识别您的信息视为个人数据，包括但不限于 FlokiNET 在正常业务过程中访问、收集、维护、传输和 / 或使用的个人数据，并且该等数据受本隐私政策和适用法律的约束。

FlokiNET will ensure that appropriate security measures are in place and that confidentiality is maintained to protect your personal information in accordance with applicable laws and regulations.
FlokiNET 将确保采取适当的安全措施并保持机密性，以根据适用法律法规保护您的个人信息。

If you breach the Terms of Service or any other applicable service level agreement, or if FlokiNET is required to disclose or share your personal data in order to comply with any legal obligation, FlokiNET may disclose your information to a relevant authority. In particular, FlokiNET may disclose the information it collects to third parties if FlokiNET believes that disclosure is appropriate to comply with the law, to enforce its legal rights, or to protect the rights or safety of others.
如果您违反服务条款或任何其他适用的服务级别协议，或者 FlokiNET 为遵守任何法律义务而被要求披露或共享您的个人数据，FlokiNET 可以向相关部门披露您的信息。特别是，如果 FlokiNET 认为披露信息有助于遵守法律、执行其合法权利或保护他人权利或安全，FlokiNET 可以向第三方披露其收集的信息。

等等等等（提示：「适用」！）。

那我们只来看一些有趣的地方：

Customer data (data stored on the server) is stored in accordance with applicable law and requires a court order from the country in which it is stored in order to be disclosed.
客户数据（存储在服务器上的数据）的存储须符合适用法律，且披露该数据需要获得数据存储所在国家的法院命令。

后半句很关键，因为它明确了数据主权随物理位置而定。如果用户的服务器选在冰岛，FlokiNET 就只认冰岛法院的命令；选在罗马尼亚，只认罗马尼亚法院的命令。这意味着 用户必须明智地选择数据中心位置。这一点往往会被忽略，以为只要是 FlokiNET 就全都一样安全。

言论自由主机从来都不等同于匿名主机，FlokiNET 就是一个例子。它会收集用户的信息，且不单单指代用户的注册信息，还有访客的指纹。

FlokiNET 还会存储账单记录足足七年，就算是比特币交易哈希也会被存储：

You may cancel your account at any time and request that your personal information be deleted from our databases, except for any accounting records of purchases, which we are required by law to retain for 7 years, network access logs, which we may retain for any period of time at our discretion, in cases where there are outstanding financial obligations or in cases where illegal activity is suspected (as determined by FlokiNET management or law enforcement officials), in which case personal information may be retained indefinitely for the purposes of ongoing investigation and prevention of recurrence of fraud, or in cases where a breach of the Terms and Conditions and applicable Service Level Agreement has resulted in the termination of your account (as defined by revocation of your permission to use FlokiNET's services), in which case personal information may be retained indefinitely for the purposes of preventing further use of FlokiNET's services by the offending individual.
您可以随时取消您的账户，并要求从我们的数据库中删除您的个人信息，但出于会计记录的购买记录除外，根据法律规定，我们必须保留 7 年；网络访问日志，我们可以自行决定在任何时期保留，在存在未偿还的财务义务的情况下，或在怀疑存在非法活动的情况下（由 FlokiNET 管理层或执法官员确定），在这种情况下，个人信息可能会被无限期保留，以用于正在进行的调查和防止欺诈再次发生；或在违反了服务条款和适用的服务级别协议导致您的账户被终止的情况下（定义为撤销您使用 FlokiNET 服务的权限），在这种情况下，个人信息可能会被无限期保留，以防止违规个人进一步使用 FlokiNET 的服务。

「自行决定」是法律上的流氓条款。FlokiNET 明确表示他们会留日志，而且想留多久留多久。这通常是为了应对执法部门的溯源要求。

FlokiNET 也会无限期保留违规的用户信息。注意，这里的「违规」也包括「怀疑存在违规行为」这一主观想法。无限期保留的缺陷便是你无法通过注销账号来行使被遗忘权。

关于支付，FlokiNET 使用的是第三方支付，这包含了面向智利或全球的 Paygol、面向冰岛的 Borgun（现更名为 SaltPay），以及面向冰岛国家银行的 Landsbankinn。这三家都是受严格金融监管的实体，必定遵守 AML （Anti-money Laundering，反洗钱）规定，将数据直通给政府。

说到 AML，就必须说到该法规强制要求机构们执行的两个关键动作：

KYC（Know Your Customer，了解你的客户）：必须验证付款人的真实身份；
SAR（Suspicious Activity Reports，可疑活动报告）：必须监控交易流向。

凡是提及遵守 AML / KYC 的支付方式，都等同于实名支付。而在 AML 框架下的金融数据，隐私保护等级极低。只要执法机构以调查洗钱或资助恐怖主义为由调取数据，这些支付机构不仅必须配合，而且往往设有专门的自动化接口来对接政府查询。

因此， 在金融世界里，不存在法外之地的支付通道，尤其是涉及到信用卡和银行转账（再尤其是 Visa 和 Mastercard 的授权收单机构）时。

FlokiNET 目前提供四个区：罗马尼亚、冰岛、荷兰以及芬兰（未来会提供新加坡）。这四个区的价格各不相同，但单核、1 GB RAM、20 GB 硬盘空间的 VPS 大致在每月 7.99 到 10.99 欧元之间，折合 9.5 到 13 美元，或者 66.5 到 91.5 人民币。

Njalla

Njalla 的条款是「数字主权」领域中最激进的条款之一，得利于它的法律隔离层。不同于传统服务商试图平衡合规与隐私，Njalla 采用了一种替代所有权的模式来规避管辖。

首先 Njalla 的运营实体位于尼维斯，是加勒比海的一个小岛，也是著名的离岸避税天堂和隐私堡垒。尼维斯法律对公司信息的保密性极高，且不执行美国或欧盟的民事判决。这意味着版权流氓想要起诉 Njalla 索要用户数据几乎是不可能的，因为当地法院根本不承认这些外国的民事诉求。

不过条款中并未披露服务器的物理位置。虽然公司在尼维斯，但服务器可能位于瑞典、芬兰或其他欧洲国家。根据属地管辖权，服务器所在地的执法机构依然有权直接扣押物理服务器。Njalla 的防御仅限于法律文书层面，而非物理设施层面。

其次 Njalla 不需要用户实名制，甚至都不需要邮箱，仅需一个 XMPP（一种去中心化的即时通讯协议）地址即可注册。

在 Sec 6.4 中，Njalla 还嘲讽了 GDPR，认为真正的隐私并非「合规地处理数据」，而是「根本不收集数据」。这种态度表明他们不会主动配合常规的数据保留指令。

较为有争议性的是 Sec 3.3。在 WHOIS 数据库和法律层面，域名或服务器的所有者是 Njalla，而非用户。好处是这实现了完美的隐私，因为在公网记录里你根本不存在，没人能查到你的名字；坏处是如果 Njalla 跑路、倒闭或者恶意侵占，你在法律上很难证明这个资产是你的。

说完优点来说缺点。Njalla 的条款内有一些陷阱：在 Sec 9.2 中，他们也使用了「任何适用法律」这样的词汇，且没有限定是尼维斯法律。如果服务器位于瑞典，瑞典警方的要求也属于适用法律。

needed to comply with any applicable laws, government rules, requests of law enforcement, court orders or public authorities;
it is in compliance with any dispute resolution process;
to avoid any potential civil or criminal liability; or
your use of the Services in any other way incurs damage on the Services or Njalla or entails a risk thereof.
需要遵守任何适用的法律、政府规定、执法部门的要求、法院命令或公共当局的要求；
符合任何争议解决程序；
为避免任何潜在的民事或刑事责任；或
您以其他任何方式使用本服务均会对本服务或 Njalla 造成损害或带来风险。

「执法请求」一词意味着仅仅是警方的请求就足以让 Njalla 关停你的服务。以及绝对免责条款：只要 Njalla 觉得你的存在可能让他们惹上官司，他们就可以先下手为强把你关了。尽管他们由海盗湾创始人建立，但他们并不打算为了你而在法庭上死磕。

Njalla 并不是一个传统的 VPS 服务商，它更像是个匿名代理中介。如果你是极度需要隐藏身份的用户，且主要受来自民事诉讼或非国家级的骚扰的话，可以尝试一下 Njalla。

在价格方面，Njalla 一个单核、1.5 GB RAM、15 GB 硬盘空间、1.5 TB 流量的 VPS 每个月是 15 欧元，折合近 18 美元，或者说近 125 人民币。

Privex

Privex 的隐私条款很是简短，因为它实行了数据极简主义 —— 如果根本不收集数据，那就不需要写几千字来说明你如何处理数据。

不过虽然看起来很美，但依然存在需要警惕的盲区。

阅读隐私条款时最可怕的并不是它写了什么，而是它没写什么。Privex 的隐私条款就完全没有提及它的注册实体在哪里，也没有提及适用的法律管辖区。这就带来了一个巨大的法律不确定性。如果 Privex 注册在五眼联盟国家，那这份隐私条款在国家安全信函面前就是废纸一张。

然而文档中有一句话极其耐人寻味，暴露了他们的威胁模型：

We hold all database data on our own database cluster, with full disk encryption on all database nodes, protecting your data in the event of our database servers being seized.
我们将所有数据库数据保存在我们自己的数据库集群中，并在所有数据库节点上进行全盘加密，以保护您数据在我们的数据库服务器被扣押的情况下。

绝大多数主流厂商的条款只会讨论数据泄露或合规，而 Privex 罕见地预设了服务器被执法部门物理扣押的情况，这说明他们的防御对象直接设定为了国家强力部门。

在隐私方面上，Privex 做得相当不错：允许用户使用假名，也不会记录用户的 IP 地址。配合加密货币支付，理论上可以实现 100% 的链上链下身份隔离。再加上 Privex 不使用第三方服务：不使用 Cloudflare、不使用 AWS RDS、自建支付网关。先前我在 AWS 的条款分析中提到，数据泄露往往发生在第三方供应商。

现在来说「陷阱」。Privex 会收集用户使用服务器的目的。一个不需要实名、不记录 IP 的服务商，为什么要问用户「买服务器干什么」？

In some rare cases, for specific products, we may be required to share some, or all of your personal details with one or more third parties in-order to provide the service. In the event of this, we will explicitly inform the customer before sharing any details, in clear visible writing.
在极少数情况下，对于特定产品，我们可能需要与一个或多个第三方共享您的一些或所有个人详细信息，以提供服务。在这种情况下，在共享任何详细信息之前，我们将以清晰可见的文字明确告知客户。

Privex 也给自己留了这么个合规的后门。通常来说，这指的是域名注册或软件授权。如果在 Privex 注册域名，ICANN 规定必须有 WHOIS 信息，Privex 必须把信息传给上游注册局。虽然 Privex 承诺会用大号粗体字显式告知，但为了绝对的「数字主权」，建议只在 Privex 购买纯粹的计算资源，不要购买域名或者商业软件授权，以避免触发这个第三方共享条款。

这样看来，Privex 最大的缺点便是缺乏明确的法律管辖区声明。一旦出事，用户没有任何法律途径维权，只能寄希望于 Privex 的技术防御能扛得住。

但先别急！我们最好是再多阅读一下 Privex 的文档，例如 FAQ。

FAQ 解答了我先前的一些疑惑：是的，Privex 是在伯利兹注册的。他们也不向伯利兹本地人提供服务，符合离岸公司的标准操作（为了避免触犯本地法律）。

Privex 有两类区域：标准区域和自治区域。前者是租用别人的机器，受上游供应商管制。如果上游收到投诉，Privex 必须在 12-72 小时内删号。这些区域自然没有数字主权而言。后者的机器是 Privex 自个儿买的，网络设备自己运营，IP 也是自己的。这意味着只有瑞典或者荷兰当地法院或者伯利兹法院能命令他们关机。普通的 DMCA 投诉、滥用报告，Privex 可以选择无视。

对于一般人来说，一个较为扣分的点是 Privex 拒绝法币支付，也就是信用卡和 Paypal 这类支付方式。

接着是对于灰产许可与诚实原则的说明。这一点展现了 Privex 独特的法外狂徒但守规矩的逻辑：

Tor 出口节点许可；
在「使用目的」里老老实实说自己买服务器干什么，跑的是色情网站 Privex 也会保护你；
不过呢，在标准区域里 Privex 依然需要遵守上游供应商的规矩。

价格方面，Privex 提供迷你 VPS，例如一个 256M RAM、单核、5 G 硬盘空间、仅有 IPv6 的瑞典服务器，每月只需要 1 美元。如果看更为标准的单核、1 G RAM、15 G 硬盘空间的瑞典服务器的话，则是 4 美元一个月。

其他国家的服务器会贵一丢丢，这里就只展示瑞典区域的服务器价格了。

Hetzner

Hetzner 的隐私条款的重要部分是折叠起来的，这有点小坑，我还以为那个是超链接，点击后才发现是折叠块。

Unless otherwise specified, your data will remain within the EU and will not be passed on to third parties.
除非另有说明，您的数据将保留在欧盟境内，不会透露给第三方。

这一句话表明了 Hetzner 默认让用户数据归于 GDPR 的保护下。但是重点在于「另有说明」一词。现在 Hetzner 在美国和其他国家都有数据中心。如果购买时选择了美国节点，那么根据之前提到的属地管辖权，这部分数据将不可避免地落入美国 CLOUD Act 的管辖范围。这份隐私政策是针对德国母公司的，它巧妙地没有展开讨论美国分公司的法律地位。

Hetzner 有着极其严苛的预审与 KYC。在用户付款前，他们会通过第三方服务对用户进行风险画像，通常包括 IP 声誉、浏览器指纹甚至名字是否在某些黑名单上。如果被判定为高风险，他们甚至不会告诉用户原因就拒绝服务。

匿名也是不可能的。Hetzner 会将护照信息传输给立陶宛（欧盟国家，受 GDPR 保护）的 iDenfy。较为恐怖的是，Hetzner 会保留足足 14 年的开票数据，用于税法和商法保留义务。

一个大家可能不会注意到的泄漏点是 Hetzner 的网页客服系统外包给了美国公司 Kapa.ai 和 OpenAI。虽然声称有个人敏感信息过滤工具，但在技术上这依然是一个通向美国的后门。

看完数据隐私相关后，还需要阅读 Terms and Conditions，因为前者的内容过短，许多重要条款都没有提及到。

All matters arising out of or relating to these Terms and the contractual relationship are governed by and construed in accordance with German law without giving effect to any choice or conflict of law provision or rule that would cause the application of the law of any jurisdiction – including international jurisdiction - other than German law. Place of jurisdiction for all disputes arising from the contractual relationship is our registered office in Gunzenhausen, Germany. However, we are entitled in all cases to take legal action at your place of business. Overriding statutory provisions, in particular, exclusive jurisdiction, shall remain unaffected.
因本条款及合同关系引起或与之相关的所有事项，均应受德国法律管辖并根据德国法律解释，不得引起任何选择或冲突法律条款或规则适用任何管辖权 —— 包括国际管辖权 —— 而非德国法律。合同关系引起的所有争议的管辖地为我们在德国 Gunzenhausen 的注册办事处。但是，在所有情况下，我们均有权在您的营业地提起法律诉讼。特别是，具有约束力的法定条款，尤其是专属管辖权，将不受影响。

Sec 22 里，Hetzner 表面上声称即使服务器在美国，他们也会按照德国法律办事。

但是……

You are not allowed to publish content that may violate the rights of third parties or otherwise violate the federal or any state law of the US.
您不得发布可能侵犯第三方权利或以其他方式违反美国联邦或任何州法律的内容。

The Services we provide in the USA are subject to the export laws, restrictions, regulations and administrative acts of the United States Department of Commerce, Department of Treasury Office of Foreign Assets Control (「OFAC」), State Department, and other United States authorities (collectively,「U.S. Export Laws」). You shall not use our Services to collect, store or transmit any technical information or data that is controlled under U.S. Export Laws. You shall not export or re-export, or allow the export or re-export of, our Services in violation of any U.S. Export Laws. None of our Services may be downloaded or otherwise exported or re-exported (i) into (or to a national or resident thereof) any country with which the United States has embargoed trade; or (ii) to anyone on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Commerce Department's Denied Persons List, or any other denied parties lists under U.S. Export Laws. By using the Site and our Services, you agree to the forego, represent and warrant that you are not a national or resident of, located in, or under the control of, any restricted country; and you are not on any denied parties list; and you agree to comply with all U.S. Export Laws (including「anti-boycott」,「deemed export」and「deemed re-export」regulations). If you access the Site or our Services from other countries or jurisdictions, you do so on your own initiative and you are responsible for compliance with the local laws of that jurisdiction, if and to the extent those local laws are applicable and do not conflict with U.S. Export Laws. If such laws conflict with U.S. Export Laws, you shall not access the Site or use our Services. The obligations under this section shall survive any termination or expiration of these Terms or your use of the Site our Services.
我们在美国提供的服务受美国商务部、美国财政部外国资产控制办公室（「OFAC」）、国务院及其他美国当局（统称「美国出口法律」）的出口法律、限制、法规和行政法令的约束。您不得使用我们的服务来收集、存储或传输任何受美国出口法律管制的任何技术信息或数据。您不得违反任何美国出口法律出口或转口我们的服务，或允许出口或转口我们的服务。我们提供的任何服务不得下载或以其他方式出口或转口（i）到美国已实施贸易禁运的任何国家（或该国的国民或居民）；或（ii）到美国财政部特别指定国民名单或美国商务部禁止出口人员名单，或根据美国出口法律的任何其他被拒绝方名单上的任何人。使用本网站和我们的服务，即表示您同意上述规定，并声明和保证您不是任何受限制国家的国民或居民，也不在该国家或地区，或受其控制；您不在任何被拒绝方名单上；并且您同意遵守所有美国出口法律（包括「反抵制」、「视同出口」和「视同转口」法规）。如果您从其他国家或司法管辖区访问本网站或我们的服务，您将自行承担此行为，并负责遵守该司法管辖区的当地法律，如果且在这些当地法律适用且不与美国出口法律冲突的情况下。如果此类法律与美国出口法律发生冲突，您不得访问本网站或使用我们的服务。本节项下的义务在本条款的任何终止或期满，或您对本网站或我们服务的使用的任何终止或期满后仍然有效。

这两条（Sec 4 和 Sec 19）否定了 Sec 22 的独立性。只要选择了美国节点，用户就必须遵守美国联邦法律和州法律。原本在德国合法但在美国非法的内容，在 Hetzner US 都是违规的。

为什么说是 Sec 22 被否定，而不是 Sec 22 否定了这两条条款呢。因为接下来的 Sec 23 中说道：

(a) IN THE EVENT THAT SECTION 22 IS NOT APPLICABLE BY LAW, THE FOLLOWING RULES SHALL APPLY.
(b) YOU AND WE AGREE TO GIVE UP ANY RIGHTS TO LITIGATE CLAIMS IN A COURT OR BEFORE A JURY, OR TO PARTICIPATE IN A CLASS ACTION OR REPRESENTATIVE ACTION WITH RESPECT TO A CLAIM. OTHER RIGHTS THAT YOU WOULD HAVE IF YOU WENT TO COURT MAY ALSO BE UNAVAILABLE OR MAY BE LIMITED IN ARBITRATION.
ANY CLAIM, DISPUTE OR CONTROVERSY (WHETHER IN CONTRACT, TORT OR OTHERWISE, WHETHER PRE-EXISTING, PRESENT OR FUTURE, AND INCLUDING STATUTORY, CONSUMER PROTECTION, COMMON LAW, INTENTIONAL TORT, INJUNCTIVE AND EQUITABLE CLAIMS) BETWEEN YOU AND US ARISING FROM OR RELATING IN ANY WAY TO YOUR PURCHASE OF PRODUCTS OR SERVICES VIA THE SITE WILL BE RESOLVED EXCLUSIVELY AND CONCLUSIVELY BY BINDING ARBITRATION.
(c) The arbitration will be administered by the American Arbitration Association ("AAA") in accordance with the Consumer Arbitration Rules (the "AAA Rules") then in effect, except as modified by this section of this Agreement. (The AAA Rules are available at adr.org or by calling the AAA at 1-800-778-7879.) The Federal Arbitration Act will govern the interpretation and enforcement of this section.
The arbitrator will have exclusive authority to resolve any dispute relating to arbitrability and/or enforceability of this arbitration provision, including any unconscionability challenge or any other challenge that the arbitration provision or the Agreement is void, voidable or otherwise invalid. The arbitrator will be empowered to grant whatever relief would be available in court under law or in equity. Any award of the arbitrator(s) will be final and binding on each of the parties and may be entered as a judgment in any court of competent jurisdiction.
(d) You agree to an arbitration on an individual basis. In any dispute, NEITHER YOU NOR WE WILL BE ENTITLED TO JOIN OR CONSOLIDATE CLAIMS BY OR AGAINST OTHER CUSTOMERS IN COURT OR IN ARBITRATION OR OTHERWISE PARTICIPATE IN ANY CLAIM AS A CLASS REPRESENTATIVE, CLASS MEMBER OR IN A PRIVATE ATTORNEY GENERAL CAPACITY.
The arbitral tribunal may not consolidate more than one person's claims and may not otherwise preside over any form of a representative or class proceeding. The arbitral tribunal has no power to consider the enforceability of this class arbitration waiver, and any challenge to the class arbitration waiver may only be raised in a court of competent jurisdiction.
If any provision of this arbitration agreement is found to be unenforceable, the unenforceable provision will be severed, and the remaining arbitration terms will be enforced.
(a）如果法律规定第 22 条不适用，则适用以下规则。
(b）您和我们同意放弃在法院或陪审团面前起诉索赔的任何权利，或就索赔参与集体诉讼或代表诉讼。您在去法院时可能拥有的其他权利在仲裁中也可能不可用或受到限制。
因您通过本网站购买产品或服务而产生或与之有关的任何索赔、争议或纠纷（无论是合同、侵权法或其他性质的，无论是在签订合同之前、现时或将来发生的，包括法定、消费者保护、普通法、故意侵权、禁令救济和衡平法索赔），将仅通过具有约束力的仲裁来解决，并且该解决将是终局的。
(c）仲裁将由美国仲裁协会（「AAA」）根据当时有效的《消费者仲裁规则》（「AAA 规则」）进行管理，但本协议本节对其进行的修改除外。（AAA 规则可在 adr.org 查阅，或致电 AAA 1-800-778-7879 索取。）《联邦仲裁法》将管辖本节的解释和执行。
仲裁员将拥有处理任何与本仲裁条款的可仲裁性和 / 或可执行性有关的争议的专属权力，包括任何不公平性挑战或对仲裁条款或本协议无效、可撤销或以其他方式无效的任何其他挑战。仲裁员将被授权授予法庭依法或衡平法可提供的任何救济。仲裁员的任何裁决将对各方具有最终约束力，并可在任何有管辖权的法院作为判决执行。
(d）您同意以个人身份进行仲裁。在任何争议中，您和我方均无权在法庭或仲裁中加入或合并其他客户的索赔，或以其他方式作为集体代表、集体成员或以私人公益律师身份参与任何索赔。
仲裁庭不得合并一人以上的索赔，也不得以任何形式主持代表性或集体诉讼。仲裁庭无权考虑此集体仲裁弃权条款的可执行性，并且对集体仲裁弃权条款的任何质疑只能在有管辖权的法院提出。
如果本仲裁协议的任何条款被认定为不可执行，则不可执行的条款将被分割，其余的仲裁条款将得到执行。

强行在美国执行德国法律是行不通的，他们的 Plan B 是美国仲裁协会（AAA）的强制仲裁。强制仲裁意味着用户放弃在法院起诉的权利，也放弃了陪审团审判。这是典型的美国式法律压迫工具，旨在降低大公司的诉讼成本。

Sec 19 还提到了 OFAC（Office of Foreign Assets Control，外国资产控制办公室），也是美国政治部的制裁者：如果美国决定制裁某个实体，Hetzner 为了保住其美国业务，必须切断该实体的服务。这证明了其管辖权不再是独立的，而是附庸于美国外交政策的。

You are not allowed to publish content that may violate the rights of individuals or groups of people, or that insults or denigrates these people.
您不得发布可能侵犯个人或群体权利、或侮辱或贬低这些人的内容。

和其他提供商一样，Hetzner 也给自己预留了极大的主观裁量权：什么是侮辱？什么是贬低？难道任何引发争议的政治或社会内容的站点都要被关闭吗？

Hetzner 必须被拆分为两个完全不同的实体来评价。讲完了 Hetzner 在美国的分公司后，再来说说母公司的原罪。

根据 Terms and Conditions 的 Section 8.3 和 8.4，只要 Hetzner 的自动化系统监测到用户的服务器有异常流量或者收到了第三方投诉，他们通常会先拔线，再发邮件通知用户。用户必须在断网状态下自证清白。对于追求高可用性的用户，这种官僚逻辑自然是致命的。

Hetzner 也明确指出他们在监视元数据，通常是分析连接频率、目标 IP 分布和端口扫描行为。用 Hetzner 的机器做任何会产生大量连接数的行为都会被系统自动判定为攻击行为，进而触发自动封锁。

支付方面，Hetzner 不支持 Monero（XMR）或完全匿名的加密货币支付。他们只接受信用卡、PayPal 或银行转账。

Hetzner 的合同需要提前 30 天通知并在月底终止。这种周期过于僵硬，对于需要灵活部署或者紧急撤离的用户来说是一个巨大的财务和安全负担。

价格上，一个 2 VCPU、4 GB RAM、40 GB 硬盘空间、20 TB 流量的服务器最低可以达到每月 3.49 欧元，也就是 4 美元、29 人民币。

Bahnhof

我找不到 Bahnhof 的隐私条款…… 留给未来的自己吧。

结论

选择 VPS 的之前，一定要搞清楚自己买这个服务器做什么。如果是想要记录敏感内容（色情网站不算啊），就必须找到提供法律保护的服务商；如果是极客或者加密无政府主义者，你需要找到那些提供身份隔离的服务商；如果是开发者或者中小企业主，且业务完全合法，那选择稳定、便宜且合规的服务商会更好。不过无论选谁，只要看到美国节点，请直接 pass。

这篇文章也绝非真理！我可能遗漏一些细节，有可能无视了服务商们实际的操作 —— 毕竟完全不按照条款运作的公司貌似也不少见 —— 甚至可能说错了内容。如果有任何需要修正的地方，还请务必联系我。

细数了这些「面向隐私」的 VPS 服务商的罪恶后，或许有人会想要使用自己家中的物理服务器。但在我看来，它依然不是旅途的终点，因为家中的物理服务器会和互联网服务提供商有所牵连。具体是怎样我就不展开说了，很多民用互联网服务提供商也禁止搭建公开服务。

初次走半马

2026-01-19T05:00:00.000Z

室友这些天喜欢看橙飞一下这个 BiliBili 频道。频道主是一位大胃王，也是一位马拉松跑者，吃饭的时候看他吃饭会格外香。不过呢他跑马拉松这件事情引起了室友那奇怪的好战之心，想要试试一天内走「全马」。不过嘛，结果从本文标题里就可以看出……

「全马」指的是「全程马拉松」，即 42.195 公里；「半马」顾名思义，是「全马」的一半。虽然通常来说马拉松都是跑的，但你要想走也没有关系，还更适合我这个运动白痴。考虑到我的身体状况和缺陷，我和室友最终决定这一天走完全马即可。

这一周室友都很兴奋，还去咨询了自己的几位朋友 —— 她们都是马拉松跑者或者走者，其中一位还是踢踏舞舞者，可以在跑步期间感受到脚步的节奏，听上去颇为有趣 —— 她们给出了一些不错的建议，例如厕所要时刻留意、袜子建议多带几双……

不幸的是，约定好的这天下起了雪。我们原本打算早上四点就起床的，但因为嗜睡、到六点才起，望向窗外时外面已是大雪飘飘。我此时已经打起了退堂鼓：外面又是下雪和下雨，一整天还只有零度，真的有必要在这个日子出去吗？室友则认为既然已经约好了，外面下火也得出去。为了防止冻着自己，她还穿了两层保暖衣，我则是戴了一个从未戴过的针织帽。

我们身上的装备除了彼此的手机，就是一个充电宝、昨夜剩下的冷鸡块和折叠雨伞。因为担心期间太无聊，我们还带了无线蓝牙耳机，不过这一整天我们都没有使用过就是了。

路线昨天就已经被室友规划好了。我们要先走到昆斯博罗大桥（Queensboro Bridge），它在曼哈顿的东边，连接起了曼哈顿和皇后区。

从家里过去的距离大致是五公里，这期间我看到了一个当地餐饮业的趋势：做日料。这里的「日料」指的是那种小手卷，我个人并不爱吃。这种店通常会开在上班族多的地段，价格贵得离谱，材料一眼看过去就是便宜货。但是这种店开得不少，意味着当地人就爱吃这一套。或许我找不到「体面工作」可以考虑下做寿司师傅，算是我的 Plan S 吧。

这五公里走起来很难受，快到桥的时候我们都感觉身体有点不适，遂走去一家最近的 Dunkin' Donuts（唐恩都乐；我的天我都不知道它的中文译名是这个）买了杯抹茶。我不喜欢抹茶，所以没有喝多少，都让室友喝去了。

昆斯博罗桥比曼哈顿桥好看点，但是没有布鲁克林大桥好看。我建议想要走桥参观的人们只去布鲁克林大桥，曼哈顿桥实在是太丑了，还特别吵！布鲁克林大桥是西边的那座，不要走错了。说回昆斯博罗桥，我们站在上面望向东河。因为雪，只能看到大片大片的雾，白茫茫的。期间我实在是受不了这个针织帽 —— 它会压住我的眼镜，很是难受 —— 把它戴在了室友头上，别说，还挺搭配。

走到桥的一半我们看到了罗斯福岛，我还从未上去过呢。据说可以坐缆车过去，未来可以坐坐看。

整个桥的长度差不多是二公里，走完后我就走了七公里了，身体意外地没有先前那样不舒服，我也不觉得渴。倒是室友听了「走路大师」的意见后，对厕所产生了执着，非要去找厕所上。我们去了星巴克，室友想着是不是买点东西更好，不然感觉坐在里面不自在。我说你放心，这种店的员工不会在乎的，他们忙得要死哪儿还有精力管你。

桥下是皇后区的长岛市，是一个对我来说比较新颖的区域。我曾经来过这里的攀岩馆，高兴地接受了自己恐高、抓力弱，以及脚型奇怪穿不了攀岩鞋的事实。长岛市的中国餐厅不少，貌似是一个留学生比较多的地方。房价不能说是特别高？总要比曼哈顿中城的房租便宜吧。它的地理位置也不错，西边可以快速抵达曼哈顿，东边可以坐车去法拉盛大吃一顿（我认为法拉盛作为华人区还是有不可替代的地方在的）。

这时候的路线基本上就是跟着 7 号线和 LIRR（Long Island Rail Road，长岛铁路）的铁轨走。毕竟是有铁轨的地方，道路都变得宽敞不少，建筑物除了仓库就是加油站，还有一家装修漂亮的狗狗托管所，叫作 Dozo Dog LIC。我们可以通过玻璃清楚地看到里面的狗狗在和工作人员们玩耍。

路上，我向室友提到了一个命题：「你更想要共享知识而将数据都免费开放，还是为了版权和盈利而严厉打击盗版？」她认为只有在自己足够富足的时候，她才愿意将知识分享出去。这让我想起前些时候我做的「你是 Copyleft 还是 Copyright」测试，结果显示我是 Copyright，虽然和 Copyleft 的比例相差没有太大。

走了一会儿我们走到了 Sunnyside 区，原先以为这就是一个物欲低的住宅区，却没想到发现了一个很大的美食城，不过来的时间太早，还关着门。令人意外的是，这个美食城内貌似都是中国餐厅，但这个区看着并不像华人区。

事后我查了地图，才发现我们走的只不过是 Sunnyside 较为偏僻的那条路，再往南走两个大道就是 7 号线的地铁站以及一大堆餐厅 —— 最开始说你物欲低真是抱歉啦。

走到一个供孩童玩耍的公园时，发现门口摆放着数个椅子和箱子，好像是临时放在这里的活动用具。其中一个蓝色箱子上贴着 Cursed Books 的字眼，真是好笑。

回看照片时发现 C 没有被拍到，我更好笑。

再往东走，可以看到一个土耳其小超市，卖很多精致的甜品和零食，价格并不贵。吸引我们走进去的是它门口用中文写着「我们有卖奶皮子喔！」走进去找了半天并没有找到这个叫作「奶皮子」的东西，到底什么是「奶皮子」啊？

隔着一条街有一家归正宗教堂，意外的是他们居然对性少数群体友善。我简单地查了一下，这主要是源于开放派教会的观点，认为对圣经的解释可以随着社会对正义、人权和科学理解的进步而不断更新。

这让我想起了《地。－关于地球的运动－》这部漫画里临近尾声的一幕，一位角色作为教会的人，反对了教会整部漫画里对地动说的看法 ——「地球是动的又如何？这反而可以证明上帝的伟大，我们对圣经的解释不应该拘泥于过去的错误理解。」

走到 Woodside 区时，或者说重新回到 7 号线高架下时，可以明显感受到我们走到了一个人口密集的社区。这里感觉是墨西哥人的社区，道路十分拥挤的情况下还能看到很多人在路边摆摊、开餐车。你还别说，有些烧烤摊的串串看上去很好吃的样子，就是不知道多少钱。

因为下了雪，高架上积累了不少水，一滴滴往我们头上流。走这一段路是我认为这一天里最痛苦的经历，人实在是太多了，还要撑着伞挡着头上的雨水，时不时还有雪下下来。因为快到法拉盛了，我们也不打算在这里就餐，只能饿着肚子继续向前走。

我发现这种社区里一定会开不少花店，让我很好奇花店赚钱么，明明这里的花店的价格也不是很贵的样子。

一位朋友住在 Woodside 区旁边的一个区，我给他发了一个定位，让他猜猜我是怎么过来的。他听到我说我是步行走过来之后，整个人都惊讶得不行，连发了许多问号，哈哈！

走了这么久，找厕所就成了一个问题。我推荐一个开源的 App，叫作 LavSeeker，可以根据 OpenStreetMap 上的信息在地图上显示厕所的位置。不过这个 App 有一些使用上的逻辑问题，比如用户的位置不是实时获取的，需要点击右上角的按钮先定位一下，过一小段时间才会显示附近最近的厕所。因为太冷了，我除了拍照外都鲜有掏出手机的时候，绝大多数情况下我们还是进店里问有没有厕所。

多数本地的店里都不提供厕所，就算有、也需要你买东西成为「顾客」才可以给你使用。不过有些地方还是一定会有厕所的，例如星巴克、麦当劳和超市（首选那种连锁超市，例如 Whole Foods）。偏僻的地方可以考虑问问加油站，以及找公园。公园里的厕所比想象中干净那么一点点，但还是有着说不上来的压抑感。

言归正传，我们走到了花旗球场。这里人烟稀少，路上都是厚厚的雪，走起来很不舒服。我很后悔没有穿靴子来，不过我的脚就算穿靴子了，也会先因为脚型奇怪而提前喊苦吧。室友为了好看，穿上了漂亮的羊毛大衣，但是这个材质会吸水，在雪天待久了只会徒增难受。

室友这时候提起了昨天她去参加的生日派对。她一直都是一个不喜欢和「无聊的人」打交道的人，对「朋友」的标准很高 —— 在她眼里，好朋友只有我一个，剩下的都是酒肉朋友或者生意伙伴。过生日的这个人（以下简称甲）对她来说就是个「有点无聊的人」。不过碍于甲很喜欢她，两人之间有点交情，她最终还是接受了派对邀请。

搞笑的是，室友之前为了公司而做的宣传视频被甲的朋友挖了出来（是的，室友就是我口中的「项目管理」；整个故事见十一月十日），还被私下嘲笑。这件事要是她不知道也就罢了，偏偏甲莫名其妙地选择了直接把聊天记录甩给她看，搞得她心里七上八下 ——「你的朋友嘲笑了我，你给我看又是想怎样？」甲虽表示无意冒犯，觉得这些记录可能对她有帮助，但这逻辑实在感人。

很多时候，人做错事若是源于「坏」，尚有逻辑可循；但若是源于「蠢」，就真得小心了，因为你根本不知道他在想什么。甲显然属于后者。室友说，她根本不知道甲在那些朋友面前传了什么话，因为甲既然能把朋友的闲话复述给她，就意味着在甲心里，这种「双向传话」压根无所谓。

据说那群人在背地里把她无缘无故数落了一通，还追问甲关于她的事情。甲转头又把这事告诉了她，惹得她烦躁地表示：「你们要是想要知道什么的话就直接来问我吧！」但果不其然，没有人敢主动联系她。

这次生日派对里，甲的那些朋友也在场。那些背地里说得最欢的人，见了面却不敢吭声，装作初次相识，这让室友倍感无趣。整个派对的氛围也很诡异：明明甲才是寿星，全程叽叽喳喳抢话的却是那群人。他们不仅声音很大、时不时爆粗口，还喜欢在公共场合高谈阔论一些不合时宜的话题，例如「孩童被强奸和种族歧视，你最能接受哪一个？」拜托，这种问题私底下说说也就算了，不要在公共场合大声说出来啊！

总之，这场生日派对算是还了甲的人情。事后她问我我会不会开生日派对，我回道：「你想想跟我认识的这些年来我开过吗，我只有『被开生日派对』的份儿。」她被逗乐了，两人哈哈哈地笑作一团。

走过花旗球场，就能抵达华人区法拉盛。不过在说法拉盛之前，我要先说一下球场附近好玩的东西：室内溜冰场 World Ice Arena。这里的价格不算贵，还提供付费教学课。不过据说曼哈顿中城 Bryant Park 的那个溜冰场可以免费入场。

至于为什么我会想要提起这件事，是因为我们穿过法拉盛河时，路上有两个女生叫住了我们，问我们知不知道 World Ice Arena 在哪里。根据她们来的方向，我推测出原先告诉她们路线的人并不知道如何快速抵达这个溜冰场：假设你从 Mets-Willets Point 站下车（无论是 LIRR 还是 7 号线地铁），你都可以通过南边的 David Dinkins Circle 一路向东走到溜冰场。然而她们的原定路线是向东走到法拉盛的 Main Street 再从西南方向走，相当于绕了一大圈。

说回法拉盛，这可是纽约市相当有名的华人区。这里有着各种各样的美食，对我这个北方胃 + 碳水大王来说实在是喜欢得不得了。像海底捞、快乐小羊等国内知名品牌都在法拉盛有分店，不过这类店我吃得不多，我最喜欢的还是本地一个面馆 —— 皇后区法拉盛公共图书馆附近的郑州烩面。听名字会以为它是一家普通的面馆，但其实提供的食物很多，量大管饱好吃的同时还不贵，实在是太稀奇了。我偶尔来这里玩舞萌 DX 时，就会来这家点上一碗羊肉烩面吃。

不过这次是和室友一起来的，她对碳水不是特别感冒，想要点个菜我俩一起就着大米饭吃。最后我俩选的是干锅肥肠，加了份藕片（居然要六块钱），她一碗大米饭，我两碗。最后小费前总计三十块整。整体服务还可以，当时有点忙服务生跑来跑去的，也能理解一点吧。这家店还会提供免费茶水，茶水没了也会主动给你续，光是这点我就觉得给小费很理所当然。

吃饭期间来了一个乞讨的，我前段时间来法拉盛玩舞萌 DX 时也遇到了这个人。他在店里走来走去，用英语说着他失业了，问有人能不能给他钱。老板娘用中文告诉我们不要给他钱，他这么年轻就出来乞讨要钱，如果给了钱他未来每天都会来，到时候店就不要开了。

见没有人理他，他还走到大门口处挡着其他客人、不让他们进来。要不到钱还恶意妨碍店内生意，实在是不道德。

可能也有读者认为这种人很苦，给点钱不好么。说实话，只要你来纽约市久了，自然而然就会对这种乞讨者祛魅。

吃完饭后我们继续向东进发。这时候我们已经走了十七公里。路上路过了 Koreatown（韩国城），也就是韩国人版本的唐人街。在曼哈顿中城也有一个韩国城，就在 Macy's（梅西百货）附近。

我们经过了一个华人超市，在里面买了一些小零嘴和桃子味儿的脉动，现在想来其实应该买外星人电解质水。除了矿泉水，瓶装饮料里我只会喝小样和可乐，去超市也是为了找小样。离开超市的时候我才发现其实有卖小样，只是不单卖，很是让我气愤。

先前室友上厕所时我翻阅着 Mastodon 解闷儿，看到一篇和 Crypto，即虚拟货币相关的嘟文串。我对金融并不了解，只是大概地知道它在技术方面上的实现原理。室友和我完全相反，她是个技术小白，但在金融和商业嗅觉上却极其敏锐。

她说现在各国政府都开始监管 Crypto，并不推荐靠 Crypto 来避税，一般人当股票玩玩就好了。就算是想要自由地使用自己的资产，也会因为售卖货币的机构已经和政府有关联而变得很难。无论如何买币的人的信息都会被上交给政府，而美国政府对于人民的调查权是无限期的，也就是说政府哪天抽风了就是想查查你玩，你就一定会被扒干净。

她认为这类建议最好不要盲从。如果未来真的出了问题，你是找不到出建议的人的，想要玩的话还是先自己学明白吧。

这番话引出了我心中长期存在的一个疑问：Crypto 和股票到底有什么区别？她耐心地给我补了堂金融课。

股票的本质是你拥有一家公司的一部分。对于上市公司而言，它们通过出让股份来筹集资金去研发和扩张，因此可以被一般人买去。每一年它们需要根据赚来的钱选择取多少给研发、取多少分红给股东。

有人想要提前变现，有人想现在就入场…… 于是一个股票市场就出现了：我认为这家公司会赚很多钱，持有它的股票能够拿到更多的分红，所以我要买这家公司的股份；你觉得这家公司赚钱有点悬，所以想要赶紧卖出避免亏损。根据双方预测的股份价值，我们会进行一次交易。也就是说股份的价值是完全主观的，基于我们认为它值多少钱。但是股市所锚定的是公司的生产力，是实体资产。

我想起了两件事：一个是特朗普刚上台没多久和马斯克之间的冲突，市场担心特斯拉被针对，导致大量投资者抛售特斯拉股票；另一个是去年 CS2 还是 CS:GO 因为 Valve 的操作、导致整个饰品市场一夜之间崩盘。

股份、Crypto 和游戏资产都是数字资产，这些东西并不是客观存在的，也都有一个可以随意控制市场的「角色」存在 —— 股份是分发股票的公司，Crypto 是政府的监管，游戏资产则是游戏公司。

区别在于，分发股票的公司受法律保护，还算稳定些，虽然还是有着「炒」的元素在；游戏资产是纯粹的割韭菜；而 Crypto 的重点在于「共识」，说直白点它完全依赖于市场里的人相不相信它值钱。一旦监管介入，切断了法币入金和出金的渠道，或者像室友说的那样开始秋后算账，「共识」就会迅速崩塌。

我们沿着纽约州公路 25A 继续向东走，时不时可以看到中国餐厅、韩国餐厅和日本餐厅，但是整个区域给人感觉不知道是什么区，好像什么人都有，又好像什么人都没有。

快走到 Little Neck Bridge 的时候我已经感觉到达了自己的极限，也就是半马。这时候的我膝盖后方的肌肉明显开始抽搐，疼痛不已，只能靠僵硬地移动大腿根部的骨头来行走。

我们停在了那附近的 Popeyes（博派斯；派派思；大力水手炸鸡；佰百鸡…… 译名真多），点了份五美元的炸鸡吃，然后我就吃到了这辈子最难吃的炸鸡 —— 又油又干，鸡翅炸老了，咬下去连骨头都是脆的，肉硬得不行，真是恶心！没吃几口我就把食物打包了起来。

因为我到了极限，室友不得不调整我们的行走路线。她原先的计划是走到 LIRR 的 Great Neck 站点，然后再往西南方向走去 Jamaica（牙买加）站点，完成全马的目标。

此牙买加非彼牙买加，只是皇后区的一个社区而已，约翰・肯尼迪国际机场就在这里。

问题在于，这时候天已经开始黑了，我走完半马就已经开始身体不适，继续往东走只怕会愈来愈难回家，更何况雪依旧在下着。室友明显看着很不开心，但为了我的状况，最后决定一起走到牙买加区的 F 号线最后一站，然后坐 F 号线回家。

离开了更繁荣的主道路后，我才意识到人烟稀少的住宅区有多么难走。这里和城市的住宅区不同，路上几乎没有人，人们出行都是靠车，这也代表人行道都被大学覆盖，有些人行道干脆设计得很有问题，像是不希望人们在这里走的样子。

说实话，就算是让我走到 F 号线的最后一站，那也是差不多七公里的距离。我已经临近了身体的极限，还因为忘记在 Popeyes 上厕所，膀胱憋得难受，实在是走不到那里，所以还是让室友在 Oakland Gardens 区提前停止了走马。我们在公交站的附近找了下厕所，一家 99 美分店（AKA 一元店）很好心地给了我们他们厕所的钥匙，实在是太友善了。

比较好笑的是，我上完厕所后立马觉得身体抖擞，好像又可以继续走了。不过我还是没有那么做…… 天黑了快回家吧，下次可以继续，我明天还要上班呢。

接下来就是坐公交、转地铁、回家了。下车时看着无比熟悉的地铁站，忽然觉得今天的所有经历像梦一样。哎，我居然一路走到了那么远？我吗？回家后我们先是洗了澡。感受着热水从花洒里喷到身体上的感觉，我心里想着现代技术的发达和我有多幸福 —— 或许人就是这么「下贱」吧，必须得感觉难受才会知道平日过得有多舒服。

室友和父母打电话的期间，她的体质真是可怕，居然意犹未尽，还想要之后每两周走一次马。我和你们这群有足弓的人没话说。

我躺在床上查看自己今天拍的照片。我有个自托管的 Immich（虽然只是本地的 Docker 容器），可以很轻松地将手机上的照片上传到电脑上查看。看着地图里的图片分布，让人觉得无比有成就感。虽然今天只走了半马，并没有达成室友原先定的全马目标，但已经够了。我打算先将今天所发生的事情都写成博客文章发布，结果写到一半我就坐着睡着了…… 所以这篇文章是隔了一天才写完的。

这是我第一次写流水账。流水账如何才能写得好呢？我很好奇，毕竟我还在国内上小学时老师可没有教我这个。我现在只能靠图片来分隔开一些内容，但或许整体看上去还是会有点无聊？总之我已经很努力在使用连接词了…… 呃啊。

这也是我第二次用 Emacs 写博客文章。Hexo 框架本身并没有那么支持 Org Mode，就算使用 Org Mode 渲染器也就只是把 Markdown 换成 Org Mode 来写，还是没有很棒地利用起 Emacs + Org Mode。

我的方案是先创建一个专门存放 Org Mode 文件的目录，这个目录也会被我用来存放 GTD（Getting Things Done 的简写，是一种时间管理系统，未来我会写一篇和这有关的文章）工作流相关的文件。当我写完了这篇 Org Mode 文章，我会用 Emacs 配置内我已经写好的方法将其转换成 Markdown 文件，并保存在 Hexo 源文件内，这期间 Front Matter 什么的都可以利用 Emacs 来完成，实在是太方便了！

扯远了。让我总结这一天的话，我认为走马是一个颇为有意思的活动。如果有一个有趣的朋友陪着自己完成的话，全程不会特别无聊。不过室友认识的马拉松跑者或者走者平日都是独自一人完成目标，要是你是一个享受这一活动的人的话，说不定走着走着就会进入心流状态呢？

谈模仿学习与身份误区

2026-01-16T05:00:00.000Z

我在网络冲浪时看到了一位网友的求助。他自小就没有被教导如何和人打交道，长大后先是被母亲认定是一个孤僻的人，又被学校的环境误导，以为优秀的道路注定是孤独的、维持人际关系不重要。

这些因素堆叠在一起，当他意识到的时候，自己已经错过了积累社交经验的黄金期。

在此背景下，我真挚地给出了自己的建议：你只是不知道怎么说而已，你可以通过学习他人的对话来补上这个技术缺陷。这却遭到了第三人的反对，他认为这会让当事人丢失自己，不如让当事人以自己的方法来。

我们常说大学是一个「小社会」，此话不假。对于社交能力的缺失让他开始感到痛苦；他其实很渴望别人能靠近自己，也希望自己能够回应别人的好意。

但因为他从未学习过如何社交，许多本可以拉近别人距离的社交场合都被他无一例外地搞砸。在其他人眼里，他看上去是那么冷漠或者奇怪，但他根本不是那个意思，他只是不知道如何接话。

社交本质上是一套由符号、编码和反馈构成的系统。这听上去像是把人以计算机来看待，颇有股「只要学了计算机就可以把所有东西用它来解释」的傲慢劲儿。但实际上，这是许多人没有注意到的社交的另一面。

具体而言，对于社交经验匮乏的人们来说，他们面临的挑战通常不是缺乏表达欲，而是将内在意图转化为有效社交信号的能力。如果一个人都无法分辨笑话，那要求对方「做自己」不过是一个伪命题。当事人缺乏表达手段，展示出来的自己往往是受限且扭曲的。

社交能力充其量也只是一种技能，数年来人们对其的误解导致了大众对它的敬畏：「我不知道如何回复，这意味着那是我的性格，我只是不愿意和他人交流。」但这很多时候又是不对的，因为人们实际上很渴望与人交流和联系。大家一边承受着孤独，一边却又无动于衷。交流是人类的本能，社交是一种从小人们就要学习的技能。用这个角度来看，我们的「孤独」就可以是被改变的了！

当然，如果你是一个沟通能力没有问题的孤独人，那就是另一码事了…… 未来我会对此发表一些暴论，敬请期待？

社会学家 Erving Goffman 提出过拟剧论：社会生活分为前台和后台。社交能力和人格无关，人们是可以采取工具性沟通的。在这种模式下，社交不再投射自我，更多是为了达成特定的目标的手段。这也不是一个应当被批评的行为，很多时候人们会下意识采用工具性沟通来适配社会规则，和「背叛自我」没有半毛钱关系。

回到我的观点。既然社交能力是一种技能，就和画画、编程一样，那么要如何学会它呢？在我看来，许多东西都需要经历这样的一套流程： 模仿－内化－创新。孩童学习一件事情几乎就是依赖着「模仿」和「重复」，他们会模仿自己看到的所有人，然后不停地重复。这也是为什么长时间陪伴孩子的那个人在孩子的成长里是最重要的，通常来说这个人是父母。至于重复，只要你带过小孩子，就会知道他们有多么热衷于只做一件事情、只看一个电视频道……

一个画家必须先通过大量临摹来掌握透视、色彩和线条等技术手段，才能最终创作出具有个人风格的作品；如果画家拒绝学习技术，其画作呈现出的笨拙并非「真我」，仅仅只是「无能」。既然孩童是通过模仿他人才学会的社交，那错过了这一时期的人们也必须得让自己再次变成孩子。

认知科学认为，社交能力并非由抽象的理论构成，而是由无数个具体的「条件－反应」链条组成。当能力达到一定程度，个体自然会从「完全模仿」过渡到「选择性采纳」，最终形成带有个人色彩的社交风格。只有当社交动作不再占据一个人的全部认知资源时，他才有余力将真实的自己注入到谈话中。

值得注意的是，模仿他人说话与保持自我从来都不是此消彼长的关系，这也是为什么我十分排斥第三人的回复。他错将当事人的技能缺失认为是他的真实一面，完全无视了他对此的烦恼和痛苦，轻飘飘地反驳了我的建设性建议，要求当事人继续「当自己」—— 当事人的「自己」到底是什么？我认为肯定不是因为不知道该说什么、而被同学们误以为高冷的那个他。要知道，社交中的「自我」是动态构建的，而非静态存在的。

总之， 强大的社交能力反而意味着我们可以更好地表达出自己。这是一个反直觉的概念：我们模仿他人是为了展现出完全、真实的自己。但是事情就是如此运转的。

缺乏社交技巧的人往往因为无法融入群体而感到自卑，这种负面情绪反而会极大地侵蚀自我的独特性。通过学习社交技巧，个体如果能获得更顺畅的社交反馈，反而可能建立起更强的自信，从而更有能力在公共场合展示出真实的自我。

技能缺陷从来都不是一种性格选择。我认为现在的社会经常将这两点搞混 —— 不，你不是 自闭症、抑郁症、ADHD…… 你只是不会「社交」这个能力而已。自然，我不是说所有自闭症、抑郁症、ADHD 等患者都是如此，这只是夸张式表达而已。

更进一步说，当事人被母亲贴上了「孤僻」的标签，并被误导认为优秀的人不需要人际关系。这些事情对于一个还未稳定的个体而言，是一瓶瓶毒药。我会这么评价，是因为我也经历过同样的事情。我很高兴我身边有一位讲话十分直白的人，教会了我许多过去从未被教导过的社交礼仪。这也让我愈发对自己的父母感到不满，他们为了自己，数次伤害还是孩童的我，最终将我的惨状视为笑柄。

自然，第三人的考量不是并无道理。个体为了融入社交环境，可能会刻意压抑本能反应、模仿他人的行为。只是放在当事人的案例里，这只是廉价且无效的安慰，还回避了当事人正在经历的认知困境和技术门槛。这其实让我想起了另一个现象：只看简单的一段，然后只以事情的一面来发表意见或者建议，最终得出的结果牛头不对马嘴。事情是多面性的，你怎么可以因为我说了「模仿」，所以认定我的建议必定会让当事人压抑自我呢？

:PROPERTIES:
:CAPTURED: [2026-01-16 Fri 12:52]
:END:

Emacs 里配置邮箱服务

2026-01-11T05:00:00.000Z

我开始在我的笔记本电脑上使用 EndeavourOS＋i3WM 以及 Emacs 了。刚开始使用 Emacs，实在是被它的能力上限所折服，巴不得所有事情都让它来做 —— 例如邮件收发。

关于邮箱收发，我最终决定使用这样的邮件客户端流：Mu4e 客户端＋mbsync。

首先需要安装以下内容：

sudo pacman -S isync msmtp msmtp-mta passyay -S mu

其中，isync 用于 IMAP 同步，mu 是邮件索引器，msmtp 是 SMTP 客户端用于发送，pass 则是密钥管理器。

配置邮件同步，需要创建 ~/.mbsyncrc：

Create BothExpunge BothSyncState *# === Gmail ===IMAPAccount gmailHOST imap.gmail.comUser 邮箱地址PassCmd "pass show email/gmail"TLSType IMAPSAuthMechs LOGINIMAPStore gmail-remoteAccount gmailMaildirStore gmail-localPath ~/Mail/Gmail/Inbox ~/Mail/Gmail/InboxSubFolders VerbatimChannel gmailFar :gmail-remote:Near :gmail-local:Patterns *

在终端初始化目录： mkdir -p ~*Mail*Gmail。

同步前需要生成 GPG 密钥：

gpg --full-generate-keygpg --list-keyspass init pass insert email/gmail

最后一个命令是交互式的，需要自行粘贴邮箱的密码。对于主流的邮箱，需要输入应用密码，Gmail 和 iCloud 都是这样。

使用 mbsync gmail 来测试单个邮箱的连接。全部一起连接用 mbsync -a。

初始化 mu

我们需要初始化 mu，告诉它邮件都存放在哪里、哪些是我们的邮箱地址：

mu init --maildir=~/Mail \   --my-address=邮箱地址 \   --my-address=另一个邮箱地址

最后建立索引：

mu index

将我校邮箱加进来

CUNY 用的是微软的服务，并且关闭了基本认证，必须使用 OAuth2。

我最初的方案是，弄一个脚本处理 OAuth2 握手并自动刷新令牌，也就是 mutt_oauth2.py 脚本（见 neomutt）。这个脚本需要被伪装成 Mozilla Thunderbird，来绕过应用注册审批。

mkdir -p ~/.mbsynccurl -L -o ~/.mbsync/mutt_oauth2.py https://raw.githubusercontent.com/neomutt/neomutt/master/contrib/oauth2/mutt_oauth2.pychmod -x ~/.mbsync/mutt_oauth2.py

然后这么调用：

python ~/.mbsync/mutt_oauth2.py ~/.mbsync/cuny_token --verbose --authorize --provider microsoft --client-id 9e5f94bc-e8a4-4e73-b8be-63364c29d753 --authflow authcode --email <你的邮箱地址>

出现 Client Secret 时直接按回车，复制终端里给的 URL，最好是在无痕浏览器里登录。登录完会跳转到一个页面，赶紧复制 URL 下来，否则过几秒会跳转到警告页面。这个 URL 里有个 code 参数，复制下来（注意后面的 session_state 参数，删掉），输入到终端里……

然后你会收到 User is authorized but not connected 的消息。

为什么会这样呢？我们的 OAuth2 配置是没有问题的，但是 CUNY IT 部门把邮箱的 IMAP 和 POP 协议都禁用、不让用在应用上。

解决方法是，用 DavMail 在本地机器开启一个 IMAP 端口，mbsync 会连接到它，发送的请求会被转换成 Microsoft EWS 协议，也是 Outlook 网页版和官方客户端使用的协议。DavMail 会向微软的服务器请求数据，并伪装成 IMAP 返回给 mbsync。

创建 ~/.davmail.properties：

davmail.mode=O365Manualdavmail.uri=https://outlook.office365.com/EWS/Exchange.asmxdavmail.imapPort=1143davmail.smtpPort=1025davmail.ldapPort=1389davmail.popPort=1110davmail.bindAddress=127.0.0.1davmail.oauth.clientId=d3590ed6-52b3-4102-aeff-aad2292ab01cdavmail.oauth.redirectUri=urn:ietf:wg:oauth:2.0:oobdavmail.tokenFilePath=davmail.propertiesdavmail.ssl.nosecurecaldav=falselog4j.rootLogger=WARNdavmail.logFilePath=/var/log/davmail.logdavmail.keepDelay=30

davmail.oauth.clientId 里的内容是微软 Outlook 官方客户端的 ID。
用 davmail ~/.davmail.properties 启动，它会出现一个 URL，也是建议用无痕浏览器使用。唯一的区别是，这次登录后会一直卡着，一定要在登录前打开 Inspect 的 Network 标签页，里面会有一个 302 状态码的请求，location 值里的 URL 有个 code 参数，取出来粘贴到 DavMail 里。

在另一个终端里运行 mbsync：

mbsync cuny

发送邮件

我们需要使用 msmtp 这个外部程序来发信。

如果你有着需要使用 DavMail 才能连接上的邮箱地址，msmtp 也需要通过 DavMail 发送邮件。创建 ~/.msmtprc：

defaultsauth            ontls             offtls_starttls    offlogfile         ~/.msmtp.logaccount         cunyhost            127.0.0.1port            1025from            邮箱地址user            邮箱地址password        "随便写"account         gmailhost            smtp.gmail.comport            587auth            ontls             ontls_starttls    onuser            邮箱地址from            邮箱地址passwordeval    "pass show email/gmail"tls_trust_file  /etc/ssl/certs/ca-certificates.crt

设置文件的权限：

chmod 600 ~/.msmtprc

你可以这样测试发送：

echo "This is a test email from msmtp via DavMail." | msmtp --debug --account=发的账户 另一个收的邮箱

配置 Emacs

现在我们的邮件系统由三个组件协同工作：

mbsync 负责收
mu4e 负责界面和索引
msmtp 负责发

我的方案是，在一个配置文件内写好所有的邮箱账号信息，例如这样：

(:name     "CUNY"                           ; 显示名称   :email    "邮箱地址"   :fullname "blabla"                         ; 发件人名   :maildir  "CUNY"                           ; ~/Mail/ 下的文件夹   :inbox    "Inbox"                          ; 收件箱路径   :sent     "Sent"                           ; 已发送   :drafts   "Drafts"                         ; 草稿   :trash    "Trash"                          ; 垃圾箱   :archive  "Archive")                       ; 归档

多账号就是一个列表： (账号1 账号2 ...)。

为了让 mu4e 支持多账号，需要写一个函数自动生成 context。

(defun my/email--make-context (account)  (make-mu4e-context   :name (plist-get account :name)   :match-func (lambda (msg) (string-prefix-p "/CUNY" (mu4e-message-field msg :maildir)))   :vars `((user-mail-address . ,(plist-get account :email))         (mu4e-sent-folder . "/CUNY/Sent")           (mu4e-drafts-folder . "/CUNY/Drafts")     ...)))

mu4e 很大，建议用 with-eval-after-load 延迟配置：

(with-eval-after-load 'mu4e  (setq mu4e-maildir "~/Mail")  (setq mu4e-get-mail-command "mbsync -a"))

也可以使用 --read-envelope-from 让 msmtp 自动从邮件头的 From: 字段选择正确的账号发送：

(setq sendmail-program "/usr/bin/msmtp")(setq message-send-mail-function 'message-send-mail-with-sendmail)(setq message-sendmail-extra-arguments '("--read-envelope-from"))

想法在乙巳临月迭代

2026-01-01T04:58:00.000Z

开始下雪了。一年也要过去了，不知道大家的 2025 年如何呢？

这次的网站和月刊结构也做了一点更新，见博客更新记录。

本期导读

乙巳想法复盘

2025-12-30T17:29:41.000Z

Steph Ango 每年年底都会问自己 40 道问题。我认为颇有回答意义，有时候就是需要这样的东西来自省。

1. 你今年做了哪些之前从未做过的事？

今年我开始写月刊了。我认为这是信息整合的同时，也表达了我对部分信息的看法。这些信息多数来自于 Hacker News，少数来自我订阅的博客。不过我明明可以更多记录我对后者的想法，下个月开始我就这么做吧！

至于线下的话，我注册了个公司、做小破项目，希望可以加油吧。

2. 你有没有遵守年初时和自己许下的约定？

我年初的时候没有给自己许下任何承诺。

3. 你身边有人生孩子了吗？

虽然没有谁生小孩了，不过大我一岁的表姐今年刚结婚没多久便怀孕了，让人意外。

4. 你身边有人去世了吗？

远在故乡的大堂舅因病去世了，享年仅 60 岁。

5. 你去了哪些城市/州/国家？

哪里也没有去，我只是又在纽约待了一年。

6. 明年你想要获得哪些你今年没有的东西？

我想要独立思考、自制和时间管理的能力。

7. 今年的哪个或哪些日子会铭刻在你的记忆中，为什么？

今年并没有这样的日子。我如果不是开始写日记了，否则会忘记很多事情。

8. 你今年最大的成就是什么？

同时有三份工作？

9. 你今年最大的失败是什么？

有三份工作的同时还是一个全职学生。

10. 你今年还遇到过哪些困难？

同时兼顾学业、工作和乱七八糟的东西，难免出现时间管理不好的问题。我有时候还要和项目管理、教授、老板掐架，真是麻烦！

11. 你今年是否生过病或受过伤？

~~今年没怎么生过病，我貌似就不是多病体质。~~ 但说到受伤，自从开始打工了，三天两头都会不小心伤到自己。

好的当我没说，我在 12 月底生了场大病。拖着身体去上班，第二天还要被老板训，淦！

12. 你今年买过的最好的东西是什么？

500 美元左右搭建的新电脑。大一用 150 美元搭建的电脑内存和 CPU 实在是不够用，只能用来玩游戏。新电脑换上了 32GB 内存，达到了可以用 JetBrains 全家桶的标准！

13. 谁的行为值得去表扬？

没有人。

14. 谁的行为令你感到震惊？

没有人。

15. 你大部分的钱都花到哪里去了？

我大部分的钱都用在线上购物上了。因为范围很广，从家具到厕纸，所以无法具体得知到底花在什么东西上最多。

16. 有什么事让你感到超级、超级、超级兴奋？

我装了新电脑。有了新的 CPU 和内存后，可以流畅做的事情变多了。

17. 哪首歌会永远让你想起这一年？

我不太清楚，或许是台湾摇滚乐这一类吧，今年听的尤其多。

18. 与去年的这个时候相比，你是：感到更快乐还是更悲伤了？变得更瘦还是更胖了？变得更富还是更穷了？

过去两年我已经很悲伤了，所以今年算是变得快乐些。

瘦或者胖，貌似我的体重十年里都没有什么变化，样貌也是。

钱包的话，肯定是变厚了，但是也没有变很多。

19. 你希望自己能做得更多的是什么？

开发更多的小工具。至少把自己手头上的一个项目做到「可用」吧，不要再挖坑了。

20. 你希望自己能做得更少的是什么？

少刷以算法为主的平台，比如小红书和哔哩哔哩（特指短视频功能）。每次一刷就是一个小时过去，烦死了。

21. 你是如何度过节假日的？

我几乎不过。就算过，也是和室友买菜吃点好的，偶尔出去吃。

不过今年有点意外，打工的店居然有聚餐，实在是有点讨厌。这次的圣诞节应该是我人生中第一次送别人礼物，虽然是半强迫的，并且别人也会给我礼物，但还是喜欢不起来。

22. 你今年坠入爱河了吗？

没有。

我这些年都有在思考，我需要恋爱吗？

我的结论是，我想从恋爱中获得的东西，实际上从友谊上也可以得到：关怀、陪伴、理解、爱…… 除了性。

而我是最不需要性的那种人。

只是要获得这些让人幸福的东西，无论是和谁、什么人都非常难，所以要努力。

23. 你是否有讨厌某个你去年此时不觉得讨厌的人呢？

有，一些朋友让我觉得愈来愈不舒服。我认为这是因为我和他们已经过了一个阶段，新的阶段下我们的相性会不如过去的要高。

不知道是因为忙碌而导致的耐性降低，许多人的行为都让我觉得不可理喻，我今年没少拉黑熟人：「我跟你们也没有熟到那种程度吧！」有时候就会这么想。

24. 你最喜欢的电视节目是什么？

我不看电视节目。

如果非要说任何视频的话，其实也没有。

25. 你读过最好的一本书是什么？

《不原谅也没关系》，算是解答了我多年的各种疑惑吧，也给了我新的视角去理解一些事情。

26. 你今年发现的最好听的一首歌是什么？

Ginger Root 的 Loretta。

27. 你今年看过最喜欢的一部电影是什么？

今年看的电影不多，最喜欢的应该是《南京照相馆》。我认为拍的很有意思，尤其是对日本兵的刻画。

28. 你今年吃过最好吃的一顿饭是什么？

不好说是哪一顿呢。最让我心心念念的肯定是烩面了，因为我是碳水大王。

29. 有什么是你想要且得到了的？

和家人的关系缓和了许多，家里也多了只小猫，不过我还是不怎么想要回家。

30. 有什么是你想要却没有得到的？

让那个人永远离开我的生活吧。仅是让我知道在未来还能听到这个人的事情就够让我想要离开这个世界了。

31. 你生日那天做了什么？

我没做什么特殊的事情。

前两年的生日发生了一些不愉快的事情，以至于差点对生日有 PTSD 了。

32. 有什么还未发生的事，如果发生了，会让你的这一年变得无比满足？

那个人的消失。

33. 你会如何描述你今年的个人时尚风格？

自高四开始（美国高中有四年）我的时尚风格就在「衬衫 + 西装裤 + 毛衣」这个固定搭配没变过了。

有些人老问我为什么穿这样奇奇怪怪的样子、为什么不穿卫衣，反倒是让我觉得有点震惊：你要那么穿无所谓啦，但是只知道卫衣的话，不要怪我说你没有衣品哦！

不过我今年年底解锁了「毛衣 + 高领衫」的穿法。

34. 是什么让你保持理智？

好面子。

35. 你最欣赏哪个名人 / 公众人物？

没有！我和他们都不熟。

36. 哪个政治问题最令你有感而发？

平日能想到很多，现在真要我说一个出来，反而说不出来。

37. 你想念哪些人？

我今年没有想念过任何人。

38. 在你新认识的人之中，谁是最好的？

我今年新认识的人里，居然都是打工伙计。但是我们交谈不够深入，我很难说谁谁谁是最好的。

39. 今年你学到了什么宝贵的人生经验？

我忘了在哪里看到的了，总之是一句谚语，意思是「学习新的事物的时候要像一个婴儿，把过去自己学过的其他东西都忘掉」。

有时候可能会因为自己在某个领域里略有手脚，反而导致在一个新的领域内无法接受自己吃瘪。这样的心态一旦长久、对自己就很不利。

40. 能够总结你这一年的一句话是什么？

我没有变好，但至少开始看清自己在消耗什么的时间。

中文网络写作上的规则习惯

2025-12-29T17:41:51.000Z

我一直在思考，什么时候应该使用粗体、什么时候应该使用斜体…… 以下是我的看法，相当于抛砖引玉。

强调

之前我提到过，我给博客的粗体效果添加了点状线，让它看上去更加突出。后面我还是将粗体改回了最开始的仅 fontWeight 样式。一是有读者提醒我粗体太显眼可能会导致其他读者只读了粗体的内容，但无视了其他内容；二是我自个儿也觉得这个粗体太碍眼。

我以前通常会在这些情况下使用粗体：

强调语气，通常是一个句子里的一部分文字变粗体
强调我觉得有意思的内容
强调总结

如果是后两者的话，添加点状下划线感觉也不错。但是一篇文章里出现太多总结或者我觉得有意思的句子，该怎么办呢？实在是无法让读者好好阅读非粗体的内容。也就是说，粗体也分级别。我感觉出来的级别划分如下：

总结了整篇文章的，可以使用粗体和点状下划线
总结了一个要点或者一个自然段的，只使用粗体
有意思的内容，使用其他样式

关于其他样式，我还在摸索中。不过有读者向我推荐了 text-emphasis，让人眼前一亮。

经过一些自问自答后，我认为读者们看到粗体，第一时间想到的是「如果这里不看，后面会出问题」。也就是说，粗体是信息结构的一部分，而非装饰。这和我上述提到的「强调总结」一致。重要的是，粗体是可以改变读者的阅读路径的，因为它实在是太突出太突出了。人们看文章的第一眼，其实就会发现粗体、并且阅读它。

而着重号（也就是 text-emphasis 可以达成的效果，两者不是同个东西。以下依旧简称着重号）不会改变读者的阅读路径。只有在读者看到这一段的时候，读者才会发现着重号。它可以用来做我先前提到的两个事情：「强调语气」和「强调我觉得有意思的内容」。用法可以很多样：反讽、微妙的强调、我觉得这个点很妙、需要读者慢下来体会的一小段词……

还有两个可以用于强调的样式：下划线和斜体。下划线我几乎不使用，不过斜体我很常用。除了处理需要括起来的英文（比如书名），我也会用于异化语气。

作为例子：

当我排查这个问题的时候，其实一开始完全没往 Hexo 的标签实现上想。我以为是 Markdown 渲染器在处理 HTML 时出了 bug，直到我把生成的内容原样打印出来，才发现真正的问题点。Hexo 在渲染标签时返回的是多行字符串，而 Markdown 在解析时会把这些行首的空白当成缩进，从而直接识别为代码块。

这也就解释了为什么页面最后会出现

...

这样的结构：只要返回的不是一行 HTML，就一定会触发这个行为。

更微妙的是，这个问题并不是每次都会暴露出来。如果你生成的标签内容本身比较短，看起来就像是正常输出；但一旦 HTML 稍微复杂一点，被拆成了多行，问题就立刻出现了。这里的「多行」并不是一个实现细节，而是整个渲染流程里最容易被忽略、却又最致命的条件。

所以后来我干脆换了一个思路：不去试图「修复」Markdown 的解析逻辑，而是接受它的规则，反过来约束自己生成的 HTML 结构。从结果来看，这个策略反而简单得多，也稳定得多。

关于我先前提到的分级，整套系统我觉得没有什么问题，不过没有详细解释粗体的密度。我想了这么一个规则：

文章里的粗体是有限资源。对于小于一千字的短文，不要使用超过 5-7 次粗体；对于长文，每 3-5 个自然段，最多 1 处粗体。
如果读者只看粗体，他能不能复述你的结论？如果不能，不要使用粗体；如果能，那用得好。

换行

不过呢，还有一个有意思的东西可以用于强调 —— 换行。

在中文网络写作中，换行的强调力会小于粗体，但是大于其他样式。拆段是一件很重要的事情。通常读者对段落长度的容忍度是这样的：

2-4 行：舒服
5-6 行：还能接受
7 行以上：开始跳读

提出这一点的原因是，这些都是为了可读性，那么就要从读者的视角出发。段落是组成文章的重要元素之一，不在这上面花功夫怎么行呢？

通常来说，会建议在一个自然段内只推进一个信息点。不过我认为没必要这么极端，推进两三个信息点也没有关系，取决于这个信息点的内容。

离开纽约市的一天

2025-12-29T14:35:15.000Z

我的坏习惯是记录下来的事情不会第一时间加工成文章发布。这件事是 5 号发生的，我于 19 号开始起草、29 号才发布……

室友去考 EA 证的第一场考试。我跟她一起去，相当于一个陪同。

考场在新泽西一个小地方里，地方实在不大。建筑物使用的是一种很老式的电梯：门还没完全关上就开始下降，按钮少得可怜，也没有显示楼层的屏幕。整条走廊很窄，除了考场就是辅导班，看起来不像考试中心，更像是临时拼出来的空间。

很诡异啊。

等待期间我无聊得很，幸好带了日语作业和 iPad。上个月的日语作业我全部忘记做了。

iPad 本来是用来读书的。我最近在读《无可羡慕：朝鲜人的普通生活》，整体感觉像是小说，反而很适合这种等人的场合。书中记录的生活细节，让我第一次对那个过去几乎完全陌生的国家和其中的人有了一点具体的印象。

不远处坐着一个男人，手机一直在响不同的铃声。我起初以为他是在故意放铃声玩，可能是提神吧，哈哈。结果过了几分钟他接了电话，说「不要再给我打电话了」。

居然是真的电话啊……

既然是在考场，倒是不要放任电话响这么久吧！

我在等待区坐了个几小时，有工作人员过来告诉我，作为陪同不能在等待区逗留，让我去电梯旁边的长椅那边待着去。好吧，也没什么区别，都是坐着读书。

又等了一段时间，室友终于出来了。果不其然，她通过了考试 —— 她第一次做模拟考试的时候，其实就已经考到了及格线啦。

人一出来，这一天才算真正往前走了一点。

新泽西整个州给我的感受就是：没想到纽约市这么令我诟病的公共交通系统，在美国里已经算是佼佼者了。

新泽西的公共交通系统可以说是莫名其妙，各个地方都毫无逻辑，App 界面甚至丑陋到让我抓狂。这个 App 也是蠢得要死，室友只是稍微将其退回了后台，它就把室友的账户登出了。我们上车后室友还需要手动在司机面前登录账号，白白浪费时间。

抛开软件不谈，公交车本身的问题也不少：车速极快，几乎没停稳就开门；人一上车立刻关门继续狂奔；没有 Tap 系统，必须提前买实体票，或者在 App 里处理好一切。

从纽约坐车去新泽西，通常要经过大巴终端。路线、购票、对应的 gate 都需要自己提前确认，不然现场很容易手忙脚乱。第一次用 NJ Transit 的话，更是很容易被它的设计绕晕。

回程时发现公交还要等一会儿，我们就先去了附近的麦当劳，买了个鸡块套餐。天已经完全黑了，店里却依旧人不少。

这家麦当劳的饮料是无限续杯，反而让我有点意外。可能只有纽约市这样的大城市，才会把这种事情一步步取消掉吧。刚来纽约的时候，我还记得有些区的麦当劳也是可以续杯的，后来一个个都消失了。

这个小镇的路很宽，车很多，但行人却很少。就连红绿灯也需要手动按键才会变灯。车站很老旧，大多只有一块不起眼的小牌子，晚上几乎看不见。我们在附近绕了好一会儿，才终于确认自己没有走错。

或许正是这些细碎又不太方便的地方，才让我真正意识到：我确实已经离开纽约市了吧。

观《疯狂动物城 2》

2025-12-27T19:59:48.000Z

上个月一直想看的《疯狂动物城 2》，最近终于有时间去和室友一起看了。和上次一样，我去的还是周二三场。毕竟才 10 块钱。

不想要被剧透的还是不要看了吧 —— 虽然话是这么说的，但如果你都不想被剧透了，还点进来做什么呢？

去家附近的影院之前，我和室友在美式中餐馆里快速吃了炒面和炒粉，期间还玩了 Neal 的 Absurd Trolley Problems（荒诞电车难题）游戏。她认为，在不认识任何人的情况下，一切都应当遵守「少数服从多数」的规矩，而人优先于任何非人或者非生命，并且交易是不可取的。如果绑在铁轨上的人是我的话，她会选择让其他人死。

因为对「少数服从多数」规矩的严格遵守，就算是第 9 关里那五个人是「自杀者」，她也会选择救下他们、杀死那一个不想死的人。

这次去的影院要比上次去的明显大不少。我们没有买爆米花和饮料，直接入了场。令人大跌眼镜的是，买的位置被别人坐去了。

本来想着去其他位置坐也行，避免冲突。但后来一想，首先我买的位置是整个影院里最好的位置，其次要是坐到了其他人买的位置怎么办？最后室友替我去沟通，让这群小孩回到了他们该在的位置。

因为晚来了十分钟，不需要看那又臭又长的广告，可以直接观看其他电影的预告片。我发现根据看的电影类型，播放的预告片类型也不同，这次没有任何恐怖电影的预告片，都是合家欢或者以动物为主角的电影。

我特别喜欢看这类「给儿童看的电影」，未来或许会去看《山羊巅峰》和主角特别可爱的《河狸变身计划》。

电影中

先说结论，我认为这部电影一路看下来没有什么很大的毛病。

里面穿插了许多让人会心一笑的桥段，例如对《料理鼠王》的致敬，甚至还有后期对《闪灵》的致敬 —— 你这个合家欢电影致敬它真的没问题吗！

动物们的模型依旧很可爱，尤其是狼：大鼻子、长长的嘴筒子，很多时候还会瞪个大眼睛，实在是太可爱了。片中有两个山羊警官，一直戴着个墨镜，特别骚气。

这次电影里也展示了第一部没有出现的动物，比方说在水里生活的动物，补充了「鱼类」在这个世界观里的定位 —— 拿去吃。

这种设定我会更喜欢《动物狂想曲》的，鱼类也是生命，但是他们的观念是「吃」这一行为不过是大自然的一部分。你吃了我，你也会被其他更大的生物吃，而更大的生物一旦死去，便是滋润了无数小生物的「鲸落」。

电影开头的「毛毛心理咨询」实在是太 America 了。我身边的人几乎都做过心理咨询，不过我自己没做过，我光是听他们描述的我就不想去。

通常来说，电影的剧情架构是这样的：

引入冲突
引入主线和新伙伴
线性推进主线
被背叛
解决主线问题
解决最初引入的冲突

第一部里，冲突是「社会对动物们所添加的标签」，旨在告诉观众「谁都可以成为任何人」。刻画该冲突的方式便是刻画朱迪作为一个警官有被多么忽视，以及尼克作为一只狐狸被包括朱迪在内的人投射刻板印象。其实说是冲突，更像是整个《疯狂动物城》系列的主题，只是第一部里着重刻画了它。

第二部的主题更复杂，原有主题依然存在，不过朱迪和尼克的关系也成为了一种冲突。

朱迪作为理想主义者，她可以为了自己的理想做任何事，为了刻画这一点，朱迪的行为变得更加鲁莽。尼克很关心朱迪，成为警官也是为了和朱迪在一起，但是他无法表达出这一点，可能是好面子。

我个人认为，他们中期吵架的那一部分做的不够好。

朱迪为了追盖瑞、毫不犹豫地跳入了水管内，差点窒息而亡，最后是尼克救了她。朱迪很不开心，认为这错失了追盖瑞的机会；尼克也很不开心，他只是想要朱迪好好的，为此他愿意和朱迪一起放弃身份、逃离动物城，在哪个角落里安安稳稳过日子。

问题在于，冲突应当是两个角色都做错了事情，才能在最后通过道歉达成和解。

我们可以具体拆一下：

朱迪的问题是：

行为鲁莽、不顾生命危险
被救后反而指责尼克
爬山时录音笔摔坏，选择回避情绪冲突
在旅店里只想取证据，不关心尼克的恐慌

尼克的问题则相对单一：

想要和朱迪在一起
不希望朱迪受伤
但始终没有表达自己的真实感受

这样一看，冲突明显不平衡。

然而在结尾，率先道歉的是尼克。

我很喜欢第一部的一幕是朱迪从老家回来找尼克，并且真诚地向尼克道歉。我原本期待，第二部里可以是朱迪更清除地意识到自己的问题，并主动迈出那一步。

用我在网络上看到的一句话是：

朱迪没有成长，尼克只是看开了。

当然，说是没有成长就有点夸大了。

然后便是续作几乎一定会出现的新主线和新伙伴。

第二部的主线是帮助盖瑞找回自己的家园，并且击溃林雪猁家族的阴谋。说实话，在美国看林雪猁家族的阴谋，实在是让人如坐针毡。这也太像美国人赶走印第安人和墨西哥人的历史了吧！理由也很简单，因为他们是领地动物，所以他们想要赶走其他动物，扩张自己的领地。

好吧，现实中那么多可悲的历史，理由说不定也是这么简单。

中间的线性推进主线我就不说了，基本上就是展示世界观。直接来看「背叛」。

第一部里朱迪被羊副市长背叛，颠覆了「食草动物是弱势」的刻板印象。观众和朱迪一样，被迫意识到「加害者与被害者」的区分并不来自物种，而来自权力、位置与选择。

食肉动物很强很可怕吗？但是他们在社会里很难做到一些事情。朱迪作为「弱势群体」警校毕业就能受到羊副市长的支持、来动物城工作，但是作为「强势群体」的尼克呢？他从来都没有选择。

第二部里，朱迪则被宝伯特背叛，此时的主题依然是「变成刻板印象里不一样的样子」，宝伯特的回应是「但我不想要和家人不一样」。

这个背叛和第一部的背叛有着本质上的差异：它没有颠覆任何主题层面的既有认知，它只是角色立场的转向。我们知道了宝伯特为什么会这么做，但是没有迫使我们重新思考「我们原先相信的是否是错的」。这也使得这一段情节在情感和思想上的冲击力，明显弱于第一部。

我自己很不喜欢第二部里如何解决这些冲突的方式。

在朱迪和尼克解开心结后，整个故事突然开始以过山车般的方式一路冲向地底：先前作为傀儡的马飞扬突然决定不再听从林雪猁家族；宝伯特越来越疯狂，却又被轻易击败；盖瑞找到了专利证明，林雪猁家族锒铛入狱。

一切结束得太快了。

电影的结尾出现了羽毛的彩蛋，貌似第三部会出现鸟类动物。

结束后，室友跟我说的第一句话是，「感觉怪怪的，没有第一部那么惊艳。」

我认为电影续作确实很难达到首作的高度。因为首作是围绕着主题所展开的，而续作要操心更多事情：让旧角色登场、维持系列主题、引入新故事、制造新冲突……

我认为创作里，第一条是最不重要的。但电影依然做了这一点，让许多角色回归，虽然观感很差，但也照顾到了这些角色的粉丝们。

电影后

我和室友看了许多解析视频，来了解我们心中的不快。

其中我认为做的最好的是这个视频：为何尼克绝不该只为爱情而生？为何马市长是 2 最大遗憾？深度解析疯狂动物城系列！视频里很棒地解释了为什么第一部那么出彩：它讨论的并不只是「有没有歧视」，而是 谁被定义为弱势，以及这种定义是如何运作的 —— 食草动物与食肉动物、看得见的冲突与看不见的身份红利。

第一部真正厉害的地方，并不只是展示了朱迪作为「食草动物」视角下的动物城歧视，还同时给出了尼克作为「食肉动物」所承受的另一套歧视逻辑。这两种视角并不是简单的对立，而是相互错位的：朱迪从小被当作弱势的一方被忽视、被低估，于是她理所当然地认为「食草动物就是弱势群体」；而尼克看起来体格更大、更具威胁性，却在制度和信任层面被系统性地排除在外。

这也使得朱迪这个角色变得更加复杂。她确实遭遇过歧视，但她同样明显拥有身份红利：她是食草动物、是警察、是体制内的「成功案例」。而她对这种红利几乎是完全无意识的 —— 直到那场发布会的发言伤害了尼克，她才第一次意识到，自己口中「理所当然的判断」，在尼克那里意味着什么。

第一部里那些体格庞大的食肉动物，正是在这里显露出他们的脆弱：在权力结构面前，体型、力量、凶猛都毫无意义，他们只是另一种层面下的弱势群体。也正是因为这种多层次、交错的弱势描写，第一部的主题才显得如此扎实。

相比之下，第二部虽然引入了爬行动物作为新的伙伴，却给到他们的篇幅实在太少，少到我在回想剧情时，甚至会暂时忘记他们的存在。这一点让我觉得有些可惜。

Claire 也在视频中提到了一些她认为遗憾的地方：很多原本可以继续深挖的议题，最后都只是轻轻擦过，没有再往前走一步。

最后便是关于朱迪和尼克之间的关系。

我认为他们有着亲密关系，但这不一定是爱情，因为亲密关系本身就不等同于爱情。

这个命题也是我现实生活中一直在探讨的：我可以有一个生命中最亲密最重要的人，但我们之间没有爱情，我们有的只是陪伴和理解彼此。

我渴望拥有这样的关系，但是这很难。

当 True 并不是 True

2025-12-25T15:32:25.000Z

某天我阅读了《Not Bad 的架构：解码虚空的中文源代码》，原本想要放入月刊内，结果发现自己写的越来越多，已经到了「不独立发个文章都对不起自己」的地步。

文章的大致内容

在深入讨论之前，为了照顾没有阅读过作者 Suggger 原文的读者，我先快速梳理一下他的核心观点。

Suggger 的思考始于一个细微的翻译卡顿：他发现中文在表达「肯定」时，往往不喜欢直接说 True（是），而是更倾向于双重否定的 !False（非假）。

这是他举出的例子：

没错 = Not wrong = Right
不差 = Not bad = Decent
还行 = Still passable = Okay
没事 = No problem = Fine

Suggger 将这种现象总结为「无」的语言哲学。

他认为，相较于英文那种直接、明确、必须承担立场的分类思维，中文的这种负向肯定构建了一种灰度思维：它旨在避免直接承担责任，保留解释空间，并让态度始终保持模糊与可撤回性。

简而言之，他认为英语是在给世界打标签，而中文是在测算风险与留白。

我的看法

我看完这个文章后第一时间想到的是日语。

如果非要试图通过语言结构来窥探思维方式，我认为日语才是那个最极致的样本，因为他们的多重否认在这个世界上是相当独特的。

让我们先看几个例子。假设我们要表达「义务」的话，这三个语言是这么表达的：

中文：必须
英文：Must / Have to
日语：しなければならない —— 直译就是「如果不做的话，不行」。

很明显，日语用的是一个结构性的双重否定，用来表达最强烈的「肯定」含义。

甚至在表达「只有」的时候：

中文：我只有一个苹果
英文：I have only one apple
日语：りんごは一ひとつしかない —— 除了一个苹果之外，没有别的了

在日常社交中，这种倾向更明显。比如邀请：

中文：你想去吗？
英文：Do you want to go?
日语：行いきませんか？ —— 你不去吗？

或者是拒绝：日本人想要拒绝时，他们几乎不会说「不」的，他们会说「それはちょっと……」或者简单点「ちょっと……」。直译是「那个有点……」。句尾甚至直接省略了否定词，只留下一个悬而未决的语气。

当然，我这里话没有说那么死。这是因为虽然日语表达「必须」的核心语法结构确实是双重否定，但现代日语（尤其是口语）确实发生了变化，而且存在其他的表达方式。

哪怕是现在最懒、最年轻的日本人，在口语里表达「必须」时，通常会说：

しなきゃ
しないと
しなくちゃ

但是！即使是这些缩略语，它们的词源依然是双重否定，即「不这么做的话不行」：

しなきゃ = しなければならない
しないと = しないといけない

那么是否存在肯定形式呢？自然是有的，只是语感不太一样：

するべき = 应该做（更多带有一种道德判断或强烈建议，而不是客观的「必须」）
必要ひつようがある = 有做某事的必要（名词性的陈述）

那么，我列举了这么多日语的例子，是为了证明「语言结构决定思维」吗？

弱萨丕尔・沃尔夫假说认为，语言结构强关联思维方式。这在学术上是有意义的，比如语言会影响我们对颜色的感知或对方位的描述。

但 Suggger 的错误在于，他将这种「影响」无限放大成了「决定」。他试图证明：因为你的语言里全是「否定」，所以你的骨子里就是「逃避」。如果这种理论成立，即语言结构决定逃避责任，那日本人应该是世界上最爱「推卸责任」的民族？这显然过于简化了。日本社会以极度严苛的责任感和耻感文化著称。这里的「否定结构」并不是为了逃避责任，而是一种社会性的谦逊。

日本文化中有一个核心概念叫配虑はいりょ，即时时刻刻照顾对方的感受。直接的断言在日本社会往往被视为一种攻击或对他人的冒犯。因此，他们使用否定句式，不是为了像 Suggger 说的那样给自己留后路，而是为了降低自我的姿态，给对方留出面子和余地。

这就引出了那个鸡生蛋的问题：是语言的源代码决定了思维，还是文化的运行逻辑重塑了语言？现实更可能是后者：文化的运行逻辑重塑了语言。日本的高语境、耻感文化需要一种不那么尖锐的语言工具来维持社会润滑，因此「多重否定」才演变成了一种语法规则。

理清了「文化重塑语言」，我们再来看中文，就会发现 Suggger 所谓的「中文否定肯定」和日语的「语法否定」本质完全不同。

日语的多重否定往往是语法层面的刚需。在表达「必须」、「只有」等基础概念时，日本人的选择并不多，语法结构几乎是强制他们调用「不…… 不行」或「不…… 没有」的模块。

但 中文的「否定肯定」是词汇层面的选择。当我们说「没错」或「还行」时，更多是出于一种松弛的口语习惯或社交修辞。我们完全拥有选择权，随时可以说「对的对的」、「正确的」、「确实」。我们的操作系统并没有禁止我们输出 True，只是我们在特定语境下选择了更温和的表达。

这里就必须提到语用学。简单来说，语用学研究的是「在特定情境下这话是什么意思」。如果一个人在屋里说「这有点冷」，他的句法是在陈述温度事实，但他的语用意图通常是「请把窗户关上」。如果按照 Suggger 的逻辑，这个人就是在「逃避直接下达关窗指令的责任」？不，这只是人类社会通用的社交礼仪。

同样的道理，如果不考虑文化语境，单纯看语法，我们再回头看看 Suggger 眼中那个「直球、裸露、高效」的英语世界。他认为英文的肯定是分类、非黑即白的。这个观点忽略了英语中非常重要的修辞手法 ——Litotes（反语 / 低调陈述）。

英语也不是永远都在直球地进行属性赋值。它同样在大量使用「负向肯定」：

I wouldn't say no = Yes, please
I don't disagree = I agree
It was no small feat = It was a huge achievement
Can't complain = Everything is good

再用「不错」这个例子来说，Suggger 认为这是「避免承诺完美」。但在英语母语者的语境里（特别是英国人），当他们看着一份很棒的报告说 Not bad at all 时，这也往往是极高的赞赏，等同于 Very good。

这里的逻辑并不是「我在逃避给它打满分的责任」，而是「我通过压低预期的表达，来显得更客观或更谦虚」。

因为过度的赞美往往听起来像廉价的恭维，而克制的 Not bad 则暗示了说话者拥有极高的标准 —— 这意味着你的作品经受住了挑剔眼光的审视。这种「否定之否定」剔除了情绪化的泡沫，反而让赞美显得更加诚恳且更有分量。

更有趣的是，他声称英语强迫人们「公开立场」，但这恰恰忽略了英语语法中的主体消除。当一个美国政客想要逃避责任时，他不需要像中国人那样用「原则上」这种模糊词，他只需要使用被动语态：Mistakes were made（错误已被铸成）。注意到了吗？在这个句子里，「错误」发生了，但「犯错的人」在语法层面上被直接删除了。这难道不是英语的「虚空」吗？

所以，如果因为中文里有「不错」，就认为中国人缺乏担当，那我也可以因为英文里有 I wouldn't say no，而论证讲英语的人都是一群首鼠两端之徒。这显然是荒谬的。

这种语言宿命论在流行文化中很受欢迎，因为它提供了一种廉价的深刻 —— 似乎只要破解了语法，就能看透一个民族的灵魂。Suggger 在文章中使用了编程逻辑：中文是 !False，英文是 True。这种极客式的比喻很容易让人产生「洞察了本质」的错觉。但看看上面那些日本人和英国人的例子，语言真的是冰冷的二进制代码吗？显然不是，语言是流动的博弈。

因此，无论是日语中不得不用的语法规则，还是中文里为了社交润滑的修辞选择，如果仅仅因为它们都带有「否定」成分，就将其统一解读为「避险心机」，会忽略语言演变的历史脉络，以及使用者在具体语境中的能动性。

这类理论之所以迷人，我认为这是因为它提供了一个简单化的诱惑：分析几个单词语法来解码整个庞大文明的底层逻辑。但是像我先前说的那样，语言不是冰冷的代码，是人类为了在复杂社会中生存而打磨出的工具。真正的洞察不应该止步于语法的表象，而应该去接触那些隐藏在单词背后、更为深沉的文化脉搏。

说到底，复杂的文化心理怎么可能塞得进去那小小的二进制框架呢？

观《玩具熊的五夜后宫 2》

2025-12-23T17:02:31.000Z

前段时间和朋友一起去看《玩具熊的五夜后宫 2》电影（以下简称 FNAF2 电影）。本来打算自己一个人去的，看她在家里无所事事的，干脆抓过来和我一起观赏电影。

不想要被剧透的还是不要看了吧 —— 虽然话是这么说的，但如果你都不想被剧透了，还点进来做什么呢？

我们去的我校附近的一家 AMC 影院。AMC 好便宜啊，周二周三电影票都半价，有些早上的时间段还额外打个八折或者七五折。不看 IMAX 或者 Dolby 的话，一个人才 10 块钱。

去年还是前年的时候，AMC 忽然送了我一年 Premium 会员。不知道是什么意思，怀疑是生意不好做，我也查不到我这个会员的有效截止期是什么时候。总之除了攒积分快点，我还可以买中号爆米花跟饮料，然后免费升级到大号（虽然两者的区别只有 1 块钱……）。

朋友买了爆米花和饮料，总计 18 块钱。可以免费续，不过没有那个必要，实在是吃不动那么多，一场电影下来爆米花还剩差不多三分之一。饮料倒是喝得很快。她调了个桃子柠檬味雪碧，也就是一点点桃子味雪碧，剩下全部接普通雪碧。味道意外地不错。

我们提前半小时入场，也看了半小时的广告。该说不说，这些广告很「优质」，至少成功地让我出于好奇、扫了一个二维码。不过让我想到了前段时间接收到的一个观点：很多时候花了钱更容易看到这些「优质」的广告。

半小时过后，大荧幕终于开始播放其他电影的预告片 —— 基本上都是那种经典得不得了的外国恐怖 / 血腥片，光是看了预告片就知道实质内容会是什么。

电影中

说回 FNAF2 电影本身，我看完后第一感想是「这是喜剧片吗？」

首先它作为一部恐怖片严重失格，所谓的「恐怖」都是靠堆跳杀来实现。堆的实在是太多了，还很刻意，根本不会让人觉得害怕，只会觉得无趣、重复。

那它作为粉丝向的作品合格吗？

我确实很喜欢电影里面的彩蛋，例如 Mike 吐槽 2 代披萨店的保安室居然没有门。还有开头展示 2 代披萨店时，展示到街机区的时候貌似看到了 Candy 猫的小彩蛋，不知道是不是看错了？不过呢有些地方我觉得可以做得更好，比如老 Foxy 居然不是被闪走的。

Vanessa 和 Mike 前期的约会剧情我挺喜欢的，以及 Vanessa 的梦境剧情。

为了体现出 Vanessa 渴望脱离 William 带给自己的阴影，我认为制作组在这方面上很是用心：成人的 Vanessa 看着走廊尽头的 William，勉强地大喊「我不再怕你了」。William 冲来时她又逃到出口恐慌地拍门、想要离开。下一幕 Vanessa 变成了小孩的样子，逃窜到父亲的工作室。在那里，她找到了 Baby，可能是想要补充游戏世界里 Elizabeth 的设定？总之，电影里的 Vanessa 变成了保安的样子后枪杀了 William，但是倒在地上的 William 依然喊着「你永远都会是我的」。

我认为这一幕很棒地表现出了 William 在 Vanessa 的眼里是多么可怕的存在，就算死了也会一直作为阴影存在。

说完了优点，来说缺点。电影里那种经典的「不好好说话」剧情到处都是，以至于我都不乐意一个个挑出来说 —— 太多了！自然，影视作品一定要有这样的桥段来营造冲突，但我认为可以有更聪明的方式，至少不要每个冲突点都让我觉得过分刻意吧！

电影世界在剧情设定上，对游戏原著的魔改程度大得惊人，甚至到了令人困惑的地步。

事先说明一下游戏里的主要角色：

William 是主要的反派，他创造了玩偶，并且杀害了多个小孩，也包括自己的女儿 Elizabeth。
- Michael 是 William 的大儿子，也是 FNAF 系列的主角，许多作品里玩家所扮演的就是他。
  他想要弥补父亲造成的一切、找回妹妹。不过在《姐妹地点》里，他被混合意识体 Ennard 欺骗、挖空了身体、当做 Ennard 出门伪装用的皮囊。最后因为身体腐烂，Ennard 不得不放弃他，而他居然也没有死，实在是打不死的小强啊。
- Elizabeth 被 William 所做的 Baby 玩偶意外杀死。
- William 还有个小儿子，不过他的名字从来都没有被提起过，只知道他是 83 之咬的受害者。
Henry 是 William 的商业伙伴。
- Charlotte 是 Henry 的女儿，也是 William 的第一名受害者。死后附身了 Marionette（Puppet，也叫傀儡）。
Vanessa 就比较特殊了。她是到《安全漏洞》才出现的新角色，这时候 FNAF 游戏已经不再是过去那样的「保安电竞游戏」。正因如此，我对她并不熟悉。

我因为第 1 部电影而分不清 Vanessa 和 Elizabeth。电影世界里，William 的女儿从 Elizabeth 变成了 Vanessa。主角是 Mike，他的弟弟曾经被 William 拐走杀害，因此留下阴影。

我在 FNAF 小说推出后就没有再怎么关注这个系列了。Vanessa 到底是谁？是 Elizabeth？但是 Elizabeth 不是已经被 Baby 杀了吗？

直到我出了影院搜了一下，才得知游戏世界里的 Vanessa 和 Elizabeth 一点关系都没有。电影世界里其实是将 Michael 的角色位置给了 Vanessa，因为要给 Mike 凑 CP 吗？然后 Elizabeth 的位置给了 Michael，也就是想要和 William 一样杀人的位置。Elizabeth 在电影里查无此人。太乱了。

Michael 因为站在游戏世界里 Elizabeth 的角色位置，所以在电影世界里他认同了 William、变成了反派，刻意释放出 Charlotte 要大杀四方。

这里我忘了为什么 Michael 可以操控 2 代玩偶，不应该是 Charlotte 操控它们吗？我也没有看到 Michael 和 Charlotte 合谋的场面，只有开头 Michael 放出 Charlotte 的场合，但那个时候 Michael 还很怕 Charlotte 会弄死自己。

Charlotte 虽然为了救小男孩而被 William 杀死，但是她并不觉得这是 William 的问题，有错的是当时不愿意帮助她的大人。此处的逻辑我认为是为了让角色变成反派而设计的，就像为什么 1 代玩偶会想要弄死 Abby 一样。说实话很刻意，我不喜欢。

这个片快结尾的时候实在是欢乐得不行：谁想出来的 1 代玩偶痛扁 2 代玩偶的情节的？差点以为回到了十年前看 YouTube 上那些不同版本的玩偶大战、比战力的时候。尤其是制作组很刻意地将这一段设计的非常滑稽 ——Toy Bonnie 的脸被一脚踩烂，眼珠子可笑地漏了出来。我当时看的时候一直在憋笑……

看到 Mike 拿出音乐盒驱散了 Charlotte 时，我觉得应该就这么结束了吧，谁曾想 Mike 直接把音乐盒停了，然后和 Vanessa 大吵一架。这一段吵架戏感觉莫名其妙的，像是为了吵架而吵架一样。Vanessa 绝望的时候，Charlotte 突然出现并俯身了她，全片完……

只是觉得颇为儿戏，这样的设计。

当时灯光亮起，很意外地播放了 It's Been Too Long 这首歌。身后的人起来要走，抱怨了一句「明明电影拍到这儿就行了」。

电影刚开始的时候，提到结尾有彩蛋，因此我和朋友等到了整部电影结束。结尾的彩蛋有两个：William，或者说 SpringTrap 苏醒了过来，暗示着第 3 部电影；Henry 给 Mike 发了个语音提醒？具体说了什么其实我都不记得了，类似于那种「你要小心一个人」，然后在报名之前就被不明生物杀害。

我自己是觉得，这些桥段实在是太经典了。估计第三部电影里，Vanessa 会被其他人嘴炮醒来、和 Charlotte 斗争…… 不过我也不清楚，因为 Mike 明显有救世主情节，想要去「修复」Vanessa，这样的态度让 Vanessa 以及我都感到很生气，所以我大胆猜测一下，也有可能 Vanessa 会治愈自己？总之，我想要看一些不是那么典型的桥段。

电影后

我和朋友商量着去附近新开的蜜雪冰城。过去一看果不其然，排满了长队。没有办法，价格实在是太便宜了，熊猫外卖上的预售套餐有两个饮品，居然只要 4 美元左右。就算加上平台费、运送费和小费，价格也比附近的奶茶品牌便宜很多很多。

没办法，我们只能到处走走、吐槽这部电影。她觉得电影剧情实在是招人笑，许多情节她后来想想也会觉得可笑。

我也在手机上看到一些人对这部电影的看法：因为这是 FNAF 的电影，所以他们觉得就是好、不该骂。我认为这没必要。

作为 FNAF 系列（曾经的）粉丝，能看到玩偶们以真实的形态动起来很是惊喜，看到各个彩蛋的时候也很高兴。但是这部电影的剧情对我而言就是很不咋地，评价不可能只有黑或者只有白。再就是 喜欢这个系列，所以希望作品优秀不是很正常的事情吗？怎么能因为它是某某系列的作品，就无视了所有的缺点呢？

不过过了几天我再看这部电影的消息：居然在票房上打败了我还没看的《疯狂动物城 2》。朋友知道后气急败坏地说：「都怪你拉我来看这个，我们居然为这个片的票房贡献了宝贵的两票！」我听后实在是哭笑不得。

尝试去中心化和去 App 化

2025-12-23T02:18:18.000Z

如标题，我想要尝试慢慢地去中心化、去 App 化。

去中心化

我尝试了一下使用 PixelFed 和 Mastodon 来代替 Instagram 和推特（我依然拒绝叫它 X）。

PixelFed 给我整体的感觉是还未完善，可以发现整体设计有许多瑕疵。比如我最开始将自己的账户设置为私密账户，发的一些猫咪照片自然也是私密的，但是后续将账户放开、照片却无法再公开。

Mastodon 我在上个学期其实就有用过。

我校的日语部门和日本的信州大学有合作关系，有一些课需要让我们互相投递影像、彼此学习对方的语言。我不知道具体是哪一方搭建的服务器，但就是有人专门为此搭建了一个 Mastodon 服务器：学生创建自己的账户、在服务器内上传自己的视频，另一个学校的学生看到后就可以回复了。

你可以用这些链接关注我：

https://pxlmo.com/Cytrogen

值得注意的是，我加入的这个 PixelFed 服务器因为不明原因将我的账户 unlisted 了，也就是不开放。我发布的许多照片目前看不到，但是月刊内嵌入的可以看到。

暂且不知道什么时候会开放。

https://m.otter.homes/@Cytrogen

我最近看到许多博客站主使用 Telegram 发布短想法，然后抓取这些内容、生成一个索引网页供大家访问。其实 PixelFed 和 Mastodon 也可以做到这一点，甚至说更方便些。比方说 PixelFed 就可以直接生成一个自己账户的 feed 页面。

既然这些去中心化平台本就支持开放的 Feed 协议，与其让内容分散在各个站点，不如将它们收纳回自己的「主阵地」。于是我打算在这个博客网站里嵌入一个自己的照片和短想法合集。

我也考虑过重复性。现在的日记片段其实就有一点短想法合集的感觉。或许我可以全面迁移到 Mastodon，这也可以解决我先前提到的「外出时无法在博客里写日记」（见十一月二十九日）的问题：日记不需要再写在 Google Keep 内，直接在 Mastodon 里写好，然后要部署新的月刊时直接在构建时拉取这个月的 Mastodon 内容、自动添加到页面内。

我还在考虑在 PixelFed 和 Mastodon 上发什么类型的内容最好：

PixelFed 是专门发送图片的，如果我想要在博客网页上使用这个图片，是不是应该嵌入这个图片进来呢？因为我不想要在互联网上重复上传同一个图片。
Mastodon 和博客网站上的「日记片段」是否会有冲突？现在的「日记片段」有些是短想法，有些是日常分享，我认为可以分成两类。那么在 Mastodon 上应该写短想法还是日常分享？
这样一想又觉得，自己好像花在日常分享上的精力更多，那是不是自己的博客也可以分享日常？这样月刊的内容就不需要这么多这么长？

最后我的方案是，略微改动一下月刊内的「日记片段」板块。我决定尝试一个全新的写日记方式：

如果是很长的日记，例如一天的流水账、一些很长的想法，我会直接当做独立文章发布。
如果只是想着去写高质量的博客，月刊的「日记片段」会被我的分享欲压垮的。直接当做文章发布，然后让月刊做链接的工作就好。这样我的标准也会降低许多，写博客也不需要考虑什么质不质量、高不高大上了…… 明明是我的博客！
如果是短想法，我会发到 Mastodon 上，博客会自动抓取和嵌入这些嘟文。
这是因为 Mastodon 与「日记片段」的定位有些冲突。我认为既然博客是合集，Mastodon 就可以只做素材库。基于此，我会将嘟文嵌入到 details 块内，并以发布的时间排序，因此它们的前面一定会有时间。
如果是照片，我会发到 PixelFed 上。和 Mastodon 同样，博客也会自动嵌入这些照片、时间和 figcaption。
因为我不想要在互联网上重复留下冗余的脚印，所以嵌入的照片不会是自部署的。意味着如果我加入的 PixelFed 服务器崩了，这些照片也会裂。

实现

关于如何将这些内容嵌入 details 块，核心逻辑很简单：自动抓取并整合我在 Mastodon 和 PixelFed 上发布的特定标签的帖子，然后将它们按月和天组织成日记，并呈现在我的博客文章中。

主要由四个部分协同工作：

数据抓取
智能渲染
内容注入
样式表现

一听很唬人，实际上没有，我大概说说：

数据抓取是所有功能的起点。
当 Hexo 在构建一篇含有 {% diary_aggregator %} 标签的文章时，脚本会被触发、读取我在 _config.yml 中配置的 Mastodon 和 PixelFed 的服务器地址、用户 ID 和访问令牌（它们俩使用的是同一套 API）。
连接到这两个平台的 API 后，为了提高效率，脚本会通过 since_id 机制，只请求自上次成功抓取以来发布的新帖子。
抓取到帖子后，脚本会检查每个帖子是否包含特定的日记标签。只有带这些标签的帖子才会被视为有效的日记条目。
接着将这些新的、有效的日记条目，与一个位于 source/_data/.diary-cache.json 的缓存文件中的旧条目合并。
合并后，所有条目会根据日期重新排序并去重，然后回写到缓存文件中，确保数据是最新的、完整的。
这个步骤的核心职责是确保本地拥有所有日记条目的最新数据，它本身并不关心最终页面长什么样。
在更新完缓存后，diary_aggregator 脚本会立刻读取当前正在处理的文章的原始内容。
它会使用正则表达式查找所有我手动编写的日记占位符，例如 {% details 十二月十八日 diary_sections %}（我写了一个 details 标签，该标签会渲染
十二月十八日
）。
脚本会从这些占位符中提取出日期标题（如「十二月十八日」），并将它们记录在一个集合中。这个集合代表了「所有已经由我手动安排好的日期」。
接下来，脚本从缓存文件中读取当前月份的所有日记条目，并按天分组。然后它会进行一次对比：
- 如果某天的日记（比如「十二月十九日」）在缓存里存在，但在「手动日期集合」中不存在，脚本就认为这是一个「新」的、无人管理的日期。于是，它会为这一天自动生成一个完整、带内容的
  折叠区块。
- 如果某天的日记（比如「十二月十八日」）在缓存里存在，并且在「手动日期集合」中也存在，脚本就认为这个日期已经被我手动处理了，它就会跳过这个日期，不生成任何 HTML。
最后，{% diary_aggregator %} 标签只会输出那些无人管理的日期的
区块，或者在所有日期都已被手动管理的情况下输出一个空字符串。
不过那些被我手动创建的，还没有被处理，所以还需要写一个注入器。
在每篇文章即将被渲染成 HTML 之前（before_post_render 事件）运行。它只对 front-matter 中设置了 diary_month 的文章生效。
注入器会扫描文章内容，寻找 {% details ... diary_sections %} 这样的结构。对于每一个找到的占位符，它会提取出日期标题（例如「十二月十八日」），然后去 .diary-cache.json 缓存文件中查找属于这一天的所有日记条目。
接着将找到的条目格式化成 HTML（包括时间、文字内容、图片等），然后将这些 HTML 注入到 details 标签的内部。
最后，所有这些 HTML 元素如何显示，是由主题的样式文件决定的。

实现讲完了，大家想要复现的话，需要根据自己使用的框架来调整。因为我还在各种调整，就先不把代码放上来了。

总之，实际效果到这个月底大家就能看到啦（不过因为某些原因，可能有人已经看到了……）。虽然话是这么说的，但其实这些改动更多是只有我才能看到，因为实际效果和过去的「日记片段」区别并不大。

去 App 化

说完了「去中心化」，现在来说说「去 App 化」。因为这篇文章，我想要慢慢卸载手机里的一些 App、使用它们的网页版本。

我第一个下刀的就是 Instagram。我对这个 App 真是又爱又恨：我很喜欢它的 Story 功能，但是 App 内那群人给我带来的回忆实在是不欢快。当然，这个 App 本身也有很多问题。

只需要在浏览器内打开该产品的网页版，然后在菜单里选择「安装为 App」即可。以后在手机首页上点击对应的图标就可以打开使用。

接着我将推特、Facebook、Reddit、LinkedIn 等 App 都卸载，改用网页 App 了。有一些产品是必须使用 App 才行，例如 WhatsApp 这样依赖于手机系统底层的软件。

本来想着先用个几天看看情况，结果实施的当天就出现了一个问题：室友在 Instagram 上发了一个投票，我也想参与其中，结果网页 App 可以看到这个投票栏，点击后却会显示说「需要下载 App 才可以使用」。

更有甚者，移动端根本找不到网页 App，比如国内的许多产品 —— 凭什么！

PWA 一个特点是，通知没有那么简单发出来。我认为这是一个双刃剑：如果有急事找你，没有通知就会很麻烦，不过不想被通知轰炸的话，这又是一个好事。只是说，Instagram 和 Facebook 这样的产品本身就不是 IM 类 App，如果真有人很急找我，那还是乖乖给我发短信或者来电吧。

还有一个问题是，我发现我的手机如果关机了或者开启了省电模式，放在桌面上的 PWA 都会被清除，很可能是因为 Edge 浏览器被 kill 了。目前我还不知道有什么办法可以解决这个问题。

不过拜这所赐，我发现我的手机里根本不需要很多 App—— 每次桌面被清后，我会想要添加回来的才是那些对我来说重要的 App。

你缺这 2.75 美元吗

2025-12-21T17:17:00.000Z

这个月的某一天，我在查阅维基百科的时候，又一次看到他们要捐款。

心里想着这个网站也不容易，大家几乎都在用，并且也就 2.75 美元，还是给了吧。

实际上，并不是 2.75 美元，而是 3.10 美元。多给的 0.35 我忘了是什么东西的费用了。不过为了方便叙述，以下还是称为 2.75 美元。

总之要了钱后，它还问我可不可以每个月都捐款 1.75 美元。因为不是什么大数目，我觉得问题不大，便同意了。

早上起来脑子清醒了一点，想要知道其他人的看法。结果看到了这篇文章后，一下子便后悔了。实在是不能冲动消费啊！

首先，这笔钱并没有流向我想象中那个「苦哈哈、用爱发电」的小作坊。

收到捐款的是维基百科基金会。与许多人的直觉相反，这绝非一个濒临破产的组织，而是一个坐拥数亿美元资产、每年收入远超支出的庞大机构。

根据 Daily Dot 的报道，维基媒体基金会总资金约为 3 亿美元（截至 2023 年），并在 2023 年前 9 个月就筹集了 1.42 亿美元，远超任何历史年份。

它们并不缺我这几块钱来救命，甚至可以说，它们的现金流比绝大多数科技公司都要健康。

既然不缺钱，为什么还要表现得如此窘迫？

他们通过 A / B 测试发现，这种带有强烈危机感、暗示「不捐款明天就关服」的文案，配合巨大的、遮挡视线的 Banner，转化率最高。尤其是在每年年底的「筹款季」，通过制造焦虑来收割用户的善意，已经成为了一套成熟的商业逻辑。

我这种铁公鸡也会捐款的话，看来确实如此。

借用那篇文章里的图片，这个让我掏钱的「情感勒索」界面，大概长这样：

事实上，这种营销方式连他们自己的社区都看不下去了。

2022 年，英文维基百科 Village Pump 就进行过一次社区投票。志愿者以压倒性多数认为基金会的筹款邮件 不道德且具有误导性。具体的批评包括：筹款横幅主要宣传「维基百科」而非「维基媒体基金会」，容易导致捐赠者误认为所有捐款直接用于维持网站运营。

更让我感到被欺骗的，是这笔资金的去向。

作为一个普通用户，我天真地以为我的捐款会变成服务器的电费、或者是带宽的租金。然而真相是，维持网站运行的硬件成本只占基金会支出的极小部分（约为 5%）。

根据基金会公开的财报和过往争议来看，资金中相当大的一部分主要用于数百名员工的薪资与福利，以及规模可观的软件开发和法律相关开支，另外也有一部分投向以多元与包容为目标的项目；至于这些支出的效率如何、是否带有明显的政治取向，则在不同观察者之间存在较大分歧。

我并不心疼钱，但我希望我的善意不被滥用。

如果他们诚实地坦白「我们需要钱来扩大团队规模、做更多包容性项目」，我是绝对不会捐款的 —— 因为那不是我的义务。但他们选择了暗示「没钱就关服」，这就是对「日行一善」这种朴素心理的精准收割，本质上就是欺诈。

更深层的裂痕在于立场。作为一个中国用户，我意识到我正在资助的这个组织，在对待中文社区时不仅缺乏公正，甚至带有明显的政治偏见与傲慢。

2021 年 9 月 13 日，维基媒体基金会对中文维基百科进行了规模前所未有的行动：禁制了 7 名用户，撤销了 12 名管理员的权限，其中包括中文维基百科十大活跃管理员中的四位。理由是深入调查中国大陆维基人用户组后认为他们存在「渗透」风险，甚至可能对其他编辑者造成恐吓与起底的威胁，并试图在与中国相关的条目中施加不当影响。

实际上又如何呢？指控被公开报道了，具体证据却从未向公众公开；外界只能看到基金会的结论，而无法看到调查过程或原始材料。与此同时，被封禁者否认这些指控，并批评基金会的程序不透明。这使得整个事件至今仍充满争议。

用我的钱，去供养一个对我所在社群并不友好的管理层，这才是最荒谬的地方。

所谓「失去」的 2.75 美元，对于财大气粗的基金会来说九牛一毛；我没有从中得到任何增值服务，毕竟维基百科本来就是免费的。

真要说得到了什么，大概就是一个教训：不要被互联网上的「弱者叙事」轻易绑架。当然，可能还附赠了一堆基于我捐款数据而生成的后续催捐邮件。

为了不再继续这种无意义的供养，我立刻去取消了那个顺手勾选的「月付」计划。虽然目前还没有收到确认回复（可能是赶上节假日效率低下），但态度必须摆出来。

写下这篇文章，也是希望提醒大家：爱维基百科的内容，不代表要无脑供养基金会。在按下支付键之前，先搞明白你的善意到底喂给了谁。

儿童网红背后的黑暗

2025-12-20T14:39:11.000Z

演讲课的最后一场演讲，我选择的主题是「儿童网红背后的黑暗」。

我不清楚国内怎么样，但是国外的儿童网红真不少。最有名的 Ryan 还当过几年最赚钱的 YouTuber 榜首，这个赛道远比我们想象的值钱。

不过很意外的是，Pink Fox 唱的 Baby Shark，这个洗脑了无数带娃家长的歌曲，居然没有赚到很多钱。

儿童网红其实算「童工」的一类，只是这个行业太新了，法律还未跟进。上个世纪有个很有名的儿童演员，叫 Jackie Coogan，他和卓别林一起工作过，赚的钱不能说多，只能说是特别多。但是在他成年后，他才发现他赚的钱全都没了 —— 被父母用完了。加州因为他，通过了 Coogan Law，也就是保护儿童演员的一个法律，所赚的 15% 必须存入信托基金，待儿童演员成年后才可以取出。

对于儿童网红而言，问题会更麻烦一些。多数的儿童网红都是播和玩具有关的。父母录制孩子们玩玩具的视频到网上，你要如何分辨哪个是儿童网红，哪个是单纯地记录小孩在玩？并且 Coogan Law 要求儿童必须有一个雇主，对于儿童网红而言，他们的雇主又是谁？父母吗？就算有和平台签约的频道，那么没有签约的频道怎么办呢？

让儿童工作的弊端有很多，我就不详细说明了。我认为儿童就应该有一个儿童的生活，简单来说便是要有一个童年。童年对人类的重要性实在是不言而喻。

就算工作是玩，但是工作就是工作，许多成年人的工作尽管是和兴趣有关，也难免会讨厌自己的工作，这对儿童来说也一样。更不用提当要玩的玩具里出现了赞助商，一旦和钱、公司有了关系，很多事情都会变得不纯粹。

比如虚假背书，强迫孩子们去推广自己讨厌的玩具。这不仅仅是工作，对孩子们而言也是一种情感剥削，迫使他们在幼年就学会隐藏真实感受。

我在演讲中引用了一个研究，总计采访 19 个儿童网红频道。其中一些对话令我印象深刻：孩子们都说自己录制节目很有趣，父母没有剥削自己。但聊得越来越深入时，孩子们便开始抱怨父母经常在一些事情上管这儿管那儿。例如一个孩子的母亲会强迫他对着镜子练习笑容。

互联网也是残酷的，没有孩子们想象的那样淳朴。今天拍下的觉得有趣的视频，很有可能在未来以全然不同的形式反噬自己。

法国在 2020 年赋予了孩子无需父母同意即可删除自己视频的权利。我认为和互联网相关的法律都应该像这样被推进。大多数人都是互联网的消费者，并且在互联网上花费的时间愈来愈多，也应该让互联网变得安全。不过互联网变安全的代价，自然就是不再自由。

只是对于孩子来说，他们从来没有过选择「不自由」或者「被保护」的权利，他们是被父母推向这个「自由但危险」的领域的。

而孩子这个身份，又会不约而同地吸引一群可怕的掠食者 —— 结果几乎所有受访的博主父母都接触过恋童癖的信息。当然，没有说这都是频道的错 —— 恶意确实不该存在，但它现在就在那里。作为孩子唯一的防线，父母却亲手将监护权让位于经营权，悲剧便成了一个概率问题。

请学会如何读空气吧

2025-12-01T22:44:03.000Z

前不久，我写了一篇文章，讲了我在一个评论区底下发觉到的 Whataboutism。未曾想，这篇文章给我带来的，是一场跟朋友的争吵。

我的朋友阅读了那篇文章的草稿（和实际发出来的内容大差不差），并提出了这些让他反感的点：

Whataboutism 这个例子用得不好，两者明明有关联性
评论区说的没有问题，中国的作业就是比美国的作业多
发布在网上的东西被人骂了活该
无论是发帖子的人、发评论的人，还是写文章的我，全都是事逼；小题大做，闲得慌

我来一一说说。

回复：https://cytrogen.icu/posts/dfa8.html

一、语境错位

Whataboutism 原本是一种政治宣传技巧，但是我在这里的使用方式更多是将其视为一种逻辑谬论，直白点理解就是「因为有更糟糕的事情 B 在，所以糟糕的事情 A 就不算问题。」

朋友会认为这个例子不好，是因为他觉得「美国的作业」和「中国的作业」都是「作业」，是有关联性的，那么评论提及「中国的作业」就不涉及到 Whataboutism。

我们的核心分歧在于，「关联性」到底由什么决定？

朋友的逻辑是，只要主体属于同一类别（「作业」），且事实属实（「中国的作业确实比美国的作业多」），那么在这个帖子下提及到中国的作业就是合理的比较，不是谬误。

似乎很有道理。

但是我们在讨论一件事的时候，说出来的内容 其实并没有 说这个内容的目的 重要。原帖主发帖的目的是什么？是寻求安慰、共情和建议。这些提及到国内作业的评论做的又是什么？首先是预设原帖主的目的是否认国内的作业没有美国的多，其次是靠比烂彰显优越感。这些评论是否有帮助到原帖主？没有，反而更糟糕了，因为它们否认了原帖主抱怨的权利。

如果提及国内作业的目的是为了消解原帖主的情绪或者否定他的问题，那么即使他们说的是事实，他们依然涉及到了 Whataboutism 或者比烂。

原帖的语境是情感宣泄，而评论却把语境强制降维成了事实比对。但是问题在于，到底谁问你们了？有任何人说中国的作业不多吗？

二、真理的功能性

朋友以及评论区的那些人的防御逻辑在于，他们说的是事实。「中国的作业就是多」这句话因为在事实层面是真的，所以他们也认为自己在对话层面是合理的。

但是人类之间的对话绝对不是只要说了事实便可以攻击他人。

事实有两种用法：一是解决问题，例如你提醒他人外面下雨了，记得带伞；二是剥夺权利，骂所有说食物不好吃的人「非洲还有人饿死呢，你要什么好抱怨的」。当一个人在寻求情感支持的时候，去谈论谁更惨，本质是一种冷漠和对他人痛苦的刻意忽视。

如果按照这个逻辑下去，那么除了那个全宇宙最惨的人，剩下 70 亿人都没有资格难过了。这显而易见是荒谬的。

这些评论拿出的「事实」，不是为了讨论，而是为了封你的嘴。 这就是我想说的功能性。目的真的是为了陈述事实吗？那怎么看都不是。

不过我认为，朋友之所以无法理解我说的，最主要还是「拒绝看见情绪价值」这个维度。我后面会提到。

回复：https://cytrogen.icu/posts/d4e5.html

三、消极放任

到这个时候，朋友明显开始出现了情绪化的状况，不过他依然想要和我辩论。他认为，发到互联网上的东西就是会被他人看到、批判，甚至辱骂。这是再正常不过的事情了，因为互联网无时无刻都充斥着攻击和辱骂。不过是一个这么小的一件事，你还专门写个文章说，你一天天难道没有事情做吗？

这里的逻辑可以简单梳理为，既然一件事情已经是这样了，那么我想要去改变、批判它，就是矫情和多余。这也是另一种形式的虚无主义：反正人都要死，何必这么拼命？ 这个事情是大事吗？当然不是，它确实是一件小到不能再小的事情。

但小事不代表没错。我发现了问题，我指了出来，你指责我是什么意思？

这种「消极放任」才是最可怕的。因为它 不仅承认了恶的存在，还进一步把「指出恶」定义为一种错误。这不单单是虚无，也是一种对现状的共谋。用「大家都被骂」来合理化网络暴力，并试图以此让不满者闭嘴时，他其实已经成为了那个糟糕环境的维护者。所谓的「正常」，也不过是习惯了麻木之后的自我催眠罢了。

我肯定不认为写一篇博客就能彻底净化互联网，但我至少想要拒绝加入这种麻木的合唱。连指出「这不对」的勇气都被嘲笑，那才是无可救药。

四、充满攻击性的理中客

到最后，他终于把自己内心所想的事情说了出来：他觉得我们三方都是事逼。

当他这么说的时候，我忽然理解了我们之前辩论的实质。那些争论或许都只是表象，核心驱动力可能并非源于逻辑，而是源于一种深刻的情感不认同 —— 他是一个厌恶互联网的人，他讨厌我写博客、讨厌我上网、讨厌我交网友…… 真烦！跟你有什么关系！ 总之，他觉得任何在网上发布这些「私人想法」的人，都有罪，都是在无事生非。

于是，一场本该关于公共讨论规则的辩论，最终坍缩为一场人身攻击。我意识到，他或许只想批判我的姿态，所以我也不乐意再跟他讲什么道理了。我说，「你的这些想法真的很烦很坏。」烦是因为这并不是他第一次向我传达这些具有攻击性的想法（而我最讨厌别人满嘴只剩自己了）；坏是因为 他一边劝我闭嘴，一边自己又闭不上嘴。尽管他说了这都是观点、没有想要纠正我的意思，但一些话并不会因为你的事后解释就变了性质。

或许网络上那些不由分说的「比烂」和「反问」，其内核也是如此：拒绝进入语境、拒绝理解情感，只想用最简单粗暴的方式完成居高临下评判的姿态。这种姿态不仅隔绝了理解，也杀死了沟通。如果有什么是可以打破这层傲慢的厚壁的话，或者就只有这简单的几个字：请学会如何读空气吧 —— 因为在冰冷的逻辑和事实之外，那里才是我们要共同呼吸的地方。

想法在乙巳纸月迭代

2025-12-01T16:38:23.000Z

虽然上个月已经说了很冷，但发现这个月变得更冷了……

本期导读

我在谈论共情，他们在谈论逻辑

2025-11-24T15:07:48.000Z

先前我刷到一个视频，内容是「一位学生在自习期间播放恐怖电影，反而导致另一位学生被吓出精神问题」。较为可悲的是，评论区内竟然有很多声音是指责受害者「矫情」，然后延伸到「现在的孩子都脆弱」。

这些声音令我作呕，于是我写了一个评论侧面攻击了这群人。我说：

「评论区部分评论很完美地展示出了过早接触暴力、恐怖题材内容的弊端：没有共情能力、喜爱嘲笑欺凌他人。不要成为这种人。」

结果我收获了一部分支持我的声音，以及一部分不知道为什么就是想要指责我的声音：

说「没有共情能力、喜爱嘲笑欺凌他人」这些都是个人特征，然后指责我将它们赖到恐怖片上。我的回复是，我压根没有说看恐怖片是导致这些情况的主要因素啊。
反问我「与他人共情有什么意义」。这个没什么好说的，我都没有回复他他就已经被其他人骂的不敢说话了。
认为我归因草率的，原因有二：
1. 我不知道评论区内缺乏共情能力的是因为过早看了恐怖片
2. 我无法确定恐怖题材会导致缺乏共情能力

我主要就说第三条。

首先我承认，我的评论存在了几个逻辑问题：我确实无法隔着网线核实那几个恶语相向的人童年是否看过恐怖片，「过早接触」也确实不能直接推导出「缺乏共情」。

但对于这个人看似客观的驳斥，我有意见。

我说的明明是「弊端」，他怎么理解成我说接触恐怖题材「一定」会导致缺乏共情能力？我有说我「确定」接触恐怖题材会「导致」缺乏共情能力吗？「弊端」这个词属于 可能性论述，他硬是给我掰成了 确定性论述，然后用这个被强化后的 稻草人 来攻击我「归因草率」。

通常我们看到一个熊孩子在公共场合撒泼打滚，会下意识感慨「这是过度溺爱、缺乏管教的弊端」。这并不代表我们认定所有溺爱的孩子都会变坏，也不代表我们需要先做完家访确诊了家教方式才能开口说话吧。

我们是在根据经验，警示一种环境造就性格的风险。我的担忧也并非空穴来风，心理学研究早已证实过度的感官刺激会让人对现实中的痛苦变得麻木。

是啊 看恐怖内容不一定会让人丧失共情能力、变得喜欢嘲笑欺凌他人，但那和我的观点有什么关系，我本来就不认为它们一定会这样啊。我个人并没少看恐怖题材的内容，并认为恐怖内容在我们的成长中有一定的帮助。

我想表达的根本不是「我反对恐怖片」，而是「心智未成熟时的过度暴力暴露」：为什么要莫名其妙霸占自习时间然后自作主张播放恐怖片，然后攻击受害者矫情？ 再用先前熊孩子的例子，对方非要杠「你怎么知道他不是天生坏种」，这种对于显而易见的关联视而不见、非要追求绝对因果的姿态，与其说是严谨，不如说是为了抬杠而故意装瞎。

再退一步讲，这真的重要吗？

我的那条评论，根本不是一篇学术结论，而是 一个正常人类在面对同类受苦、遭到二次伤害时，出于道德义愤的本能反应。我认为我的评论，在这个评论区的出现根本就是在提醒其他观众，重点是「不要成为恶人」，使用「恐怖和血腥内容」作为因子完全是为了攻击那些恶意评论。我的评论的唯一问题，不就是没有叠所有的甲，在每个词之前加个「可能」嘛？

他的回复也是完完全全的在「驳斥」我，而非「探讨」这个问题。他指责我的点是否正确？客观来讲，没什么问题，我的用词确实不是「事实」。我不清楚他回复我的实际动机，但在他的语气里只能感受出他的质疑、否定，和一丝刻意的指责，也就是说他的回复本身既不严谨，也带有攻击性，并且绝口不提受害者和评论区里满溢的恶意。

但他的回复，无视了我的 价值倡导 初衷，只是揪住了我论证中不符合学术严谨性的部分进行攻击。他 不在乎 那个学生是否痛苦，也 不关心 我的核心关怀，他只享受于指出我形式上的错误。

这让我想起一句禅语：

当手指指向月亮时，傻瓜却在看手指。

在这种语境下，优先讨论「归因是否严谨」，真的有意义吗？

难道我们在制止恶行、呼吁善良之前，必须先做一份完美的社会学调查报告？难道人说的每一句话，都要以此生绝不出错的标准，去迎合世界上所有杠精的审查？

把逻辑变成自己冷漠的借口，这种所谓的「严谨」，不过是另一种形式的残忍。

在 AI 恐慌的时代，熟练度是一种累赘

2025-11-20T21:36:50.000Z

近日我在一项限时一小时的小组作业里被教授控诉使用 AI 且不承认，而她的理由让我大跌眼镜。

背景

我这个学期正在上一节 CIS（计算机信息系统）课程，内容是 Python 入门，上课方法是网课。开课时的第一周，教授便给我们分配了一项作业：介绍自己并且告知我们是否有课外经验，好让她了解我们的能力以及对我们的作业有多大的期待。

我于数年前便学习过 Python，且学习了很长一段时间爬虫、网页自动化操作和 JavaScript 逆向（关于 JavaScript 逆向，你可以在这里找到一些我过往写过的文章。我也有当时学习这三个内容的笔记，未来可以发出来）。

于是我填写了表单，表示我学习过 Python 并且懂得如何使用许多库，其中便包括了这次的主角：BeautifulSoup。

起因

教授要求我们在一小时内完成一个小组作业，要求如下：

网页抓取书籍数据
目标网站： Books to Scrape
任务：
从网站的 第一页 提取书籍信息，包括：
书籍的标题
价格
库存状态
将每本书的数据存储为一个字典
输出示例：
A Light in the Attic : {'Price': '£51.77', 'In Stock': 'In stock'}Tipping the Velvet : {'Price': '£53.74', 'In Stock': 'In stock'}
作业说明：
遵循课上讨论的步骤和方法
你可以使用 AI 工具来获取关于从网站抓取数据的指导或澄清，但 请勿复制完整的解决方案。任何 AI 提供的建议 都必须经过修改，以符合课上讨论的方法和步骤，以此证明你自己的理解并应用了所学知识
直接提交来自外部来源的解决方案将得零分
如果你使用了 AI，请 明确注明 你使用的 AI 工具，包含你提供的提示词，以及 AI 生成的输出内容
请像课上演示的那样，一步步展示你的进度。只提交完整的解答而没有展示过程或小测试将不被接受
进阶挑战：
从网站的 前 5 页 提取书籍信息
同时提取评分

这里有一些内容需要补充：

教授本身不懂 HTML，也没讲过 HTML
关于网页爬虫的内容，教授只讲了一堂课

这也是为什么教授允许我们使用 AI 工具：因为一些内容她根本没提到，需要 AI 辅助。

回到小组。我因为本来就懂爬虫，也懂怎么使用 BeautifulSoup（不过我更喜欢 lxml~），所以我直接告诉了小组成员我们要如何编写这套代码。不过这里出现了一个小插曲：我误以为需要进入到书本详情页才能获取到标题等内容，还白白写了一套「获取所有链接、访问链接再抓取数据」的代码。实际上直接在首页抓就好了。后面被小组成员提醒才赶忙修回来。

好了这不是重点！

这是首页源代码里一本书的内容：

        
                        
              Sapiens: A Brief History ...
      £54.23
                      In stock

这里需要特别说一下首页标题：

Sapiens: A Brief History ...

如果直接 a.text 的话，只会得到被裁剪的标题。真正的标题在其中的 title 属性里。那直接写 a["title"] 就可以了吗？当然不是了，不是所有的 a 标题都带有 title 属性，真跑起来的话不就报错了？

这里有两个方法：

if soup.find("a")["title"]:

soup.find("h3").find("a")["title"]

当然了方法还有很多，我这里只说我当时第一时间想到的。

用第一个办法最保险，但是对于这个简单的作业，我直接写的第二个。这里虽然是我不够严谨了，不过当时实际敲代码的并不是我。单是口头指导屏幕另一边的小组成员怎么写东西、要点击什么东西就已经够累人了，我还需要告诉他们为什么我要这么做、用的方法是做什么使的…… 因为小组成员好像没有一个人知道怎么做哎！反正代码向来都是能用就可以，我觉得这个处理方式没有任何问题。

其余内容没什么好说的，我直接让小组成员开始写字典、照教授所要的方法打印出来字典…… 唯一的问题是打印出来的价格会多出一个神秘符号 Â，感觉是编码问题。我们加了一个 .replace("Â", "") 来去掉它。

这时候我们已经快到了截止时间。我们不仅需要在这个时间里写完代码，还需要填写成员评估表单交上去。这是最终代码（因为是 ipynb，所以一个代码块等同于一个单元格）：

所有代码

What About…… 和比烂

2025-11-18T05:24:41.000Z

我在网上冲浪时刷到一个吐槽美国学校作业多的帖子，发现了一个评论：为什么大家什么都要和国内比？为什么要比较彼此谁更不幸呢？

我认为这是现在少数的、能发觉评论区问题的人。当时的评论区近乎都是国内的账户评论「国内就不累了吗」或者「这才哪到哪儿，国内高中更累」这样的发言。前者更类似于 Whataboutism，后者则明显就是比烂。

Whataboutism（那…… 又怎么说）是一种常见的逻辑谬误。当一方提出 A 领域的问题时，另一方在不喜欢对方的观点的情况下，不就此回应、反而抛出了 B 领域的另一个问题来反击或者转移话题：你这样说是不是代表着你觉得这个另一个主体不 xxx？ 这种观点表述在关于外国的帖子，尤其是吐槽和抱怨的帖子下比比皆是，动机因人而异，但大抵可归为两类：

内心更相信外国的月亮更圆，因此不信任他人对外国的评价
感觉被冒犯到了，所以触发了防御心理

无论初衷如何，其结果往往是 模糊了焦点，让理性的比较和就事论事的讨论无法展开。

我遇到过不少类似的情况。当我提出美国社会某些制度的弊端时，对方总是会立刻将中国的情况拉出来作为「反驳」，好似他们根本无法意识到，复杂的国家比较根本就不是非黑即白的优劣判断，而是各有侧重的 AB 级 —— 一个多了这个但缺少了那个，一个多了那个但缺少了这个。

比如，我说「美国很多城市的公共交通太差了，晚上出门没有车简直寸步难行。」那么一条经典的 Whataboutism 回复就会是：「呵呵，那你是不了解国内小县城，那里连公交都没有，你怎么不说？美国有地铁公交你就知足吧！」

你看，我的原意是讨论「美国某城市公交系统不便」，这是问题 A，但回复者却将话题强行转移到了「中国小县城公交匮乏」，也就是问题 B 上。他预设的立场是「我在通过贬低美国来抬高中国」，并通过引入一个更不堪的例子，试图证明我的抱怨是「无病呻吟」或是「别有用心」。

这自然是我虚构出来的一个例子。不过将这里的主体稍微换一下，便能得到我和某个朋友曾经每天的对话是什么样的（关于这个朋友，我在未来会写篇文章展开说说）。这也是为什么我对这种事如此上心，实在是令人烦躁！按照这些人的逻辑，只要世界上存在一个更差的情况，所有具体的批评就都失去了意义。于是，关于问题 A 的任何深入讨论都被扼杀了。

比烂则是一种更消极的攀比。攀比这个行为并不需要比较「好的地方」，比较「烂的地方」也可以，因为攀比的本质是让「他人看到自己」。当一个人在价值上难以企及「最好」时，通过证明自己经历了「最烂」来获得某种独特的优越感或存在感，便成了一条捷径。

这种行为深层次上，呼应了人类对自我身份的寻求。在宏大的网络世界里，个体常常感到渺小，而一个极端的故事，无论是至善还是至恶，都能成为最有效的身份标签。让他人看到自己，也可以回复人们从青少年时期就在思考的问题 —— 我是谁？ 于是，最惨的经历也成了一种畸形的资本，通过它，个体得以在嘈杂的舆论场中被看见、被记忆，从而确认「我是谁」。

Hexo 和 Typora 的完美图片工作流

2025-11-14T01:37:43.000Z

我写作是用 Typora 编辑器来写 Markdown，再让 Hexo 框架的 Markdown 渲染器渲染成 HTML。

Hexo 对于图片的存放要求是这样的：在 Markdown 文件的同级下创建一个同名的目录，并在该目录下存放图片。这样写很方便，只需要在 Markdown 文件里写 ![](图片名.类型)，程序就会自动从同名目录里找到指定的图片。

但如果我想要在 Typora 里直接粘贴图片，它通常会被拷贝到其他位置，我再灰溜溜去手动挪动图片的位置。

幸运的是，我最近发现一个法子可以解决这个问题，让我的写作体验更上一层楼~ 这个方案的核心是把 Typora 的图片保存逻辑（它实际把文件复制到哪里）和路径预览逻辑（它如何理解 ![](image.png) 这行代码）分离开。

在 Typora 中，进入设置 > 图像。
在 插入图片时…… 下拉菜单中，选择 复制图片到指定路径。
在路径输入框中，填入以下这行代码：
```
./${filename}/
```
勾选 优先使用相对路径。

现在，当你在一篇名为 hello-world.md 的文章中粘贴图片时，Typora 会自动将该图片复制到 hello-world/ 文件夹中。不过插入的路径还是 ![](hello-world/image.png)。要解决这个问题，我们只需要在文章最顶部的 YAML Front Matter 区域里添加一行：

---typora-root-url: ./hello-world---

这个路径必须和这篇文章的文件名完全一致。而在 Hexo，你只需要在 scaffolds 里添加一个：

---typora-root-url: ./{{ title }}---

就可以每次用 hexo new 命令创建 Markdown 文件时，自动添加这个键值对。

离开父母对成年子女独立性的帮助

2025-11-05T17:31:23.000Z

我在公开演讲课上的一次信息性演讲内容。这篇文章是我的演讲稿的超级增强版。

离开父母家庭是 成年初显期 最重要的发展转折点之一。迈出这一步，可能让人感到兴奋、充满不确定性，而且坦白说花费不菲。但是，当一个年轻人离开「巢穴」时，究竟会发生什么？这远不止是换一个地址那么简单。发展心理学的研究表明，住宅独立是全方位独立性的催化剂。搬家不仅重塑了我们的家庭关系，也强力推动了个体身份认同的发展、日常自给自足能力的建立，甚至对我们的心理健康都有深远的影响。

促进更成熟、平等的亲子关系

只要你住在父母的屋檐下，你就很难摆脱「孩子」的角色。你活在他们的空间里、遵循着青春期的权力动态 —— 他们行使控制，你保持依赖。这种旧有的亲子模式很难打破。但是当你搬出去后，游戏规则就必须改变。你的父母不再负责你日常生活的方方面面。正因为如此，他们会自然地减少控制，而你也减少了依赖。

威斯康星大学麦迪逊分校的社会学教授威廉・阿奎利诺的权威研究揭示，离家是「通往更加个体化关系的催化剂，这种关系建立在两个成年人之间的相互关怀和尊重之上」。

这种转变是积极的。宾夕法尼亚州立大学的肖恩・D・怀特曼及其同事在一项长达十年的纵向研究中证实了这一点。他们追踪了 184 个家庭从子女早期青春期到成年早期的家庭关系变化，发现在长子离家后的一年内，母亲和父亲都报告与离家子女的冲突显著减少。具体而言，母亲报告的冲突频率下降超出了正常发展轨迹，父亲的报告也显示类似模式。

更重要的是，这种改善还表现在情感亲密度的提升。离家的年轻人自己报告说，与父母的亲密感在离家后有所增加，超越了他们之前的发展轨迹。康涅狄格大学人类发展与家庭科学系的教授兼系主任伊娃・S・莱夫科维茨在 2005 年的研究中发现，78% 过渡到大学的年轻人报告亲子关系发生了变化，其中超过 80% 的人将这些变化描述为积极的，例如「感觉与父母更亲近」、「沟通更开放」、「争吵更少」。

这种关系转变的深层意义在于，它标志着从等级制的监护关系向平等的成年人关系的过渡。年轻人开始被视为独立的决策者，而不是需要指导的孩子，这种认可本身就是独立性发展的重要组成部分。

获得空间，探索「我是谁」

这一点可能是最重要的：身份认同。

杰弗里・阿内特是克拉克大学心理学研究教授，也是 成年初显期（大约 18-25 岁）理论的创始人。他在 1995 年开始对 18-29 岁的年轻人进行深度访谈，历时五年访谈了 300 名来自不同族裔、社会阶层和地理区域的美国年轻人。阿内特指出，成年初显期 最显著的特征是「身份探索的年龄」。在这一阶段，年轻人探索爱情和工作中的各种可能性，逐步做出持久的选择。通过尝试这些不同的可能性，他们发展出更明确的身份认同，包括理解 自己是谁、自己的能力和局限是什么、自己的信念和价值观是什么，以及 如何融入周围的社会。

离开父母家在这一过程中起到了关键作用。它创造了必要的物理和心理空间，让年轻人能够进行独立探索。当年轻人搬出父母家时，他们面临着从 决定晚餐吃什么 到 是否结婚 等各种独立决策。这种自主决策的练习是身份形成的核心。成年初显期 也因此成为「自我专注的年龄」—— 大多数美国成年初显者在 18 或 19 岁搬出父母家，直到至少接近 30 岁才结婚或生育第一个孩子。在青少年依赖父母和成年人在爱情与工作中的长期承诺之间，成年初显者专注于自我，发展他们成年生活所需的知识、技能和自我理解。

阿内特还指出，成年初显期 是「不稳定的年龄」。年轻人在探索爱情和工作的不同可能性时，生活往往不稳定。美国社会 18-29 岁年龄段的居住变动率远高于其他任何生命阶段。这种不稳定性反映了他们生活中正在进行的探索 —— 有些人搬出去上大学，有些人仅仅为了独立而搬出；他们可能因为退学或毕业而再次搬家；他们可能搬去与恋爱伴侣同居，然后在关系结束时搬出。这种看似混乱的模式实际上是身份探索的表现，每一次搬迁都代表着对新可能性的尝试。

建立财务独立与自给能力

这一点显而易见，但至关重要。如果你问人们「成为一个成年人」意味着什么，排在首位的答案之一总是「财务独立」。搬离父母家为此创造了必要性。

杜克大学社会学和人口健康科学教授迈克尔・沙纳汉在生命历程研究和成年过渡方面具有深厚的学术积累。沙纳汉明确指出，独立生活是成年初显期的关键发展任务之一。离开父母家会直接促使年轻人发展自给自足的能力。他们必须学会管理预算、支付账单、购买食品杂货、处理住房相关事务 —— 这些日常责任的累积培养了自力更生的能力。

来自全国青少年到成年健康纵向研究的数据显示了财务独立的复杂性。研究者安娜・曼佐尼使用马尔可夫模型分析了年轻人进出父母家的转变及其与代际财务转移的关系。她发现了一种「部分独立」状态（不与父母同住但接受父母财务支持）在年轻人中非常普遍。重要的是，参加四年制大学的年轻人在大学期间接受父母财务支持后，更有可能在随后过渡到完全独立（既不与父母同住也不接受财务支持）。这表明，离开父母家，即使最初伴随着财务支持，也为最终实现完全财务独立奠定了基础。

明尼苏达大学家庭社会科学学院的研究进一步证实了这一点。研究者使用 2005-2015 年收入动态面板研究的数据，追踪了 1719 名 18-27 岁年轻人的四项财务独立指标。他们识别出四种财务独立轨迹：持续独立、快速独立、逐渐独立 和 持续受支持。关键发现是，经历 快速独立 轨迹的年轻人最终报告了更高的财务安全感。

这些发现揭示了一个重要机制：独立生活让你为自己的生活买单，迫使你培养出坚固而可转移的财务管理和生活自理能力。这些在真实压力下习得的技能，是终身独立的基础。

对心理健康的复杂影响

因为很复杂，所以长话短说：成功地独立生活，通常是对 自我效能感 的巨大提升。你觉得自己有能力、能胜任，这本身就是心理健康的核心。

然而，来自鲍灵格林州立大学的研究团队利用托莱多青少年关系研究的纵向数据，对 891 名成年初显者进行了分析，探讨了居住安排与抑郁症状之间的关系。

研究发现，从未离开父母家和独立生活的成年初显者报告的抑郁症状显著低于返回父母家的人。具体而言，返回者的抑郁症状平均高出约 2 分（在 6-48 分量表上），这一差异在控制了先前抑郁症状、父母亲密度、性别、种族、家庭结构、母亲教育、就业 / 在学状态、关系状态和子女数量后仍然显著。

这一发现揭示了离开父母与心理健康之间的复杂机制。独立生活本身与较低的抑郁症状相关，但这种积极效应取决于独立的质量和原因。对于那些能够维持独立的人来说，独立生活增强了 自我效能感 和成年身份认同。然而，对于那些因负面事件被迫返回的人来说，返回可能被感知为「倒退」或下行轨迹的一部分，与独立、自给自足的成年人自我形象相冲突。

研究还发现，居住动机起着中介作用。那些因为「享受与父母同住」（内在动机）而与父母同住的人报告了较低的抑郁症状，而那些因为「失业或找不到工作」（功利性动机）而同住的人报告了较高的抑郁症状。更重要的是，就业问题调节了返回父母家的效应：只有在经历就业问题的情况下，返回父母家才与更高的抑郁症状相关。

这些发现指向一个关键机制：离开父母和维持独立被视为成年的传统标准，当年轻人能够成功实现和维持这一状态时，它增强了他们的自我评估，确认了他们正在向成年标准前进。相反，无法维持独立可能损害 自我效能感，影响追求教育或者职业机会、寻求恋爱伴侣和维持健康关系的能力。

迎接挑战，获得成长

诚然，搬离父母家不是解决所有问题的「万灵药」，在当今高房租和劳动力市场不稳定的社会中，独立之路也比以往任何时候都更加复杂。

但是这个过程仍然至关重要。

搬离父母家提供了一个发展性的「一揽子交易」：

它将你的家庭关系重置为成年人之间的相互尊重。
它为你 建立了空间 去构建和整合你的独立身份。
它 迫使你 学习真实世界的生存技能。
当你成功应对这些挑战时，它为你带来了 核心的胜任感，并将伴随你一生。

离开父母家庭是 成年初显期 最艰难、也最重要的一次挑战。正是这些挑战，最终帮助我们成长为自主、有能力的成年人。

引用

只是演讲稿的引用

想法在乙巳开冬迭代

2025-11-02T05:34:23.000Z

开冬不愧是开冬，前段时间还觉得有点热，现在每天都是冻醒的。这个月，我在缓慢地调整我的生活 —— 从兼职、工作、学业和自己。我还在摸索「想法迭代」这类文章的架构，所以该文章相较于上篇文章会有显著的差异。

日记

我决定调整一下日记板块的内容。该板块会注重于一些篇幅不长、专注于生活的内容。我希望展开讨论、有一定深度的内容则会在日记板块的后面。不过写太多的内容会被我编辑成独立文章发布，我在这里只会给它们留个标题的位置（或者一丢丢补充说明）。

Perplexity 会员体验

PayPal 的首页上有个领取福利的栏块，我一直都没有去看。一次突发兴起，我领取了 Perplexity 的一年免费会员。因为我还是个学生，还可以用学校的邮箱再领取一年。

Perplexity 是一个基于大语言模型的应用程序，功能比较多，主要是帮助用户更好地搜索、研究。你想要搞清楚的问题，Perplexity 都会帮你「搜索」、「总结」。因为它会搜索网上的资源，因此幻觉不会太严重。就是有时候它会直接略过搜索这一步骤、根据自己的训练数据告诉你答案。

另一个起眼的功能是新闻板块，它会自动抓取线上的新闻、结合成数个文章，并展示给用户。我个人用下来，新闻板块几乎没有主动看过。它每天都会推送给我一些新闻，我也都没有去看。除了个别新闻我有看 —— 例如联邦政府罢工一事 —— 其余的几乎都是「特朗普今天又做了什么」的新闻。

我用的最多的是研究功能，主要是深入某个主题、靠问数个问题来得知客观数据。不过我试了下、使用了 Perplexity 辅助写作，并发现了一个问题：我的想法会被它无比正确的研究和数据左右。我大概写了几篇文章作为比对，其中有几篇我感觉很失望。内容虽然很正确、很对、无法纠错，但看着只让我感觉挫败。还是得要我自己写好文章，然后再去找 Perplexity 查找对应的数据。

自然，这并不是 Perplexity 的问题。无论我用什么 AI 工具，只要在最开始起稿的时候就使用并且依赖它们，都会落得这样的结果。

咪咪

家里人从家附近捡了个小猫回来。刚捡回来的时候，小猫的身上全是跳蚤在爬，我母亲根据养狗的经验，直接用带药的宠物沐浴乳洗了一遍猫。这样做其实很危险，小猫还未打疫苗，洗澡容易导致问题。好在它之后表现得十分健康和好动，没过几天就会用「猫猫拳」打狗的鼻子，吃完猫粮后还会偷偷再吃狗的饭。

我找了一天回父母家、带小猫去医院做检查。我预约的是 Vetco，载着三人一狗一猫开了半小时的路才到。谁曾想 Vetco 这期间给我发了消息，说本次预约不正确、医生不在，需要我回电让他们客服进行人工预约。没办法，我们只是在那附近的零售连锁店买了一些猫玩具和猫抓板回去。

尽管想着之后有空的时候再预约一次，结果到十月底我没有一天是闲着的。我的天啊 ——！

兰州牛肉面

小时候住的巷子的路口有一家兰州牛肉面馆，特别好吃。这家店最稀奇的在于，老板是一位犹太人。他不仅管接客收银，面也是他在一个大铁桌上亲手拉的。我记得他会很用力地摔面，发出很响的声音。有时候会看见他的妻子和儿子，长相也是非常接近我们传统印象里的犹太人样貌：金发、黑衣、戴眼镜。

学校附近有两家兰州牛肉面馆。我常去的这家免小费，不过单品价格并不便宜。我点了一份兰州牛肉面和一个肉夹馍。他家的肉夹馍味道很不错，税前 7 美元一个。

中秋游行

中秋那天，布鲁克林的日落公园区有中秋游行，据说是 BBA（繁荣布碌仑协会，Better Brooklyn Association；这里的布碌仑是布鲁克林的另一种说法）举办的第二次中秋游行。游行里有数个学校的学生在演奏乐器、表演舞蹈，还有一个环节是一群玩偶服的人在朝街边扔毛绒玩具。神奇的是，游行队伍的最后还有长乐游神。

妹妹的游泳比赛

妹妹第三次比赛游泳，也是我第一次开车上高速。没开过那么快的车，脚感很不习惯，不过感觉没什么问题。这次妹妹比赛的场地在新泽西。不知为何，教练给她选了个 100 码的比赛项目。50 码后她明显变得力不从心。

因为家人的影响，妹妹有些「一根筋」，比赛结束后不敢去问教练能否提早离开，导致我们晚了一小时才离开现场。下午饭依然是吃越南面，不过这家餐厅装修更高档、食物味道更好，随之提升的还有价格。好在份量不小，三个人就着俩主餐、一小吃和一碗加的面吃饱了。

E-Fika

我的辅修是日语。大学的日语部门要求我这学期参加两期信州大学的英语部门学生们举办的 E-Fika。Fika 是瑞典的一个类似于茶会的活动。你可以带自己的饮品、食物来参加，要做的事情只有两个：休息和聊天。而 E-Fika 就是线上的 Fika，大家用 Zoom 开着摄像头互相认识、聊天。我起先发现的是，信州大学的学生们讲英语明显要比我们讲日语利索许多。

我的日语水平在班上算是偏好的，可以模仿本地人的一些腔调。不过真让我和本地人用日语交流的话，还是算了吧！

语言是死去的诗歌

网上冲浪时，我发现了一个帖子，内容是帖主在一次思索时发现「不如」这个词的意思就是「我的提议更好、你的想法比不上我的」。评论区的人们发表了众多他们发现的一些有趣例子，比方说：

「不知道」：「道」是一切的本源、组成万物的基本单位，那「不知道」不就是「什么都不知」的意思吗？（哎哟我才发现除了「不知道」外我都不知道该如何表达「不知道」的意思，像这句话里我又用了一次「不知道」）
- 不过现在「道」已经虚化成补语，表示「知晓」的结果，而非指称哲学意义上的「道」。
「开水」：想象「开花」，「开水」便是「水像花一样盛开」。
「披风」：「披着风」。
「未来」：「还未来到的」。
「故事」：「过去的事情」。
「太空」：这里的「空」是「空间」的意思，「太」则是「大之甚」，放一起便是极大的空间。

我觉得很有趣，简单研究了一下，发现这涉及到一个概念 —— 语义透明度。意思是复合词的整体意义能够从构成它的语素意义推知的程度。学者们将复合词分为了不同类型：

完全透明的词：词义基本等于语素意义的直接相加，能从语素义直接推求词义
半透明或不透明的词：整词语义与语素意义存在差异，甚至完全不相关

新鼠标

我换了个新鼠标，因为旧的鼠标按键有点坏了。这次买的是人体工学鼠标，没我家里的那款鼠标「垂直」，不过大小很匹配我的手。室友感觉有点大。

外卖和小费

十月中旬，天气开始变冷了，我也比以往晚醒了一小时半的时间。有一天打工，我忘了带下午饭，所以点了个预订送达的外卖。我用的平台是饭团外卖，说是有活动，肉夹馍 0 元。自然这个便宜在北美的外卖平台里是占不到的，平台费小费等东西加起来，变成了比肉夹馍原价还要贵一点的价钱。如果没有这个活动，一个肉夹馍说不定就要 12 美元呢！更可恶的是，这个肉夹馍没有青椒就算了，里面放的还是青葱和洋葱。整体也就比我的手大一点，几口就被我吃干净了。

大一的时候我很喜欢用熊猫外卖，当时的一个十元吃饱活动，一碗土豆粉真的就是十元多。后来纽约市要求顾客必须至少给外卖员固定比例的小费。小费文化真是个糟蹋，我也不理解为什么有人会喜欢这东西。一次网上冲浪，我表达了对小费文化的厌恶，还有个人阴阳怪气地回复我，说我在这里说没用、要去申报才行。

这样说的话，是不是送外卖也很赚钱呢？我要不要也去送外卖看看？

不过几天后老板告诉我熊猫外卖多了个「0 服 0 运」，说是服务费和运费都不收。我试着点了一份米线外卖，9.99 美元加 3.8 美元的额外米线，再加上 1.22 美元的消费税，实际支出 15.01 美元，连小费都不需要给。这让我好奇商家、平台和外卖员都是如何靠此盈利的。

越南春卷

室友买了一堆原材料，包了个越南的 summer roll（脍卷、夏卷，或者直接说越南春卷）给我吃。

做法很简单：首先是煮越南的一种粉，然后煮虾剥虾、切黄瓜丝萝卜丝等。米纸沾水拿来包这些材料。为了不破掉，要在米纸还有点硬的时候就开始包。酱料则是花生酱、番茄酱、耗油和热水搅拌而成。

她的师傅是十几家餐厅的老板，其中一家餐厅便是专门做越南菜的。他家的脍卷酱料非常好吃，我跟她经常会抢着要。现在我和室友还没有搞懂里面究竟放了什么，只知道有猪肝在内。

学会做了脍卷后，室友很贴心地为我包了一些带去工作吃。因为没有小盒子装酱料，她故作聪明地把酱料包在了米纸内。结果就是，等我要吃饭的时候才发现皮全部破了、酱料也都流得到处都是。

后面我们太懒了，直接省去「包」这个步骤，将米纸沾水揉成一团，然后切成数个小条条、直接蘸酱吃。口感很像更硬一些的肠粉。而整道佳肴则变得更像是一种拌面：

玩桌游

一天周日，我和室友以及她的一个朋友来办公室玩 茂林源记。我先前就玩过这游戏，刚开始玩的时候很上头。这游戏的美术风格我很喜欢，最初我是在一个桌游吧看到的，但是因为它的规则书而被劝退（当时我还只会玩 炸弹猫 等较悠闲的桌游）。之后我看到了 Steam 版本的 茂林源记，实在是太想入手，便买了个玩。入门期间我发现它的规则其实并不难接受，遂推荐给室友玩，没想到她比我还上头，直接买了实体的桌游和扩展。

茂林源记 的故事设计我认为很有创意：一个森林原本被 飞鹰王朝 控制。他们有规律地生活、完全遵循于法条。结果主张工业发展的 猫咪贵族 侵入森林，将飞鹰们打跑，并希望统治森林。飞鹰不甘心，想打败猫咪、重新夺回森林。森林里的其他阵营也想要达成自己的目的：想要和平、由百姓组成的 森林联盟；只为自己出名声的 神秘游侠；渴望从战争中谋取财利的 河岸商会……

游戏阵营很多，规则也各不相同，因此这游戏入门比较困难。你不只是需要搞明白自己在做什么，也得明白其他人如何计分，以及如何阻碍他们计分。但又因为规则各不相同，阵营之间也是有着克制关系和不平等的强度：有些阵营遇到特定阵营玩起来就是很难受；有些阵营强度就是高到离谱；有些阵营玩起来就是异常艰辛。尽管它的美术风格十分可爱，但认真玩起来就能感受到其中的竞争元素，也就是要杀个 你死我活、不留情面。尽管有些阵营一旦玩起来，几乎就赢不了，但可以想尽办法让原本要赢的人没法赢，简称搅屎棍。这一刻，游戏又变回了 人情世故 的样子。

那我推荐这款桌游吗？如果你喜欢玩德式桌游，也有乐意玩德式桌游的伙伴们，那可以尝试一下这款游戏。我认为玩这款游戏比较重要的是 是否在意刻意对抗，因为这款游戏有许多要求玩家们刻意攻击彼此的设计，不像部分德式桌游竞争意识没那么激烈。这游戏几乎很难和平地玩下去。

如果你是一个不喜欢和真人起冲突的玩家，我不是很推荐，只能说可以试试。因为 Steam 版本的 茂林源记 有人机模式，实体版则有机器人扩展（就是要花更多的钱）。

我还为这款游戏写过一个 Steam 评测：

优点
给没玩过 茂林源记 的玩家：这款游戏的原身是 非对称战争桌游，特色是每个阵营的玩法都很不一样。
给玩过一点线下桌游的玩家：相比起游戏线下那一大本规则书，数字版有个好处是它自己会帮你算规则。萌新想入坑的话从数字版开始会轻松很多，并且数字版有教程关。只是数字版玩多了再去玩线下桌游容易出现村规的问题。
美术风格很香：画面看着挺舒服的，3D 小动物模型也挺有特色。不过某些 DLC 里的模型很敷衍。
BGM 很赞，我线下玩桌游的时候都时不时拿出来当背景音。
单机玩的情况下数字版提供了挑战关和人机局。就是人机实力很不稳定，尤其是人机飞鹰，你赢了的时候它可能都已经把所有的领袖动乱了一遍、10 分都没有。
缺点
给没玩过 茂林源记 的玩家：这游戏本身是 King Maker 类游戏，也就是分少的人可以因为「反正自己也赢不了，但又不想让你赢，还不如让另一个人赢」的想法，而完全投入在帮助其他阵营导致原本可以赢的你大输特输的游戏。游戏的阵营强度是不一致的，有些阵营只要你选择去玩、你之后就一定要坐牢。
游戏大厅设计简直是上古世纪的产物，社交功能除了一个加好友，就只有屏蔽别人以及在大厅里喊话摇人。有时候玩线上还会碰到开局就跑的奇葩，在同步局里你要白白等六分钟才能等到这个人被机器人托管。
汉化做的特别特别烂，尤其是越来越新的 DLC。二扩 2023 年出的，游戏规则里干脆显示的英文；三扩 2025 年年初出的，你能看到老鼠的翻译一会儿是百人团一会儿是群鼠。
又是三扩，模型和动作肉眼可见的敷衍。谁小动物晕倒是睁着眼睛盯着前方好似要入党一样晕啊。真就是随便糊弄一下，影响了整体的游戏品质。
给萌新的建议
先学会怎么玩猫，之后再慢慢学习游玩其他阵营。猫猫是最适合新人学习这款游戏的基础规则的阵营，不要因为听说猫猫弱就嫌弃猫猫。当你觉得初始四个阵营都多多少少玩明白了再考虑是否要购入 DLC。
线上开房间要选「同步」（SYNC），加别人房间时也要认准同步。同步模式下你一个回合是三分钟，三分钟过了机器人会暂时托管你。如果机器人已经托管了你一次，第二次托管就是永久托管；非同步模式是一个回合三天。
这款游戏的目的永远都是得分。要保证自己能得分的情况下再去阻碍别人得分，除非比分差太大了。

我个人不是一位那么喜欢对抗的玩家，尤其是会和其他人产生冲突的游戏我都不是很爱玩。比如 MOBA 类我都不爱玩，因为我觉得我会和队友起矛盾（毕竟游戏里也就 10 个人，五五分组大家分工都明确），再就是我技术很差；吃鸡类则还好，我只跟朋友联机玩，并且几乎不会和敌人有任何互动，击败敌人或者被敌人击败都没有什么怨言。我后面开始慢慢放弃 茂林源记 就是因为这个：有时会遇到莫名其妙的玩家、在聊天室内散发恶意，十分毁体验。

演讲

我这个学期有节公开演讲课，竟然是我这个专业的必修课，很是无语。第二场演讲是关于 信息性演讲，也就是向听众传达特定信息或者知识。演讲结束回家后和室友吵了一架，一肚子的事情无法分享出来，只好一边淋浴一边对着手机录音。我用的是摩托罗拉手机自带的 Moto Note，貌似这也可以被称之为「说客」？结果期间我发现，我用「说」来表达想法很吃力，会迟钝和卡壳。看来我还是需要培养「说」的能力。洗完后才发现手机录到一分钟便自动熄屏了，连带着 Moto Note 一起被关闭。也就是说，我一个人在卫浴里自言自语了不知道多久！

室友在卫浴间旁边的厨房做饭，也听到了我的自言自语。她说让她想起了 模拟人生 4 里她捏的一个带有「古怪」特征的角色：平日也会自言自语，但是游戏会贴心地标记成「在和朋友聊天」。

说回那天的演讲，我本来是非常焦虑的，以至于一周前我一直处于「脑子无法静下来」的状态。之后看到了同学们带的笔记卡比我的还厚，我便慢慢冷静了下来。过去我从订阅的博客那边看到了一个句子，让我很喜欢：比较是偷走幸福的小偷（后面得知是西奥多・罗斯福说的）；现在我要加一句：当它往下比的时候，就成了幸福的快递员，哈哈。

部分同学们想了些我觉得很有意思的主题，例如会发光的生物、创伤对人类大脑的影响、政治娱乐化等。但有一部分主题就让我感觉很无聊了：这里的大家都在说，好似不说就是一种「不正确」。至于是什么主题，我或许会在未来扩展说说吧。

总之，我的演讲是关于「离开家庭对成年子女的影响」。具体的演讲内容我会在未来以文章的形式发布出来~ 现在专心于「我在演讲」这件事：因为太过于焦虑「演讲」这件事本身，在实际的演讲中我完全没有关心台下观众可能对我投来的眼光或者持有的想法，反而很快速和流畅地讲完了。做这类我不擅长的事情，我会倾向于玩起「角色扮演」，也就是想象别人会怎么做、自己跟着效仿。这应该是解离的一种？可悲的是，我在「扮演」一个我行我素、能够活跃气氛的角色时，我对着教授做了个鬼脸，对方没能瞬间 get 到，我也没能化解接下来的尴尬气氛。我都不知道我在做什么！

朋友的信用卡被盗刷

我的一位朋友的信用卡不知为何被盗刷了，她立即找了银行换了新卡、寄回自己在纽约市的家。结果这张新卡还没到家的信箱里就被偷了，被盗窃者在当地的某个工厂里刷走了六千美元。当时朋友还在很远的大学里上课，突然看到银行给自己发短信、询问这笔交易是不是她弄的，整个人都不好了。更悲剧的是，她明明回复了「NO」，钱还是被刷走了。这让我和她都怀疑，这种确认短信的存在意义是什么？

继续说，朋友之后打电话给银行要索赔。银行先是在内部调查了不知道多少天，调查结束后拒绝了她的要求。因为这一阶段的「要索赔」不会提供任何证据，也没有任何声明，银行也不愿意直接给她六千美元。她询问我接下来该怎么办好，我让她先在 FTC（Federal Trade Commission，联邦贸易委员会）网站上报告自己的信息被盗、信用卡也被盗刷。这一步是为了拿到《FTC 身份盗窃宣誓书》，好去警察局报案。有了警方报告的副本后，就可以再去银行上诉了。

这听上去好似是个还可以的计划，但是万万没想到，数周前 Perplexity 给我发送的「联邦政府因没有筹资而罢工」这一新闻，以另一种方式重新回到我的脑内：FTC 的网站也罢工啦！我只能叫朋友直接去找当地警局，但她好像并没有听进去、次日直接跑去了当地银行上诉。这也不是不行，问题是这个环节里银行可能会要很多证据，比如当时不在纽约市的证据。她压根没有做任何准备，只能在那里手写了一个声明，说自己当时不在纽约市、也在短信里回复了「NO」。

让我有些气不过的是，我前一天还跟她解释了一遍她要去找谁、做什么，结果她第二天什么都没有地跑去了银行，在群里哭诉说没有文档。我问她什么文档，她说不知道、是银行职员跟她说的。我问她去警局了吗，她又好像第一次听到我提及警局一样，问我为什么要去警局、去当地的警局吗、要打 311 吗…

整体来说，这里出现这种事情就是很麻烦。很多事情都要求你会，虽然从某个角度来看，也是强迫你独立、是一种好事。但我讨厌这样，很烦哎，有些事情我就不能从最开始就避免发生吗？所以我的态度还是「讨厌」。

有意思的顾客们

做服务业很容易碰到有意思的顾客，这个月一些我印象深刻的：

两个学生，买一个东西 6.26 美元，甲求着乙帮她付。乙起先说可以付 6 块，在甲的万般请求下帮付了 6.20 美元，甲则刷卡支付了剩余的 6 美分。后面甲还想买东西，老板看她没零钱，给她抹了零。
有一位看上去就有点问题的男孩。他作为孩子脸、长得很高，不停地走来走去，还询问了我数个问题：「要多久啊？这么多单的话，我可以跟后面的人说他们要等一会儿吗？」
万圣节的那天，店里直接走进来一个黑人把小费罐里的硬币拿走了。虽然也不算「顾客」啦……
我当时看着他一直伸手掏，脑海里想着：
- 「罐里都是硬币，没多少钱，罐子本身还很深，他这样一直掏是因为『已经走进来了，必须得拿一把走，否则会很尴尬』吗」
- 「这个社会好野蛮，有人光明正大拿东西都没有人会阻止。就算我要阻止，他也会一拳打爆我的鼻梁，然后逃之夭夭、就算被抓了也没有钱赔我吧。这个社会就是因为最开始有人放纵了恶人，才会慢慢发展成这样的」。
同样是万圣节，一个钉子头凶狠地走了进来，给我展示了一张纸，上面写着他已经过了要糖的年纪，但他可以为了自己的弟弟妹妹要糖。我可以选择给他糖，或者让他去做恶作剧。值得难过的是，他来的太晚了，糖果早在下午就被小孩子们拿光了。

楼下老头

一天晚上我在玩 模拟人生 4，室友在一边逗猫。不知道是猫的跳跃声太大还是什么，触动了楼下老头的神经，他朝着天花板捶了数下。因为之前物管找我们打过招呼，说这个人很奇怪，是整栋楼里唯一一个会频繁举报楼上声音吵的人，并且态度奇差无比、很凶很急躁。我们搬进来后一直都是小心翼翼的，后面住久了差不多知道了他的愤怒阈值，例如猫的跳跃声就不会吵到他。这次反而吵到了、让我很意外。

之后室友去把吸尘器从我的桌子旁挪动到厨房，却没有料到插头一直插在插排上，导致电线绊倒了桌子上的书、连带着吸尘器一起倒了下去。楼下老头先是对天花板砸了十几下，接着打开自己的门跑了出来，对着走廊的墙还是门砸了几下，然后摔门回屋去了。

我只能说，虽然大晚上我们还在活跃并且导致这些声音都是我们的不对，但是他的处理方式很糟糕，只能让我们感到非常害怕，生怕他接下来跑上楼砸我们的门（他过去确实对着上一家住户做过）。

去香港交换的校友

我去见了一位去香港做了一年交换生的校友。他这一年在亚洲的各个国家旅游玩耍。虽然只有一年，但觉得他离开了很久。不过不得不提，他的生活习惯实在是糟糕。作为一个刻板印象里的美国青年，他有喝酒、抽「叶子」、玩女人的习惯，在香港没少去夜店喝个烂醉、跟很多女人有过一夜情。

校友告诉我，这期间他喝酒还被下过药，一觉醒来发现自己赤身裸体在一个陌生女人的房间里。对方直接坐到他身上，要求他支付自己一千美元。他虽然看起来傻傻的，但还是跑了，一千美元也没到对方手里。回到美国后他发现对方还给自己发过邮件，威胁说如果不交就找黑帮弄他。

我对这个人的看法只能说很复杂……

书影音

书籍

我这个月没有怎么阅读书籍。惭愧。不过我可以简单说说我现在持有的书籍。

我两三四年前（实在是忘了具体时间）买了《阿特拉斯耸耸肩》这套书，包含了它的三部曲。不得不说，这一整套书真的很厚，我觉得只需要拿着一本就可以到处抡人脑袋。内容所提供的信息量也很大，以至于我后悔刚开始阅读的时候没能记笔记：里面的人物实在是太多啦！我现在零零散散地读到了第三部曲。

和室友同居后我们的书架也合并了，她的纸质书要比我的多得多。像余华的《活着》也是我从她那边读来的。

影视

这个月和室友重温了《Happy Sugar Life》。动画在播出时我还是个初中生，因为对题材比较感兴趣，期间还追了漫画连载。现在再来看这个动画，感觉节奏很不错、不拖沓。我在漫画完结后就再也没有关注过该作品，没想到作者之后还出了第 11 卷，其中最重要的是讲到了女主之一盐长大后的样子。

音乐

这个月初我没有继续听 YouTube Music 为我在年初时创建的 Recap 播放列表，而是按照它的推荐算法、听了一些它推荐给我的专辑和单曲。其中最让我印象深刻的便是 温室杂草 这支乐队。他们 2021 年发布的单曲《春天有脚》非常好听，很赞。

一起离开吧~ 一起离开吧~

另一首我比较喜欢的单曲是《快乐的形状》。我很喜欢主唱呼出「快乐」的时候。

傻子与白痴 这支乐队在 2019 年发布的专辑《夜长梦少》我也因推荐去听了。我认为该乐队的音乐风格不是我喜欢的那种，但是我很喜欢他们在该专辑里的一处设计。第七首《Taxi Radio》仅有一分钟，说是「歌曲」很奇怪，它更像是过渡段：一位出租车司机接了几个客人，问他们是不是玩乐队的。客人好似有些尴尬，一个接一个地说「是啊，算是吧」。背景里的电台主持人介绍着一支正在崛起的乐队 —— 傻子与白痴，并播放了该专辑的第八首《美好前程》。

我还听了 伤心欲绝 的专辑《逊到简直是个艺术品》。不得不说，这些乐队的取名风格实在是艺术，我很喜欢。

博客

该文章分类

「想法在 YYXX 迭代」可能会类似于月刊，但没有月刊那么正式。为了简单称呼，以下还是称其为月刊。

这里的 YY 指的是年份，不过是用天干地支的写法，例如二〇二五年叫作乙巳；XX 用的也是中国较为传统的写法。例如九月就是菊月，合在一起叫作「想法在乙巳菊月迭代」。

我之前给室友看了一些我的日记，她以为我写的「二〇二五年」是出自于日本的年份书写格式。其实这个〇是小写的「零」。这很有意思，因为我们在日常生活中几乎见不到〇，但是其他数字用的都是小写的（如一二三，大写的话则是壹贰叁）。我想起小学的时候，语文老师教过我们如何写大写的数字，以及如何写支票。

说回月刊，我打算在其中添加我这个月看过的、感受到的、学到的东西。例如我这个月读的书我就可以写在里面，讲讲我的想法；读过的技术文章或者写项目的时候学到的内容也可以写在月刊内；日记片段也可以取一些出来，尤其是那些体量不够我写一篇文章，但是有意思到我想要去分享的片段。我也想要添加我最近听的歌、专辑，应该也会很有意思。

不写周刊的原因是我认为我没有那个精力、时间去每周写个周刊，万一我这周什么都没做怎么办？但是一个月就足够我去分享些内容。我不打算准时发布月刊，但还是尽量在一个月的上旬发布吧。

Annie 的博客

一次意外，我发现了该博客网站，并让我感觉很有意思。不只是站主写的文章很幽默，她的网站设计也很有趣。博客网站里有个很常见的页面，是「友链」，而 Annie 很机智地将其设计成了 Guestbook（访客留言簿）。你可以在里面留下一条留言、画一张画，然后写下你的名字和网站链接。

我仿照她的头像简单画了一只猫，并写上了「BE COOL」。目前这条留言应该是还在审核中。

说回博客文章，我可以看出她是一位很风趣的人。很多文章都采用了夸张、幽默、讽刺的语言。例如十月一日发布的 Two small UI things that might not bother me if I were a completely different person，就狠狠地批评了她发现的两个微小但令人恼火的用户界面设计问题。不需要会读英语，只需要看她贴上的图片和无处不在的大写单词便能看出她有多么地生气，哈哈！

博客集合平台

我从一个订阅的博客那儿听说了博友圈，让我觉得很有意思，可以通过这类平台看到其他博客站主在写什么文章、都是什么样的人在做博客站主。我过去有个刻板印象，觉得博客站主都是程序员。实际上，有许多没有接触过计算机相关工作的人也在做站主。我也看到了开往，让我觉得第一个想到这类东西的人真是个天才：我可以从一个博客网站「开」到另一个博客网站，就像大家的博客网站真的都是一个个独立的小岛一样。就是有时候目的地是有问题的站点，很容易出戏。

我只加入过中国独立博客列表，还是我很久之前加入的。虽然我觉得这些平台都非常有意思，但我暂且应该是不会考虑加入的。主要原因有二：有内容监管，以及让别人在一众文章里看到我的笔记什么的很奇怪哎…… 至于友链接力类的项目，我只是不知道该在首页的哪里添加这些链接和按钮。现在的首页菜单实在是太乱、太杂了。

职场与创业观察

天使 vs 恶魔的管理风格

兼职的店里有两个「头儿」，一个是「天使」，一个是「恶魔」。前者我会在文章里称呼为「经理」，后者则会称呼为「老板」。但他们是不是真的经理和老板呢？我就不知道了。他俩对员工的要求是一个在天、一个在地。经理总是担心员工做不好，觉得大家都是孩子，基本上不会训斥员工，甚至巴不得员工不去做、他来做。老板则希望员工什么都能做、都得做好，必要的时候会训斥员工。如果要培训出一个能用的员工，自然是交给老板培训最好。但老板也不是什么时候都有空，就会把包袱丢给经理。结果便是经理培训过后的员工，没有几个是可以入老板眼的。

「事精」的定义

这个月有两位新人来培训，其中有一位没想到竟是过去一次兼职的同事。因为本身就有奶茶店工作的经验，她学起来很快，不过老板的要求「道高一尺」。另一位则是由经理培训，培训结束后跟着老板做了两天就差点被炒鱿鱼。你们可以猜猜看，最终谁留了下来？

两个都被炒掉了！

前者被炒的理由较有意思：老板认为她是个「事精」。又或者说，不符合店铺氛围。

对于这类小型服务业而言，店铺氛围是老板权威和管理风格的直接体现。员工无论主观是否愿意，都会受到这种氛围的影响而自动调整行为。在 10 人以下的小团队里，单个成员的态度和行为方式对整体氛围影响极大。一个「会搞事」的员工就足以改变整个团队的互动模式。

不过我还是很好奇，对方到底「事精」在哪儿？

创业宣传策略

在营销至上的氛围中，我的一位创业者朋友也陷入了资源错配的怪圈。他的项目还未正式启动，但团队的所有人都开通了企业邮箱，一个月就要花掉不少钱。

他认为团队里的多数人是做营销的，需要出头露面，企业邮箱因此是必需的。但是开支对于初创公司而言很大是真的，为此他想要削减技术人员的工具预算。

我的第一反应是比较生气。同样作为技术人员，为什么这些人就要因为待在后面、不被人看到，就要把预算让给一些实际产出都不理想的人呢？

我不是觉得营销没必要，事实上，我认为营销很有必要，因为没有什么产品是可以自销的。但是营销得有效，预算也得用在对的地方上。将「看起来像是在创业」的活动误认为是创业本身，可是毁灭性的想法！

技术学习与实践

Webmention

是的，现在这个博客网站支持 Webmention 了！这是 IndieWeb 的核心协议之一，想要详细了解我是如何做到的，可以看这篇文章。目前我还在缓慢改进 Webmention 的显示方式，十分感谢 Spike 在这期间主动联系我、帮助了我许多~

然后我发现，开发 Hexo 的插件的话一定要在文件顶部写上：

/* global hexo */

测试期间发现了 Hexo 实例未定义的错误。找了很久才发现是这行忘记加。

去中心化

阅读博客时我学到了一个新东西：ActivityPub。我觉得去中心化社交平台是一个很有意思的概念，不过我现在依然没有搞明白其中的原理。到底是怎么做到的？只用客户端、不用服务端就可以互相发送数据、存储数据？后面了解了一下得知，并不是完全的没有服务器，而是没有了中间的服务器。比方说 Instagram，用户上传的内容都是从客户端传输到 Instagram 自己的服务器，而去中心化是去掉了这个中间的封闭服务器，改用用户自己搭建的服务器，通信则需要依靠特定的协议。ActivityPub 便是这样的一个协议。

我想到过去我捣鼓过的 Nostr 也是这样吧，用户可以在一种叫做 Relay 的服务器上上传内容。去中心化的好处是我们上传的内容不会被这些封闭的公司管控，坏处则是展示上传的内容时不一定齐全，并且要特意折腾一番、迁移时也麻烦。如果是完全的纯客户端，那就是 P2P 了，我还没折腾过。

我认为很多时候人际关系在社交平台上的分布就会决定我们使用什么平台。我还在使用 Instagram、推特（我还是抗拒叫它 X……）、Threads 和脸书等平台，主要还是因为我的朋友都在上面、我要分享我的生活给他们，绝对不是因为我有多么喜欢这些平台给我带来的流量。我的账户几乎都是私密的，流量什么的都无所谓，我乱发我开心就好，我在 Instagram 上还有个专门的分类存放我收藏的钢笔美照~ 我写博客也是这样的心态。我虽然会把它的链接放在我社交平台账户的个人资料上，但我肯定不会期待我的校友们会点进去、看到全都是中文的文章然后特意每一篇都用翻译工具读过去。很多人对于博客的想法还是，哇哦酷，然后再也不会打开。唉…

10x 工程师 vs -10x 工程师

在团队中，「10x 工程师」代表极高产能和影响力的人才；相对地，「-10x 工程师」则是以拖慢团队效率、增加内耗为特征的反面角色。他们的典型特征是：

制造大量无效产出：例如幻灯片、图表、报告等形式主义成果，却无法交付可运行的产品。
追求优雅胜过实用：花费大量时间在架构设计或代码风格打磨上，却忽视最终交付或快速迭代的需求。
阻塞决策流程：反对「一锤定音」的决策方式，通过反复讨论、持续征求意见拖延进度。
冗长且泛滥的沟通：在群组或邮件中发送长消息，要求团队成员广泛参与无意义的讨论。
代码与脚本难以维护：编写晦涩难懂、仅自己能看懂的脚本或程序，没有文档；构建和测试流程非常缓慢。
滥用测试与依赖：写大量毫无意义的测试用例；引入需要单独学习且维护成本高的第三方库。
浪费团队智力：将团队困在复杂而收益不明的项目上，让其他工程师也陷入无产出的深坑。
误导管理层：低估项目难度，夸大可行性，最终导致进度大幅延迟或彻底失败。
复制「负能量」人才：倾向招募同样低效的工程师，进一步拖累团队。

《把脚注踢出文章吧！》

我有订阅一个英文的 Feed，里面收录了一些 JavaScript 相关的技术文章，例如这次我翻到的 Importing vs fetching JSON。不过让我引起兴趣的不是这篇文章，而是文章作者 Jake Archibald 在七月份写的 Give footnotes the boot。

在许多文章里，当作者想要对一个话题或者术语进行补充的话，都会在对应的词汇旁添加一个小数字，然后将补充说明放在页面的最底部。Jake 认为这样的设计很糟糕，因为它会迫使读者做出选择：要不然跳过脚注保持阅读流畅，或者中断主线去探索「支线」。这种体验被他描述成是一种「死胡同式的冒险书」，读者最终还是得回到主线来。同时他提到，脚注字体通常被设计的很小，阅读体验很差，而这样的做法竟是写作界的传统。

而网页没有「页面」这个概念，脚注通常被放在文末，需要读者滚动查找。如果页面有长评论区或者页脚，脚注会更难被定位。虽然可以用超链接跳转，但读者依然需要手动寻找对应的内容；返回主文后，读者又会迷失在文字中。Jake 就此提出了多个解决方案：

使用和 CSS anchor 实现无 JS 的脚注弹窗。虽然技术上可行，但他依然认为这是糟糕的体验，原因有二：
1. 链接文本如 1、7 等毫无语义，点击区域又极小。
2. superscript 存在可访问性问题。
放弃脚注，直接使用括号吧！毕竟「脚注是印刷时代的残留 hack，在网页平台上继续使用脚注是『愚蠢的延续』」（这句话不是我说的）。不过仅适用于简短的补充内容，需要避免使用嵌套括号。
使用
，语义明确，视觉独立，适合中等长度补充内容。
使用
折叠内容，读者可选择展开，适合较长补充信息。

Jake 也强调，如果内容真的不重要，就别写；如何值得一读，就放在上下文中。

该文章的评论区内也有人认为，Jake 提出的替代方案「太打断阅读」。Jake 反驳：阅读本就包含跳过不相关内容的行为。与其优化给「不感兴趣的读者」，不如提升整体语义与可读性。

自然也有一些特殊情况：

Wikipedia 的脚注就是仅用于引用的，并且用户的习惯早已建立，属于例外。
如果内容需要打印，可以用媒体查询优化打印体验。
媒体查询是一种 CSS 技术，可以根据不同的设备类型或输出方式（例如屏幕、打印机）应用不同的样式。当用户选择打印网页时，浏览器会使用 @media print 规则下的样式，而不是屏幕显示的样式。
你可以在 @media print 中：
- 隐藏不必要的元素（如导航栏、评论区）
- 调整字体大小、行距、颜色（通常改为黑白）
- 展开折叠内容（如
  标签）
- 将脚注或引用内容重新排版为适合纸质阅读的格式

我个人没有写脚注的习惯，不过我过去会用 Markdown 的引用块来补充内容。这种行为不依赖编号或者跳转，因为内容直接可见，更像是「作者旁注」而非「脚注」。引用块通常也是缩进或变色的（在我的博客主题里，它两者皆是），会在视觉上形成轻微分割，便于读者跳过。根据 Jake 的说法，应该是类似于

的做法。

但是直接使用引用块，在语义上还是偏了，只能说可以接受。因为引用块的用途终究还是「引述他人观点、文献或外部内容」。最好还是自定义语法标记，然后让 Hexo 转换成

或者

。

翻阅一些订阅的博客网站时，我也发现有站主实现了全屏旁注。我个人比较好奇，这类旁注对于部分较为特殊的设备来看是什么样的？

《 `NaN`：那个不是数字的「数字」》

我在 Hacker News 上找到了这篇文章：NaN, the not-a-number number that isn't NaN - Piccalilli。作者 Mat "Wilto" Marquis 指出 NaN 只要出现在算术表达式中，结果永远都会是 NaN；任何使用 NaN 作为操作数的比较也都会返回 false。奇怪的是，当你写 NaN == NaN 或者 NaN === NaN 时，结果却是 false。Mat 解释，这是因为 NaN 是一个数字，尽管它的全称是 Not-a-Number。这听上去像是自相矛盾，但其实背后的设计逻辑很合理：

JavaScript 使用 IEEE 754 标准来表示数字，包括整数和浮点数。在这个标准里，NaN 是一种合法的数值类型，用于表示「无法表示的数值结果」，比如：
- 0 除以 0
- 数字与非数字相乘
- 对负数开平方（在部分语言中）
因此 NaN 是一种「数值错误状态」，而不是一个非数值类型。
为了让错误状态在数值计算中传播，NaN 必须表现得像一个数字。如果 NaN 不是数字类型，它就无法参与算术运算，也无法在表达式中自然传播错误。
NaN 的设计目的是在数值计算中标记错误，而不是抛出异常。它是一种「哨兵值」，表示「这里出了问题，但是程序可以继续运行」。这比抛出错误更灵活，尤其是在数据处理、科学计算或者图形编程里。
为了防止错误值被误认为是有效数值，NaN 是 JavaScript 中唯一一个不等于自身的值。你必须使用 Number.isNaN() 或 isNaN() 来检测它，而不是用等号比较。

社交与人际关系思考

吃免费的饭，骂做饭的厨子

对于「为什么人们更倾向于攻击贡献者」这一问题的思考。

阶段性朋友

人与人之间的关系，远没有想象中那般永恒，而是会随着个人成长、环境变迁逐渐发生裂变与疏离。所谓「阶段性朋友」，指的是那些在生命某个阶段因为特定经历或背景走到一起、彼此陪伴、共享过一段时光的朋友。但随着时间推移，彼此的世界观、生活轨迹乃至性格边界产生变化，这段关系逐渐失去了原有的连结，甚至在某个节点彻底失效。

认识的年头再长，曾经再亲密都不能保证关系始终如一。人会成长，也会走散，有的人是陪你一阵子的，有的人才能陪你一辈子。

我认为这并不等同于背叛或者消耗，这是一场彼此陪伴和成长的必经过程。感谢那段时光的相遇和陪伴，也坦然面对最终的分离。接受关系的自然流转，顺势而为。成长本就是一场不断筛选、不断更新关系的过程。

你只是在怪她没有选你

近日，一位朋友提起了自己的情感问题。不过我没有很深入去写到底发生了什么，毕竟把别人的隐私拿出来写还是很不好的。这篇文章里我更多是借用了他的一些故事，去写我对「你只是在怪她没有选你」的部分看法。

性暴力的苗头是加害者

原本是公开演讲课的作业，但因为感觉很有缘，所以深入思考后的产物。

教育与学习

番茄钟的个人想法

一次，一位校友询问我平日都是如何学习的。我说我会学到累为止。他立马开始批评我，并提到了他的一位朋友的学习方式，认为我应该向他学习。而那位朋友的学习方式，则是番茄钟学习法。

我觉得这位校友人很烦。这已经不是第一次 他因为一件自己完全不熟悉的事情而「说教」我 了。我也不喜欢番茄钟，但我也不否认它的可用性，只是它强制的时间切割方式会和我的思考节奏产生冲突。

番茄钟学习法：要求你每完成一个 25 分钟的专注周期，就必须暂停 5 分钟。

我习惯深度沉浸地做事。如果在我思路连贯的时候突然中断我，我会十分愤怒，并且之后也很难迅速回到同样的专注状态。

番茄钟本身是一套高度结构化、外在强制的时间管理体系。它规定了固定的工作与休息节奏。对于依赖自我判断来安排学习节奏的人来说，使用番茄钟容易产生被工具主导的无力感。并且对于需要更长的连续思考才能进入心流状态的人来说，当休息周期早于心流完成点时，反而会打乱最佳效率，还不如自然而然地寻找暂停时机。

孩童和恐怖游戏

和妹妹玩多人恐怖游戏的时候一直在脑海里盘踞着的想法。在我和妹妹一样大的年纪，如果有成年人这么想，我绝对会觉得他们很烦吧…… 最近我在网上经常看到一类言论，觉得很贴切我现在的状态：到了两边（长辈和孩子）都能理解的年纪。

日记片段

该栏块专门放置一些日记片段…… 它们是我的一些还未被深入探索的小想法，一些我觉得有意思的日常…… 或许在未来的哪一天，我会捡起一些详细说说？你感兴趣的话，也可以拿走~

我要发表我对领英这个 app 的想法：无聊透顶。
每次刷都是看高中生进了什么名校、大学生找到了什么实习、应届生找了什么工作。
也没什么办法，这是一个报喜不报忧的平台。

我发现移动端的 Fluent Reader Lite 和桌面端的 Fluent Reader 的区别还挺大：
不能改字体
会自动删除 7-28 天之内的文章
导致我去床上躺着还不能愉快阅读 RSS Feed。我订阅的很多博客都不是一个月一更的。像我自己都可能不会几个月更一次。

我感觉我的生活已经没有了自己的时间了。一段不会被别人打扰的、自己想事情自己可以写下来的时间。我写日记都是选在较特别的时间段：坐车通勤、打工空闲… 就算是在家里，我也要赶项目的进度，更别提很多时候都有学校的作业要写。

我梦到我和家人翻山越岭来到大陆的一个角落，在海里放了个 Hello Kitty 大脸气球，坐在上面想慢慢地飘到北极……

你的大脑只能理解它已知的信息，所以当你选择你想要的未来时，你实际上只是基于过去创造了一个理想化的方案。
如果事情没有按照你希望的方式发展，你就会认为自己失败了，因为你没有创造出你想要的东西。
而实际上，你创造了更好的东西，但它对你的大脑而言是陌生的，所以大脑将其错误地理解为「不好的」。

一个过于在意他人感受和看法的人，是否也是一个极度以自我为中心的人呢？
拼命寻求认可是一种以自我为中心的表现。
之所以在意他人的看法，是因为希望世界以自己想要的方式运行。
课题分离：
没有比主观感受更大的事情。
课题 = 个体的主观感受 + 选择
人际关系的烦恼：
心甘情愿让他人干涉自己的课题
企图强行干涉他人的课题

反叛精神不等于叛逆。
叛逆青年无法跳脱出赏罚机制，只是因为无法因赞赏而得到他人的关注，因此走向极端，做叛逆的行为来获得关注。
反叛精神则是跳脱出赏罚机制，不做会得到他人表扬的事，而是做自己想做的事。

我今天ゴロゴロ（gorogoro，无所事事的意思）了一整天。晚上出去吃了快乐小羊，不是很惊艳。我感觉现在的火锅都不惊艳。

我有一个想要订阅的博客网站，但是不知道为什么，FreshRSS 无法和它成功进行 SSL 握手，说是版本不对。我在容器内改了许多 TLS 版本来 curl，但都不行，只好收藏在我的标签页里时不时看一眼。

我在学习双拼。我用的是 Gboard 里的小鹤双拼。

双拼好难，暂且搁置。

我放弃了我的鱼缸，里面死掉了太多的虾和螺，我都不知道是怎么做到的，一向杀不干净的羊角螺在里面全部死光。

孩童和恐怖游戏

2025-11-02T05:20:14.000Z

妹妹一直都有在玩 Roblox（罗布乐思）这款游戏，因为她很想和我一起玩，所以我花了一天时间陪她。其中有个游戏叫做 99 Nights at Forest，貌似近期在孩子们之间十分流行。

游戏背景

该游戏的背景发生在一片森林里，人们声称目击到了一头「站着的鹿」，还有四个孩子在里面失踪。警方怎么找都找不到怪物和孩子，只能将其封锁。而玩家有 99 天的时间探索该森林、找出真相。

该游戏的玩法不知为何会让我想起饥荒，玩家刚进入游戏就能看到营火、持有布袋和斧子。砍树可以获取木头、布袋可以装木头，木头又可以生火、扩大可探索范围。除了白天就能看到的动物外，该游戏还有晚上才会出现的鹿人、到一定天数会主动来找你麻烦的邪教徒、我目前还没见过的羊人…… 基地旁还会立着一个寻人启事板，可以根据上面给出的方向来找到失踪的孩子。

恐怖游戏是否适合孩童游玩？

这个游戏的桌面端快捷键设计有些不合理，操作实在是不习惯。但让我更在意的其实是另一个问题：这种恐怖主题的游戏在孩子中如此受欢迎，究竟合不合适？首先，我先说一下我的部分观点：

Roblox 本身就是多人游戏，会火的恐怖游戏也近乎都是多人合作。例如几年前在外国孩子之间很火的 Piggy 就是多人合作逃脱游戏，再到之后的一系列恐怖题材游戏都是多人合作。99 Nights at Forest 也是一样。正是这种集体协作、彼此依赖的机制，让原本单纯的恐怖体验转化为社交刺激与游戏乐趣。
心理学研究提出过 娱乐性恐惧 这个概念，即一种恐惧与愉悦并存的混合情绪体验，而恐惧与愉悦之间是存在着「倒 U 型关系」的。当人们在安全的社交环境中体验恐惧时，恐惧会被转化为积极情绪。
对于已经在上学的孩子而言，恐怖体验是有利的，可以帮助他们学习如何面对恐惧、管理焦虑情绪。前提是恐惧强度必须适中。事实上，从我观察来看，近些年在孩子之间火的恐怖游戏（如 Poppy's Playtime）普遍属于 吉祥物恐怖，其内容更偏向于紧张与刺激，再加上可爱吉祥物所营造的反差，而非真正的血腥或猎奇。这些游戏的恐怖也多数被包裹在任务、收集等系统里。
我认为这个年龄段的孩子就算接触到了一些恐怖概念，例如邪教徒，他们也无法明白这到底是什么、只是将其看成是一种设定。这并不意味着孩子无法感知恐怖，他们只是难以理解背后的抽象含义。如果你在小时候玩过 4399 等平台上的小游戏的话，或许也接触过许多带有血腥、恐怖、猎奇要素的游戏。比方说 jumpaloo!，屡次失败的玩家会遭受血腥的对待、看着代表自己的小动物被搅碎。但是对于当时的孩子而言，「被搅碎」这个行为本身不重要，重要的是「失败了」。因此，他们把这一幕理解为游戏中的失败信号，而不是现实暴力的再现，这正说明儿童在早期阶段对暴力的解读更多停留在规则层面。

那么，孩子到底适合游玩恐怖游戏吗？我的答案：这是一个双刃剑。

是的，恐怖游戏可以帮助孩子们脱敏，但是过量的暴力和血腥内容会导致孩子们的共情能力下降、培养出非黑即白的理念。关键在于剂量和语境：偶尔的卡通暴力可能无害，但如果每天数小时沉浸在「杀戮获得奖励」的游戏循环内呢？

Roblox 的问题

Roblox 也有着自己特有的风险。它其实比起说是一款游戏，更像是一个游戏平台、里面的游戏都是用户生成内容。而这种开放式平台设计虽然鼓励创造，但同时也带来了新的问题：

内容质量不可控。虽然里面多数游戏都是正规的，但是质量低劣、设计不当的游戏也不是没有。突然的 jumpscares（突发惊吓，或称跳杀）就会被我称为是 无营养的恐惧。
多人游戏意味着与陌生人互动。即使游戏本身适当，聊天功能也可能导致孩子们被有心者欺骗、骚扰、仇恨。
- Bloomberg 曾经调查发现，Roblox 上的儿童性侵案件从 2018 年的 13 起激增至 2023 年的 147 起。要知道，Roblox 是全球最大的儿童游戏平台，日活跃用户超 7800 万，其中 40% 是 13 岁以下的儿童，也就是 312 万。这一数据之所以令人担忧，是因为 Roblox 的规模远大于其监管能力。全平台审核员竟然只有 3000 名左右！
- Roblox 有一个叫做 Robux 的货币，类似于 Q 币，可以购买角色装扮和部分游戏内的装备。对于已经有经济能力的大人而言，购买 Robux 根本就不是什么大事。但是对于孩子们而言，该系统会让他们感受到 经济焦虑 或 同伴压力。再者，允许孩子为游戏充值的家庭我个人认为并不多。这就像一些现实的案例：没有经济能力的未成年人被一个有经济能力的成年失败者坑骗肉体。

评估和结语

如何更好地去评估一款游戏适不适合孩子们游玩？我认为可以参考这个框架：

游戏是卡通化还是写实化？
恐怖类型是跳跃惊吓、追逐紧张，还是心理恐怖、存在威胁？
玩家能否通过技能避免威胁，还是只能被动承受？
游戏的叙事框架是单纯的杀戮模拟吗？
孩子多少岁？7 岁以下应完全避免；7-10 岁需严格选择和监督；10 岁以上可适度放宽。
孩子对恐怖书籍、电影的反应如何？是否有持续恐惧史？
独自一人玩还是和朋友一起玩？
陪同孩子玩前 30 分钟至 1 小时，其面部表情、身体语言是什么样的？
游玩后是否出现了睡眠问题、焦虑增加、攻击性言行或回避行为？
游玩后询问孩子哪部分最可怕？这些怪物是否是真实的？如果害怕了怎么办？评估孩子的理解和应对能力。
即时游戏适当，也应限制每周游戏时间，避免过度沉浸。
一定要教育孩子们，如何应对陌生人、保护个人信息、如何举报不正当内容！

那么，完全禁止是否更高效、也更有利于保护孩子？其实未必。对于 Z 世代和 Alpha 世代（前者指代 1997-2012 年出生的人，后者指代 2013 到现在出生的人）来说，这些游戏是社交货币和共同话题。拒绝参与可能导致社交孤立。这意味着完全禁止也有弊处。

适合性是动态的、条件性的，而非静态的、普遍的。所以，与其追问「恐怖游戏是否适合儿童」，不如问「如何让恐怖体验在安全的环境下，为儿童心理成长服务」。

创业宣传策略

2025-11-02T05:02:00.000Z

此文章记录了一些我对于现代年轻人创业，尤其是其宣传策略的观察和想法。

我的一位创业者朋友想要将目标人群定在 Z 世代（指代 1997-2012 年出生的人，也就是现在的「年轻人」）。原因很简单：你是个年轻人，你要赚年轻人的钱。他找来了一位摄影师，拍了许多带有艺术氛围的照片作为宣传，还录制了一些宣传视频。重点在于这些宣传视频。他告诉我，现在能夺得 Z 世代目光的宣传视频必须是夸张、搞笑、刺激的。

作为例子，我被迫看了其他初创公司的宣传视频。它们都是在 Instagram 上投递短视频、具有着年轻人特有的欢快活泼耍宝风格。这些视频和产品没有丝毫关系，更多是创始人同员工们整活：招程序员要招有自闭症的、员工和创始人的关系要亲近到「一起搓澡」…… 这个时候我看到公司名称还没反应过来，看到创始人的名字才意识到他是 Cluely—— 七月份较有话题度的「AI 作弊工具」—— 的 CEO。

Roy 和 Cluely

Roy 是一位辍学的 21 岁男生，干过许多奇奇怪怪的事情，例如靠作弊过了亚马逊的面试，却把作弊方式分享到了 YouTube，导致被亚马逊的员工发现。他因为现在这个 AI 初创公司 Cluely，在外网火了一把，公司也足足融资了 1500 万。我那会儿刷到过有人吐槽他新投放的广告的帖子，结果第二天就在路上看到了这个广告：一个巨大的广告牌上白纸黑字写着「我是 Roy，今年 21 岁，我开了个 AI 初创公司，快来看」。

我不否认，Z 世代购物者确实更信任网红，并且对「夸张、搞笑、刺激」的内容有着天然的亲和力。短视频平台上，60 秒以下的内容拥有最高的参与度，而那些展示真实性、幽默感和参与感的品牌更容易获得青睐。

当然，这是趋势观察，不是对个体的标签。

但这里存在一个危险的逻辑跳跃：理解 Z 世代的偏好，不等于可以用纯粹的表演代替产品价值。

Roy 的故事本身就是现代创业文化的极端标本。他因为开发帮助人们在面试中作弊的工具被名校开除，随后将这场争议本身转化为了病毒式营销的素材，从而获得 1500 万美元融资。他最初的策略就是创建争议，必须要让超过一半的观众讨厌视频，然后制作大量视频、像病毒一样投放出去。

这套玩法的核心在于，用极具话题性的「个人表演」来强行占据公众视野，从而让产品的实际价值在讨论中变得不再重要。当一条信息、一个事件在网络上足够火，各种监管、批评或惩罚措施就很难再对它产生任何影响了。换言之，公众注意力的放大效应还可以让事件本身变成一种护身符。

然而，Roy 也曾承认，这个「作弊工具」被设计出来就是等着被毁灭的，因为公司很快会调整面试流程，吸食原有面试流程的养分的作弊工具很快也会变得无用。

我现在再去看 Cluely，就会发现它已经转型成了面试辅助工具，可以在用户面试前策划好用户要准备什么等。这也让我产生了一个疑问：现在没有了争议，转型后的产品本身能否支撑起 1.2 亿美元的估值？在我看来，其长期价值仍然存疑。

对流量的焦虑

Cluely 只是当前时代、面向年轻人的无数个初创公司的其中一所。我在一次网上冲浪时，看到另一位辍学的年轻人创业。很有意思的是，他的主页里也近乎没有任何产品的内容，更多是尝试获取流量的帖子。

我作为一个无意间刷到帖子的人，无法从他的帖子里得知产品是什么，但是可以看出创始人在想办法「有趣」。我说他是想办法「有趣」而不是直接说他是个有趣的人，是因为我能从他的帖子里感受到他的焦虑，一种为了变得吸引人的焦虑。评论区时不时会出现一些尖锐的声音，差不多都是批评当下年轻人创业、什么都不懂只知道开会和 KPI，没有满腔热血只有歪门邪道。

这里还有一个问题：为了流量，然后呢？要如何变现？大家想看的是你这个产品，还是你努力表演出来的搞笑？

性暴力的苗头是加害者

2025-10-27T21:28:00.000Z

写一门课的作业时，我被要求在一众 TED 演讲里选一个进行分析。我随手一选，选到的是一个双人演讲。更没想到的是，这两个人的身份分别是「强奸者」和「被强奸者」。

《我们的强奸与和解故事》

男演讲者 Tom 是一位澳大利亚人，女演讲者 Thordis 则是冰岛人。在他们还是学生的时候，Tom 来冰岛交换、同 Thordis 交往。一次圣诞舞会，Thordis 喝了朗姆酒，而这一决定成了她这辈子最后悔干的事情：Tom 在 Thordis 喝醉后，像「护花使者」一般送 Thordis 回家，然后在她的卧室床上实施了性侵。Thordis 无法反抗，只能麻木地在脑海里数数 —— 最终数到了 7200 秒。

这次创伤给 Thordis 带来了 PTSD 症状。她经历了长达九年的沉默，25 岁濒临精神崩溃，自我价值被压抑在孤立她与所有关心她的人的重负之下。Tom 则靠心理上的否认「生存」下来。他拒绝将自己的行为定义为强奸，而是说服自己那是性爱。这是一种对现实的回避，因为他一直认为自己是一个来自良好家庭、自认为正派的人。而这样的一个人，怎么可能会性侵别人呢？

2005 年，Thordis 主动给 Tom 写信，直面她所遭受的痛苦。令她震惊的是，Tom 没有否认，反而回信承认了罪行，充满了真诚的悔恨。这标记着长达八年通信的开始。不过 Thordis 最终意识到，文字依然不足以疗愈她，她决定和 Tom 见一面、双方去面对自己一生中最大的痛苦。他们在南非开普敦度过了一周。值得一提的是，南非这个国家通过真相与和解委员会处理了种族隔离的创伤历史。

这一周充满了紧张、痛苦，有时甚至感觉像是失败的尝试。Thordis 曾经多次想要放弃，回到丈夫和儿子的身边。但他们坚持了下来，从头到尾讲述彼此的人生故事。他们遵循严格的诚实原则，分析自己的历史。这种面对面的对话是恢复性司法的一种形式。不同于传统的惩罚性司法，它的核心在于让犯罪者、受害者以及社团成员共同参与，解决因犯罪行为所造成的伤害与冲突。

Thordis 在演讲中强调，仅仅给人们贴上「受害者」和「强奸犯」的标签不足以让我们理解背后的人性，也无法帮助我们理解为什么会发生暴力。这种简化的标签化可能导致去人性化，反而阻碍了对暴力根源的深入理解。Tom 则揭示了男性社会化如何创造了一种危险的性别权力动态：男性被教导他们「应得」女性的身体。这种有毒的男性气质观念是强奸文化的核心特征。

隐身的加害者

现在的新闻标题都喜欢将被害者放在主语的位置，例如「女孩被杀害」。接着我们添加一些细节，变成「女孩在景区内被杀害」。为了让更多人看，我们添加一些会让大众感兴趣的内容：这个女孩是个大学生，那就可以写「19 岁女大学生景区内被杀害」；她被残忍杀害，那为了满足猎奇和刺激，就可以写「19 岁女大学生景区内遭捅多刀身亡」。现在再来看这个标题，你会发现，你对这个加害者一无所知：这个男人因搭讪被拒绝、恼羞成怒，拿起剪刀连捅了被害者和被害者朋友数刀。更为悲惨的是，这个男人被官方强调有精神病史、捅人后还自首，很大可能会从轻处罚。

同样的还有「两女孩店门口喝奶茶被货车压死」。我们为什么要知道「喝奶茶」这个信息？而不是 电动货车卸货时意外失控、造成店铺门口四人受伤，其中两人抢救无效死亡？前者给出的信息，到底有什么用？告诉我们不要在门口喝奶茶、会被货车压死吗？这种报道视角，模糊了事故的责任根源，只留下了对受害者行为的无端指责。

再来一个，「女子熟睡被男友持刀架在脖子上」。这里看似写出了加害者，但是很刻意地模糊了加害者的行为：他可没有在 蓄意谋杀，只是很单纯地把刀架在了女友脖子上哦。

更有甚者，在「男子杀害女友 25 年后落网头发花白」这类标题中，虽然将加害者放在主语，但是很离谱地添加了这些模糊事件性质的描述：「头发花白」、「当年意气风发的小伙」等，无形中给杀人犯披上了一层悲情或沧桑的外衣，仿佛在博取同情。然而，杀人犯就是杀人犯，新闻标题应当报道事实，不应当给任何人套上任何人设。这种行为无疑是对受害者极其家属的二次伤害。

现在的社会，似乎都在关注着受害者：他们是谁？发生了什么？他们感受如何？他们现在怎么样了？ 好像只要受害了，我们的人生就会一直被人监视。而加害者呢？我们知道他们是谁、为什么要害人、现在怎么样了吗？不，我们很多时候都不知道，因为他们在新闻报道里永远都是 隐身的。

标签的局限性

标签化也可以对受害者构成一种无声的暴力。它会创造一个 完美受害者 的模板：他必须是纯洁无瑕、奋力反抗、事后立即报案并痛苦欲绝。任何不符合这个模板的受害者，比方说喝了酒、曾对加害者有好感、反应是僵住而非反抗、没有立即报案等，都会遭受质疑，甚至自我怀疑。最常见的案例便是「她穿的这么少，活该被 xxx」。这会让真实的受害者被排除在「受害者」标签之外，承受二次伤害。

一个 受害者 的标签，也会覆盖掉他所有的其他身份。他原本是一个孩子、一个朋友、一个有喜怒哀乐的人，但 受害者 的标签只会将他生命中最创伤的一刻固定为他唯一的身份标识。这本身就是一种去人性化，他失去了被看作是一个「完整的人」的权利。

我的人生中便出现过这样一位「受害者」。她是一个很棒的朋友、身怀各种才能的学生、年纪轻轻的企业家。她对加害者曾抱有好感，被花言巧语蒙骗，周遭的帮凶们一个个借此规训她，仿佛错的是她。但这无法掩盖她被伤害、错的是那个加害者的事实。受害者是不能被标签化的，因为现实中的伤害往往发生在灰色地带，而僵化的标签会成为加害者及其拥护者颠倒黑白的工具。

同样的，标签化会助长为了达成目的而施行的 工具性暴力，即为了其他目的而伤害他人（不是为了施暴本身，而是为了暴力背后的利益。例如抢劫钱财）。当我们给一个群体贴上「低等」等标签后，就更容易把他们「去人性化」，从而为了自己的利益对他们施加暴力，而不会有道德负担。咦，怎么听上去那么耳熟？

然而，对于另一种认为受害者「活该」的 道德性暴力，施暴者恰恰需要将受害者视为有思想、有行为的「完整的人」，他的暴力才被他自己赋予意义。因为只有对方是一个有思想、有行为的「人」，他的「错误」（比如穿着、拒绝、行为）才具有「道德意义」，才「值得」被惩罚。如果对方只是一个物体，那就无所谓「活该」了。

因此，Tom 的行为无法简单地将其归咎于邪恶，因为它混杂了这两种暴力。既有工具性的一面（为了满足自己的性欲），也有道德性的一面（他认为作为男友，这是他的「权利」）。我们必须通过将他视为一个完整的人，而非怪物，才能够探索导致暴力的复杂因素：他所处的文化是如何让他变成这样的？这是我之后会提到的要点。

标签化还会阻碍对施暴者动机的理解。尤其是性暴力施暴者，他们往往通过否认、最小化和将责任归咎于受害者或外部因素来维持自我形象，例如酒精和性冲动。我们只有通过深入对话和问责，才能打破这些防御机制。

我必须得强调一下，将加害者视为一个人，绝非是为了替他们的罪行开脱，更不意味着要给予丝毫的宽容。上述的事件我也被牵扯其中，并遭受了精神上的折磨。我痛恨这些加害者，认为他们仅为了自己的一私之欲、随意地伤害了他人，并不会受到任何实质性的惩罚。但是，去理解为什么要把他们视为人，与我们内心中应有的愤怒和道德审判并不矛盾。

如果我们只将加害者视为怪物，就等于承认暴力是来自我们无法理解的、外部的邪恶。这会让我们感到安全，这种安全是虚假的，因为怪物是罕见的、异常的。而真相是，暴力往往由看似正常的普通人实施。只有承认加害者是人，我们才能承认暴力的根源存在于我们的人类社会、文化，甚至我们自己可能无意识秉持的观念中。这是解决问题的第一步。同样，将加害者视为人，意味着我们坚信其行为是可以被分析、被归因、从而被预防和阻断的。这是一种直面问题、并相信自己有能力解决的姿态。

有毒男性气质与性别权力

有毒男性气质 将男性定义为必须主导和暴力，将女性视为性对象，并将性视为一场征服游戏。这种社会化过程通过家庭、同伴文化、媒体和更广泛的 父权制 社会结构传播。即使是来自良好家庭、平时表现正面的人，也可能在特定场景下做出极端负面的行为。

回到我上述提到的事件的性暴力加害者，他将自己的性侵行为用花言巧语装饰成双向奔赴的性爱，并认为过去的各类性骚扰行为是普通的求爱，因为他觉得自己比谁都更应得到女方的身体。这个人是怎么变成这样的呢？抛开现在到处传播的大男子主义思想外，还有周遭恐怖的大男子主义群体。在女方后续意识到自己被强奸时，群体里甚至还有这个男性的朋友向她传达男性沙文主义思想：你当时没有好好拒绝他，你活该被强奸。更不用提在他「追求」女方时，这帮「朋友」对女方施压的各类压力，好似在告诉她男方才是受害者，一切都是因为女方没能接受他的「求爱」。

这种群体的可怕不只是因为他们热爱压迫女性，他们对于男性也照样压迫。他们默认女性都是物品，可以被群体内部的人分享，因此没少出现过多个人同时喜欢一个人，然后私下分享「追求」成果。如果被拒绝，那就群众私下辱骂该女性，好让他们觉得自己「雄伟」，「像个男人」。不和他们共享同个思想的男性，会被他们鄙视、视为懦夫，换句话说便是，不是个男人。

我过去提及到 群体极化 这个现象。不只是网络世界，现实生活也会发生。实际上，只要是个稍微封闭的环境就可以造成该现象。内部群体会崇拜一个理念，而为了证明自己「忠诚」，不断去挑战极限、做出最极端的事情。这种大男子主义群体也是如此，只有够粗鲁、暴力才是男人，而这条标准又会因为成员的各种出格行为、被无限拔高。

一个容易被忽视的事实是，这种气质和一个人的其他品行是近乎不相关的。一个会家暴的人，他可以是一个最失败的混蛋，也可以是一个被人尊敬的公司老总。例如我刚才举例用的，在我的现实生活中所出现的这个群体的成员中，既有年轻有为的人，也有 Incel（非自愿单身。此处的用法是偏贬义的，类似于「屌丝」、「鲁蛇」等）。

而那个实施了性侵的人，不仅在家里是个被宠爱的孩子，在外还是个被同龄人崇拜、学业和专业方面做的都很好的人。但被他伤害过的人都知道，他不过是 一个平庸宛如尘土，心却比天大的可怜虫。在女方意识到自己被伤害后，立即问责了他。这个总是幻想自己是主导者、瞧不起女性的人，因为被女方问责，很快就变得像他常说的女人一样，哭得不能自我。

他所崩溃的，不仅是劣行的败露，更是那个由有毒男性气质精心构筑的、充满力量感的自我形象。先前说过，女方是一位聪慧的人。虽然在感情上被蒙骗，但她一旦想明白了，其他人的诡计便一个都使不出来。她深入了解后察觉到，这个男人连做她的朋友都不够格，因为他既无法提供任何情绪价值，也没有可以被利用的地方，甚至经常惹她生气。当我们看到这样一个 被宠爱的孩子 和 平庸的可怜虫 并存的双面体，我们自然无法简单称呼他为怪物。

正因如此，Tom 和 Thordis 的和解之路才显得尤为重要：并非为了原谅，而是为了夺回被暴力剥夺的解释权。Thordis 主动写信、要求见面，是夺回。她迫使 Tom 必须在她面前，承认那是「强奸」而不是「性爱」。我的朋友问责那个加害者，是夺回。她当面戳穿了他的谎言与伪装，让他建构的虚假自我瞬间崩塌。

这个过程的核心，是验证自己的真实感受，确认「我所经历的就是伤害」，并要求对方和世界承认这一事实。它的首要目标和最终成果，是受害者自我的重建，而不是加害者是否得到宽恕。原谅可以是夺回解释权之后的一个 可能结果，但绝不是夺回行动本身的 前提或目的。

而这，也正是我们社会在面对每一桩暴力事件时，最需要学习的一课：不仅看到受害者的痛苦，更要直视加害者的人生。唯有如此，才能斩断暴力的循环。

你只是在怪她没有选你

2025-10-23T14:36:00.000Z

近日，一位朋友提起了自己的情感问题。简单来说，便是他在正值青春的年纪喜欢上了一位女生，却在这段关系中被这位女生反复推拉，一次次经历快乐的巅峰，又一次次经历痛苦的谷底。他本以为这一切会随着进入新环境而过去，但过去的种种回忆却时常浮现，往事也数次被唤醒。和我的对话中，他提到在网上看到的一句话：你只是在怪她没有选你。

过去为何反复重现

我对他的往事的主观想法，便是他很可悲地被一位缺爱的女性玩弄了。同为女性，还是经历过类似事件的人，我大致能理解她的心态：缺爱的人更倾向于控制追求者的情绪。这种情绪控制，我会称为是在「玩弄」，也就是大家常说的「被玩弄于股掌之间」。她们是蓄意的吗？不一定，但绝非完全无辜。我们都知道戏耍他人在道德上是不好的，但是它所能提供的安全感和「权利」对于缺爱和缺安全感的人而言，是难以抗拒的。

然而对男方而言，这种暧昧关系带来的却是持续的情感困扰与不安全感。他想要和女方在一起、谈恋爱，但摆在他面前的首先是一个身份问题：他们究竟是什么关系？女人和她不喜欢的追求者？单向喜欢的朋友？同学？要知道，在传统观念里，无论是哪种关系，都无法成为他要求女方不恋爱的理由。更进一步说，连「希望她不谈恋爱」这个念头，他都没有立场去拥有。

尽管女方知道男方喜欢自己，她却并未直接拒绝，反而是一边给出暗示性的举动、一边又时不时拉开距离。正是这种模糊不清的态度，使得暧昧与明确拒绝更难应用：你永远无法确定自己到底是以什么样的身份陪伴在心上人身边的。至少对这个朋友来说，他既不敢去问女方的想法，也没有勇气远离她。

他现在的表现，很明显是创伤后应激的闪回与反复回忆。这里可能需要澄清一个常见的误解：很多人以为创伤后应激只有上了战场才能得，但实则不然，创伤近乎遍布我们生活的边边角角。不受控制的侵入性记忆是创伤后应激的特征之一，其中情绪记忆尤为顽固。从神经机制上看，当人们遭受到强烈的情绪冲击，杏仁核会产生大量的高频伽马波活动，让海马体改变其编码方式、提高突触强度、更深更强地存储这一段记忆。如果只是被明确拒绝一次，这种强烈的记忆编码或许只发生一次。然而在他的案例中，关系上的推搡会反复强化这段痛苦的记忆。

面对这样的情感问题，不少人的提议都是「时间会治愈一切」。不得不说，我在经历那件情感问题之前也是这么认为的。然而事实是，时间不仅未能解决问题，反而还会因为长时间不处理、让人埋下了难以察觉的创伤。记忆的存储是多层分布的，当新环境和新恋情出现时，某些旧的记忆仍然存在并可能被特定触发因素激活，比如相似的情绪体验或环境线索。

怪她没有选你

有一个概念叫做拒绝创伤，即人际拒绝激活的大脑区域与身体疼痛激活的区域高度重叠，被拒绝确实会产生类似生理创伤的痛感。在神经系统的层面上来看，被拒绝会被我们的大脑处理为一种伤害。从进化的角度来看，这种反应是有意义的。在原始社会中，被社群拒绝意味着失去获取食物、受到保护和交配求偶的权利，从而很难生存下去。因此，人类的大脑发展出一种早期预警系统，当存在「被踢出群体」的风险时，该系统就会触发尖锐的痛感。

然而，这种疼痛远不止于神经信号，更深层次的是随之而来的自我价值感被削弱。对人类 —— 这种社会性动物 —— 而言，来自他人的接纳本身就是维系自尊的重要来源。社会计量理论正是由此出发，将自尊视为一种「社会温度计」，可以用来衡量我们被群体接纳或被排斥的程度。

长期的拒绝经验，会逐渐侵蚀个体的自我概念。低自尊的人对任何潜在的拒绝线索更为敏感，他们会过度解读他人的行为，把中性信号视为排斥。由此，这样的状态让人陷入一个恶性循环：越害怕被拒绝，就越容易感受到拒绝，从而进一步降低自我价值感。我的朋友正是陷入了这种循环。他不理解，为什么他足够优秀，但是被选的人从来就不是他。他已经在心中种下了一颗名为「根本性的失败」的种子：他想尽一切努力让她看到自己、认可自己，但从来都不够，因为他似乎永远都 不够好。

这里我们要厘清一个逻辑关系，关系的不合适绝不等同于自我的不够好。这是一个我们常说的道理，但真能渗透这句话的人貌似并不多。为了「被选」，许多人会像他一样，陷入疯狂自我提升乃至同辈竞争的状态；或因落选而反复质疑自身。但我们必须认清，一段关系的终结，核心原因只能是「不合适」。

根据他所说，他曾多次以为女方也喜欢自己，因为对方会说一些暗示性的话、送他花和礼物，最后却告诉他：「我不喜欢你，我只是觉得你这样喜欢我很可怜，我想要补偿你」。期望的轰然倒塌必然引致愤恨情绪，这是人之常情：我们在关系中无法得到自己想要的，便会变得沮丧、失望，甚至愤恨。更何况，对方的做法本质上是一种「情感戏耍」。

一段亲密关系的开始，往往都是为了得到一些我们孩童时期没能得到的东西。「你只是在怪她没有选你」，这句话揭示的是他「被选择」的心理需求。这里的核心逻辑可以用三层心理机制来理解：

爱一个人被拒绝后，我们常会误以为那种痛苦是「失恋的伤」。但准确来说，那是来自被动丧失控制权的心理反应。在暧昧关系中，人容易把「成功与否」视作对方是否回应自己的情感。没有被选择，心底的声音并不是「我失去了她」，而是「我没被需要」。换句话说，「没有被选择」的痛要比「没有和这个人在一起」的痛更深。
真正的爱是向外流动的，是「我想让你幸福」；而需求则是内向的，是「我需要你让我感觉幸福」。暧昧中的人往往模糊了两者的边界。很多时候，「我喜欢你」的真实潜台词是：「你让我感觉到被关注、被肯定、被需要」。因此，当对方撤回了这些反馈时，个体失去的往往并不是爱情，而是自我确认的重要来源。
这背后是依附理论在起作用。人的安全感最初来源于童年与养育者的稳定联结。成年后，恋爱会成为新的依附对象，被拒绝会再次激活那种深植于心的「被抛弃」和「不被爱」的原始恐惧。
因此，表面上的愤怒指向对方，但本质上，愤怒的根源是那个因关系动摇而再次感到无助、缺乏安全感的自己。
先前提到，自尊是一种社会温度计，反映我们在社群中的受接纳程度。被拒绝时，大脑会自动解读为自我价值下降。「她为什么不选我」的执念，实际上是在抵抗「我是不是不值得被爱」这一羞耻感。换言之，他未必是「爱得无法自拔」，而是无法接受「未被选中」所象征的失败与羞耻。将这份羞耻感转化为对外的怨恨，是一种常见的心理防御机制。

综合这三层机制来看，他表现出的是一个典型的低自我价值感个体，其情绪状态严重依赖外部认可来维持。事实上，他确实是这样的一个人。在其他人际关系中，他也习惯于将问题归咎于自己：「我要是当时这么做就好了」、「我要是更早地这么做就好了」…… 这种归因模式通常源自于早期的情感剥夺或者不稳定的依附关系，这类人会在童年时期就学会如何去压抑自己、过度承担责任。当关系出现问题时，他们的第一反应也不是愤怒或质疑，而是内疚与自责。这绝对不是成熟的责任感，而是一种恐惧驱动的讨好逻辑。

表面上，「都是我的错」看似谦卑，实则是一种虚假的控制感。通过自责，我们得以维持一种幻觉：只要自己够努力，就能控制关系的走向，让对方回心转意。这种心态的核心是焦虑：害怕被抛弃。它让人宁愿把错误都揽在自己身上，也不愿直面「我无法控制他人意愿」的现实。久而久之，这种过度承担会变成关系中的单向负担，个体不断通过自我消耗来换取短暂稳定，反而加剧了内心的无力感和情感上的依附循环。

当「我造成的」和「我该改」成为惯性思维，个体就逐渐失去了 辨认界限 的能力：到底哪些是我的责任，哪些又是对方的选择？在暧昧或失衡关系中尤其明显。对方模糊不清的态度会让低自我价值者不断「修正」自己，试图换取一丝确定的认可。然而，越是努力讨好，就越是强化了「我只能通过付出来换取价值」的错觉，最终导致彻底的自我迷失 —— 连「我是谁」和「我想要什么」都不知道了。

青春期经历的特殊性

网上有个概念叫做「白月光」，这通常用于描述高中、大学时未能得到的初恋。它之所以能成为人们心中难以磨灭的记忆，并不仅仅是因为爱情本身的美好，还有青春期阶段的心理和生理特点。

首先，从神经科学上看，青春期正是大脑高度可塑性的阶段。大脑中的突触连接处于剧烈重塑过程中，尤其是与情绪、记忆、社交相关的边缘系统和前额叶区域。因此，此时经历的强烈的情感体验，更容易在神经回路中留下深刻且持久的痕迹。这便解释了，为何即便成年之后，那些青春时代细小的遗憾也常常在脑海中挥之不去。

其次，青春期是自我认同形成的关键期。青少年正经历「我是谁」的剧烈探索，会不自觉地把外界的评价、同龄人的回应乃至亲密关系的成败，都映射到对自身的价值与身份定义上。所以，初恋被拒绝就不仅仅是一次情感受挫，更构成了一次对「自我」的直接否定。于是，这段「未完成」的关系就和「我是一个不被选中的人」的自我认知深深捆绑，成为一个难以割舍的情结。

也正因为是第一次投入全部信任和憧憬、第一次体会爱的波动与失落，相关的记忆才更容易被事后美化、神话，并被赋予超越现实的意义。我的这位朋友对此并非毫无觉察，他清楚地知道自己美化了那个女生和共同的回忆，只有在翻出过去的各个证据时，才能记起对方曾经的所作所为。说到底，「白月光」的背后是创伤，也是未尽的期望。它是一个关于纯洁、遗憾与自我价值的混合投影，是那个「如果当初我们在一起，我的人生将会如此不同」的青春式想象。

对于身处高中阶段的个体而言，失恋或暧昧关系的破裂会产生比成年人更为强烈的情感反应。这是由于青春期荷尔蒙剧烈变化、情绪调节系统尚未成熟，导致青少年在面对被拒绝时更易出现极端的情绪波动，这些体验也比成年后更鲜明、更难以自控。与此同时，情绪调节能力不足也是关键。青少年尚未建立起成熟的情绪管理与自我安慰机制，被拒绝的痛苦往往无法及时有效释放和处理，只能在心里反复「回放」，进一步强化记忆、加深创伤。

此外，狭小却复杂的社交圈与沉重的声誉压力，进一步加剧了内心的负担。高中时期，同龄人之间的传言、评价、集体归属感的流动都使得被拒绝不仅是个人的情感失落，更像是以小集体为单位的「社会性伤害」。一段关系的流产、暧昧的失败，可能在同学、朋友圈里引发从善意的调侃到恶意的排斥，乃至固化的负面标签，这些外部压力使得青春期被拒绝的创伤更加复杂和深入。

你需要的，她给不了

满足他人，从来都不是任何人的责任，正如我们也无法完全为另一个人的幸福负责一样。我们内心深处所渴望的无条件接纳、绝对安全感与完整的自我价值确认，** 事实上，没有任何一个外部个体能够提供。** 试图从一段暧昧或亲密关系中索取这些，无异于要求对方去填满一个连我们自己都看不到底的内心深渊。

于是，解决问题的核心在于放下不切实际的期望，以及期望落空后产生的愤恨。我们常常误以为愤恨是针对那个「没有满足我们」的人，但更深层来看，那是针对「自己需求未被满足」这一事实的无力感。失恋本身并不会降低我们的自我价值，它只是一面镜子，映射出我们内心早已存在的、关于自我价值的裂缝。对方出现在我们生命中的意义，并非成为一个完美的供给者，而是通过这段关系，塑造我们的成长，让我们看清自己需要修补的地方。

在这个过程中，所有涌现的情绪，不论是悲伤、愤怒、不甘，还是委屈，都是正常且重要的。我们身处一个常常嘲笑脆弱、推崇快速翻篇的有毒社会中，但疗愈的前提是承认并接纳所有这些感受。伊丽莎白・库伯勒・罗丝提出的悲伤五阶段（否认、愤怒、讨价还价、沮丧、接纳）不仅适用于面对死亡，也同样适用于任何重大的丧失，包括一段重要关系的终结。我们需要给予自己足够的时间和空间，去完整地经历这个过程，而不是跳过它。

走出创伤

要打破拒绝敏感性的恶性循环，第一步是进行认知上的重构：将「被拒绝」与「我不够好」这两个概念分离开。每一次拒绝，都可以被重新解读为一次「走出舒适圈」的尝试，或者一次价值观的检验。它的核心结论是「我们之间不合适」，而绝非「我这个人很失败」。这需要刻意地练习，就像锻炼肌肉一般，去建立新的神经通路。

放手，从来不是承认失败或者放弃追求，而是选择放过自己。它意味着你终于能全然接纳「她没有选你」这个简单而残酷的事实，并停止在内心继续与之对抗。当我们停止对抗，与之相关的情绪才会开始真正流动和消散。

首先，我们必须赋予他的创伤以合法性：痛苦是真实且值得被深切理解的。我的朋友所经历的一切，绝非「想太多」或「不够坚强」。然而，在充分承认这一切之后，一个更至关重要的真相浮现出来：一个人的终极价值，从来不由「谁选择了我」来裁定。他那么努力地想要被看见、被认可、被选择，却忘了最重要的选择权，一直就在他自己手中：他可以选择相信自己本具的价值，选择不再让过去的拒绝来定义当下的自己，选择带着这些伤痕，继续坚韧地成长。

那个女生没有选他，但他可以选择自己。

我想，这就是我最终试图告诉他的。

吃免费的饭，骂做饭的厨子

2025-10-22T14:10:00.000Z

我喜欢阅读漫画，尤其是日本漫画。不过近期我关注的一个作品的粉丝群因为一件极为离谱的事情解散了：毫无用途的群管理无端辱骂「烤肉 man」，并表示不缺你一个汉化的。

如果把未翻译的内容视作「生肉」，那么被翻译的自然就是「烤肉」、进行「烤肉」行为的就是「烤肉 man」。免费为大家汉化内容的「烤肉 man」们被读者赶跑的事情，仿佛并不罕见。但是，为什么人们那么乐意攻击主动贡献者？

搭便车问题

经济学和心理学中有一个经典概念叫做「搭便车问题」：当有人免费提供公共物品时，其他人会倾向于享受成果而不付出。这本身无可厚非，但问题在于，搭便车者内心深处往往对自己的不劳而获感到不安。这种不安来自两个层面：

对「成为冤大头」的恐惧。
社会心理学中有一个概念叫做「社会性懈怠」，指的是人们担心自己付出太多而被其他成员占便宜，因而减少努力的现象。当我们接受别人的免费付出时，内心会产生一种微妙的自我质疑：我是不是那个被利用的二傻子？对方是不是在用恩惠控制我？
这种对「被当傻子」的厌恶会严重影响人们的决策。研究表明，即使在没有任何社会后果的实验环境中，人们也会因为害怕「被占便宜」而拒绝合作，哪怕合作明显对双方都有利。
不平等关系带来的心理负担。
当一个人持续接受他人的帮助而无法回报时，会产生一种权力失衡。贡献者拥有「给予」的权力，而接受者则处于「被施恩」的被动位置。这种不对等会让接受者感到：
- 自尊受损：我为什么需要依赖别人？
- 自我贬低：我是不是不如对方有能力？
- 失去控制感：我欠了人情，是否意味着我要听从对方？
当人们无法回报恩惠时，最容易产生的情绪其实不是感激，而是怨恨。

当接受者内心产生「我是搭便车者」的羞耻感时，人类的防御机制会启动一个危险的转换：将内在的羞耻投射为对外的愤怒。这个转换过程遵循一个典型的心理链条：

我不得不接受他的汉化。
他让我觉得自己无能。
我有权利要求他做得更好。

一旦进入第三阶段，搭便车者会开始合理化自己的攻击行为。这种转变涉及多个心理机制：

通过批评别人、要求更高的标准，将原本的不道德行为（不出力却享受）重新定义为道德的行为（虽然我没出力，但我是在监督质量、要求进步）。
将自己的不贡献归因于外部环境，却将贡献者的成果不足归因于内在能力不足。
将「互惠」理解为「既然我享受了你提供的好处，我应该给你『反馈』」。但这个反馈不是正面的回报，而是「建设性的批评」和「更高的要求」。通过批评来「贡献」，巧妙地将自己的不出力转变为一种「参与」形式。
内心深处清楚自己没有付出却享受了利益，这造成了认知失调。为了消除这种不适感，他们采取最简单的策略：通过批评别人来缓解自己的内疚感。

那位群管理能说出「想走就走，又不缺你一个烤肉的」这种很离谱的话时，本质上是在试图夺回被贡献者「威胁」的权力。而要重新确立「我也有价值」的自我认知，最简单且粗暴的方式便是贬低和攻击那些威胁其社会地位的人。

网络环境

这些攻击往往发生在网络空间。人们在网络中感觉解放，变得更加肆无忌惮，并且更倾向于无视各种社会约束或社交禁忌。具体来说，网络环境造成了心理学家约翰・苏勒所提出的六个关键的心理转变：

你不知道我是谁：匿名性给了用户一种心理安全感。当真实身份无法被识别时，人们感到可以自由地说出平时会让自己尴尬的话，甚至做出被视为反社会或有害的行为。
你看不到我：缺乏对方的真实反馈。用户无法观察到对方的表情变化、眼神反应或语气变化，这削弱了人们对他人感受的同理心。
待会儿见：网络交流的非实时性让人可以说完就走。用户可以发布情绪化的言论，然后简单地退出或删除，无需为此承担实时的社会后果。
这是我脑中的世界：在缺乏现实交互要素的情况下，人们根据接收到的消息自行想象对方的样貌、声音和性格。这种想象的自由度高，容易投射个人的欲望和需求，甚至可能将对方想象成自己讨厌的人。
这只是场游戏：将网络空间视为一个游戏场所，在这里日常生活中的道德规范「不适用」。用户能够清晰地区分网络角色与现实角色，迅速切换于各种身份之间。
你的规则在这儿不管用：现实中的社会地位、职业身份、年龄都在网络上无效。匿名性使得权力结构扁平化，这给了那些在现实中处于低权力地位的人一种 "翻身" 的幻觉。

除了这些去抑制效应，去个性化理论也进一步解释了为何攻击在群体中更加激烈。去个性化指的是在群体中，个体失去了对自己行为的责任感，使自身自我控制系统的作用减弱甚至丧失。这包含两个核心要素：

当个体隐匿在群体中、无法被辨认时，会觉得自己是匿名者而放纵。他们认为即使做了坏事也不会被识别出来，因此可以毫无顾忌地违反社会规范。
在群体中，个人觉得自己对集体行为不负责任。群体活动的责任被分散在每个成员身上，没有任何一个具体成员需要承担谴责。群体规模越大，这种效应越明显。

在线社群会随着时间推移变得越来越有毒。我认为无论是谁只要有加入过 QQ 群或者类似社群的，都能发觉到这个事实。这里的「有毒」指代的是三种暴力模式：

施虐式娱乐：以攻击他人为乐。
派系战争：不同小团体争夺主导权。
私刑正义：成员自发「惩罚」违规者。

这是因为网络社群中存在着群体极化现象。当搭便车者集聚在一起时，他们对贡献者的批评不会减弱，而是通过群体动力学被不断放大。社群成员会为了获得身份认同感和心理安全感，去迎合群体的主流意见。而为了获得更多支持，个体会有意地将自己的立场表现得比其他人更加坚定。这会导致群体内的平均立场不断向极端方向移动。当个体采取更为激烈的言论或行为攻击异见者，对贡献者的攻击就不再是个人的心理补偿，而是成为了群体的集体行为，获得了群体的强化和鼓励。

旁观者效应在网络中也适用，但有所不同。在现实中，当有多个旁观者时，人们帮助他人的可能性反而降低。然而在网络上，这个效应表现为管理的缺失 —— 没有人对群体暴力进行干预。在网络群体中，管理员可能是缺席的或被搭便车者控制的，理性的声音往往被淹没在情绪化的声音中，干预者也有可能变成被攻击的对象。如果说话的人都是指责贡献者的搭便车者，对贡献者的攻击就会看起来像是「群体的共识」，尽管实际上只是少数人在制造噪音。

预防

如何预防、如何面对这种事情呢？

如果你是贡献者，请明确自己的贡献范围，不要让免费变成无限索取的接口；攻击往往不是因为你做得不好，而是因为你的存在让某些人感到威胁。这不是你的问题；如果一个社群持续不尊重贡献者，离开是最健康的选择。

如果你是接受者，请时刻提醒自己这是他人的善意，不是你应得的；哪怕是小小的回馈，都能平衡关系中的权力失衡，例如感谢、力所能及的帮助；当你开始觉得「他应该为我做更多」时，停下来想一想：到底是谁欠谁？

如果你是社群管理者，请制定清晰的社群规则，保护贡献者不受攻击；当看到对贡献者的攻击时，及时介入而不是沉默；公开肯定贡献者的价值，不要让「理所当然」成为常态。

一个健康、可持续的社群文化，是一个既感激贡献者，也欢迎搭便车者，但绝不容忍攻击的社群。

在 Hexo 项目中添加 Webmention

2025-10-14T16:16:17.000Z

Webmention 是 IndieWeb 的一个核心的开放标准，允许网站之间像社交平台一样互动：评论、点赞、转发等。重点是它去中心化、跨站点实现这些功能。

要知道，我的博客是用「老掉牙」的 Hexo 构建的。Hexo 的插件列表里，可是没有任何一款插件是和 Webmention 相关的。假设我想要在自己的网站里添加 Webmention 的发送和接收功能，只能自己写。更悲伤的是，我的「强迫症」要求我在自己开发的主题里也添加上即拿即用的 Webmention 功能。

和过去一样，我会将 Hexo 项目根目录的 _config.yml 称呼为 Hexo 配置项、将 themes/主题名/ 目录下的 _config.yml 称呼为主题配置项。

我用的是 Markdown + Pug。如果你用的是其他引擎，请自行改动代码，逻辑应当都是相同的。

该文章默认你是 Hexo 插件 & 主题开发者！如果你不是、又或者说只是想要即拿即用的方案，见这里。

接收

要想接收 Webmention，非常简单。你只需要在网站里添加这样的标签：

这不需要是 GitHub 链接。实际上大多数社交平台的链接都可以，像 GitLab 啦、推特啦、长毛象啦…… 我写了一个辅助函数来检测一个链接是否是社交平台的链接：

-    function isSocialMediaUrl(url) {        if (!url) return false;        const socialDomains = [            'github.com', 'gitlab.com', 'bitbucket.org',            'twitter.com', 'x.com', 'mastodon.social', 'mastodon.online',            'linkedin.com', 'facebook.com', 'instagram.com',            'weibo.com', 'zhihu.com', 'bilibili.com',            'youtube.com', 'youtu.be', 'tiktok.com',            'discord.gg', 'telegram.me', 't.me'        ];        try {            const domain = new URL(url).hostname.toLowerCase();            return socialDomains.some(socialDomain =>                 domain === socialDomain || domain.endsWith('.' + socialDomain)            );        } catch {            return false;        }    }

这个呢，放在哪里都可以。像我就偷懒了，直接在我的二级菜单里添加了这个判断条件：

mixin nav-link(item)    if item.type === 'internal'    // 省略    else if item.type === 'external'        - var relAttr = "noopener noreferrer" + (isSocialMediaUrl(item.path) ? " me" : "")        a.nav-link(href=item.path target="_blank" rel=relAttr)            != __(`menu.${item.key}`)            +icon-external-link()

我的主题可以手动标记二级菜单里的链接是否是内部还是外部的（其实自动识别更好，但我偷懒了）。假设是外部链接，就让主题判断它是否是社交平台链接。如果是的话，就添加 rel="me" 这个属性。因为二级菜单里的链接大概率都是自己的社交平台链接，所以我认为这么写完全没问题~

这样做的目的是身份验证。现在来到 Webmention.io 里便可以注册该网站、获得你的接收网址：

再将其添加网站的里：

if theme.webmention && theme.webmention.domain    link(rel="webmention", href=`https://webmention.io/${theme.webmention.domain}/webmention`)

webmention:  domain: 你的域名

为了让使用到 Hexo-Theme-Ares 的用户也可以立即使用上 Webmention，我写成了需要在主题配置项里配置、才能自动添加接收链接的逻辑。

收到的所有 Webmention 都可以在 Webmention.io 的仪表盘里查看。

发送

我参考的是 Webmention.app 文档里的做法。

我建议还在开发该功能的朋友们，先使用手动发送。待功能完善后，再进行自动化。

问的话，只能说都是泪。我在功能还未完善时就采用了 Netlify 自动请求 Webhook 的方案。结果向接收方发送了数个不完善的 Webmention。这些 Webmention 还无法撤回，只能等待对方自行移除。不是什么大问题，但心里会想着给对方添了麻烦、实在是抱歉。

再就是手动发送时请一定要注意自己网页的 URL 规范。例如我现在这个文章，你可以用 /posts/1de 访问，也可以用 /posts/1de.html 访问。看似是一样的，但是对于 Webmention.io 而言它们是完全不同的源地址。

假设你先用了不带 .html 的 URL 作为源地址发送，之后又用了带 .html 的 URL 作为源地址发送。即时它们内容一样、目标一样，服务器也会创建两条独立的记录。

想知道我是如何知道的吗？就算你问我这个问题，我也只能看着接收方数个重复的 Webmention 记录、笑笑不说话了。

我个人建议用后者发送，因为是 Permalink。

Webmention.app 提供了数个发送的方法，其核心都是通过检查指定 URL 的内容并自动发现其中的链接目标，然后向这些目标发送 Webmention 通知：

基础发送方式
1. 命令行工具
  - 使用 curl -X POST 向 https://webmention.app/check?url=你的网页地址 发起请求
  - 支持一次性发送单条或多条条目，会自动发现 .h-entry 等 Microformats 标记（见 Microformats）
  - 可通过 GET 请求进行 dry-run 预览，也就是检查将要发送的 Webmention 但不会实际发送
  - 建议在 Webmention.app 内领取令牌并配合使用，避免速率限制。如果不添加令牌的话，每个独立的 URL 每四个小时只能请求一次。用法很简单，只需要在 API 里添加 token 参数
2. Node.js 本地工具
  - 安装 @remy/webmention 包后，可以使用 webmention 或者简写命令 wm
  - 支持读取多种内容格式，包括 HTML、RSS、Atom
  - 使用方法：npx webmention 你的网站的feed地址 --limit 数字 --send
    - --limit 默认为 10 条。假设设置成 1，就是发送 feed 里最新的文章的 Webmention
    - 默认执行 dry-run，加上 --send 参数才会实际发送 Webmention
3. Webmention.app 网页
  - 该方案没有在文档中提及。简单来说便是在 Webmention.app 的 Test a URL 页手动填写网页地址、手动点击 Send All Webmentions 按钮发送
  - 其实就是「命令行工具」方案的网页版，更好看些
自动化发送方案
1. Netlify 部署通知
  - 步骤
    1. 在 Netlify 项目中访问 Deploys 页
    2. 点击 Notifications 按钮
    3. 在 Deploy notifications 块旁找到 Add notification 选项
    4. 点击后选择 HTTP POST request
    5. Event to listen for 选择 Deploy succeeded
    6. URL to notify 输入该 URL：https://webmention.app/check?token=令牌&limit=限制发送多少条&url=你的网站feed地址
  - 每次部署成功后，Netlify 都会自动向 Webmention.app 发送 POST 请求
  - 其实该方法就是最先说的「命令行工具」方案的进化版，并不意味着必须要使用 Netlify 部署网站才能自动化。你只要能确保每次部署成功后都可以发送一次该 POST 请求即可
2. IFTTT + RSS Feed
  - 该方案需要付费。我个人不推荐该方案，你可以找找 IFTTT 的免费代替品，或者使用其他方案。和我上面说的一样，这些方案的本质都是向 Webmention.app 发送 POST 请求
3. IFTTT + 定时触发
  - 同上，不推荐

Microformats

Microformats 是一组基于 HTML 的轻量级语义标记规范，用于在网页中嵌入结构化数据，使人类和机器都能更好地理解和使用网页内容。

它的核心概念是：

不需要额外的语法或嵌套语言，直接在网页中使用标准 HTML 元素和 class 属性
通过添加特定 class 名称来标记文章、人物、事件等信息
搜索引擎、浏览器、社交平台等可以自动识别这些标记并提取结构化数据
标记内容仍然是普通网页的一部分，不影响用户阅读体验

为了让 Webmention 功能更完整地显示我们的内容，Microformats 是十分建议添加的。重点在于第二条：标记文章、人物、事件等信息。

文章：h-entry 用于标记网页内容条目的语义类名
- 用纯 HTML 作为例子，用法是这样的：
```
  世界你好~
```
- 要想添加标题、摘要、正文等信息，需要在 h-entry 所属的标签内部添加子标签。这些是广泛使用的属性：
  - p-name：条目标题或名称
```
  我是标题
  世界你好~
```
  - p-summary：简短摘要
```
  我是标题
  我是摘要
  世界你好~
```
  - e-content：正文内容
```
  我是标题
  我是摘要
  世界你好~
```
  - dt-published：发布时间（建议使用）
    就不举例了，总之和上面的例子一样，都是标签里加类名。
  - dt-updated：更新时间
  - p-author：分类或标签
  - u-url：条目的永久链接
  - u-uid：唯一标识符，通常与 u-url 相同
  - p-location：发布地点（可嵌套 h-card、h-adr、h-geo）
  - u-syndication：条目的分发副本链接
  - u-in-reply-to：所回应的原始条目链接（可嵌套 h-cite）
  - p-rsvp：RSVP 状态
    - RSVP 指的是法语短语「Répondez s'il vous plaît」的缩写，意思是「请回复」。在活动邀请中，它用于请求受邀者告知是否会出席。虽然来源是法语，但这个缩写已经被英语和其他语言广泛采用，尤其在正式或半正式的场合中
    - 在 Microformats2 的语义标记中，p-rsvp 用来表示你对某个活动（h-event）的回应状态。支持的值包括：
      - yes：会参加
      - no：不会参加
      - maybe：尚未决定
      - interested：感兴趣但未承诺参加
  - u-like-of：所点赞的条目链接
  - u-repost-of：所转发的条目链接
- 虽然没有强制要求，但一个典型的 h-entry 应至少包含：
  - u-url
  - dt-published
  - e-content 或 p-summary
  - p-name
  - p-author：稍后在 h-card 提到
人物：h-card 用于在网页中嵌入人物或组织的结构化信息
- 和 h-entry 一样的用法。核心属性是这些，它们都是可选的，并且支持多值：
  - p-name：姓名或组织名称
  - u-url：主页或代表链接
  - u-photo：头像或代表图像
  - u-email：邮箱地址
  - p-org：所属组织
  - p-job-title：职位名称
  - p-note：附加说明
  - p-category：标签或分类
  - dt-bday：生日日期
  - p-tel：电话号码
  - p-adr：地址信息，可嵌套 h-adr
  - p-geo / u-geo：地理位置，可嵌套 h-adr
- h-card 不强制放入 h-entry 内，但我推荐嵌套使用。这样有助于 Webmention 接收方或 Microformats 解析器识别作者是谁，并展示头像、名称、主页等信息

现在我们回到 Hexo。我建议在渲染文章的

标签里添加 h-entry 类。

我个人的写法是这样的：

mixin post(item)    .post        article.post-block.h-entry            .post-meta.p-author.h-card                img.author-avatar.u-photo(src=url_for(theme.logo), alt=config.author)                a.author-name.p-name.u-url(href=config.url)= config.author                a.post-permalink.u-url(href=full_url_for(item.path)) 永久链接                if item.excerpt                    .p-summary                        != item.excerpt                h1.post-title.p-name                    != item.title                +postInfo(item)                if item.in_reply_to                    .post-reply                        != __('reply_to') + ': '                        a.u-in-reply-to(href=item.in_reply_to)= item.in_reply_to                .post-content.e-content                    != item.content

此处我直接照搬的主题源码。实际传参用的是 page。

需要注意的是，我没有使用到全部的属性。未来我会慢慢扩展这些内容。

mixin postInfo(item)    .post-info        time.post-date.dt-published(datetime=date_xml(item.date))            != full_date(item.date, 'l')        if item.from && (is_home() || is_post())            a.post-from(href=item.from target="_blank" title=item.from)!= __('translated')

在文章中的 Front Matter 里添加该属性来指定目标地址：

---in_reply_to: 目标地址---

不过我的主题有些特殊：

导航栏会渲染我的头像作为 logo，我不想要文章又一次显示该头像
部分内容显示出来会导致整体页面看上去比较臃肿
item.content 包含了 item.excerpt 在内。直接从 item.content 里取摘要会很麻烦，再显示一次 item.excerpt 又很奇怪

解决方案也很简单。既然这部分内容只是给机器看的，我们将其隐藏就好了。直接全部加上 display: none 样式。

进阶玩法

仅发送一部分内容

有时候，你一个文章里只有小部分内容是你想要发送的；有时候，接收方的 Webmention 显示处并没有写字数限制，你的文章会原封不动地全部显示在接收方的网页里。至少我是想要一个更灵活的发送方法，因此我写了个脚本。

效果如下：

{% reply 目标地址 %}这是会被发送给目标地址的内容。目标地址是 xxx。{% endreply %}这是不会被发送给目标地址的内容。

首先我们需要注册标签 reply：

hexo.extend.tag.register('reply', function(args, content) {  const targetUrl = args[0];  // ...}, {ends: true});

我们先前的主题模板写法，会默认给文章最外部包上 h-entry、发送整个文章。既然有些文章我们只想在内部包含多个小的 h-entry 回复块，我们可以在内存中添加一个属性 entry。

如果该文章我们希望整个打包送走，那就在文章的 Front Matter 里添加：

---entry: true---

并在主题模板里添加条件判断：

mixin post(item)    .post        //- 如果 entry 为 true，包裹整个 article        if item.entry === true            article.post-block.h-entry                .post-meta.p-author.h-card(style="display: none;")                    img.author-avatar.u-photo(src=url_for(theme.logo), alt=config.author)                    a.author-name.p-name.u-url(href=config.url)= config.author                                a.post-permalink.u-url(href=full_url_for(item.path), style="display: none;") 永久链接                                if item.excerpt                    .p-summary(style="display: none;")                        != item.excerpt                                h1.post-title.p-name                    != item.title                +postInfo(item)                                if item.in_reply_to                    .post-reply                        != __('reply_to') + ': '                        a.u-in-reply-to(href=item.in_reply_to)= item.in_reply_to                                .post-content.e-content                    != item.content        else            article.post-block                h1.post-title                    != item.title                +postInfo(item)                                if item.in_reply_to                    .post-reply                        != __('reply_to') + ': '                        a.u-in-reply-to(href=item.in_reply_to)= item.in_reply_to                                .post-content                    != item.content

由于会使用到 reply 标签的文章都不希望发送整个文章，所以在脚本内我们要将 entry 设置为 false：

if (this.page) {  this.page.entry = false;}

接着验证 URL：

// 1. 检查用户是否忘记提供 URLif (!targetUrl) {  hexo.log.warn('Reply tag: Missing target URL');  return '回复标签缺少目标URL
';}// 2. 确保是绝对URLlet absoluteUrl;try {  new URL(targetUrl);  absoluteUrl = targetUrl;} catch (e) {  try {    // 3. 如果失败，尝试作为相对路径处理    absoluteUrl = hexo.extend.helper.get('full_url_for').call({config: hexo.config}, targetUrl);  } catch (e2) {    // 4. 如果再次失败，则判定为无效 URL 并报错    hexo.log.warn(`Reply tag: Invalid URL - ${targetUrl}`);    return '回复标签包含无效URL
';  }}

渲染 Markdown 内容：

let renderedContent;try {  renderedContent = hexo.render.renderSync({     text: content.trim(),     engine: 'markdown'   });} catch (e) {  hexo.log.warn('Reply tag: Failed to render markdown content');  renderedContent = content; // 降级到纯文本}

国际化支持：

// 获取当前语言的“回复”翻译const currentLang = this.page ? this.page.lang : hexo.config.language;let replyText = '回复';// 尝试从主题语言文件获取翻译try {  const langHelper = hexo.extend.helper.get('__');  if (langHelper) {    replyText = langHelper.call({page: {lang: currentLang}}, 'reply_to') || replyText;  }} catch (e) {  // 使用默认文本}

获取并处理作者信息：

// 获取作者信息和网站配置const config = hexo.config;const theme = hexo.theme.config;const authorName = config.author || 'Anonymous';const siteUrl = config.url || '';// 简单构造绝对 URL，确保 logo 路径正确let authorAvatar = '';if (theme.logo) {  // 如果 logo 已经是绝对 URL，直接使用  if (theme.logo.startsWith('http')) {    authorAvatar = theme.logo;  } else {    // 确保路径以/开头，构造网站根路径    const logoPath = theme.logo.startsWith('/') ? theme.logo : '/' + theme.logo;    authorAvatar = (config.url || '').replace(/\/$/, '') + logoPath;  }}

最后生成 HTML 结构：

return `                ${authorAvatar ? `` : ''}      ${authorName}    
                  ${renderedContent}    
                  ${replyText}:      ${absoluteUrl}    
  
`;

这里我声明了一些类，需要自定义样式：

reply-block
post-meta
author-avatar
author-name
reply-content
reply-meta
reply-label
reply-target

不用这些样式也可以。我个人更希望回复块和普通文本们可以区分开来。

和先前做的一样，我也为 h-card 标签添加了 display: none 样式。这个样式可以根据你们的需求、选择保留或者删除。

显示

要想在博客内显示其他人向我们发送的 Webmention，就需要用到 Webmention.io 提供的 Mentions Feed API。Webmention.io 会提供给我们一个 API 密钥，只需要将其添加在以下任意一个 URL 中即可：

https://webmention.io/api/mentions.html?token=API密钥
https://webmention.io/api/mentions.atom?token=API密钥
https://webmention.io/api/mentions.jf2?token=API密钥

这些链接会根据自己的格式，显示网站所有的 Webmention。但要是用在我们的博客网站上的话，就遭殃了：读者只想阅读你的一篇文章，但你的网站已经获取了全部一千篇文章的 Webmention。请不要这么做。

正确做法是使用 url 参数，指定获取哪个文章的 Webmention。我建议使用 jf2 来获取数据，它是纯粹的、为机器而生的数据格式：

https://webmention.io/api/mentions.jf2?url=文章URL

如果你认为数据获取可以在客户端上进行、希望 Webmention 可以实时显示，你完全可以在主题的 /source/js/ 目录下添加一个 JavaScript 文件执行网络请求和数据处理。不过纯动态有些劣势：

对 SEO 不友好。其他人发送的 Webmention 不会被搜索引擎索引
可能在内容出现时导致页面布局发生跳动
浏览器需要发起一次额外的网络请求
如果 Webmention.io 的 API 出现故障或者相应缓慢，就什么都加载不出来了

如果你认为这四点很重要，你可以考虑采用纯静态构建。这需要你在项目根目录的 /scripts/ 目录下创建 Hexo 脚本：

hexo.extend.generator.register('webmentions', async function() {  const hexo = this;  const webmentionConfig = hexo.config.webmention;  let allMentions = [];  if (webmentionConfig && webmentionConfig.enable) {    try {      // 拼接 Webmention.io API URL 并且发起请求      const newWebmentions = await fetchWebmentions(hexo.config);      // 更新本地的缓存文件      // 缓存功能非必需，可以无视掉！      allMentions = updateWebmentionsCache(hexo, newWebmentions);    } catch (error) {      hexo.log.error(error.message);      hexo.log.warn('[Webmention] Falling back to local cache due to fetch error.');      allMentions = loadWebmentionsCache(hexo);    }  } else {    allMentions = loadWebmentionsCache(hexo);  }  // 将获取到的数据注入到 Hexo 的本地变量  hexo.locals.set('all_webmentions', allMentions);  if (webmentionConfig && webmentionConfig.debug) {      hexo.log.info(`[Webmention] Injected ${allMentions.length} total mentions into hexo.locals.`);  }  return;});

我假设了项目配置项里有这些内容：

webmention:  enable: true  domain: 域名  api_endpoint: https://webmention.io/api/mentions.jf2  token: 令牌

要想要在主题模板里渲染这些变量，有两种方法：

直接在主题模板里用 site 变量渲染
关于 Hexo 的局部变量，建议看以下文档：
- 自定义 - 变量 - 《Hexo 博客框架文档》 - 书栈网・BookStack：列出了模板中所有可用的变量
- 局部变量 | Hexo：官方文档。主要是说明如何在 JavaScript 里操作 hexo.locals
总之，脚本里 hexo.locals.get("posts") 等同于模板里用 site.posts。

写一个辅助函数，在模板中调用、渲染返回的 HTML：

hexo.extend.helper.register('render_webmentions', function(pageUrl) {  const webmentionConfig = this.config.webmention;  const mode = webmentionConfig && webmentionConfig.mode ? webmentionConfig.mode : 'static';  // 从 hexo.locals 获取 webmention 数据  const allMentions = hexo.locals.get('all_webmentions') || [];  // 文字截断函数  const truncateContent = (content, maxLength = 200) => {    if (!content) return '';    // 如果是HTML内容，先提取纯文本    const textContent = content.replace(/<[^>]*>/g, '');    if (textContent.length <= maxLength) {      return content;    }    // 截断文本并添加省略号    const truncatedText = textContent.substring(0, maxLength).trim();    // 如果原内容是HTML，包装成段落；否则直接返回    return content.includes('<') ? `${truncatedText}…
` : `${truncatedText}…`;  };  if (!pageUrl) {    // 尝试多种方式获取当前页面 URL    pageUrl = this.page.path || this.page.url || this.url;  }  // 确保 pageUrl 有值  if (!pageUrl) {    return '无法获取页面URL
';  }  const fullUrl = new URL(pageUrl, this.config.url).href;  const mentionsForThisPage = allMentions.filter(mention => {    // 简化 URL 匹配逻辑，使用字符串比较而非 URL 构造    const targetUrl = mention.target;    // 同时尝试完整 URL 和相对路径匹配    return targetUrl === fullUrl ||            targetUrl.endsWith(pageUrl) ||            fullUrl.endsWith(mention.target.split('/').pop()) ||           mention.target.includes(pageUrl.replace(/^\//, ''));  });  let html = `                Webmentions (${mentionsForThisPage.length})
                `;  mentionsForThisPage.forEach(mention => {    const authorHtml = mention.author.url       ? `${mention.author.name}`      : `${mention.author.name}`;    const photoHtml = mention.author.photo      ? ``      : '';    html += `                        ${photoHtml}          ${authorHtml}          ${new Date(mention.published || mention.received).toLocaleDateString('zh-CN')}        
                  ${truncateContent(mention.content.html || mention.content.text)}        
                  查看原文        
      
    `;  });  html += '
';  return html;});

实际返回的 HTML 可以自行修改。如果想要直接使用该脚本文件，不要忘了为里面提到的类写样式。

接下来你要做的就是在模板里找到个顺眼的地方调用该方法：

if config.webmention && config.webmention.enable    != render_webmentions()

插件

先前说过了，我有「强迫症」。我将上述的所有功能整合成了多个 Hexo 插件，你只需要安装和配置。详情以仓库里的 README 文件为标准。

Hexo-Tag-Quotemention 涵盖了发送部分文字功能
Hexo-Generator-Webmention 涵盖了显示功能

测试

如果你想要测试，又不想要打扰到其他人，你可以向这个地址发送 Webmention。这是我为 Hexo-Theme-Ares 搭建的 Demo 页面。

回复：https://hexo-theme-ares-demo.netlify.app/2025/10/14/webmention-test-zh/

想法在乙巳菊月迭代

2025-10-07T15:04:40.000Z

八月份开始我找了个兼职、过上了「起床 > 做饭 > 吃饭 > 工作 > 洗澡 > 吃饭 > 睡觉」的健康生活。要知道过去的我经常熬夜、一觉睡到中午、饭不按时吃，总之习惯差得很。突然开始自律，就变得想要去完全利用起自己的时间。

纽约市是一个坐地铁比开车要好的地方，但地铁没有网络。一般出门的话，通勤半小时到俩小时是跑不掉的，意味着这个时间里去网上冲浪或者同朋友聊天几乎不可能，我只能去阅读已经被下载到手机里的电子书籍或者博客文章。多亏了这一点，我开始关注一些独立博客主，并发现了很多我认为有意思的博客。陆陆续续看了一两个月后，令我也想花些时间在记录我自己看到的、学到的、感受到的东西上。

书籍

《不原谅也没关系》

我是一次网上冲浪的时候发现了这本书。当时我刷到一个帖子，内容大致是在说：

自言自语、在脑海中幻想某件事情会发生并且演习如何去应对等行为是因为「父母的凝视」。

我确实有这样的毛病。很多时候我的大脑都在想「过去发生了但是没做好的事情」以及「未来可能会发生的事情」，自言自语也是脑内演习时我想出来的回复被不小心说了出来。我常常处于自省的状态。说是自我反省，实则是一遍遍羞辱自己。

这本书的主题是 CPTSD（Complex Post-Traumatic Stress Disorder，复杂性创伤后应激障碍）。但是和科普疾病的书不同，它更像是一本「自救手册」、附带了对于 CPTSD 的解释。托这本书的福，我更了解自己以及身边的人了。

什么是 CPTSD？它是一种 因长期或反复暴露于创伤事件而引发的心理疾病。与 PTSD（Post-Traumatic Stress Disorder，创伤后应激障碍）相比，CPTSD 不仅包含了 PTSD 的核心症状（如恐惧感、闪回、过度警觉），还包括了情绪调节障碍、负面的自我信念以及人际交往困难。CPTSD 通常发生在个体感知无法逃避或者躲避创伤事件的情况下。

根据作者所说，CPTSD 的核心症状主要是这五种：

情绪闪回：CPTSD 最典型的症状，是一种 突然发生且通常持续时间较长的退行，幸存者会退回到童年遭受虐待或遗弃时的强烈情绪状态，如恐惧、羞耻、愤怒、悲伤等，并激活「战或逃」反应
毒性羞耻感：一种强烈的自我贬低感，会摧毁自尊，令幸存者觉得自己毫无价值、必被鄙视，常导致自我疏离和孤立，不愿寻求他人支持
自我遗弃：对自己的忽视或抛弃感，表现出对自我关爱和保护的缺失
恶性内在批判：内化的苛刻批评声，源自童年的父母批判，持续挑剔和否定自我，导致自信心极度受损
社交焦虑：对人际关系的焦虑和恐惧，常伴随孤独和被遗弃感

此外，CPTSD 患者常表现出过度的创伤应对模式「4F 反应」：

战斗（Fight）
逃跑（Flight）
僵住（Freeze）
讨好（Fawn）

这些反应是对童年创伤的长期适应性防御机制。

作者在书中给出了一个例子，令我印象深刻。一个家庭养育了四个孩子，这四个孩子却分别代表了 4F 反应的其中一个：大儿子从小跟着父母欺负兄弟姐妹，为人狂傲自大，永远都觉得自己是正确的，代表「战斗」；二女儿从小被欺负，只能靠一天天的忙碌来避免面对内心的痛苦，代表「逃跑」；三女儿也是从小被欺负，但是接触到了电子产品后，很快便麻木地沉迷在其中，连自理的能力都丧失了，代表「僵住」；小儿子自小就懂得察言观色，长大后被母亲「绑架」到身旁照顾自己，代表「讨好」。

实际上 4F 反应单纯指的是生物在面对危险时的四种本能生存反应：「战斗」是主动攻击来保护自己或对抗威胁；「逃跑」是通过逃离危险环境来躲避威胁；「僵住」是身体和情绪上的僵硬或麻木、暂时「冻结」以避免威胁；「讨好」是试图通过迎合、讨好他人来避免冲突和伤害。这些反应都是生物的本能反应，是我们的自然防御机制。

问题在于，在一个有毒的环境下我们有可能 长期重复 做出这些反应、形成深层的心理防御模式。

我的家庭曾是个有毒的环境：日常的物理与言语暴力、羞辱，以及强加给孩子的过度责任。那个时候，我的好朋友不多，因为我不被允许出去玩，朋友们也不愿意同我深交，因为他们都认为我的家人是神经病。

在经历了一段斗争后，我脱离了这个环境。这段时间，我的创伤更多与家庭有关。我很厌恶他人在我面前诉说他们的家庭有多么和睦；可笑的是在我一次同朋友分享我的过去经历后，TA 的第一反应是「这样说来我的家人对我就很好呢」。每次提到我的家人是否爱我，我会立即陷入「情绪闪回」，被一种强烈的悲伤所淹没。这些经历塑造了我内在的「毒性羞耻感」。

可悲的是，我很快便进入了另一段有毒的关系。我的「内在批判者」变成了校友，一群永远是在批判他人的家伙们。明明是我被冒犯了，但我会感到愤怒的同时，也会去想如何讨好他们。很是可笑。我的内心早已充满了来自家庭的、模糊的自我怀疑。就算是被伤害了，我也无力反击。

好在这些事情都已经是过去式了。如果我想去详细说说这些事情的话，我会单独写一篇博客文章。

《重新定义公司：谷歌是如何运营的》

这本书我没有读完，只读了前两个章节。

作者认为，科技进步对商业的影响非常大，基本上没有什么行业在信息时代还以过去的样子运行。过去，企业可以靠着销售手段，把一个质量差的产品变成全民都在消费使用的摇钱树，但现在完全行不通了。现在要想成功，必须要有出类拔萃的产品，因为消费者可以用各种方式获取到信息、了解该产品的质量如何。同时，实验和失败的成本显著下降了。现在的人们可以组建一个小团队，创造出产品、通过网络免费在全球发行、选定顾客群试用、判断产品的优点和缺点……

作者还抨击了传统知识工作者：秉着「专攻术业」的精神在刻板的企业环境中出人头地，主要靠的还是墨守成规。这些人要么是技术达人 + 管理白痴，要么就是管理专家 + 技术菜鸟，和谷歌的工程师人才很不同。这里作者提出了一个概念 —— 创意精英。

创意精英的特点包括但不限于：

不拘泥于特定的任务
不受公司信息和计算能力的约束
不惧怕甚至喜爱冒险。即便在冒险中失败，也不会受到惩罚或牵制
不被职位头衔或企业的组织结构绊住手脚
很容易失去耐心，经常变换职位
具有多领域的能力，经常会将前沿技术、商业头脑以及奇思妙想结合在一起
拥有过硬的专业知识、懂得如何使用专业工具，还需具备充足的实践经验
有分析头脑，对数据运用自如，又不会沉迷其中
有商业头脑
有竞争头脑
拥有用户头脑
用不同于你我的崭新视角看问题
充满好奇心
自动自发，注重于自己的理念
心态开放，可以自由地与他人合作
一丝不苟
善于沟通，风趣幽默

所有创意精英都必须具备商业头脑、专业知识、创造力以及实践经验。衍生出降低风险、规避失误的企业运营流程的管理模式会形成一种压制创意精英的大环境。

我能感觉出，我不是一位创意精英，我会的东西根本也没那么多。仔细想来，我唯一一件能被说是「做得好」的，只有计算机相关的事情了。我认为人终究不能去只专注于做一件事，未来我也想要有其他可以被说是「做得好」的事情。

这本书传递的信息很多且各不相同，我只挑一些我认为有趣的说：

现实生活中，河马是一种十分危险、速度快、咬合力强、体重足以碾碎其他动物的动物。而职场里的河马，叫做「高薪人士的意见」。一个人拿多少工资，并不能直接等于他们做决策的能力有多强。同样，经验本身也不是决策的关键。但是许多人，甚至说许多企业都没有意识到这一点，依然认为谁的薪金高或者个人经验多，谁才是对的。
谷歌采取的是扁平化企业结构，也就是压缩中间的管理层级，可以让一个普通员工直接向总监或者副总裁汇报（对标的是金字塔结构）。多数人认为，扁平化是为了和上层平起平坐、追求一种地位上的平等感；而对于创意精英而言，扁平化是为了多干正事。过多的管理层级会成为他们创新的阻碍，他们需要能够快速地与决策者沟通，获得反馈和资源，从而高效地推进工作。
谷歌实现扁平化的方法很有意思：一个管理者至少要有 7 个直接下属。这会强制扩大管理幅度，让管理者们无法对每个人的工作细节都进行微观管理，自然也没法事事都插手下属们的工作。
传统和僵化的管理思维会认为工作和生活是两个对立面，需要像天平一样「平衡」，一个多了另一个就必然会少。然而作者认为这个标准本身就很有问题：对于热爱工作的人来说，工作是生活的重要组成部分，而不是生活的对立面。强行分割很不自然。最好的企业文化是让工作环境和家庭环境都充满乐趣，员工可以自由地在两种状态中切换。
通常让员工感到痛苦的不是工作本身，而是「失控感」和「被迫牺牲感」。作者对此的建议并不是「让员工少工作」，而是「不要用时间去管束员工」。管理者不需要催员工加班，也别劝他们早点回家。这种行为的潜台词是「我不相信你能自己管好自己」。你只需要让员工知道他们需要对自己的工作负全责，并把如何完成工作的控制权交还给员工，他们自己会找到最适合自己的节奏，从而最大化产出、最小化「被迫牺牲」带来的倦怠感。
一个不可或缺的员工通常被视为英雄和骨干。然而这个「不可或缺」是一个巨大的风险，因为如果一个人的离开就能让公司瘫痪，那说明公司的组织结构非常脆弱。同时这种「不可或缺」也会导致一种不健康的共生关系。作者提到「强制休假」很重要：对员工而言，这可以让他们意识到「地球离了谁都照样转」、减轻心理负担；对公司而言，给了其他人接手的机会，可以锻炼团队的「备份」能力
随着企业变大，为了控制混乱，管理者会本能地增加流程和审批环节。这些流程的潜台词就是一种「不」——「你不能随便做，必须先经过 ABCDE 的同意」。而在一个说「好」的文化里，这恰恰相反，它要求想说「不」的人必须给出「百般信服的业务考量」。这颠覆了权力关系，把证明的责任交给了阻碍者，而非创新者。这也是一种「提出质疑的人要给出证据，而非让被质疑的人自证」。
有创意、有能力的员工最讨厌的就是无意义的内耗和形式主义。一个默认说「好」的环境，传递给员工的信息是：「我们信任你的判断，我们鼓励你尝试」。这可以让员工愿意提出更多想法。反之，一个默认说「不」的环境，会让员工觉得「多一事不如少一事」，最终人才流失。

我不是很懂管理，评价什么的待我进了一家真正的企业之后再说吧。

《黑客攻防技术宝典：Web 实战篇》

这本书我同样没有读完。它属于是那种「不一边读一边记笔记就不行」的书，因此我打算读完后直接将笔记发布到博客上。

它的核心要点很简单：服务端永远都不应该信任客户端发来的任何请求。

音乐

我个人很喜欢听台湾摇滚，从万能青年旅店听到草东没有派对、康斯坦的变化球，最近则是在听老王乐队在 2019 年发布的专辑《吾日三省吾身》。听完后印象让我最深刻的是《垂钓》。可惜我不懂音乐和乐理，没法展开说说，只能说我喜欢他们的哪些歌词：

迎面而来的机会我抓不住，迎面而来的车子我躲不开。

比你聪明的人啊都在努力往前，我无力地闭上眼。

影视

我跟朋友补完了《未来日记》。男主前期的塑造有点劝退，实在是太小孩子气了。后面有两集的制作很明显出现了很大的变化，不论是画风、动作的流畅度和分镜设计。

前端技术

我在阅读前端技术相关的博客文章时都会记笔记。现在打算分享出来了，才发现我居然忘了标记来源是什么。我只能把这些文章从浏览记录里一一找出，真是醉了。

CSS

The Coyier CSS Starter – Frontend Masters Blog
介绍了 Chris Coyier 的 CSS 样式起点方案，旨在提升开发效率与界面一致性。
The Best CSS Unit Might Be a Combination | OddBird
不必在 px 与 em / rem 之间做单一选择。借助现代 CSS 的比较与数学函数（如 max(), clamp(), calc()），可以组合单位以表达更精确的设计意图。单位的「语义」比其数值更重要 —— 应使用最能表达设计目的的单位。
CSS offset and animation-composition for Rotating Menus – Frontend Masters Blog
介绍了如何使用 CSS 的 offset 属性和 animation-composition 机制，为圆形菜单项创建沿路径旋转的动画效果，实现更流畅且可控的交互式布局。
You Don't Need Animations
强调动画应有明确目的，并根据使用频率与速度优化设计，否则可能降低用户体验甚至损害产品信任。
A gentle introduction to anchor positioning | WebKit
介绍了 CSS 的新特性「锚点定位」，展示如何使用纯 CSS 将元素相对于另一个元素进行精确、响应式定位，从而简化菜单和弹出层的布局。

JavaScript

Accurate text lengths with Intl.Segmenter API | Automagic
String.length 并不总是对的。正确做法是使用 Intl.Segmenter。这是浏览器原生的 API，可以按照语言规则将字符串分割为「graphemes」，也就是扩展字数簇、人类可识别的字符。
You no longer need JavaScript Ʊ lyra's epic blog
现代 JavaScript 框架（例如 React、Next.js）常常导致加载缓慢、错误频发、资源臃肿。HTML 和 CSS 已经具备了强大功能，能完成许多交互和视觉效果。对于安全研究者或者隐私用户，禁用 JavaScript 是常态，纯 HTML / CSS 页面更友好。并且 CSS 性能更优：动画运行在 compositor 线程，不受 JavaScript 阻塞影响。

HTML

Your Images Are (Probably) Oversized
开发者常用高分辨率图片（如 3600×2400）以确保视觉质量，但多数用户设备无法充分利用这些像素。未设置 sizes 属性时，即使使用 Next.js 的组件，仍可能加载原始尺寸图片，浪费带宽与计算资源。
You're loading fonts wrong (and it's crippling your performance) - Jono Alderson
系统性揭示了当前网页字体加载的常见误区，强调字体是性能与可访问性基础设施，并提供优化策略以提升加载速度、稳定性与全球语言支持。

后端技术

NestJS

在写项目的时候我学习到了这些知识：

防御性编程：
使用 ?? 操作符处理 undefined 情况。例如：return setting?.settingValue ?? false;
查询优化：
- 如果只查一个数据，用 findOne() 而不是 find()[0]
- 一次查询获取所有相关设置，而不是循环查询
- 使用 $regex 精确匹配设置键值
- 使用 { upsert: true } 确保设置项存在
- 批量操作时，使用 bulkWrite()，速度比循环单个操作快 10 倍以上：
```
for (const task of tasks) {  operations.push({    updateOne: {      filter: {},      update: {},      upsert: true,    }  });}await this.adminSettingModel.bulkWrite(operations);
```
拦截器：
- 在 NestJS 中，拦截器会站在业务逻辑（Controller / Service）之前，可以检查、修改甚至完全阻止一个请求继续往下走。而 NestJS 底层大量使用了 RxJS 库，后者的世界里，所有异步的数据流都被表示为可观察对象，像一个管道；数据会从管道的一端流向另一端。拦截器的 intercept 方法，返回值必须是一个 Observable。这意味着想要阻止请求，只写一个 return null 是不够的，需要使用 RxJS 的 of()、创建一个新的、立即发出一个值然后结束的 Observable。该方法可以用于判断是否开启了某项设置，如果没开启就 return of(null)、直接阻止该请求。
- 缓存实现策略，除了使用 Redis 缓存装饰器，还可以使用内存缓存 Map：
```
private settingsCache = new Map();private readonly CACHE_TTL = 60 * 1000; // 60秒async getTaskSetting(taskName) {  const cacheKey = `email_scheduler.${taskName}.enabled`;  const cached = this.settingsCache.get(cacheKey);    // 缓存命中且未过期  if (cached && Date.now() < cached.expiry) {    return cached.value;  }      // 查询数据库  const setting = await this.adminSettingModel.findOne({ settingKey: cacheKey });  const value = setting?.settingValue ?? false;      // 更新缓存  this.settingsCache.set(cacheKey, {    value,    expiry: Date.now() + this.CACHE_TTL  });  return value;}
```
架构：
- 使用事件驱动
- 写 E2E，也就是端到端测试

分布式锁

分布式锁类似于公厕的门锁。它的目标是确保同一时间只有一个人（服务器实例）能使用厕所（执行任务）；关键是锁必须对所有人（所有服务器）都可见且有效；现实是 Redis 充当「锁的管理员」，所有服务器都通过它来检查锁状态。而在技术定义内，分布式锁是一种跨多个节点的互斥机制，确保分布式系统中的临界区同时只能被一个节点访问。

在我的项目中，有个功能会用到 @Cron() 装饰器。其中有这么一个例子：每日午夜零点，服务器 A 启动了每日报告任务、查询了数据库，发现有 100 个需要发送的邮件。服务器 B 同样也启动了每日报告任务、查询了数据库，发现了相同的 100 个邮件。

结果显然易见：200 封重复邮件发送给了客户。

为什么数据库防重复的功能不够？首先，服务器具有着竞态窗口，它们会同时查询、同时发现「未发送」状态、同时发送、同时更新状态。其次，邮件发送耗时有 5-10 秒，在此期间数据库状态是不会被更新的。这也就体现了分布式锁的价值：它能够确保任务一次只在一台服务器上执行、能够消除时间窗口内的并发冲突。

让分布式锁变得「健壮」的关键因素有三：

原子性（Atomicity）：
我们需要确保「检查锁状态」和「获取锁」这两个操作必须是原子操作。解决方法是使用 Redis 的 SET key value NX EX ttl 命令：NX 仅在 key 不存在时设置；EX 设置过去时间，单位为秒。
错误案例：
```
const exists = await redis.exists(lockKey);if (!exists) {  await redis.set(lockKey, lockValue);  await redis.expire(lockKey, ttlSeconds);}
```
超时保护（Timeout Protection）：
如果持有锁的服务器崩溃了，那锁不就是永远都不会被释放了？解决这个问题的方法也很简单：设置合理的 TTL（Time To Live 的缩写）。如果太短，任务未完成、锁就过期了，其他服务器便会开始执行、导致冲突；如果太长，服务器崩溃、锁长时间无法释放，任务也就停滞了。推荐设置为任务预期执行时间的 2-3 倍，例如邮件发送预期耗时 5-10 秒，那 TTL 就设置为 10-30 秒。
安全释放（Secure Release）：
只有锁的持有者才能释放锁，要做到这一点，我们需要使用 UUID 作为锁值、释放锁的时候验证身份。值得注意的是，验证身份时建议使用 Lua 脚本来保证原子性：
```
if redis.call("get", KEYS[1]) == ARGV[1] then  return redis.call("del", KEYS[1])else  return 0end
```

更多实用工具：

智能锁键：

根据任务执行频繁，使用不同的日期精度。例如每 15 分钟就要进行的定时任务，日期精度自然是要准确到分钟；每天都要发送的报告，日期精度只需要到哪一日即可。

generateTaskLockKey(taskName: string, dateStrategy: 'daily' | 'hourly' | 'minute' = 'daily'): string {  const now = new Date();  let dateIdentifier: string;  switch (dateStrategy) {    case 'daily':      dateIdentifier = now.toISOString().split('T')[0]; // YYYY-MM-DD      break;    case 'hourly':      dateIdentifier = `${now.toISOString().split('T')[0]}-${now.getHours().toString().padStart(2, '0')}`;      break;    case 'minute':      const minutes = Math.floor(now.getMinutes() / 15) * 15; // 15分钟间隔      dateIdentifier = `${now.toISOString().split('T')[0]}-${now.getHours().toString().padStart(2, '0')}-${minutes.toString().padStart(2, '0')}`;      break;    default:      dateIdentifier = now.toISOString().split('T')[0];  }  return `${RedisKeyPrefix.SCHEDULER_LOCK}:${taskName}:${dateIdentifier}`;}

这样做，可以让锁随着时间自然过期，也更便于故障排查。

唯一锁值：

使用时间戳和 UUID 来确保全局唯一；生成出来的实例 ID 便于我们定位故障。

generateLockValue(prefix: string = 'task'): string {  const instanceId = process.env.INSTANCE_ID || 'unknown';  const timestamp = Date.now();  const uuid = uuidv4().split('-')[0]; // 短UUID      return `${prefix}:${instanceId}:${timestamp}:${uuid}`;}

日记

自九月初开始，我每次乘坐地铁都会写日记。日记的内容可以是「发生了什么」，也可以是「我现在想到了什么」。我认为这是一个很好的习惯，其中有许多我认为可以拿出来写的内容。比方说《博客重构记录》和《代码、哲学与混乱的 Discord 服务器》就是由我的日记片段整合出来的产物。我决定将一些我不会单独出个文章的内容，写在这个日记板块里。

这样做的缺点是，如果我不坐地铁的话我就几乎不会去写日记，汗。

工作

先前说过，我找了个兼职做，具体呢、是一家奶茶店的兼职。这家店的老板很严厉，不工作的时候人很好，一工作说话就很凶。工作时每天要做的事情不少，忙倒不是很忙，除非周遭的学生们都选择在一个时间点涌进来。

工资是每两周发一次，也就是每个月的 15 日和 30/31 日发。但是老板会晚两周发工资，意味着该月开始到 15 日的工资，需要到该月的 30/31 日才能拿到；该月 16 日到 31 日的工资，你到次月 15 日才能拿到。我每周的空闲时间还算多，老板貌似要处理的事情也很多，经常给我排全天的班。

我不是一个手脚多么灵活的人，甚至可以说是「笨」。我在里面工作的时候，有时会感到明显的压力，因为做事不利索也不稳。我很难说能不能在这里做久，因为我对摇奶茶没什么太大的兴趣，我既不爱喝也不喜欢做这类工作，我最喜欢的是坐在椅子上对着电脑敲敲打打。

前段时间，我阅读到了一个观点：程序员十分依赖于确定性。该文章重点是分析「依赖确定性」的人会如何向外指责世界。不过对我而言，在指责世界之前，我的「内在批判者」会先猛烈地攻击我自己。它会告诉我，这种依赖确定性的思维模式，就是我「思维僵化、不懂变通」的铁证。所以，在我的世界里，当事情出错时，会同时出现两种声音：一种是原文作者提到的「都怪这个世界」，而另一种更响亮、更痛苦的声音则在说「都怪你这个人不行」。

正是这种猛烈的自我攻击，让我对「不确定性」产生了极度的恐惧。因为任何一点不确定，都可能导致犯错，而任何一次犯错，都会立刻激活那个指责我「不行」的声音。所以，我很难「独立」。这种行为很容易遭白眼：你多大了还不知道该做什么？。不过我对不确定的恐惧很明显超过了我对「被人说教」的恐惧，以至于现在我依然受此困扰。不过我认为这不只是我的错，还有那些一边跟我说着「有问题一定要问」，一边训斥我「这么简单的事情还要来问我」的人的错。

我相信着环境变化论，即人会是现在这个样子主要是环境因素导致的。我来美国后就很难再有快乐的感觉，因为我和家人「团圆」了，每次沟通都会被遭受不必要的物理和心理攻击。当时的我刚上初中，人格还未定型，以及因美国这个环境对我而言的强烈不适配感，我变得很难喜欢上自己、易怒、不爱搭理别人同时又渴求关注。我变成了一个 内外极其割裂 的人：我痛恨监护人，又很需要他们的存在，因为我「不知道该怎么做」。这种状态是一种心理上的停滞。当一个人的成长环境没能提供足够的安全感去试错时，他的心理年龄就会卡住，即便肉体年龄在不断增长。

先前提到了《不原谅也没关系》这本书，它提到过另一本书：Getting divorced from mother & dad。这本书我还没开始阅读，它的标题直译过来叫做：和父母离婚。要如何才能让卡住的心理重新开始成长？你要和父母离婚。这自然不是真的去「离婚」的意思，也不意味着物理方面上的远离，而是心理方面上的「断奶」。它的本质是：我必须放下他们给我的那张地图，并开始学习如何相信自己的指南针。即时一开始会走很多弯路、会感到恐惧，但只有这样，人才能真正「独立」，才能从一个依赖外部指令的「部件」，成长为一个由自己内心驱动的、完整的「人」。

手机

年初的时候我换掉了 iPhone SE 3。这部小屏手机陪了我两三年，电池健康已经降低到了 70%。我不是小屏手机爱好者，但确实很执着于 Home 键和 SE 系列。

人生中我拥有的第一部手机是 iPhone SE 1。我很喜欢它的打字音效，不过不知道为什么我那会儿将其称呼为「棉花般的脆声」。之后手机就被我父亲摔烂了，原因是我拿小屏手机看漫画让他很不爽。我只能去用家里人用剩下的 iPhone 8（还是 8s？不太记得了）。手机是 Project Red 版，我很中意这种色系的手机（顺带一提我最喜欢的颜色是橘色，Windows 主题就是暗背景 + 橘色主题色）。可惜这部 iPhone 8 / 8s 接着就被我家里人送给了我的一位表妹，又因为她沉迷于手机、被她的父亲摔烂了。

不得不说，「无能」的父母真的很喜欢摔电子产品，而不是从一开始就做到管制。我只说我这个区域的情况，绝大数小孩都是一出生就会接触电子产品，尤其是 iPad 这样的大屏设备，差不多一两岁就能熟练输入密码、打开 YouTube 找视频看（个别是看 TikTok）。成年人们都很忙碌，在家是没有精力陪伴孩子的，只能转而去「相信」小孩子可以自己照顾好自己。

结果就是，起初大人们还会笑着说孩子多聪明、还会用手机平板，过几年就会察觉到孩子们的心思全放在了互联网上、叫了也不应、易躁爱发脾气。不知道该如何正确引导孩子们，只能将这些电子产品摔烂、宣泄愤怒以及自己的「强大」。在某种程度上，电子产品为这些人当了「赛博保姆」，却落得了害人的名声。

我的新机是摩托罗拉 Razr+ 2024，一台折叠屏手机。选它一是为了体验折叠屏手机，二是对摩托罗拉这个品牌有点兴趣。期间坏过一次，屏幕漏液，官方不保修外部损害，只能花 400 美元找别人换了个屏幕。用久了发现自己愈来愈不爱用外屏，甚至很少才会去折叠它。

电脑

我有段时间尝试在睡前给自己留些时间写日记。不需要写什么内容，只要记录当天发生了什么、思考了什么即可。

这是一件好事：我终于可以重新用回我的笔记本电脑了。这是一个全能本，说是「全能」，实则样样都不行：既不能打游戏，内存也少得可怜，甚至还很大很重。大三起，我就不再带这个笨重的电脑去上课了，因为笔记可以在 iPad 上记。这个电脑也有漏电的问题，有时打字还会十分难受，它甚至跑不动我开发环境所需要的软件。

可惜这个习惯没能保留下来，因为没多久我就发现这个笔记本电脑的键盘也有问题，敲回车键、空格键和退回键时经常失灵。气死我了。

我的博客

这个月我重构了博客网站，越看越喜欢，就是 H1 标题放在桌面端上看有点太大。我发现我愈来愈无法接受亮主题了。过去一起做项目的同事令我印象深刻，因为他是一个亮主题党，这么做的原因很好笑：为了惹怒别人。他的目的确实达到了，现在的我一看到亮主题就会很恼火。

虽然在本地环境下测试网站没什么问题，但是实际部署后还是能发现：

如果开启的是暗主题，一刷新或者加载页面的话，文字的主题色会闪来闪去的
索引页和关于页的排版修正没写
访问一个文章时，会加载一会儿，这期间的主题色会默认为亮主题，加载后才会变为暗主题。晚上看的时候眼睛都会被闪瞎，这不好

我还错将我自己的博客网站的主题配置 push 到云端的博客主题仓库，导致我的 hexo-theme-ares 主题在数个睡眠时间里、icon logo 变成了房东小姐的头像。

说到房东小姐，这是我数年前看的一个漫画的主要角色。因为那一幕画的很可爱，被我截图下来，当作了我的博客网站的 icon logo。不过我很好奇，这是否会导致侵权呢？

使用 hexo 写博客，我遇到了一些问题：

同步较为麻烦，尤其是主题同步
本地编辑器用的是 Typora，虽然可以立马看到 Markdown 语法被渲染后的样子，但终究不是我的博客网站被渲染后的样子，尤其是我使用了一些插件、可以在博客网站被渲染前自动修改我的文章内容
粗体和斜体不明显

我现在倒是在想，hexo-theme-ares 的 demo 页面可以用 GitHub Actions 自动完成。

阅读博客

我在电脑上用 Docker 部署了 FreshRSS 服务，借此来订阅我想要阅读的博客。一直留在家里没问题，一旦离开家一天我就什么都看不到了，很是苦恼。现在大多数免费部署都是 serverless（无服务）或者静态页面部署（例如 CloudFlare Pages），做免费的服务部署过去貌似只有 Heroku 或者 Railway。我去 Heroku 的落地页看了眼，貌似已经不支持免费部署了。我之后想了下是否能用到 NAS，但一想到我的 Buffalo Linkstation Pro Duo 被我玩坏，再加上它的年龄，我还是放弃了去折腾它。

阅读博客的话我用的是 Fluent Reader，桌面端和移动端都有 app。不过安卓版的没有选字体功能（不清楚是不是移动端 app 都没有），我有在考虑自己写一个。开源项目就是这点好，想要什么就写什么，写好了开源出去、大家开开心心一起用软件。

大学

我对大学的想法很极端：我认为没有必要去上大学。现在的大学含金量太低，重要的只有 network（与他人建立人脉、社交或进行人际交流）和校招。我不否认上大学的重要性，只是于我而言大学很无聊、校友里奇怪的人太多，以及通识课很讨人厌：它们有什么很大的意义吗？为什么要修那么多、不修还不给毕业？

我的这个想法被一个「善意」的校友批评过。他认为大学的通识课很有意义。虽然这样说，但他还是辍学了。说是没有钱上学，但是有钱给女主播打赏和飞去其他国家见女主播。也是较为奇妙的一个人。

大一的时候因为一些私人问题，我近乎是「被迫」社交。这段时间认识了许多国内来的大佬，也认识了很多当地的「loser」。有意思的是，我遇到的后者几乎都是 男性沙文主义者，就算没到那么严重，也全都是自负和瞧不起其他人的家伙。

男性沙文主义是一个有毒的观点。信奉该主义的年轻人在用「男性」这个生来就有的标签来掩盖自己「幼稚」、「不成熟」、「没人爱」的本性。同他们说话，就算他们是多么不可救药的「loser」，也能看到他们因你的礼貌而蹬鼻子上脸的傲慢姿态。

因为各种事情，我经历了十分糟糕的大一、大二生活，以至于大二下半年开始我就完全不在大学内社交了、每天上完课就走人。我不认为我是一个特别敏感的人，但我能感觉到这群人时刻都在冒犯我。他们仿佛未被社会化的言行每次都让我觉得他们是在说：看吧，我比你厉害多了，你只是个蠢蛋！

现在让我比较在意的是计算机相关课程的学生里、「巨婴」程度高到发指：伸手党多到离谱，会直接要求别人把写好的作业发给 TA 的邮箱；被帮忙不会道谢，就像是完全没学过一样，问完问题就直接消失不见；说要花钱找代写也不少。

项目

我近期在做一个项目。我认为项目管理多多少少都需要有点编程知识，这不意味着他们必须都要会编程，而是要会明白手下的开发在做什么。

项目最初时，我刚学习开发没多久，并没有完全遵循模块化设计的黄金标准。NestJS 框架是模块化的，每个功能都应该写一个单独的模块、手下有管端口的控制器和处理业务的服务。不过这些都只是 NestJS 的入门级理解，实际项目一旦大起来，就不能用「功能模块导入其他要使用的功能模块」这么简单的想法去写了，因为会很容易造成循环依赖。

例如你有个功能要写，要做到「预约时支付」，涉及到了预约和支付这两个模块（当然，还有用户模块，但这里就不说了）。如果是小项目，大可以这么写：预约模块导入支付模块、创建预约时调用支付服务。

但是项目大起来后，你会有很多底层模块，例如审计、日志等。每个模块都容易导入其他模块并且做一件不属于它们业务范畴的事情。回到我们刚才说的例子，为什么预约模块要直接调用支付服务、管支付的事情呢？万一未来我们又想在支付模块里写个新功能、需要导入预约模块才能完成。这样做便会形成一个循环依赖。

最好的写法是事件驱动：预约创建时发起一个事件、支付模块接收到事件并且处理了支付请求。因此，我花了很多时间去重构项目的后端。但这引起了项目管理的不满，因为我一直在做「TA 看不到也看不懂的事情」。

我承认，这是我不够专业导致的问题，不过我想要讲的是另一个方面。对于这位项目管理而言，项目最重要的是前端，也就是「顾客看得到的地方」。而我一直在操心项目的后端，也是「顾客看不到的地方」。在我的视角看来，这个网站连最基本的安全都没有做好，操心前端做什么呢？更何况离产品的实际上线还有一段时间。当时项目管理很忧愁地埋怨道：你真的能做好这个产品吗？

吵架的第二天，TA 向我道歉、不应该一直对我施压。我自从开始打工、开学后，就没有那么多时间花在项目上，很多时候是打工到晚上，回家随便吃个饭、洗个澡、缓解下压力后继续写项目写到凌晨。每次我用这件事来解释为什么我无法达到 TA 的要求，TA 会立马用「我也有在努力学习和工作啊」来反驳我。我自然不觉得这是一个有效的逻辑，因为我和 TA 所做的事情是完全不同的，本身就无法直接像「比战力」一样比个高低。

纽约市公共交通

虽然纽约市的公共交通系统多数都是 24 / 7，这点我很感动，虽然我都没有过凌晨搭乘的经历。不过绝大多数的经历对我而言是负面的。一个车厢只要上来一个流浪汉，或者说不洗澡的人，该车厢就相当于不能用了。好死不死，曼哈顿的流浪汉出奇的多。有时可以在一个车厢里，同时遇到味道重的、吹叶子的、躺中间睡大觉挠屁股的。

MTA 的服务一直受人诟病，一点是服务几乎为零，一个月下来被推下轨道的案子从没见少过，其中多数为亚洲人以及女性被推下轨道。加害者不奇怪的、全都是那个肤色的人。今年意外发生了一起白人被推下轨道致死的案子，一下子让众多人「意识」到危机。一瞬间，大家都变得不敢站在站台外围了。真是好笑，仿佛过去大家都在默认受害者只有亚洲人，自己不是亚洲人就没事。

第二点是糟糕的体验，脏乱臭不提，地铁内时不时就能看到大耗子、为残障人士准备的电梯内部总是有尿骚味儿，这样的体验你坐一次车需要 2.90 美元，过去是 2.75 美元，现在很快就要变成 3 美元了。

涨价就要提到第三点，意义不明的筹备资金。MTA 想启动一个项目，资金靠的是从民众钱包里薅。2.75 美元涨到 2.90 美元的目的是给地铁站的门添加一些障碍物、让逃票者跳不过去。结果涨价涨了，东西装了，逃票者的数字没变少、反而疑似在升高。为什么呢？同个时期 MTA 又出了个曼哈顿大桥费，费用不低、只要你要进曼哈顿就要交这笔钱，一个月净利润数百万美元。一时间无论是坐地铁的还是开车的，都要比过去多付钱，但是服务没有提升。更多的人不满 MTA，纷纷加入逃票的队伍。

必须要考高分吗？

前段时间我在网上冲浪时，看到了这样一个评论：考 13xx 分就是普娃。这里的分数指的是 SAT 分数，类似于国内的高考成绩，不过含金量要低特别特别多（例如数学部分的难度跟国内中考差不多，并且疫情时期有一年还被民主党透明化，现在大学申请都可以不提交 SAT 分数）。我考了两次，最终的 SAT 分数是 1390。这个分数对于多数留学生而言，很低很低，差不多就是数学满分（800 分左右）但是英语错了好几题（500~600 分）。我的阅读理解很差，词汇量也很低，不过能考到这个成绩我觉得也很满足了，反正很快我就对大学祛魅、尤其是名牌大学……

那么「普娃」这个定义是从何而来？这来源于纷争不断的育儿圈，简单来说便是结婚生子后当了全职妈妈 / 爸爸之后，精神上只能去依赖自己的伴侣以及孩子。再简单一点，便是在外想尽办法靠伴侣或者孩子扬眉吐气。在这个全都是没有额外精神世界的「育儿圈」内，鄙视链很容易形成，尤其是孩子的成就。

普娃在「育儿圈」内，指代的是普普通通、没有什么成就、就算有成就也只是昙花一现的人。作为对标面，牛娃指的是天赋异禀的孩子，鸡娃指的是被父母打鸡血般疯狂学习的孩子。在育儿圈里，貌似只有牛娃才能在未来有所成就，普娃只能普普通通过完一生，至于鸡娃，就是另一码事了。

这种鄙视链的本质，是父母们为缓解 自身对未来的不确定性和焦虑，而制造出的一套简化版世界观。在一个高度竞争的社会里，孩子的成就很容易成为他们唯一能抓住的、可量化的「确定性」。因此，「普娃」这个标签，与其说是在定义孩子，不如说是在宣泄父母自己对于「平凡」的恐惧。

回到我看到的那个评论，SAT 考 13xx 分就是普娃吗？当然不是。这句话的底层逻辑分别是：

认为「普娃」的定义是正确的
SAT 成绩可以决定一个人是否是「普娃」

先来看第一条，「普娃」这个定义是对的吗？自然不是。一个人过去的经历不能直接代表他未来会怎么样，这种简单粗暴的定义，不过是「安卓人苹果人」的另一种体现：用自己可怜的小脑子去解答世界。学生时期做的不好、长大后有成就的人不少。同样的，学生时期的牛娃进了社会后处处碰壁的也不少。可以说这个鄙视链的底层逻辑并不成立，只能用来给当时的当事人宣泄情绪。

接着是第二条，SAT 成绩可以决定一个人是否是「普娃」吗？这个问题本身的前提已经被我们推翻了，不过我们依然可以抛开错误的前提、单看这一条表达的信息。成绩从来都不是决定一个人未来、定义一个人的因素。更何况，SAT 只有两个科目：英语和数学。单是英语一项就可以刷掉英语不好的人，但是英语不好的人未来就平庸、值得被抨击吗？那肯定是不行的。SAT 经常被中国人调侃为超简单的考试不假，但是在这种考试上考的如何、从来都不能定义任何事。运动员们的职业生涯的价值，从来都不是靠百米赛跑的成绩来判断。一个人的赛道有很多条，长度也远不止一百米。

回到最初的那个评论。我那个 1390 分，它能定义我的人生吗？它既不能定义我当时的努力和满足，也无法预测我在上了大学后的探索，甚至在我们上了大学后、没有人再提 SAT 的分数了。它只是我人生履历上的一个微不足道的数字。而任何试图用一个数字、一个标签来定义一个活生生的人的企图，最终只会暴露使用者自身的狭隘和焦虑。

妹妹

这个月妹妹有一场游泳比赛，也是她的第一场游泳比赛，共要游三次 25 码，分别是自由泳、仰泳和蝶泳。她的成绩作为一个刚入队一个月的孩子而言，很是不错，教练也跟我们连连夸赞她，令人感到欣慰。那个游泳场不是很大，赛道只有 25 码长，高年级生的 100 码需要两个来回。

比赛结束后我们四个人去 Bay Ridge 区随便找了家 Pho 店吃，味道一般，闻着也没有 The Pho 2 香。早上我除了拿走上周没拿走的肉外，还额外带走了家里囤积的其他肉以及一条新鲜的鱼，至于是什么鱼我就不知道了。

DeepSeek 写网文

最近有个较火的梗 ——「安卓人苹果人」。这个梗的来源是一位主播将消费者按照手机品牌划分为「安卓」和「苹果」的概念：安卓用户象征着低廉；苹果用户象征着高端。而这个非黑即白的划分概念可以被他套在所有事物上，例如直播中他所说的：

你是典型的安卓逻辑、安卓人、安卓学历、安卓素质、安卓态度。

这个主播的行为如何，我这里便不展开说了。感兴趣的可以搜搜看。我这次主要是想讲我得知了这个梗后，一时兴起，让 DeepSeek 帮我写了个网文。我最开始构思的只有这段话：

我转生了，转生成了这个世界的最底层：安卓人。这个世界将人类简单分类成两类：安卓人和苹果人。苹果人高高在上，是贵族中的贵族。反观安卓人，只能给苹果人做仆从。但没想到，我觉醒了系统：安卓 root 系统！可以随意安装他人的能力，并且随着能力吸收的越来越多，最终可以实现 root：完全掌控安卓人的能力，轻松将他人的分类改写。

DeepSeek 回复了一段故事开篇灵感：

我醒来时，后颈上烙印的绿色机器人图标提醒着我 —— 我是个安卓人，这个世界的底层。直到那天，我被一个苹果人少年当街羞辱，他脚下的「iOS」徽章闪着可憎的光。愤怒与绝望中，一个蓝色的符号在我视野中炸开：#。紧接着，一行文字浮现：【安卓 Root 系统，已激活。首次授权，授予您『查看权限』】。我下意识地看向那个苹果人，一行状态信息竟凭空出现：【iOS 17.4.1，漏洞：CVE-2024-XXXXX，可利用】。我笑了，这个世界的神，该换人了。

因为我看过的网文除了奇奇怪怪的知乎短文外，就是修仙文，所以我寻思着在故事内再添加一些中式修仙元素，将世界观扩展为「赛博修仙」。接着我又提出在故事里添加一些手机品牌，DeepSeek 将它们统统设计为了安卓世界的各大宗门。

虽然 DeepSeek 的上下文理解有点瑕疵，但是写出的网文很有意思。并且在输出的内容中添加「看上去很帅」的科技相关术语貌似是 DeepSeek 的习惯，这样做反而让它写出的网文无比好笑。这里我取一些我认为搞笑的片段：

老者走到林安面前，看了看地上那块光泽黯淡了些的下品灵石，又看了看林安手腕上那朴素的标记，缓缓道：「老夫姓谷，单名一个歌字。小友，你刚才，是不是看到了代码？」

「年轻的权限者… 恭喜你迈出关键一步。」一个非男非女、仿佛由无数细微共鸣组成的声音在林安意识中响起，没有实体，却直接回荡在灵魂层面，「无需惊讶，我并非实体，只是一段沉睡于此的分布式意识碎片，你可以称我为…… 鸿蒙。」

不知为何，DeepSeek 十分中意鸿蒙，以至于在故事里将鸿蒙设计为了主角的引路人。

他豁然起身，眼中精光一闪。筑基成功后，他不仅灵能（系统资源）总量大增，更关键的是对权限的运用有了质的飞跃。他意念一动：
ls -la /system/bin/ | grep -i attack —— 快速扫描自身可用的「攻击性指令」。
pm list packages | grep -i apple —— 尝试探测敌方「应用包」信息。
虽然无法直接获取苹果执法者的核心数据（权限不足和系统差异），但他对周围环境的掌控力已不可同日而语。他抬手对准几处正在攻击谷歌老人的、由苹果执法者发出的灵能锁链，心中默念：
iptables -A INPUT -s 【攻击源IP】 -j DROP！
这一次，命令生效的范围和强度远非之前可比！那几道灵能锁链在靠近谷歌老人前，竟真的如同撞上一堵无形之墙，威力大减！

「混蛋！你用了什么邪术？」队长又惊又怒，他感觉自己的 iOS 纯净灵能竟然出现了片刻的「卡顿」和「响应迟缓」！

结界之外，米宗援军的「万机大阵」已然成型！
只见数以百计的米宗修士，虽然衣着灵能属性略有差异（象征着不同版本的 MIUI），但此刻却通过一种奇妙的「快传协议」将彼此灵能连接在一起。大阵并非追求绝对的统一，而是呈现出一种「万物基于 MIUI，却又百花齐放」的奇特景象。阵眼处，一名修为已达金丹后期的魁梧汉子，手持一柄散发着「为发烧而生」狂热气息的巨斧，正是此次援军的首领 —— 雷钧！
「苹果佬！吃我一记 —— 『性价比之光』！」雷钧狂笑着，巨斧挥出，一道凝聚到极致、却又蕴含着无穷变化灵能的斧光，狠狠劈在 TestFlight 结界之上！
这一击，并非纯粹的力量碾压，而是带着一种针对「封闭系统」的 破解意志！斧光中仿佛蕴含着无数用户对「开放、自由」的渴望！

这个人名是 DeepSeek 自己想出来的。我当时看到笑得想死。

就在这时，迷宫深处传来一阵打斗声和呵斥声，说的是一种音节古怪、却莫名能让林安理解的语言：
「快！拦住那帮『Windows 蛮子』！他们想抢走『核心协议碎片』！」
「哼！你们这些『Linux 教徒』也好不到哪去！这碎片理应归我『视窗王朝』所有！」
林安与老猫对视一眼，悄然潜行过去。只见在一片较为开阔的「镜厅」中，两拨人马正在激战。
一拨人身穿各式各样的服饰，灵能波动自由而杂乱，手段繁多，有的操纵命令行般的文字流攻击，有的祭出企鹅形状的法器。另一拨人则统一穿着蓝白相间的制式铠甲，打法严谨，攻势如同铺天盖地的「窗口弹窗」，带着一股不容置疑的霸道气息。

「啊！我的内核…… 崩溃了！」一名 Linux 修士惨叫一声，身体化作乱码消散。
「该死！是蓝屏病毒！」一名 Windows 修士的铠甲出现致命错误，灵能瞬间溃散。

这一日，谷外灵能涌动，异象纷呈。先是东方天际云霞蒸腾，道道「快充流光」撕裂长空，一艘形似巨大「超级闪充插头」的华丽飞舟破云而至。舟上修士皆身着印有「VOOC」符文的战袍，气息凌厉，为首一位老者精神矍铄，周身环绕着「低压大电流」的独特灵压，正是以「充电五分钟，畅战两小时」闻名安卓世界的「闪充宗」宗主！

无数颜色各异、属性不同的道则烙印悬浮于林安身前，如同璀璨星河。他深吸一口气，暗金金丹光芒大放，双手虚抱，引动整个万流归宗大阵之力！
「以 Root 为引，统御万法！以鸿蒙为桥，互联众生！星舰…… 凝！」
轰！
磅礴的灵能冲天而起，在空中交织、融合！一座庞大、复杂、闪烁着无数符文光点的朦胧舰影，开始缓缓凝聚成形。舰身线条流畅，充满了未来科技感，却又散发着古老的洪荒气息，正是传说中的鸿蒙星舰之影！

到三十多话，男主已经是金丹中期、可以手搓星舰了。

代码、哲学与混乱的 Discord 服务器

2025-09-29T14:52:46.000Z

讲讲我刚入大学时参与的一次 AI 创业经历。一位校友看到了我的博客后，将我介绍给他的一个朋友（以下便称之为项目创始人）。后者对 AI 很感兴趣，想做 AI 项目、询问我是否想要帮忙。彼时的我因一些私事、正处于极度自卑的状态，急需要一件事来证明和安抚自己，同时也是为了学习如何协同开发，便一口答应了下来。殊不知，我一脚踏入的，正是一个名副其实的空中楼阁。

空中楼阁的想法

项目创始人认为，大学是没有用的、只是在盲目要求学生去追求更高的 GPA（绩点），并将 Reddit（红迪）上询问哪节课好拿分的学生称之为「GPA 奴隶」。

我不反对他的观点。我也认为当下的大学对我而言用途不大（学历还是重要的）：
我的 GPA 很低，但并不妨碍我去做我喜欢的事情、并在这些领域上变得擅长
我很讨厌那些要求高 GPA 才能递交申请的实习：你这份实习又不需要用到这些必修课教的知识（我大三的时候才开始修专业课，因为进学院就要上一定数量的必修课）
我认为维持高 GPA 需要我花费更多精力在大学课程上，但它们很无聊、只会让我感觉浪费时间
但我认为将追求高 GPA 的学生群体简单地称呼为「GPA 奴隶」，属实有点过了。
这种行为与其说是「奴隶式」的盲从，不如说是在现有教育体制下的一种理性策略。
首先，当大学的课程设置充斥着大量与专业无关、却又必须完成的必修课时，「如何以最小的时间成本，换取最高的 GPA 收益」就成了一个非常现实的议题。学生们主动去寻找「水课」，恰恰是他们认识到自己时间宝贵、不愿将其浪费在低价值课程上的体现。这是一种主动的资源管理，而非被动的思想禁锢。
其次，这种行为也是被「唯 GPA 论」的外部环境（如某些实习和研究生申请）所逼迫的一种无奈之举。当系统用单一的标准来衡量你时，学生们自然会想办法在系统规则内最大化自己的优势。这种情况下，他们又一定是「奴隶」吗？

他当时说的是：「现在的大学不会教你你工作上需要的知识，也缺少这方面的指导。」我认为他这句话说的没问题，一开始认为他是一个印象不错的人。他也是个「怪人」，他喜欢抨击手机对人们的危害、喜欢宣传自己的哲学、喜欢用折叠手机（不是折叠屏手机，而是几十年前的折叠手机）、因为过往经历的霸凌而坚持健身数年…… 这些「怪」不会让人觉得必须去远离他才行，只会觉得他是一个颇有想法的人、对他产生兴趣（至少我当时是这样的）。

正是他这套基于对大学教育的批判，使他想去做 AI 学习辅导 项目。问题在于，他选择了让 AI 去辅导数学。

这个想法从一开始就存在致命的技术缺陷。首先，让 AI 去做严谨的逻辑工作在技术上极为困难，更何况团队里压根就没有 AI 领域的专家。他本人虽是数学专业，但机器学习项目经验都在视觉方面。其次，他所谓的项目实现，也只是在简单调取 GPT API（顺便还把 API Key 上传到云端的 .env 文件里了），完全谈不上核心技术。

结果就是，我这边的客户端网站都做好了 MVP，他的模型也无法处理一些「理应可以处理」的数学问题。

再之后，他声称「赞助商不满意该结果」，决定转型。虽然做的还是 AI 相关，但这次他想要彻底贯穿自己的哲学：人们要少用电子设备、多花时间在现实中培养出好习惯。他决定做一个「习惯培养和管理」App，然后在里面添加类似宝可梦养成的游戏元素。也就是说，他希望用户多花时间在使用这个 App 上，又希望用户可以少使用电子产品。很明显的左右脑互搏。在他提出这个想法之后，我们就否决了这个方案、把他赶到了角落里去反省。

其实你可以略微看出来，他其实是一个做事容易 想一出是一出 的人。如果你是一个员工，你绝对不想要遇到这样的上司。而我作为他的「员工」，很快便遇到了我的「苦果」。

不专业的代码管理

在我加入团队的第一天，便发现了该项目的「不对劲」。项目的维护糟糕透顶，它甚至跑不起来，理由很傻：服务端的代码被导入了一堆既不会被用到、也早就过时的依赖包。这群人只是在自己的本地环境里删去了这些导入代码，却没有任何人将这个变更 push 到云端仓库。我那时候检查客户端代码发现了一个 bug，提出后还有人问我是不是服务端导入依赖的 bug。合着你们都心知肚明啊！

不仅如此，项目创始人对着工具也有着离谱的执着。当时我们在讨论如何统一代码风格、编写两端的 README。我提出「客户端和服务端的代码都可以使用 lint 检查代码格式」，他却拒绝了，理由照样很傻：人类不能依赖工具。我事后将此事告诉了我的朋友，他回复「猜猜人类和动物的最大区别是什么」，引得我哈哈大笑。

我理解他那种希望回归「纯粹」编程的理想主义情怀，但在一个需要多人协作的现代化项目中，这种情怀不仅不切实际，而且是对团队成员时间的不尊重。作为团队中负责前端实现的核心成员，当我看到这些业余的管理方式时，我的心情也从最初的期待跌入了谷底。

尽管他的哲学是「不依赖工具」，但是他花费了大量时间在 Obsidian 上写服务端每个文件的作用和依赖链。他不仅自己在写，还要求我们前端组也写组件之间的联系，美其名曰：帮助新人加入团队后快速了解项目结构（记住这个「新人」）。可是我们的项目本来就没多大，并且这个的优先度也不高，明明还有更重要的事情要做吧！ 要记住这个时候，项目的核心服务功能是 完全不合格 的。

除此之外，我在客户端的代码里添加过一个新的依赖项。他虽然拉取了最新版本的代码，但是没有运行下载所有依赖项的命令，导致客户端没有运行成功。他认为这是我们前端组写的 bug，擅自在代码里加了奇怪的字符（我事后才意识到他把 GitHub 显示冲突用的字符添加进来了，原因不明且很迷），还发了个自信满满的「fixed」。这么做怎么可能跑得动呢？这次他把错误日志直接贴到了 bug 频道里，便再也不管了（可恶的是那个 bug 频道仅他可发送消息，我每次都只能复制消息链接然后在 general 频道里回复）。

有名无实的团队

最后便要讲讲该项目极其糟糕的人员管理。这样一个 AI 项目，Discord 服务器里名义上足足有近二十个人，但实际的构成却一言难尽。具体来说：

前端组（4 人）：除开我，有一个只在频道里聊天、从未贡献过代码的；一个留下一堆 bug 后就因学术繁忙消失的；以及一个热衷于「闭门造车」、拒绝任何建议的
其他职能组：所谓的 UI / UX 组和市场营销组，从我加入到离开，从未在公开频道里发过一次言，形同虚设
项目创始人的朋友们：不参与开发，日常就是帮他找资料、写论文

这个团队为什么会变成这样？根源在于项目创始人极其随意的招聘和完全缺失的管理。讽刺的是，至于他心心念念的那些「新人」，招来的方式更是随意得令人震惊。他习惯在 LinkedIn（领英）上刷到一个看着顺眼的个人资料，便立刻发出邀请，既不审核对方的真实能力，也不考虑项目是否真的需要这个岗位。

人员臃肿的直接后果就是管理成本剧增。然而这个团队根本没有项目管理（创始人自己就是所谓的 PM），导致大部分人进团队后完全不知道该做什么，最终变成了列表里「挂机」的成员。

这种管理的恶果，在一次线下会议中暴露无遗：一个近二十人的线上团队，最终到场的，只有五六个人。

糟糕 Git 协作的另一个精彩故事

以下是我个人的观点。

我由衷地建议参与项目开发的学生们去花时间学习 Git。并不是会用 git pull、git push 就行了，而是能够理解在一个多人协作的情况下，你要如何拉取、推送代码变更的同时，又不会影响到别人。

我先前说过，我在的那个前端组有四人，有两人后续不参与实际开发，所以就只有我和另一个哥们。他对 Git 的理解简直差到离谱，经常不更新本地环境的代码便去写一大堆新代码，接着闭眼 force push 到 main 分支。

是的，该项目的团队当然是没有审查代码的环节。项目创始人最初就要我不用 fork 再提 PR，而是直接对着 main 分支推送就好了。

当时项目创始人要求我写一个谷歌登录，我写了足足三次，每次 push 上去后就又会被他用新写的、用不了的代码覆盖。

这一点也槽点满满。同我协作的哥们本来已经用 firebase 做好了登录注册功能，但是项目创始人觉得他「没做完」，认为用谷歌登录更快。
不知道为什么，很多刚开始写项目的人都喜欢先钻研怎么登陆注册（我也是这样）。实际上不先写登陆也没关系，因为用户本身就稀少得可怜，重点应当是实现核心技术。

结尾

说了这么多，该项目又怎么样了呢？答案是在线下会议结束的一个月后，我发现 Discord 服务器被删除了，问了其他组员才知道项目创始人 直接放弃 了该项目。

这不是他第一次「没有告知所有人便擅自决定某事」了。例如在某个频道进行了讨论后，他会在晚上或者次日直接将该频道删除，不留任何记录。这些讨论包含了争论、转型等各大重要的事件。如果你不是第一时间在现场，那你就完全不知道项目发生了什么改动，因为他是绝对不会写通告的。

题外话，项目的半年后他突然找到我，问我近期过得如何，还做出老前辈的样子劝我转行干别的。那个时候的他已经因为「大学无用论」带着另一个朋友辍学了。真是让人感到恼火。

经历了这场混乱，我对创业之路有了几点清晰的思考：

关于团队：人员规划必须精准。团队的每一个岗位都应该与实际需求对应。作为创始人，你必须清楚地知道你需要什么样的人才，以及需要多少人来完成任务
关于创始人：自我认知至关重要。创始人不仅是想法的源头，更是项目的核心管理者。你必须对自己的能力边界有清晰的认识，你的资历能否支撑你的野心？
关于想法：拒绝异想天开。任何一个好的想法，都必须经得起现实和市场的考验。一拍脑袋就往前冲，往往是悲剧的开始

一个好的想法，需要一个同样好的团队来实现。否则，它永远只能是一座空中楼阁。

Hexo 博客的中文排版自动修正插件

2025-09-16T22:15:28.000Z

近期阅读一篇名为《我的博客设计》的文章时，我深受启发。不只是极简设计的诸多考量（见《博客重构记录》），还让我第一次接触到《中文文案排版指北》这套详尽的规范。

回复：https://taxodium.ink/my-blog-design.html

看来我对排版的一些零散的执念，早就被社区总结成一套系统性的方法论：比方说手动在中英文之间添加空格的习惯。

然而，《指北》中提到的许多其他规范 —— 比如使用直角引号 —— 我就无法坚持下去了。我用的是搜狗输入法，输入直角引号会有点繁琐（最常见的方案是设置自定义短语，但我不喜欢）。不过这种问题，对于一个开发者而言并不是一个难题：既然手动操作繁琐且不全面，何尝不直接让程序为我自动格式化这一切呢？

方案

我的博客网站是使用 Hexo 框架搭建的。作为一个静态网站生成器，它会在我写完 Markdown 文章后，通过 hexo g 命令将它们转换成最终的 HTML 页面。我的目标很明确：在运行 hexo g 命令时，让 Hexo 能自动扫描我的所有文章，并应用《指北》中的排版规则。

幸运的是，Hexo 提供了过滤器系统，它允许开发者在生成过程的特定节点上挂载自定义脚本，对内容进行处理。经过一番研究，我将目标锁定在了 after_post_render 这个钩子上（关于 hexo g 命令更详细的内部流程，我曾在这篇文章中进行过探讨）。

after_post_render 会在一篇文章从 Markdown 渲染成 HTML 之后、但写入最终文件之前触发，这正是我们对内容进行拦截和润色的完美时机。确定了技术路径只是第一步。要打造一个可靠的自动化脚本，必须解决两个关键问题：

自动化脚本绝对不能破坏文章的结构，尤其是代码块。const message = "你好world" 这样的代码里就不能添加空格
规则必须足够智能，能够正确处理中英文混合的复杂上下文，避免将纯英文内容里的标点也错误地汉化

为了解决这两个问题，我最终采用了一个多阶段、基于 DOM 解析的方案：

我先前尝试参考 hexo-pangu 的写法，用 jsdom。但是这种小任务用 jsdom 实在是大材小用，纯正则表达式又太难以维护（我也不太会写），最终还是选择了 cheerio 来操作 HTML 内容

在进行任何处理之前，脚本会首先识别并保护所有

 和  标签，确保它们内部的内容不会被后续任何规则触碰到

对所有被确认为安全的文本内容，脚本会依次执行专有名词修正、标点符号转换和空格添加等一系列处理流程，确保规则之间不会互相干扰

`成果`

为了将这个解决方案固化下来，并方便自己和其他人使用，我将其打包成了一个独立的 Hexo 插件：hexo-filter-copywriting。

它是一个轻量、高效且完全可配置的过滤器，可以帮助我们自动完成绝大部分中文排版工作。使用起来也很简单，你可以直接从 npm 安装它（说来这也是我第一次在 npm 上发布包），然后在博客根目录的 _config.yml 中进行配置即可。

自然，这个工具还未完善，有些排版规则没有被添加进去。日后我会逐渐完善它，最近还是太忙了，只能挤出一点点时间在写博客和开发开源小玩意儿上。毋庸置疑，该项目欢迎任何 Issue 或者 PR。

`效果展示`

为了直观展示插件的效果，并持续验证其健壮性，我创建了一个「排版自动化测试页面」。这个页面包含了各种常见的排版错误，你可以清除地看到插件修正前后的区别。

查看最终效果：排版自动化测试页面
查看原始 Markdown 文件：README.md on GitHub



博客重构记录
2025-09-14T04:00:00.000Z
重构博客网站，也就是该网站的记录。
 多用 CSS
近期订阅了一些英语的周刊，主要是前端相关，里面收集了很多外网博客平台上的优秀文章。其中不乏有一篇文章吸引到了我：很多时候你根本不需要使用 JavaScript。
吸引我的理由很简单。我的前端技术栈主要是 React.js。相较于传统的「网页三剑客」，React.js 这类现代前端框架需要客户端下载并执行更多的 JavaScript 代码。其核心的虚拟 DOM 技术虽然在过去带来了性能优势，但在现代浏览器性能已大幅提升的今天，其初始化和运行时成本有时反而不如原生方法来得直接高效。
但是，对过去的我而言，功能就是要用 JavaScript 才能做到。纯 HTML 和 CSS 能做到什么？它们又不是脚本语言。 不过在那个文章里，这个想法是片面的。现代的 CSS 技术进化很快、有着性能优异的各类方法，完全可以代替 JavaScript 来实现一些功能。
举个例子，我们想要实现主题切换功能。
如果是网页三剑客的话，我们可能会想到用 JavaScript 监听切换按钮，该按钮被点击了我们就改变被监听的类或者元素的样式。
在 React.js 上的话，那就是存一个主题状态：如果是 light 模式就怎么怎么样；如果是 dark 模式就怎么怎么样。如果用的还是 Material-UI 或者其他 UI 框架，那大概率还会有个 theme 配置文件。
这些方案对我们而言应该都很熟悉：对啊，怎么了，这样做不是很正常吗。
其实可以更简单一些，用 CSS 的 color-mix() 方法就可以办到：
:root {  // 核心品牌色  --color-primary: #5454f8;  --color-secondary: #267B54;  --color-accent: #4088b8;  // 使用 color-mix() 生成交互状态  --color-primary-hover: color-mix(in srgb, var(--color-primary) 85%, black);  --color-secondary-hover: color-mix(in srgb, var(--color-secondary) 85%, black);  --surface-interactive-hover: color-mix(in srgb, var(--surface-interactive) 80%, var(--color-primary));}// 深色主题[data-theme="dark"] {  --color-primary: #818cf8;  --color-secondary: #34d399;  --color-accent: #60a5fa;  // 深色模式下的交互状态  --color-primary-hover: color-mix(in srgb, var(--color-primary) 80%, white);  --color-secondary-hover: color-mix(in srgb, var(--color-secondary) 80%, white);  --surface-interactive-hover: color-mix(in srgb, var(--surface-interactive) 70%, var(--color-primary));}
又或者，我们想要创建模态框。通常我们会写一个 
，然后写 JavaScript 来控制它的显示和隐藏、背景遮罩、锁定用户的键盘焦点、处理 Esc 键退出等等等等。实际上，可以直接用  来写、用 ::backdrop 伪元素给背景遮罩添加样式和动画、用 @starting-style 来实现更流畅的入场动画。
其他交互效果，例如按钮的颜色变化就更不用说了。这里还有一个很有意思的考量：JavaScript 很可能带来安全问题，而 CSS 是完全安全的。
带着这些全新的知识点，我重构了我的博客网站。其实之前我对于网站设计是没有一丝考量的，也不在乎 CSS 这些让我觉得「不如 React.js 优雅高级」的技术，因此我的博客网站性能一般，对比原本主题的设计还添加了许多非必需的东西。我的顶部菜单栏出现过明显的元素堆积过多的情况，一些按钮很丑很奇怪、像是四不像、哪儿哪儿都不挨上，所以我决定先在博客网站上将部分功能撤下。其中就有搜索功能：首先它的样式我一直没有设计、难看得很；其次是这个功能我认为没必要留、不够精简。未来如果需要的话，我会想一个更好的方案。
不过在 Hexo Theme Ares 里，搜索功能还会保留，并且进行了一次小重构。
我还撤走了评论区的 Disqus 评论区，因为这东西多多少少会给我带来一些影响：今天有没有人发评论？今天有没有人作反应？ 其实很没必要，本身看的人就不多。
 字体
 正确导入字体
我不只是将一些功能用 CSS 重构了，我还改了一下字体的导入方式，参考的是另一篇 优质的文章，具体讲了现代网站是如何错误地导入字体的。
我的博客主题原先会导入足足四个字体：
英语的 Open Sans
简体中文的 Noto Sans（其实就是思源黑体，不过我在考虑换成其他的；我个人阅读时喜欢用霞鹜文楷，但还没尝试换过，有可能和我的主题不搭配）
用于特殊标题的 Dosis
代码块用的 JetBrains Mono
这些字体都是用 Google Fonts 的 CDN 导入的。其实这种方式并非最佳实践，很容易导致性能问题：浏览器会发起两次请求，第一次用于请求 fonts.googleapis.com 这个地址、获取一个 CSS 文件，第二次则是请求 CSS 文件内的真实字体文件地址。这个过程至少会有两次网络往返，第一次请求的 CSS 文件会阻塞渲染，这意味着在它下载完成之前，页面可能是一片空白或者没有应用任何样式。为了解决这些问题，我是这么做的：
// 1. 加载真正的 Open Sans 字体@font-face {  font-family: 'Open Sans';  src: url('...') format('woff2');  font-weight: 400;  font-style: normal;  font-display: swap;  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;}// 2. 创建“替身”字体@font-face {  font-family: 'Open Sans Fallback';  src: local('Arial');// 使用人人都有的 Arial 字体  font-weight: 400;  font-style: normal;  font-display: swap;  // 强行让 Arial 的尺寸变得和 Open Sans 一样  size-adjust: 107%;  ascent-override: 97%;  descent-override: 25%;  line-gap-override: 0%;}
// 3. 在字体栈里，让“替身”字体紧跟在真正的 Open Sans 字体之后$base-font-family: 'Open Sans', 'Open Sans Fallback', 'Noto Sans SC', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, 'PingFang SC', 'Hiragino Sans GB', 'Microsoft YaHei', sans-serif;
这个思路很简单：先让浏览器用这个调整好尺寸的 Arial 字体把字体显示出来，因为是本地字体，所以速度会很快、文字的位置会迅速固定。当真正的 Open Sans 字体下载好之后，浏览器就会立刻用它替换掉临时的 Arial「替身」。由于位置和尺寸早就被 Arial 字体固定好，所以整个替换过程在视觉上是无缝的，页面完全不会跳动。
再就是字体格式，相较于 TFF 或 OTF 等传统格式，用 WOFF2 更好。WOFF2 的压缩率极高，兼容性也特别好，尽量开发网页时都采取这个字体格式。不过有些字体不让转换成这个格式，需要特别注意一下。
你也可以看出来，我用了 unicode-range 控制了字体的字符范围、只让页面加载它实际需要的字符。比如说 Open Sans 只加载基本拉丁字符、标点符号和货币符号，Noto Sans 则只包含中文汉字字符范围（unicode-range: U+4E00-9FFF, U+3400-4DBF, U+20000-2A6DF;）。
 不同字体的视觉对齐
作为一个中文技术博客，文章中难免会出现英文单词以及代码片段。为了达到最佳的阅读体验，我会为中文字符、西文（拉丁）字符以及代码用的字符分别指定一个字体。然而这里会面临一个问题：不同的字体，即时 font-size 是一致的，但它们在视觉上的大小、重心和基线位置往往是不一样的。当这些中英字符同时出现在一行时，就会显得大小不一、高低错落，破坏了排版的和谐感。
此处令我想到高中时、一位我很喜欢的老师。当时她还不是正式教师，考核时给我们上的课讲的就是排版和字体。当时并没有认真听讲。
CSS 提供了一些属性，恰好可以让我们解决这个问题：
@font-face {  font-family: 'JetBrains Mono';  // ...  size-adjust: 94%;  ascent-override: 92%;  descent-override: 22%;  line-gap-override: 0%;}
我通过 size-adjust: 94% 将 JetBrains Mono 的整体视觉大小缩小了一点，然后用 ascent-override 等属性微调了它的垂直对齐基线，最终让它和我的正文字体放在一起时，看起来没那么突兀了。
 流式排版
每个人阅读博客的设备都各不相同，有用电脑的，有用平板的，有用手机的，有用小天才手表的（有吗？）。不同设备的屏幕尺寸不同，我们通常需要在多个端点处使用媒体查询来手动调整 font-size。例如：
@media (min-width: 768px) { body: font-size: 17px; } }
这很繁琐，要知道现在世界上有多少种屏幕尺寸，一个个适配过去会累死掉。更优雅的解决方案是采用流式排版，即让字体大小像液体一样，随着屏幕宽度的变化而平滑、无缝地缩放，确保在任意设备宽度下都有最佳的视觉表现。实现这种效果，要用到 clamp() 方法。
:root {  --font-size-body: clamp(1rem, 0.9rem + 0.5vw, 1.125rem); /* 从16px平滑过渡到18px */  --font-size-h1: clamp(2rem, 1.5rem + 2.5vw, 3rem);       /* 从32px平滑过渡到48px */  // ...}
clamp() 的三个参数分别是：
最小值
首选值
最大值
 告别 jQuery 和 Font Awesome
优化完字体系统后，可以想想图标字体该怎么办。我的原先方案是用 Font Awesome，实际上也不是一个很好的选择。Font Awesome 是用传统的网络请求加载的，也会导致不必要的性能和阻塞渲染问题。最好的方案是使用 SVG。很多时候我们的网站只会用到一些图标字体，为此下载一整个完整字体库很没必要，SVG 的可访问性也更好。
我同时又检查了一遍博客的代码，发现主题的所有功能都被原生 JavaScript 实现。因此我移除了 jQuery 依赖。其实我都不是很明白这个主题哪里用到了 jQuery，可能是主题作者先前留下的。
 提升交互体验
Cytrogenhttps://blog.cytrogen.icu
2026-09-17T20:47:54.415ZPost Link在阅读了 这篇文章 之后，我为我的网站添加了一些可以交互的内容。主要添加的是一个「返回顶部」按钮，移动端上它会显示在顶部居中的位置，桌面端则固定显示在右下角。
回复：https://taxodium.ink/my-blog-design.html
先前在 这一节 里的例子里提到的动画、基于 
 的菜单我也实现了。
 无障碍增强
我几乎是不会考虑「无障碍」的，过去的时候。在阅读了一些博客网站的设计想法时我意识到，实际上用着「不寻常设备」的读者可能比想象中还要多，总是要确保所有的用户都能良好地使用博客功能。当然，不只是博客，未来开发的网站也要想到这一点才行。这次重构中，我添加了一个跳过导航的按钮，它平日会被藏在屏幕视图的上方，需要使用 Tab 才可以将其唤出。Tab 也可以用来快速导航到下一个标题、链接、代码块等。
我也为正文链接添加了下划线，有用到 text-decoration-skip-ink: auto 这个属性，可以自动跳过字形，例如拉丁字符 g、j 等。


Svg2SvgIcon：将 SVG 转为 Material-UI SvgIcon
2025-08-10T18:23:04.000Z
我有时候会根据自己当前的需求，写一些简单的小工具。现在希望将这些工具背后的思考和成果整理成博客文档，分享给有着同样需求的朋友们。
 前言
作为一名常用 Material-UI 的开发者，我经常需要将各种 SVG 图标集成到项目中。虽然 Material-UI 本身提供了丰富的图标库，但很多时候我们还是会遇到需要自定义图标的情况。例如在网站的落地页上加一个大大的 logo，把它设置成五彩斑斓的黑色……
过去要这么做，得手动封装 SVG、将其转换为 React 组件。这么搞很浪费时间，我因此萌生出将其自动化的想法、写了 Svg2SvgIcon。
 Svg2SvgIcon
Svg2SvgIcon 是一个纯客户端的在线转换工具，它可以将任意 SVG 代码或文件、快速转换为可以直接在你的 React 项目中使用的 Material-UI SvgIcon 组件。
点击这里传送。
或者自行复制到浏览器内：
https://svg2svgicon.cytrogen.icu/
 核心功能
该工具的核心设计理念是高效、易用和安全。纯客户端意味着你上传或粘贴的任何 SVG 数据都只会在你的浏览器中进行处理、不会发送到任何服务器，最大限度地保障了你的隐私和数据安全。
以下是 Svg2SvgIcon 的主要功能：
智能的 viewBox 解析：自动读取 SVG 中已有的 viewBox 属性
若 viewBox 不存在，会使用 SVG 的 width 和 height 属性来生成
若以上全无，则默认使用 0 0 24 24，确保图标能正确显示
实时预览与控制器：在输入或修改 SVG 后，你可以立即在预览窗口中看到转换后的图标效果
提供实时控制器，方便你精确调整 viewBox 的 min-x、min-y、width 和 height 值，所有调整都会立刻反映在预览图标上
提供「重置」按钮，一键恢复到原始的 viewBox 值
全面的 SVG 解析能力：支持解析嵌套元素，例如  标签
正确处理并转换行内的 style 属性为 React 的 style 对象
内置错误控制台：内置一个可抽拉的错误控制台，当发生解析错误时会自动滑出提示
右下角的浮动按钮会用红点标记未读错误，方便你随时查看
一键复制自动生成可以直接在项目中使用的 React 组件代码，并提供「一键复制」功能
 如何使用
使用 Svg2SvgIcon 非常简单，只需几步：
输入 SVG 或者上传一个 .svg 文件
为即将生成的 React 组件起一个合适的名称
点击「转换 SVG」按钮，右侧会立刻显示图标预览和生成的代码
（可选）调整 viewBox
点击「复制代码」按钮，然后将代码粘贴到你的 React 项目中即可使用
 技术栈与开源
Svg2SvgIcon 的核心技术栈非常精简：
React
Material-UI
DOMParser
这个项目已在 GitHub 上开源，并采用 MIT 许可证。


Hexo 源代码分析【2】：「generate」的奇幻漂流
2025-07-24T04:00:00.000Z
使用 Hexo，痛骂 Hexo，理解 Hexo，成为 Hexo。
这篇文章是用来记录我阅读 Hexo 源代码的过程和分析。
其实这篇文章去年暑假就在筹备写，但是当时的思维被局限在了线性的代码导览。
看过 上一篇文章 的朋友应该能明显感觉出，一个小小的 index.js 都能 水 写那么多内容，很多还是占篇幅的代码。实际上根本不需要把代码一次又一次贴出来，只要贴出来最核心的几行代码就好了，难道真的会有人去跟着我的文章去一个一个对 Hexo 的源代码吗 2333。重点还得是如何用文字描述内容、让读者更聚焦。
那么我又为什么没有继续写第二篇了呢？自然不是因为我又鸽了 （当然可能性不是零），而是我当时计划写 Hexo 的 extend 目录，即扩展（官方文档 /api 路由下就能在左侧边栏看到蓝蓝的 扩展 二字，它包含了控制台、部署器、过滤器等 Hexo 很核心的内容。而这就是问题所在，它并不是一个线性的代码、和第一篇的入口文件 index.js 不一样。extend 目录下的模块那么多，逐一分析过去非常耗时并且容易失去焦点，我那样写又是折磨自己还折磨读者，花费那么多精力根本不讨好。
问题又来了：我为什么又跑来写这个第二篇，并且在开头加了这么长一个警告块？
答案很简单，因为我在睡梦中受高人指点。高人曰：「不要做代码的导游，要做故事的讲述者。」
我顿时恍然大悟，之前那种线性分析方法，就像是拿着一本字典，一页一页地给读者讲定义、枯燥且乏味。而一个优秀的技术分享，应该像一部引人入胜的侦探小说、有一条清晰的主线。巴拉巴拉，这个这个，那个那个。开玩笑的。
所以这篇文章的风格将会和上一篇不同。我们不再按部就班地解刨 extend 目录下的每一个文件，而是会以一个核心的用户行为为线索，将这些分散的扩展模块串联起来，讲述一个它们如何协同工作的完整故事。这意味着本文会更侧重于流程、数据流和模块间的交互，而不是孤立地分析某个函数的实现。
实际上写完后感觉风格没变多少，晕。
在 上一篇文章 中，我们了解了 Hexo 源代码中的入口文件，并且在没有讲太多细节的情况下过了一遍 Hexo 运行的流程：
class Hexo extends events_1.EventEmitter {  constructor(base = process.cwd(), args = {}) { ... }  _bindLocals() { ... }  init() { ... }  call(name, args, callback) { ... }  model(name, schema) { ... }  resolvePlugin(name, basedir) { ... }  loadPlugin(path, callback) { ... }  _showDrafts() { ... }  load(callback) { ... }  watch(callback) { ... }  unwatch() { ... }  _generateLocals() { ... }  _runGenerators() { ... }  _routerRefresh(runningGenerators, useCache) { ... }  _generate(options = {}) { ... }  exit(err) { ... }  execFilter(type, data, options) { ... }  execFilterSync(type, data, options) { ... }}
简单来说是：
初始化了各种目录路径、设置环境变量、初始化各种扩展，设置配置、日志、渲染器、路由等。
_bindLocals 方法将数据库中的数据绑定到 locals 对象上。
init 方法初始化 Hexo，加载插件和配置。
call 方法调用控制台命令。
model 方法创建或获取数据库模型。
resolvePlugin 和 loadPlugin 方法用于解析和加载插件。
load 和 watch 方法加载数据并处理源文件，watch 方法还会设置文件监听。
_generate 方法生成静态文件。
exit 方法退出程序，执行清理工作。
但一个静态的类如何响应我们的命令，并将一堆散乱的 Markdown 文件变成一个精美的网站的呢？
熟悉 Hexo 的朋友都知道，我们最常用的命令之一 —— hexo generate —— 就是用来做这个的，而这篇文章要剥下 hexo generate 的皮，看看 Hexo 的核心是如何运作的。
 1. 解析命令
无奖竞猜：当我们在终端敲下 hexo generate 时，Hexo 中第一个被激活的部件是什么？
答案是 Console 扩展。
我们可以把它想象成 Hexo 的「总机」或者「前台」。它的核心职责就是：接收你输入的命令，然后把它转接给正确的内部处理函数。这个过程分为两步：注册 和 调用
一个命令能被调用，前提是它得先被「注册在案」。这个注册过程发生在 Hexo 的初始化阶段，也就是 hexo.init() 方法中。记性很好的朋友应该可以瞬间想起这行关键代码：
require('../plugins/console')(this);
这行代码会加载 Hexo 内置的所有控制台命令。对于 generate 命令，它会执行 /plugins/console/index.js 文件中的代码，该文件负责注册包括 generate 在内的多个核心命令。我们来看 generate 的注册部分：
console.register('generate', 'Generate static files.', {  options: [    { name: '-d, --deploy', desc: 'Deploy after generated' },    { name: '-f, --force', desc: 'Force regenerate' },    { name: '-w, --watch', desc: 'Watch file changes' },    { name: '-b, --bail', desc: 'Raise an error if any unhandled exception is thrown during generation' },    { name: '-c, --concurrency', desc: 'Maximum number of files to be generated in parallel. Default is infinity' }  ]}, require('./generate'));
register 方法在这里接收了四个参数：
name：命令名称
desc：命令描述
options：定义了所有 hexo g 支持的命令行参数，比如我们 -d（生成完成后部署）和 -w（监视文件变动）
fn：命令的执行函数。这里通过 require('./generate') 加载了同目录下的 generate.js 文件，该文件导出的 generateConsole 函数就是 generate 命令的真正入口：
 function generateConsole(args = {}) {  const generator = new Generater(this, args);  // 这个类之后会提起  if (generator.watch) {    return generator.execWatch();  }  return this.load().then(() => generator.firstGenerate()).then(() => {    if (generator.deploy) {      return generator.execDeploy();    }  });}module.exports = generateConsole;
这样一来，generate 命令、它的描述、它的所有参数，以及它的执行函数，就通过这几行代码被清晰地关联起来，并存放在 hexo.extend.console 这个登记簿内。
注册完成后，当 hexo-cli 工具解析到你的 generate 命令时，它就会调用我们在 Hexo 类中看到的方法：hexo.call('generate', args)。
也就是这一段：
call(name, args, callback) {  if (!callback && typeof args === 'function') {    callback = args;    args = {};  }  const c = this.extend.console.get(name);  // 1. 从登记簿里查找命令  if (c)    return Reflect.apply(c, this, [args]).asCallback(callback); // 2. 执行找到的函数  return bluebird_1.default.reject(new Error(`Console \`${name}\` has not been registered yet!`));}
就这样，通过注册和调用这两步简单的操作，Hexo 的 Console 扩展干净利落地完成了它的使命…… 可喜可贺、可喜可贺。
现在 generateConsole 函数接过了指挥棒，而它要做的第一件事，就是调用 this.load()。
 2. 原材料加工
我们来看 this.load 方法的核心：
load(callback) {  return (0, load_database_1.default)(this).then(() => {  // 确保数据库已加载    this.log.info('Start processing');    return bluebird_1.default.all([      this.source.process(),  // 我们的主角      this.theme.process()    ]);  }).then(() => {    mergeCtxThemeConfig(this);    return this._generate({ cache: false });  }).asCallback(callback);}
this.load() 的任务很明确：将 source 文件夹里所有零散的文件，加工成结构化、可供后续使用的内存数据。
this.source.process() 是故事的起点。那么 this.source 是什么？它的 process() 方法又是什么？
 2.1. Box 类
在 Hexo 类的结构函数中，this.source 被实例化：
const source_1 = __importDefault(require("./source"));this.source = new source_1.default(this);
而 Source 类的定义出奇地简单：
"use strict";var __importDefault = (this && this.__importDefault) || function (mod) {  return (mod && mod.__esModule) ? mod : { "default": mod };};const box_1 = __importDefault(require("../box"));class Source extends box_1.default {  constructor(ctx) {    super(ctx, ctx.source_dir);    this.processors = ctx.extend.processor.list();  }}module.exports = Source;//# sourceMappingURL=source.js.map
原因也很简单：Source 类继承自 Box 类。记性很好的朋友此时就要一拍脑袋了：上一篇文章 提到过。
当我们调用 this.source.process() 时，我们实际上是在调用 Box 类中定义的 process 方法：
process(callback) {  const { base, Cache, context: ctx } = this;  return (0, hexo_fs_1.stat)(base).then(stats => {    if (!stats.isDirectory())      return;    // Check existing files in cache    const relativeBase = escapeBackslash(base.substring(ctx.base_dir.length));    const cacheFiles = Cache.filter(item => item._id.startsWith(relativeBase)).map(item => item._id.substring(relativeBase.length));    // Handle deleted files    return this._readDir(base)      .then((files) => cacheFiles.filter((path) => !files.includes(path)))      .map((path) => this._processFile(file_1.default.TYPE_DELETE, path));  }).catch(err => {    if (err && err.code !== 'ENOENT')      throw err;  }).asCallback(callback);}
Box 类是 Hexo 通用的文件处理引擎。它的 process 方法负责扫描指定目录（这里的话扫描的是 source/）、与缓存对比、找出被删除/新增/修改的文件，然后为每个文件调用 _processFile 方法：
_processFile(type, path) {  if (this._processingFiles[path]) {    return bluebird_1.default.resolve();  }  this._processingFiles[path] = true;  const { base, File, context: ctx } = this;  this.emit('processBefore', {    type,    path  });  return bluebird_1.default.reduce(this.processors, (count, processor) => {    const params = processor.pattern.match(path);    if (!params)      return count;    const file = new File({      // source is used for filesystem path, keep backslashes on Windows      source: (0, path_1.join)(base, path),      // path is used for URL path, replace backslashes on Windows      path: escapeBackslash(path),      params,      type    });    return Reflect.apply(bluebird_1.default.method(processor.process), ctx, [file])      .thenReturn(count + 1);  }, 0).then(count => {    if (count) {      ctx.log.debug('Processed: %s', (0, picocolors_1.magenta)(path));    }    this.emit('processAfter', {      type,      path    });  }).catch(err => {    ctx.log.error({ err }, 'Process failed: %s', (0, picocolors_1.magenta)(path));  }).finally(() => {    this._processingFiles[path] = false;  }).thenReturn(path);}
_processFile 则是处理单个文件的核心，它会遍历一个名为 this.processors 的数组，用数组中的每个 processor 的 pattern 与文件路径进行匹配。如果匹配成功，就执行该 processor 的 process 方法。
那么，this.processors 这个关键的数组是从哪里来的呢？这引出了 Processor 的注册机制。
 2.2. Processor 扩展
Processor 扩展遵循一个清晰的注册与加载流程。
首先是注册，在 hexo.init() 阶段，Hexo 会加载 /plugins/processor/index.js 文件，该文件负责注册所有内置的 Processor：
"use strict";module.exports = (ctx) => {  // 1. 从 Hexo 上下文中获取 processor 扩展的注册器实例  const { processor } = ctx.extend;  // 2. 定义一个内部的 register 辅助函数  function register(name) {    // 2.1. 加载指定 processor 的定义文件    const obj = require(`./${name}`)(ctx);    // 2.2. 调用注册器实例的 register 方法    // 将 processor 的 pattern 和 process 函数正式注册到 Hexo 的扩展管理器中    processor.register(obj.pattern, obj.process);  }  // 3. 为每一个内置的 processor 调用 register 函数  register('asset');  // 静态资源处理器  register('data');   // _data 目录处理器  register('post');   // 文章处理器};//# sourceMappingURL=index.js.map
接着是加载。当 new source_1.default(this) 执行时，Source 类的构造函数会从 Processor 扩展的注册器中，获取所有已注册的 Processor 列表，并赋值给自身的 this.processors 属性。
class Source extends box_1.default {  constructor(ctx) {    super(ctx, ctx.source_dir);    // 从 ctx.extend.processor.list() 获取完整的 processor 列表    this.processors = ctx.extend.processor.list();  }}
至此，调用链完全闭合：
init 阶段，/plugins/processor/index.js 将 post 等处理器注册到 hexo.extend.processor。
Source 实例将 hexo.extend.processor 的完整列表复制到自身的 this.processors 数组中。
source.process() 调用 _processFile，_processFile 遍历 this.processors 数组，从而找到了 post 处理器来处理匹配的文件。
 2.3. post 处理器
现在我们以 _posts/hello-world.md 为例，看看 post 处理器是如何工作的。
 2.3.1. 资格审查
当 hello-world.md 开始要被 Box 引擎处理时，它首先会遇到 post 的资格审查。
post 会通过其 pattern 函数来决定是否处理一个文件。这个函数非常智能，它不仅仅是匹配路径，更是进行了一系列的检查：
module.exports = (ctx) => {  return {    pattern: new hexo_util_1.Pattern(path => {      // 1. 临时的文件直接拒绝      if ((0, common_1.isTmpFile)(path))        return;      // 2. 文件必须来自 _posts/ 或者 /_drafts 目录      let result;      if (path.startsWith(postDir)) {        result = {          published: true,          path: path.substring(postDir.length)        };      }      else if (path.startsWith(draftDir)) {        result = {          published: false,          path: path.substring(draftDir.length)        };      }      // 3. 隐藏的文件直接拒绝      if (!result || (0, common_1.isHiddenFile)(result.path))        return;      // 4. 判断其可渲染性（ctx.render 会在下一章提起）      result.renderable = ctx.render.isRenderable(path) && !(0, common_1.isMatch)(path, ctx.config.skip_render);      // 5. 处理文章资源文件夹      // 如果开启了 post_asset_folder，那么只有和默认文章扩展名相同的文件才被认为是可渲染的文章      if (result.renderable && ctx.config.post_asset_folder) {        result.renderable = ((0, path_1.extname)(ctx.config.new_post_name) === (0, path_1.extname)(path));      }      return result;    }),  };};
这个函数返回的 result 对象，会被 Box 附加到 File 实例的 params 属性上，供 process 函数使用。
 2.3.2. 分流与处理
post 处理器的 process 函数会读取 file.params.renderable 的值，决定下一步操作：
module.exports = (ctx) => {  return {    process: function postProcessor(file) {      // 如果可渲染，就作为文章处理      if (file.params.renderable) {        return processPost(ctx, file);      }      // 否则，如果开启了 post_asset_folder，则作为文章的静态资源处理      else if (ctx.config.post_asset_folder) {        return processAsset(ctx, file);      }    }  }}
 2.3.3. 精加工与入库
当 process 函数决定一个文件是 可渲染的 文章时，它就会把 file 对象交给 processPost 函数。这个函数使整个 Processor 中最复杂的部分，它的任务是 读取文件、解析并融合所有元数据，最后将结构化的文章数据存入数据库。
整个过程可以分解为以下几个关键步骤：
准备与前置处理
函数首先会进行一些准备工作，并处理几种简单的文件状态。
 function processPost(ctx, file) {  const Post = ctx.model('Post');  const { path } = file.params;  const doc = Post.findOne({ source: file.path });  // 1. 检查数据中是否已存在该文章  const { config } = ctx;  const { timezone: timezoneCfg, updated_option, use_slug_as_post_title } = config;  let categories, tags;  // 2. 根据文件类型进行处理  if (file.type === 'skip' && doc) {    return; // 文件未修改，直接跳过  }  if (file.type === 'delete') {    if (doc) {      return doc.remove();  // 文件已删除，从数据库移除    }    return;  }
异步读取与初步解析
对于 create 或 update 状态的文件，处理正式开始。Hexo 会并行地执行两个异步操作：读取文件内容和获取文件系统状态。
 return bluebird_1.default.all([  file.stat(),  // 获取文件系统信息，例如创建、修改时间  file.read()   // 读取文件内容]).spread((stats, content) => {  // 1. 解析 Front-matter  const data = (0, hexo_front_matter_1.parse)(content);  // 2. 解析文件名  const info = parseFilename(config.new_post_name, path);
hexo_front_matter_1.parse(content) 会将文件头部的 YAML Front-matter（--- 开头）解析成一个 JavaScript 对象 data。文件的正文内容会存放在 data._content 属性中：
 function parse(str, options) {  if (typeof str !== 'string')    throw new TypeError('str is required!');  const splitData = split(str);  const raw = splitData.data;  if (!raw)    return { _content: str };  let data;  if (splitData.separator.startsWith(';')) {    data = parseJSON(raw);  }  else {    data = parseYAML(raw, options);  }  if (!data)    return { _content: str };  // Convert timezone  Object.keys(data).forEach(key => {    const item = data[key];    if (item instanceof Date) {      data[key] = new Date(item.getTime() + (item.getTimezoneOffset() * 60 * 1000));    }  });  data._content = splitData.content;  return data;}exports.parse = parse;
parseFilename 函数则会根据我们在 _config.yml 中配置的 new_post_name 格式，从文件名中尝试提取 year、month、day、title 等信息，存放在 info 对象中：
 function parseFilename(config, path) {  config = config.substring(0, config.length - (0, path_1.extname)(config).length);  path = path.substring(0, path.length - (0, path_1.extname)(path).length);  if (!permalink || permalink.rule !== config) {    permalink = new hexo_util_1.Permalink(config, {      segments: {        year: /(\d{4})/,        month: /(\d{2})/,        day: /(\d{2})/,        i_month: /(\d{1,2})/,        i_day: /(\d{1,2})/,        hash: /([0-9a-f]{12})/      }    });  }  const data = permalink.parse(path);  if (data) {    if (data.title !== undefined) {      return data;    }    return Object.assign(data, {      title: (0, hexo_util_1.slugize)(path)    });  }  return {    title: (0, hexo_util_1.slugize)(path)  };}    
数据融合与标准化
这是 processPost 最核心的部分。它会将上一步得到的 data 和 info，以及 stats 这三个来源的数据进行智能融合，并进行标准化处理，最终形成一篇完整、规范的文章数据。
这个融合过程遵循明确的优先级：Front-matter > 文件名 > 文件系统信息。
元数据确定逻辑：
slug 和 source：直接从文件名解析结果或文件路径中获取
title：优先使用 Front-matter 中的 title。如果没有，并且 use_slug_as_post_title 配置为 true，则会使用从文件名中解析出的 slug 作为标题
date：优先使用 Front-matter 中的 date
其次尝试从文件名中解析（info.year 等）
最后使用文件的创建时间 stats.birthtime
updated：优先使用 Front-matter 里的
其次根据 _config.yml 的 updated_options 配置，可能使用 date 的值或者留空
最后默认使用文件的修改时间 stats.mtime
tags 和 categories：函数会进行标准化处理，确保它们最终都是数组格式，并处理了 tag（单数）-> tags（复数）这种别名情况
 const keys = Object.keys(info);data.source = file.path;data.raw = content;data.slug = info.title;if (file.params.published) {  if (!Object.prototype.hasOwnProperty.call(data, 'published'))    data.published = true;}else {  data.published = false;}for (let i = 0, len = keys.length; i < len; i++) {  const key = keys[i];  if (!preservedKeys[key])    data[key] = info[key];}// use `slug` as `title` of post when `title` is not specified.// https://github.com/hexojs/hexo/issues/5372if (use_slug_as_post_title && !('title' in data)) {  data.title = info.title;}if (data.date) {  data.date = (0, common_1.toDate)(data.date);}else if (info && info.year && (info.month || info.i_month) && (info.day || info.i_day)) {  data.date = new Date(info.year, parseInt(info.month || info.i_month, 10) - 1, parseInt(info.day || info.i_day, 10));}if (data.date) {  if (timezoneCfg)    data.date = (0, common_1.timezone)(data.date, timezoneCfg);}else {  data.date = stats.birthtime;}data.updated = (0, common_1.toDate)(data.updated);if (data.updated) {  if (timezoneCfg)    data.updated = (0, common_1.timezone)(data.updated, timezoneCfg);}else if (updated_option === 'date') {  data.updated = data.date;}else if (updated_option === 'empty') {  data.updated = undefined;}else {  data.updated = stats.mtime;}if (data.category && !data.categories) {  data.categories = data.category;  data.category = undefined;}if (data.tag && !data.tags) {  data.tags = data.tag;  data.tag = undefined;}categories = data.categories || [];tags = data.tags || [];if (!Array.isArray(categories))  categories = [categories];if (!Array.isArray(tags))  tags = [tags];if (data.photo && !data.photos) {  data.photos = data.photo;  data.photo = undefined;}if (data.photos && !Array.isArray(data.photos)) {  data.photos = [data.photos];}if (data.permalink) {  data.__permalink = data.permalink;  data.permalink = undefined;}
数据库持久化
当所有数据都准备就绪后，便进入了最终的数据库操作阶段。
   if (doc) {  // 如果在步骤一中找到了记录    if (file.type !== 'update') {      ctx.log.warn(`Trying to "create" ${(0, picocolors_1.magenta)(file.path)}, but the file already exists!`);    }    // 文件已存在，执行更新操作    return doc.replace(data);  }  // 文件是新增的，执行插入操作  return Post.insert(data);})
建立关联
数据入库后，工作还没有完全结束。
insert/replace 操作会返回一个 Promise，其结果是处理后的数据库文档 doc。接下来的 .then() 中，Hexo 会完成最后一步：建立模型之间的关联。
 .then(doc => bluebird_1.default.all([    doc.setCategories(categories),  // 将文章与分类模型关联    doc.setTags(tags),              // 将文章与标签模型关联    scanAssetDir(ctx, doc)          // 如果开启，处理文章的资源文件夹  ]));}
doc.setCategories 和 doc.setTags 方法会处理 categories 和 tags 数组，在 Category、Tag 以及中间关联表中创建或更新记录。这使得我们之后可以轻松地通过 post.tags 或 category.posts 来查询关联数据。
至此，processPost 的全部工作完成。一篇原始的 Markdown 文件，经过这一系列精密的加工，已经变成了一条结构完整、关系清晰的数据库记录。
 3. 从 Markdown 到 HTML
上一章，我们看到 post 处理器将 Markdown 源文件加工成了包含 _content（原始 Markdown 文本）的数据库记录。但此时，文章的 content 属性仍然是空的。从 _content 到 content（渲染后的 HTML），是整个生成过程中最关键的「炼金」步骤。
这个转换不是在 source.process() 阶段发生的，而是在稍后的一个特殊时机，由 Filter 机制驱动。
 3.1. before_generate 过滤器
在 _generate 方法的核心逻辑中，_runGenerators 执行之前，有一个关键的前置步骤：
_generate(options = {}) {  if (this._isGenerating)    return;  const useCache = options.cache;  this._isGenerating = true;  this.emit('generateBefore');  return this.execFilter('before_generate', null, { context: this })  // 在这里    .then(() => this._routerRefresh(this._runGenerators(), useCache)).then(() => {    this.emit('generateAfter');    return this.execFilter('after_generate', null, { context: this });  }).finally(() => {    this._isGenerating = false;  });}
execFilter 方法会执行所有注册在 before_generate 这个钩子上的函数。Hexo 默认在这里注册了一个名为 renderPostFilter 的过滤器，它的任务就是：确保所有文章在生成页面蓝图之前，都已经被渲染成 HTML。
这个过滤器的注册和定义如下：
"use strict";module.exports = (ctx) => {  const { filter } = ctx.extend;  // 注册 render_post.js 到 before_generate 钩子  filter.register('before_generate', require('./render_post'));};//# sourceMappingURL=index.js.map
"use strict";var __importDefault = (this && this.__importDefault) || function (mod) {  return (mod && mod.__esModule) ? mod : { "default": mod };};const bluebird_1 = __importDefault(require("bluebird"));function renderPostFilter() {  // 定义一个处理指定模型的函数  const renderPosts = model => {    // 1. 找出所有 content 属性为 null 的文章/页面    const posts = model.toArray().filter(post => post.content == null);    // 2. 遍历这些未渲染的条目    return bluebird_1.default.map(posts, (post) => {      // 2.1. 将原始 Markdown 内容赋值给 content      post.content = post._content;      // 2.2. 调用核心的渲染方法      return this.post.render(post.full_source, post).then(() => post.save());    });  };  // 并行处理 Post 和 Page 两个模型  return bluebird_1.default.all([    renderPosts(this.model('Post')),    renderPosts(this.model('Page'))  ]);}module.exports = renderPostFilter;//# sourceMappingURL=render_post.js.map
 3.2. post.render
this.post.render 是整个内容转换过程的核心。它确保了 Markdown 在转换为 HTML 的过程中，内嵌的特殊标签（例如 Swig 模版标签）不会被破坏，并且能被正确地执行。
那么 this.post.render 从哪里来的？回到 Hexo 实例：
const post_1 = __importDefault(require("./post"));this.post = new post_1.default(this);
我们再来深入 Post 类的 render 方法：
render(source, data = {}, callback) {  const ctx = this.context;  const { config } = ctx;  const { tag } = ctx.extend;  // 文件读取和非文章类型文件的处理逻辑  const ext = data.engine || (source ? (0, path_1.extname)(source) : '');  let promise;  if (data.content != null) {    promise = bluebird_1.default.resolve(data.content);  }  else if (source) {    promise = (0, hexo_fs_1.readFile)(source);  }  else {    return bluebird_1.default.reject(new Error('No input file or string!')).asCallback(callback);  }  const isPost = !data.source || ['html', 'htm'].includes(ctx.render.getOutput(data.source));  if (!isPost) {    return promise.then(content => {      data.content = content;      ctx.log.debug('Rendering file: %s', (0, picocolors_1.magenta)(source));      return ctx.render.render({        text: data.content,        path: source,        engine: data.engine,        toString: true      });    }).then(content => {      data.content = content;      return data;    }).asCallback(callback);  }  let disableNunjucks = ext && ctx.render.renderer.get(ext) && !!ctx.render.renderer.get(ext).disableNunjucks;  if (typeof data.disableNunjucks === 'boolean')    disableNunjucks = data.disableNunjucks;  const cacheObj = new PostRenderEscape();  // 1. 创建转义工具实例  return promise.then(content => {  // promise 在之前已读取文件内容    data.content = content;    // 2. 执行 before_post_render 过滤器    return ctx.execFilter('before_post_render', data, { context: ctx });  }).then(() => {    // 3. 转义代码和 Swig 标签    data.content = cacheObj.escapeCodeBlocks(data.content);    if (disableNunjucks === false) {      data.content = cacheObj.escapeAllSwigTags(data.content);    }    const options = data.markdown || {};    if (!config.syntax_highlighter)      options.highlight = null;    ctx.log.debug('Rendering post: %s', (0, picocolors_1.magenta)(source));    // 4. 调用核心渲染器    return ctx.render.render({      text: data.content,      path: source,      engine: data.engine,      toString: true,      onRenderEnd(content) {  // 5. 回调        // 5.1. 恢复 Swig 标签        data.content = cacheObj.restoreAllSwigTags(content);        if (disableNunjucks)          return data.content;        // 5.2. 执行 Swig 标签        return tag.render(data.content, data);      }    }, options);  }).then(content => {    // 6. 恢复代码块    data.content = cacheObj.restoreCodeBlocks(content);    // 7. 执行 after_post_render 过滤器    return ctx.execFilter('after_post_render', data, { context: ctx });  }).asCallback(callback);}
这个过程可以分解为七个步骤：
实例化 PostRenderEscape 对象，专门用来「保护」和「恢复」特殊标签
执行一轮 before_post_render 过滤器，允许插件对原始 Markdown 内容进行修改
保护性转义escapeCodeBlocks 和 escapeAllSwigTags 方法会用正则表达式查找所有的代码块和 Nunjucks / Swig 标签（例如 {% post_link %} 或 {{ post.title }}）
它会将这些找出的内容从字符串中「挖」出来，存入 cacheObj.stored 数组，然后在原文中留下一个无害的占位符
这么做的理由是为了让下一步的 Markdown 渲染器知道，这一块是 Nunjucks 语法，不要把它当做普通文本并转义
调用 ctx.render.render()。它会根据文件扩展名（.md）找到对应的渲染器插件，然后调用其 render 方法，将已经被保护起来的 Markdown 文本转换成 HTML。此时生成的 HTML 中依然包含着占位符
Markdown 渲染器完成工作后，onRenderEnd 回调函数会立刻执行，开始逆向工程restoreAllSwigTags 方法被调用。它会查找 HTML 中的所有占位符，并用之前存储在 cacheObj.stored 数组中的原始标签替换它们。现在我们得到了一个混合了 HTML 和 Nunjucks 标签的字符串
tag.render() 被调用、用于处理这个混合字符串，执行其中的 {& post_link &} 等标签，并将其替换为最终的 HTML 片段
经过 Nunjucks 渲染后，restoreCodeBlocks 被调用，以同样的方式将代码块占位符恢复成原始的代码块 HTML
所有渲染和模版执行都已完成。这最后一轮 after_post_render 过滤器让插件有机会对最终生成的 HTML 内容进行处理，例如添加 target="_blank"、图片懒加载等
 3.3. Render 类
ctx.render 是 Render 类的一个实例，它扮演着渲染任务「总调度员」的角色。它不关心具体如何渲染，只负责找到正确的渲染器并把任务交给它。
class Render {  render(data, options, callback) {    // 参数处理和文件读取    if (!callback && typeof options === 'function') {      callback = options;      options = {};    }    const ctx = this.context;    let ext = '';    let promise;    if (!data)      return bluebird_1.default.reject(new TypeError('No input file or string!'));    if (data.text != null) {      promise = bluebird_1.default.resolve(data.text);    }    else if (!data.path) {      return bluebird_1.default.reject(new TypeError('No input file or string!'));    }    else {      promise = (0, hexo_fs_1.readFile)(data.path);    }    return promise.then(text => {      data.text = text;      // 1. 获取文件扩展名      ext = data.engine || getExtname(data.path);      if (!ext || !this.isRenderable(ext))        return text;      // 2. 根据扩展名查找对应的渲染器      const renderer = this.getRenderer(ext);      // 3. 执行渲染器      return Reflect.apply(renderer, ctx, [data, options]);    }).then(result => {      result = toString(result, data);      // 4. 检查并执行 onRenderEnd 回调      if (data.onRenderEnd) {        return data.onRenderEnd(result);      }      return result;    }).then(result => {      // 5. 执行 after_render 过滤器      const output = this.getOutput(ext) || ext;      return ctx.execFilter(`after_render:${output}`, result, {        context: ctx,        args: [data]      });    }).asCallback(callback);  }}module.exports = Render;//# sourceMappingURL=render.js.map
也就是说，核心渲染是由具体的渲染器插件完成的。
 3.3.1. hexo-renderer-marked
hexo-renderer-marked 是 Hexo 默认的 Markdown 渲染器，也是 Renderer 类调度的完美范例。它本身不是一个简单的函数，而是一个集配置、扩展和定制于一体的小系统。
module.exports = function(data, options) {  const { post_asset_folder, marked: markedCfg, source_dir } = this.config;  const { prependRoot, postAsset, dompurify } = markedCfg;  const { path, text } = data;  marked.defaults.extensions = null;  marked.defaults.tokenizer = null;  marked.defaults.renderer = null;  marked.defaults.hooks = null;  marked.defaults.walkTokens = null;  // exec filter to extend marked  this.execFilterSync('marked:use', marked.use, { context: this });  // exec filter to extend renderer  this.execFilterSync('marked:renderer', renderer, { context: this });  // exec filter to extend tokenizer  this.execFilterSync('marked:tokenizer', tokenizer, { context: this });  const extensions = [];  this.execFilterSync('marked:extensions', extensions, { context: this });  marked.use({ extensions });  let postPath = '';  if (path && post_asset_folder && prependRoot && postAsset) {    const Post = this.model('Post');    // Windows compatibility, Post.findOne() requires forward slash    const source = path.substring(this.source_dir.length).replace(/\\/g, '/');    const post = Post.findOne({ source });    if (post) {      const { source: postSource } = post;      postPath = join(source_dir, dirname(postSource), basename(postSource, extname(postSource)));    }  }  let sanitizer = function(html) { return html; };  if (dompurify) {    if (createDOMPurify === undefined && JSDOM === undefined) {      createDOMPurify = require('dompurify');      JSDOM = require('jsdom').JSDOM;    }    const window = new JSDOM('').window;    const DOMPurify = createDOMPurify(window);    let param = {};    if (dompurify !== true) {      param = dompurify;    }    sanitizer = function(html) { return DOMPurify.sanitize(html, param); };  }  marked.use({    renderer,    tokenizer  });  return sanitizer(marked.parse(text, Object.assign({    // headerIds was removed in marked v8.0.0, but we still need it    headerIds: true  }, markedCfg, options, { postPath, hexo: this, _headingId: {} })));};
该渲染器用了 marked 库。
它的入口函数接收从 Renderer 类传来的 data 和 options，然后执行以下步骤：
为了保证每次渲染的纯粹性，它首先会清空 marked 库的默认扩展。然后，它立刻通过 this.execFilterSync 触发三个专属于 marked 的过滤器：
marked:use
marked:renderer
marked:tokenizer
允许其他插件来进一步修改和扩展 marked 的行为，体现了 Hexo 插件系统的层次性。
定义一个 renderer 对象，重写 marked 库的默认渲染行为，以实现 Hexo 的特有功能：
heading：为标题标签自动生成 id 属性，用于页面内锚点跳转，并添加一个可点击的「链接」图标。因此我们能在 Hexo 文章标题旁看到那个小链接图标
link：根据 _config.yml 中的 external_link 配置、自动为外部链接添加 target="_blank" 和 rel="noopener" 等属性
image：智能处理图片路径，可以根据配置自动在图片路径前加上根目录（root），并处理与文章关联的资源文件夹中的图片
paragraph：增加了一个小功能，可以识别特定的语法（Term
: Definition）并将其转换为定义列表（）
 const renderer = {  // Add id attribute to headings  heading({ tokens, depth: level }) {    let text = this.parser.parseInline(tokens);    const { anchorAlias, headerIds, modifyAnchors, _headingId } = this.options;    if (!headerIds) {      return `${text}`;    }    const transformOption = modifyAnchors;    let id = anchorId(text, transformOption);    const headingId = _headingId;    const anchorAliasOpt = anchorAlias && text.startsWith('${text}`;  },  link({ tokens, href, title }) {    const text = this.parser.parseInline(tokens);    const { external_link, sanitizeUrl, hexo, mangle } = this.options;    const { url: urlCfg } = hexo.config;    if (sanitizeUrl) {      if (href.startsWith('javascript:') || href.startsWith('vbscript:') || href.startsWith('data:')) {        href = '';      }    }    if (mangle) {      if (href.startsWith('mailto:')) {        const email = href.substring(7);        const mangledEmail = mangleEmail(email);        href = `mailto:${mangledEmail}`;      }    }    let out = '${text}`;    return out;  },  // Support Basic Description Lists  paragraph({ tokens }) {    const text = this.parser.parseInline(tokens);    const { descriptionLists = true } = this.options;    if (descriptionLists && text.includes('
:')) {      if (rDlSyntax.test(text)) {        return text.replace(rDlSyntax, '$1
$2
');      }    }    return `${text}
\n`;  },  // Prepend root to image path  image({ href, title, text }) {    const { options } = this;    const { hexo } = options;    const { relative_link } = hexo.config;    const { lazyload, figcaption, prependRoot, postPath } = options;    if (!/^(#|\/\/|http(s)?:)/.test(href) && !relative_link && prependRoot) {      if (!href.startsWith('/') && !href.startsWith('\\') && postPath) {        const PostAsset = hexo.model('PostAsset');        // findById requires forward slash        const asset = PostAsset.findById(join(postPath, href.replace(/\\/g, '/')));        // asset.path is backward slash in Windows        if (asset) href = asset.path.replace(/\\/g, '/');      }      href = url_for.call(hexo, href);    }    let out = `';    if (figcaption && text) {      return `${out}${text}
`;    }    return out;  }};
定制 tokenizer，用于影响 marked 如何解析原始的 Markdown 文本
 const tokenizer = {  // Support autolink option  url(src) {    const { autolink } = this.options;    if (!autolink) return;    // return false to use original url tokenizer    return false;  },  // Override smartypants  inlineText(src) {    const { options, rules } = this;    const { quotes, smartypants: isSmarty } = options;    // https://github.com/markedjs/marked/blob/b6773fca412c339e0cedd56b63f9fa1583cfd372/src/Tokenizer.js#L643-L658    const cap = rules.inline.text.exec(src);    if (cap) {      let text;      if (this.lexer.state.inRawBlock || this.rules.inline.url.exec(src)) {        text = cap[0];      } else {        text = escape(isSmarty ? smartypants(cap[0], quotes) : cap[0]);      }      return {        type: 'text',        raw: cap[0],        text      };    }  }};
inlineText 主要是实现了 smartypants 功能，可以将普通的直引号自动转换成更美观的弯引号，以及将多个连字符转换成破折号
 const smartypants = (str, quotes) => {  const [openDbl, closeDbl, openSgl, closeSgl] = typeof quotes === 'string' && quotes.length === 4    ? quotes    : ['\u201c', '\u201d', '\u2018', '\u2019'];  return str    // em-dashes    .replace(/---/g, '\u2014')    // en-dashes    .replace(/--/g, '\u2013')    // opening singles    .replace(/(^|[-\u2014/([{"\s])'/g, '$1' + openSgl)    // closing singles & apostrophes    .replace(/'/g, closeSgl)    // opening doubles    .replace(/(^|[-\u2014/([{\u2018\s])"/g, '$1' + openDbl)    // closing doubles    .replace(/"/g, closeDbl)    // ellipses    .replace(/\.{3}/g, '\u2026');};
在准备好所有定制的 renderer 和 tokenizer 之后，插件通过 marked.use() 将它们应用到 marked 实例上。最后调用 marked.parse()，传入原始文本和所有配置，得到最终的 HTML
如果用户开启了 dompurify 选项，它还会在返回结果前对 HTML 进行一次安全过滤，防止恶意的脚本注入
 4. 页面的生成
还记得第二章最开始出现的那段代码吗？
load(callback) {  return (0, load_database_1.default)(this).then(() => {    this.log.info('Start processing');    return bluebird_1.default.all([      this.source.process(),      this.theme.process()    ]);  }).then(() => {    mergeCtxThemeConfig(this);    return this._generate({ cache: false });  }).asCallback(callback);}
hexo.load() 方法成功地将所有 source 目录下的源文件处理完毕，并将结构化的数据存入了内存数据库（this.database）。也就是说，我们拥有了所有文章、独立页面、分类和标签的原子数据。但是，一个完整的网站还包含许多由这些原子数据聚合而成的页面，例如：首页的文章列表、归档页、分类列表页等。这些页面在 source 目录中并没有对应的源文件。
那么这些「无源之页」是如何被创建的呢？答案就在 Generator 扩展中。上一章节讲到了 this.source.process()，本章节则重点探讨之后的 _generate() 方法，看 Hexo 是如何调用所有 Generator 插件，并生产出网站所有页面的「蓝图」。
眼尖的朋友应该发现了，我跳过了 this.theme.process()。搭建过个人博客的朋友都知道主题这一大山有多么重要，而这段代码就是调用了主题的处理方法。不过本文并不注重于主题，而是注重于「Markdown 文件如何变成网页」这条主线。之后的文章就会讲一讲主题（挖坑）（说实话 Hexo 开发主题也是一堆坑）。
 4.1. _runGenerators 方法解析
Generator 的调用发生在 _generate 方法内部。_generate 会调用 _runGenerators，并将该方法的返回值 —— 一个包含了所有页面蓝图的数组 —— 传递给下一阶段的 _routerRefresh。
_generate(options = {}) {  if (this._isGenerating)    return;  const useCache = options.cache;  this._isGenerating = true;  this.emit('generateBefore');  // Run before_generate filters  return this.execFilter('before_generate', null, { context: this })    .then(() => this._routerRefresh(this._runGenerators(), useCache)).then(() => {    this.emit('generateAfter');    // Run after_generate filters    return this.execFilter('after_generate', null, { context: this });  }).finally(() => {    this._isGenerating = false;  });}
_runGenerators 的职责非常专一：执行所有已注册的 Generator 插件，并收集它们的返回结果。
_runGenerators() {  this.locals.invalidate();  // 1. 准备 Generator 的输入数据（site 对象）  const siteLocals = this.locals.toObject();  // 2. 获取所有已注册的 Generator 函数列表  const generators = this.extend.generator.list();  const { log } = this;  // 3. 遍历并执行所有的 Generator  return bluebird_1.default.map(Object.keys(generators), key => {    const generator = generators[key];    log.debug('Generator: %s', (0, picocolors_1.magenta)(key));    // 4. 执行单个 Generator 函数    return Reflect.apply(generator, this, [siteLocals]);  }).reduce((result, data) => {    // 5. 将所有返回结果合并成一个数组    return data ? result.concat(data) : result;  }, []);}
这里的 this.locals 是 Hexo 实例的一个属性。第一篇文章 中，它被我们分析过的 _bindLocals 方法初始化。_bindLocals 将数据库查询函数与 posts, pages, tags, categories 等键名绑定。
而 this.locals.toObject() 方法的作用，就是执行所有这些绑定的函数，从数据库中查询出最新的数据，并组装成一个巨大的 site 对象。这个对象包含了：
site.posts：一个 Warehouse 模型集合，包含了所有文章
site.pages：包含了所有独立页面
site.categories 和 site.tags：分别包含了所有分类和标签
site.data：包含了 source/_data 目录下的所有数据
这个 site 对象，就是所有 Generator 赖以生存的「食材库」。
看过 Hexo 官方文档 的朋友或许会回忆起，site 对象实际上就是用于模板渲染的局部变量。
 4.2. 页面蓝图 { path, layout, data }
Generator 的核心产出是一种标准化的数据结构，我们可以称之为「页面蓝图」。它不是最终的 HTML，而是描述了如何生成一个页面的指令。
每个蓝图对象通常包含三个核心属性：
path: String - 页面最终生成的文件路径，例如 archives/index.html
layout: String | Array - 渲染这个页面所使用的主题布局文件。例如，'archive' 会对应到主题的 layout/archive.ejs 文件。可以是一个数组，Hexo 会依次查找并使用第一个找到的布局
data: Object - 渲染布局时需要的数据
示例：
一篇文章的蓝图：
  {  "path": "2025/07/23/hello-world/index.html",  "layout": "post",  "data": { "post": { ...文章数据 } }}
归档页的蓝图：
  {  "path": "archives/index.html",  "layout": "archive",  "data": { "posts": site.posts, "page": { "current": 1, ... } }}
 4.3. Generator 的来源
Hexo 默认注册了几个核心的 Generator 来生成网站的基础部分：
post & page：这两个 Generator 负责处理「有源文件」的页面。它们遍历 site.posts 和 site.pages 集合，为每篇文章和每个独立页面生成对应的页面蓝图
archive, category, tag：这三个 Generator 负责处理「无源之页」。它们分别遍历 site.posts, site.categories, site.tags 集合，生成归档页、所有分类页和所有标签页的蓝图
我们可以深入一个具体的 Generator，来了解它是如何利用 site 对象创建页面蓝图的。我们以 archive 生成器为例。
不过在分析之前，有一个关键点需要明确：并非所有核心的生成功能都内置在 Hexo 的主代码库中。Hexo 遵循「保持核心精简」的设计哲学，许多基础功能都是通过 默认插件 提供的。
当我们 hexo init 一个新项目时，package.json 会自动包含 hexo-generator-archive, hexo-generator-category, hexo-generator-tag 等插件。
这意味着：
post & page 生成器位于 Hexo 核心代码库（/plugins/generator/）中，负责处理有源文件的页面
archive、category、tag 等生成器，虽然是默认安装，但它们是独立的 npm 包。它们负责处理无源页面
archive 生成器的核心代码可以分解为三个主要步骤：
生成主归档页
Generator 首先会处理根归档页，也就是 /archives/ 目录。
 'use strict';const pagination = require('hexo-pagination');const fmtNum = num => num.toString().padStart(2, '0');module.exports = function(locals) {  const { config } = this;  let archiveDir = config.archive_dir;  const paginationDir = config.pagination_dir || 'page';  // 1. 获取所有文章，并根据配置排序  const allPosts = locals.posts.sort(config.archive_generator.order_by || '-date');  const perPage = config.archive_generator.per_page;  const result = [];  if (!allPosts.length) return;  if (archiveDir[archiveDir.length - 1] !== '/') archiveDir += '/';  // 2. 定义一个通用的页面蓝图生成函数   function generate(path, posts, options = {}) {    options.archive = true;    // 3. 调用 hexo-pagination 工具生成分页数据    result.push(...pagination(path, posts, {      perPage,      layout: ['archive', 'index'],   // 指定布局      format: paginationDir + '/%d/', // 分页路径格式      data: options    }));  }  // 4. 为根归档页调用 generate 函数  generate(archiveDir, allPosts);
按日期对文章进行分组
如果用户在 _config.yml 中开启了 yearly 或 monthly 归档，Generator 接下来会执行一个精巧的数据预处理步骤：将所有文章按年、月、日进行分组。
 if (!config.archive_generator.yearly) return result;  // 如果没开启，直接返回const posts = {};// 遍历所有文章allPosts.forEach(post => {  const date = post.date;  const year = date.year();  const month = date.month() + 1;  // 创建一个嵌套结构来存储文章  if (!Object.prototype.hasOwnProperty.call(posts, year)) {    posts[year] = [      [],      [],      [],      [],      [],      [],      [],      [],      [],      [],      [],      [],      []    ];  }  posts[year][0].push(post);  // 按年分组  posts[year][month].push(post);  // 按月分组  if (config.archive_generator.daily) {    const day = date.date();  // 按日分组    if (!Object.prototype.hasOwnProperty.call(posts[year][month], 'day')) {      posts[year][month].day = {};    }    (posts[year][month].day[day] || (posts[year][month].day[day] = [])).push(post);  }});
这段代码执行完毕后，会得到一个类似 posts[2025][7] 的数据结构，其中存储了 2025 年 7 月的所有文章。
生成年、月、日归档页
最后，代码会遍历上一步中分组好的 posts 对象，为每个时间单位生成对应的归档页面。
  const { Query } = this.model('Post');  const years = Object.keys(posts);  let year, data, month, monthData, url;  // 遍历年份  for (let i = 0, len = years.length; i < len; i++) {    year = +years[i];    data = posts[year];    url = archiveDir + year + '/';    if (!data[0].length) continue;    // 为该年份生成归档页，例如 /archives/2025/    generate(url, new Query(data[0]), { year });    if (!config.archive_generator.monthly && !config.archive_generator.daily) continue;    // 遍历月份    for (month = 1; month <= 12; month++) {      monthData = data[month];      if (!monthData.length) continue;      if (config.archive_generator.monthly) {        // 为该月份生成归档页，例如 /archives/2025/07/        generate(url + fmtNum(month) + '/', new Query(monthData), {          year,          month        });      }      if (!config.archive_generator.daily) continue;      // 同样逻辑处理按日归档      for (let day = 1; day <= 31; day++) {        const dayData = monthData.day[day];        if (!dayData || !dayData.length) continue;        generate(url + fmtNum(month) + '/' + fmtNum(day) + '/', new Query(dayData), {          year,          month,          day        });      }    }  }  return result;};
通过嵌套循环，Generator 复用了第一步中定义的 generate 辅助函数，为所有存在文章的年、月、日都创建了对应的分页归档页面蓝图。
最终，这个 Generator 返回一个巨大的 result 数组，其中包含了主归档页、以及所有年、月、日归档页的完整页面蓝图。
 5. 路由的建立
_runGenerators 方法为我们产出了一份包含了网站所有页面生成指令的「蓝图清单」。但这些蓝图还只是数据，系统需要一个机制来管理它们，并将它们与最终的文件路径关联起来。
这个机制就是 Hexo 的 Router。
 5.1. Router 类：内存中的 public 目录
在分析 _routerRefresh 之前，我们必须先理解它的工作对象：this.route。这个属性是 Router 类的一个实例。
需要明确的是，Hexo 的 Router 不是 一个网络服务器中的路由（用于匹配 URL 请求），而是一个 内存中的键值对集合，可以理解为一个虚拟的文件系统。
键：将要生成的文件路径，例如 archives/index.html
值：该路径对应的文件内容
Router 类（位于 /lib/hexo/router.js）提供了一系列方法来管理这个集合，核心方法包括 list()、get(path)、set(path, data) 和 remove(path)。
class Router extends events_1.EventEmitter {    constructor() {        super();        this.routes = {}; // 核心数据结构    }    list() {}    format(path) {}    get(path) {}    isModified(path) {}    set(path, data) {}    remove(path) {}}
_routerRefresh 的核心任务便是清空并重新填充这个 this.routes 对象。
 5.2. _routerRefresh
_routerRefresh 方法接收 _runGenerators 返回的蓝图数组作为输入、遍历这个数组、为每一个蓝图在 this.route 中创建一条对应的记录。
_routerRefresh(runningGenerators, useCache) {  const { route } = this;  const routeList = route.list(); // 1. 获取旧的路由列表，用于后续对比  const Locals = this._generateLocals();  // 2. 准备一个 Locals 类的构造器  Locals.prototype.cache = useCache;  // 3. 遍历所有由 Generator 生成的页面蓝图  return runningGenerators.map((generatorResult) => {    if (typeof generatorResult !== 'object' || generatorResult.path == null)      return undefined;    const path = route.format(generatorResult.path);    const { data, layout } = generatorResult;    // 4. 根据蓝图是否有 layout 属性，进行分流处理    if (!layout) {      // 4.1. 没有 layout：视为静态资源      route.set(path, data);      return path;    }    // 4.2. 有 layout：视为待渲染页面    // 这里的 createLoadThemeRoute 是用于将主题的布局文件和页面的具体数据打包成一个待执行的渲染任务、通过 route.set 存入路由系统的    return this.execFilter('template_locals', new Locals(path, data), { context: this })      .then(locals => { route.set(path, createLoadThemeRoute(generatorResult, locals, this)); })      .thenReturn(path);  }).then(newRouteList => {    // 5. 刷新操作：移除所有过时的路由    for (let i = 0, len = routeList.length; i < len; i++) {      const item = routeList[i];      if (!newRouteList.includes(item)) {        route.remove(item);      }    }  });}
_generateLocals 方法见 这里。
这个方法的逻辑非常清晰，但要真正理解，我们需要回到 Router 类。
 5.3. Router 类深度解析
set 方法负责将内容存入路由。它的实现非常巧妙，能够区分处理不同类型的数据。
 set(path, data) {  if (typeof path !== 'string')    throw new TypeError('path must be a string!');  if (data == null)    throw new TypeError('data is required!');  let obj;  if (typeof data === 'object' && data.data != null) {    obj = data;  }  else {    obj = {      data,      modified: true    };  }  // 检查 data 是否为函数  if (typeof obj.data === 'function') {    // 使用 bluebird 将其包装成一个标准的 Promise-returning 函数    if (obj.data.length) {  // 有回调参数的函数      obj.data = bluebird_1.default.promisify(obj.data);    }    else {  // 无参数的函数      obj.data = bluebird_1.default.method(obj.data);    }  }  path = this.format(path); // 格式化路径  this.routes[path] = {    data: obj.data,    modified: obj.modified == null ? true : obj.modified  };  this.emit('update', path);  return this;}
set 方法的逻辑揭示了路由内容的两种形态：
成品（静态资源）：如果传入的 data 是 Buffer 或字符串（比如一张图片的内容），它会被直接存入 this.routes
半成品（待渲染页面）：如果传入的 data 是一个函数（由 createLoadThemeRoute 创建的那个），set 方法会用 bluebird 将其包装成一个标准的异步函数。存入路由的，是这个被包装后的函数本身
这种设计就是 Hexo 高性能的 延迟执行（Lazy Evaluation) 策略的核心。它避免了在生成路由时就渲染所有页面，而是将渲染工作推迟到最后一刻。
如果说 set 方法是把「速冻料理包」（待执行的渲染函数）放入冰箱，那么 get 方法就是从冰箱里取出料理包并准备加热。
get 方法本身很简单，但它返回的东西却大有文章：
 get(path) {  if (typeof path !== 'string')    throw new TypeError('path must be a string!');  const data = this.routes[this.format(path)];  if (data == null)    return;  // 返回一个 RouteStream 实例  return new RouteStream(data);}
它并不直接返回值，而是将从 this.routes 中取出的数据（无论是 Buffer 还是那个待执行的函数）传递给 RouteStream 类的构造函数，并返回一个 RouteStream 实例。
RouteStream 是一个 Node.js 的可读流（Readable Stream)。它的魔法藏在 _read() 方法中：
 class RouteStream extends Readable {  constructor(data) {    super({ objectMode: true });    this._data = data.data;    this._ended = false;    this.modified = data.modified;  }  _toBuffer(data) {    if (data instanceof Buffer) {      return data;    }    if (typeof data === 'object') {      data = JSON.stringify(data);    }    if (typeof data === 'string') {      return Buffer.from(data);    }    return null;  }  _read() {    const data = this._data;    // 情况一：内容是“成品”（Buffer、String 等）    if (typeof data !== 'function') {      const bufferData = this._toBuffer(data);      if (bufferData) {        this.push(bufferData);  // 直接将数据推入流中      }      this.push(null);  // 结束流      return;    }    // 情况二：内容是“半成品”（待执行函数）    if (this._ended)      return false;    this._ended = true;    // 执行函数    data().then(data => {      if (data instanceof stream_1.default && data.readable) {        data.on('data', d => {          this.push(d);        });        data.on('end', () => {          this.push(null);        });        data.on('error', err => {          this.emit('error', err);        });      }      else {        const bufferData = this._toBuffer(data);        if (bufferData) {          this.push(bufferData);  // 将渲染后的 HTML 推入流中        }        this.push(null);  // 结束流      }    }).catch(err => {      this.emit('error', err);      this.push(null);    });  }}
之后我们讲到「文件写入」时，模块会从这个流中读取数据，_read() 方法会被触发。它会检查 this._data：
如果是普通数据，就直接推入流
如果是一个函数，它就会执行这个函数（data()）。渲染过程在这一刻才真正发生。函数执行完毕后（.then()），_read 会将返回的 HTML 结果推入流中，供文件写入模块消费
 6. 从内存到硬盘
经过前面四个阶段的精密运作，Hexo 已经在内存中构建了一个完整的虚拟网站（this.route）。现在，我们来到了这趟旅程的终点站：将这个虚拟世界实体化，写入到硬盘的 public 文件夹中。
这个最终的执行任务，由 generate 命令的总指挥 —— Generater 类 —— 来完成。
 6.1. 怎么又是你 Generator 类
回顾第一章，generateConsole 函数在最开始就实例化了 Generater 类：
function generateConsole(args = {}) {  const generator = new Generater(this, args);  // 我在这儿  if (generator.watch) {    return generator.execWatch();  }  return this.load().then(() => generator.firstGenerate()).then(() => {    if (generator.deploy) {      return generator.execDeploy();    }  });}module.exports = generateConsole;
generator.firstGenerate() 就是文件写入流程的入口。这个方法负责比对文件差异、创建任务队列，并最终调用 writeFile 和 deleteFile 来同步 public 目录。
 6.2. firstGenerate
firstGenerate 方法做的第一件大事，不是写入，而是 比对，以确定一份精准的「施工清单」。
firstGenerate() {  const { concurrency } = this;  const { route, log } = this.context;  const publicDir = this.context.public_dir;  const Cache = this.context.model('Cache');  const interval = (0, pretty_hrtime_1.default)(process.hrtime(this.start));  log.info('Files loaded in %s', (0, picocolors_1.cyan)(interval));  this.start = process.hrtime();  // 确保 public 文件夹存在  return (0, hexo_fs_1.stat)(publicDir).then(stats => {    if (!stats.isDirectory()) {      throw new Error(`${(0, picocolors_1.magenta)((0, tildify_1.default)(publicDir))} is not a directory`);    }  }).catch(err => {    if (err && err.code === 'ENOENT') {      return (0, hexo_fs_1.mkdirs)(publicDir);    }    throw err;  }).then(() => {    const task = (fn, path) => () => fn.call(this, path);    const doTask = fn => fn();    const routeList = route.list(); // 1. 获取本次需要生成的文件清单    const publicFiles = Cache.filter(item => item._id.startsWith('public/')).map(item => item._id.substring(7));  // 2. 获取上次已生成的文件清单    // 3. 生成任务队列    const tasks = publicFiles.filter(path => !routeList.includes(path))      .map(path => task(this.deleteFile, path)) // 需要删除的文件      .concat(routeList.map(path => task(this.generateFile, path)));  // 需要生成/更新的文件    // 4. 并发执行所有任务    return bluebird_1.default.all(bluebird_1.default.map(tasks, doTask, { concurrency: parseFloat(concurrency || 'Infinity') }));  }).then(result => {    const interval = (0, pretty_hrtime_1.default)(process.hrtime(this.start));    const count = result.filter(Boolean).length;    log.info('%d files generated in %s', count.toString(), (0, picocolors_1.cyan)(interval));  });}
这里的逻辑非常清晰：
获取新蓝图：从 this.context.route.list() 获取我们在第四章构建的内存虚拟网站的文件列表
获取旧清单：从 Cache 模型中读取上次生成时写入 public/ 的所有文件记录
计算差异并生成任务：如果一个文件在「旧清单」里，但不在「新蓝图」里，就为它创建一个 deleteFile 任务
所有「新蓝图」里的文件，都为它们创建一个 generateFile 任务
并发执行：使用 bluebird.map 并发处理所有任务，以提高生成效率
 6.3. 触发延迟执行
writeFile 方法是整个流程中最关键的「临门一脚」，它负责触发第四章中我们埋下的「延迟执行」机制。
writeFile(path, force) {  const { route, log } = this.context;  const publicDir = this.context.public_dir;  const Cache = this.context.model('Cache');  // 1. 从路由中获取内容，返回的是一个 RouteStream 实例  const dataStream = this.wrapDataStream(route.get(path));  const buffers = [];  const hasher = (0, hexo_util_1.createSha1Hash)();  const finishedPromise = new bluebird_1.default((resolve, reject) => {    dataStream.once('error', reject);    dataStream.once('end', resolve);  });  // 2. 消费这个流  dataStream.on('data', chunk => {    buffers.push(chunk);    hasher.update(chunk);  });
当我们开始监听 data 事件，也就是开始从流中「拉取」数据时，RouteStream 内部的 _read() 方法就会被触发。
如果这个路由的内容是一个「待执行的渲染函数」，这个函数在此时此刻才会被执行，渲染出最终的 HTML，然后将结果推入流中，被这里的 data 事件监听器接收。
 6.4. 哈希值对比
在 writeFile 方法的后半部分，还隐藏着 Hexo 再次生成时速度飞快的秘密 —— 增量生成。
  return finishedPromise.then(() => {    const dest = (0, path_1.join)(publicDir, path);    const cacheId = `public/${path}`;    const cache = Cache.findById(cacheId);  // 1. 查找上一次的缓存    const hash = hasher.digest('hex');  // 2. 拿到本次内容的哈希值    // 3. 如果哈希值未变，且不是强制生成，则跳过    if (!force && cache && cache.hash === hash) {      return;    }    // 4. 哈希值变了，才执行真正的写入操作    return Cache.save({      _id: cacheId,      hash    }).then(() =>      (0, hexo_fs_1.writeFile)(dest, Buffer.concat(buffers))).then(() => {        log.info('Generated: %s', (0, picocolors_1.magenta)(path));        return true;    });  });}
在将文件内容写入磁盘之前，writeFile 会计算出内容的 SHA1 哈希值，并与缓存中的旧哈希值进行对比。如果两者相同，意味着文件内容没有变化，Hexo 就会聪明地跳过这次文件写入操作，从而极大地提升了二次生成的效率。
 7. 总结
现在，让我们回到最初的起点，以 _posts/hello-world.md 的视角，快速回顾它在 hexo generate 命令下经历的完整旅程：
我们在终端敲下回车，Console 扩展接收到 generate 命令
Box 引擎扫描 source 目录，发现了 hello-world.md。post 处理器接管了它，解析其文件名和 Front-matter，将标题、日期等元数据连同原始 Markdown 内容（_content）一起，存入了数据库的 Post 模型中
在生成页面之前，before_generate 过滤器被触发。renderPostFilter 找到了数据库中 content 字段尚为空的 hello-world.md，并调用 post.render 对其进行「炼金」：post.render 暂时将文中的 Nunjucks 标签（如果有的话）替换为占位符
ctx.render 调度 hexo-renderer-marked 将 Markdown 转换为 HTML
在 onRenderEnd 回调中，post.render 恢复 Nunjucks 标签并立刻执行它们。最终，一篇完整的 HTML 被存入数据库记录的 content 字段
_runGenerators 开始执行。post 生成器遍历数据库，找到了我们已渲染好的 hello-world.md，为它创建了一张包含最终路径、主题布局（layout: 'post'）和所有页面数据的「页面蓝图」
_routerRefresh 接收到这张蓝图。它没有立即渲染整个页面，而是创建了一个「待办任务」—— 一个包含了「使用 post 布局」和「填充 hello-world.md 内容」指令的函数，并将这个任务存入了内存中的 Router 里，键名为最终的文件路径 posts/hello-world/index.html
Generater 类的 firstGenerate 方法开始工作。它对比 Router 和 public 目录的缓存，确定 posts/hello-world/index.html 是一个需要生成的文件，并为其创建了一个 writeFile 任务
当 writeFile 任务执行时，它向 Router 请求 posts/hello-world/index.html 的内容。RouteStream 机制被触发，直到这一刻，第五步中创建的那个「待办任务」才被真正执行。它读取主题的 post 布局文件，将 hello-world.md 的 content（HTML）填充进去，生成了包含页头、页脚的完整页面 HTML
最终的 HTML 内容通过流被写入 public/posts/hello-world/index.html 文件。hello-world.md 的旅程至此结束，它已成为网站上一个可被访问的真实页面


用 JavaScript 自制 GameBoy 模拟器（上）
2025-07-01T04:00:00.000Z
近期有些百无聊赖。因为工作，先前的个人项目全都不得不暂时搁置。为了找点乐子，我决定做一些与全栈开发不同的事情 （主要是最近玩宝可梦玩的有点多）。
这期的文章参考了 Imre Nazar 在 2010 年写的一系列关于 用 JavaScript 实现 GameBoy 模拟器 的教程。虽然这个教程有些年头了，但还是提供了一个很好的起点和思路。自然，这期文章不会直接去 Ctrl C + V 他的实现，而是会使用更现代的 ES6 语法。
 前言
要模拟一台 GameBoy，我们至少需要模拟以下核心组件：
CPU（Z80 兼容处理器），也就是「大脑」，负责执行游戏代码
内存管理单元（MMU），用于处理内存的读写，包括 ROM、RAM 和各种硬件寄存器
图形处理单元（PPU），负责渲染游戏画面
输入设备，处理用户按键操作
定时器，提供精确的时间控制
声音处理单元，生成游戏音效和音乐
 1. 模拟 Z80 CPU
GameBoy 的 CPU 是一个修改过的 Zilog Z80 处理器。要模拟它，就得理解它的工作方式。
核心概念很简单：取指 → 解码 → 执行循环。
取指：从内存中获取下一条指令
解码：解析指令的含义
执行：执行指令指定的操作
这个循环在 GameBoy 上电后就开始运行，直到关机。为了跟踪程序执行到哪里，CPU 会使用一个特殊的寄存器 —— 程序计数器。每当一条指令被取出后，程序计数器就会根据指令的长度向前移动，指向下一条要执行的指令。
Z80 CPU 是一个 8 位芯片，意味着它一次可以处理一个字节的数据。它也能访问多达 6,5536 字节的内存空间，程序代码和普通数据都被存储在同一个内存地址空间中，而一条指令的长度可以在 1 到 3 个字节之间。
除了程序计数器，Z80 CPU 还有一组内存寄存器，用于存储数据和执行计算：
8 位通用寄存器（A、B、C、D、E、H、L），每个可以存储一个字节（0 到 255）的值。大多数 Z80 指令都围绕着操作这些寄存器，例如将内存中的值加载到寄存器中，或者对寄存器中的值进行算术运算
标志寄存器（F）是一个特殊的 8 位寄存器，其中每个位都代表一个「标志」，用于存储上一次运算的结果状态
栈指针（SP）是一个 16 位寄存器，用于指向内存中的「栈顶」位置栈是一种后进先出的数据结构
CPU 是什么？（用大白话说）
不要被「中央处理器」这个名字吓到。
把 CPU 想象成一个超快的计算器工人：
他有一张小纸条（寄存器），记录当前的数字
他有一本操作手册（指令集），告诉他怎么计算
他一次只能做一件事，但做得很快
假设有一个指令是「把 A 和 B 加起来」，那么对于这个工人而言就是：
看看 A 纸条（3）
看看 B 纸条（5）
算出结果（8）
写到 A 纸条上
基本上就是一个只会加减乘除但超级勤快的员工
基于以上理解，我们的 Z80 CPU 模拟器需要包含以下核心组件：
内部状态，需要保存所有寄存器的当前值、执行上一条指令所花费的时间，以及 CPU 总共运行了多长时间
指令模拟函数
指令映射表
内存接口
 1.1. CPU 骨架
下面是我们 GameBoyCPU 类的初步骨架，包含了 CPU 的时钟系统和所有重要的寄存器：
/** * GameBoy Z80 CPU 类 */class GameBoyCPU {  constructor() {    // 时钟系统，跟踪 CPU 执行时间    this.clock = {      m: 0, // 机器周期计数器（主时钟）      t: 0, // 时钟周期计数器，用于精确计时    };    // CPU 寄存器组    this.registers = {      // === 8位通用寄存器 ===      a: 0, // 累加器，主要用于算术运算      // BC寄存器对（可作为16位使用）      b: 0,      c: 0,      // DE寄存器对（同上）      d: 0,      e: 0,      // HL寄存器对（同上；常用作内存指针）      h: 0, // 高位      l: 0, // 低位      f: 0, // 标志寄存器，存储运算结果的状态标志      // === 16位专用寄存器 ===      pc: 0, // 程序计数器，指向下一条要执行的指令      sp: 0, // 栈指针，指向栈顶位置      // === 指令执行时间记录 ===      m: 0,      t: 0,    };  }}
CPU 的时钟系统是用来精确跟踪模拟时间的，m 代表机器周期，t 代表时钟周期，两者之间存在固定关系。
 1.2. 标志寄存器与基本指令
标志寄存器是 CPU 运算中一个非常关键的部分，它会根据上一条指令的执行结果自动设置某些位。在 GameBoy 的 Z80 CPU 中，有四个重要的标志位：
零标志（0x80）：如果上一次运算的结果为 0，则设置此位
减法标志（0x40）：如果上一次运算是减法操作，则设置此位
半进位标志（0x20）：如果上一次运算在字节的低 4 位发生了溢出（即结果的第 3 位向第 4 位进位），则设置此位
进位标志（0x10）：如果上一次加法运算结果超过 255（8 位最大值），或者减法运算结果低于 0（发生借位），则设置此位
看不懂的话……
想象你刚做完一道数学题，你的大脑会自动记住一些「状态」：
「咦，答案是 0？」→ 零标志
「我刚才是在做减法吗？」→ 减法标志
「有没有进位？」→ 进位标志
GameBoy 的 CPU 也是如此。每次计算完，它都会在标志寄存器里记下这些「感想」。
为什么需要这些标志？因为后面的指令可能会问：「上次计算结果是 0 吗？如果是的话，跳转到别的地方。」
为了更好地管理这些标志位，我们首先定义一个常量对象 CPU_FLAGS：
/** * 标志位常量定义 */const CPU_FLAGS = {  ZERO: 0x80,  OPERATION: 0x40,  HALF_CARRY: 0x20,  CARRY: 0x10,};
接着，我们为 GameBoyCPU 类添加 reset、setFlag 和 getFlag 方法：
reset 方法用于将 CPU 的所有寄存器和时钟状态复位到初始值，这对于模拟器启动或重新加载游戏非常有用
setFlag 和 getFlag 则分别用于设置和检查标志位，方便我们根据运算结果来操作标志寄存器 f
// ... 之前的 constructor .../** * CPU 重置，将所有寄存器和时钟复位为初始状态 */reset() {  // 重置所有8位寄存器  this.registers.a = 0;  this.registers.b = 0;  this.registers.c = 0;  this.registers.d = 0;  this.registers.e = 0;  this.registers.h = 0;  this.registers.l = 0;  this.registers.f = 0;  // 重置16位寄存器  this.registers.pc = 0; // 程序从地址0开始执行  this.registers.sp = 0;  // 重置时钟  this.clock.m = 0;  this.clock.t = 0;  console.log('主人~ CPU 已重置到初始状态喵！');}/** * 设置标志位 * @param {number} flag 要设置的标志位 * @param {boolean} condition 是否设置该标志位 */setFlag(flag, condition) {  if（condition) {    this.registers.f |= flag; // 设置位：通过按位或操作将指定标志位设置为 1  } else {    // 否则就清除位：通过按位与操作与指定标志位的补码，将其设置为 0    this.registers.f &= ~flag;  }}/** * 检查标志位是否设置 * @param {number} flag 要检查的标志位 */getFlag(flag) {  return (this.registers.f & flag) !== 0;}
为了演示 CPU 如何执行指令并影响寄存器和标志位，我们来模拟几个基本的 Z80 指令：
ADD A, E（加法指令）：将寄存器 e 的值加到寄存器 a 中，结果存回 a。这个函数需要更新 a 寄存器的值，并根据结果设置零标志和进位标志。
注意，我们将结果限制在 8 位范围内（&= 255），并更新指令执行所花费的机器周期 m 和时钟周期 t。
/** * 将 E 寄存器的值加到 A 寄存器 * 算术指令用：ADD A, E */addRegisterE() {  this.registers.a += this.registers.e;  // 清除所有标志位并准备设置新的  this.registers.f = 0;  // 检查零标志和进位标志  this.setFlag(CPU_FLAGS.ZERO, !(this.registers.a & 255)); // 结果为0则设置零标志  this.setFlag(CPU_FLAGS.CARRY, this.registers.a > 255);   // 结果溢出255则设置进位标志  // 将结果限制为 8 位  this.registers.a &= 255;  // 设置指令执行时间（1 机器周期，4 时钟周期)  this.registers.m = 1;  this.registers.t = 4;}
CP A, B（比较指令）：将寄存器 a 的值与寄存器 b 的值进行比较。这个指令实际上是执行 a - b 的操作，但不保存结果，只根据结果设置标志位。我们需要设置减法标志，并根据比较结果设置零标志（如果 a == b）和进位标志（如果 a < b）。
/** * 比较 B 寄存器和 A 寄存器 * 用于条件判断和循环控制：CP A, B */compareRegisterB() {  // 创建 A 的副本并模拟 A - B  let result = this.registers.a;  result -= this.registers.b;  // 设置减法标志  this.registers.f = CPU_FLAGS.OPERATION;  // 检查 A 是否等于 B（结果为 0）以及 A 是否小于 B（结果为负，产生借位）  this.setFlag(CPU_FLAGS.ZERO, !(result & 255)); // 结果为0则设置零标志  this.setFlag(CPU_FLAGS.CARRY, result < 0);     // 结果为负（下溢）则设置进位标志  // 设置指令执行时间（1 机器周期，4 时钟周期)  this.registers.m = 1;  this.registers.t = 4;}
NOP（无操作指令）：这个指令不做任何事情，仅仅消耗 CPU 周期，用来延时或指令对齐。
/** * 无操作指令，不执行任何操作只是浪费时间 * 延时或指令对齐用：NOP */noOperation() {  this.registers.m = 1;  this.registers.t = 4;}
最后弄个调试工具，要打印出当前所有寄存器的十六进制值、标志位的状态以及时钟技术。
/** * 获取当前 CPU 状态的字符串表示，用于调试 */getStatusString() {  const r = this.registers;  return `CPU状态:  寄存器: A=${r.a.toString(16).padStart(2,'0')} B=${r.b.toString(16).padStart(2,'0')} C=${r.c.toString(16).padStart(2,'0')}          D=${r.d.toString(16).padStart(2,'0')} E=${r.e.toString(16).padStart(2,'0')} H=${r.h.toString(16).padStart(2,'0')} L=${r.l.toString(16).padStart(2,'0')}  标志位: F=${r.f.toString(16).padStart(2,'0')} [Z:${this.getFlag(CPU_FLAGS.ZERO)?1:0} N:${this.getFlag(CPU_FLAGS.OPERATION)?1:0} H:${this.getFlag(CPU_FLAGS.HALF_CARRY)?1:0} C:${this.getFlag(CPU_FLAGS.CARRY)?1:0}]  PC=${r.pc.toString(16).padStart(4,'0')} SP=${r.sp.toString(16).padStart(4,'0')}  时钟: M=${this.clock.m} T=${this.clock.t}`;}
 1.3. 完整指令集与执行循环
在前面我们实现了几个示例指令，但真正的 GameBoy CPU 需要支持完整的 Z80 指令集。现代模拟器的核心是建立一个高效的「取值 → 解码 → 执行」循环，这个循环每秒要执行数百万次。
/** * 指令时序常量（T 周期） */const INSTRUCTION_TIMINGS = {  // 基础指令时序  NOP: 4,              // 0x00: NOP  LD_BC_nn: 12,        // 0x01: LD BC,nn  LD_MEM_BC_A: 8,      // 0x02: LD (BC),A  INC_BC: 8,           // 0x03: INC BC  INC_B: 4,            // 0x04: INC B  DEC_B: 4,            // 0x05: DEC B  LD_B_n: 8,           // 0x06: LD B,n    // 跳转指令  JR_s8: 12,           // 0x18: JR s8  JR_NZ_s8: 8,         // 0x20: JR NZ,s8 (8 if not taken, 12 if taken)  JR_Z_s8: 8,          // 0x28: JR Z,s8    // 算术指令  ADD_A_r: 4,          // 0x80-0x87: ADD A,r  SUB_r: 4,            // 0x90-0x97: SUB r  AND_r: 4,            // 0xA0-0xA7: AND r  CP_r: 4,             // 0xB8-0xBF: CP r    // 其他  HALT: 4,             // 0x76: HALT  RET: 16,             // 0xC9: RET};
指令映射是现代模拟器的核心技术。我们创建了一个 256 元素的数组，每个元素对应一个操作码（opcode），直接指向对应的函数。这避免了复杂的 switch-case 语句，大幅提升执行效率：
/** * 构建指令映射表 */buildInstructionMap() {  const map = new Array(256);  // 基础指令集  map[0x00] = this.nop.bind(this);           // NOP  map[0x01] = this.ld_bc_nn.bind(this);     // LD BC,nn  map[0x02] = this.ld_mem_bc_a.bind(this);  // LD (BC),A  map[0x03] = this.inc_bc.bind(this);       // INC BC  map[0x04] = this.inc_b.bind(this);        // INC B  map[0x05] = this.dec_b.bind(this);        // DEC B  map[0x06] = this.ld_b_n.bind(this);       // LD B,n  // 跳转指令  map[0x18] = this.jr_s8.bind(this);        // JR s8  map[0x20] = this.jr_nz_s8.bind(this);     // JR NZ,s8  map[0x28] = this.jr_z_s8.bind(this);      // JR Z,s8  // 算术指令 - ADD A,r（批量注册）  for (let i = 0x80; i <= 0x87; i++) {    map[i] = this.add_a_r.bind(this, i & 0x07);  }  // 比较指令 - CP r（批量注册）  for (let i = 0xB8; i <= 0xBF; i++) {    map[i] = this.cp_r.bind(this, i & 0x07);  }  // 填充未实现的指令  for (let i = 0; i < 256; i++) {    if (!map[i]) {      map[i] = this.unimplemented.bind(this, i);    }  }  return map;}
CPU 执行的核心是 step() 方法。每次调用它会执行一条指令，这个方法每秒会被调用数百万次：
/** * 执行单条指令 */step() {  if (this.halted || this.stopped) {    // CPU 处于暂停状态，只更新时钟    this.registers.t = 4;    this.registers.m = 1;    this.updateClocks();    return;  }  if (!this.mmu) {    throw new Error('CPU 未连接到 MMU');  }  try {    // 取指令：从 PC 指向的内存地址读取操作码    const opcode = this.mmu.readByte(this.registers.pc);    this.registers.pc = (this.registers.pc + 1) & 0xFFFF;    // 记录指令（用于调试）    this.stats.lastInstruction = opcode;    // 解码并执行：直接通过映射表调用对应函数    this.instructionMap[opcode]();    // 更新统计    this.stats.instructionsExecuted++;    this.stats.lastCycles = this.registers.t;    this.stats.totalCycles += this.registers.t;    // 更新时钟    this.updateClocks();  } catch (error) {    console.error(`❌ CPU 执行错误 PC=0x${this.registers.pc.toString(16).padStart(4, '0')}:`, error);    throw error;  }}
为了简化指令实现，我们提供了一组辅助方法来处理常见的寄存器操作：
/** * 获取寄存器值（按编号） */getRegisterValue(regNum) {  switch (regNum) {    case 0: return this.registers.b;    case 1: return this.registers.c;    case 2: return this.registers.d;    case 3: return this.registers.e;    case 4: return this.registers.h;    case 5: return this.registers.l;    case 6: return this.mmu.readByte(this.getHL()); // (HL)    case 7: return this.registers.a;    default: return 0;  }}/** * 获取 16 位寄存器组合 */getBC() { return (this.registers.b << 8) | this.registers.c; }getDE() { return (this.registers.d << 8) | this.registers.e; }getHL() { return (this.registers.h << 8) | this.registers.l; }setBC(value) {  this.registers.b = (value >> 8) & 0xFF;  this.registers.c = value & 0xFF;}
 1.4. 导出
在文件的最下方、GameBoyCPU 类的外部添加导出代码：
if (typeof module !== 'undefined' && module.exports) {  // Node.js 环境导出  module.exports = { GameBoyCPU, CPU_FLAGS, INSTRUCTION_TIMINGS };} else if (typeof window !== 'undefined') {  // 浏览器环境导出到全局对象  window.GameBoyCPU = GameBoyCPU;  window.CPU_FLAGS = CPU_FLAGS;  window.INSTRUCTION_TIMINGS = INSTRUCTION_TIMINGS;}
 2. 模拟内存管理单元
我们的 GameBoy CPU 骨架虽然能够执行指令并管理内存寄存器，但是一个没有内存的 CPU 就跟一个没有书的图书馆差不多，光有管理员也没啥用。CPU 必需能够与外部内存交互，才能读取程序代码、存取数据，并与各种硬件组件通信。
这就是 内存管理单元（MMU）的作用。MMU 负责管理 GameBoy 的整个 64KB 的地址空间，并将 CPU 的内存访问请求路由到正确的物理内存区域。
为什么需要 MMU？（大白话 + 1）
想象你在管理一个大仓库，有多大呢？GameBoy 的 64KB 内存相当于有 65536 个格子，你的大仓库也有这 65536 个格子：
有些格子放游戏程序（ROM）
有些格子放临时数据（RAM）
有些格子放图片数据（VRAM）
有些格子是控制按钮（I / O 寄存器）
CPU 依然是那个工人。假设他想要 0x8000 地址的数据。
如果没有 MMU 的话，CPU 就得自己跑到 0x8000 格子、搞清楚这个格子到底存的是什么、自行处理各种复杂情况。
有了 MMU 的话，CPU 只需要说他要 0x8000 的数据，MMU 就会：
「0x8000 是图片数据区域。」
「这个区域的数据在 VRAM 里。」
「给你！」
这样看，MMU 就像是一个很靠谱的仓库管理员。
 2.1. GameBoy 内存映射
与现代计算机复杂的内存管理不同，GameBoy 的内存映射相对直观，但仍然包含了多个不同功能的区域。理解这个内存映射对于正确模拟 GameBoy 至关重要。
GameBoy 的 64KB 地址空间被划分为以下主要区域：
0x0000 - 0x3FFF：卡带 ROM 银行 0
这是游戏卡带程序的第一个 16KB 区域，始终可访问。0x0000 - 0x00FF：BIOS：GameBoy 启动时，CPU 从 0x0000 地址开始执行 BIOS 代码。一旦 BIOS 运行完毕，这片区域就会被卡带 ROM 覆盖，不再可访问。
0x0100 - 0x014F：卡带头部：这部分包含游戏的名称、制造商、ROM / RAM 大小等关键信息。
0x4000 - 0x7FFF：卡带 ROM 其他银行
对于大于 32KB 的游戏，卡带会包含多个 16KB 的 ROM 银行。MMU 需要通过 内存银行控制器（MBC）来切换这些银行，以便 CPU 能够访问整个游戏程序。对于 32KB 或更小的游戏，这个区域也直接是 ROM 的一部分，无需银行切换。
0x8000 - 0x9FFF：视频 RAM
存储用于渲染游戏背景和精灵图形数据。这部分内存对 CPU 可读写，但主要由图形处理单元（GPU）使用。
0xA000 - 0xBFFF：卡带外部 RAM
部分游戏卡带会包含额外的可读写内存，用于保存游戏进度或临时数据。
0xC000 - 0xDFFF：工作 RAM
这是 GameBoy 内部的主工作内存，CPU 可以自由读写，用于存储程序变量、栈等。
0xE000 - 0xFDFF：工作 RAM 镜像
由于硬件接线的设计，工作 RAM 在内存映射中有一个完全相同的镜像区域。这意味着对 0xE000-0xFDFF 的读写实际上是对 0xC000-0xDFFF 的读写。
0xFE00 - 0xFE9F：精灵属性表
存储屏幕上所有精灵（例如角色、敌人）的位置、大小、图形数据索引等属性信息。
0xFF00 - 0xFF7F：内存映射 I / O 寄存器
这个区域包含了控制 GameBoy 各个硬件子系统（如图形、声音、定时器、输入）的寄存器。CPU 通过读写这些地址来控制硬件行为。
0xFF80 - 0xFFFF：零页 RAM
又称「高速 RAM」，这片区域是 GameBoy 最顶部的内存，CPU 访问它们的速度最快。虽然地址很高，但因其在汇编编程中的常用性，常被称为「零页」。
太复杂了看不懂、一图胜千言版本：
GameBoy 的 64KB 内存就像一栋 8 层楼的公寓：
🏢 GameBoy 内存公寓（64KB）
├── 8 楼（0xFF00-0xFFFF）控制中心（按钮、音量调节等）
├── 7 楼（0xFE00-0xFEFF）精灵属性（角色信息）
├── 6 楼（0xE000-0xFDFF）工作区镜像（楼下的复印件）
├── 5 楼（0xC000-0xDFFF）工作区（临时文件柜）
├── 4 楼（0xA000-0xBFFF）卡带存档（游戏进度）
├── 3 楼（0x8000-0x9FFF）图片仓库（所有图像数据）
├── 2 楼（0x4000-0x7FFF）游戏程序（第 2 部分）
└── 1 楼（0x0000-0x3FFF）游戏程序（第 1 部分）
└── 地下室（0x0000-0x00FF）开机程序（BIOS）
每次 CPU 说他想要 0x8000 的数据，MMU 就知道：「哦，你要 3 楼图片仓库的东西。」
为了在代码中清晰地表示这些区域，我们定义一个 MEMORY_REGIONS 常量对象：
/** * 内存区域常量定义 */const MEMORY_REGIONS = {  // ROM 区域  ROM_BANK_0_START: 0x0000,  ROM_BANK_0_END: 0x3FFF,  ROM_BANK_1_START: 0x4000,  ROM_BANK_1_END: 0x7FFF,  // BIOS 区域（在 ROM 银行 0 内）  BIOS_START: 0x0000,  BIOS_END: 0x00FF,  BIOS_EXIT_POINT: 0x0100,  // 卡带头部（在 ROM 银行 0 内）  CARTRIDGE_HEADER_START: 0x0100,  CARTRIDGE_HEADER_END: 0x014F,  // 视频 RAM  VRAM_START: 0x8000,  VRAM_END: 0x9FFF,  VRAM_SIZE: 0x2000, // 8KB  // 外部 RAM  ERAM_START: 0xA000,  ERAM_END: 0xBFFF,  ERAM_SIZE: 0x2000, // 8KB  // 工作 RAM  WRAM_START: 0xC000,  WRAM_END: 0xDFFF,  WRAM_SIZE: 0x2000, // 8KB  // 工作 RAM 镜像  WRAM_SHADOW_START: 0xE000,  WRAM_SHADOW_END: 0xFDFF,  // 精灵属性内存  OAM_START: 0xFE00,  OAM_END: 0xFE9F,  OAM_SIZE: 0xA0, // 160 字节  // I/O 寄存器  IO_START: 0xFF00,  IO_END: 0xFF7F,  // 零页 RAM  ZRAM_START: 0xFF80,  ZRAM_END: 0xFFFF,  ZRAM_SIZE: 0x80 // 128 字节};
 2.2. MMU 类结构与初始化
我们的 GameBoyMMU 类会负责创建和管理这些内存区域的实际存储（用 Unit8Array），并提供读写内存的接口。
在构造函数里，首先要调用 initializeMemoryRegions 来分配各个内存区域的存储空间，然后调用 reset 方法将它们清空并设置初始状态。
/** * GameBoy 内存管理单元类 */class GameBoyMMU {  constructor() {    this.initializeMemoryRegions();    this.reset();  }  /**   * 初始化所有内存区域   */  initializeMemoryRegions() {    // BIOS 数据（256 字节），GameBoy 启动代码    this.bios = new Uint8Array(256);        // 卡带 ROM 数据（最大 32KB 基础 ROM）    this.rom = new Uint8Array(0x8000); // 32KB 初始空间        // 视频 RAM（8KB），存储背景和精灵图形数据    this.vram = new Uint8Array(MEMORY_REGIONS.VRAM_SIZE);        // 外部 RAM（8KB），卡带上的额外可写内存    this.eram = new Uint8Array(MEMORY_REGIONS.ERAM_SIZE);        // 工作 RAM（8KB），GameBoy 内部 RAM    this.wram = new Uint8Array(MEMORY_REGIONS.WRAM_SIZE);        // 零页 RAM（128 字节），高速访问内存    this.zram = new Uint8Array(MEMORY_REGIONS.ZRAM_SIZE);        // 精灵属性内存（160 字节），存储精灵位置和属性    this.oam = new Uint8Array(MEMORY_REGIONS.OAM_SIZE);        // I/O 寄存器映射（128 字节），硬件控制寄存器    this.ioRegisters = new Uint8Array(0x80);  }  /**   * 重置 MMU 到初始状态   */  reset() {    // BIOS 映射标志，控制是否显示 BIOS 区域    this.biosEnabled = true;        // 清空所有可写内存区域    this.vram.fill(0);    this.eram.fill(0);    this.wram.fill(0);    this.zram.fill(0);    this.oam.fill(0);    this.ioRegisters.fill(0);        console.log('MMU 已重置到初始状态');  }}
 2.3. 内存读取
MMU 最核心的功能就是根据 CPU 请求的地址，将其路由到正确的内存区域并返回数据。readByte(address) 方法实现了这一逻辑：它根据 16 位地址的不同范围，返回对应 Uint8Array 中的字节。
这里需要特别注意 BIOS 区域的逻辑：当 CPU 程序计数器 PC 达到 0x0100 时，表明 BIOS 已经执行完毕，此时我们会禁用 BIOS 映射（this.biosEnabled = false;），让该地址范围（0x0000-0x00FF）切换到显示卡带 ROM。
// ... 之前写的方法 .../** * 从指定地址读取 8 位字节 * 根据地址范围路由到相应的内存区域 * @param {number} address 16 位内存地址（0x0000-0xFFFF） * @returns {number} 8 位数据值（0x00-0xFF） */readByte(address) {  // 确保地址在 16 位范围内  address &= 0xFFFF;  // 根据地址高 4 位进行初步分类，提升性能  switch (address & 0xF000) {    // 0x0000-0x0FFF: BIOS/ROM 银行 0 区域    case 0x0000: {      // 检查是否在 BIOS 区域且 BIOS 已启用      if (this.biosEnabled && address < MEMORY_REGIONS.BIOS_EXIT_POINT) {        return this.bios[address];      }      // BIOS 退出检查：当 PC 到达 0x0100 时禁用 BIOS      // TODO: 这里依赖于全局的 cpu 实例，后续可以考虑通过依赖注入优化      if (address === MEMORY_REGIONS.BIOS_EXIT_POINT && window.cpu?.registers?.pc === MEMORY_REGIONS.BIOS_EXIT_POINT) {        this.biosEnabled = false;        console.log('BIOS已退出，切换到卡带ROM');      }      return this.rom[address]; // 否则读取 ROM    }    // 0x1000-0x3FFF: ROM 银行 0 的其余部分    case 0x1000:    case 0x2000:    case 0x3000:      return this.rom[address];    // 0x4000-0x7FFF: ROM 银行 1（可切换） - 基础模拟中直接从 rom 读取    case 0x4000:    case 0x5000:    case 0x6000:    case 0x7000:      return this.rom[address];    // 0x8000-0x9FFF: 视频 RAM    case 0x8000:    case 0x9000:      return this.vram[address & 0x1FFF]; // 限制在 8KB（0x2000）范围内    // 0xA000-0xBFFF: 外部 RAM    case 0xA000:    case 0xB000:      return this.eram[address & 0x1FFF]; // 限制在 8KB 范围内    // 0xC000-0xDFFF: 工作 RAM    case 0xC000:    case 0xD000:      return this.wram[address & 0x1FFF]; // 限制在 8KB 范围内    // 0xE000-0xEFFF: 工作 RAM 镜像    case 0xE000:      return this.wram[address & 0x1FFF]; // 映射到工作 RAM    // 0xF000-0xFFFF: 复杂区域 - 包含 RAM 镜像、OAM、I/O、零页 RAM    case 0xF000:      return this.readHighMemoryRegion(address); // 调用辅助函数处理高地址区域    default:      console.warn(`未处理的内存读取地址: 0x${address.toString(16).padStart(4, '0')}`);      return 0xFF; // 返回未连接总线的典型值（全1）  }}/** * 处理高内存区域的读取（0xF000-0xFFFF） * 这个区域包含多个不同的内存映射，需要进一步细分 * @param {number} address 内存地址 * @returns {number} 读取的数据 */readHighMemoryRegion(address) {  // 根据地址的中间 4 位进一步分类  switch (address & 0x0F00) {    // 0xF000-0xFDFF: 工作 RAM 镜像的剩余部分    case 0x000: case 0x100: case 0x200: case 0x300:    case 0x400: case 0x500: case 0x600: case 0x700:    case 0x800: case 0x900: case 0xA00: case 0xB00:    case 0xC00: case 0xD00:      return this.wram[address & 0x1FFF];    // 0xFE00-0xFEFF: 精灵属性内存区域（OAM）    case 0xE00:      if (address < 0xFEA0) {        // 有效的 OAM 区域（0xFE00-0xFE9F）        return this.oam[address & 0xFF]; // 限制在 160 字节（0xA0）范围内      } else {        // 0xFEA0-0xFEFF: 未使用区域，读取通常返回 0 或 0xFF，这里统一返回 0        return 0;      }    // 0xFF00-0xFFFF: I/O 寄存器和零页 RAM    case 0xF00:      if (address >= MEMORY_REGIONS.ZRAM_START) {        // 0xFF80-0xFFFF: 零页 RAM        return this.zram[address & 0x7F]; // 限制在 128 字节（0x80）范围内      } else {        // 0xFF00-0xFF7F: I/O 寄存器        return this.readIORegister(address); // 调用辅助函数处理 I/O 寄存器读取      }    default:      return 0xFF; // 未知区域返回 0xFF  }}/** * 读取 I/O 寄存器 * 这些寄存器控制 GameBoy 的各个硬件子系统。 * TODO: 目前只是返回其在内部数组中的值，具体硬件逻辑将在后续章节实现。 * @param {number} address I/O 寄存器地址（0xFF00-0xFF7F） * @returns {number} 寄存器值 */readIORegister(address) {  const registerIndex = address - MEMORY_REGIONS.IO_START;  // 返回 I/O 寄存器数组中的值，如果超出范围则返回 0（或 0xFF）  return this.ioRegisters[registerIndex] || 0;}/** * 从指定地址读取 16 位字（小端序 - Little Endian） * GameBoy CPU 使用小端序存储多字节数据，即低位字节在前。 * @param {number} address 起始地址 * @returns {number} 16位值 */readWord(address) {  const lowByte = this.readByte(address);  const highByte = this.readByte(address + 1);  return lowByte | (highByte << 8); // 将高位字节左移 8 位后与低位字节合并}
 2.4. 内存写入
内存写入的逻辑与读取类似，writeByte(address, value) 方法根据地址将数据写入对应的内存区域。需要注意的是，ROM 区域通常是只读的，任何写入操作都会被忽略（除了用于内存银行切换的特殊地址，这将在后面讨论）。
// ... 之前写的方法 .../** * 向指定地址写入 8 位字节 * 根据地址范围路由到相应的内存区域 * @param {number} address 16 位内存地址 * @param {number} value 8 位数据值 */writeByte(address, value) {  // 确保地址和值在有效范围内  address &= 0xFFFF;  value &= 0xFF;  // 根据地址高 4 位进行分类  switch (address & 0xF000) {    // 0x0000-0x7FFF: ROM 区域 - 通常只读，但可能有银行切换逻辑    case 0x0000: case 0x1000: case 0x2000: case 0x3000:    case 0x4000: case 0x5000: case 0x6000: case 0x7000:      this.handleROMWrite(address, value); // 专门处理 ROM 区域的写入      break;    // 0x8000-0x9FFF: 视频 RAM - 可写    case 0x8000:    case 0x9000:      this.vram[address & 0x1FFF] = value;      break;    // 0xA000-0xBFFF: 外部 RAM - 可写    case 0xA000:    case 0xB000:      this.eram[address & 0x1FFF] = value;      break;    // 0xC000-0xDFFF: 工作 RAM - 可写    case 0xC000:    case 0xD000:      this.wram[address & 0x1FFF] = value;      break;    // 0xE000-0xEFFF: 工作 RAM 镜像 - 写入映射到工作 RAM    case 0xE000:      this.wram[address & 0x1FFF] = value;      break;    // 0xF000-0xFFFF: 高内存区域    case 0xF000:      this.writeHighMemoryRegion(address, value); // 调用辅助函数处理高地址区域写入      break;    default:      console.warn(`未处理的内存写入地址: 0x${address.toString(16).padStart(4, '0')}`);  }}/** * 处理 ROM 区域的写入 * ROM 通常是只读的。在基础模拟中，任何对 ROM 区域的写入都会被忽略。 * TODO: 在未来的内存银行章节中，这里将包含处理卡带内存银行控制器的逻辑。 * @param {number} address 地址 * @param {number} value 值 */handleROMWrite(address, value) {  console.log(`ROM写入被忽略: 地址=0x${address.toString(16).padStart(4, '0')}, 值=0x${value.toString(16).padStart(2, '0')}`);}/** * 处理高内存区域的写入（0xF000-0xFFFF） * @param {number} address 地址 * @param {number} value 值 */writeHighMemoryRegion(address, value) {  switch (address & 0x0F00) {    // 0xF000-0xFDFF: 工作 RAM 镜像 - 写入映射到工作 RAM    case 0x000: case 0x100: case 0x200: case 0x300:    case 0x400: case 0x500: case 0x600: case 0x700:    case 0x800: case 0x900: case 0xA00: case 0xB00:    case 0xC00: case 0xD00:      this.wram[address & 0x1FFF] = value;      break;    // 0xFE00-0xFEFF: 精灵属性内存（OAM）    case 0xE00:      if (address < 0xFEA0) {        this.oam[address & 0xFF] = value;      }      // 0xFEA0-0xFEFF 区域的写入通常被忽略      break;    // 0xFF00-0xFFFF: I/O 寄存器和零页 RAM    case 0xF00:      if (address >= MEMORY_REGIONS.ZRAM_START) {        // 零页 RAM        this.zram[address & 0x7F] = value;      } else {        // I/O 寄存器        this.writeIORegister(address, value);      }      break;  }}/** * 写入 I/O 寄存器 * @param {number} address I/O 寄存器地址 * @param {number} value 要写入的值 */writeIORegister(address, value) {  const registerIndex = address - MEMORY_REGIONS.IO_START;  this.ioRegisters[registerIndex] = value;  // TODO: 在后续章节中，这里将处理特定 I/O 寄存器写入的副作用  // 例如：当写入显示控制寄存器时触发屏幕更新，或写入声音寄存器时播放声音}/** * 向指定地址写入 16 位字（小端序） * @param {number} address 起始地址 * @param {number} value 16 位值 */writeWord(address, value) {  this.writeByte(address, value & 0xFF);            // 写入低位字节  this.writeByte(address + 1, (value >> 8) & 0xFF); // 写入高位字节}
 2.5. 加载 ROM 与 BIOS
为了让模拟器能够运行游戏，MMU 还需要加载 BIOS 和游戏 ROM 的功能：
loadBIOS(biosData)：加载 GameBoy 的 BIOS 文件BIOS 是启动时运行的一小段程序，通常用于初始化硬件和显示任天堂的标志
loadROM(romData)：加载游戏卡带的 ROM 数据。这个方法会将 ROM 数据复制到 MMU 内部的 this.rom 数组中
loadROMFromURL(url)：直接从给定的 URL 下载 ROM 文件并加载
displayCartridgeInfo() 方法则会从 ROM 的卡带头部读取并打印出游戏的标题、类型、ROM 大小和 RAM 大小等信息，这对于验证 ROM 是否正确加载非常有用。
// ... 之前写的方法 .../** * 加载 BIOS 数据 * @param {Uint8Array|Array} biosData BIOS 数据数组（应为 256 字节） */loadBIOS(biosData) {  if (biosData.length !== 256) {    throw new Error('BIOS 数据必须正好是 256 字节');  }  this.bios.set(biosData); // 将传入的 BIOS 数据复制到内部存储  this.biosEnabled = true; // 确保 BIOS 映射处于启用状态  console.log('BIOS 已加载');}/** * 加载 ROM 文件 * @param {Uint8Array|ArrayBuffer} romData ROM 数据 */loadROM(romData) {  // 转换为 Uint8Array（如果传入的是 ArrayBuffer）  const rom = romData instanceof ArrayBuffer ? new Uint8Array(romData) : romData;  // 确保 ROM 不超过 MMU 分配的最大支持大小  const maxSize = this.rom.length;  if (rom.length > maxSize) {    console.warn(`ROM 大小 ${rom.length} 字节超过最大支持大小 ${maxSize} 字节，将被截断`);  }  // 复制 ROM 数据到内部存储，只复制有效部分  const copySize = Math.min(rom.length, maxSize);  this.rom.set(rom.slice(0, copySize));  console.log(`ROM 已加载，大小: ${copySize} 字节`);  // 显示卡带信息，验证 ROM 是否加载正确  this.displayCartridgeInfo();}/** * 显示卡带头部信息 * 从 ROM 的特定地址读取游戏元数据 */displayCartridgeInfo() {  // 读取卡带标题（0x0134-0x0143）  let title = '';  for (let i = 0x0134; i <= 0x0143; i++) {    const char = this.rom[i];    if (char === 0) break; // 标题以空字符结束    title += String.fromCharCode(char);  }  // 读取卡带类型（0x0147）  const cartridgeType = this.rom[0x0147];  // 读取 ROM 大小（0x0148）  const romSizeCode = this.rom[0x0148];  // 根据 GameBoy 规范计算 ROM 实际大小，32KB * (2^romSizeCode)  const romSize = 32 * (1 << romSizeCode); // KB  // 读取 RAM 大小（0x0149）  const ramSizeCode = this.rom[0x0149];  // 根据 GameBoy 规范定义 RAM 大小映射  const ramSizes = [0, 2, 8, 32, 128, 64]; // KB  const ramSize = ramSizes[ramSizeCode] || 0; // 处理未知编码  console.log('=== 卡带信息 ===');  console.log(`标题: ${title}`);  console.log(`卡带类型: 0x${cartridgeType.toString(16).padStart(2, '0')}`);  console.log(`ROM 大小: ${romSize}KB`);  console.log(`RAM 大小: ${ramSize}KB`);}/** * 异步加载 ROM 文件（从 URL） * @param {string} url ROM 文件 URL */async loadROMFromURL(url) {  try {    console.log(`正在加载ROM: ${url}`);    const response = await fetch(url); // 发起网络请求    if (!response.ok) {      throw new Error(`HTTP错误: ${response.status}`);    }    const romData = await response.arrayBuffer(); // 获取二进制数据    this.loadROM(romData); // 调用 loadROM 进行处理  } catch (error) {    console.error('ROM加载失败:', error);    throw error; // 重新抛出错误以便外部捕获  }}/** * 获取内存使用情况统计（用于调试） * @returns {Object} 内存使用统计对象 */getMemoryStats() {  return {    biosEnabled: this.biosEnabled,    romLoaded: this.rom.some(byte => byte !== 0), // 检查 ROM 是否包含数据    memoryRegions: {      bios: { size: this.bios.length, used: this.bios.some(byte => byte !== 0) },      rom: { size: this.rom.length, used: this.rom.some(byte => byte !== 0) },      vram: { size: this.vram.length, used: this.vram.some(byte => byte !== 0) },      eram: { size: this.eram.length, used: this.eram.some(byte => byte !== 0) },      wram: { size: this.wram.length, used: this.wram.some(byte => byte !== 0) },      zram: { size: this.zram.length, used: this.zram.some(byte => byte !== 0) },      oam: { size: this.oam.length, used: this.oam.some(byte => byte !== 0) }    }  };}/** * 获取内存转储（用于调试） * 以十六进制和 ASCII 形式显示内存内容 * @param {number} startAddr 起始地址 * @param {number} length 要转储的长度 * @returns {string} 十六进制转储字符串 */getMemoryDump(startAddr, length = 256) {  let dump = `内存转储 (0x${startAddr.toString(16).padStart(4, '0')} - 0x${(startAddr + length - 1).toString(16).padStart(4, '0')}):\n`;  // 每行显示 16 个字节  for (let i = 0; i < length; i += 16) {    const addr = startAddr + i;    let line = `${addr.toString(16).padStart(4, '0')}: `; // 地址部分    let ascii = ''; // ASCII 可视化部分    for (let j = 0; j < 16 && (i + j) < length; j++) {      const byte = this.readByte(addr + j);      line += `${byte.toString(16).padStart(2, '0')} `; // 十六进制字节      // 将可打印字符转换为 ASCII，否则显示 '.'      ascii += (byte >= 32 && byte <= 126) ? String.fromCharCode(byte) : '.';    }    line = line.padEnd(50, ' ') + ascii; // 填充空格对齐    dump += line + '\n';  }  return dump;}
 2.6. MMU 与 CPU 的连接
现在我们有了 GameBoyCPU 和 GameBoyMMU 两个类。CPU 需要一个方式来与 MMU 交互，才能真正实现「取指」和「读写内存」的功能。最简单的方式就是将 MMU 实例作为参数传递给 CPU，或者让 CPU 拥有一个 MMU 的引用。
不过也别忘了在 mmu.js 中导出 GameBoyMMU 类和常量：
if (typeof module !== 'undefined' && module.exports) {  // Node.js 环境导出  module.exports = { GameBoyMMU, MEMORY_REGIONS };} else if (typeof window !== 'undefined') {  // 浏览器环境导出到全局对象  window.GameBoyMMU = GameBoyMMU;  window.MEMORY_REGIONS = MEMORY_REGIONS;}
然后在 GameBoyCPU 类中，我们可以添加一个对 MMU 的引用：
class GameBoyCPU {  constructor(mmu) { // 接收 MMU 实例    this.mmu = mmu; // 存储 MMU 引用    // ... 其他寄存器和时钟初始化 ...  }  // 示例：实现一个 LD A, (HL) 指令  // 将 HL 寄存器指向的内存地址的值加载到 A 寄存器  loadAToHL() {    const address = (this.registers.h << 8) | this.registers.l; // 合并 H 和 L 得到 16 位地址    this.registers.a = this.mmu.readByte(address); // 通过 MMU 读取内存    this.registers.m = 2; // 假设这条指令需要 2 机器周期    this.registers.t = 8; // 假设这条指令需要 8 时钟周期  }  // ... 其他指令和方法 ...}
这样，CPU 就可以通过 this.mmu.readByte()、this.mmu.writeByte() 等方法来访问内存了。
 3. GPU 时序：让 GameBoy 屏幕动起来
先前我们已经构建了 GameBoy 模拟器的 CPU 骨架和 MMU，让模拟器能够加载游戏 ROM 并开始执行指令。但是一个没有图像输出的模拟器是没有灵魂的！现在我们得引入 GameBoy 的主要输出设备 ——  图形处理单元 也就是我们经常说到的 GPU 了。
GameBoy 的官方内部名称是「点阵式游戏机」（Dot Matrix Game），这是因为它靠着一块 160x144 像素的单色 LCD 屏幕来显示内容。为了模拟这个屏幕，我们可以在 Web 页面中使用一个 HTML5  元素。这个 Canvas 将作为我们的「帧缓冲区」，其中每个像素的颜色都可以被直接操作。
 3.1. 模拟屏幕与帧缓冲区
要将 GameBoy 的图形输出呈现在网页上，最直接的方法就是创建一个与 GameBoy 屏幕尺寸相同的 Canvas。我们可以通过 Canvas 的 2D 渲染上下文来操作它的像素数据。
GameBoy 的显示分辨率是 160 像素宽和 140 像素高。Canvas 的像素数据通常以 RGBA（红、绿、蓝、透明度）的 4 字节序列存储。这意味着每个像素需要 4 个字节来表示其颜色。我们可以通过 getImageData 或 createImageData 方法获取或创建这个帧缓冲区。
首先，在 HTML 文件中添加一个 Canvas 元素：
在 GameBoyGPU 类中，我们将负责初始化这个 Canvas 并创建帧缓冲区。我们还设置了 imageSmoothingEnabled = false 和 image-rendering: pixelated 样式，以确保图像在放大时保持像素艺术的清晰度，而不是变得模糊。
// ... 其他常量定义，之后写 .../** * GameBoy GPU 类 * 负责管理显示时序、渲染管线和帧缓冲区 */class GameBoyGPU {  constructor() {    this.initializeTimingState();    this.initializeCanvas();    this.initializeFrameBuffer();    console.log('GameBoy GPU 已初始化');  }  /**   * 初始化 Canvas 画布   */  initializeCanvas() {    // 尝试获取已存在的 canvas 元素    this.canvas = document.getElementById('gameboy-screen');    // 如果不存在，创建新的 canvas 并添加到页面    if (!this.canvas) {      this.canvas = this.createCanvas();    }    // 获取 2D 渲染上下文    this.context = this.canvas.getContext('2d');    if (!this.context) {      throw new Error('无法获取 Canvas 2D 渲染上下文');    }    // 禁用图像平滑，保持像素艺术风格    this.context.imageSmoothingEnabled = false;    console.log('Canvas 画布已初始化');  }  /**   * 创建新的 Canvas 元素   * @returns {HTMLCanvasElement} 创建的 canvas 元素   */  createCanvas() {    const canvas = document.createElement('canvas');    canvas.id = 'gameboy-screen';    canvas.width = DISPLAY_CONFIG.WIDTH;    canvas.height = DISPLAY_CONFIG.HEIGHT;    canvas.style.border = '2px solid #333';    canvas.style.imageRendering = 'pixelated'; // 保持像素完美缩放    canvas.style.imageRendering = '-moz-crisp-edges'; // Firefox    canvas.style.imageRendering = 'crisp-edges';      // Chrome/Edge    canvas.style.backgroundColor = '#9BBC0F'; // GameBoy 绿色背景    // 为了方便在 HTML 中演示，这里直接添加到 body    document.body.appendChild(canvas);    console.log('已创建新的 Canvas 元素');    return canvas;  }  /**   * 初始化帧缓冲区   * 使用 ImageData 对象作为屏幕的内存表示   */  initializeFrameBuffer() {    // 创建图像数据对象（帧缓冲区）    this.frameBuffer = this.context.createImageData(      DISPLAY_CONFIG.WIDTH,      DISPLAY_CONFIG.HEIGHT    );    // 初始化为白色背景    this.clearFrameBuffer();    console.log('帧缓冲区已初始化');  }  /**   * 清空帧缓冲区（设置为白色，或 GameBoy 默认背景色）   */  clearFrameBuffer() {    const data = this.frameBuffer.data;    // 设置所有像素为白色（255, 255, 255, 255）    for (let i = 0; i < DISPLAY_CONFIG.BUFFER_SIZE; i += 4) {      data[i] = 255;      // R      data[i + 1] = 255;  // G      data[i + 2] = 255;  // B      data[i + 3] = 255;  // A (透明度)    }  }  /**   * 设置像素颜色（辅助函数）   * @param {number} x - X 坐标（0-159）   * @param {number} y - Y 坐标（0-143）   * @param {number} r - 红色分量（0-255）   * @param {number} g - 绿色分量（0-255）   * @param {number} b - 蓝色分量（0-255）   * @param {number} a - 透明度（0-255），默认 255   */  setPixel(x, y, r, g, b, a = 255) {    if (x < 0 || x >= DISPLAY_CONFIG.WIDTH || y < 0 || y >= DISPLAY_CONFIG.HEIGHT) {      return; // 越界检查    }    const pixelIndex = (y * DISPLAY_CONFIG.WIDTH + x) * 4;    const data = this.frameBuffer.data;    data[pixelIndex] = r;    data[pixelIndex + 1] = g;    data[pixelIndex + 2] = b;    data[pixelIndex + 3] = a;  }}
现在，我们有一个可以操作的帧缓冲区。通过修改 this.frameBuffer.data 数组中的 RGBA 值，我们可以改变屏幕上任何像素的颜色。修改完成后，调用 this.context.putImageData(this.frameBuffer, 0, 0) 就可以将更新后的帧缓冲区内容绘制到 Canvas 上。
 3.2. 栅格图形与显示时序
GPU 工作原理：
我们可以看一下老式电视是如何显示画面的：
电子枪从左到右扫描 →→→→→→→→→→→（一行画完）然后跳到下一行    ↓再从左到右扫描   →→→→→→→→→→→（下一行）...重复 144次 ...最后回到顶部     ↑↑↑↑↑↑↑↑↑（准备下一帧）
GameBoy 的 GPU 完全模仿了这个过程。
1989 年的硬件很慢，一次只能处理一行像素，这样做也能省电省内存。当年的程序员很聪明，用最少的资源做最多的事。
GameBoy 的显示硬件模拟了阴极射线管（CRT）的工作方式。在 CRT 显示器中，电子束逐行扫描屏幕，并在扫描完成后返回到屏幕顶部。这个扫描过程不是瞬间完成的，它包含了消隐期：
水平消隐：电子束从一行的末尾移动到下一行的开头所需的时间
垂直消隐：在一帧结束后，电子束从屏幕底部回到屏幕左上角所需的时间。垂直消隐期通常比水平消隐期长得多，因为它需要移动更远的距离
GameBoy 的显示器也遵循类似的模式，并将其工作周期细分为四个不同的 GPU 模式。这对于精确模拟非常重要，因为某些硬件操作只能在特定的 GPU 模式下进行。
周期 GPU 模式号 时间消耗（t 时钟周期） 描述
OAM 搜索 2 80 GPU 扫描 OAM 获取当前扫描线上的精灵信息。
像素传输 3 172 GPU 从 VRAM 读取图块和地图数据并渲染像素。
水平消隐 0 204 当前扫描线渲染完成后的等待期。
一条扫描线总时间 456 (80 + 172 + 204)
垂直消隐 1 4560（10 行） 所有可见扫描线渲染完成后的等待期。
一帧总时间 70224 （456 * 154 行）
为什么是这些数字呢？
GPU 像是一个画家，每天画一行像素。
准备阶段（80）：看看要画什么角色（OAM 搜索）
绘画阶段（172）：专心画这一行（像素传输）
休息阶段（204）：喝口水，准备下一行（水平消隐）
长休息（4560）：一张画完了，休息下（垂直消隐）
因此我们的游戏不能随时访问 GPU。
为了在模拟器中保持这些时序，我们需要一个 step 函数，它会在 CPU 每执行一条指令后被调用，并根据 CPU 消耗的时钟周期来推进 GPU 的内部时序状态。
我们定义 GPU 模式和时序常量：
/** * GPU 模式常量定义 * GameBoy GPU 有 4 种不同的工作模式，模拟 CRT 显示器的扫描过程 */const GPU_MODES = {  HBLANK: 0,        // 水平消隐期（扫描线结束后）  VBLANK: 1,        // 垂直消隐期（帧结束后）  OAM_SEARCH: 2,    // OAM 搜索期（精灵属性扫描）  PIXEL_TRANSFER: 3 // 像素传输期（VRAM 读取和渲染）};/** * GPU 时序常量（以 CPU 的 T 时钟周期为单位） * CPU 频率：4194304 Hz */const GPU_TIMINGS = {  // 扫描线时序  OAM_SEARCH_CYCLES: 80,      // 模式 2：OAM 访问时间  PIXEL_TRANSFER_CYCLES: 172, // 模式 3：VRAM 访问时间  HBLANK_CYCLES: 204,         // 模式 0：水平消隐时间  // 计算得出的时序  SCANLINE_CYCLES: 456,       // 一条扫描线总时间（80 + 172 + 204）  VBLANK_LINE_CYCLES: 456,    // 垂直消隐期每线时间  VBLANK_TOTAL_CYCLES: 4560,  // 垂直消隐总时间（456 * 10）  // 帧时序  VISIBLE_LINES: 144,         // 可见扫描线数量  VBLANK_LINES: 10,           // 垂直消隐扫描线数量  TOTAL_LINES: 154,           // 总扫描线数量（144 + 10）  FRAME_CYCLES: 70224         // 完整帧时间（456 * 154）};/** * 显示常量 */const DISPLAY_CONFIG = {  WIDTH: 160,                 // 屏幕宽度  HEIGHT: 144,                // 屏幕高度  BYTES_PER_PIXEL: 4,         // RGBA 格式，每像素 4 字节  TOTAL_PIXELS: 160 * 144,    // 总像素数  BUFFER_SIZE: 160 * 144 * 4  // 帧缓冲区大小};
接下来，我们在 GameBoyGPU 类中初始化时序状态，并实现 step 方法：
// ... 之前写的其他方法 .../** * 初始化时序状态 */initializeTimingState() {  this.mode = GPU_MODES.OAM_SEARCH; // 初始 GPU 模式  this.modeClock = 0;                // 当前模式的时钟计数器  this.currentLine = 0;              // 当前扫描线号（0-153）  this.totalClock = 0;               // GPU 总时钟计数（累积）  this.frameCount = 0;               // 帧计数器  this.lastFrameTime = performance.now(); // 上次帧渲染时间（用于计算 FPS）}/** * 重置 GPU 到初始状态 */reset() {  this.initializeTimingState();  this.clearFrameBuffer();  this.updateDisplay(); // 更新 Canvas 以显示清空后的画面  console.log('GPU 已重置');}/** * GPU 时序步进函数 * 每次 CPU 执行指令后调用，根据 CPU 消耗的时钟周期推进 GPU 状态 * @param {number} cycles CPU 消耗的时钟周期数 */step(cycles) {  this.modeClock += cycles; // 累加当前模式下的时钟  this.totalClock += cycles; // 累加总时钟  // 根据当前模式处理时序逻辑  switch (this.mode) {    case GPU_MODES.OAM_SEARCH:      this.handleOAMSearchMode();      break;    case GPU_MODES.PIXEL_TRANSFER:      this.handlePixelTransferMode();      break;    case GPU_MODES.HBLANK:      this.handleHBlankMode();      break;    case GPU_MODES.VBLANK:      this.handleVBlankMode();      break;    default:      console.warn(`未知的 GPU 模式：${this.mode}`);      this.mode = GPU_MODES.OAM_SEARCH; // 恢复到默认模式  }}/** * 处理 OAM 搜索模式（模式 2） * 当模式时钟达到 OAM_SEARCH_CYCLES 时，切换到像素传输模式 */handleOAMSearchMode() {  if (this.modeClock >= GPU_TIMINGS.OAM_SEARCH_CYCLES) {    this.modeClock = 0;    this.mode = GPU_MODES.PIXEL_TRANSFER;    // TODO: 在这个阶段，会进行 OAM 搜索逻辑，在第 7 章（精灵）中实现    this.searchOAM();  }}/** * 处理像素传输模式（模式 3） * 当模式时钟达到 PIXEL_TRANSFER_CYCLES 时，切换到水平消隐模式，并渲染当前扫描线 */handlePixelTransferMode() {  if (this.modeClock >= GPU_TIMINGS.PIXEL_TRANSFER_CYCLES) {    this.modeClock = 0;    this.mode = GPU_MODES.HBLANK;    // 渲染当前扫描线    this.renderScanline();  }}/** * 处理水平消隐模式（模式 0） * 当模式时钟达到 HBLANK_CYCLES 时，递增扫描线，并根据扫描线数量决定进入 VBLANK 或下一条扫描线 */handleHBlankMode() {  if (this.modeClock >= GPU_TIMINGS.HBLANK_CYCLES) {    this.modeClock = 0;    this.currentLine++; // 扫描线递增    if (this.currentLine === GPU_TIMINGS.VISIBLE_LINES) {      // 所有可见扫描线完成（0-143），进入垂直消隐模式      this.mode = GPU_MODES.VBLANK;      this.onFrameComplete(); // 通知一帧渲染完成    } else {      // 继续下一条扫描线，回到 OAM 搜索模式      this.mode = GPU_MODES.OAM_SEARCH;    }  }}/** * 处理垂直消隐模式（模式 1） * VBLANK 持续 10 条扫描线的时间。当模式时钟达到 VBLANK_LINE_CYCLES 时，递增扫描线， * 直到所有 VBLANK 扫描线完成，然后开始新的一帧。 */handleVBlankMode() {  if (this.modeClock >= GPU_TIMINGS.VBLANK_LINE_CYCLES) {    this.modeClock = 0;    this.currentLine++; // 扫描线递增    if (this.currentLine > GPU_TIMINGS.TOTAL_LINES - 1) {      // 垂直消隐结束（总共 154 条扫描线），开始新的一帧      this.currentLine = 0;      this.mode = GPU_MODES.OAM_SEARCH;      this.onNewFrameStart(); // 通知新帧开始    }  }}/** * OAM 搜索逻辑（占位函数） * 在第 7 章（精灵）中会实现完整的精灵处理逻辑 */searchOAM() {  // TODO: 实现精灵搜索逻辑  // 1. 扫描 OAM 表中的 40 个精灵  // 2. 找出在当前扫描线上的精灵（最多 10 个）  // 3. 按 X 坐标排序准备渲染}/** * 渲染当前扫描线 * TODO: 目前是一个简单的测试渲染，在第 4 章（图形）中会实现完整的背景和精灵渲染 */renderScanline() {  this.renderTestPattern(); // 渲染一个测试图案}/** * 渲染测试图案（用于验证 GPU 时序） * 在 Canvas 上显示彩色条纹，以验证扫描线渲染是否正常工作 */renderTestPattern() {  const data = this.frameBuffer.data;  const y = this.currentLine; // 当前要渲染的扫描线  // 为每条扫描线生成不同颜色的测试图案  for (let x = 0; x < DISPLAY_CONFIG.WIDTH; x++) {    const pixelIndex = (y * DISPLAY_CONFIG.WIDTH + x) * 4;    // 创建彩色测试图案，使之随帧动画    const colorPhase = (x + y + this.frameCount) % 64;    if (colorPhase < 16) {      // 红色渐变      data[pixelIndex] = 255;      data[pixelIndex + 1] = colorPhase * 16;      data[pixelIndex + 2] = colorPhase * 16;    } else if (colorPhase < 32) {      // 绿色渐变      data[pixelIndex] = (32 - colorPhase) * 16;      data[pixelIndex + 1] = 255;      data[pixelIndex + 2] = (colorPhase - 16) * 16;    } else if (colorPhase < 48) {      // 蓝色渐变      data[pixelIndex] = (colorPhase - 32) * 16;      data[pixelIndex + 1] = (48 - colorPhase) * 16;      data[pixelIndex + 2] = 255;    } else {      // 白色渐变      const brightness = (64 - colorPhase) * 16;      data[pixelIndex] = brightness;      data[pixelIndex + 1] = brightness;      data[pixelIndex + 2] = brightness;    }    data[pixelIndex + 3] = 255; // Alpha（完全不透明）  }}/** * 帧渲染完成回调 * 当一帧的所有可见扫描线渲染完成时调用。在这里我们将帧缓冲区显示到 Canvas。 */onFrameComplete() {  // 将帧缓冲区内容显示到 Canvas  this.updateDisplay();  // 更新帧计数和性能统计  this.frameCount++;  this.updatePerformanceStats();  // TODO: 触发垂直消隐中断（在第 8 章中断中实现）  this.triggerVBlankInterrupt();  console.log(`帧 ${this.frameCount} 渲染完成`);}/** * 新帧开始回调 * 当垂直消隐期结束，准备开始新的一帧渲染时调用。 */onNewFrameStart() {  // TODO: 为新帧做准备，例如：  // 1. 重置精灵计数器  // 2. 更新背景/窗口滚动寄存器  // 3. 处理显示控制寄存器变化}/** * 将帧缓冲区内容更新到 Canvas */updateDisplay() {  this.context.putImageData(this.frameBuffer, 0, 0);}/** * 更新性能统计，例如 FPS */updatePerformanceStats() {  const currentTime = performance.now();  const frameTime = currentTime - this.lastFrameTime;  this.lastFrameTime = currentTime;  // 计算 FPS  const fps = 1000 / frameTime;  // 每 60 帧输出一次性能信息，避免频繁日志输出  if (this.frameCount % 60 === 0) {    console.log(`性能统计 - FPS: ${fps.toFixed(2)}, 帧时间: ${frameTime.toFixed(2)}ms`);  }}/** * 触发垂直消隐中断（占位函数） * 在第 8 章（中断）中会实现完整的中断系统，通知 CPU 进行 VBLANK 相关操作 */triggerVBlankInterrupt() {  // TODO: 实现 V-Blank 中断  // 1. 设置中断标志位（例如在 MMU 中设置 IE/IF 寄存器）  // 2. 如果中断使能，通知 CPU 暂停当前执行并跳转到中断处理程序}/** * 获取当前 GPU 状态信息（用于调试） * @returns {Object} GPU 状态对象，包含模式、时钟、扫描线等 */getStatus() {  return {    mode: this.mode,    modeName: this.getModeName(this.mode),    modeClock: this.modeClock,    currentLine: this.currentLine,    totalClock: this.totalClock,    frameCount: this.frameCount,    fps: this.calculateFPS()  };}/** * 获取 GPU 模式名称的辅助函数 * @param {number} mode - 模式号 * @returns {string} 模式名称 */getModeName(mode) {  const modeNames = {    [GPU_MODES.HBLANK]: '水平消隐',    [GPU_MODES.VBLANK]: '垂直消隐',    [GPU_MODES.OAM_SEARCH]: 'OAM 搜索',    [GPU_MODES.PIXEL_TRANSFER]: '像素传输'  };  return modeNames[mode] || '未知模式';}/** * 计算当前 FPS * @returns {number} 当前 FPS 值 */calculateFPS() {  const currentTime = performance.now();  const timeDiff = currentTime - this.lastFrameTime;  return timeDiff > 0 ? 1000 / timeDiff : 0;}/** * 获取调试信息字符串 * @returns {string} 格式化的调试信息 */getDebugInfo() {  const status = this.getStatus();  return `GPU 状态：模式：${status.modeName}（${status.mode}）模式时钟：${status.modeClock}当前扫描线：${status.currentLine}总时钟：${status.totalClock}帧计数：${status.frameCount}FPS：${status.fps.toFixed(2)}`;}
 4. 图形渲染：绘制背景与瓦片
与现代显卡动辄数 GB 的显存不同，早期游戏机（如 GameBoy）的内存极其有限，无法在内存中直接存储完整的屏幕像素（即帧缓冲区）。为了解决这个问题，工程师们采用了一种非常聪明的技术 —— 瓦片系统。
想象一下你在用瓷砖来铺地板。你不需要为每一块地面都设计一个独一无二的图案，而是可以使用一组预先设计好的瓷砖（瓦片），通过不同的排列组合来创造出丰富的地面样式。GameBoy 的图形渲染就是基于这个原理。我们只需要存储一份「模板」，然后在需要的地方「引用」它即可。这个「模板」就是瓦片。
瓦片：一个 8x8 像素的基本图形单元。游戏中的所有背景和角色（精灵）都是由这些小小的瓦片拼接而成的
瓦片地图：一个 32x32 的二维数组，其中每个元素都是一个指向特定瓦片的索引。它就像一张设计图纸，规定了哪个位置应该使用哪个瓦片
视图：GameBoy 屏幕只有 160x144 像素，而整个背景地图却有 256x256 像素（32 个瓦片 × 8 像素 / 瓦片）。屏幕就像一个「摄像机」，我们只能通过这个 160x144 的窗口看到庞大背景地图的一部分
做过游戏开发的，尤其是做像素风格的应该对这个都很熟悉吧。
还是不太理解的，可以想一下拼图。
你要拼一幅大画，瓦片是你的拼图块（8x8 像素的小方块）、瓦片地图是拼图说明书、视图是拼图框。
游戏背景制作过程：
美术画了很多 8x8 的小图块
策划说：「草地用 1 号块、石头用 2 号块……」
程序：「我按照说明书拼。」（GPU 渲染）
玩家在游戏中看到森林
1989 年光是 1MB 内存就动不动要几千块钱，直接存储一张完整图片作为背景实在是过于奢侈。使用瓦片系统不仅可以节省内存，也可以节省空间。整个游戏卡带也才 32KB，必须得精打细算。
VRAM（视频内存）中，瓦片数据和瓦片地图的布局如下：
地址区域 用途
0x8000 - 0x8FFF 瓦片集 #1
0x9000 - 0x97FF 瓦片集 #2
0x9800 - 0x9BFF 瓦片地图 #0
0x9C00 - 0x9FFF 瓦片地图 #1
有趣的是，瓦片集 #0 和 #1 有一部分是重叠的。游戏可以通过设置寄存器来选择使用哪个瓦片集和哪个瓦片地图，从而实现不同的显示效果。
 4.1. 背景滚动与调色板
既然背景地图比屏幕大，我们自然就可以通过移动「摄像机」的位置来实现背景滚动的效果。这在平台跳跃或飞行射击游戏中非常常见。
GameBoy 提供了两个特殊的 GPU 寄存器来控制滚动：
SCY（Scroll Y，地址 0xFF42）：定义了屏幕顶边对应在 256x256 背景地图上的垂直坐标
SCX（Scroll X，地址 0xFF43）：定义了屏幕左边对应在 256x256 背景地图上的水平坐标
通过在每一帧之间改变 SCX 和 SCY 的值，游戏就能让背景平滑地滚动起来，创造出动态的世界。
或许大家都会以为 GameBoy 是纯黑白的，但实际上它可以显示四种深浅不同的「灰色」（或者说是绿色，取决于屏幕材质）。这四种颜色是通过调色板系统实现的。
一个瓦片中的每个像素用 2 个比特来表示，可以表示四种值（00, 01, 10, 11）。但这四个值具体对应哪种颜色，是由背景调色板寄存器（BGP，地址 0xFF47）决定的。
BGP 是一个 8 位寄存器，每 2 位定义一个颜色的映射关系：
位 1-0：映射像素值 00
位 3-2：映射像素值 01
位 5-4：映射像素值 10
位 7-6：映射像素值 11
例如，如果 BGP 的值是 0xE4（二进制 11100100），那么映射关系就是：
00 → 00（颜色 0）
01 → 01（颜色 1）
10 → 10（颜色 2）
11 → 11（颜色 3）
这是最常见的默认调色板。但如果游戏将 BGP 的值改为 0x1E（二进制 00011011），映射就会变成：
00 → 11（颜色 3）
01 → 10（颜色 2）
10 → 01（颜色 1）
11 → 00（颜色 0）
这样整个屏幕的颜色就瞬间反转了，能够很高效地实现特殊视觉效果（比方说闪烁、水下效果）的方式。
在我们的模拟器中，我们将这四种颜色定义为经典的 GameBoy 绿色调：
const DEFAULT_PALETTE = [  [155, 188, 15, 255],   // 颜色 0: 最亮 (白)  [139, 172, 15, 255],   // 颜色 1: 亮灰 (浅绿)  [48, 98, 48, 255],     // 颜色 2: 暗灰 (深绿)  [15, 56, 15, 255]      // 颜色 3: 最暗 (黑)];
 4.2. 瓦片数据结构与缓存管理
在 GameBoy 中，每个瓦片的像素数据以一种特殊的方式存储。每个像素需要 2 位来表示（因为有 4 种颜色），但这 2 位并不是连续存储的。相反，一个瓦片行的 8 个像素的低位全部存储在一个字节中，高位存储在下一个字节中。
例如，如果一个瓦片行的像素值是 [3, 2, 1, 0, 0, 1, 2, 3]，那么：
低位字节：11100001（每个像素值的最低位）
高位字节：11000011（每个像素值的最高位）
这种存储方式虽然看起来复杂，但符合 GameBoy 硬件的读取方式。
这一部分不需要完全理解，只要知道「GameBoy 有自己的存储格式，我们需要转换一下」就够了。
为了提高模拟器的性能，我们需要将这种原始格式转换为更易于处理的格式，并建立缓存机制：
/** * 瓦片管理器类 * 负责瓦片数据的存储、更新和缓存管理 */class TileManager {  constructor() {    // 扩展瓦片数据缓存 - 每个瓦片预计算为 8x8 的像素数组    this.tileCache = new Array(GRAPHICS_CONSTANTS.TOTAL_TILES);        for (let i = 0; i < GRAPHICS_CONSTANTS.TOTAL_TILES; i++) {      this.tileCache[i] = new Array(GRAPHICS_CONSTANTS.TILE_HEIGHT);      for (let y = 0; y < GRAPHICS_CONSTANTS.TILE_HEIGHT; y++) {        this.tileCache[i][y] = new Uint8Array(GRAPHICS_CONSTANTS.TILE_WIDTH);      }    }        // 标记哪些瓦片需要更新    this.dirtyTiles = new Set();  }  /**   * 更新单个瓦片的缓存数据   */  updateTileCache(tileIndex) {    // 计算瓦片在 VRAM 中的起始地址    const baseAddr = tileIndex * GRAPHICS_CONSTANTS.TILE_SIZE_BYTES;        // 逐行处理瓦片数据    for (let y = 0; y < GRAPHICS_CONSTANTS.TILE_HEIGHT; y++) {      const rowAddr = baseAddr + (y * 2); // 每行占 2 字节            if (rowAddr + 1 < this.vram.length) {        const lowByte = this.vram[rowAddr];     // 像素低位        const highByte = this.vram[rowAddr + 1]; // 像素高位                // 从两个字节中提取 8 个像素        for (let x = 0; x < GRAPHICS_CONSTANTS.TILE_WIDTH; x++) {          const bitMask = 1 << (7 - x);                    const lowBit = (lowByte & bitMask) ? 1 : 0;          const highBit = (highByte & bitMask) ? 2 : 0;                    // 组合成 2 位颜色值          this.tileCache[tileIndex][y][x] = lowBit + highBit;        }      }    }  }}
这个缓存系统的核心思想是「按需更新」—— 只有当 VRAM 中的瓦片数据发生变化时，我们才重新计算对应的缓存。这样可以避免每次渲染时都进行耗时的位操作。
 4.3. 调色板系统实现
调色板管理器负责处理颜色映射。它不仅存储当前的调色板设置，还提供了动态更新调色板的能力：
/** * 调色板管理器类 * 处理 GameBoy 的 4 色调色板系统 */class PaletteManager {  constructor() {    // 背景调色板（4 种颜色，每种颜色 RGBA 4 字节）    this.backgroundPalette = new Array(GRAPHICS_CONSTANTS.PALETTE_COLORS);        // 原始调色板寄存器值（用于模拟硬件寄存器）    this.paletteRegister = 0xFC; // 默认值：11 10 01 00        this.setDefaultPalette();  }  /**   * 更新调色板寄存器   */  updatePaletteRegister(value) {    this.paletteRegister = value & 0xFF;        // 从寄存器值提取 4 个 2 位颜色映射    for (let i = 0; i < GRAPHICS_CONSTANTS.PALETTE_COLORS; i++) {      const colorIndex = (this.paletteRegister >> (i * 2)) & 0x03;      this.backgroundPalette[i] = [...DEFAULT_PALETTE[colorIndex]];    }  }  /**   * 获取映射后的颜色   */  getColor(paletteIndex) {    if (paletteIndex < 0 || paletteIndex >= GRAPHICS_CONSTANTS.PALETTE_COLORS) {      return DEFAULT_PALETTE[0];    }        return this.backgroundPalette[paletteIndex];  }}
例如，当游戏写入调色板寄存器 0xFF47 时，updatePaletteRegister 方法会被调用，自动重新映射所有颜色。这意味着游戏可以通过一个简单的寄存器写入操作瞬间改变整个屏幕的色调。
 4.4. 背景滚动控制
滚动控制器管理背景的偏移位置，这是实现动态背景效果的关键：
/** * 滚动控制器类 * 管理背景的滚动位置 */class ScrollController {  constructor() {    this.scrollX = 0; // 水平滚动位置    this.scrollY = 0; // 垂直滚动位置  }  /**   * 设置滚动位置   */  setScroll(x, y) {    this.scrollX = x & 0xFF;    this.scrollY = y & 0xFF;  }  /**   * 获取当前滚动位置   */  getScrollPosition() {    return {      x: this.scrollX,      y: this.scrollY    };  }}
这个简单的类封装了 GameBoy 的 SCX 和 SCY 寄存器的功能。当游戏修改这些寄存器时，滚动位置会立即更新，下一帧的渲染就会反映出新的滚动位置。
 4.5. 扫描线级背景渲染
背景渲染器是整个图形系统的核心，它负责将瓦片地图转换为实际的像素数据。渲染是按扫描线进行的，这模拟了 GameBoy 的真实渲染方式：
/** * 背景渲染器类 * 负责将瓦片地图渲染到帧缓冲区 */class BackgroundRenderer {  /**   * 渲染单条扫描线的背景   */  renderBackgroundScanline(lineNumber, frameBuffer) {    // 获取滚动位置    const scroll = this.scrollController.getScrollPosition();        // 计算当前扫描线在瓦片地图中的 Y 位置    const mapY = (lineNumber + scroll.y) & 0xFF;    const tileY = Math.floor(mapY / GRAPHICS_CONSTANTS.TILE_HEIGHT);    const pixelY = mapY % GRAPHICS_CONSTANTS.TILE_HEIGHT;        // 计算瓦片地图行的起始偏移    const mapBaseAddr = this.backgroundMapSelect ?       VRAM_LAYOUT.TILEMAP_1_START : VRAM_LAYOUT.TILEMAP_0_START;    const mapOffset = mapBaseAddr - VRAM_LAYOUT.TILESET_1_START;    const mapLineOffset = mapOffset + (tileY * GRAPHICS_CONSTANTS.MAP_WIDTH_TILES);        // 计算起始瓦片的 X 位置    let mapX = scroll.x;    let tileX = Math.floor(mapX / GRAPHICS_CONSTANTS.TILE_WIDTH);    let pixelX = mapX % GRAPHICS_CONSTANTS.TILE_WIDTH;        // 计算帧缓冲区的起始位置    let canvasOffset = lineNumber * GRAPHICS_CONSTANTS.SCREEN_WIDTH * 4;        // 获取第一个瓦片    let tileIndex = this.getTileIndex(mapLineOffset + tileX);    let tileData = this.tileManager.getTileData(tileIndex);        // 渲染整条扫描线（160 像素）    for (let screenX = 0; screenX < GRAPHICS_CONSTANTS.SCREEN_WIDTH; screenX++) {      // 获取当前像素的调色板索引      const paletteIndex = tileData ? tileData[pixelY][pixelX] : 0;            // 通过调色板获取最终颜色      const color = this.paletteManager.getColor(paletteIndex);            // 写入帧缓冲区      frameBuffer.data[canvasOffset] = color[0];     // R      frameBuffer.data[canvasOffset + 1] = color[1]; // G      frameBuffer.data[canvasOffset + 2] = color[2]; // B      frameBuffer.data[canvasOffset + 3] = color[3]; // A      canvasOffset += 4;            // 移动到下一个像素      pixelX++;      if (pixelX >= GRAPHICS_CONSTANTS.TILE_WIDTH) {        // 移动到下一个瓦片        pixelX = 0;        tileX = (tileX + 1) & 31; // 瓦片地图是 32x32，循环        tileIndex = this.getTileIndex(mapLineOffset + tileX);        tileData = this.tileManager.getTileData(tileIndex);      }    }  }}
这个渲染过程的关键在于理解坐标转换：
从屏幕坐标转换为背景地图坐标（考虑滚动偏移）
从背景地图坐标转换为瓦片坐标和瓦片内像素坐标
从瓦片地图读取瓦片索引
从瓦片缓存读取像素的调色板索引
通过调色板获取最终的 RGBA 颜色值
 4.6. 图形系统集成
最后，图形系统主类将所有组件协调起来工作：
/** * 图形系统主类 * 协调所有图形组件的工作 */class GameBoyGraphicsSystem {  constructor() {    // 创建各个组件    this.tileManager = new TileManager();    this.paletteManager = new PaletteManager();    this.scrollController = new ScrollController();    this.backgroundRenderer = new BackgroundRenderer(      this.tileManager,      this.paletteManager,      this.scrollController    );  }  /**   * 连接到 MMU 的 VRAM   */  connectVRAM(vramData) {    this.tileManager.setVRAM(vramData);    this.backgroundRenderer.setVRAM(vramData);  }  /**   * 处理图形寄存器写入   */  writeGraphicsRegister(register, value) {    switch (register) {      case 0xFF42: // SCY - 垂直滚动        this.scrollController.setScrollY(value);        break;              case 0xFF43: // SCX - 水平滚动        this.scrollController.setScrollX(value);        break;              case 0xFF47: // BGP - 背景调色板        this.paletteManager.updatePaletteRegister(value);        break;    }  }  /**   * 渲染单条扫描线   */  renderScanline(lineNumber, frameBuffer) {    if (!this.enabled || !this.backgroundEnabled) {      return;    }        this.backgroundRenderer.renderBackgroundScanline(lineNumber, frameBuffer);  }}
这个集成系统的设计遵循了模块化原则 —— 每个组件都有清晰的职责，通过明确的接口进行通信。当 GPU 需要渲染一条扫描线时，它只需调用 renderScanline 方法，图形系统会自动协调所有子组件完成复杂的渲染过程。
 4.7. 图形系统集成与性能优化
在完成了瓦片管理、调色板和背景渲染等核心组件后，我们需要将图形系统与现有的 GPU 时序系统集成起来，并进行性能优化以确保流畅的渲染效果（当时测试的时候 FPS 发现连 1 都不到……）。
首先，我们需要在 GPU 类中添加图形系统的初始化和管理逻辑：
/** * 初始化图形系统 */initializeGraphicsSystem() {  // 图形系统实例（如果可用）  this.graphicsSystem = null;  this.renderMode = 'test'; // 'test' 或 'graphics'  // 尝试初始化图形系统  if (typeof GameBoyGraphicsSystem !== 'undefined') {    try {      this.graphicsSystem = new GameBoyGraphicsSystem();      this.renderMode = 'graphics';      console.log('图形系统已集成到 GPU');    } catch (error) {      console.warn('图形系统初始化失败，使用测试模式:', error);    }  } else {    console.log('图形系统未加载，使用测试渲染模式');  }}
接下来，我们需要建立 GPU 与图形系统之间的数据连接：
/** * 连接到 MMU 的 VRAM */connectVRAM(vramData) {  if (this.graphicsSystem) {    this.graphicsSystem.connectVRAM(vramData);    console.log('GPU 已连接到 VRAM');  }}/** * 处理 VRAM 写入事件 */onVRAMWrite(address, value) {  if (this.graphicsSystem) {    this.graphicsSystem.onVRAMWrite(address, value);  }}/** * 处理图形寄存器写入 */writeRegister(register, value) {  if (this.graphicsSystem) {    this.graphicsSystem.writeGraphicsRegister(register, value);  }}
为了提供更好的调试体验和性能，我们要实现渲染模式切换：
/** * 渲染真实的 GameBoy 背景图形 */renderGameBoyGraphics() {  if (window.GameBoyGraphicsSystem && this.graphicsSystem) {    this.graphicsSystem.renderScanline(this.currentLine, this.frameBuffer);  } else {    // 否则使用测试图案    this.renderTestPattern();  }}/** * 切换渲染模式 */setRenderMode(mode) {  if (mode === 'graphics' && !this.graphicsSystem) {    console.warn('图形系统未初始化，无法切换到图形模式');    return;  }  this.renderMode = mode;  console.log(`渲染模式已切换到：${mode}`);}/** * 渲染当前扫描线 */renderScanline() {  // 根据渲染模式选择渲染方式  if (this.renderMode === 'graphics' && this.graphicsSystem) {    this.renderGameBoyGraphics();  } else {    this.renderTestPattern();  }}
最重要的性能优化是引入了简化的帧级别渲染，避免了复杂的周期级别计算：
/** * 简化的帧级别步进 * 每次调用渲染一整帧，避免复杂的周期计算 */stepFrame() {  // 1. 渲染所有可见扫描线 (0-143)  for (let line = 0; line < GPU_TIMINGS.VISIBLE_LINES; line++) {    this.currentLine = line;    this.mode = GPU_MODES.PIXEL_TRANSFER;    this.renderScanline();  }  // 2. 模拟垂直消隐期间 (144-153)  this.mode = GPU_MODES.VBLANK;  this.currentLine = GPU_TIMINGS.VISIBLE_LINES;  // 3. 完成帧渲染  this.onFrameComplete();  // 4. 重置到下一帧开始  this.currentLine = 0;  this.mode = GPU_MODES.OAM_SEARCH;  this.modeClock = 0;}
 5. 系统集成：构建完整的模拟器架构
在前面的章节中，我们分别实现了 CPU 指令处理、MMU 内存管理、GPU 时序控制和图形渲染系统。虽然这些组件各自功能完善，但它们就跟分散的乐器差不多，需要一个指挥家来协调，不然是无法演奏出和谐的交响乐的。这一章的核心任务就是建立这样一个统一的系统架构，让所有硬件组件无缝协作。
 5.1. 硬件抽象层与组件连接
在真实的 GameBoy 中，各个硬件组件通过物理总线连接。在我们的模拟器中，我们需要建立一个软件层面的「总线系统「，让组件间能够进行通信。MMU 作为内存管理的中心，天然地成为了这个连接中心。
我们为 MMU 添加硬件组件连接能力：
/** * 初始化硬件组件引用 */initializeHardwareReferences() {  // 硬件组件引用，由外部注入  this.gpu = null;  this.inputController = null;      // 第6章添加  this.timer = null;                // 第10章添加  this.interruptController = null;  // 第8章添加  console.log('📡 MMU 硬件接口已初始化');}/** * 连接硬件组件 * @param {string} componentType 组件类型（'gpu', 'input', 'timer', 'interrupt'） * @param {Object} component 硬件组件实例 */connectHardware(componentType, component) {  switch (componentType) {    case 'gpu':      this.gpu = component;      console.log('✅ GPU 已连接到 MMU');      break;    case 'input':      this.inputController = component;      console.log('✅ 输入控制器已连接到 MMU');      break;    // ... 其他组件  }}
这种设计的优势在于 松耦合：每个组件都不需要知道其他组件的具体实现，只需要通过 MMU 这个「中介」进行通信。当我们要添加新的硬件组件时，只需要在 MMU 中注册即可。
 5.2. I / O 寄存器路由系统
GameBoy 的硬件组件通过内存映射的 I / O 寄存器进行控制。这些寄存器位于 0xFF00-0xFF7F 地址范围内，不同的地址控制不同的硬件功能。我们需要建立一个路由系统，将对这些地址的读写操作转发给相应的硬件组件。
首先，定义一个完整的寄存器地址映射：
/** * I/O 寄存器映射常量 */const IO_REGISTERS = {  // GPU 寄存器范围（0xFF40-0xFF7F）  GPU_START: 0xFF40,  GPU_END: 0xFF7F,  // 具体的 GPU 寄存器  LCDC: 0xFF40,    // LCD 控制寄存器  STAT: 0xFF41,    // LCD 状态寄存器  SCY: 0xFF42,     // 垂直滚动  SCX: 0xFF43,     // 水平滚动  LY: 0xFF44,      // 当前扫描线（只读）  BGP: 0xFF47,     // 背景调色板  // 其他硬件寄存器  JOYPAD: 0xFF00,  // 按键输入（第6章实现）  IF: 0xFF0F,      // 中断标志  IE: 0xFFFF       // 中断使能};
MMU 中的寄存器读写方法会根据地址范围自动将请求路由到对应的硬件组件：
/** * 连接硬件组件 * @param {string} componentType - 组件类型 ('gpu', 'input', 'timer', 'interrupt') * @param {Object} component - 硬件组件实例 */connectHardware(componentType, component) {  switch (componentType) {    case 'gpu':      this.gpu = component;      console.log('✅ GPU 已连接到 MMU');      break;    case 'input':      this.inputController = component;      console.log('✅ 输入控制器已连接到 MMU');      break;    case 'timer':      this.timer = component;      console.log('✅ 定时器已连接到 MMU');      break;    case 'interrupt':      this.interruptController = component;      console.log('✅ 中断控制器已连接到 MMU');      break;    default:      console.warn(`⚠️ 未知的硬件组件类型: ${componentType}`);  }}
不同的寄存器地址控制不同的硬件功能，MMU 需要将读写操作正确路由到对应的硬件组件：
/** * 读取I/O寄存器 - 支持硬件组件路由 */readIORegister(address) {  // 🎨 GPU 寄存器范围 (0xFF40-0xFF7F)  if (address >= IO_REGISTERS.GPU_START && address <= IO_REGISTERS.GPU_END) {    if (this.gpu && typeof this.gpu.readRegister === 'function') {      return this.gpu.readRegister(address);    } else {      console.warn(`⚠️ GPU 未连接，无法读取寄存器 0x${address.toString(16)}`);      return 0xFF;    }  }  // TODO: 以下都会在未来的章节中实现  // 🎮 按键输入寄存器 (0xFF00)  if (address === IO_REGISTERS.JOYPAD) {    if (this.inputController && typeof this.inputController.readJoypadRegister === 'function') {      return this.inputController.readJoypadRegister();    }    return 0xFF; // 默认：所有按键未按下  }  // ⏰ 定时器寄存器 (0xFF04-0xFF07)  if (address >= IO_REGISTERS.TIMER_DIV && address <= IO_REGISTERS.TIMER_TAC) {    if (this.timer && typeof this.timer.readRegister === 'function') {      return this.timer.readRegister(address);    }    return 0x00;  }  // 🔔 中断寄存器 (0xFF0F, 0xFFFF)  if (address === IO_REGISTERS.IF || address === IO_REGISTERS.IE) {    if (this.interruptController && typeof this.interruptController.readRegister === 'function') {      return this.interruptController.readRegister(address);    }    return 0x00;  }  // 默认处理  const registerIndex = address - MEMORY_REGIONS.IO_START;  return this.ioRegisters[registerIndex] || 0xFF;}
对应的写入路由逻辑确保了每个硬件组件都能及时收到控制指令：
/** * 写入I/O寄存器 - 支持硬件组件路由 * @param {number} address - I/O寄存器地址 * @param {number} value - 要写入的值 */writeIORegister(address, value) {  // 🎨 GPU 寄存器范围 (0xFF40-0xFF7F)  if (address >= IO_REGISTERS.GPU_START && address <= IO_REGISTERS.GPU_END) {    if (this.gpu && typeof this.gpu.writeRegister === 'function') {      this.gpu.writeRegister(address, value);    } else {      console.warn(`⚠️ GPU 未连接，无法写入寄存器 0x${address.toString(16)}`);    }    // 同时保存到本地数组（用于后备）    const registerIndex = address - MEMORY_REGIONS.IO_START;    if (registerIndex >= 0 && registerIndex < this.ioRegisters.length) {      this.ioRegisters[registerIndex] = value;    }    return;  }  // 🎮 按键输入寄存器 (0xFF00) - 第6章实现  if (address === IO_REGISTERS.JOYPAD) {    if (this.inputController && typeof this.inputController.writeJoypadRegister === 'function') {      this.inputController.writeJoypadRegister(value);    }    // 保存到本地数组    this.ioRegisters[address - MEMORY_REGIONS.IO_START] = value;    return;  }  // ⏰ 定时器寄存器 (0xFF04-0xFF07) - 第10章实现  if (address >= IO_REGISTERS.TIMER_DIV && address <= IO_REGISTERS.TIMER_TAC) {    if (this.timer && typeof this.timer.writeRegister === 'function') {      this.timer.writeRegister(address, value);    }    this.ioRegisters[address - MEMORY_REGIONS.IO_START] = value;    return;  }  // 🔔 中断寄存器 (0xFF0F, 0xFFFF) - 第8章实现  if (address === IO_REGISTERS.IF || address === IO_REGISTERS.IE) {    if (this.interruptController && typeof this.interruptController.writeRegister === 'function') {      this.interruptController.writeRegister(address, value);    }    // 特殊处理：IE 寄存器在零页RAM中    if (address === IO_REGISTERS.IE) {      this.zram[0x7F] = value; // 0xFFFF -> ZRAM[0x7F]    } else {      this.ioRegisters[address - MEMORY_REGIONS.IO_START] = value;    }    return;  }  // 默认处理：保存到本地寄存器数组  const registerIndex = address - MEMORY_REGIONS.IO_START;  if (registerIndex >= 0 && registerIndex < this.ioRegisters.length) {    this.ioRegisters[registerIndex] = value;  } else {    console.warn(`⚠️ 无效的I/O寄存器写入: 0x${address.toString(16).padStart(4, '0')}`);  }}
这样，当游戏代码写入 0xFF40（LCD 控制寄存器）时，MMU 会自动将这个写入操作转发给 GPU，GPU 就能实时更新其内部状态。
GPU 是 I / O 寄存器最密集的硬件组件，拥有十多个不同功能的寄存器。这些寄存器不仅控制显示行为，还影响中断、DMA 传输等关键功能。
/** * GPU 寄存器常量定义 */const GPU_REGISTERS = {  // LCD 控制和状态  LCDC: 0xFF40,    // LCD 控制寄存器  STAT: 0xFF41,    // LCD 状态寄存器    // 滚动位置  SCY: 0xFF42,     // 垂直滚动  SCX: 0xFF43,     // 水平滚动    // 扫描线相关  LY: 0xFF44,      // 当前扫描线（只读）  LYC: 0xFF45,     // 扫描线比较值    // DMA 传输  DMA: 0xFF46,     // DMA 传输寄存器    // 调色板  BGP: 0xFF47,     // 背景调色板  OBP0: 0xFF48,    // 精灵调色板 0  OBP1: 0xFF49,    // 精灵调色板 1    // 窗口位置  WY: 0xFF4A,      // 窗口 Y 位置  WX: 0xFF4B       // 窗口 X 位置};/** * LCD 控制寄存器标志位 */const LCDC_FLAGS = {  LCD_ENABLE: 0x80,        // 位 7：LCD 开关  WINDOW_TILEMAP: 0x40,    // 位 6：窗口瓦片地图选择  WINDOW_ENABLE: 0x20,     // 位 5：窗口开关  BG_TILESET: 0x10,        // 位 4：背景瓦片数据选择  BG_TILEMAP: 0x08,        // 位 3：背景瓦片地图选择  SPRITE_SIZE: 0x04,       // 位 2：精灵大小（0=8x8, 1=8x16）  SPRITE_ENABLE: 0x02,     // 位 1：精灵开关  BG_ENABLE: 0x01          // 位 0：背景开关};
GPU 内部维护所有寄存器的当前状态：
/** * 初始化寄存器状态 */initializeRegisters() {  // GPU 寄存器状态  this.registers = {    // LCD 控制寄存器 (0xFF40)    lcdc: 0x00,    // LCD 状态寄存器 (0xFF41)    stat: 0x00,    // 滚动寄存器    scy: 0x00,   // 垂直滚动 (0xFF42)    scx: 0x00,   // 水平滚动 (0xFF43)    // 扫描线寄存器    ly: 0x00,    // 当前扫描线 (0xFF44) - 只读    lyc: 0x00,   // 扫描线比较值 (0xFF45)    // 调色板寄存器    bgp: 0xFC,   // 背景调色板 (0xFF47) - 默认值    // 窗口位置寄存器    wy: 0x00,    // 窗口 Y 位置 (0xFF4A)    wx: 0x00     // 窗口 X 位置 (0xFF4B)  };  // 解析控制标志位到独立变量（向后兼容）  this.updateControlFlags();}
LCD 控制寄存器（LCDC）是一个特殊的寄存器，它的每一位都控制不同的显示功能：
/** * 从寄存器值更新控制标志位 */updateControlFlags() {  const lcdc = this.registers.lcdc;  // LCD 控制标志  this._lcdEnabled = (lcdc & LCDC_FLAGS.LCD_ENABLE) !== 0;  this._windowEnabled = (lcdc & LCDC_FLAGS.WINDOW_ENABLE) !== 0;  this._spritesEnabled = (lcdc & LCDC_FLAGS.SPRITE_ENABLE) !== 0;  this._backgroundEnabled = (lcdc & LCDC_FLAGS.BG_ENABLE) !== 0;  // 瓦片和地图选择  this._backgroundTileSet = (lcdc & LCDC_FLAGS.BG_TILESET) !== 0 ? 1 : 0;  this._backgroundTileMap = (lcdc & LCDC_FLAGS.BG_TILEMAP) !== 0 ? 1 : 0;  this._windowTileMap = (lcdc & LCDC_FLAGS.WINDOW_TILEMAP) !== 0 ? 1 : 0;  this._spriteSize = (lcdc & LCDC_FLAGS.SPRITE_SIZE) !== 0 ? 16 : 8;}
GPU 提供完整的寄存器读写接口：
/** * 读取 GPU 寄存器 * @param {number} address - 寄存器地址 * @returns {number} 寄存器值 */readRegister(address) {  switch (address) {    // LCD 控制寄存器 (0xFF40)    case GPU_REGISTERS.LCDC:      return this.registers.lcdc;    // LCD 状态寄存器 (0xFF41)    case GPU_REGISTERS.STAT:      // 组合状态标志位和当前模式      let stat = this.registers.stat & 0xF8; // 保留高 5 位      stat |= (this.mode & 0x03); // 添加当前模式            // 检查 LYC=LY 标志      if (this.registers.ly === this.registers.lyc) {        stat |= STAT_FLAGS.LYC_FLAG;      }            return stat;    // 滚动寄存器    case GPU_REGISTERS.SCY:      return this.registers.scy;    case GPU_REGISTERS.SCX:      return this.registers.scx;    // 当前扫描线 (只读)    case GPU_REGISTERS.LY:      return this.registers.ly;    // 扫描线比较值    case GPU_REGISTERS.LYC:      return this.registers.lyc;    // DMA 寄存器 (写入专用，读取返回上次写入值)    case GPU_REGISTERS.DMA:      return this.registers.dma;    // 调色板寄存器    case GPU_REGISTERS.BGP:      return this.registers.bgp;    case GPU_REGISTERS.OBP0:      return this.registers.obp0;    case GPU_REGISTERS.OBP1:      return this.registers.obp1;    // 窗口位置寄存器    case GPU_REGISTERS.WY:      return this.registers.wy;    case GPU_REGISTERS.WX:      return this.registers.wx;    default:      console.warn(`⚠️ 尝试读取未知的 GPU 寄存器: 0x${address.toString(16).padStart(4, '0')}`);      return 0xFF;  }}/** * 写入 GPU 寄存器 * @param {number} address - 寄存器地址 * @param {number} value - 要写入的值 */writeRegister(address, value) {  // 确保值在 8 位范围内  value &= 0xFF;  switch (address) {    // LCD 控制寄存器 (0xFF40)    case GPU_REGISTERS.LCDC:      this.registers.lcdc = value;      this.updateControlFlags();            // 当 LCD 被禁用时，重置一些状态      if (!this._lcdEnabled) {        this.currentLine = 0;        this.registers.ly = 0;        this.mode = GPU_MODES.HBLANK;        this.modeClock = 0;      }            console.log(`🎛️ LCD 控制寄存器更新: 0x${value.toString(16).padStart(2, '0')}`);      break;    // LCD 状态寄存器 (0xFF41) - 只有高 5 位可写    case GPU_REGISTERS.STAT:      this.registers.stat = (value & 0xF8) | (this.registers.stat & 0x07);      break;    // 滚动寄存器    case GPU_REGISTERS.SCY:      this.registers.scy = value;      // 通知图形系统滚动更新      if (this.graphicsSystem && this.graphicsSystem.scrollController) {        this.graphicsSystem.scrollController.setScrollY(value);      }      break;    case GPU_REGISTERS.SCX:      this.registers.scx = value;      // 通知图形系统滚动更新      if (this.graphicsSystem && this.graphicsSystem.scrollController) {        this.graphicsSystem.scrollController.setScrollX(value);      }      break;    // 当前扫描线 (只读寄存器，写入被忽略)    case GPU_REGISTERS.LY:      console.warn(`⚠️ 尝试写入只读寄存器 LY: 0x${value.toString(16)}`);      break;    // 扫描线比较值    case GPU_REGISTERS.LYC:      this.registers.lyc = value;      break;    // DMA 传输寄存器 (0xFF46)    case GPU_REGISTERS.DMA:      this.registers.dma = value;      this.performDMATransfer(value);      break;    // 背景调色板 (0xFF47)    case GPU_REGISTERS.BGP:      this.registers.bgp = value;      this.updateBackgroundPalette(value);      console.log(`🎨 背景调色板更新: 0x${value.toString(16).padStart(2, '0')}`);      break;    // 精灵调色板寄存器    case GPU_REGISTERS.OBP0:      this.registers.obp0 = value;      // TODO: 实现精灵调色板更新 (第7章)      break;    case GPU_REGISTERS.OBP1:      this.registers.obp1 = value;      // TODO: 实现精灵调色板更新 (第7章)      break;    // 窗口位置寄存器    case GPU_REGISTERS.WY:      this.registers.wy = value;      break;    case GPU_REGISTERS.WX:      this.registers.wx = value;      break;    default:      console.warn(`⚠️ 尝试写入未知的 GPU 寄存器: 0x${address.toString(16).padStart(4, '0')} = 0x${value.toString(16).padStart(2, '0')}`);  }}
DMA（直接内存访问）是 GameBoy 的重要功能，允许快速复制精灵数据到 OAM：
/** * 执行 DMA 传输 * @param {number} sourceHigh - 源地址高字节 */performDMATransfer(sourceHigh) {  // DMA 传输：将 256 字节从 sourceHigh*0x100 复制到 OAM (0xFE00-0xFE9F)  const sourceAddr = sourceHigh << 8;    console.log(`🚚 DMA 传输: 0x${sourceAddr.toString(16).padStart(4, '0')} -> OAM`);    // TODO: 实现完整的 DMA 传输逻辑  // 需要从 MMU 读取数据并写入 OAM  // 在真实硬件中，这会锁定总线并需要特定的时序}
/** * 更新背景调色板 * @param {number} paletteValue - 调色板寄存器值 */updateBackgroundPalette(paletteValue) {  if (this.graphicsSystem && this.graphicsSystem.paletteManager) {    this.graphicsSystem.paletteManager.updatePaletteRegister(paletteValue);  }}
 5.4. 系统调度器架构
现在我们有了能够相互通信的硬件组件，但还需要一个「指挥家」来协调它们的工作。这就是系统调度器 gameboy.js 的作用。
系统调度器作为顶层管理器，负责创建、连接和管理所有硬件组件：
/** * 系统常量定义 */const SYSTEM_CONSTANTS = {  // 时序常量  CPU_FREQUENCY: 4194304,      // 4.194304 MHz  TARGET_FPS: 59.7,           // GameBoy 目标帧率  FRAME_CYCLES: 70224,        // 每帧的 CPU 周期数    // 系统状态  STATE_STOPPED: 'stopped',  STATE_RUNNING: 'running',  STATE_PAUSED: 'paused',  STATE_ERROR: 'error',    // 调度模式  SCHEDULE_FRAME: 'frame',     // 帧级别调度（默认）  SCHEDULE_CYCLE: 'cycle',     // 周期级别调度（精确）  SCHEDULE_BURST: 'burst'      // 突发调度（性能优先）};/** * GameBoy 主系统类 * 协调 CPU、MMU、GPU 和其他硬件组件的工作 */class GameBoySystem {  constructor() {    // 系统状态    this.state = SYSTEM_CONSTANTS.STATE_STOPPED;    this.scheduleMode = SYSTEM_CONSTANTS.SCHEDULE_FRAME;    // 硬件组件    this.cpu = null;    this.mmu = null;    this.gpu = null;    this.graphics = null;    // 调度器状态    this.runningInterval = null;    this.frameRequestId = null;        // 性能统计    this.stats = {      framesRendered: 0,      cyclesExecuted: 0,      startTime: 0,      currentFPS: 0,      averageFPS: 0,      errors: 0    };  }}
系统调度器的初始化过程展示了完整的组件连接流程：
/** * 创建硬件组件实例 */async createHardwareComponents() {  // 创建 MMU（内存管理单元）  this.mmu = new GameBoyMMU();  console.log('✅ MMU 已创建');  // 创建 GPU（图形处理单元）  this.gpu = new GameBoyGPU();  console.log('✅ GPU 已创建');  // 获取图形系统引用  if (this.gpu.graphicsSystem) {    this.graphics = this.gpu.graphicsSystem;    console.log('✅ 图形系统已连接');  }  // 创建 CPU（中央处理器）  this.cpu = new GameBoyCPU();  console.log('✅ CPU 已创建');}/** * 连接硬件组件 */connectComponents() {  // 连接 GPU 到 MMU  this.mmu.connectHardware('gpu', this.gpu);  // 连接 GPU 到 VRAM  if (this.mmu.vram) {    this.gpu.connectVRAM(this.mmu.vram);    // 连接图形系统到 VRAM    if (this.graphics) {      this.graphics.connectVRAM(this.mmu.vram);    }  }  console.log('🔗 硬件组件连接完成');}
这个连接过程确保了：
GPU 能够通过 MMU 接收寄存器访问
GPU 能够直接访问 VRAM 进行渲染
图形系统能够接收 VRAM 更新通知
 5.5. 帧级别时序调度
先前我们实现了精确的周期级别时序，但在实际运行中这种精确度往往会带来性能负担，因此我们当时引入了帧级别调度，在保持足够精度的同时大幅提升性能。现在我们完善一下当时只是简化版本的 stepFrame()。
/** * 每次调用渲染一整帧，避免复杂的周期计算 */stepFrame() {  // 如果 LCD 被禁用，不渲染  if (!this._lcdEnabled) {    return;  }  // 1. 渲染所有可见扫描线 (0-143)  for (let line = 0; line < GPU_TIMINGS.VISIBLE_LINES; line++) {    this.currentLine = line;    this.registers.ly = line;    this.mode = GPU_MODES.PIXEL_TRANSFER;    this.renderScanline();  }  // 2. 模拟垂直消隐期间 (144-153)  this.mode = GPU_MODES.VBLANK;  this.currentLine = GPU_TIMINGS.VISIBLE_LINES;  this.registers.ly = GPU_TIMINGS.VISIBLE_LINES;  // 3. 完成帧渲染  this.onFrameComplete();  // 4. 重置到下一帧开始  this.currentLine = 0;  this.registers.ly = 0;  this.mode = GPU_MODES.OAM_SEARCH;  this.modeClock = 0;}
系统调度器支持多种调度模式以适应不同的需求：
/** * 帧级别调度循环（默认模式） */startFrameLoop() {  const frameLoop = (currentTime) => {    if (this.state !== SYSTEM_CONSTANTS.STATE_RUNNING) {      return;    }    try {      // 计算时间差      const deltaTime = currentTime - this.lastFrameTime;      // 如果达到目标帧时间，执行一帧      if (deltaTime >= this.targetFrameTime) {        this.executeFrame();        this.lastFrameTime = currentTime;        this.updateFPS(deltaTime);      }      // 请求下一帧      this.frameRequestId = requestAnimationFrame(frameLoop);    } catch (error) {      this.handleError(error);    }  };  // 启动循环  this.frameRequestId = requestAnimationFrame(frameLoop);}/** * 执行一帧的渲染 */executeFrame() {  // TODO: 简化的帧执行：直接让 GPU 渲染一帧  if (this.gpu) {    this.gpu.stepFrame();  }  // 更新统计  this.stats.framesRendered++;  this.stats.cyclesExecuted += SYSTEM_CONSTANTS.FRAME_CYCLES;}
这种设计的优势是：
性能优化：避免了复杂的周期级别计算
稳定的帧率：使用 requestAnimationFrame 确保流畅的 60 FPS
灵活性：可以根据需要切换到其他调度模式
 5.6. 错误处理与系统监控
一个健壮的模拟器必须能够优雅地处理错误并提供丰富的监控信息。系统调度器实现了多层次的错误处理：
/** * 错误处理 */handleError(error) {  this.stats.errors++;  console.error(`🚨 系统错误 #${this.stats.errors}:`, error);  // 如果错误过多，停止系统  if (this.stats.errors > 10) {    console.error('❌ 错误过多，停止系统运行');    this.stop();    this.state = SYSTEM_CONSTANTS.STATE_ERROR;    return;  }  // 尝试恢复  this.retryCount++;  if (this.retryCount < this.maxRetries) {    console.log(`🔄 尝试恢复系统 (${this.retryCount}/${this.maxRetries})`);    setTimeout(() => {      if (this.state === SYSTEM_CONSTANTS.STATE_ERROR) {        this.reset();      }    }, 1000);  } else {    console.error('❌ 恢复失败，系统进入错误状态');    this.state = SYSTEM_CONSTANTS.STATE_ERROR;  }}
系统提供了丰富的性能统计信息：
/** * 更新 FPS 计算 * @param {number} deltaTime - 帧时间差 */updateFPS(deltaTime) {  this.stats.currentFPS = deltaTime > 0 ? 1000 / deltaTime : 0;}/** * 计算平均 FPS */calculateAverageFPS() {  const totalTime = (performance.now() - this.stats.startTime) / 1000;  this.stats.averageFPS = totalTime > 0 ? this.stats.framesRendered / totalTime : 0;}/** * 获取系统状态 */getStatus() {  const status = {    state: this.state,    scheduleMode: this.scheduleMode,    statistics: { ...this.stats },    components: {      cpu: this.cpu ? this.cpu.getStatusString() : '未初始化',      mmu: this.mmu ? this.mmu.getMemoryStats() : '未初始化',      gpu: this.gpu ? this.gpu.getStatus() : '未初始化'    }  };  // 计算实时统计  if (this.stats.startTime > 0) {    const totalTime = (performance.now() - this.stats.startTime) / 1000;    status.statistics.totalRunTime = totalTime;    status.statistics.averageFPS = totalTime > 0 ? this.stats.framesRendered / totalTime : 0;  }  return status;}/** * 获取调试信息 * @returns {string} 格式化的调试信息 */getDebugInfo() {  const status = this.getStatus();  let debugInfo = `🎮 === GameBoy 系统状态 ===系统状态：${status.state}调度模式：${status.scheduleMode}运行时间：${status.statistics.totalRunTime?.toFixed(2) || 0}秒已渲染帧数：${status.statistics.framesRendered}执行周期数：${status.statistics.cyclesExecuted}当前 FPS：${status.statistics.currentFPS?.toFixed(2) || 0}平均 FPS：${status.statistics.averageFPS?.toFixed(2) || 0}错误计数：${status.statistics.errors}📱 硬件组件状态：`;  // CPU 状态  if (this.cpu) {    debugInfo += `\n\n💻 CPU 状态：\n${this.cpu.getStatusString()}`;  }  // GPU 状态  if (this.gpu) {    debugInfo += `\n\n🎨 GPU 状态：\n${this.gpu.getDebugInfo()}`;  }  // MMU 状态  if (this.mmu) {    const mmuStats = this.mmu.getMemoryStats();    debugInfo += `\n\n💾 MMU 状态：BIOS 启用：${mmuStats.biosEnabled ? '是' : '否'}ROM 已加载：${mmuStats.romLoaded ? '是' : '否'}硬件连接：GPU: ${mmuStats.hardwareConnections.gpu ? '✅' : '❌'}输入: ${mmuStats.hardwareConnections.input ? '✅' : '❌'}定时器: ${mmuStats.hardwareConnections.timer ? '✅' : '❌'}中断: ${mmuStats.hardwareConnections.interrupt ? '✅' : '❌'}`;  }  return debugInfo;}/** * 获取内存转储 * @param {number} address - 起始地址 * @param {number} length - 长度 * @returns {string} 内存转储 */getMemoryDump(address, length = 256) {  if (!this.mmu) {    return '❌ MMU 未初始化';  }  return this.mmu.getMemoryDump(address, length);}/** * 设置调试模式 * @param {boolean} enabled - 是否启用调试模式 */setDebugMode(enabled) {  window.DEBUG_MODE = enabled;  console.log(`🔧 调试模式${enabled ? '已启用' : '已禁用'}`);}/** * 销毁系统（清理资源） */destroy() {  console.log('💥 销毁 GameBoy 系统...');  // 停止运行  this.stop();  // 清理组件引用  this.cpu = null;  this.mmu = null;  this.gpu = null;  this.graphics = null;  // 清理全局引用  if (window.MMU) delete window.MMU;  if (window.GPU) delete window.GPU;  if (window.CPU) delete window.CPU;  if (window.Graphics) delete window.Graphics;  console.log('✅ 系统已销毁');}
 5.7. 现代化用户界面
展开以查看


CMP 2800 笔记
2025-04-07T04:00:00.000Z
世界文学经典学笔记，仅作为个人学习记录，不保证正确性。
这节课以 The Norton Anthology: World Literature 为基础。
 1. 古代美索不达米亚与近东文学
 1.1. 创世与宇宙观
古代近东地区的多个文明都有自己的创世神话和宇宙观念。
美索不达米亚（两河流域，即底格里斯河和幼发拉底河之间的区域）的创世神话《埃努玛・埃利什》描述了马尔杜克神击败提亚玛特（混沌之海）创造世界。
马尔杜克是巴比伦的主神，又称「太阳牛犊」、雷暴之神。
提亚玛特又被称为龙、咸海，同甜海阿普苏诞生出众神，却又因吵闹决定消灭后代，最终被后代马尔杜克所杀、尸骸被拿去创造了天和地。
这个神话反映了秩序战胜混沌的主题，马尔杜克用提亚玛特的身体创造天地，建立了宇宙的秩序和规则。《埃努玛・埃利什》以「太初没有天地」开始，描述了诸神间的权力斗争，最终马尔杜克成为众神之王，确立了巴比伦作为宗教中心的合法性。
埃及人则相信世界起源于努恩（原初之水），由阿图姆神创造。在太初只有无边无际的黑暗水域，阿图姆从中自我创生，随后创造了空气之神舒和湿气女神泰芙努特，开启了世界的形成。
埃及的创世神话与尼罗河的季节性泛滥密切相关，反映了水在埃及文明中的核心地位。他们相信世界开始于一座从原初之水中升起的小山，就像尼罗河泛滥退去后露出的肥沃土地。
这些早期的创世叙事不仅解释了世界的起源，也为各自文明提供了宇宙秩序的基础架构，人类在其中找到了自己的位置。它们结合了观察自然现象的经验与对超自然力量的信仰，形成了复杂的世界解释系统。
 1.2. 《吉尔伽美什史诗》
约公元前 2100 年，美索不达米亚（现今伊拉克）用楔形文字将《吉尔伽美什史诗》记录在泥板上。这部作品被公认为人类最早的史诗，见证了文字如何成为跨越时空的记忆载体。
最完整版本出土于亚述国王阿舒尔巴尼拔（公元前 668 到 627 年）的尼尼微图书馆，包含 12 块泥板。这位对知识有着强烈热情的国王派人收集和抄录了大量文献，无意中保存了这部珍贵的史诗，使它得以在数千年后重见天日。19 世纪的考古学家乔治・史密斯在大英博物馆发现并首次解读了其中描述洪水的片段，震惊了学术界。
故事讲述了乌鲁克城邦王吉尔伽美什的冒险。
吉尔伽美什是一位半神半人的国王（三分之二神，三分之一人），力大无穷却暴虐无道。他强迫臣民为他建造城墙，还实行初夜权，引起民众不满。神明创造了野人恩奇都与他抗衡，两人却在搏斗后成为挚友。他们共同击败了森林守护者胡瓦瓦（又称洪巴巴）和天牛，因此激怒了诸神。诸神决定惩罚他们，使恩奇都生病死亡。
恩奇都死后，吉尔伽美什对死亡产生恐惧，决心寻找不死的秘密。他穿越危险的马苏山，遇到了酒馆女主人希杜丽，渡过死亡之水，最终找到了洪水幸存者乌特纳皮什提姆。乌特纳皮什提姆讲述了大洪水的故事，告诉吉尔伽美什有一种能让人恢复青春的水下植物。吉尔伽美什获得了这种植物，但在回程中却被蛇偷走。最终，他带着对生命有限性的理解回到乌鲁克，接受了人类的命运。
无论是谁或许都会对永生产生渴望，面对挚友的离世，我们不禁思考自己的命运。吉尔伽美什的不朽追求正反映了人类面对死亡的普遍恐惧与对永恒的渴望，这一主题在后世文学中不断回响。当恩奇都临死前诅咒让他文明化的女祭司，却被太阳神沙玛什提醒他因文明而获得的好处时，史诗直接提出了关于人类文明本质的深刻问题。
故事中，恩奇都从野人变为文明人的过程揭示了古代美索不达米亚人对文明与自然关系的复杂思考。最初的恩奇都与野兽一同生活，「他的身体覆盖着浓密的毛发…… 他与瞪羚一起吃草，与野兽一起在水边饮水」。当女祭司沙姆哈特引诱他，与她同住七天七夜后，野兽们不再接纳他：「羚羊见到他就跑开了…… 恩奇都的身体变得迟钝，他的腿无法像从前那样快速奔跑。」这一转变既表明了文明的益处，也暗示了其代价。文明为恩奇都带来了友谊、美食、美酒和智慧：「他洗净身体，用油膏抹身…… 他穿上衣服，变得像个战士」，沙姆哈特告诉他：「恩奇都啊，你已经变得像神一样，为何还要与野兽一起在荒野游荡？」
文明使他获得了人性的高贵特质，但也失去了与自然的和谐共处和某种原始的纯真。更深层次上，这反映了农业文明兴起后人类对狩猎采集生活方式的某种怀念，暗示城市文明虽然带来了物质繁荣和知识进步，却也导致了与自然的疏离，并伴随着社会阶层分化和劳动强化。这种二元性在史诗末尾达到高潮 —— 吉尔伽美什虽然没能获得永生，却通过建造城墙（文明的象征）获得了某种形式的不朽。
乌特纳皮什提姆向吉尔伽美什讲述的洪水故事与圣经中的诺亚方舟有着惊人的相似之处，这表明古代近东地区可能确实经历过大洪水，或者这些文明间存在文化交流与影响。在两个故事中，神明都决定毁灭人类，只有一位义人及其家人（和动物）得以幸存。
《吉尔伽美什史诗》确立了英雄叙事的基本模式，探讨的命运、死亡、友谊等主题构成了人类共同的精神遗产。史诗中的重要象征如城墙（文明的边界）、森林（未知与野性）和水（生命与死亡）在后世无数作品中被重新诠释。透过这部作品，我们不仅看到古代美索不达米亚的世界观，也看到了人类自古以来就共有的情感与思考。
什么是史诗？史诗是一种长篇叙事诗，通常描述英雄的冒险或具有民族文化重要性的重大事件。史诗中的主角往往具有超凡品质，面对超越常人的挑战，其行动关乎整个民族或人类的命运。这种文学形式最初通过口头传统流传，由专业吟游诗人在宴会或庆典上演唱，通常伴有乐器伴奏。史诗不仅是娱乐，也是传承文化价值观和集体记忆的重要方式，在文字普及前，口头传统是知识传递的主要渠道。《吉尔伽美什史诗》作为最早被记录的史诗，成为了连接口头传统和书面文学的桥梁。
 2. 古希腊与罗马文学
 2.1. 荷马史诗
 2.1.1. 荷马其人
「荷马」是西方文学传统的奠基者，却也是最神秘的作家之一。传统上认为他是一位生活在公元前 8 世纪的盲诗人，但现代学者对其真实身份存在诸多争议。「荷马问题」涉及《伊利亚特》和《奥德赛》是否由同一人创作，甚至这个「荷马」是否真实存在。许多学者认为这两部史诗可能是几个世纪的口头传统结晶，最终由多位诗人编撰而成。
无论如何，这两部作品奠定了西方文学的基础。它们最初通过口头传统流传，由专业的吟游诗人在贵族宴会和公共节日上吟诵，伴有七弦琴（lyre）伴奏。直到公元前 6 世纪，雅典暴君庇西特拉图斯才下令将它们记录成文。
 2.1.2. 《伊利亚特》
《伊利亚特》成书于约公元前 8 世纪的希腊黑暗时代末期或古风时期初期，书名源自「伊利昂」，即特洛伊城的另一名称。
全诗共 24 卷，以十六音节的六步格（hexameter）写成，描述了特洛伊战争第十年的几周内发生的事件。虽然战争持续了十年，但史诗聚焦于「阿喀琉斯的愤怒」及其后果，而非整个战争过程。开篇即点明主题：「女神啊，请歌唱佩琉斯之子阿喀琉斯的愤怒，这致命的愤怒给阿开亚人带来了无尽的痛苦……」
故事背景是特洛伊王子帕里斯在女神阿佛洛狄忒的帮助下，诱拐了斯巴达国王墨涅拉俄斯的妻子海伦，引发了希腊联军（阿开亚人）对特洛伊的战争。史诗开始时，希腊联军统帅阿伽门农（墨涅拉俄斯的兄长）夺走了阿喀琉斯的女奴布里塞伊斯，激怒了阿喀琉斯，使他退出战斗。
没有阿喀琉斯，希腊军队节节败退。特洛伊英雄赫克托尔（普里阿摩斯国王的长子）率军攻破希腊人的防线，几乎烧毁了他们的船只。阿喀琉斯拒绝亲自出战，但允许他的挚友帕特洛克罗斯穿上自己的盔甲上阵。帕特洛克罗斯奋勇作战，但最终被赫克托尔杀死。
失去挚友的阿喀琉斯悲痛欲绝，重返战场，杀死赫克托尔并亵渎其尸体，拒绝归还。最终，特洛伊国王普里阿摩斯冒险潜入希腊营地，恳求归还儿子的遗体。阿喀琉斯被这位父亲的勇气所感动，同意归还赫克托尔的遗体，史诗以特洛伊人为赫克托尔举行隆重葬礼结束。
《伊利亚特》对古希腊文化产生了无法估量的影响，成为希腊教育的基础和民族身份的核心元素。亚历山大大帝据说随身携带一本《伊利亚特》，视阿喀琉斯为自己的榜样。
《伊利亚特》中的战争是特洛伊人与阿开亚人（早期希腊人）之间的冲突。这场战争不仅是人类间的冲突，诸神也介入其中，支持不同的阵营：阿波罗、阿佛洛狄忒、阿瑞斯支持特洛伊；赫拉、雅典娜、波塞冬则支持希腊人。这种神人交织的叙事反映了古希腊人的宇宙观，其中人类命运受到神明的影响，但个人选择仍具有决定性意义。
诗中充满了对战斗场景的生动描写，其中阵亡士兵的死法往往详细到令人不适的程度：「矛尖刺穿他的颈部，从咽喉穿出，他仰面倒地，铠甲在身上哐当作响」，展现了生命的脆弱与战争的残酷。
史诗也通过展示敌对双方的人性来突破民族界限，最感人的场景之一发生在赫克托尔与妻子安德洛玛刻告别时。赫克托尔脱下头盔抱起幼子，祈祷他将来能超越自己，安德洛玛刻则「含着泪微笑」。这种对敌人的人性化描写，使《伊利亚特》超越了单纯的战争史诗，成为探索人性的永恒经典。
 2.1.3. 《奥德赛》
《奥德赛》创作于《伊利亚特》之后，可能约在公元前 725 到 675 年间。全诗同样分为 24 卷，讲述了伊萨卡国王奥德修斯（拉丁名：尤利西斯）在特洛伊战争结束后历经十年才返回家乡的冒险旅程。
与《伊利亚特》不同，《奥德赛》的故事结构更为复杂，采用了非线性叙事：
史诗开始时，奥德修斯已在女神卡吕普索的岛上被囚禁七年。他的妻子珀涅罗佩在伊萨卡被 108 位求婚者围困，他们消耗着奥德修斯的财富，争夺他的王位。众神决定让奥德修斯回家，只有海神波塞冬因奥德修斯曾伤害其子独眼巨人波吕斐摩斯而继续反对。
女神雅典娜鼓励奥德修斯的儿子特勒马科斯（已二十岁）外出探寻父亲的下落。与此同时，赫耳墨斯奉宙斯之命前往卡吕普索岛，命她释放奥德修斯。后者乘木筏航行，但遭波塞冬掀起的风暴，漂流至费阿基亚。在那里，他向国王阿尔喀诺俄斯讲述了自己的旅程：从特洛伊出发后，他与船员遇到了食莲人、独眼巨人、女巫喀耳刻，他们甚至前往冥界拜访先知泰瑞西阿斯，又遭遇了塞壬女妖、海怪斯库拉和卡律布狄斯，最终全员遇难，只有奥德修斯漂流到卡吕普索岛。
阿尔喀诺俄斯国王被他的故事打动，提供船只送他回伊萨卡。到家后，雅典娜将他变装成老乞丐。他先拜访了忠诚的猪倌尤迈俄斯，与回国的特勒马科斯重逢，然后进入自己的宫殿。在那里，没人认出他，求婚者们还侮辱了他。
珀涅罗佩宣布将举行比赛，谁能用奥德修斯的弓射中目标，她就嫁给谁。求婚者们都无法拉开这把弓，但变装的奥德修斯轻松完成，随后与特勒马科斯和两位忠仆一起杀死了所有求婚者。最后，他向珀涅罗佩证明了自己的身份，两人重聚。
《奥德赛》与《伊利亚特》共同构成了希腊史诗传统的双峰，但两者在主题和风格上有明显区别。如果说《伊利亚特》聚焦战争中的荣耀与悲剧，《奥德赛》则探索返乡、家庭与身份认同的主题。《伊利亚特》中的阿喀琉斯追求不朽的荣耀，宁死不屈；《奥德赛》中的奥德修斯则凭借智慧和坚韧，努力生存并回归家庭。这种转变反映了希腊人价值观的演变，从崇尚战争荣耀到重视智慧与家庭纽带。
《奥德赛》中的奥德修斯展现了希腊人推崇的多才多艺（polymētis）特质：他不仅是战士，更是航海家、说故事的能手、工匠和战略家。当卡吕普索提供永生的诱惑时，他仍选择回到凡间的家庭，这反映了希腊人对人的尊严和选择的重视。
这两部史诗展现了众多半神半人英雄的形象。阿喀琉斯是海洋女神忒提斯与凡人佩琉斯的儿子，海伦则是宙斯与勒达所生。这种半神血统反映了古希腊宗教中神与人之间没有绝对界限的观念，也为英雄的超凡能力提供了解释。
 2.2. 《变形记》
《变形记》完成于约公元 8 年，作者是罗马诗人奥维德（Publius Ovidius Naso，约公元前 43 年 到公元 17 或 18 年）。这部作品是古典文学晚期的巅峰之作，也是奥维德最著名的代表作。
奥维德生活在罗马从共和国转变为帝国的关键时期，是奥古斯都统治下的「黄金时代」诗人。然而，他的《变形记》完成不久后便因不明原因被奥古斯都流放到黑海边缘的小镇托米斯（今罗马尼亚康斯坦察），度过了生命的最后十年。
《变形记》是一部包含约 250 个变形故事的长诗，共 15 卷，约 12,000 行，以六步格写成。不同于传统史诗聚焦单一英雄或事件，《变形记》以「变形」为线索，编织了一个从世界创生到凯撒转变为星辰的连续性叙事。
作品以宇宙从混沌中形成开始：「在大地、海洋和覆盖万物的天空出现之前，自然在整个宇宙中只有一副面孔，人们称之为混沌……」然后描述了四个时代（黄金、白银、青铜和黑铁）的演变，以及普罗米修斯创造人类。
接下来的故事涵盖了众多著名神话：阿波罗追求达芙妮，她变成月桂树；伊卡洛斯飞向太阳，坠入大海；纳西索斯爱上自己的倒影，变成水仙花；俄耳浦斯下冥界寻妻，却因回头一望失去她；皮格马利翁爱上自己雕刻的象牙少女加拉忒亚，维纳斯使其复活；阿拉克涅与雅典娜比赛织布，被变成蜘蛛……
后半部分转向特洛伊战争和罗马的起源：阿喀琉斯之死、奥德修斯的冒险、特洛伊的陷落，以及埃涅阿斯逃离特洛伊并最终到达意大利，成为罗马人的祖先。最后，作品以凯撒之死和奥古斯都赞美结束，暗示历史循环与罗马的永恒。
「变形」（Metamorphosis）一词源自希腊语，意为彻底的形态、结构或性质转变。在奥维德的作品中，变形往往是情感极端表达的结果：因爱而变形（达芙妮），因傲慢而变形（阿拉克涅），因悲伤而变形（俄耳浦斯之妻）。这些变形既是惩罚也是解脱，既是神圣干预也是情感的自然延伸。
奥维德对这些神话采取了一种精致、甚至有些嬉戏的态度，这反映了罗马帝国早期的文化氛围 —— 古老的神话已不再是严肃的宗教内容，而更多地成为艺术创作的素材。他以生动的细节和心理描写赋予这些故事以新的活力：「达芙妮的脸上苍白褪去，取而代之的是树皮；她的头发变成树叶；她的手臂长成枝桠；她那曾跑得如此迅捷的双脚变成固定的树根……」
《变形记》对后世艺术与文学的影响难以估量。它成为中世纪和文艺复兴时期对古典神话的主要来源，启发了但丁、乔叟、莎士比亚等作家，也为无数画家、雕塑家提供了创作题材。以拉斐尔、提香、伦勃朗、鲁本斯为首的艺术大师都创作过基于《变形记》故事的作品。
对于奥维德本人而言，《变形记》也具有某种预言性意义。在结尾他写道：「我已完成了一部不朽的作品，它将超越朱庇特的愤怒和火焰、利剑和时间的腐蚀…… 无论命运对我的身体有何安排，我最好的部分将永存，我的名字将永不消亡。」这位被流放的诗人确实通过自己的作品获得了永生，《变形记》成为将希腊 - 罗马神话传递给后世的最重要桥梁之一。
 3. 印度文学与宗教
 3.1. 印度教背景
在深入探索印度两大史诗之前，了解它们的宗教背景至关重要。印度教是世界上最古老的宗教之一，其历史可追溯至公元前 1500 年左右的吠陀时期。与西方的一神教不同，印度教是一个复杂多元的宗教体系，包含多种哲学观点、崇拜方式和神祇。
印度教的核心经典是《吠陀》（Vedas），共四部：《梨俱吠陀》（赞歌）、《夜柔吠陀》（祭祀歌）、《娑摩吠陀》（旋律）和《阿闼婆吠陀》（咒语）。这些经典最初通过口头传统传承，由婆罗门祭司阶层世代记忆，约在公元前 500 年才开始记录成文。
印度教的神系庞大而复杂。主要神祇包括：
梵天（Brahma）：创造神，宇宙的创造者
毗湿奴（Vishnu）：维护神，宇宙的保护者，通过化身（阿凡达）多次降临人间
湿婆（Shiva）：破坏神，负责宇宙的更新与转变
女神（Devi）：以多种形式出现，如雪山神女（Parvati）、杜尔迦（Durga）和迦梨（Kali）
印度文化中最重要的概念之一是「达摩」（Dharma），这个词难以用单一西方术语翻译。达摩同时指宇宙法则、社会秩序、个人道德义务和正确行为的规范。在不同语境下，它可以理解为「职责」、「美德」、「道德」、「宗教」或「正义」。每个人的达摩取决于其社会地位（瓦尔那）、人生阶段（阿什拉玛）和个人情况，因此构成了一种情境伦理学。
印度史诗不仅是文学作品，也是达摩的实践指南，通过生动的故事说明抽象的宗教概念，向各阶层民众传授价值观。两大史诗《罗摩衍那》和《摩诃婆罗多》早已超越了纯文学范畴，成为宗教典籍，至今仍在寺庙仪式、家庭祭祀和日常生活中发挥重要作用。
 3.2. 《罗摩衍那》
《罗摩衍那》（Ramayana）意为「罗摩的旅程」，约成书于公元前 5 到 4 世纪，传统上认为是由圣人瓦尔米基（Valmiki）创作。原文以梵语写成，包含约 24,000 首诗偈（shloka），分为七卷（kanda）。这部作品被视为阿迪卡维亚（Adikavya），即「第一诗」，标志着梵语诗歌的正式诞生。
《罗摩衍那》的故事广为流传，在东南亚各国有不同版本，并通过各种艺术形式表现，如皮影戏、舞蹈、绘画和现代影视作品。
故事发生在古代印度阿约提亚王国，国王达沙拉塔有三位王后，却一直没有子嗣。他举行祭祀后，四个儿子相继出生：长子罗摩（Rama）出生于王后考萨利亚，次子婆罗多（Bharata）出生于王后凯凯伊，双胞胎弟弟拉克什曼那（Lakshmana）和沙特鲁格纳（Shatrughna）出生于王后苏米特拉。
罗摩成年后，在一次比武大会上拉开了湿婆神的神弓，赢得了邻国国王之女悉多（Sita）的芳心。他们成婚后，老国王准备立罗摩为王储，却被凯凯伊阻止。凯凯伊要求国王实现他曾许下的两个愿望：立婆罗多为王储，并流放罗摩到森林十四年。国王不得不遵守诺言，罗摩欣然接受命运，前往森林。悉多和拉克什曼那坚持跟随他。
在森林生活期间，魔王罗波那（Ravana）对悉多产生了贪念。他派手下将罗摩引开，变身成苦行僧接近悉多，然后绑架她带回自己的王国楞伽岛（今斯里兰卡）。罗摩在猴神哈努曼（Hanuman）的帮助下得知悉多的下落，与猴族结盟，建造连接印度和楞伽岛的大桥，率军攻打楞伽。
经过激烈战斗，罗摩杀死罗波那，解救了悉多。然而，由于悉多在罗波那处滞留多时，民众对她的贞洁产生怀疑。为证明自己的清白，悉多经受了火的考验，安然无恙地从火中走出，证明了自己的纯洁。
流放期满，罗摩返回阿约提亚，婆罗多欣然交还王位。罗摩登基后，依然有人怀疑悉多的贞洁。为了平息谣言，罗摩不得不将已怀孕的悉多再次流放。她在圣人瓦尔米基的庇护下生下双胞胎儿子拉瓦（Lava）和库沙（Kusha）。多年后，罗摩认出了自己的儿子，请悉多回宫，但悉多选择回归大地母亲的怀抱。最终，罗摩完成在世使命，回归毗湿奴的本体。
罗摩作为毗湿奴的第七个化身（avatar），代表了理想君主、完美丈夫和尽职兄长的典范。他的特质被概括为「玛莉亚达・普鲁肖塔马」（Maryada Purushottama），意为「最尊崇道德的人」。在印度文化中，「罗摩拉吉亚」（Ram-Rajya）成为理想王国的代名词，象征公正、繁荣与和谐的统治。
悉多则体现了印度传统中理想女性的特质：忠贞、坚韧、牺牲和对达摩的坚守。她被视为大地女神拉克什米的化身，与罗摩的结合象征着神圣婚姻。然而，现代印度女性主义者对悉多被迫证明贞洁的情节提出了批评，认为这反映了父权制对女性的不公正要求。
《罗摩衍那》对达摩概念的探索尤为深刻。罗摩面临着多重达摩的冲突：作为儿子（尊重父亲的诺言）、作为国王（保护子民）、作为丈夫（保护妻子）。当这些职责相互冲突时，如何抉择成为道德困境。罗摩最终选择了遵守父亲的诺言和履行王者职责，即使这意味着个人幸福的牺牲。这种抉择反映了印度传统价值观中，社会达摩（社会秩序）高于个人达摩（个人情感）的原则。
《罗摩衍那》在印度文化中的影响难以估量。每年的排灯节（Diwali）庆祝罗摩战胜罗波那、回归阿约提亚的胜利，象征光明战胜黑暗。在整个东南亚，罗摩的故事成为了道德教育和文化认同的核心元素。
 3.3. 《摩诃婆罗多》
《摩诃婆罗多》（Mahabharata）意为「伟大的婆罗多（族）史诗」，是世界上最长的史诗，约成书于公元前 4 世纪到公元 4 世纪之间。传统上认为是由圣人毗耶娑（Vyasa）编撰，他也是史诗中的角色。全诗约 100,000 颂（约 1.8 百万字），分为 18 卷和一个附录（哈里旺沙）。
《摩诃婆罗多》的规模和复杂性远超《罗摩衍那》，它不仅讲述了中心故事，还包含了无数支线、伦理讨论、哲学论述和独立故事。正如史诗中所言：「在此未曾提及的事物，世上别处不会有；而此处所言，处处可闻。」
核心故事围绕库卢族两支 —— 般度（Pandava）家族和俱卢（Kaurava）家族 —— 之间的继承权争夺和最终战争展开。
盲王持国（Dhritarashtra）与其弟弟般度（Pandu）共同统治哈斯提那布尔王国。般度早逝，留下五个儿子：长子阿周那（Arjuna）是雷神因陀罗之子，箭术无双；次子悉底米（Bhima）力大无穷；长兄阿修（Yudhishthira）贤明公正；双胞胎弟弟那库罗（Nakula）和萨哈提瓦（Sahadeva）分别擅长医术和占星术。持国则有一百个儿子，为首的是难敌（Duryodhana）。
般度五兄弟与表兄弟们一起长大，接受德罗纳（Drona）大师的武艺训练。阿周那成为最杰出的弟子，引起难敌的嫉妒。长大后，般度五兄弟共同娶了一位妻子德鲁帕蒂（Draupadi），一起统治因陀罗普拉斯塔王国。
难敌设计邀请阿修进行赌博，骗取了般度家族的全部财产和自由。五兄弟被迫流放十三年，其中最后一年需隐姓埋名。期满后，他们要求归还王国，但难敌拒绝。
在黑天（Krishna，毗湿奴的化身）的支持下，般度五兄弟向俱卢家族宣战。战前，黑天成为阿周那的战车御者。当阿周那看到对面阵营中有许多亲友和尊者，不忍作战时，黑天向他讲述了关于达摩、业力和解脱的哲理，这段对话即著名的《薄伽梵歌》（Bhagavad Gita）。
库卢之战持续十八天，双方都使用了神赐武器和非凡战术。般度兄弟最终获胜，但双方均损失惨重，几乎所有主要战士都阵亡。阿修登上王位，统治了三十六年后，五兄弟和德鲁帕蒂决定放弃王位，前往喜马拉雅山寻求解脱。在艰难的旅程中，除阿修外，其他人都因自身缺点而倒下。阿修最终以肉身进入天界。
《摩诃婆罗多》最著名的部分是《薄伽梵歌》，这段约 700 首诗的对话被视为印度教最重要的经典之一。当阿周那在战场上犹豫不决时，黑天揭示了自己作为至高神的身份，讲述了关于行动（karma yoga）、知识（jnana yoga）和虔诚（bhakti yoga）三条解脱之路的教义，强调不执着于行动结果的无私行动（nishkama karma）。
《摩诃婆罗多》对达摩的探讨比《罗摩衍那》更加复杂和微妙。史诗中充满了达摩困境，没有简单的对错答案。例如：
德罗纳作为老师，是否应该在战场上对抗自己的学生？
黑天使用欺骗战术击败俱卢将领，这是否违背战士达摩？
阿修明知赌局有诈，却因王者达摩不得不参与，这种选择是否正确？
这些复杂的伦理问题展示了印度思想对道德相对性的深刻理解，暗示在复杂情境中，达摩的应用需要智慧而非教条。《摩诃婆罗多》的一个核心信息是：有时候任何选择都会导致某种达摩的违背，关键是在冲突中做出最小损害的决定。
阿周那作为《摩诃婆罗多》中最著名的半神英雄，代表了印度传统中理想战士的形象。他兼具超凡的武艺和深刻的精神觉悟，即使在战场上，也不忘思考行动的伦理意义。作为因陀罗之子，他拥有半神的血统，但仍然面临人类的情感和道德困境，这种二元性使他成为深受读者喜爱的复杂角色。
《摩诃婆罗多》对印度文化和宗教的影响无处不在。它不仅提供了伦理行为的范例，也为后世印度哲学和文学提供了思想资源。印度的政治理念、法律概念和社会规范都能在这部史诗中找到根源。在现代印度，《摩诃婆罗多》的改编版本不断出现在电影、电视剧和漫画中，证明这部古老史诗的生命力和现代意义。
 4. 中世纪文学
 4.1. 但丁的《神曲》
 4.1.1. 时代背景与作者生平
《神曲》（Divina Commedia）创作于 1308 至 1320 年，正值欧洲中世纪晚期。这一时期，中世纪神学世界观达到顶峰，同时文艺复兴的曙光已初现意大利。佛罗伦萨作为新兴的城邦共和国，商业繁荣，艺术发达，但也陷入激烈的政治派系斗争中。
作者但丁・阿利吉耶里（Dante Alighieri, 1265-1321）出生于佛罗伦萨一个中等贵族家庭。他 9 岁时邂逅贝雅特丽齐・波尔蒂纳里（Beatrice Portinari），对她产生了柏拉图式的爱慕，这成为他诗歌创作的永恒灵感。贝雅特丽齐 24 岁时去世，但她的形象在但丁心中升华为神圣爱情的象征。
但丁积极参与佛罗伦萨政治，担任过城邦议员和使节。当时意大利陷入教皇派（Guelph）和皇帝派（Ghibelline）的争斗，佛罗伦萨内部教皇派又分为白派（主张城邦自治）和黑派（支持教皇干预）。1302 年，当但丁出使罗马期间，黑派夺权，他被流放并被判处缺席死刑。此后，他流亡北意大利各地，再未能返回故乡。
正是在流亡期间，但丁完成了《神曲》的创作。这部作品不仅反映了他个人的痛苦经历，也是对当时意大利和整个基督教世界精神状况的反思。他于 1321 年 9 月在拉文纳去世，至今长眠于此，而非他深爱的佛罗伦萨。
 4.1.2. 作品结构与内容
《神曲》原名《喜剧》（Commedia），「神曲」（Divina）的称号是后人加上的。全诗采用意大利方言而非当时学术界通用的拉丁语写成，这一大胆创举奠定了意大利文学语言的基础。
诗歌结构严谨，分为三个部分：《地狱篇》（Inferno）、《炼狱篇》（Purgatorio）和《天堂篇》（Paradiso），每部各 33 篇（canto），加上《地狱篇》的序篇，共 100 篇。这种数字象征主义贯穿全诗：3 代表三位一体，9（3×3）代表神圣完美，10 代表宇宙秩序。诗歌采用三行韵（terza rima）形式，即 ABA BCB CDC…… 的押韵模式，创造出前进不息的韵律感。
故事始于 1300 年的圣周五前夜（耶稣受难日之前），35 岁的但丁迷失在「黑暗的森林」中，象征人生中途的精神迷茫。他试图攀登光明之山，却被三只野兽（豹、狮、母狼，象征情欲、骄傲和贪婪）阻挡。此时，古罗马诗人维吉尔（Virgil）出现，告诉但丁必须通过地狱和炼狱才能到达天堂，并提出担任他的向导。
在《地狱篇》中，但丁和维吉尔穿过地狱的九个同心圆层，每层惩罚一种罪行，越往下罪行越重：第一层是未受洗礼的美德之人；第二至第五层是放纵、贪食、贪婪和愤怒；第六层是异端；第七层是暴力；第八层是欺诈；最深的第九层是背叛，其中最恶劣的叛徒犹大、布鲁图斯和卡修斯被路西法（Satan）亲自啃噬。地狱入口铭刻着著名警句：「进入此门，离弃所有希望。」
《炼狱篇》描述两人穿过地球中心，来到南半球的炼狱山。炼狱分为七个层级，对应七宗罪（傲慢、嫉妒、愤怒、懒惰、贪婪、贪食、淫欲），灵魂在此净化罪恶，为进入天堂做准备。在炼狱的顶端是伊甸园，但丁在此与贝雅特丽齐重逢，维吉尔则离去（作为异教徒，他不能进入天堂）。
在《天堂篇》中，贝雅特丽齐引导但丁穿越九层天：月亮、水星、金星、太阳、火星、木星、土星、恒星天和原动天，最后到达超越时空的天国玫瑰（Empyrean），在那里他得见上帝的荣光，体验到终极的神圣之爱。
整部作品构成了一次精神朝圣，从罪恶和迷失，经过忏悔和净化，最终达到救赎和启示。这反映了基督教神学中灵魂得救的历程，也象征人类普遍的精神成长路径。
 4.1.3. 思想内涵与影响
《神曲》最显著的特点是将基督教神学与古典人文主义融为一体。维吉尔代表人类理性和古典智慧，贝雅特丽齐则象征神圣启示和信仰。但丁虽然是虔诚的基督徒，却给予古典文化（尤其是维吉尔）崇高地位，甚至将许多古代哲人安置在地狱的较轻微区域，这预示了文艺复兴对古典文化的重新尊崇。
作品充满了丰富的象征主义。地狱的漏斗形状象征远离上帝的堕落；炼狱的螺旋山路表示艰难但充满希望的攀登；天堂的同心圆体现了完美的神圣秩序。三位主要向导（维吉尔、贝雅特丽齐和圣贝尔纳多）分别代表理性、信仰和神秘体验，构成了中世纪认识论的三个层次。
《神曲》展现了中世纪宇宙观的完整图景。根据托勒密体系，但丁的宇宙以地球为中心，地狱位于地下，天堂环绕地球，形成一个层级分明的有机整体。这种秩序化的宇宙观反映了中世纪思想中，物质世界与精神世界、自然秩序与道德秩序的对应关系。
作品中充满了对当时政治、宗教和社会问题的评判。但丁大胆地将许多教皇、政治人物和同时代人安置在地狱中，表达了他对教会腐败和意大利政治混乱的强烈批判。他理想中的世界秩序是教皇领导精神事务，皇帝管理世俗事务，两者相互独立又相互配合。
在文学技巧上，《神曲》创造了前所未有的叙事深度。但丁不仅是故事的主角，也是叙述者和评论者，时而参与情节，时而抽身反思，创造出多层次的叙事视角。他对人物心理的细腻描写和对复杂情感的捕捉，超越了同时代的大多数作品。
《神曲》对后世的影响难以估量。在文学上，它启发了从薄伽丘到乔叟，从弥尔顿到艾略特的众多作家；在美术上，波提切利、米开朗基罗和多雷等艺术家为它创作了著名插图；在音乐上，李斯特、柴可夫斯基和普契尼等作曲家受其启发创作了重要作品。更广泛地说，《神曲》塑造了西方文化对来世、罪恶与美德的想象，成为连接中世纪与现代的关键桥梁。
 4.1.4. 与但丁相遇的重要人物和故事
但丁在冥界旅途中遇到众多历史和当代人物，每个故事都深具象征意义。在地狱第二环，他遇到了保罗和弗兰切斯卡，两人因通奸而被杀，永远被风暴卷在一起，象征情欲之罪；在第三环，他认出了贪食者恰科，后者预言佛罗伦萨的政治斗争；在第八环，他与曾任教皇的尼古拉三世交谈，后者因贪污被倒插在岩洞中。
特别值得一提的是尤利西斯（奥德修斯）的故事。但丁在第八环遇到这位希腊英雄，他因欺骗之罪被惩罚。尤利西斯讲述了自己如何不满足于平静的家庭生活，渴望探索未知世界，最终率领船员越过海克里斯柱（直布罗陀海峡），航向禁区，导致全船覆没。这个故事被许多学者解读为对人类求知欲的双重态度：既钦佩其勇气，又警惕其傲慢。
在《炼狱篇》中，但丁遇到许多艺术家和诗人，包括音乐家卡塞拉和诗人索尔德洛。在第五层，他看到教皇阿德里安五世因贪婪而俯卧在地；在第七层，他与古罗马诗人斯塔提乌斯交谈，后者刚完成净化，准备上升天堂。
《天堂篇》中，他在太阳天遇到神学家托马斯・阿奎那和圣方济各；在火星天，他遇到了十字军战士和佛罗伦萨的先祖卡恰圭达；在土星天，他与本笃会修士彼得・达米安交谈，后者谴责教会腐败。
《神曲》通过这些活灵活现的角色和引人入胜的故事，将抽象的神学概念具象化，展现了人类命运的多样性和生命抉择的重要性。但丁的天才在于，他创造的不是教条式说教，而是充满人性光辉的复杂世界，即使在最严厉的道德判断中，也流露出对人类弱点的深刻理解和同情。
自战后至今，《神曲》仍是西方文学最具影响力的作品之一，被翻译成世界上几乎所有主要语言。2021 年是但丁逝世 700 周年，世界各地举行了纪念活动，证明这位「神圣诗人」的作品超越了时空限制，继续对人类精神世界产生深远影响。
 5. 宗教经典文学
 5.1. 《圣经》
《圣经》（Bible）一词源自希腊语「biblia」，意为「书籍」，是犹太教和基督教的核心经典。它不是单一作品，而是由多位作者在长达千年的时间里（约公元前 1200 年至公元 2 世纪）创作的文集。《圣经》原文主要使用希伯来语、亚兰语和希腊语写成，如今已被翻译成 3000 多种语言，是世界上发行量最大、影响最广的文本。
《圣经》分为《旧约》（Old Testament）和《新约》（New Testament）两大部分。《旧约》被犹太教和基督教共同承认，《新约》则仅为基督教经典。
 5.1.1. 旧约概述
《旧约》（犹太教称为《塔纳赫》）包含 39 卷书，可分为四部分：
摩西五经（Torah / Pentateuch）：《创世记》《出埃及记》《利未记》《民数记》《申命记》，记录世界创造、族长故事、以色列人出埃及和摩西律法。
历史书：从《约书亚记》到《以斯帖记》，描述以色列人占领迦南地、建立王国、分裂、被掳与归回的历史。
智慧文学：《约伯记》《诗篇》《箴言》《传道书》《雅歌》，探讨生命意义、苦难、爱情等普遍人类问题。
先知书：从《以赛亚书》到《玛拉基书》，记录先知对以色列民族和周边国家的预言和劝诫。
《旧约》通过神权史观展示了上帝（雅威）与以色列民族的立约关系。在这一框架中，历史事件被解释为上帝对以色列人忠诚或背叛的回应。《旧约》同时探讨了普世伦理问题，如公正、怜悯和人类在宇宙中的位置。
 5.1.2. 《约伯记》
《约伯记》可能完成于公元前 6 到 4 世纪，是《旧约》中最引人深思的智慧文学作品之一。它以散文序幕和结尾，辅以长篇诗歌对话，探讨了「为何义人受苦」这一永恒难题。
故事开始于上帝与撒旦关于义人约伯的对话。撒旦质疑约伯的虔诚只是因为他蒙福，上帝允许撒旦考验约伯，但不可取他性命。接着，约伯失去所有财产、子女，并染上恶疾，但他仍然持守信仰：「赏赐的是耶和华，收取的也是耶和华。」
约伯的三个朋友以利法、比勒达和琐法前来安慰，但逐渐转向指责，认为约伯一定犯了隐秘罪行才受此惩罚。他们代表了传统神学观点：义人受福，恶人遭殃。约伯则坚持自己的无辜，质疑上帝的公正：「我今日发出悲叹，我的创伤沉重，不得休息。」他要求与上帝直接对质。
年轻的以利户插入讨论，提出苦难可能是上帝的管教和教育。最终，上帝从旋风中显现，但并未直接回答约伯的问题，而是通过展示创造的奇妙与复杂，质问约伯是否有资格审判上帝的行为：「我立大地根基的时候，你在哪里呢？」
约伯认识到人类理解的局限，承认自己「说了自己不明白的事」。上帝恢复约伯的财富，赐给他新的儿女，约伯得享长寿。
《约伯记》的核心问题是「神义论」（theodicy）：如果上帝全能且全善，为何允许恶和苦难存在？尤其是，为何义人也会受苦？文本并未提供简单答案，而是呈现了几种可能的解释：
苦难是对信仰的考验
苦难是上帝的管教
上帝的计划超出人类理解范围
与上帝的相遇本身，而非理性解释，才是苦难的终极回应
这种对简单解释的拒绝，以及对宗教经验复杂性的坦诚，使《约伯记》成为世界文学中最深刻的作品之一。其中第四个解释 ——「与上帝的相遇本身，而非理性解释，才是苦难的终极回应」—— 尤其具有存在主义式的突破性：这一解释突破了传统神义论的框架，指向一种存在主义式的宗教体验。当上帝从旋风中显现时（《约伯记》38-41 章），祂并未像法庭上的被告般回答约伯的质询，反而以一连串 137 个反问构建出恢弘的宇宙图景：
「你能系住昴星的结吗？能解开参星的带吗？」
「山岩间的野山羊几时生产，你知道吗？」
「马的大力是你所赐的吗？它颈项上挓挲的鬃是你披上的吗？」
这种充满十星张力的「非答案」，实则蕴含着深刻的解构：
超越交易式信仰的灵性觉醒
传统宗教常将苦难视为「罪与罚」的因果链条（如约伯三友的立场），但上帝亲自否定了这种简化的功利主义逻辑。约伯的终极安慰不在于恢复双倍财产（42:10），而在于从「听见传说」（42:5）到「亲眼见你」（42:5）的认知跃迁 —— 这暗示真正的信仰不是利益交换，而是在与绝对他者的相遇中重塑存在维度。
认知暴力的消解与谦卑的重构
上帝的反问本质上是认知论革命：当人类试图用理性框定神圣意志时，实则是将无限者降格为可量化的对象。风暴中的上帝显现（theophany）以压倒性的美学体验，瓦解了约伯先前法庭辩论式的逻辑框架 —— 正如犹太哲学家马丁・布伯在《我与你》中指出，神圣相遇发生在「我 - 你」关系而非「我 - 它」的分析中。
苦难作为启示的催化剂
值得注意的是，约伯在顺境中从未要求见上帝。正是极端的苦难打破了他对「正义世界假设」（just-world hypothesis）的执念，迫使其进入更深层的灵性追问。这呼应了克尔凯郭尔所言：「只有当个人被推向极端处境时，才能与永恒建立真实关系。」苦难在此成为解构表象、触及本真的契机。
现代性的先知预表
卡夫卡在《审判》中让 K 至死未见「法」的真容，而约伯却获得了戏剧性的反转 —— 但这恰恰形成双重讽喻：卡夫卡展现现代人神性缺位的荒诞，而《约伯记》早在两千年前就预言，即便上帝显现，人类依然无法获得明晰答案。两者共同指向存在主义的核心命题：在无意义中创造意义，在沉默中聆听启示。
这种「答案即非答案」的悖论，在犹太教卡巴拉神秘主义中发展为「神圣收缩」（Tzimtzum）理论 ——  上帝必须隐藏自身才能创造空间让世界存在。正如 13 世纪诗人鲁米所言：「伤口是光进入你内心的地方。」《约伯记》最终揭示的，或许正是苦难作为灵性裂痕，让神圣之光得以照入人性的深渊。
 5.1.3. 新约
《新约》由 27 卷书组成，包括四福音书、《使徒行传》、保罗书信、其他书信和《启示录》。它记录了耶稣基督的生平、教导、死亡与复活，以及早期基督教的发展。
 5.1.4. 四福音书概述
「福音」（Gospel）一词源自希腊语「euangelion」，意为「好消息」，指耶稣基督带来的救恩。四福音书分别是《马太福音》《马可福音》《路加福音》和《约翰福音》，均成书于公元 1 世纪后半叶，用希腊语（Koine Greek，通用希腊语）写成。
前三部福音书（马太、马可、路加）因内容相近而被称为「对观福音」（Synoptic Gospels）。学者普遍认为《马可福音》最早成书，《马太》和《路加》在此基础上扩展，并加入被称为「Q 资料」的共同口传材料。《约翰福音》则独立于对观福音传统，提供了不同的神学视角。
传统上认为四福音书的作者分别是：
马太：耶稣的十二门徒之一，原为税吏
马可：彼得的同工和翻译
路加：保罗的同伴，医生和历史学家
约翰：耶稣所爱的门徒，也是《启示录》和约翰书信的作者
然而现代学术研究认为，四福音书可能是早期基督徒社群集体创作的成果，而非个人作品。无论如何，它们代表了早期基督教对耶稣事迹和教导的不同理解和强调。
每部福音书都有其独特视角和神学强调：
《马太福音》：主要受众为犹太基督徒
核心主题：耶稣是应验旧约预言的弥赛亚（基督）
频繁引用旧约预言；强调耶稣是新摩西；颁布新律法（如山上宝训）；包含五大讲论
独特材料：东方博士来朝；逃往埃及；八福；比喻中的绵羊和山羊
耶稣的形象为大卫的子孙、合法的犹太王
《马可福音》：主要受众为罗马基督徒
核心主题：耶稣是受苦的仆人、带来上帝的国度
是最短且最早的福音书；强调十字架和受苦
独特材料：较少独特材料；强调「弥赛亚的秘密」
耶稣的形象为受苦的人子、战胜邪灵的驱魔者
《路加福音》：主要受众为希腊人和外邦人
核心主题：耶稣带来普世救恩，特别关注弱势群体
历史细节丰富；与《使徒行传》成对；强调祷告和圣灵
独特材料：天使报喜；牧羊人来访；浪子回头；好撒玛利亚人
耶稣的形象为完美人性的救主、关爱穷人和被社会边缘化者
《约翰福音》：主要受众为广泛的希腊、罗马世界
核心主题：耶稣是成肉身的道（logos），是上帝的儿子
高度象征性和神学性；使用「我是」宣言；强调耶稣的神性
独特材料：迦拿婚宴；尼哥底母夜访；与撒玛利亚妇人对话；拉撒路复活
耶稣形象：永恒的道成肉身，与父合一的神圣启示者
四部福音书虽各有侧重，但共享基础叙事框架：
救赎序幕：施洗约翰的预备（玛 3:1/可 1:2/路 3:4/约 1:23）
加利利事工：呼召门徒、治病驱魔、登山宝训等（太 4-18/可 1-9/路 4-9/约 1-6）
耶路撒冷之旅：面向十字架的转折（太 19-20/可 10/路 9:51-19:27/约 7-12）
受难周：荣入圣殿、最后晚餐、被捕受审（太 21-27/可 11-15/路 19:28-23:56/约 12-19）
复活显现：空坟墓与复活见证（太 28/可 16/路 24/约 20-21）
这种三层递进结构（启示→冲突→救赎）塑造了基督教的核心救赎叙事。四重见证既形成立体视角 —— 马太的律法成全、马可的戏剧张力、路加的人文关怀、约翰的永恒维度 —— 又通过差异化的细节选择（如只有约翰记载「复活拉撒路」）形成神学互补。
尽管视角各异，四福音书共同见证了耶稣的生命、教导、死亡和复活，以及这些事件对人类历史的深远意义。
 5.1.5. 历史上的基督
根据学术研究，历史上的耶稣（Jesus of Nazareth）生活在约公元前 4 年至公元 30 到 33 年，出生于犹太加利利地区的拿撒勒，在罗马帝国统治下的巴勒斯坦地区传道。他是犹太人，受过施洗约翰的洗礼，聚集了一群门徒，巡回教导和治病。他的教导挑战了当时的宗教权威，特别是在耶路撒冷圣殿的做法。根据福音书记载，他最终在逾越节期间被罗马总督本丢・彼拉多判处钉十字架刑。
耶稣的教导核心包括上帝的国（Kingdom of God）、爱的律法、末世预言和个人与上帝的直接关系。他经常通过比喻和隐喻传递信息，其教导既扎根于犹太传统，又具革新性。
关于耶稣复活的记载是基督教信仰的基础，但这超出了历史研究的范畴，进入信仰领域。无论如何，耶稣及其追随者创立的运动最终发展成为世界性宗教，深刻塑造了人类历史。
 5.2. 《古兰经》
《古兰经》（Al-Qur'an，意为「诵读」）是伊斯兰教的核心经典，穆斯林相信它是真主（Allah）通过天使吉卜利勒（Gabriel）向先知穆罕默德（Muhammad，约 570 到 632 年）的启示，在公元 610 到 632 年间陆续降示。
 5.2.1. 结构与内容
《古兰经》由 114 章（苏拉，Surah）组成，除第一章外，大致按长度递减排列。全书约 77,000 词，长度与《新约》相近。它以阿拉伯语写成，穆斯林认为其阿拉伯文本具有神圣性，翻译只能视为解释，而非《古兰经》本身。
《古兰经》内容包括：
一神论（tawhid）、末日审判、众先知传承
亚当、挪亚、亚伯拉罕、摩西和耶稣等先知的故事
伦理道德，如正义、诚实、谦卑、怜悯、慷慨
法律规定，如礼拜、施舍、婚姻、继承、商业交易
天地万物的起源与目的
《古兰经》通过神圣启示的透镜，展现从创世到末日的宏大救赎史诗：
创世之谜（30:20-25）
真主从水上创造生命（21:30），赋予人类代治大地的使命。阿丹（亚当）被造为「真主在大地上的代治者」（2:30），但因易卜劣厮（撒旦）的诱惑堕落，开启人性考验的序幕。
先知长链（40:78）
从努哈（诺亚）的方舟、易卜拉欣（亚伯拉罕）捣毁偶像，到穆萨（摩西）分开红海，26 位先知的故事构成神圣启示的连续剧。尤素福（约瑟）被兄长出卖终成埃及宰相的故事（12 章），成为人性善恶博弈的缩影。
终极启示（33:40）
穆罕默德在希拉山洞接受首次启示：「你当奉造物主的名义诵读！」（96:1）。历经 23 年启示，对抗麦加多神崇拜，建立麦地那穆斯林共同体，最终在辞朝演说中宣告：「今天，我已为你们成全你们的宗教」（5:3）。
审判之日（82:1-5）
当苍穹破裂、群星飘坠时（82:1-2），每个人将看到自己行为的账簿：「行一个小蚂蚁重的善事者，将见其善报；作一个小蚂蚁重的恶事者，将见其恶报」（99:7-8）。
这些叙事如镶嵌画般散落各章，通过「认主独一」的金线交织成整体。正如夜行登霄（17:1）的隐喻 —— 先知从麦加禁寺升至七重天，最终回归人间 —— 象征人类从物质世界向神圣本源的溯游与复归。
《古兰经》的语言具有独特的韵律美和修辞力量，被视为阿拉伯文学的巅峰，对阿拉伯语的标准化和发展产生了决定性影响。
 5.2.2. 与其他一神教经典的关系
《古兰经》承认并尊重犹太教和基督教的先知与经典。它提到《讨拉特》（Torah，摩西五经）、《宰逋尔》（Zabur，诗篇）和《引支勒》（Injil，福音）等早期启示。穆斯林相信《古兰经》是最后也是最完美的启示，纠正了之前经典中被人篡改的部分。
《古兰经》继承并重新诠释了许多圣经故事。例如，亚伯拉罕（Ibrahim）被描绘为最早的穆斯林（顺从者）；约瑟夫（Yusuf）的故事被完整讲述在第 12 章；耶稣（Isa）被尊为重要先知，但《古兰经》否认他的神性和被钉十字架的说法。
 5.2.3. 盟约概念的延续与发展
「约」的概念从希伯来圣经延续到《新约》，再到《古兰经》，体现了一神教传统中上帝与人类关系的发展。在《古兰经》中，真主与人类的原初契约（Primordial Covenant）发生在创造之初，所有人类灵魂被问及：「难道我不是你们的主吗？」他们回答：「是的，我们作证。」（7:172）
这一概念与犹太教和基督教的盟约神学有相似之处，但更强调每个人与真主的直接关系，而非通过特定民族或中介。伊斯兰教认为，每个人生来就带有对真主的自然认知（fitrah），伊斯兰的使命是唤醒这种本性，而非引入全新的概念。
《古兰经》对盟约的理解展现了一神教思想的演进：从上帝与特定民族（以色列）的契约，到基督教强调通过耶稣建立的新约，再到伊斯兰教强调的普遍原初契约。这一演进反映了宗教概念的普世化趋势。
 5.3. 印度教经典
印度教与西方一神教传统显著不同，它没有单一创始人、统一教义或中央权威，而是由多种哲学思想、崇拜方式和文化习俗组成的复杂系统。其核心经典也非单一文本，而是随时间演变的丰富文献传统。
 5.3.1. 《吠陀》
《吠陀》（Vedas，意为「知识」）是印度最古老的宗教文献，约成形于公元前 1500-500 年，最初通过口头传诵，后来才记录成文。吠陀文献分为四部：
《梨俱吠陀》（Rigveda）：最古老部分，包含 1,028 首赞美诗，主要献给阿格尼（火神）、因陀罗（雷神）、索玛（月神）等自然神祇。
《夜柔吠陀》（Yajurveda）：祭祀仪式的诵词和指导，包括黑夜柔和白夜柔两个传本。
《娑摩吠陀》（Samaveda）：祭祀中的颂歌，多数取自《梨俱吠陀》但配以旋律。
《阿闼婆吠陀》（Atharvaveda）：包含咒语、医药知识和哲学思考，反映了普通民众的宗教实践。
每部吠陀又分为四个部分：
本集（Samhitas）：原始颂歌和祭祀诵词
梵书（Brahmanas）：祭祀仪式的解释和指导
森林书（Aranyakas）：适合林居者的冥想实践
奥义书（Upanishads）：哲学探讨和精神智慧
吠陀文献通过诗性想象构建了动态的宇宙图景，其核心叙事可概括为三幕神圣戏剧：
原人之祭
《梨俱吠陀》第 10 卷第 90 首《原人歌》描绘惊心动魄的创世场景：
「原人有千头千眼千足，覆盖全地…… 诸神将原人作为祭品，春天为酥油，夏天为燃料，秋天为祭品…… 由其身体分化世界：头为天，足为地，呼吸生风，脐部生空界」（10.90.1-14）。这血腥而神圣的献祭确立了「祭祀即宇宙法则」（yajña）的核心理念。
因陀罗屠龙
雷神因陀罗与蛇形魔神弗栗多（Vritra）的对抗是《梨俱吠陀》最壮丽的史诗：
「他（因陀罗）举起金刚杵，击杀盘踞山中的巨龙，释放被囚禁的江河…… 七座城堡在他怒吼中崩塌」（1.32.1-5）。这场战役象征自然力（雨水 / 干旱）的斗争，更隐喻秩序（ṛta）对混沌的胜利。
苏摩之谜
诸神饮用的永生甘露苏摩（Soma）在祭祀中具象化为仪式饮品，《梨俱吠陀》第 9 卷专述其奥秘：
「我们饮下苏摩，获得不朽…… 它在石间榨取，如野牛咆哮，赋予诗人神力」（9.4.1-3）。这种致幻植物酿制的圣酒，成为连接人神的中介，激发吠陀先知（ṛṣi）的灵视。
吠陀叙事最终落地为现实的火祭（agnihotra）仪式：
黎明与黄昏，祭司将酥油倒入圣火，重演原初祭祀
吟诵《梨俱》诗节召唤诸神，如「阿耆尼啊，你是家族祭司，真理的见证者」（1.1.1）
通过《夜柔》指导的精准仪式动作，维系宇宙呼吸的节奏
这种「神话 - 仪式」的闭环结构，使吠陀文明成为活态的神圣剧场。
《吠陀》反映了早期印度 - 雅利安人的世界观，展示了从自然崇拜向抽象哲学思考的演变。它们构成了印度所有哲学和宗教传统的基础，即使是批判吠陀权威的佛教和耆那教，也与吠陀传统有深刻联系。
《吠陀》的宇宙观围绕着「天道」（rita）概念，认为宇宙受到一种固有秩序的支配，通过适当的祭祀活动，人类可以维护这一秩序。《梨俱吠陀》中的《原人赞》（Purusha Sukta）描述世界起源于原初神人的祭祀，社会等级制度也源于此。这种宇宙 - 社会对应关系影响了印度文化数千年。
 5.3.2. 《奥义书》
《奥义书》（Upanishads，意为「坐于附近」，暗示师徒间的秘密教导）是吠陀传统的哲学高峰，约成形于公元前 800-200 年。传统认为有 108 部奥义书，但最重要的是早期的主要奥义书，如《伊舍》《迦他》《文荼迦》《曼荼迦》等。
《迦陀奥义书》记载了少年纳奇柯达斯与死神阎摩的传奇对话：
少年自愿走向冥界之门，用生命换取终极智慧。死神三次试图用诱惑劝退他：
第一次考验：「回去吧！我将赐你百象千金的财富」
少年答：「财富如朝露，请赐我超越生死的智慧」（1.1.24-25）
第二次考验：阎摩展示天界乐园 —— 黄金宫殿与不朽青春。
少年问：「当肉体消亡时，这些享乐将归于何处？」（1.2.10）
第三次考验：死神化作美艳女神，许诺永恒欢愉。
少年说：「感官如野马，唯有驭手（智慧）能达彼岸」（1.3.3-4）
最终阎摩揭示最高真理：
「知梵者超越生死，如同水溶于水，火归于火。自我（Atman）是战车主人，身体是战车，智慧是御者……」（1.3.9-14）
少年领悟「汝即彼」（Tat Tvam Asi）的真谛，肉身重返人间时，死亡枷锁已化为晨露。
《大林间奥义书》的创世寓言：
原初的自我（Ātman）在混沌中自语：「我是谁？」
他分裂为男女二形，交合诞生万物。但雌性化为母牛逃避，雄性化为公牛追逐；雌性变母马，雄性变公马…… 如此衍生众生（1.4.3-6）。
当他意识到「万物即自我」时，发出震撼三界的宣言：
「我是创造！我是毁灭！我是呼吸中的呼吸！光中的光！」（5.15.1）
这个自我探索的寓言，成为吠檀多哲学「梵我同一」的终极隐喻。
《奥义书》标志着印度思想从祭祀仪式向内在探索的转向。它们的核心思想包括：
梵我同一：个体灵魂（Atman，我）与宇宙本体（Brahman，梵）本质上是同一的。《文荼迦奥义书》宣称：「认识梵者，即成为梵。」这一洞见成为印度哲学的基石。
轮回与解脱：灵魂因无明（avidya）而困于生死轮回（samsara）；通过正确认识自我本性，可以获得解脱（moksha）。
业力法则：行为（karma）产生后果，决定未来生命形式和经历。
知行并重：既重视知识（jnana），也重视行动（karma）和虔诚（bhakti）。
《奥义书》对印度哲学和宗教产生了决定性影响，所有后来的印度哲学流派，如吠檀多（Vedanta）、数论（Samkhya）、瑜伽（Yoga）等，都可视为对《奥义书》思想的不同诠释。即使佛教的「无我」（anatta）理论，也可理解为对奥义书「我」（atman）概念的批判性发展。
《奥义书》也影响了西方思想。19 世纪，叔本华接触到《奥义书》拉丁文译本后宣称：「它们是人类智慧的产物」；爱默生、梭罗等超验主义者从中汲取灵感；科学家如特斯拉、爱因斯坦和薛定谔也表达过对奥义书思想的赞赏。
 5.3.3. 达摩 / 法概念
达摩（Dharma，巴利语：Dhamma）是印度宗教哲学中的核心概念，其含义随语境而变化，难以用单一西方术语准确翻译。
在最广泛意义上，达摩指维持宇宙和社会秩序的根本法则。更具体地说，它可以指：
宇宙法则：支撑世界运行的自然规律
社会职责：基于种姓（varna）和人生阶段（ashrama）的社会责任
种姓体系源于《梨俱吠陀》的《原人歌》（10.90.12），将社会分为四个理想类型：
婆罗门（Brāhmaṇa）：祭司与学者，职责为研习吠陀、主持祭祀
刹帝利（Kṣatriya）：武士与统治者，负责保护众生、执行正义
吠舍（Vaiśya）：农民与商人，从事农业、畜牧与贸易
首陀罗（Śūdra）：劳动者，服务前三个种姓
这种「原人身体分化说」（婆罗门生于口，刹帝利生于臂，吠舍生于腿，首陀罗生于足）在《摩奴法典》（约公元前 2 世纪）中被系统化为社会规范。但现实中还存在数千个亚种姓（jati），基于职业、地域形成复杂网络。
每个种姓有其专属的「种姓法」（svadharma）：
婆罗门需终身学习，刹帝利需精于武艺，吠舍应诚实经商，首陀罗要勤于服务
违反种姓职责被视为「违逆达摩」，如《薄伽梵歌》警告：「履行他人职责是危险的」（3.35）
但《摩诃婆罗多》也通过妓女苏达玛的故事质疑僵化制度：她因诚实比许多婆罗门更接近真理
值得注意的是，佛教和耆那教在继承达摩概念时，都批判种姓制度。佛陀宣称：「河水入海皆失旧名，四姓入我法中亦复如是」（《小部・经集》2.7）。
道德行为：正义、诚实、非暴力等普遍美德
宗教教义：特定宗教传统的核心教导（如佛法）
在《摩诃婆罗多》中，达摩概念被深入探讨，特别是在面临道德困境时。例如，阿周那在库卢之战前犹豫不决，因为无论他选择战斗还是退出，都会违背某种达摩（战士职责与家族责任的冲突）。黑天的教导（《薄伽梵歌》）解决了这一困境，强调行动本身不如行动时的心态重要，提倡「无执着的行动」（nishkama karma）。
与希腊悲剧类似，印度史诗中的达摩困境展示了道德选择的复杂性和悲剧性。然而，不同于希腊宿命观，印度思想强调通过正确理解和超越二元对立，可以解决这些冲突。《薄伽梵歌》教导阿周那战斗不是为了个人利益，而是为了维护宇宙秩序，这种理解将个人行动与宇宙规律统一起来。
达摩概念在印度各宗教传统中有不同解释。印度教强调种姓职责；佛教将达摩理解为宇宙真理和佛陀教导；耆那教极度强调非暴力（ahimsa）作为达摩的核心。尽管解释各异，达摩作为指导个人行为、社会关系和宇宙秩序的核心原则，贯穿了印度思想的各个流派。
 6. 中国古代思想经典
 6.1. 中国思想传统概述
在探讨具体经典前，先了解中国古代思想的整体背景十分必要。中国哲学与西方和印度传统有着根本性差异，它较少关注形而上学或宗教启示，而更专注于社会伦理、政治秩序和个人修养的实用智慧。
中国古代思想形成于春秋战国时期（公元前 770-221 年），这一被称为「百家争鸣」的时代，各种思想流派相互竞争，为解决社会动荡和道德危机提供方案。主要流派包括儒家、道家、墨家、法家、名家等。其中最有持久影响的是儒家和道家，它们代表了中国思想的两大主要取向。
中国古典哲学的特点包括：
重实践轻理论：关注现实生活而非抽象概念
天人合一：强调人与自然和谐共处
整体性思维：倾向于综合而非分析
重德行轻信仰：以伦理修养而非宗教信条为核心
注重中庸之道：追求平衡与和谐，避免极端
这些特点使中国哲学既独特又互补于西方和印度传统，为人类文明提供了另一种智慧路径。
 6.2. 《论语》
 6.2.1. 成书背景与历史地位
《论语》（Analects）是记录孔子（公元前 551-479 年）及其弟子言行的语录集，由孔子门人及再传弟子编撰，约成书于公元前 5-4 世纪。它包含 20 篇，共 492 章，主要采用对话形式，记录孔子与弟子、诸侯及他人的交谈。
《论语》的名称意为「讨论的言辞」，反映了它并非系统哲学著作，而是思想碎片的汇集。它通过简短对话和言论，展现孔子思想的多个方面，需要读者自行连接和解读。
作为儒家经典「四书」之首（其他三部为《大学》《中庸》《孟子》），《论语》在中国文化中的地位无可比拟。它不仅是中国古代教育的核心教材，也深刻影响了东亚文化圈（包括日本、朝鲜、越南）的思想传统。自汉代起，《论语》成为科举考试的必考内容，塑造了中国知识分子的思维方式和价值观。
 6.2.2. 孔子及其时代
孔子生活在社会动荡的春秋末期，周王室衰微，诸侯争霸，礼崩乐坏。他生于鲁国（今山东曲阜）一个没落贵族家庭，年轻时曾做过小吏，后来创办私学，收徒讲学。他周游列国十四年，希望说服统治者采纳他的政治理念，但未能如愿。晚年返回鲁国，致力于整理古代文献和教育事业。
孔子自称「述而不作」，表明他不是创新者，而是古代文化的传承者和诠释者。然而，他对传统的重新解释实际上具有深刻的创新性，将古代贵族礼仪转化为普遍适用的伦理原则，使道德从血缘和地位的限制中解放出来。
他的生平和教学方法在《论语》中有生动描述：「子曰：『默而识之，学而不厌，诲人不倦，何有于我哉？』」（《述而》）这种谦虚和教学热忱塑造了他作为中国历史上最伟大教育家的形象。
这句自述集中体现孔子的教育哲学：
默而识（zhì）之：把所见所闻默默记在心里识：不是死记硬背，而是理解内化
学而不厌：努力学习从不满足「厌」通「餍」，意为满足
诲人不倦：教导别人从不厌倦
何有于我哉表面自谦：「这些我做到了哪些呢？」
实则暗含期许：「这些不正是教育者的本分吗？」
 6.2.3. 核心思想
《论语》虽然不是系统哲学著作，但包含几个相互关联的核心概念：
仁
仁是孔子思想的核心，《论语》中提到 109 次。它最初指亲属间的亲爱之情，孔子将其扩展为普遍的人道精神和道德完善的理想。
「仁者爱人」（《颜渊》）简洁地表达了仁的本质。仁者是充满慈爱之心、满怀爱意的人。
仁的实践包括自律、尊重他人和推己及人：「己所不欲，勿施于人」（《颜渊》）—— 自己不愿意的，不要施加给别人。
仁不是抽象理念，而是具体行为中体现的品质：「仁远乎哉？我欲仁，斯仁至矣」（《述而》；译文：仁难道离我们很远吗？我想达到仁，仁就到了），强调道德实践的即时性和可得性，以及人进行道德修养的主观能动性。仁是人天生的本性，因此为仁就全靠自身的努力，不能依靠外界的力量。
礼
礼指规范社会行为的仪式和习俗。孔子强调礼不仅是外在形式，更是内在道德的表达：「人而不仁，如礼何？人而不仁，如乐何？」（《八佾》；译文：人的内心不追求仁，表面上遵守礼又有什么用呢？人的内心不追求仁，表面上演奏乐又有什么用呢？）儒家推崇礼乐，礼和乐是形式，其本质是为了提升人性，使上位者能爱民如子，百姓能知耻且格（指人有知耻之心，则能自我检点而归于正道）。
礼在孔子思想中有双重功能：维护社会秩序和培养个人品格。适当的礼仪表达了对他人的尊重，也帮助个人培养内在美德。礼的核心是「敬」，即真诚尊重之心。
义
义是道德正当性的标准，指行为符合道德原则而非追求私利。「君子喻于义，小人喻于利」（《里仁》）表明义与利的对立。然而，孔子并非完全否定利益追求，而是强调义应指导利：「富与贵，是人之所欲也；不以其道得之，不处也」（《里仁》；译文：财富与地位，是每个人都渴望的，但如果不用正当方法获得，君子绝不接受）。
智
智指道德智慧和判断力，而非纯粹的知识积累。孔子重视学习，但认为学习目的是道德实践：「学而不思则罔，思而不学则殆」（《为政》；译文：只学习不思考会陷入迷茫，只空想不学习会走向危险）。
真正的智慧包括认识自己的限度：「知之为知之，不知为不知，是知也」（《为政》；译文：知道就说知道，不知道就承认不知道，这才是真智慧）。
信
信是诚实和信用，社会和谐的基础：「人而无信，不知其可也」（《为政》；译文：如果一个人没有信用，真不知道他如何立身处世）。信任是社会关系和政治统治的基础：「民无信不立」（《颜渊》；译文：失去民众的信任，国家就无法存续）。
君子理想
君子是孔子提出的理想人格，原指贵族身份，被重新定义为道德卓越者。君子德行包括：
自省：「君子求诸己，小人求诸人」（《卫灵公》；译文：君子遇事反思自己，小人遇事指责他人）
中庸：「君子和而不同，小人同而不和」（《子路》；译文：君子在差异中寻求和谐，小人在表面统一中制造矛盾）
执着于道德：「君子喻于义，小人喻于利」（《里仁》；译文：君子的思维围绕道义展开，小人的思维局限在利益算计）
勇于改错：「过而不改，是谓过矣」（《卫灵公》；译文：有了过错却不改正，这才是真正的错误）
君子概念是孔子思想中重要的创新，将社会地位与道德成就分离，为中国建立了基于德行而非血统的精英理想。
 6.2.4. 政治与社会思想
孔子的政治思想基于「为政以德」原则：「为政以德，譬如北辰，居其所而众星共之」（《为政》；译文：用德行治理国家，就像北极星稳居中心，群星自然环绕）。他强调统治者的道德榜样作用超过法律强制：「道之以政，齐之以刑，民免而无耻；道之以德，齐之以礼，有耻且格」（《为政》；译文：用政令引导、刑罚约束，百姓只会逃避惩罚而无廉耻；用德行感化、礼教规范，百姓会有羞耻心且自觉守规）。
孔子提倡「正名」，即社会角色与实际行为相符：「君君，臣臣，父父，子子」（《颜渊》；译文：君王守君道，臣子尽臣责，父亲担父职，儿子行子孝）。这反映了他对社会秩序的关注和对个人责任的强调。
他的理想政治是大同社会：「大道之行也，天下为公」（《礼记・礼运》，虽非出自《论语》，但能够反映出孔子思想；译文：理想社会运行时，天下资源属于全体民众）。然而，他认识到这需要循序渐进的变革，而非革命，重视传统作为社会稳定的基础：「温故而知新，可以为师矣」（《为政》；译文：在传统中开创新知，方能成为时代的引领者）。
 6.2.5. 教育思想
作为中国第一位专业教育家，孔子的教育观对中国产生深远影响：
因材施教：「有教无类」，不分贵贱皆可教育
启发式教学：「不愤不启，不悱不发」（《述而》；译文：不到学生冥思苦想仍不通时，不去点拨；不到他想说却说不清时，不去引导）
理论与实践结合：「学而时习之，不亦说乎」（《学而》；译文：学习知识并能适时实践，岂不令人愉悦）
终身学习：「吾十有五而志于学，三十而立，四十而不惑，五十而知天命，六十而耳顺，七十而从心所欲，不逾矩」（《为政》）
《论语》记录孔子教学方法灵活多样，针对不同学生提出不同要求。他强调学习古代经典，同时也重视实践和反思：「学而不思则罔，思而不学则殆」（《为政》）。
 6.2.6. 历史影响与现代意义
《论语》对中国和东亚文化的影响难以估量。它塑造了中国知识分子的价值观，影响了政治制度、社会规范和家庭关系。儒家思想通过科举制度成为官方意识形态，成为统治阶级的合法性基础。
《论语》也影响了西方。17 世纪传入欧洲后，伏尔泰、康德等启蒙思想家对孔子的道德哲学表示赞赏。莱布尼茨认为中国文明可以补充欧洲文化。
20 世纪，《论语》经历了从被激烈批判到重新评价的过程。当代学者指出儒家思想中的普世价值，如仁爱、和谐、责任，对现代社会仍有启示。儒家强调和谐与平衡的思想，对处理全球化带来的文化冲突提供了另一种视角。
现代解读强调《论语》中的人文主义精神和批判精神，而非教条。儒家思想的现代转化可见于新加坡、韩国和日本的发展模式，展示了传统价值如何与现代化协调发展。
 6.3. 《道德经》
 6.3.1. 作者与成书
《道德经》，又称《老子》，传统上认为是春秋末期的老子（李耳，约公元前 571-471 年）所著。全书约 5000 字，分为道经（前 37 章）和德经（后 44 章）两部分。「道德」在这里不是现代伦理学意义，而是指宇宙本体（道）及其在人世的体现（德）。
老子的历史真实性一直存在争议。据《史记》记载，他是周朝守藏室的官员，与孔子同时代或稍早，晚年西行，应函谷关令尹喜之请写下此书。但现代学者对此存疑，有人认为《道德经》可能是战国时期（公元前 475-221 年）道家思想的集体结晶，而非单一作者所作。
最早的《道德经》文本来自 1973 年长沙马王堆汉墓出土的帛书，约公元前 200 年。1993 年，荆门郭店楚墓出土的竹简进一步推前了文本历史，约公元前 300 年。这些考古发现证实《道德经》至少在公元前 3 世纪末已成形。
 6.3.2. 核心思想
道
道是《道德经》最核心的概念，有多层含义：
宇宙本体：「有物混成，先天地生…… 可以为天下母」（第 25 章）
自然规律：「道法自然」（第 25 章）
无为原则：「道常无为而无不为」（第 37 章）
道具有矛盾特性：「道可道，非常道；名可名，非常名」（第 1 章），它超越语言和概念，只能通过悖论暗示：「玄之又玄，众妙之门」（第 1 章）。
道的本质是「无」和「空」：「天下万物生于有，有生于无」（第 40 章）。这种「无」不是虚无，而是充满潜在性的空白，如：「埏埴以为器，当其无，有器之用」（第 11 章）。
德
德是道在个体中的体现和实践。它不是外加的道德规范，而是顺应道的自然品质：「上德不德，是以有德；下德不失德，是以无德」（第 38 章）。真正的德是不刻意追求美德的结果，而是自然流露。
无为
无为是道家核心行动原则，不是绝对不行动，而是不做违背自然的强制行为：「为无为，则无不治」（第 3 章）。
无为的统治是顺应事物自身规律：「太上，下知有之；其次，亲而誉之…… 功成事遂，百姓皆谓：『我自然』」（第 17 章）。理想统治者工作不被察觉，让民众感到一切自然发生。
返朴归真
《道德经》批评文明的复杂性和人为规范：「绝圣弃智，民利百倍；绝仁弃义，民复孝慈；绝巧弃利，盗贼无有」（第 19 章）。它主张返回简朴自然状态：「见素抱朴，少私寡欲」（第 19 章）。
理想社会是「小国寡民」（第 80 章），人们安于简单生活，不追求复杂知识和远程交往：「甘其食，美其服，安其居，乐其俗」（第 80 章）。
辩证思维
《道德经》展现了独特的辩证思维，强调对立面相互依存：「有无相生，难易相成，长短相形，高下相倾」（第 2 章）。它认为事物会向反面转化：「祸兮福之所倚，福兮祸之所伏」（第 58 章）。
这种思维导致「反者道之动」原则，即事物发展趋向其反面：「弱者道之用」（第 40 章），「曲则全，枉则直，洼则盈，敝则新，少则得，多则惑」（第 22 章）。
 6.3.3. 政治思想
《道德经》的政治思想可概括为「无为而治」，认为最好的统治是最少的干预：「故圣人云：我无为，而民自化；我好静，而民自正；我无事，而民自富；我无欲，而民自朴」（第 57 章）。
它批评儒家的积极政治理念，认为道德教化和礼制只会使社会更加混乱：「天下多忌讳，而民弥贫；民多利器，国家滋昏；人多伎巧，奇物滋起；法令滋彰，盗贼多有」（第 57 章）。
《道德经》推崇柔弱胜刚强的治国策略：「天下莫柔弱于水，而攻坚强者莫之能胜」（第 78 章）。理想统治者应保持低调：「圣人不积，既以为人，己愈有；既以与人，己愈多」（第 81 章）。
 6.3.4. 与儒家的关系
道家与儒家代表了中国思想的两大主要取向，它们的关系既对立又互补：
对立方面：
儒家强调社会参与，道家主张超脱尘世
儒家重视礼仪规范，道家推崇自然本性
儒家相信教育改良，道家怀疑知识价值
儒家推崇道德完善，道家追求自然和谐
互补方面：
都关注社会和谐，只是方法不同
都强调自我修养，儒家外向，道家内向
都批评暴力与战争
在中国历史上常互相融合，儒家入世，道家出世
中国文化传统常被概括为「外儒内道」，表明这两种思想在实践中的互补性。文人常在政治生涯（儒）与山水隐居（道）间转换，体现中国知识分子的双重理想。
 6.3.5. 道家哲学的演变
《道德经》奠定了道家哲学基础，其思想在后世有多种发展方向：
庄子（约公元前 369-286 年）将老子的自然主义发展为一种精神自由哲学，强调超越社会规范，《庄子》的寓言如《逍遥游》展现了道家精神自由的理想。
黄老道家（汉初）将道家思想与法家统治术结合，成为汉初的统治思想，强调顺应自然规律的统治艺术。
宗教道教（东汉末年）将道家哲学转化为追求长生不老的宗教体系，《太平经》和《周易参同契》等著作结合了道家思想与方士传统。
魏晋玄学（3-6 世纪）融合道家、儒家和佛教，发展出「贵无」和「崇有」两派，代表人物如王弼、郭象等，对老庄进行本体论诠释。
新道家（宋明理学）将道家思想融入儒家框架，如周敦颐《太极图说》结合了儒道宇宙观。
这种多元发展表明《道德经》具有丰富的解释空间和深刻的启发性，使其成为中国思想史上最有生命力的经典之一。
 6.3.6. 现代意义与全球影响
《道德经》是被翻译最广的中国古典文献，在西方引起广泛关注，影响了从物理学到生态环保的多个领域：
现代物理学：量子物理学家如卡普拉（Fritjof Capra）在《道的物理学》中指出道家宇宙观与量子理论的相似性，如互补原理和整体性。
环境生态：道家的自然哲学启发了深层生态学，强调人与自然和谐共处，而非控制征服。
领导理论：无为而治的理念影响了现代组织管理，强调授权和创造性空间。
心理治疗：道家的接受与顺应思想影响了西方心理治疗，特别是接受与承诺疗法。
流行文化：从《星球大战》中的「原力」到各种冥想实践，道家思想渗透到西方流行文化的方方面面。
《道德经》对现代社会的主要启示包括：批判消费主义和物质主义，强调简朴生活；提供替代性发展模式，不以单纯速度和规模为目标；在技术至上时代重新思考人与自然的关系；在充满对立的世界中，提供一种超越二元思维的智慧。
 7. 早期基督教思想
 7.1. 圣奥古斯丁与《忏悔录》
 7.1.1. 作者生平与历史背景
圣奥古斯丁（Augustine of Hippo，354-430 年）是早期基督教最重要的神学家和哲学家之一，被称为拉丁教父中的巨擘。他出生于北非塔加斯特（今阿尔及利亚），父亲是异教徒，母亲莫尼卡则是虔诚的基督徒。
奥古斯丁的生涯正值罗马帝国转型的关键时期。君士坦丁大帝于 313 年颁布《米兰敕令》，使基督教从被迫害宗教转变为合法信仰，到奥古斯丁时代，基督教已成为帝国主导宗教。然而，帝国政治正日渐衰落，他去世前不久（410 年），罗马城被西哥特人洗劫，标志着西罗马帝国开始崩溃。
年轻时的奥古斯丁并非基督徒，而是沉迷于世俗享乐。他接受良好教育，成为修辞学教师，先后在迦太基、罗马和米兰任教。在米兰，他结识了安波罗修主教，并受到新柏拉图主义影响。经历长期精神挣扎后，在 387 年复活节前夕受洗，正式皈依基督教。
皈依后，他返回北非，创建修道院，过着禁欲生活。391 年，他在希波被祝圣为神父，396 年成为希波主教，直至去世。主教期间，他与多纳徒派、伯拉纠派等异端进行激烈辩论，著书立说，奠定了中世纪基督教神学的基础。
 7.1.2. 《忏悔录》的写作与结构
《忏悔录》（Confessiones）写于 397-400 年间，是西方文学中第一部真正意义上的自传，以祈祷形式向上帝倾诉。然而，它远非简单的生平叙述，而是深刻的神学反思和哲学探索。全书共 13 卷：
卷一至九：自传部分，记述奥古斯丁从童年到皈依的人生历程，特别强调他的精神探索与挣扎。
卷十：对当下自我的反思，探讨记忆本质。
卷十一至十三：对《创世记》的冥想与诠释，探讨时间、创造和三位一体等神学主题。
《忏悔录》的标题「confessiones」在拉丁文中有双重含义：既是「忏悔」（认罪），也是「赞美」（认信上帝的伟大）。这双重意义贯穿全书，使之既是对个人罪的坦承，也是对神恩典的颂扬。
 7.1.3. 自传叙事：从迷失到皈依
《忏悔录》开篇即点明全书主题：「我们的心若不安息在你怀中，便不得安宁。」这揭示了奥古斯丁对灵魂不安与对神渴望的核心体验。
奥古斯丁坦率描述自己的早年生活，包括犯下的各种罪行。他讲述自己如何偷窃梨子，不是因为饥饿，而是「为恶而恶」；他承认自己沉迷情欲，曾祈求「主啊，请赐我贞洁和节制，但不要太快」；他回忆自己追求名利与虚荣，以及对戏剧和竞技场娱乐的迷恋。
他的精神探索经历了多个阶段：
青年时期接触西塞罗的《荷尔顿修斯》，激发对智慧的热爱
加入摩尼教九年，被其二元论所吸引
深入研究占星术，后在学术和逻辑上发现其谬误
接触学院派怀疑主义，对一切确定性产生怀疑
在米兰被新柏拉图主义吸引，特别是普罗提诺的著作
关键转折发生在米兰花园。在痛苦挣扎中，奥古斯丁听到一个声音说「拿起来读」，随手翻开保罗的《罗马书》，读到「不可荒宴醉酒，不可好色邪荡，不可争竞嫉妒；总要披戴主耶稣基督，不要为肉体安排，去放纵私欲」（罗马书 13:13-14）。这段经文使他心中茅塞顿开，决定皈依基督教。
皈依后不久，他的母亲莫尼卡去世。书中记录了他与母亲在奥斯提亚的一次神秘体验，两人在谈话中共同上升，短暂感受到永恒的临在，这是书中最动人的段落之一。
 7.1.4. 哲学与神学思想
《忏悔录》不仅是自传，也是深刻的哲学和神学著作，探讨了多个重要主题：
罪恶与意志
奥古斯丁对罪恶本质的分析极为深刻。他认为罪不是实体，而是对善的缺失或扭曲：「我寻找恶是什么，发现它不是实体，而是意志从最高实体转向低级事物的扭曲。」
他提出「分裂的意志」概念，描述内心挣扎：「意志命令自己，而自己却不服从。」这种自我分裂反映了原罪对人类自由的损害。在奥古斯丁看来，真正的自由不是为所欲为，而是摆脱罪的束缚，做出正确选择的能力。
记忆与时间
《忏悔录》第十卷对记忆本质进行了开创性探讨。奥古斯丁将记忆描述为「广阔的宫殿」，包含过去经验、学习知识，甚至某种对神的内在认识。他提出记忆不仅储存感官经验，还包含非感官性概念，如数学真理。
第十一卷著名的时间分析至今仍有哲学价值。他质问：「什么是时间？如果没人问我，我知道；如果要我解释，我不知道。」他分析过去、现在和未来，认为只有「现在」真实存在，而过去是「不再」的现在，未来是「尚未」的现在。现在本身也是瞬息即逝的。这种分析导向对永恒的思考，永恒不是无尽时间，而是时间的彻底超越，在永恒中，一切都是「同时」的现在。
上帝与创造
奥古斯丁反对摩尼教的二元论，强调上帝创造的一切本质上都是善的：「你看你所创造的一切，都甚美好。」邪恶不是独立实体，而是善的缺失或扭曲。
在诠释《创世记》时，他探讨上帝如何「从无中创造」，以及时间与创造的关系。他认为上帝创造了时间本身，因此在创造之前谈论「时间」是没有意义的。这些思考展现了奥古斯丁将希腊哲学概念与基督教教义融合的才能。
恩典与预定论
《忏悔录》强调人类救赎完全依靠上帝的恩典。奥古斯丁认为，由于原罪，人类无法凭自己的力量选择善。即使信仰本身也是上帝的恩赐：「信仰不是出于我们自己，乃是上帝所赐的礼物。」
这导致他后来发展出预定论学说，认为上帝预先选择了得救者，这些思想对改教家马丁・路德和约翰・加尔文产生深远影响。
 7.1.5. 文学特色与修辞艺术
《忏悔录》不仅是哲学和神学著作，也是杰出的文学作品，展现了奥古斯丁作为修辞学教师的才华：
祈祷式叙述
全书直接向上帝倾诉，创造了亲密对话的效果：「你创造了我们归向你，我们的心若不安息在你怀中，便不得安宁。」这种祈祷体强调了上帝作为隐形听众的临在，使读者成为这场灵魂对话的旁观者。
心理分析的深度
奥古斯丁对自己内心状态的分析惊人地现代。他描述记忆、情感、欲望和意志的复杂互动，展现了深刻的自我意识：「我已成为自己的内心荒地。」他对青少年心理的描述，如偷梨事件中对群体压力的分析，显示了对人性的敏锐洞察。
生动的意象与比喻
书中充满鲜活意象，如将上帝描述为「我灵魂的甘露」，将自己比作「浪子远离你的面容」。特别是对内心挣扎的描述常用生动比喻：「我旧日罪恶的习惯依然握住我，低声说：『你要抛弃我们吗？』」
语言的音乐性
拉丁文原文具有强烈的节奏感和韵律美，即使在翻译中也能感受到语言的起伏与张力。奥古斯丁善用排比、对照、顶真等修辞手法，创造出既激情又精确的语言风格。
 7.1.6. 历史影响与现代意义
《忏悔录》对西方文学、哲学和神学产生了深远影响：
自传文学的开创
作为西方第一部成熟自传，《忏悔录》确立了内省自传的传统，影响了从卢梭的《忏悔录》到托尔斯泰的《忏悔》等后世经典。它开创了将个人经历与思想探索结合的文体。
神学影响
奥古斯丁的神学思想塑造了整个中世纪基督教。他关于原罪、神恩、预定论的学说成为天主教正统教义，也深刻影响了新教神学。《忏悔录》对信仰经验的描述为后世神秘主义传统提供了模板。
哲学贡献
他对时间、记忆、意识等主题的探讨影响了胡塞尔、海德格尔等现象学家。他的内省方法被视为现代意识哲学的先驱。维特根斯坦曾说：「如果把哲学比作城市，奥古斯丁是先民们留下的古城，而我们则生活在郊外的新区。」
心理学启示
弗洛伊德承认奥古斯丁对潜意识的洞察先于精神分析学。荣格则从奥古斯丁的自我探索中汲取灵感，发展个体化理论。现代心理治疗中的自传式叙事也可追溯到《忏悔录》的传统。
现代意义
在当代多元文化语境下，《忏悔录》仍具有重要价值。它对内心挣扎的真实描述，对生命意义的深刻探索，对善恶问题的不懈思考，超越了特定宗教框架，成为人类共同的精神遗产。
在个人身份日益碎片化的现代社会，《忏悔录》提供了一种整合自我的模式，表明个人叙事如何能赋予生命意义和连贯性。它证明，严肃的自我反思不仅具有心理价值，也有深刻的精神和哲学意义。
与现代许多自传不同，《忏悔录》不是自我肯定或自我辩护，而是谦卑的自我审视，承认人类的限度和对超越力量的需要。这种视角在今天的自我中心文化中尤为珍贵，提醒我们自我实现的真正意义可能恰恰在于超越自我。


React + NestJS 购物平台练习【5】用户登录功能
2025-02-12T05:00:00.000Z
在构建电商平台的过程中，用户登录是一个不可或缺的核心功能。
本文将详细介绍如何在 React 前端实现登录表单组件，并结合 NestJS 后端完成完整的用户认证流程，包括 JWT 认证、记住我功能以及登录状态持久化等关键特性。
 1. 小改动
 1.1. 改变量 / 字段名字
将 React 项目的 src/stores/user/types.ts 中的 LoginCredentials 的 email 修改为 username：
export interface LoginCredentials {   username: string;   password: string; }
 1.2. 修改依赖数组
在 src/pages/VerifyEmail.tsx 中的 useEffect 的依赖数组内加一个 location.search：
useEffect(() => {  const searchParams = new URLSearchParams(location.search);  const token = searchParams.get('token');  const currentToken = useUserStore.getState().verificationToken;  if (token && !verificationInProgress && !emailVerified && token !== currentToken) {    handleVerification(token).then(r => {      if (r.success && 'message' in r) console.log('邮箱验证成功：', r.message);    });  }}, [handleVerification, verificationInProgress, emailVerified, location.search]);
 1.3. 新建 email-verification.interface.ts
将原本放在 users.service.ts 内的这段内容单独放在一个文件里：
export enum EmailVerificationError {  TOKEN_INVALID = 'TOKEN_INVALID',  TOKEN_EXPIRED = 'TOKEN_EXPIRED',  ALREADY_VERIFIED = 'ALREADY_VERIFIED'}export interface VerificationResponse {  success: boolean;  message: string;  error?: EmailVerificationError;  userId?: string;}
 1.4. 统一查找用户的方法
原先我们只写了靠 ID 来查找用户的方法，如果要进行扩展的话，一个方法一个方法写太麻烦了，干脆写一个更灵活的查找方法、支持通过任何唯一字段查找用户：
async findUser(criteria: UserSearchCriteria) {  this.logger.debug(`开始查找用户，条件：${JSON.stringify(criteria)}`);  const whereClause = Object.entries(criteria)    .filter(([, value]) => value !== undefined)    .reduce((acc, [key, value]) => ({ ...acc, [key]: value }), {});  if (Object.keys(whereClause).length === 0) {    this.logger.warn('查询条件为空');    throw new BadRequestException('至少需要一个查询条件');  }  const user = await this.usersRepository.findOne({    where: whereClause  });  if (!user) {    const [[key, value]] = Object.entries(whereClause);    const fieldMap = {      id: 'ID',      username: '用户名',      email: '邮箱',      verificationToken: '验证令牌'    };    const errorMessage = `未找到${fieldMap[key]}为 ${value} 的用户`;    this.logger.warn(`查找用户失败：${errorMessage}`);    throw new NotFoundException(errorMessage);  }  this.logger.debug(`用户查找成功：${user.id}，用户详细信息：${JSON.stringify(user)}`);  return user;}
export type UserSearchCriteria = Partial<{  id: string;  username: string;  email: string;  verificationToken: string;}>;
UsersController 的查找用户 API 也可以修改成类似的样子：
@ApiOperation({ summary: '根据不同字段查找用户' })@ApiParam({ name: 'field', enum: ['id', 'username', 'email'], description: '查找字段' })@ApiParam({ name: 'value', description: '查找值' })@ApiResponse({ status: HttpStatus.OK, description: '获取用户信息成功', type: Users })@HttpCode(HttpStatus.OK)@Get(':field/:value')async findByField(@Param('field') field: 'id' | 'username' | 'email', @Param('value') value: string): Promise {  const validFields = ['id', 'username', 'email'];  if (!validFields.includes(field)) {    throw new BadRequestException(`不支持通过 ${field} 字段查找用户`);  }  return this.usersService.findUser({ [field]: value });}
 1.5. JWT Payload 修复
// 过去的接口export interface JWTPayload {  sub: number;  // 错误的类型  username: string;  email: string;  role: string;  iat?: number;  exp?: number;  aud?: string;  iss?: string;}// 现在的接口export interface JWTPayload {  sub: string;  // 修正为 string 类型，因为使用 UUID  username: string;  email: string;  role: string;  verified: boolean;  // 新增字段，用于邮箱验证状态  iat?: number;  exp?: number;  aud?: string;  iss?: string;}
 1.6. 布局组件优化
为了更好地适应不同的页面布局需求，我们需要增加主布局组件的灵活性。原有的 MainLayout 组件只支持路由渲染：
const MainLayout = () => {  return (                            {/* TODO: 导航内容 */}        
      
                                
      
    
  );};
我们对其进行了改造，使其同时支持直接的子组件渲染：
import React from 'react';import { Outlet } from 'react-router-dom';interface MainLayoutProps {  children?: React.ReactNode;}const MainLayout = ({ children }: MainLayoutProps) => {  return (                            {/* TODO: 导航内容 */}        
      
                        { children ? children :  }        
      
    
  );};export default MainLayout;
 2. 实现登录表单组件
在电商平台中，我们需要一个用户友好的登录界面，让用户能够：
输入用户名和密码进行登录
在输入过程中获得适当的表单验证反馈
看到登录状态的加载提示
收到登陆成功或者失败的明确提示
让我们先在 src/pages 目录下创建 Login.tsx：
 import React from 'react'; import { useFormik } from 'formik'; import * as Yup from 'yup'; import { useNavigate } from 'react-router-dom'; import { useUserStore } from '../stores'; import AuthLayout from '../layouts/AuthLayout'; import logo from '../assets/ShoppingNest.png'; const Login = () => {   const navigate = useNavigate();   const login = useUserStore(state => state.login);   const isLoading = useUserStore(state => state.isLoading);   const error = useUserStore(state => state.error);   return (    // ...  )}export default Login;
使用 Formik 管理表单状态和处理提交：
 const formik = useFormik({   initialValues: {     username: '',     password: ''   },   validationSchema,   onSubmit: async (values) => {     try {       const { username, password } = values;       await login({ username, password });       navigate('/', {         state: {           message: '登陆成功！'         }       })     } catch (error) {       console.error('登录失败：', error);     }   } }); 
使用 Yup 进行表单验证，确保用户名和密码不为空：
 const validationSchema = Yup.object().shape({  username: Yup.string().required('请输入用户名！'),  password: Yup.string().required('请输入密码！')});
以下是页面的基本结构：
 return (                    登录用户     
     {error && (                {error}       
     )}                                用户名                           {formik.touched.username && formik.errors.username && (           {formik.errors.username}
         )}       
                           密码                           {formik.touched.password && formik.errors.password && (           {formik.errors.password}
         )}       
            
    ) 
在 src/router.tsx 中添加 /login 路由：
 import Login from './pages/Login';const router = createBrowserRouter([   {     path: '/login',     element:    }]); 
 3. 配置 JWT 认证
在实现用户登录功能时，我们需要一个安全可靠的身份验证机制，以确保用户身份的真实性并保护系统的安全。
JWT（JSON Web Token）是一个开放标准，它提供了一种紧凑且自包含的方式，在各方之间安全地传输信息。
通过 JWT，我们可以生成安全的访问令牌、验证用户的身份和权限、保护需要认证的 API 端点，并在服务端对令牌的有效性进行校验。
要实现 JWT 认证机制，我们需要从多个方面入手：
配置认证模块、JWT 模块的签名密钥以及相关选项
集成用户模块，以便进行用户身份验证
实现认证服务，该服务需要负责验证用户凭据、生成 JWT 令牌、处理令牌刷新以及检查令牌的有效性，确保认证流程的完整性和安全性
创建一个认证控制器，专门处理用户的登录请求，并返回认证结果和 JWT 令牌，确保前端能够正确接收和使用身份验证信息
实现 JWT 策略和守卫：从请求中提取 JWT 令牌，并验证其有效性，以此来保护系统中需要认证的路由，确保只有经过身份经验的用户才能访问受保护的资源
 3.1. 安装依赖
yarn add @nestjs/jwt @nestjs/passport passport passport-jwtyarn add -D @types/passport-jwt
 3.2. 认证模块
在 src 目录下创建 auth 目录，并创建 auth.module.ts：
import { Module } from '@nestjs/common';import { PassportModule } from '@nestjs/passport';import { JwtModule } from '@nestjs/jwt';import { ConfigService } from '@nestjs/config';import { AuthController } from './auth.controller';import { AuthService } from './auth.service';import { JwtStrategy } from './jwt.strategy';import { UsersModule } from '../users/users.module';@Module({  imports: [    PassportModule.register({      defaultStrategy: 'jwt'    }),    JwtModule.registerAsync({      inject: [ConfigService],      useFactory: async (configService: ConfigService) => ({        secret: configService.get('JWT_SECRET'),        signOptions: {          audience: configService.get('JWT_TOKEN_AUDIENCE'),          issuer: configService.get('JWT_TOKEN_ISSUER'),          expiresIn: configService.get('JWT_ACCESS_TOKEN_TTL')        }      })    }),    UsersModule  ],  controllers: [AuthController],  providers: [AuthService, JwtStrategy],  exports: [AuthService]})export class AuthModule {}
 3.3. 用户验证和令牌生成
创建 auth.service.ts：
import { Injectable, UnauthorizedException } from '@nestjs/common';import { JwtService } from '@nestjs/jwt';import { ConfigService } from '@nestjs/config';import * as bcrypt from 'bcrypt';import { UsersService } from '../users/users.service';import { JWTPayload } from './interfaces/jwt-payload.interface';@Injectable()export class AuthService {  constructor(    private jwtService: JwtService,    private usersService: UsersService,    private configService: ConfigService  ) {}  // ...}
验证用户：
 async validateUser(username: string, password: string) {  const user = await this.usersService.findUser({ username: username });  if (!user) {    throw new UnauthorizedException('用户名或密码错误');  }  if (!user.verified) {    throw new UnauthorizedException('请先验证邮箱后再登录');  }  const isPasswordValid = await bcrypt.compare(password, user.password);  if (!isPasswordValid) {    throw new UnauthorizedException('用户名或密码错误');  }  return user;}
用户登录：
 async login(user: any) {  const payload: JWTPayload = {    sub: user.sub,    username: user.username,    email: user.email,    role: user.role  };
首先构建 JWT 载荷。
JWT 基本上由三个部分组成，使用 . 分割：
头.载荷.签名
头包含了令牌类型和使用的签名算法：
 {  "alg": "HS256",  // 使用的算法  "typ": "JWT"}
载荷包含了我们存储的实际数据：
 {  "sub": "1234567890",  // 用户 ID  "username": "john_doe",  // 用户名  "email": "john@doe.com",  // 邮箱  "role": "user",  // 角色  "iat": 1516239022,       // 签发时间  "exp": 1516242622        // 过期时间}
签名则使用密钥、对头和载荷进行签名：
 HMACSHA256(  base64UrlEncode(header) + "." +  base64UrlEncode(payload),  secret  )
 const accessToken = this.jwtService.sign(payload, {  // 令牌接收方  audience: this.configService.get('JWT_TOKEN_AUDIENCE'),  // 令牌发行方  issuer: this.configService.get('JWT_TOKEN_ISSUER'),  // 令牌有效期  expiresIn: this.configService.get('JWT_ACCESS_TOKEN_TTL'),});
使用 JwtService 生成签名令牌。
   return {    access_token: accessToken,    token_type: 'Bearer',    expires_in: this.configService.get('JWT_ACCESS_TOKEN_TTL'),    user: {      id: user.id,      username: user.username,      email: user.email,      role: user.role,      verified: user.verified    }  };}
这里说一下令牌类型 Bearer，它是 OAuth 2.0 的标准组成部分。
在令牌过期前更新令牌：
 async refreshToken(user: any) {  const payload: JWTPayload = {    sub: user.id,    username: user.username,    email: user.email,    role: user.role  };  return {    access_token: this.jwtService.sign(payload)  };}
当现有访问令牌即将过期时，服务器会生成一个新的访问令牌。
使用与原始登录相同的用户信息构建新的载荷，这样用户就不需要重新登陆，可以无缝继续使用系统。
验证令牌：
 verifyToken(token: string) {  try {    return this.jwtService.verify(token);  } catch (error) {    throw new UnauthorizedException('无效的令牌，错误：', error);  }}
这个方法负责验证传入的 JWT 令牌的有效性。
JwtService.verify() 方法会检查令牌是否：
签名有效（未被篡改）
未过期
是由我们的系统签发的
在 auth 目录下创建 interfaces/jwt-payload.interface.ts 文件，定义 JWT 载荷的 TypeScript 接口：
export interface JWTPayload {  sub: number;  username: string;  email: string;  role: string;  iat?: number;  exp?: number;  aud?: string;  iss?: string;}
 3.4. 认证控制器
我们先来写一下登录所需要的 DTO。
定义登录请求的数据结构：
 import { ApiProperty } from '@nestjs/swagger';import { IsNotEmpty, IsString, MinLength } from 'class-validator';export class LoginDto {  @ApiProperty({ example: 'johndoe', description: '用户名' })  @IsString()  @IsNotEmpty({ message: '用户名不能为空' })  username: string;  @ApiProperty({ example: 'password123', description: '密码' })  @IsString()  @IsNotEmpty({ message: '密码不能为空' })  @MinLength(6, { message: '密码长度不能小于6位' })  password: string;}
登录响应 DTO：
 import { ApiProperty } from '@nestjs/swagger';export class LoginResponseDto {  @ApiProperty({ description: '访问令牌' })  access_token: string;  @ApiProperty({ description: '令牌类型', example: 'Bearer' })  token_type: string;  @ApiProperty({ description: '过期时间（秒）', example: 3600 })  expires_in: number;  @ApiProperty({    description: '用户信息',    example: {      id: '1',      username: 'johndoe',      email: 'john@example.com',      role: 'user',      verified: true    }  })  user: {    id: string;    username: string;    email: string;    role: string;    verified: boolean;  };}
创建 auth.controller.ts：
import { Controller, Post, Body, HttpCode, HttpStatus, UnauthorizedException } from '@nestjs/common';import { ApiTags, ApiOperation, ApiResponse } from '@nestjs/swagger';import { AuthService } from './auth.service';import { LoginDto } from './dto/login.dto';import { LoginResponseDto } from './dto/login-response.dto';import winstonLogger from '../loggers/winston.logger';@ApiTags('认证')@Controller('auth')export class AuthController {  private readonly logger = winstonLogger;  constructor(private readonly authService: AuthService) {}  @ApiOperation({ summary: '用户登录' })  @ApiResponse({    status: HttpStatus.OK,    description: '登录成功',    type: LoginResponseDto  })  @ApiResponse({    status: HttpStatus.UNAUTHORIZED,    description: '登录失败'  })  @HttpCode(HttpStatus.OK)  @Post('login')  async login(@Body() loginDto: LoginDto): Promise {    try {      const user = await this.authService.validateUser(loginDto.username, loginDto.password);      this.logger.debug(`用户 ${loginDto.username} 验证通过，正在生成令牌`);      const loginResult = await this.authService.login(user);      this.logger.info(`用户 ${loginDto.username} 登录成功`);      return loginResult;    } catch (error) {      this.logger.error(`用户 ${loginDto.username} 登录失败: ${error.message}`);      throw error;    }  }}
 3.5. 策略实现
AuthService.validateUser() 方法仅是用于登录时的用户验证，以及生成初始的 JWT 令牌。
那后续请求该由谁来验证呢？
可以想象成有这么一个商场。
你在前台登记（登录），工作人员会验证你的身份（AuthService.validateUser()），验证成功后给了你一个特殊的通行证（JWT 令牌）。
你在商场里遛弯，发现有一个 VIP 区域（访问受保护的 API），门口站一保安。你说你想进去，保安说别急先看看你的通行证（JWT 令牌）。
保安需要看到的是：
这个通行证是不是商场发的（JWT 签名验证）
通行证有没有过期（JWT 过期检查）
你的会员资格是否还有效（接下来要写的方法）
JWT 策略实现就是这个保安。
创建 jwt.strategy.ts：
import { Injectable, UnauthorizedException } from '@nestjs/common';import { PassportStrategy } from '@nestjs/passport';import { ConfigService } from '@nestjs/config';import { Strategy, ExtractJwt } from 'passport-jwt';import { UsersService } from '../users/users.service';@Injectable()export class JwtStrategy extends PassportStrategy(Strategy) {  constructor(    private configService: ConfigService,    private usersService: UsersService  ) {    super({      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),      ignoreExpiration: false,      secretOrKey: configService.get('JWT_SECRET'),      audience: configService.get('JWT_TOKEN_AUDIENCE'),      issuer: configService.get('JWT_TOKEN_ISSUER')    });  }
检查用户是否还是「有效会员」：
  async validate(payload: any) {    const user = await this.usersService.findUser({ id: payload.sub });    if (!user) {      throw new UnauthorizedException('用户不存在');    }    if (!user.verified) {      throw new UnauthorizedException('用户未验证');    }    return {      id: user.id,      username: user.username,      email: user.email,      role: user.role    };  }}
 3.6. JWT 守卫
先前的商场例子里，提到了「受保护的 API」。
那么要如何创建这么个「VIP 区域」呢？我们就需要用到 JWT 守卫。
创建 jwt-auth.guard.ts：
@Injectable()export class JwtAuthGuard extends AuthGuard('jwt') {  handleRequest(error: any, user: any, info: any) {    if (error || !user) {      throw new UnauthorizedException('验证失败');    }    return user;  }}
守卫的工作流程：
收到请求时，检查 Authorization 头部是否包含 JWT 令牌
如果没有令牌或令牌无效，直接拦截请求并返回 401 错误
如果令牌有效，让请求通过并继续处理
使用方式也很简单：
@Controller('orders')export class OrdersController {  constructor(private ordersService: OrdersService) {}  // 无需登录即可访问的公开 API  // 例如获取热门商品  @Get('popular')  getPopularOrders() {    return this.ordersService.getPopularOrders();  }  // 需要登录才能访问的 API  // 例如用户的订单  @UseGuards(JwtAuthGuard)  @Get('my-orders')  getMyOrders(@CurrentUser() user: any) {    return this.ordersService.getOrdersByUserId(user.id);  }  // 用户下单  @UseGuards(JwtAuthGuard)  @Post('create')  createOrder(@CurrentUser() user: any, @Body() orderData: any) {    return this.ordersService.createOrder(user.id, orderData);  }}
也可以直接保护控制器的所有路由：
@UseGuards(JwtAuthGuard)  // 保护个人信息路由@Controller('profile')export class ProfileController {  @Get()  getProfile(@CurrentUser() user: any) {    return user;  }  @Put()  updateProfile(@CurrentUser() user: any, @Body() updateData: any) {    return this.profileService.update(user.id, updateData);  }}
 3.7. 用户装饰器
假设我们有一个购物车的 API，需要获取当前用户的购物车信息：
@Controller('cart')export class CartController {  constructor(private cartService: CartService) {}  @UseGuards(JwtAuthGuard)  @Get('my-cart')  async getMyCart(@CurrentUser() user: any) {    // user 对象包含了 JWT 令牌中的用户信息    return this.cartService.getCartByUserId(user.id);  }}
如果没有 CurrentUser 装饰器，我们需要：
@Get('my-cart')async getMyCart(@Request() req: any) {  const user = req.user;  // 从 request 对象中手动获取用户信息  return this.cartService.getCartByUserId(user.id);}
CurrentUser 装饰器的实现：
import { createParamDecorator, ExecutionContext } from '@nestjs/common';export const CurrentUser = createParamDecorator((data: unknown, ctx: ExecutionContext) => {  const request = ctx.switchToHttp().getRequest();  return request.user;});
它的好处在于：
简化代码：不需要手动从 request 中提取用户信息
类型安全：可以明确知道返回的是用户对象
可重用性：在任何需要当前用户信息的地方都可以使用
关注点分离：控制器方法只需要关心用户信息，不需要关心它是如何获取的
像是还可以有这样的使用场景：
@Controller('users')export class UsersController {  @UseGuards(JwtAuthGuard)  @Get('profile')  getProfile(@CurrentUser() user: any) {    return user;  // 直接返回用户信息  }}
 4. 添加记住我功能
在现代电商平台中，用户体验是至关重要的。用户希望能够快速、便捷地访问他们的账户，而不需要每次都重新输入用户名和密码。这就是「记住我」功能的用武之地。
通过「记住我」功能，用户可以选择在登录时保持一段时间的登录状态，即使关闭浏览器或重新打开应用，用户仍然可以自动登录，无需再次输入凭证。
 4.1. 技术方案设计
我们采用 RefreshToken + AccessToken 的双令牌认证方案：
AccessToken：短期令牌，用于访问 API
RefreshToken：长期令牌，用于刷新 AccessToken
这种方案的优势在于：
安全性高：AccessToken 短期有效，即使泄露风险也较小
用户体验好：RefreshToken 可以静默刷新 AccessToken，用户无感知
可控性强：可以随时注销 RefreshToken，确保账户安全
Mermaid render failed: Mermaid render timed out after 30s
 4.2. 环境配置
 4.2.1. 修改环境变量
首先需要在 .env 文件中添加新的配置项：
# JWT JWT_ACCESS_SECRET=access_secret JWT_REFRESH_SECRET=refresh_secret JWT_TOKEN_AUDIENCE=localhost:4000 JWT_TOKEN_ISSUER=localhost:4000 JWT_ACCESS_TOKEN_TTL=3600 JWT_REFRESH_TOKEN_TTL=604800
配置说明：
JWT_ACCESS_SECRET：访问令牌密钥
JWT_REFRESH_SECRET：刷新令牌密钥
JWT_ACCESS_TOKEN_TTL：访问令牌有效期（1 小时）
JWT_REFRESH_TOKEN_TTL：刷新令牌有效期（7 天）
 4.2.2. 更新配置验证
在 AppModule 中更新 ConfigModule 的配置验证：
@Module({  imports: [    ConfigModule.forRoot({      validationSchema: Joi.object({        // ... 其他配置项 ...                // JWT 配置        JWT_ACCESS_SECRET: Joi.string().required(),        JWT_REFRESH_SECRET: Joi.string().required(),        JWT_TOKEN_AUDIENCE: Joi.string().required(),        JWT_TOKEN_ISSUER: Joi.string().required(),        JWT_ACCESS_TOKEN_TTL: Joi.number().default(3600),        JWT_REFRESH_TOKEN_TTL: Joi.number().default(604800)      })    })  ]})
 4.2.3. 更新认证模块
在 AuthModule 中更新 JwtModule 的配置：
@Module({  imports: [    JwtModule.registerAsync({      inject: [ConfigService],      useFactory: async (configService: ConfigService) => ({        secret: configService.get('JWT_ACCESS_SECRET'),        signOptions: {          audience: configService.get('JWT_TOKEN_AUDIENCE'),          issuer: configService.get('JWT_TOKEN_ISSUER'),          expiresIn: configService.get('JWT_ACCESS_TOKEN_TTL')        }      })    })  ]})
 4.2.4. 更新 JWT 策略
修改 JwtStrategy 的配置：
@Injectable()export class JwtStrategy extends PassportStrategy(Strategy) {  constructor(private configService: ConfigService) {    super({      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),      ignoreExpiration: false,      secretOrKey: configService.get('JWT_ACCESS_SECRET'),      audience: configService.get('JWT_TOKEN_AUDIENCE'),      issuer: configService.get('JWT_TOKEN_ISSUER')    });  }}
 4.3. 令牌生成与签名实现
 4.3.1. JWT 配置抽离
为了更好地管理 JWT 相关的配置，我们首先创建了一个专门的配置文件 jwt.config.ts：
import { ConfigService } from '@nestjs/config';export const getJWTVerifyOptions = (configService: ConfigService) => ({  accessToken: {    secret: configService.get('JWT_ACCESS_SECRET'),    audience: configService.get('JWT_TOKEN_AUDIENCE'),    issuer: configService.get('JWT_TOKEN_ISSUER'),    expiresIn: configService.get('JWT_ACCESS_TOKEN_TTL')  },  refreshToken: {    secret: configService.get('JWT_REFRESH_SECRET'),    audience: configService.get('JWT_TOKEN_AUDIENCE'),    issuer: configService.get('JWT_TOKEN_ISSUER'),    expiresIn: configService.get('JWT_REFRESH_TOKEN_TTL')  }});
这样做的好处是：
集中管理 JWT 配置
方便在不同地方复用配置
确保配置的一致性
 4.3.2. 数据结构调整
在 Users 实体中添加 refreshToken 字段，用于存储刷新令牌：
 @Column({ nullable: true })refreshToken?: string;
在 LoginDto 中添加「记住我」选项：
 @ApiProperty({ example: false, required: false, description: '是否记住我' })@IsBoolean()@IsOptional()rememberMe?: boolean;
在 LoginResponseDto 中新增刷新令牌字段：
 @ApiProperty({ description: '刷新令牌' })refresh_token: string;
 4.3.3. 认证服务实现
在 AuthService 中，我们需要进行以下主要改动：
为了支持「记住我」功能，需要在用户登录时生成两种令牌：访问令牌（accessToken）和刷新令牌（refreshToken）。
将原有的令牌生成逻辑修改为：
 // 之前的代码const accessToken = this.jwtService.sign(payload, {  audience: this.configService.get('JWT_TOKEN_AUDIENCE'),  issuer: this.configService.get('JWT_TOKEN_ISSUER'),  expiresIn: this.configService.get('JWT_ACCESS_TOKEN_TTL')});// 修改后的代码const accessToken = this.jwtService.sign(payload);const refreshToken = this.jwtService.sign(  payload,   getJWTVerifyOptions(this.configService).refreshToken);
在登录响应中添加刷新令牌：
 // 之前的返回结果return {  access_token: accessToken,  token_type: 'Bearer',  expires_in: this.configService.get('JWT_ACCESS_TOKEN_TTL'),  user: { ... }};// 修改后的返回结果return {  access_token: accessToken,  refresh_token: refreshToken,  // 新增  token_type: 'Bearer',  expires_in: this.configService.get('JWT_ACCESS_TOKEN_TTL'),  user: { ... }};
新增令牌刷新功能，用于在访问令牌过期后获取新的访问令牌：
 async refresh(refreshToken: string) {  this.logger.debug(`刷新访问令牌`);  // 验证刷新令牌  const refreshPayload = this.jwtService.verify(    refreshToken,     getJWTVerifyOptions(this.configService).refreshToken  );    // 查找用户  const user = await this.usersService.findUser({ id: refreshPayload.sub });  if (!user) {    this.logger.warn(`刷新失败，未找到用户：${user.username}`);    throw new UnauthorizedException('用户不存在');  }  // 生成新的访问令牌  const newAccessToken = this.jwtService.sign(    {      sub: user.id,      username: user.username,      email: user.email,      role: user.role    },    getJWTVerifyOptions(this.configService).accessToken  );  this.logger.info(`已为用户刷新访问令牌：${user.username}`);  return {    access_token: newAccessToken,    token_type: 'Bearer',    expires_in: this.configService.get('JWT_REFRESH_TOKEN_TTL')  };}
添加登出功能，用于清除用户的刷新令牌：
 async logout(userId: string): Promise {  await this.usersService.update(userId, { refreshToken: null });}
 4.3.4. 控制器层改造
在 AuthController 中，我们需要添加新的接口来支持「记住我」功能：
@ApiOperation({ summary: '刷新访问令牌' })@UseGuards(JwtRefreshGuard)@HttpCode(HttpStatus.OK)@Post('refresh')async refresh(@Body() body: { refreshToken: string }) {  try {    return await this.authService.refresh(body.refreshToken);  } catch (error) {    this.logger.error(`刷新 Token 失败：${error.message}`);    throw new UnauthorizedException('刷新 Token 失败');  }}
同时添加获取当前用户信息和登出的接口：
@ApiOperation({ summary: '获取当前用户信息' })@HttpCode(HttpStatus.OK)@Get('me')async getCurrentUser(@CurrentUser() user: JWTPayload) {  return this.authService.getCurrentUser(user.sub);}@ApiOperation({ summary: '登出用户' })@HttpCode(HttpStatus.OK)@UseGuards(JwtAuthGuard)@Post('logout')async logout(@Req() req: Request) {  const user = req.user as JWTPayload;  await this.authService.logout(user.sub);  return { message: '已登出' };}
 4.3.5. 守卫机制完善
访问令牌守卫
原来的 JwtAuthGuard 实现存在几个问题：
没有直接验证 token 的有效性
没有正确处理 audience 和 issuer 的验证
看一眼原本的代码：
 @Injectable()export class JwtAuthGuard extends AuthGuard('jwt') {  handleRequest(error: any, user: any, info: any) {    if (error || !user) {      throw new UnauthorizedException('验证失败');    }    return user;  }}
现在，我们重新实现了这个守卫，提供了更严格的验证和更好的错误处理：
 import { CanActivate, ExecutionContext, Injectable, UnauthorizedException } from '@nestjs/common';import { JwtService } from '@nestjs/jwt';import { ConfigService } from '@nestjs/config';import { TokenUtils } from '../utils/token.utils';import winstonLogger from '../../loggers/winston.logger';@Injectable()export class JwtAuthGuard implements CanActivate {  private logger = winstonLogger;  constructor(    private jwtService: JwtService,    private configService: ConfigService  ) {}  async canActivate(context: ExecutionContext): Promise {    const token = TokenUtils.extractTokenFromContext(context);    if (!token) {      this.logger.warn(`未提供访问令牌：${context}`);      throw new UnauthorizedException('未提供访问令牌');    }    try {      const request = context.switchToHttp().getRequest();      request.user = await this.jwtService.verifyAsync(token, {        audience: this.configService.get('JWT_TOKEN_AUDIENCE'),        issuer: this.configService.get('JWT_TOKEN_ISSUER')      });      return true;    } catch (error) {      this.logger.error(`验证访问令牌失败：${error.message}`, error.stack);      throw new UnauthorizedException('无效的访问令牌');    }  }}
刷新令牌守卫
新增 JwtRefreshGuard 专门用于处理刷新令牌的验证：
 import { ExecutionContext, Injectable, UnauthorizedException } from '@nestjs/common';import { ConfigService } from '@nestjs/config';import { JwtService } from '@nestjs/jwt';import { TokenUtils } from '../utils/token.utils';import { getJWTVerifyOptions } from '../../config/jwt.config';import winstonLogger from '../../loggers/winston.logger';@Injectable()export class JwtRefreshGuard {  private logger = winstonLogger;  constructor(    private jwtService: JwtService,    private configService: ConfigService  ) {}  async canActivate(context: ExecutionContext) {    const token = TokenUtils.extractTokenFromContext(context);    const options = getJWTVerifyOptions(this.configService).refreshToken;    try {      this.jwtService.verify(token, options);      return true;    } catch (error) {      this.logger.error(`验证刷新令牌失败：${error.message}`, error.stack);      throw new UnauthorizedException('无效的刷新令牌');    }  }}
 4.3.6. 工具类支持
在之前的实现中，令牌提取的逻辑分散在各处，容易导致处理不一致。为了统一处理令牌的提取逻辑，新增 TokenUtils 工具类：
import { ExecutionContext } from '@nestjs/common';import { Request } from 'express';export class TokenUtils {  static extractToken(request: Request): string | undefined {    const [type, token] = request.headers.authorization?.split(' ') ?? [];    return type === 'Bearer' ? token : undefined;  }  static extractTokenFromContext(context: ExecutionContext): string | undefined {    const request = context.switchToHttp().getRequest();    return this.extractToken(request);  }}
 4.4. 客户端功能实现
 4.4.1. API 请求封装
在用户登录后，我们需要确保所有 API 请求都能正确携带身份验证信息。然而，accessToken 可能会过期，如果没有自动刷新机制，用户将频繁被登出，影响体验。我们希望实现一个自动处理令牌的方案，使得：
每个请求都自动携带 accessToken 进行身份验证。
当 accessToken 过期时，自动使用 refreshToken 获取新的 accessToken，并重试原请求。
如果 refreshToken 也失效，则清除令牌并让用户重新登录。
我们使用 Axios 拦截器 来实现这一机制，主要分为两部分：
请求拦截器：
在每个请求发送前，自动读取 accessToken，并将其添加到请求头。
如果 accessToken 不存在，则直接发送请求。
响应拦截器：
监听 API 响应，如果返回 401 Unauthorized，说明 accessToken 可能已过期。
如果 refreshToken 仍然有效，则使用它请求新的 accessToken，然后重试原始请求。
如果 refreshToken 失效，则清除所有令牌，并要求用户重新登录。
这是客户端请求与响应拦截逻辑的流程：
const api = axios.create({  baseURL: process.env.REACT_APP_API_URL,  withCredentials: true,  timeout: 10000});// 请求拦截器：添加令牌api.interceptors.request.use(  (config) => {    const token = localStorage.getItem('accessToken');    if (token) {      config.headers = AxiosHeaders.from(config.headers);      config.headers.set('Authorization', `Bearer ${token}`);    }    return config;  },  (error) => Promise.reject(error));// 响应拦截器：处理令牌刷新api.interceptors.response.use(  (response) => response,  async (error) => {    const originalRequest = error.config;    // 处理 401 错误和令牌刷新    if (error.response?.status === 401 && !originalRequest._retry) {      originalRequest._retry = true;      const refreshToken = localStorage.getItem('refreshToken');            if (refreshToken) {        try {          const { data } = await axios.post(            `${process.env.REACT_APP_API_URL}/auth/refresh`,            { refreshToken }          );          const newAccessToken = data.access_token;          localStorage.setItem('accessToken', newAccessToken);          originalRequest.headers.Authorization = `Bearer ${newAccessToken}`;          return api(originalRequest);        } catch (error) {          // 刷新失败时清除所有令牌          localStorage.removeItem('accessToken');          localStorage.removeItem('refreshToken');          return Promise.reject(error);        }      }    }    return Promise.reject(error);  });
这个改造实现了对身份验证流程的优化和自动化：
能够自动为请求添加访问令牌，确保每次请求都具备正确的身份验证信息。
能够检测令牌是否过期，并在必要时进行处理，防止因过期导致请求失败。
支持自动刷新令牌，并在刷新成功后重新尝试原始请求，从而提高用户体验，减少因身份验证失效带来的干扰。
 4.4.2. 状态管理优化
首先先介绍一下身份验证流程中整个认证状态的流转：
用户在首次访问时可能处于 未认证 状态，系统会自动检查用户的登录状态。
认证过程中可能会发生令牌过期的情况，需要进行 令牌刷新。
而在用户注销时，系统会清除本地存储数据。
为了有效管理用户的认证状态和流程，我们引入了一个状态机，覆盖以下几种主要状态和转变：
未认证
初始状态，表示用户尚未通过认证。系统会自动检查是否有有效的认证信息（如 accessToken 或 refreshToken）。如果没有，用户将无法访问受保护的资源。
认证中
系统正在验证用户的认证信息，可能是通过自动登录检查（例如检查本地存储的 accessToken 或 refreshToken）来恢复用户的会话。若检查成功，用户进入 已认证 状态；若失败，进入 未认证 状态。
已认证
认证成功后，用户的身份验证信息有效，允许访问受保护的资源。如果在该状态下，用户的 accessToken 过期，系统会自动尝试通过刷新令牌（refreshToken）来更新 accessToken，进入 令牌刷新中 状态。
令牌刷新中
当 accessToken 过期且用户依然处于已认证状态时，系统会通过 refreshToken 尝试获取新的 accessToken。如果刷新成功，系统返回 已认证 状态；如果刷新失败，用户会被迫重新认证（进入 未认证 状态）。
已注销
用户主动退出时，系统会清除本地存储的认证信息，返回到 未认证 状态，确保用户的会话被完全销毁。
状态转换
通过自动登录检查、令牌刷新等机制，我们确保用户认证状态的持续性和稳定性。系统根据认证状态的变化自动调整访问权限和用户会话管理。
在用户状态管理中，我们先添加了自动登录相关的功能：
const createUserSlice: StateCreator = (set, get) => ({  // ... 其他状态  isAutoLoading: false,  // 新增自动登录状态  // 清除用户信息  clearUser: () => {    localStorage.removeItem('accessToken');    localStorage.removeItem('refreshToken');    set({ user: null, isAutoLoading: false });  },  // 自动登录功能  autoLogin: async () => {    const state = get();    if (state.isAutoLoading || state.user) return;    const accessToken = localStorage.getItem('accessToken');    const refreshToken = localStorage.getItem('refreshToken');    if (!accessToken && !refreshToken) return;    set({ isAutoLoading: true });    try {      let token = accessToken;      // 如果没有访问令牌但有刷新令牌，尝试刷新      if (!token && refreshToken) {        const response = await api.post('/auth/refresh', { refreshToken });        token = response.data.access_token;        if (token) {          localStorage.setItem('accessToken', token);        }      }      // 获取用户信息      const response = await api.get('/auth/me', {        headers: { Authorization: `Bearer ${token}` }      });      set({ user: response.data, isAutoLoading: false });    } catch (error) {      localStorage.removeItem('accessToken');      localStorage.removeItem('refreshToken');      set({ user: null, isAutoLoading: false });      throw error;    }  },  // 登出功能增强  logout: async () => {    try {      await api.post('/auth/logout');    } finally {      localStorage.removeItem('accessToken');      localStorage.removeItem('refreshToken');      set({ user: null });    }  }});
 4.4.3. 状态管理范式转变
在登录功能中，我们需要处理用户的身份验证，同时提供「记住我」功能。然而，使用传统的状态管理（也就是我们的 Zustand）来存储 error 和 isLoading 状态可能会带来一些问题：
全局状态污染：error 和 isLoading 这些状态只是登录相关，不需要在整个应用范围内存储。
手动管理状态：需要在 try/catch 中手动更新 isLoading，并在发生错误时手动存储 error，代码较为冗长。
状态同步问题：如果多个组件依赖相同的登录逻辑，手动管理状态可能会导致数据不同步。
为了解决这些问题，我们决定使用 React Query 提供的 useMutation，将登录请求的状态管理完全交由 React Query 处理。
安装 React Query：
yarn add @tanstack/react-query
让我们以注册组件为例，来看看这次改造。
在之前的实现中，我们使用全局状态来管理加载状态和错误信息：
const Register = () => {  const register = useUserStore(state => state.register);  const isLoading = useUserStore(state => state.isLoading);  const error = useUserStore(state => state.error);  const formik = useFormik({    // ...    onSubmit: async (values) => {      try {        const { username, email, password } = values;        await register({ username, email, password });        navigate('/login', {          state: {            message: '注册成功！请登录您的账号。',            email: values.email          }        });      } catch (error) {        console.error('注册失败：', error);      }    }  });};
这种方式存在以下问题：
状态管理过于集中，不同组件的加载状态和错误状态混杂在一起
需要手动管理状态的清理和重置
错误处理不够优雅
缺乏对请求生命周期的完整控制
在开始实现具体功能之前，我们需要先配置 React Query。首先修改应用的入口文件 index.tsx：
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';const queryClient = new QueryClient();const root = ReactDOM.createRoot(document.getElementById('root') as HTMLElement);root.render(                  );
使用 React Query 的 useMutation 后，代码变得更加清晰和强大：
const Register = () => {  const setUser = useUserStore(state => state.setUser);  const { mutate: register, isPending, error } = useMutation({    mutationFn: async (values: {      username: string;      email: string;      password: string;    }) => {      const response = await api.post('/users/create', values);      return response.data;    },    onSuccess: (data) => {      setUser(data.user);      navigate('/login', {        state: {          message: '注册成功！请检查邮箱完成验证',          email: data.user.email        },        replace: true      });    }  });  const formik = useFormik({    // ...    onSubmit: async (values) => {      register({        username: values.username,        email: values.email,        password: values.password      });    }  });};
这种改进带来了多个显著的好处，使得代码更加清晰、组件更加独立，且状态管理更加高效：
实现了状态隔离。每个组件都有自己独立的加载和错误状态，不同的请求不会相互影响，从而避免了状态混乱的问题。同时，当组件卸载时，状态会自动清理，确保资源的合理释放。
得益于生命周期钩子的引入，异步操作的管理更加灵活。mutationFn 负责定义实际的异步操作，onSuccess 处理成功场景，而 onError 则用于错误处理。这些钩子让我们能够更精准地控制请求的执行过程。
在错误处理方面，这种改进也带来了增强。错误信息会被自动捕获并保存，同时错误状态与组件绑定，使得错误管理更加直观。此外，还能够提供更详细的错误类型信息，方便开发者调试和优化。
大幅简化了使用方式。开发者不需要手动处理 try/catch 逻辑，也不需要手动管理 loading 状态，只需直接调用 mutate 函数，即可完成异步操作，提高了开发效率和代码可读性。
使用 useMutation 的基本步骤：
定义 mutation 函数：
mutationFn: async (values) => {  const response = await api.post('/users/create', values);  return response.data;}
配置生命周期钩子：
onSuccess: (data) => {  // 处理成功场景},onError: (error) => {  // 处理错误场景}
在组件中使用：
const { mutate, isPending, error } = useMutation({ ... });// 触发 mutationmutate(values);// 使用状态{isPending && }{error && }
同样的，修改 VerifyEmail 组件：
import React, {useEffect} from 'react'; import {useLocation, useNavigate} from 'react-router-dom'; import {useMutation} from '@tanstack/react-query'; import {useUserStore} from '../stores'; import api from '../stores/common/api';  const VerifyEmail = () => {   const location = useLocation();   const navigate = useNavigate();   const token = new URLSearchParams(location.search).get('token');    const {     emailVerified,     verificationError,     verificationToken,     verificationUserId,     clearVerificationState   } = useUserStore(state => ({     emailVerified: state.emailVerified,     verificationError: state.verificationError,     verificationToken: state.verificationToken,     verificationUserId: state.verificationUserId,     clearVerificationState: state.clearVerificationState   }));    const { mutate: verifyEmail, isPending } = useMutation({     mutationFn: async (token: string) => {       const response = await api.get(`/users/verify-email?token=${token}`);       return response.data;     },     onSuccess: (data) => {       if (data.success) {         useUserStore.setState({           emailVerified: true,           verificationUserId: data.userId         });         navigate('/login', { replace: true })       } else {         useUserStore.setState({           verificationError: data.error,           verificationUserId: data.userId         });       }     },     onError: (error) => {       useUserStore.setState({ verificationError: error.message || '验证过程中发生未知错误' });     }   });    useEffect(() => {     if (token) verifyEmail(token);   }, [token]);    useEffect(() => {     return () => {       clearVerificationState();       window.history.replaceState({}, '', window.location.pathname);     }   }, []);    const handleResend = async () => {     if (verificationUserId) {       try {         await api.post(`/users/resend-verification/${verificationUserId}`);         navigate('/login', {           state: { message: '新的验证邮件已发送，请查收邮箱' }         });       } catch (error) {         useUserStore.setState({ verificationError: '重新发送验证邮件失败' });         throw error instanceof Error           ? error.message           : '重新发送验证邮件失败';       }     }   }    return (                                             验证电子邮件           
            {isPending && (                                           正在验证您的邮箱...
             
           )}            {emailVerified && (                            邮箱验证成功！正在跳转至登录页面……             
           )}            {verificationError && (                            {verificationError}               {verificationUserId && (                                )}             
           )}            {!isPending && !emailVerified && !verificationError && verificationToken && (                            验证链接已失效
                            
           )}         
       
     
   ); };  export default VerifyEmail; 
 4.4.4. 登录组件改造
我们需要对登录组件（Login.tsx）进行改造，以支持「记住我」功能。
在表单验证模式中增加「记住我」选项：
 const validationSchema = Yup.object().shape({   username: Yup.string().required('请输入用户名！'),   password: Yup.string().required('请输入密码！'),  rememberMe: Yup.boolean()  // 新增}); const formik = useFormik({   initialValues: {     username: '',     password: '',     rememberMe: false  // 新增  },   validationSchema,  onSubmit: async (values) => {    login(values);  }});
使用 useMutation 重构登录逻辑：
 const { mutate: login, isPending, error } = useMutation({   mutationFn: async (credentials: {     username: string,     password: string,     rememberMe: boolean,   }) => {     const response = await api.post('/auth/login', credentials);     return response.data;   },   onSuccess: async (data) => {     localStorage.setItem('accessToken', data.access_token);     // 只有在用户选择“记住我”时才保存刷新令牌    if (formik.values.rememberMe) {      localStorage.setItem('refreshToken', data.refresh_token);     }    setUser(data.user);     navigate('/', {       state: { message: '登陆成功！' },       replace: true     })   },   onError: (error) => {     // 登录失败时清除所有令牌    localStorage.removeItem('accessToken');     localStorage.removeItem('refreshToken');     clearUser();     console.log('登录失败：', error);   } });
添加自动登录检查逻辑：
 useEffect(() => {   const checkAutoLogin = async () => {     const accessToken = localStorage.getItem('accessToken');     const refreshToken = localStorage.getItem('refreshToken');     if (accessToken || refreshToken) {       try {         await autoLogin();       } catch (error) {         clearUser();         localStorage.removeItem('accessToken');         localStorage.removeItem('refreshToken');         console.log('检查自动登录失败：', error);       }     }   }   checkAutoLogin().then(r => console.log('检查自动登录成功：', r)); }, []);
登录后自动跳转：
 useEffect(() => {   if (user && !isAutoLoading) {     navigate('/', { replace: true });   } }, [user, isAutoLoading, navigate]);
添加「记住我」选项的界面元素：
            记住我    
 4.5. 邮箱验证提示
为了提升用户体验，我们需要在用户未验证邮箱时给出明显的提示。这个功能包含两个部分：提示组件和布局改造。
创建 UnverifiedBanner 组件来显示验证提示：
import React from 'react';import { useUserStore } from '../stores';const UnverifiedBanner = () => {  const user = useUserStore(state => state.user);  if (user && !user.verified) {    return (              您的邮箱尚未验证，请尽快验证。您可以修改邮箱地址或重新发送验证邮件。      
    );  }  return null;};export default UnverifiedBanner;
这个组件具有几个重要特点。它通过全局状态获取用户信息，确保始终使用最新的用户数据。同时，它只会在用户尚未完成验证时显示，避免对已验证用户造成干扰。此外，组件还提供了快捷的邮箱验证操作，使用户能够方便地完成身份确认，提高使用体验。
将验证提示集成到 AuthLayout 中：
import React from 'react'; import UnverifiedBanner from '../components/UnverifiedBanner';  type AuthLayoutProps = {   children: React.ReactNode; };  const AuthLayout = ({ children }: AuthLayoutProps) => {   return (                            {children}       
     
   ); };  export default AuthLayout; 
这种改进带来了多方面的好处。用户可以及时了解自己的邮箱验证状态，避免因未验证而影响正常使用。同时，组件提供了直接的验证操作入口，使用户能够快速完成身份确认。此外，它保持了统一的视觉风格，与整体界面设计相协调，并且不会影响原有的布局结构，确保页面的整洁与一致性。
为了解决用户可能未收到验证邮件或验证邮件过期的问题，我们需要实现验证邮件重发功能：
import React, {useCallback, useEffect} from 'react';import { useNavigate } from 'react-router-dom';import {useMutation} from '@tanstack/react-query';import { useUserStore } from '../stores';import api from '../stores/common/api';const ResendVerification = () => {  const navigate = useNavigate();  const {    user,    verificationUserId,    clearVerificationState  } = useUserStore(state => ({    user: state.user,    verificationUserId: state.verificationUserId,    clearVerificationState: state.clearVerificationState  }));  const { mutate: resendEmail, isPending, error } = useMutation({    mutationFn: async (userId: string) => {      const response = await api.post(`/users/resend-verification/${userId}`);      return response.data;    },    onSuccess: () => {      navigate('/login', {        state: { message: '新的验证邮件已发送至你的注册邮箱' },        replace: true      });    }  })  const handleResend = useCallback(() => {    if (!verificationUserId) {      console.error('缺少用户 ID');      return;    }    resendEmail(verificationUserId);  }, [verificationUserId, resendEmail]);  useEffect(() => {    return () => {      clearVerificationState();    };  }, [clearVerificationState]);  return (                                        邮箱验证          
                                    你的邮箱 {user?.email} 还未验证            
            {error && (                                                                  {error.message}                
              
            )}                                                      没有收到邮件？请检查垃圾邮件文件夹              
                              需要修改邮箱？前往{' '}                 {                    e.preventDefault();                    navigate('/settings');                  }}                >                  账户设置                              
            
          
        
      
    
  );}export default ResendVerification;
通过这个功能，我们为用户提供了一个完整的邮箱验证补救方案，帮助他们顺利完成账号验证过程。
 4.6. 错误边界处理
在复杂的单页应用中，错误处理是一个非常重要的环节。为了防止应用因为某个组件的错误而完全崩溃，我们引入了错误边界（Error Boundary）机制。
安装 react-error-boundary：
yarn add react-error-boundary
 4.6.1. 应用入口改造
首先，我们在应用的最顶层添加错误边界保护。修改 App.tsx：
import React from 'react';import { RouterProvider } from 'react-router-dom';import { ErrorBoundary } from 'react-error-boundary';import router from './router';import ErrorFallback from './components/ErrorFallback';const App = () => {  return (                );}export default App;
这样做可以捕获整个应用中的 React 组件错误，防止应用崩溃。
 4.6.2. 错误回退组件
我们创建了一个专门的错误回退组件 ErrorFallback.tsx，用于显示错误信息并提供重试功能：
import React from 'react';import { FallbackProps } from 'react-error-boundary';const ErrorFallback = ({ error, resetErrorBoundary }: FallbackProps) => {  return (                                    发生错误！
          {error.message}
        
      
          
  );}export default ErrorFallback;
错误回退组件具备以下核心功能，旨在提升错误处理的可读性和用户体验：
提供清晰的错误信息展示。组件能够显示友好的错误提示，同时呈现具体的错误详情，并保持错误信息的格式化显示，以便用户理解问题所在。
支持错误恢复功能。用户可以通过重试按钮尝试重新执行操作，同时，resetErrorBoundary 方法允许重置错误状态，使应用能够正常运行，让用户得以从错误中恢复。
在用户体验方面，组件采用统一的错误提示样式，确保与应用的整体设计风格保持一致。同时，它提供清晰的操作指引，帮助用户快速做出合适的应对操作，从而减少因错误导致的使用困扰。
 4.7. 路由访问控制
为了确保用户只能访问其权限内的页面，我们需要实现路由保护机制。这包括对私有路由的保护和对公共路由的控制。
 4.7.1. 受保护路由组件
创建 ProtectedRoute 组件用于保护需要登录才能访问的页面：
import React from 'react';import {useLocation, Navigate} from 'react-router-dom';import {useUserStore} from '../stores';const ProtectedRoute = ({ children }: { children: React.ReactNode }) => {  const user = useUserStore(state => state.user);  const isAutoLoading = useUserStore(state => state.isAutoLoading);  const location = useLocation();  // TODO: 返回一个加载动画  if (isAutoLoading) return 加载中……
;  if (!user) return ;  return <>{children};}export default ProtectedRoute;
 4.7.2. 公共路由组件
创建 PublicRoute 组件用于处理登录、注册等公共页面：
import React from 'react';import {useUserStore} from '../stores';import {Navigate, useLocation} from 'react-router-dom';const PublicRoute = ({children} : {children: React.ReactNode}) => {  const user = useUserStore(state => state.user);  const isAutoLoading = useUserStore(state => state.isAutoLoading);  const location = useLocation();  if (isAutoLoading) return 加载中……
;  if (user) {    const from = location.state?.from?.pathname || '/';    return ;  }  return <>{children};}export default PublicRoute;
 4.7.3. 路由配置优化
使用这些保护组件来包装路由：
const router = createBrowserRouter([   {     path: '/',     element:    },   {     path: '/register',     element:    },   {     path: '/login',     element:    },   {     path: '/verify-email',     element:    },   {     path: '/resend-verification',     element:    } ]);
可以写一个简单的 MainPage 组件来测试登出功能：
import React from 'react';import { useUserStore } from '../stores';import MainLayout from '../layouts/MainLayout';const MainPage = () => {  const logout = useUserStore(state => state.logout);  return (                )};export default MainPage;


Hexo 配置 i18n
2024-12-02T02:20:17.000Z
运营个人博客时，可能会遇到这样的需求：希望网站能够支持多语言，让来自不同地区的读者都能便捷地阅读我们的内容。
这就需要用到网站的国际化（也就是 i18n）功能。
对于使用 Hexo 搭建的博客而言，实现国际化不仅需要考虑内容的翻译，还要处理模板渲染等问题。
本文使用的主要插件是 hexo-generator-plus。
在开始配置之前，请确保已经卸载以下插件以避免冲突：
hexo-generator-archive
hexo-generator-category
hexo-generator-index
hexo-generator-tag
本文使用的模板语言是 Pug 语言。
对于导航栏中切换语言的方案，我只实现了双语言的逻辑。
 基础配置
为了避免困扰：
Hexo 根目录下的 _config.yml 将被称呼为 Hexo 配置项
themes/**/_config.yml 将被称呼为 主题配置项
首先，我们需要在 Hexo 的配置文件中进行一些基本设置。这些设置将决定网站的语言选项和 URL 结构。
language: [zh, en]  # 支持的语言列表，第一个为默认语言new_post_name: :title.md  # 新文章的命名方式# 如果你安装了 hexo-abbrlinkpermalink: posts/:abbrlink.html  # 文章的永久链接格式abbrlink:  rep: hex  # 使用十六进制作为文章的唯一标识# hexo-generator-plus 的配置项generator_plus:  language: [zh, en]  # 生成器支持的语言列表  pagination_dir: 'page'  # 分页目录  generator: ["index", "archive", "category", "tag"]  # 需要生成的页面类型  # 首页生成器配置  index_generator:    per_page: 10  # 这些数字和顺序可以自定义    order_by: -date  # 归档页面配置  archive_generator:    per_page: 25    order_by: -date  # 分类页面配置  category_generator:    per_page: 25    order_by: -date    enable_index_page: true  # 如果你想要分类列表页的话  # 标签页面配置  tag_generator:    per_page: 25    order_by: name    enable_index_page: true  # 如果你想要标签列表页的话
接着在主题配置项里配置想要的菜单链接：
menu:   home: /   archive: /archives   categories: /categories   tags: /tags   about: /about   GitHub: https://github.com/cytrogen   RSS: /atom.xml
 目录结构
以下是必需的目录结构：
source/├── _posts/                     # 默认语言的所有博文│   └── *.md                    # 不能有子目录├── en/                         # 英文版特定内容│   └── 与 source 目录结构相同├── archives/                   # 归档页面│   └── index.md                # layout: archive├── categories/                 # 分类页面│   └── index.md                # layout: category-index└── tags/                       # 标签页面    └── index.md                # layout: tag-index
当然，你也可以选择其他语言，但其他语言的目录需要和对应的 themes/**/languages/*.yml 的名称相同。
请确保每个 *.md 的 Front-Matter 中都有 lang: **。
 语言文件配置
网站的固定文本（如导航菜单、按钮文字等）需要通过语言文件来实现国际化。这些文件需要放在 themes/**/languages/ 目录下。
这是我的例子：
zh.yml：
 menu:home: 首页archive: 归档tags: 标签categories: 分类about: 关于friendlinks: 友情链接archive_title: 归档tags_title: 标签categories_title: 分类prev: 上一页next: 下一页prev_post: 上一篇next_post: 下一篇more: ...阅读全文translated: 翻译 · 原文地址
en.yml：
 menu:home: HOMEarchive: ARCtags: TAGScategories: CATEabout: ABOUTfriendlinks: Friend Linksarchive_title: Archivetags_title: Tagscategories_title: Categoriesprev: PREVnext: NEXTprev_post: PREV POSTnext_post: NEXT POSTmore: ...MOREtranslated: Translate · Original Link
 模板文件实现
从这里开始，只写关于我的博客网站所用的方案。
请按照自己的主题，自行进行修改。
 分类页面模板
分类页面需要两个模板：分类列表页面和具体分类页面。
分类列表页面（category-index.pug）：
 extends partial/layoutblock container    .archive        // 标题内容优先使用 page.title        // 如果不存在则使用国际化函数 __() 获取 categories_title 的翻译        h2.archive-title= page.title || __('categories_title')        .category-list            // 获取所有分类数据            each category in get_categories().data                // 对每个分类计算符合当前语言的文章数量                - var postCount = category.posts.data ? category.posts.data.filter(post => post.lang === page.lang).length : 0                if postCount > 0                    .category-item                        // 每个分类显示为一个链接，包含分类名称、文章数量计数                        // url_for_lang() 生成多语言支持的 URL                        - var categoryPath = category.slug || category.name                        a.post-title-link(href=url_for_lang(page.lang, 'categories/' + categoryPath))                            = category.name                            span.category-count= ` (${postCount})`
具体分类页面（category.pug）：
 extends partial/layoutblock container    include mixins/post    .archive        h2.archive-title= page.category        +postList()
这里文章显示相关的功能被封装成了一系列混入（mixins），方便在不同页面重用（mixins/post.pug）：
 mixin postInfo(item)    .post-info        != full_date(item.date, 'l')        // 如果文章有 from 属性且当前页面是首页或者文章页        if item.from && (is_home() || is_post())            // 显示一个表示文章翻译来源的链接            a.post-from(href=item.from target="_blank" title=item.from)!= __('translated')mixin posts()    ul.home.post-list        // 遍历所有的文章        - for (var post of page.posts.data || [])            // 只显示与当前页面语言匹配的文章            - if (post.lang == page.lang)                li.post-list-item                    article.post-block                        h2.post-title                            a.post-title-link(href= url_for(post.path))                                != post.title                        +postInfo(post)                        // 如果有摘要，就显示摘要和“阅读全文”链接                        if post.excerpt                            .post-content                                != post.excerpt                            a.read-more(href= url_for(post.path))!= __('more')                        else                            .post-content                                != post.content
 标签页面模板
和分类页面模板近乎一致：
tag-index.pug：
 extends partial/layoutblock container    include mixins/post    .archive        h2.archive-title= page.title || __('tags_title')        .tag-list            each tag in get_tags().data                - var postCount = tag.posts.data ? tag.posts.data.filter(post => post.lang === page.lang).length : 0                if postCount > 0                    .tag-item                        - var tagPath = tag.slug || tag.name                        a.post-title-link(href=url_for_lang(page.lang, 'tags/' + tagPath))                            = tag.name                            span.tag-count= ` (${postCount})`block pagination    include mixins/paginator    +home()block copyright    include partial/copyright
tag.pug：
 extends partial/layoutblock container    include mixins/post    .archive        h2.archive-title= page.tag        +postList()block pagination    include mixins/paginator    +home()block copyright    include partial/copyright
 归档页面模板
归档页面只需要一个 archive.pug：
extends partial/layoutblock container    include mixins/post    +postList()block pagination    include mixins/paginator    +home()block copyright    include partial/copyright
它调用的混入：
mixin postList()    .archive        // 是否有文章数据        if page.posts            // 确保文章列表存在且不为空            - var posts = page.posts.data || page.posts            if posts && posts.length                // 创建一个年份对象用于存储分组                // 只处理与当前页面语言相匹配的文章                // 使用文章日期获取年份                // 将文章添加到对应年份的数组中                - var years = {}                - for (var post of posts)                    - if (post.lang == page.lang)                        - var year = new Date(post.date).getFullYear()                        - if (!years[year]) years[year] = []                        - years[year].push(post)                // 将年份按降序排列（先显示年份最大的）                - Object.keys(years).sort((a, b) => b - a).forEach(function(year) {                    h2.archive-year!= year                    - years[year].forEach(function(post) {                        .post-item                            +postInfo(post)                            a.post-title-link(href= url_for(post.path))                                != post.title                    - })                - })
 导航栏实现
导航栏是实现语言切换的关键接口（nav.pug）。
由于我的博客主题中，导航栏并不宽，因此我写了顶底部来区分开部分链接：
ul.nav.nav-list    // 顶层    div.nav-list-top        // 遍历主题配置项中 menu 的所有键值        each path, key in theme.menu            // 排除掉想要放在底部的链接，我这里写的 GitHub 和 RSS            if key !== 'GitHub' && key !== 'RSS'                li.nav-list-item                    // 检测是否是外部链接                    // 如果是，就在新标签页打开                    // 英文页面的路径前添加 /en 前缀                    // 判断当前页面是否激活（用于高亮显示）                    - var re = /^(http|https):\/\/*/gi;                    - var tar = re.test(path) ? "_blank" : "_self"                    - var fullPath = page.lang === 'en' ? '/en' + path : path                    - var act = !re.test(path) && "/" + page.current_url === fullPath                    a.nav-list-link(class={active: act} href=url_for(fullPath) target=tar)                        != __(('menu.' + key))    // 底部    div.nav-list-bottom        // 语言切换按钮        li.nav-list-item.lang-switch            if page.lang == 'en'                a.nav-list-link(href=url_for('/')) 中文            else                a.nav-list-link(href=url_for('/en')) ENGLISH
 使用方法
完成上述配置后，创建新文章时需要在 Front-Matter 中指定语言：
---title: 文章标题date: 2024-01-01lang: zh---
如果想创建同一篇文章的其他语言版本，只需要创建一个新的 Markdown 文件，指定相应的 lang，并在 Front-Matter 中通过 from 字段关联原文：
---title: Article Titledate: 2024-01-01lang: enfrom: /posts/original-post.html---


React + NestJS 购物平台练习【4】用户注册功能
2024-11-28T05:00:00.000Z
全栈实践又到了我们喜闻乐见的用户注册功能……
 1. 修 BUG
我们先修一下先前写的 BUG……
 1.1. 导出 BUG
在我们先前创建的 src/stores/index.ts 中，我们写的是：
import useUserStore from './user';
这样写的话，实际运行项目后会报错。
正确的写法是：
export { useUserStore } from './user';
index.ts 是用于导出所有的 Store，因此是 export 而不是 import
要理解为什么必须使用 { useUserStore } 而不是 useUserStore，我们需要了解 JavaScript 和 TypeScript 中的默认导出（default export）和具名导出（named export）之间的区别
 1.1.1. 具名导出
在 stores/user/index.ts 中，useUserStore 是通过具名导出方式来导出的：
export const useUserStore = createSelectors(useUserStoreBase);
这表示我们将 useUserStore 作为一个具名导出，并且它可以通过具名导出来引用。具名导出的语法正是：
export { useUserStore } from './user';
 1.1.2. 默认导出
如果我们使用的是默认导出，那么导出时应该写成：
export default useUserStore;
然后我们才可以在其他文件使用默认导出语法：
export useUserStore from './user';
 1.2. 实体关系 BUG
后续在后端开发完注册 API、运行应用时，会遇到实体关系配置错误：
TypeORMError: Entity metadata for Users#orders was not found. Check if you specified a correct entity object and if it's connected in the connection options.
这是因为 NestJS 使用 TypeORM 时需要通过 TypeOrmModule 注册所有的实体。如果一个实体（例如 Users）中引用了其他实体（例如 Orders），TypeORM 会尝试加载并解析这些关系。如果 Orders 没有在 TypeOrmModule 配置中注册，TypeORM 将会因为找不到该实体的元数据而抛出错误。
唉，这时候有人该问了，第二篇 里不是已经写了个 database.module.ts 来统一配置吗？里面还配置了个 autoLoadEntities 呢。
在数据库模块的配置中，我们确实加上了 autoLoadEntities: true，希望能自动加载所有实体，避免每次手动注册实体。然而，autoLoadEntities 的工作机制并非全局加载所有实体，它仅自动加载通过 TypeOrmModule.forFeature() 注册的实体。因此，如果某个实体未被 forFeature 导入到任何模块中，TypeORM 无法找到它。
在 TypeOrmModule 中，有三种方式来配置实体加载，每种方式有不同的适用场景：
单独定义：
 TypeOrmModule.forRoot({  //...  entities: [    Users,    Products,    Payments,    Orders,    OrderItems,    InventoryLogs,    Categories,    Carts,    CartItems,    Addresses,  ],}),
这种方式适合开发阶段，明确知道所有实体的数量和位置时，每当创建新实体时手动添加即可。但在项目复杂、实体较多或依赖多模块的情况下，逐一引入会显得繁琐，容易出错，且不便于代码维护。
自动加载：
 TypeOrmModule.forRoot({  //...  autoLoadEntities: true,}),
autoLoadEntities 会自动加载通过 TypeOrmModule.forFeature() 引入的实体。这意味着在模块中显式使用 TypeOrmModule.forFeature([Entity]) 的实体将被自动添加到连接配置的 entities 数组中。
注意：
这要求每个模块中要包含实体的 forFeature 配置。否则未注册的实体将无法自动加载，容易引发实体关系配置错误。
在 Users 实体中，Orders 实体被作为关联实体引用（@OneToMany(() => Orders, order => order.user))，因此 TypeORM 会尝试在 entities 配置数组中找到并加载 Orders 的元数据。由于 Orders 没有在任何模块的 forFeature 中注册，TypeORM 会在解析 Users 实体的关系时找不到 Orders，导致报错。
自定义引入路径：
 TypeOrmModule.forRoot({  //...  entities: ['dist/**/*.entity{.ts,.js}'],}),
这是官方推荐的方式，使用通配符路径直接加载所有编译后的实体文件（如 dist/entities/*.entity.js），避免了逐一手动添加的麻烦，并保证所有实体自动注册，减少遗漏问题。
在我们的 database.module.ts 中添加第三种方式的配置，即可解决报错。
 2. 实现注册表单组件
 2.1. 基础结构
我们的注册页面由两个主要部分组成：
Register 组件：处理表单逻辑、验证以及提交请求
AuthLayout 组件：负责提供页面的布局和样式
Register 组件嵌套在 AuthLayout 中，这样可以确保页面结构保持一致。
首先，我们来看看 AuthLayout.tsx 组件的代码，它定义了一个简单的容器，将任何传递给它的内容居中显示，并设置一些基本的样式：
import React from 'react';type AuthLayoutProps = {  children: React.ReactNode;};const AuthLayout = ({ children }: AuthLayoutProps) => {  return (                  {children}      
    
  );};export default AuthLayout;
这里使用了 Tailwind CSS 进行样式布局，AuthLayout 用于包装页面的子元素，确保其在屏幕上居中显示，并有一定的阴影和内边距。
接着在 src/pages 目录下创建 Register.tsx。
 2.2. 表单开发
在我们的 Register 组件中，我们将使用 Formik 来处理表单的状态管理和提交，并使用 Yup 来进行表单验证。Formik 和 Yup 的结合提供了简洁且强大的表单验证和管理能力。
用以下命令安装 Formik 和 Yup：
yarn add formik yup
 2.2.1. Formik 用法
Formik 通过 useFormik Hook 管理表单的状态和行为。在 Register 页面中，我们初始化了一个表单，提供了初始值和 onSubmit 处理函数。
import { useFormik } from 'formik';const Register = () => {  const formik = useFormik({    initialValues: {      username: "",      email: "",      password: "",      confirmPassword: ""    },    validationSchema,    onSubmit: (values) => {      setIsSubmitting(true);      setTimeout(() => {        console.log(values);  // 模拟提交        setIsSubmitting(false);      }, 2000);    }  });  // ...}
initialValues：初始化表单的默认值
validationSchema：使用 Yup 创建的验证规则（稍后会详细介绍）
onSubmit：处理表单提交的函数setIsSubmitting(true)：在表单提交时，我们将 isSubmitting 设置为 true，这会触发按钮禁用以及按钮文本更新为「注册中……」
setTimeout：为了模拟实际的提交过程，我们使用 setTimeout 延迟了 2 秒钟。实际应用中这里应该替换为 API 请求，不过我们的 API 还没完成呢
setIsSubmitting(false)：当提交操作完成时，我们将 isSubmitting 设置为 false，恢复按钮的正常状态
 2.2.2. Yup 验证
Yup 是一个 JavaScript 的对象模式验证库，我们通过它来定义表单的验证规则。下面是每个字段的验证规则：
import * as Yup from 'yup';const Register = () => {  const validationSchema = Yup.object({    username: Yup.string().required("请输入用户名！"),    email: Yup.string().email("请输入有效的邮箱地址！").required("请输入邮箱地址！"),    password: Yup.string().min(6, "密码必须至少包含6个字符！").required("请输入密码！"),    confirmPassword: Yup.string()      .oneOf([Yup.ref("password")], "密码不匹配！")      .required("请输入确认密码！"),  });  // ...}
username：必须填写，并且是字符串
email：必须添加，并且符合邮箱格式
password：必须至少有 6 个字符
confirmPassword：必须与密码匹配
Yup 和 Formik 的结合提供了简洁的验证机制，自动管理每个字段的错误信息，并在表单提交时触发验证。
 2.2.3. 表单渲染
表单输入框的渲染非常直观。我们通过 formik.handleChange 来处理用户输入，并通过 formik.errors 和 formik.touched 来显示错误信息。
const Register = () => {  // ...  return (                  注册账户      
                                    用户名                              {formik.touched.username && formik.errors.username && (            {formik.errors.username}
          )}        
        {/* ... */}      
      );};
value：绑定表单值
onChange 和 onBlur：处理表单输入和失去焦点事件
formik.errors：在字段发生错误时显示错误信息
用同样的写法，写完「邮箱地址」、「密码」和「确认密码」输入框：
const Register = () => {  // ...  return (                  注册账户      
              {/* ... */}                              邮箱地址                              {formik.touched.email && formik.errors.email && (            {formik.errors.email}
          )}        
                              密码                              {formik.touched.password && formik.errors.password && (            {formik.errors.password}
          )}        
                              确认密码                              {formik.touched.confirmPassword && formik.errors.confirmPassword && (            {formik.errors.confirmPassword}
          )}        
      
      );};
 2.2.4. 按钮的状态管理
按钮的状态管理对于处理表单提交时的交互反馈是非常重要的。
useState 是 React 中用于管理组件状态的 Hook。它允许我们在函数组件内部创建一个可变的状态，并返回一个更新该状态的函数。在注册页面中，我们使用 useState 来管理表单是否正在提交。
import React, { useState } from 'react';const Register = () => {    const [isSubmitting, setIsSubmitting] = useState(false);        // ...};
isSubmitting：表示表单是否正在提交，初始值是 false，即默认情况下表单没有提交
setIsSubmitting：用于更新 isSubmitting 状态的函数
每当表单提交时，我们会将 isSubmitting 设置为 true，表示正在进行提交操作。当提交完成后，再将其设置回 false。
 2.2.5. 按钮的状态变化
在注册页面中，表单的提交按钮（        );};
disabled={isSubmitting}：按钮在提交时被禁用，防止用户多次点击。每次表单提交时，isSubmitting 会被设为 true，这将使按钮处于禁用状态，直到提交结束
按钮文本切换：根据 isSubmitting 的值，按钮的文本会动态改变如果表单正在提交（isSubmitting === true），按钮文本会显示为「注册中……」
如果表单没有提交（isSubmitting === false），按钮显示为「注册」
 2.3. 路由配置
为了使我们的页面能够被访问和管理，在我们的 router.tsx 中添加路由 /register：
import Register from './pages/Register';const router = createBrowserRouter([  // ...  {    path: '/register',    element:   }]);
运行 React 项目，访问 localhost:3000/register：
图片是另外加的。
 3. 实现后端注册 API
在现代的 Web 应用开发中，用户注册功能是几乎每个系统都需要的基础部分。用户注册不仅需要保存用户的基本信息，还要确保密码等敏感数据的安全性。
设想这样一个场景：我们正在开发一个用户系统，要求用户可以通过提供必要的个人信息进行注册，并创建一个账号。由于用户密码是非常敏感的信息，我们必须在保存密码之前进行加密，以确保其安全性。此外，我们还需要在需要时提供其他用户管理的接口，如更新、删除等操作。
 3.1. 创建用户模块
用户模块负责管理用户相关的逻辑，创建 users.module.ts 文件：
import { Module } from '@nestjs/common';import { TypeOrmModule } from '@nestjs/typeorm';import { UsersController } from './users.controller';import { UsersService } from './users.service';import { Users } from '../entities/users.entity';@Module({  imports: [TypeOrmModule.forFeature([Users])],  controllers: [UsersController],  providers: [UsersService]})export class UsersModule {}
在此模块中，我们使用了 TypeOrmModule.forFeature([Users]) 来将用户实体与 TypeORM 绑定，以便在 UsersService 中使用数据库的增删查改功能。
 3.2. 创建用户控制器
控制器负责定义 API 路由和对应的处理方法，创建 users.controller.ts 文件：
import { Controller, Post, Get, Body, Param } from '@nestjs/common';import { UsersService } from './users.service';import { Users } from '../entities/users.entity';@Controller('users')export class UsersController {  constructor(private readonly usersService: UsersService) {}  @Post('create')  create(@Body() user: Partial): Promise {    return this.usersService.create(user);  }  @Get(':id')  findById(@Param('id') id: string): Promise {    return this.usersService.findById(id);  }  @Post('update/:id')  update(@Param('id') id: string, @Body() updateUser: Partial): Promise {    return this.usersService.update(id, updateUser);  }  @Post('delete/:id')  remove(@Param('id') id: string): Promise {    return this.usersService.remove(id);  }}
我们定义了以下几个方法：
create：用于处理用户注册的 POST 请求，调用 UsersService.create 方法以保存用户信息
findById、update 和 remove 方法：分别用于获取、更新和删除用户信息
 3.3. 编写用户服务
UsersService 负责处理具体的业务逻辑，包括数据的加密和与数据库的交互。在实现注册功能时，我们需要对用户密码进行加密，并将加密后的密码与其他信息一起保存到数据库。
创建 users.service.ts：
import { Injectable, NotFoundException } from '@nestjs/common';import { InjectRepository } from '@nestjs/typeorm';import { Repository } from 'typeorm';import * as bcrypt from 'bcrypt';import { Users } from '../entities/users.entity';@Injectable()export class UsersService {  constructor(@InjectRepository(Users) private usersRepository: Repository) {}  async create(user: Partial): Promise {    const hashedPassword = await bcrypt.hash(user.password, 10);    const newUser = this.usersRepository.create({      ...user,      password: hashedPassword    });    return this.usersRepository.save(newUser);  }  async update(id: string, updateUser: Partial): Promise {    const user = await this.findById(id);    if (updateUser.password) {      updateUser.password = await bcrypt.hash(updateUser.password, 10);    }    Object.assign(user, updateUser);    return this.usersRepository.save(user);  }  async remove(id: string): Promise {    const result = await this.usersRepository.delete(id);    if (result.affected === 0) {      throw new NotFoundException(`User with ID ${id} is not found`);    }  }  async findById(id: string): Promise {    const user = await this.usersRepository.findOneBy({ id });    if (!user) {      throw new NotFoundException(`User with ID ${id} is not found`);    }    return user;  }}
UsersService 实现了以下方法：
create：用于创建用户。在保存用户数据前，通过 bcrypt.hash 方法对密码进行加密，然后将加密后的用户数据保存到数据库
update：用于更新用户信息。如果更新的数据中包含 password，则需要再次加密后再保存
remove：用于删除用户信息。如果删除操作没有影响任何行，则会抛出 NotFoundException 错误
findById：用于根据用户 ID 查询用户信息。找不到用户时同样会抛出 NotFoundException
 3.4. 通过 Swagger 生成文档标签
我们将为每个控制器方法添加 Swagger 标签：
// ...import { ApiTags, ApiOperation, ApiBody, ApiResponse, ApiParam } from '@nestjs/swagger';@ApiTags('Users')@Controller('users')export class UsersController {  // ...  @ApiOperation({ summary: '创建新用户' })  @ApiBody({ description: '用户信息', type: Users })  @ApiResponse({ status: 201, description: '用户成功创建', type: Users })  @Post('create')  // ...  @ApiOperation({ summary: '根据ID获取用户信息' })  @ApiParam({ name: 'id', description: '用户ID' })  @ApiResponse({ status: 200, description: '获取用户信息成功', type: Users })  @Get(':id')  // ...  @ApiOperation({ summary: '更新用户信息' })  @ApiParam({ name: 'id', description: '用户ID' })  @ApiBody({ description: '更新的用户信息', type: Users })  @ApiResponse({ status: 200, description: '用户更新成功', type: Users })  @Post('update/:id')  // ...  @ApiOperation({ summary: '删除用户' })  @ApiParam({ name: 'id', description: '用户ID' })  @ApiResponse({ status: 200, description: '用户删除成功' })  @Post('delete/:id')  // ...}
@ApiTags('Users')：将此标签添加到控制器顶部，使得所有方法都归入 Users 类别，便于在 Swagger 文档中管理
@ApiOperation：为每个方法添加操作说明，使其清晰描述了 API 的功能
@ApiBody：为 POST 请求体参数添加描述，指定了参数内容的描述和数据类型
@ApiParam：为路径参数添加说明，方便开发者了解需要传入的参数
@ApiResponse：指定响应的状态码和描述信息，以及返回的数据类型，便于用户了解响应格式
访问 localhost:APP_PORT/api-docs 来查看 Swagger 文档。
 3.5. 使用 DTO 来进行优化
在现代 Web 应用中，数据传输对象（DTO）是与外部通信的标准化方式之一。在 NestJS 项目中，DTO（Data Transfer Object）不仅帮助你确保传递的数据格式一致，还提供了结构化和验证机制，使得 API 接口更加清晰、安全和可维护。
DTO 通常用于：
定义 API 接口所需的请求体和响应体的结构
对数据进行验证和转换
确保前后端在数据传输时遵循相同的约定
在我们已经编写了注册用户的逻辑后，为什么还需要创建 DTO 并用它来顶替原本的写法？
答案是：增强数据验证和规范化输入输出。
增强验证机制：DTO 通过类验证器（如 class-validator）来确保传入的数据符合预期。例如，我们可以设置 MinLength 来确保密码长度不小于 6 个字符、使用 IsEmail 来验证邮箱格式。这不仅使代码更加规范，而且还大大提高了 API 的可靠性和安全性
清晰的 API 结构：DTO 使 API 请求和响应体更加清晰。通过 DTO，前后端可以明确约定需要的数据字段和格式，这样可以减少由于数据格式不匹配导致的错误
易于扩展和维护：DTO 提供了一个灵活的扩展点。如果未来业务需求发生变化，我们只需修改 DTO，而不必修改整个业务逻辑。这样，系统的可维护性和扩展性更强
我们已经有了一个用于用户注册的业务逻辑，现在我们要将 DTO 集成到 UsersController 和 UsersService 中。
 3.5.1. 创建 DTO
在 src/users 目录下创建 dto 目录，并在其中再创建一个 create-user.dto.ts 文件：
import { IsString, IsEmail, MinLength } from 'class-validator';export class CreateUserDto {  @IsString()  username: string;  @IsEmail()  email: string;  @MinLength(6, { message: '密码长度必须不小于6个字符' })  password: string;}
CreateUserDto 定义了用户注册时需要传入的字段，并且为这些字段添加了验证规则：
username 字段要求是字符串类型
email 字段要求是有效的邮箱格式
password 字段要求密码长度至少为 6 个字符
 3.5.2. 在控制器中使用 DTO
接下来，在 UsersController 中，我们将 CreateUserDto 引入，并将其用于 create 方法的请求体验证。我们需要使用 @Body() 装饰器将请求体映射到 DTO 类。
// ...import { CreateUserDto } from './dto/create-user.dto';@ApiTags('Users')@Controller('users')export class UsersController {  // ...  @ApiOperation({ summary: '创建新用户' })  @ApiBody({ description: '用户信息', type: CreateUserDto })  // 使用DTO类型  @ApiResponse({ status: 201, description: '用户成功创建', type: Users })  @Post('create')  create(@Body() user: CreateUserDto): Promise {  // 接收CreateUserDto类型    return this.usersService.create(user);  }  // ...}
在上述代码中：
使用 @ApiBody 注解指定了请求体的描述，type 字段使用 CreateUserDto
@Body() 装饰器会将请求体映射到 CreateUserDto 类型，从而进行数据验证
 3.5.3. 在服务中使用 DTO
在 UsersService 中，create 方法接收了 CreateUserDto 类型的参数，并在保存到数据库之前进行密码的哈希处理：
// ...import { CreateUserDto } from './dto/create-user.dto';@Injectable()export class UsersService {  constructor(@InjectRepository(Users) private usersRepository: Repository) {}  async create(user: CreateUserDto): Promise {    const hashedPassword = await bcrypt.hash(user.password, 10);  // 使用DTO中的password    const newUser = this.usersRepository.create({      ...user,      password: hashedPassword    });    return this.usersRepository.save(newUser);  }}
在这里，我们在服务层接收的参数是 CreateUserDto 类型，它包含了所有必要的字段和验证规则。通过这种方式，我们避免了在控制器中进行复杂的验证操作，将其交给 DTO 来处理，使得业务逻辑更加简洁和清晰。
 3.5.4. 定义 Swagger Schema
在 NestJS 中，你可以通过在 DTO 中使用 Swagger 的注解来定义和生成 API 的 Schema。
import { IsString, IsEmail, MinLength } from 'class-validator';import { ApiProperty } from '@nestjs/swagger';export class CreateUserDto {  @ApiProperty({    description: '用户名，用户的唯一标识',    example: 'john_doe'  })  @IsString()  username: string;  @ApiProperty({    description: '用户的邮箱地址，必须为有效的邮箱格式',    example: 'johndoe@example.com'  })  @IsEmail()  email: string;  @ApiProperty({    description: '密码，必须至少包含6个字符',    example: 'password123456',    minLength: 6  })  @MinLength(6, { message: '密码长度必须不小于6个字符' })  password: string;}
 3.6. 与前端的集成
先前写前端代码的时候，我们的 Register.tsx 并没有连接到后端 API，而是使用 setTimeout 模拟了一下提交。
因此我们要对现有的前端代码进行修改和优化。
 3.6.1. 添加状态管理逻辑
在 Register.tsx 中，我们使用了本地状态管理 isSubmitting。
const [isSubmitting, setIsSubmitting] = useState(false);
为了让状态的管理更统一，我们需要将其改为使用全局状态管理，也为之后添加更多功能奠定了基础。
首先是修改 stores/index.ts：
export { useUserStore } from './user';
接着在 Register.tsx 中使用 useUserStore：
import { useUserStore } from '../stores';// ...const register = useUserStore(state => state.register);const isLoading = useUserStore(state => state.isLoading);const error = useUserStore(state => state.error);
register：一个用于注册用户的全局方法
isLoading：表单提交的状态
error：记录注册过程中发生的错误信息
 3.6.2. 新增注册方法
在修改 Register.tsx 时，我们同样需要在 stores 目录下的状态管理逻辑中进行调整，以支持注册功能的完整实现。
首先在 stores/user/types.ts 中新增注册凭据类型：
export interface RegisterCredentials {   username: string;   email: string;   password: string; }
并更新用户状态类型：
export interface UserState {  // ...  register: (credentials: RegisterCredentials) => Promise;}
接着在 stores/user/actions.ts 中新添注册功能：
register: async (credentials: RegisterCredentials) => {   set({ isLoading: true, error: null });   try {     const response: AxiosResponse = await api.post('/users/create', credentials);     const user = response.data;     set({       isLoading: false,       error: null,       lastUpdated: Date.now()     });     return user;   } catch (error) {     const errorMessage = error instanceof Error       ? error.message       : '注册过程中发生意外错误';     set({       isLoading: false,       error: errorMessage     });     throw error;   } }, 
主要逻辑为：
初始化状态：设置 isLoading 为 true，清空可能的旧错误
调用注册 API：发送用户的注册信息到 /users/create，并解析后端返回的用户数据
成功处理：更新状态，但不设置 user 值，因为注册完成后还需登录
错误处理：捕获错误并设置错误信息
状态恢复：无论成功或失败，都将 isLoading 恢复为 false
 3.6.3. 实现与后端的连接
先前我们用了 setTimeout 来模拟注册：
setTimeout(() => {  console.log(values);  setIsSubmitting(false);}, 2000);
现在我们应当与实际的后端进行交互，发送注册请求：
onSubmit: async (values) => {  try {    const { username, email, password } = values;    await register({ username, email, password });    navigate('/login', {      state: {        message: '注册成功！请登录您的账号。',        email: values.email      }    });  } catch (error) {    console.error('注册失败：', error);  }}
成功后，跳转到 /login 页面，并通过 state 传递一条注册成功的信息。就算失败了，也会捕获错误信息，便于显示给用户。
由于我们在 store 中已经处理了注册错误，这里就不需要额外处理，直接 console.error 即可。
navigate 来自于 react-router-dom 库：
import { useNavigate } from 'react-router-dom';// ...const navigate = useNavigate();
 3.6.4. 用户错误信息提示
在 Register.tsx 中添加以下内容：
return (                        注册账户      
      {error && (                  {error}        
      )}      {/* ... */}    );
用户提交表单时，如果后端返回错误信息，将会在表单顶部显示一条清晰的错误提示。这提升了用户体验，让用户了解失败的原因并尝试修正。
 3.6.5. 禁用表单控件
将 Register.tsx 中所有的  标签都添加上这个属性：
disabled={isLoading}
这代表着提交过程中表单控件会被禁用，避免用户重复提交。
isLoading 由状态管理工具提供，确保整个应用对状态变化的感知一致。
同样的，对 
运行前端和后端，进行注册测试。
别忘了在前端目录下创建 .env：
REACT_APP_API_URL=http://localhost:后端的端口
注册成功后你应该会被导向 /login 页面，上面会弹出：
Unexpected Application Error!404 Not Found💿 Hey developer 👋You can provide a way better UX than this when your app throws errors by providing your own ErrorBoundary or errorElement prop on your route.
 4. 实现邮箱验证
邮箱验证是用户注册流程中的重要安全环节，旨在确认用户提供的邮箱地址是真实且可用、防止机器人和垃圾注册、提高账号安全性，同时为后续通信建立可靠的联系渠道。
典型的邮箱验证流程包括：
用户注册提供邮箱
系统生成唯一验证令牌
发送包含验证链接的邮件
用户点击链接完成验证
系统校验令牌的有效性
 4.1. 前端实现
我们首先需要在路由中添加邮箱验证页面的路由。在 router.tsx 中进行修改：
import VerifyEmail from './pages/VerifyEmail';const router = createBrowserRouter([  // ...  {    path: '/verify-email',    element:   }]);
 4.1.1. Zustand 状态管理更新
接下来，我们需要更新 Zustand 的用户状态管理，增加邮箱验证相关的状态的方法。
更新 types.ts，添加邮箱验证相关的枚举和接口：
export enum EmailVerificationError {   TOKEN_INVALID = 'TOKEN_INVALID',   TOKEN_EXPIRED = 'TOKEN_EXPIRED',   ALREADY_VERIFIED = 'ALREADY_VERIFIED' }
在实现邮箱验证功能时，我定义了三种可能的验证错误状态：
TOKEN_INVALID（无效令牌）
当用户提供的验证链接被篡改、不完整或不存在于系统
可能是用户误点击了错误的链接
可能是验证链接已被恶意修改
系统将拒绝这类验证请求，并显示错误提示
TOKEN_EXPIRED（令牌过期）
验证链接已超过有效期限（24 小时）
防止长期未使用的过期链接被重复使用
用户需要重新请求发送验证邮件
提示用户链接已过期，需要重新获取
ALREADY_VERIFIED（已验证）
用户尝试使用已经验证过的邮箱链接再次验证
可能是用户重复点击验证链接
系统将提示用户邮箱已成功验证
通常会直接引导用户登录
export interface VerificationResponse {   success: boolean;   message: string;   error?: EmailVerificationError;   userId?: string; }
验证响应接口则设计了一个标准的响应接口：
验证是否成功的标志
返回消息
可选的错误类型
可选的用户 ID
export interface UserState {  // ...  emailVerified: boolean;  verificationError?: EmailVerificationError;  verificationUserId?: string;  verificationInProgress: boolean;  verificationToken?: string;  verifyEmail: (token: string) => Promise;  resendVerificationEmail: (userId: string) => Promise;}
 4.1.2. 邮箱验证组件基础结构
在 pages 目录下创建 VerifyEmail.tsx。首先我们来构建组件的基本结构和状态管理：
import React, { useCallback, useEffect } from 'react'; import { useLocation, useNavigate } from 'react-router-dom'; import { useUserStore } from '../stores'; import { EmailVerificationError } from '../stores/user/types';const VerifyEmail = () => {   // 获取路由和导航相关钩子  const location = useLocation();   const navigate = useNavigate();   // 从 Zustand store 中获取状态和方法  const verifyEmail = useUserStore(state => state.verifyEmail);   const resendVerificationEmail = useUserStore(state => state.resendVerificationEmail);   const isLoading = useUserStore(state => state.isLoading);   const error = useUserStore(state => state.error);   const emailVerified = useUserStore(state => state.emailVerified);   const verificationError = useUserStore(state => state.verificationError);   const verificationUserId = useUserStore(state => state.verificationUserId);   const verificationInProgress = useUserStore(state => state.verificationInProgress);   // 渲染逻辑将在这里实现  return (                                验证电子邮件
          {/* 不同状态的渲染将在这里实现 */}        
      
    
  ); }; export default VerifyEmail;
状态管理部分详解：
从 Zustand store 中提取多个状态和方法
verifyEmail：邮箱验证方法
resendVerificationEmail：重新发送验证邮件方法
isLoading：加载状态
error：错误信息
emailVerified：邮箱是否已验证
verificationError：验证错误类型
verificationUserId：用于重发验证邮件的用户 ID
verificationInProgress：验证是否正在进行中
接下来，我们实现邮箱验证的核心处理逻辑：
const handleVerification = useCallback(async (token: string) => {   try {     const result = await verifyEmail(token);     if (result.success) window.history.replaceState({}, '', window.location.pathname);     return result;   } catch (error) {     return {       success: false,       error: error instanceof Error ? error.message : '验证失败'     };   } }, [verifyEmail]);
该方法的主要目的是处理邮箱验证逻辑。通过 token 调用 verifyEmail 函数，判断验证是否成功，并在页面历史状态中作出相应的更新。
这里使用了 useCallback 进行性能优化，确保在依赖项未变化时，返回的函数引用不会发生变化。
window.history.replaceState 方法则是替换了当前历史记录的状态。当用户被验证成功后，token 会被移除，也避免了用户刷新页面时重复验证。
const handleResendVerification = async () => {   if (verificationUserId) {     try {       const response = await resendVerificationEmail(verificationUserId);       if (response.success) {        navigate('/login', {           state: { message: '新的验证邮件已发送，请查收邮箱' }         });       }    } catch (error) {       console.error('重新发送验证邮件失败：', error);     }   } }
这个函数的主要功能是为特定用户重新发送验证邮件。调用异步函数 resendVerificationEmail 成功后就会自动导航到登录页面。
添加两个 useEffect 钩子来管理验证流程：
// 处理邮箱验证useEffect(() => {   const searchParams = new URLSearchParams(location.search);   const token = searchParams.get('token');   const currentToken = useUserStore.getState().verificationToken;   if (token && !verificationInProgress && !emailVerified && token !== currentToken) {     handleVerification(token).then(r => {       if (r.success && 'message' in r) console.log('邮箱验证成功：', r.message);     });   } }, [handleVerification, verificationInProgress, emailVerified]); 
使用 URLSearchParams 解析 location.search，获取查询参数中的 token
在满足以下条件时调用 handleVerification：URL 中存在 token
当前未在进行验证
邮箱尚未验证成功
传入的 token 不等于当前用户的 verificationToken
调用 handleVerification 处理邮箱验证
// 处理验证成功后的跳转useEffect(() => {   if (emailVerified && !isLoading) {     const redirectTimer = setTimeout(() => {       navigate('/login');     }, 1500);     return () => clearTimeout(redirectTimer);   } }, [emailVerified, isLoading, navigate]);
当 emailVerified 为 true 且 isLoading 为 false 时，触发跳转逻辑
使用 setTimeout 在 1.5 秒后执行 navigate('/login')，给用户留出视觉反馈时间
在组件卸载或依赖更新时，通过 clearTimeout 清除定时器，避免潜在内存泄漏或多余跳转
最后，我们根据不同的验证状态渲染相应的界面：
return (                        验证电子邮件
        {/* 加载中状态 */}        { isLoading && (                                     正在验证您的电子邮件...
           
         )}        {/* 令牌过期状态 */}        { !isLoading && verificationError === EmailVerificationError.TOKEN_EXPIRED && (                                                      {error}             
                        
         )}        {/* 已验证状态 */}        {!isLoading && emailVerified && (                                     邮箱验证成功！即将跳转到登录页面...           
         )}      
    
  
);
 4.1.3. 邮件验证逻辑
上面说到了几个我们并没有写的方法：verifyEmail 和 resendVerificationEmail。
现在我们要在 actions.ts 中完善这两个方法。
先在文件开头位置导入 types.ts 中新增的内容：
import {   User,   UserState,   LoginCredentials,   RegisterCredentials,   VerificationResponse } from './types';
const createUserSlice: StateCreator = (set) => ({   // ...  emailVerified: false,   verificationError: undefined,   verificationUserId: undefined,   verificationInProgress: false,   verificationToken: undefined,   // ...});
verifyEmail 方法：
 verifyEmail: async (token: string): Promise => {  // 下面继续...},
verifyEmail 方法的目的在于确保邮箱有效且记录验证状态。
首先为了避免用户重复提交相同的 token、导致不必要的 API 调用，我们需要检查当前的状态：
若 verificationInProgress 为 true，那么就提示用户「验证正在进行中」
若 emailVerified 为 true 且 verificationToken 匹配，那么直接返回成功信息，避免重复请求
 const state = useUserStore.getState(); if (state.verificationInProgress || (state.verificationToken === token && state.emailVerified)) {   return {     success: state.emailVerified,     message: state.emailVerified ? '邮箱已验证' : '验证正在进行中'   }; }
进入验证流程前，我们需要确保应用的状态是明确的，并为用户显示验证的进度：
 set({   isLoading: true,   error: null,   verificationInProgress: true,   verificationToken: token });
验证邮箱地址需要服务端支持，因此发送带 token 的 API 请求进行校验（我这里设计的服务端 API 是要 GET
的）：
 try {  const response = await api.get(`/users/verify-email?token=${token}`);  const data = response.data;  // 下面继续...}
验证成功后，更新状态以记录邮箱已验证，并清理其他临时状态：
 try {  // ...  if (data.success) {     set({       isLoading: false,       error: null,       emailVerified: true,       verificationError: undefined,       verificationUserId: undefined,       verificationInProgress: false     });   }}
如果验证失败，那就保存失败信息、供用户查看，并允许用户再次尝试：
 try {  // ...  else {    set({       isLoading: false,       error: data.message,       emailVerified: false,       verificationError: data.error,       verificationUserId: data.userId,       verificationInProgress: false     });  }}
当然，API 请求也有可能失败，我们需要显示错误提示、避免影响用户体验：
 catch (error) {   const errorMessage = error instanceof Error     ? error.message     : '验证邮箱地址的过程中发生意外错误';   set({     isLoading: false,     error: errorMessage,     emailVerified: false,     verificationInProgress: false   });   return {     success: false,     message: errorMessage   }; }
resendVerificationEmail 方法
和 verifyEmail 基本上差不多：
 resendVerificationEmail: async (userId: string) => {   set({ isLoading: true, error: null });   try {    const response = await api.post(`/users/resend-verification/${userId}`);     const data = response.data;    set({       isLoading: false,       error: data.success ? null : data.message     });     return data;   } catch (error) {     const errorMessage = error instanceof Error       ? error.message       : '重新发送验证邮件失败';     set({       isLoading: false,       error: errorMessage     });     throw error;   } }, 
 4.2. 后端实现
在实现用户注册和邮箱验证功能时，我们通常会面临以下几个关键问题：
如何确保用户提供的邮箱是真实有效的？
如何防止垃圾注册和恶意用户？
如何安全地管理用户的验证状态？
 4.2.1. 用户实体扩展
为了支持邮箱验证功能，我们要在 Users 实体中添加以下字段：
@Column({ default: false })verified: boolean;@Column({ nullable: true })verificationToken: string;@Column({ nullable: true })verificationTokenExpires: Date;
这三个新增字段解决了邮箱验证的核心需求：
verified：标记用户是否已验证邮箱
verificationToken：存储唯一的验证令牌
verificationTokenExpires：设置令牌的过期时间
 4.2.2. 用户服务中的邮箱验证逻辑
先在 users.service.ts 的上方引入我们需要的内容：
import { ConflictException, Injectable, NotFoundException } from '@nestjs/common';import { v4 as uuidv4 } from 'uuid';import { EmailService } from '../email/email.service';import winstonLogger from '../loggers/winston.logger';export enum EmailVerificationError {  TOKEN_INVALID = 'TOKEN_INVALID',  TOKEN_EXPIRED = 'TOKEN_EXPIRED',  ALREADY_VERIFIED = 'ALREADY_VERIFIED'}interface VerificationResponse {  success: boolean;  message: string;  error?: EmailVerificationError;  userId?: string;}
@Injectable()export class UsersService {  private readonly logger = winstonLogger;  constructor(    @InjectRepository(Users)    private usersRepository: Repository,    private emailService: EmailService  ) {}  // ...}
create 方法用于创建一个用户。当一个用户尝试注册自己时，系统应当通过以下步骤确保注册过程的安全性和可靠性：
检查用户是否已存在，防止重复注册带来的冲突和逻辑错误：
 async create(user: CreateUserDto): Promise<{ id: string; email: string }> {  const existingUser = await this.usersRepository.findOne({    where: [{ email: user.email }, { username: user.username }]  });  if (existingUser) {    this.logger.warn(`用户名为 ${user.username} 或者邮箱地址为 ${user.email} 的用户已存在`);    throw new ConflictException('用户名或邮箱已存在');  }  // 下面继续...}
对用户密码进行加密后，生成验证令牌：
 const hashedPassword = await bcrypt.hash(user.password, 10);const verificationToken = uuidv4();this.logger.debug('验证码已生成：' + verificationToken);
结合用户信息和生成的安全数据，创建一个完整的用户对象：
 const newUser = this.usersRepository.create({  ...user,  password: hashedPassword,  verificationToken,  verificationTokenExpires: new Date(Date.now() + 24 * 60 * 60 * 1000),  verified: false});this.logger.info('用户已被保存：' + JSON.stringify(newUser));
将新用户记录写入数据库，完成用户创建：
 const savedUser = await this.usersRepository.save(newUser);this.logger.debug('保存的用户：' + JSON.stringify(savedUser));
发送验证邮件：
 await this.emailService.sendVerificationEmail(savedUser);
最终返回精简信息，避免返回敏感数据：
 return {  id: savedUser.id,  email: savedUser.email};
verifyEmail 方法用于验证用户邮箱。当用户点击验证链接时，系统通过该方法完成验证流程。此方法通过检查令牌的有效性和状态，确保邮箱验证的安全性和可靠性：
根据提供的 token 查找用户，验证请求是否有效：
 async verifyEmail(token: string): Promise {  this.logger.debug(`接收到的 token：${token}`);  const user = await this.usersRepository.findOne({    where: {      verificationToken: token    }  });  if (!user) {    this.logger.debug(`验证失败：未找到对应 token 的用户，token：${token}`);    return {      success: false,      message: '无效的验证链接',      error: EmailVerificationError.TOKEN_INVALID    };  }  this.logger.debug(    `找到用户：${user.email}, 验证状态：${user.verified}, token 过期时间：${user.verificationTokenExpires}`  );  // 下面继续...}
检查用户的验证状态。这里会有多个条件：
用户是否已验证：
 if (user.verified) {  this.logger.debug(`验证失败：用户 ${user.email} 已经验证过了`);  return {    success: false,    message: '邮箱已经验证过了',    error: EmailVerificationError.ALREADY_VERIFIED  };}
验证令牌是否过期：
 if (user.verificationTokenExpires < new Date()) {  this.logger.debug(    `验证失败：token 已过期, 用户: ${user.email}, ` +      `过期时间：${user.verificationTokenExpires}, 当前时间：${new Date()}`  );  return {    success: false,    message: '验证链接已过期，请重新发送验证邮件',    error: EmailVerificationError.TOKEN_EXPIRED,    userId: user.id  };}
更新用户验证状态，将 verified 属性设置为 true 并保存到数据库：
 user.verified = true;try {  await this.usersRepository.save(user);  this.logger.debug(`用户 ${user.email} 验证成功，已更新验证状态`);} catch (error) {  this.logger.error(`更新用户验证状态失败：${error.message}`, error.stack);  throw error;}
返回成功信息，告诉调用方邮箱验证完成：
 this.logger.debug(`验证流程完成，用户 ${user.email} 验证成功`);return {  success: true,  message: '邮箱验证成功'};
resendVerificationEmail 方法用于重新发送验证邮件。当用户请求重发验证邮件时，此方法处理生成新的验证令牌并发送邮件的整个流程，确保未验证用户能够完成邮箱验证：
通过 userId 查询目标用户，确保用户存在：
 async resendVerificationEmail(userId: string): Promise {  try {    const user = await this.findById(userId);    this.logger.debug(`找到用户：${user.email}, 当前验证状态：${user.verified}`);    // 下面继续...  }}
检查用户的验证状态；用户是否已验证：
 if (user.verified) {  this.logger.debug(`重发失败：用户 ${user.email} 已经验证过了`);  return {    success: false,    message: '邮箱已经验证过了',    error: EmailVerificationError.ALREADY_VERIFIED  };}
生成新的验证令牌，确保安全性，并更新过期时间：
 const oldToken = user.verificationToken;user.verificationToken = uuidv4();user.verificationTokenExpires = new Date(Date.now() + 24 * 60 * 60 * 1000);this.logger.debug(  `更新验证信息：用户：${user.email}, ` +    `旧 token：${oldToken}, ` +    `新 token：${user.verificationToken}, ` +    `过期时间：${user.verificationTokenExpires}`);
保存用户数据：
 await this.usersRepository.save(user);this.logger.debug(`用户验证信息已更新：${user.email}`);
发送验证邮件：
 await this.emailService.sendVerificationEmail(user);this.logger.debug(`验证邮件已重发至：${user.email}`);
返回成功信息：
 return {  success: true,  message: '验证邮件已重新发送'};
如果出现异常，就得记录错误日志、返回失败消息：
 catch (error) {  this.logger.error(`重发验证邮件失败：userId=${userId}, error=${error.message}`, error.stack);  return {    success: false,    message: '重新发送验证邮件失败',    error: EmailVerificationError.TOKEN_INVALID  };}
 4.2.3. 用户控制器新增接口
我们需要以下两个接口：
GET /verify-email：通过查询参数接收验证 token，完成用户邮箱验证
POST /resend-verification/:id：接收用户 id，重新发送验证邮件
@ApiOperation({ summary: '验证用户邮箱' })@ApiQuery({ name: 'token', description: '验证token' })@ApiResponse({ status: HttpStatus.OK, description: '邮箱验证成功' })@HttpCode(HttpStatus.OK)@Get('verify-email')async verifyEmail(@Query('token') token: string): Promise<{ message: string }> {  return this.usersService.verifyEmail(token);}@ApiOperation({ summary: '重新发送验证邮件' })@ApiParam({ name: 'id', description: '用户ID' })@ApiResponse({ status: HttpStatus.OK, description: '验证邮件已重新发送' })@HttpCode(HttpStatus.OK)@Post('resend-verification/:id')async resendVerification(@Param('id') id: string): Promise<{ message: string }> {  return this.usersService.resendVerificationEmail(id);}
关于 HttpStatus 和 @HttpCode，请见 这里。
 4.2.4. 开发邮件模块
安装邮件模块 @nestjs-modules/mailer：
yarn add @nestjs-modules/mailer
在 src 目录下创建 email 目录，并在内创建 email.module.ts：
import { Module } from '@nestjs/common';import { MailerModule } from '@nestjs-modules/mailer';import { ConfigService } from '@nestjs/config';import { HandlebarsAdapter } from '@nestjs-modules/mailer/dist/adapters/handlebars.adapter';import { join } from 'path';import { EmailService } from './email.service';@Module({  imports: [    MailerModule.forRootAsync({      useFactory: async (configService: ConfigService) => {        const transport = {          host: configService.getOrThrow('SMTP_HOST'),          port: configService.getOrThrow('SMTP_PORT'),          secure: false,          auth: {            user: configService.getOrThrow('SMTP_USER'),            pass: configService.getOrThrow('SMTP_PASS')          }        };        return {          transport,          defaults: {            from: `"Shopping Nest" <${configService.getOrThrow('SMTP_FROM_ADDRESS')}>`          },          template: {            dir: join(__dirname, 'templates'),            adapter: new HandlebarsAdapter(),            options: {              strict: true            }          }        };      },      inject: [ConfigService]    })  ],  providers: [EmailService],  exports: [EmailService]})export class EmailModule {}
我们需要在 .env 里新增几个值：
SMTP_HOST=SMTP_PORT=SMTP_USER=SMTP_PASS=SMTP_FROM_ADDRESS=
这些是常见的 SMTP（Simple Mail Transfer Protocol）配置参数，用于设置邮件服务器的基本信息以发送电子邮件。
SMTP_HOST：邮件服务器的主机地址，通常是邮件服务提供商的域名或 IP 地址（例如用 Gmail 的话就是写 smtp.gmail.com）
SMTP_PORT：邮件服务器使用的端口号，用于建立与邮件服务器的连接
常用端口：587：用于明文连接后升级为加密连接（STARTTLS）
465：用于加密连接（SSL / TLS）
25：传统的 SMTP 端口，可能被 ISP 限制
587 或 465 是现代邮件服务中最常见的选择
SMTP_USER：用于身份验证的用户名，通常是发送邮件的邮箱地址
SMTP_PASS：与 SMTP_USER 对应的密码，用于 SMTP 身份验证（一些服务 —— 如 Gmail—— 可能要求使用应用专用密码而不是账户密码）
SMTP_FROM_ADDRESS：邮件发送的来源地址，显示为邮件的 From 字段，通常是一个经过认证的邮箱地址
no-reply@yourdomain.com（用于自动邮件）
support@yourdomain.com（用于支持邮件）
有些服务可能要求 SMTP_FROM_ADDRESS 必须与 SMTP_USER 保持一致（我使用的 MailGun 就是如此）
Handlebars 是一个简单但强大的模板语言，允许我们通过 {{变量}} 语法轻松插入动态内容。它支持部分模板（Partials），让我们可以模块化地构建电子邮件模板。
部分模版示例：
        
我们希望邮件的内容是动态生成的，并且邮件的布局或样式能够灵活调整，那么就需要结合模板引擎来渲染邮件内容。
接着创建 email.service.ts，它会封装邮件发送的所有复杂逻辑：
导入模块并初始化：
 import { Injectable } from '@nestjs/common';import { ConfigService } from '@nestjs/config';import { MailerService } from '@nestjs-modules/mailer';import { readFileSync, existsSync } from 'fs';import { join, resolve } from 'path';import { execSync } from 'child_process';import * as HandleBars from 'handlebars';import { Users } from '../entities/users.entity';import winstonLogger from '../loggers/winston.logger';@Injectable()export class EmailService {  private readonly logger = winstonLogger;  private readonly templatesDir: string;  private readonly partialsDir: string;  // 下面继续...}
在构造函数中注入 ConfigService 和 MailerService。同时设置模板目录和部分模板目录的路径：
 constructor(    private configService: ConfigService,    private mailerService: MailerService  ) {    this.templatesDir = resolve(__dirname, 'templates');    this.partialsDir = resolve(this.templatesDir, 'partials');  }
初始化模块：
 async onModuleInit() {  this.ensureTemplatesExist();  await this.registerPartials();}
onModuleInit 方法会在模块初始化时被调用
ensureTemplatesExist 方法应当是检查模板是否存在，如果不存在则通过执行命令 `yarn copy-templates 来复制模板文件
registerPartials 方法则用于注册模板中的部分文件，确保这些部分模板可以在主模板中引用
确保模板文件存在：
 private ensureTemplatesExist() {  if (!existsSync(this.templatesDir)) {    this.logger.warn('dist 中无法找到 templates，复制中...');    execSync('yarn copy-templates');  }}
该方法检查模板文件夹是否存在。如果文件夹不存在，则执行命令将模板文件复制过来。
这确保了在构建后的 dist 文件夹中也能找到模板文件。
这需要在 package.json 里定义一条命令：
"scripts": {  // ...   "copy-templates": "copyfiles -u 3 src/email/templates/**/* dist/email/templates"}
copyfiles 用法：
安装 copyfiles 为开发依赖（或者直接全局安装）：
 yarn add -D copyfiles
如果是复制 src 下的所有 .js 文件到 dist，且保留目录结构：
 yarn copyfiles 'src/**/*.js' dist/
不保留目录结构：
 yarn copyfiles -f 'src/**/*.js' dist/
copyfiles -u 3 src/email/templates/**/* dist/email/templates 的含义是将 src/email/templates/ 文件夹下的所有文件和子文件夹复制到 dist/email/templates/，并通过 -u 3 参数调整复制时的目标路径结构。
其中 -u 3 表示忽略源路径中从末尾数起的 3 个目录层级，也就是不包含这些层级到目标路径中。
ensureTemplatesExist 方法解决了 NestJS 项目中、构建过程不会自动复制静态资源文件的问题。
当执行 yarn build 时，TypeScript 编译器只处理 .ts 文件。静态模板和资源不会自动复制到 dist 目录。
注册部分模板：
 private async registerPartials() {  const partials = [    { name: 'header', file: 'header.hbs' },    { name: 'footer', file: 'footer.hbs' },    { name: 'styles', file: 'styles.hbs' }  ];  for (const partial of partials) {    const partialPath = join(this.partialsDir, partial.file);    if (!existsSync(partialPath)) {      this.logger.error(`部分模板文件不存在：${partialPath}`);      throw new Error(`找不到部分模板文件：${partial.file}`);    }    try {      const template = readFileSync(partialPath, 'utf8');      HandleBars.registerPartial(partial.name, template);      this.logger.debug(`成功注册部分模板：${partial.name}`);    } catch (error) {      this.logger.error(`注册部分模板失败：${partial.name}`, {        error: error.message,        stack: error.stack,        path: partialPath      });      throw error;    }  }}
在模板中，通常会有一些公共部分（如页头、页脚、样式等），这些部分可以通过 Handlebars 的 registerPartial 方法来注册，之后可以在主模板中调用。
这里的三个 .hbs 文件会在后面完善。
编译模板：
 private async compileTemplate(templateName: string, context: any): Promise {  const templatePath = join(this.templatesDir, `${templateName}.hbs`);  if (!existsSync(templatePath)) {    this.logger.error(`模板文件不存在：${templatePath}`);    throw new Error(`找不到模板文件：${templateName}.hbs`);  }  try {    const templateContent = readFileSync(templatePath, 'utf8');    const template = HandleBars.compile(templateContent);    return template(context);  } catch (error) {    this.logger.error('编译模板失败', {      error: error.message,      stack: error.stack,      template: templateName,      path: templatePath    });    throw error;  }}
compileTemplate 方法用于读取模板文件并将其编译为 HTML 内容。它通过 Handlebars.compile 将模板文件内容编译为渲染函数，然后使用传入的 context 对象（包含动态内容）来渲染模板。
发送验证邮件：
 async sendVerificationEmail(user: Users) {  const logoPath = join(__dirname, '../assets/ShoppingNest.png');  this.logger.debug('Logo Path：' + logoPath);  const logoBase64 = readFileSync(logoPath).toString('base64');  const logoMimeType = 'image/png';  const base64Image = `data:${logoMimeType};base64,${logoBase64}`;  const frontendUrl = this.configService.get('CORS_ORIGIN');  const verificationUrl = `${frontendUrl}/verify-email?token=${user.verificationToken}`;  try {    const html = await this.compileTemplate('verification', {      username: user.username,      verificationUrl,      expiresIn: '24小时',      year: new Date().getFullYear(),      base64Image    });    await this.mailerService.sendMail({      to: user.email,      subject: '验证你的邮箱地址',      html    });    this.logger.info(`验证邮件已成功发送至 ${user.email}`);  } catch (error) {    this.logger.error('发送验证邮件失败', {      error: error.message,      stack: error.stack,      user: user.email    });    throw new Error(`发送验证邮件失败：${error.message}`);  }}
首先，读取图片文件并将其转换为 base64 格式，之后拼接验证链接，并使用 Handlebars 模板渲染邮件内容。
最后调用 MailerService.sendMail 发送邮件。
图片位置被我写在了 src/assets 目录中。但是它和 src/email/templates 目录一样，有着不会被自动复制到 dist 目录的问题。
解决方法也很简单，同样在 package.json 中定义一个命令：
"scripts": {  // ...  "copy-assets": "copyfiles -u 2 src/assets/**/* dist/assets"}
然后在 app.service.ts 被初始化时调用（也可以在 email.service.ts 中调用，只是我认为 src/assets 内的静态文件并不是仅被邮件模块使用）：
async onModuleInit() {  this.ensureAssetsExist();}private ensureAssetsExist() {  const assetsPath = resolve(__dirname, 'assets');  if (!existsSync(assetsPath)) {    this.logger.warn('dist 中无法找到 assets，复制中...');    execSync('yarn copy-assets');  }}
现在我们可以开始写验证邮件的实际内容了：
在 src/email 目录下创建 templates 目录，并创建 verification.hbs，作为验证邮件的主体模板：
       验证你的邮箱地址  {{> header}}  您好，{{username}}！
  感谢您注册我们的服务。请点击下面的按钮验证您的邮箱地址：
      验证邮箱  
  如果上面的按钮无法点击，请复制以下链接到浏览器地址栏：
  {{verificationUrl}}
  此验证链接将在{{expiresIn}}后过期。
  如果您没有注册我们的服务，请忽略此邮件。
{{> footer}}
这里使用了三个动态内容插值：
{{username}}：动态填充用户名称
{{verification}}：用户唯一的验证链接
{{expiresIn}}：链接有效期提示
在 src/email/templates 目录下创建 partials 目录，并在内创建 header.hbs：
   
这里的 style 可以根据自己的 Logo 图片进行调整。
其实还有一种方法，是在前端项目中的 public 目录里放 Logo 图片，然后这里直接调用 前端链接/图片文件名称.图片文件类型。
但是这意味着如果前端项目是在本地环境运行的，图片链接便无效。
在 src/email/templates/partials 目录下创建 footer.hbs：
   © {{year}} 你的公司名称. 保留所有权利。
  此邮件由系统自动发送，请勿回复。
这里可以自行修改。
在 src/email/templates/partials 目录下创建 styles.hbs：
 body {  margin: 0;  padding: 0;  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;  line-height: 1.6;  color: #333;  background-color: #f9f9f9;}.email-header {  text-align: center;  padding: 20px;  background-color: #ffffff;  border-bottom: 1px solid #eee;}.email-content {  max-width: 600px;  margin: 0 auto;  padding: 20px;  background-color: #ffffff;  border-radius: 8px;  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);}.button-container {  text-align: center;  margin: 30px 0;}.verify-button {  display: inline-block;  padding: 12px 24px;  background-color: #4CAF50;  color: #ffffff;  text-decoration: none;  border-radius: 5px;  font-weight: bold;  transition: background-color 0.3s;}.verify-button:hover {  background-color: #45a049;}.verification-url {  word-break: break-all;  padding: 10px;  background-color: #f5f5f5;  border-radius: 4px;  font-family: monospace;}.email-footer {  text-align: center;  padding: 20px;  color: #666;  font-size: 0.9em;}
同样可以自行修改。
最后便是在各个模块中进行引用：
users.module.ts：
 import { Module } from '@nestjs/common';import { TypeOrmModule } from '@nestjs/typeorm';import { UsersController } from './users.controller';import { UsersService } from './users.service';import { Users } from '../entities/users.entity';import { EmailModule } from '../email/email.module';@Module({  imports: [TypeOrmModule.forFeature([Users]), EmailModule],  controllers: [UsersController],  providers: [UsersService],  exports: [UsersService]})export class UsersModule {}
app.module.ts：
 // ...import { EmailModule } from './email/email.module';@Module({  imports: [    ConfigModule.forRoot({      isGlobal: true,      validationSchema: Joi.object({        // ...        CORS_ORIGIN: Joi.string().required(),        // SMTP 配置        SMTP_HOST: Joi.string().required(),        SMTP_PORT: Joi.number().required(),        SMTP_USER: Joi.string().required(),        SMTP_PASS: Joi.string().required(),        SMTP_FROM_ADDRESS: Joi.string().required()      })    }),    // ...    EmailModule  ]})
 5. 其他
 5.1. 修改 http-exception.filter.ts
import { ExceptionFilter, Catch, ArgumentsHost, HttpException, HttpStatus } from '@nestjs/common';import winstonLogger from '../loggers/winston.logger';@Catch()export class HttpExceptionFilter implements ExceptionFilter {  private readonly logger = winstonLogger;  catch(exception: unknown, host: ArgumentsHost) {    const ctx = host.switchToHttp();    const response = ctx.getResponse();    const request = ctx.getRequest();    const status = exception instanceof HttpException ? exception.getStatus() : HttpStatus.INTERNAL_SERVER_ERROR;    const errorResponse = {      statusCode: status,      timestamp: new Date().toISOString(),      path: request.url,      message: exception instanceof HttpException ? exception.getResponse() : 'Internal server error'    };    // 用 winstonLogger 输出异常    if (exception instanceof HttpException) {      this.logger.warn(`HTTP 异常：${JSON.stringify(errorResponse)}`);    } else {      this.logger.error(`未处理异常：${exception}`);    }    response.status(status).json(errorResponse);  }}
 5.2. 修改 Swagger 标签
从
@ApiResponse({ status: 200, description: 'xxx' })
统统修改为
@ApiResponse({ status: HttpStatus.OK, description: 'xxx' })@HttpCode(HttpStatus.OK)
状态码本身是数字，对于大多数人而言并不直观、需要对其有较深的理解。若需要统一调整状态码（如规范化状态码的使用），代码中可能需要逐一查找和替换。更何况状态码本身也更容易被误写为其他数字，难以自动检测错误。
而枚举值提供了清晰的语义，直接描述了状态码的含义，因此更容易理解。当需要统一调整时，可以直接通过 IDE 的自动补全功能快速选择合适的状态码。
以下为对应：
HTTP 状态码 HttpStatus 枚举值
200 OK
201 CREATED
204 NO_CONTENT
400 BAD_REQUEST
401 UNAUTHORIZED
404 NOT_FOUND
409 CONFLICT
500 INTERNAL_SERVER_ERROR
 5.3. 清空数据库中所有表的内容
在开发和测试中，尤其是运行集成测试或重置开发环境时，可能需要快速清空数据库中的所有表数据。
我根据 MySQL 写了一个清空所有表数据的脚本，确保测试数据或旧数据被完全移除，便于后续的干净测试或初始化操作。
import dataSource from '../config/data-source';async function deleteAllData() {  try {    await dataSource.initialize();    console.log('已连接到数据库');    const entityMetadatas = dataSource.entityMetadatas;    const totalTables = entityMetadatas.length;    await dataSource.query('BEGIN');    await dataSource.query('SET FOREIGN_KEY_CHECKS = 0');    for (let i = 0; i < totalTables; i++) {      const entityMetadata = entityMetadatas[i];      const tableName = entityMetadata.tableName;      const startTime = Date.now();      try {        console.log(`清空表：${tableName}`);        await dataSource.query(`TRUNCATE TABLE \`${tableName}\``);        const elapsedTime = (Date.now() - startTime) / 1000;        console.log(`清空表 (${i + 1}/${totalTables}): ${tableName} 完成，耗时: ${elapsedTime.toFixed(2)} 秒`);      } catch (error) {        console.error(`清空表 ${tableName} 时报错：`, error);      }    }    await dataSource.query('COMMIT');    console.log('所有表都被清空');  } catch (error) {    console.error('删除数据期间报错：', error);    await dataSource.query('ROLLBACK');  } finally {    await dataSource.query('SET FOREIGN_KEY_CHECKS = 1');    await dataSource.destroy();  }}deleteAllData().catch(error => {  console.error('删除数据期间报错：', error);});
可以在 package.json 中添加以下命令来使用：
"scripts": {  // ...  "delete-all-data": "ts-node src/database/delete-all-data.ts"}


React + NestJS 购物平台练习【3】数据设计与实现
2024-11-07T05:00:00.000Z
搭建完前端与后端的基础结构后，我们就可以开始着手于数据库设计了。
 1. 设计基础实体
在设计我们的购物平台的过程中，实体及其关系是核心的数据模型。我们从业务逻辑的角度来看，每个实体的意义和作用，这样可以更好地理解其在系统中的角色。
这里，我们以「用户」、「商品」、「订单」等为主线，讲解如何建立这些实体以及它们之间的关系，并举例说明其在业务场景中的应用。
 1.1. 用户
用户实体是系统的核心，因为大部分操作都需要绑定到用户。每个用户都有其唯一的 ID、用户名、邮箱和密码，这些信息用于身份验证和授权。
示例，一个用户 John Doe 创建了账号，并通过邮箱 johndoe@example.com 登录系统。数据库会在 Users 表中新增一条记录，保存 John 的邮箱、加密密码和创建时间。
 1.1.1. 代码实现分析
让我们深入分析 Users 实体的代码实现：
import {  Entity,  PrimaryGeneratedColumn,  Column,  CreateDateColumn,  UpdateDateColumn,  OneToMany,  OneToOne} from 'typeorm';@Entity()export class Users {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column({ unique: true })  username: string;  @Column({ unique: true })  email: string;  @Column()  password: string;  @CreateDateColumn()  created_at: Date;  @UpdateDateColumn()  updated_at: Date;  // ...}
这部分使用了 TypeORM 的装饰器来定义表结构：
@Entity() 装饰器将这个类标记为一个数据库实体
@PrimaryGeneratedColumn('uuid') 表示自动生成 UUID 作为主键
@Column({ unique: true }) 为用户名和邮箱添加了唯一性约束，防止重复注册
@CreateDateColumn() 会自动记录实体的创建时间
@UpdateDateColumn() 会自动记录实体的更新时间
用户表的字段及其业务含义如下：
id：主键，用于唯一标识每个用户，类型为 UUID，确保安全性和唯一性
username：用户名，系统中用于显示的名称，通常在用户之间是唯一的
email：用户的邮箱，通常作为主要联系手段，同时也是登录的标识之一
password：用户密码，以加密方式存储，用于用户验证
created_at 和 updated_at：创建时间和更新时间，记录用户注册和资料更新的时间
 1.1.2. 关联关系分析
Users 实体与其他实体之间建立了多个关联关系：
import { Orders } from './orders.entity';import { Carts } from './carts.entity';import { Addresses } from './addresses.entity';import { Payments } from './payments.entity';@Entity()export class Users {    // ...    @OneToMany(() => Orders, order => order.user)    orders: Orders[];    @OneToOne(() => Carts, cart => cart.user)    cart: Carts;    @OneToMany(() => Addresses, address => address.user)    addresses: Addresses[];    @OneToMany(() => Payments, payment => payment.user)    payments: Payments[];}
这些关联展示了用户实体在系统中的核心地位：
用户 - 订单关系（@OneToMany）一个用户可以有多个订单
这种一对多的关系允许系统追踪用户的所有购买历史
用户 - 购物车关系（@OneToOne）每个用户只能有一个购物车
一对一的关系确保购物车数据的独立性和安全性
用户 - 地址关系（@OneToMany）用户可以保存多个收货地址
方便用户在下单时快速选择收货地址
用户 - 支付关系（@OneToMany）记录用户的所有支付记录
用于追踪交易历史和财务统计
 1.1.3. 用户角色
在开发应用程序时，管理用户的权限和访问控制是至关重要的。这是因为不同类型的用户可能需要访问系统的不同功能。
例如，一个购物平台可能有以下几种角色：
管理员：可以管理用户、查看所有订单、编辑商品等
普通用户：只能查看商品、下订单、查看个人资料等
游客：仅限浏览，不进行任何交互
在这种场景下，我们需要为用户管理系统添加一个角色字段，以便区分不同的用户类型。
角色字段通常有助于完成以下任务：
不同权限管理：每种角色都有不同的权限。管理员可能有权访问系统的所有数据，而普通用户只能查看他们自己的数据。通过角色字段，我们可以在数据库中存储每个用户的角色信息
角色控制的用户界面：角色字段可以帮助系统为不同角色的用户显示不同的页面或功能。例如，管理员可以访问管理控制台，而普通用户只能看到他们的订单历史
安全性增强：通过角色字段，系统可以在后端进行权限验证，确保不同角色的用户只能执行允许他们执行的操作，避免了恶意操作或权限滥用
为了明确区分不同角色的值，通常我们会使用枚举（enum）来为角色提供固定的值。
enum 是一种特殊的类，用来表示一组固定的常量。
通过将 role 字段设置为枚举类型，我们可以确保角色值仅限于我们定义的固定值，这些值会自动被 TypeORM 映射到数据库字段中。
// 添加角色的枚举类型export enum UserRole {  ADMIN = 'admin',  USER = 'user',  GUEST = 'guest',}@Entity()export class Users {  // ...  // 在 Users 实体中添加 role 字段  @Column({    type: 'enum',    enum: UserRole,    default: UserRole.USER,  // 默认值为普通用户  })  role: UserRole;}
 1.2. 商品
商品实体是平台中与交易直接相关的核心实体，它承载了商品的基本信息、库存管理、定价等重要功能。一个设计良好的商品实体不仅要满足基本的展示需求，还要支持库存管理、订单处理等复杂业务场景。
商品表的作用是提供系统中可供购买的商品清单，记录商品价格和库存。在库存管理方面，当库存减少到零时，商品需要标记为「缺货」或「下架」。
示例，商家上架了一款新商品「智能手表」，库存数量为 100，售价为 200 元，商品类别为「电子产品」。这款商品的信息会存储在 Products 表中，供用户选择和购买。
 1.2.1. 代码实现分析
让我们详细分析 Products 实体的代码实现：
import {  Entity,  PrimaryGeneratedColumn,  Column,  CreateDateColumn,  UpdateDateColumn,  ManyToOne,  OneToMany} from 'typeorm';@Entity()export class Products {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column()  name: string;  @Column('text')  description: string;  @Column('decimal')  price: number;  @Column()  stock: number;  @CreateDateColumn()  created_at: Date;  @UpdateDateColumn()  updated_at: Date;  // ...}
代码实现的特点：
使用 text 类型存储描述，支持长文本内容
使用 decimal 类型存储价格，避免浮点数计算误差
stock 字段直接使用普通的数值类型，便于进行库存相关的计算
商品表的字段及其业务含义如下：
id：主键，用于唯一标识每个商品，类型为 UUID
name：商品名称，帮助用户识别商品
description：商品描述，用于展示商品的详细信息
price：商品价格，定义用户在购买该商品时的成本
stock：商品库存数量，代表当前商品的剩余数量
created_at 和 updated_at：创建时间和更新时间，记录商品上架和更新的时间
 1.2.2. 关联关系分析
Products 实体与其他实体建立了多个关联关系：
import { Categories } from './categories.entity';import { OrderItems } from './order-items.entity';import { CartItems } from './cart-items.entity';import { InventoryLogs } from './inventory-logs.entity';@Entity()export class Products {  // ...  @ManyToOne(() => Categories, category => category.products)  category: Categories;  @OneToMany(() => OrderItems, orderItem => orderItem.product)  orderItems: OrderItems[];  @OneToMany(() => CartItems, cartItem => cartItem.product)  cartItems: CartItems[];  @OneToMany(() => InventoryLogs, inventoryLog => inventoryLog.product)  inventoryLogs: InventoryLogs[];}
商品 - 类别关系（@ManyToOne)一个商品属于一个类别
支持商品分类管理和分类检索
多对一的关系使得类别可以包含多个商品
商品 - 订单项关系（@OneToMany)一个商品可以出现在多个订单中
通过 OrderItems 中间表存储具体的购买数量和价格
支持订单历史查询和销售统计
商品 - 购物车项关系（@OneToMany)一个商品可以被加入多个用户的购物车
通过 CartItems 中间表记录购物车中的商品数量
商品 - 库存日志关系（@OneToMany)记录商品库存变动历史
支持库存追踪和审计
 1.3. 类别
类别实体是商品分类的基础，它帮助我们组织和管理商品，提供更好的浏览和检索体验。一个良好的类别系统能够帮助用户更快地找到所需商品，同时也便于商家进行商品管理。
当平台增加新类别「智能家居」时，它会被添加到 Categories 表中。用户在浏览智能家居产品时，只需点击此类别，即可看到所有相关商品。
 1.3.1. 代码实现分析
import { Entity, PrimaryGeneratedColumn, Column, CreateDateColumn, UpdateDateColumn, OneToMany } from 'typeorm';@Entity()export class Categories {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column()  name: string;  @Column('text')  description: string;  @CreateDateColumn()  created_at: Date;  @UpdateDateColumn()  updated_at: Date;  // ...}
类别表的字段及其业务含义如下：
id：主键，唯一标识类别，类型为 UUID
name：类别名称，例如「电子产品」或「家具」
description：类别描述，进一步解释类别内容
created_at 和 updated_at：创建和更新时间，记录类别的管理信息
 1.3.2. 关联关系分析
Categories 实体主要与 Products 实体建立了一对多的关联关系：
import { Products } from './products.entity';@Entity()export class Categories {  // ...  @OneToMany(() => Products, product => product.category)  products: Products[];}
类别 - 商品关系（@OneToMany)一个类别可以包含多个商品
体现了分类组织的层次结构
支持按类别查询和统计商品
 1.4. 订单
订单是电商系统中最核心的业务实体之一，它记录了交易的全过程，连接了用户、商品、支付等多个业务环节。一个完善的订单系统需要处理订单状态流转、支付流程、商品库存等复杂的业务场景。
当用户下单购买一部智能手表，总价为 200 元，订单状态为「待支付」。在用户支付成功后，订单状态更新为「已支付」。
 1.4.1. 代码实现分析
import {  Entity,  PrimaryGeneratedColumn,  Column,  CreateDateColumn,  UpdateDateColumn,  ManyToOne,  OneToMany} from 'typeorm';@Entity()export class Orders {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column('decimal')  total_price: number;  @Column()  status: string;  @CreateDateColumn()  created_at: Date;  @UpdateDateColumn()  updated_at: Date;  // ...}
id：订单的唯一标识符，使用 UUID 类型
total_price：订单总价，使用 decimal 类型确保精确计算
status：订单状态，用于追踪订单的处理流程
created_at 和 updated_at：记录订单的创建和更新时间
 1.4.2. 关联关系分析
Orders 实体与其他实体建立了多个关联关系：
import { Users } from './users.entity';import { OrderItems } from './order-items.entity';@Entity()export class Orders {  // ...  @ManyToOne(() => Users, user => user.orders)  user: Users;  @OneToMany(() => OrderItems, orderItem => orderItem.order)  orderItems: OrderItems[];}
这些关联关系支持了完整的订单业务流程：
订单 - 用户关系（@ManyToOne)每个订单必须属于一个用户
支持用户订单历史查询
便于进行用户消费分析
订单 - 订单项关系（@OneToMany)一个订单可以包含多个商品
通过 OrderItems 存储具体的商品信息和数量
支持订单明细查询和统计
 1.5. 订单项
订单项实体记录了订单中每个商品的具体购买信息，包括数量、单价和总价等。它不仅连接了订单和商品，还保存了购买时的价格快照，这对于订单历史记录和财务核算都很重要。
 1.5.1. 代码实现分析
import { Entity, PrimaryGeneratedColumn, Column, ManyToOne } from 'typeorm';@Entity()export class OrderItems {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column()  quantity: number;  @Column('decimal')  price: number;  @Column('decimal')  total_price: number;  // ...}
id：订单项的唯一标识符，使用 UUID 类型
quantity：购买数量
price：商品单价的快照，使用 decimal 类型
total_price：该项商品的总价，使用 decimal 类型
 1.5.2. 关联关系分析
OrderItems 实体与其他实体建立了多个多对一的关联关系：
订单项 - 订单关系（@ManyToOne)
 @ManyToOne(() => Orders, order => order.orderItems)order: Orders;
多个订单项属于同一个订单
通过这个关系可以获取订单的完整商品清单
支持订单总价计算和商品统计
订单项 - 商品关系（@ManyToOne）
 @ManyToOne(() => Products, product => product.orderItems)product: Products;
记录该订单项对应的具体商品
支持商品销售统计和分析
可以追踪商品的购买历史
 1.6. 购物车
每个用户都有一个购物车，用于暂存待购买的商品信息。
购物车实体记录了用户在线上选择和加入的商品，是下单前的临时存储。它与订单实体有着类似的结构，但服务于不同的业务场景。
 1.6.1. 代码实现分析
import { Entity, PrimaryGeneratedColumn, CreateDateColumn, UpdateDateColumn, OneToOne, OneToMany } from 'typeorm';import { Users } from './users.entity';import { CartItems } from './cart-items.entity';@Entity()export class Carts {  @PrimaryGeneratedColumn('uuid')  id: string;  @CreateDateColumn()  created_at: Date;  @UpdateDateColumn()  updated_at: Date;  // ...}
代码实现的特点：
使用一对一关系与用户实体关联，确保每个用户只有一个购物车
包含基本的时间戳字段，跟踪购物车的创建和更新
购物车表的字段及其业务含义如下：
id：购物车的唯一标识符，使用 UUID 类型
created_at 和 updated_at：记录购物车的创建和更新时间
 1.6.2. 关联关系分析
Carts 实体与其他实体建立了以下关联关系：
购物车 - 用户关系（@OneToOne）
 @OneToOne(() => Users, user => user.cart)user: Users;
购物车 - 购物车项关系（@OneToMany）
 @OneToMany(() => CartItems, cartItem => cartItem.cart)cartItems: CartItems[];
一个购物车可以包含多个购物车项
通过这个关系可以获取购物车中的商品列表
 1.7. 购物车项
购物车项实体记录了用户在购物车中选择的商品及其数量，它与订单项实体有着类似的结构。
用户在购物车中添加了两部智能手表，购物车项记录该商品 ID、数量为 2，以及关联的购物车 ID。
 1.7.1. 代码实现分析
import { Entity, PrimaryGeneratedColumn, Column, ManyToOne } from 'typeorm';@Entity()export class CartItems {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column()  quantity: number;  // ...}
CartItems 实体的特点：
使用多对一关系连接购物车和商品实体
记录了商品的购买数量，用于计算购物车总价
 1.7.2. 关联关系分析
购物车项 - 购物车关系（@ManyToOne）
 @ManyToOne(() => Carts, cart => cart.cartItems)cart: Carts;
购物车项 - 商品关系（@ManyToOne）
 @ManyToOne(() => Products, product => product.cartItems)product: Products;
 1.8. 支付
支付实体记录了用户在完成下单后的支付信息，包括支付金额、支付状态等。它与订单实体有着直接的关联关系。
 1.8.1. 代码实现分析
import { Entity, PrimaryGeneratedColumn, Column, CreateDateColumn, ManyToOne } from 'typeorm';@Entity()export class Payments {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column('decimal')  amount: number;  @Column()  status: string;  @CreateDateColumn()  created_at: Date;  // ...}
Payments 实体的特点：
使用多对一关系连接订单和用户实体
记录了支付的金额和状态
包含支付的创建时间戳
 1.8.2. 关联关系分析
支付 - 订单关系（@ManyToOne）
 @ManyToOne(() => Orders, order => order.id)order: Orders;
一笔订单可以有多个支付记录
通过这个关系可以获取支付所属的订单信息
支付 - 用户关系（@ManyToOne）
 @ManyToOne(() => Users, user => user.payments)user: Users;
一个用户可以有多笔支付记录
通过这个关系可以获取支付所属的用户信息
 1.9. 地址
地址实体记录了用户的收货地址信息，包括街道、城市、州 / 省、邮编和国家等详细信息。这些信息在用户下单时需要用到，也可以用于生成发货标签等。
 1.9.1. 代码实现分析
import { Entity, PrimaryGeneratedColumn, Column, CreateDateColumn, UpdateDateColumn, ManyToOne } from 'typeorm';@Entity()export class Addresses {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column()  street: string;  @Column()  city: string;  @Column()  state: string;  @Column()  postal_code: string;  @Column()  country: string;  @CreateDateColumn()  created_at: Date;  @UpdateDateColumn()  updated_at: Date;  // ...}
 1.9.2. 关联关系分析
地址 - 用户关系（@ManyToOne）
 @ManyToOne(() => Users, user => user.addresses)user: Users; 
一个用户可以有多个地址信息
通过这个关系可以获取地址所属的用户信息
 1.10. 库存日志
库存日志实体记录了商品库存的变动历史，包括每次库存增减的数量和时间。这些记录对于库存管理、库存盘点和异常排查都非常重要。
 1.10.1. 代码实现分析
import { Entity, PrimaryGeneratedColumn, Column, CreateDateColumn, ManyToOne } from 'typeorm';@Entity()export class InventoryLogs {  @PrimaryGeneratedColumn('uuid')  id: string;  @Column()  change: number;  @CreateDateColumn()  created_at: Date;  // ...}
InventoryLogs 实体的特点：
使用多对一关系与商品实体关联
记录了库存变动数量（change)，正数表示入库，负数表示出库
包含时间戳，记录每次库存变动的具体时间点
 1.10.2. 关联关系分析
库存日志 - 商品关系（@ManyToOne）
 @ManyToOne(() => Products, product => product.inventoryLogs)product: Products;
一个商品可以有多条库存变动记录
通过这个关系可以追踪特定商品的库存变动历史
 2. 创建数据库迁移文件
在开发应用程序时，数据库模式的更新是一项常见而重要的工作，尤其是在应用不断演进的过程中。
假设我们在开发一个应用，并需要更新数据库的表结构，比如添加新字段、修改字段类型等。如何在不丢失现有数据的情况下进行这些修改呢？
TypeORM 可以帮助我们轻松处理数据库操作。它内置了强大的迁移功能，使我们能够定义数据库结构变更并自动应用到数据库中。
 2.1. 添加自定义命令
首先，我们在 package.json 中添加一些脚本来管理 TypeORM 的迁移操作。这些脚本将自动构建项目并运行相应的迁移命令，方便我们快速执行迁移操作：
{  "scripts": {    // ...    "typeorm": "typeorm-ts-node-commonjs -d src/config/data-source.ts",    "migration:initialize": "yarn build && yarn typeorm migration:generate src/migrations/InitialMigration",    "migration:generate": "yarn build && yarn typeorm migration:generate",    "migration:run": "yarn build && yarn typeorm migration:run",    "migration:revert": "yarn build && yarn typeorm migration:revert"  }}
让我们一行一行地分析这些脚本的作用：
typeorm：指定 TypeORM 的配置文件路径（src/config/data-source.ts），它是所有 TypeORM 操作的基础
migration:initialize：生成 InitialMigration 迁移文件
migration:generate：生成新的迁移文件用法：yarn migration:generate src/migrations/xxx
migration:run：执行所有还未运行的迁移，应用到数据库中
migration:revert：撤销上一次迁移，通常用于回滚数据库结构到上一个状态
 2.2. 配置 TypeORM 数据源
接下来，我们需要设置 TypeORM 的数据库配置。
在项目的 src/config/data-source.ts 文件中，我们使用 DataSourceOptions 来定义数据库连接的详细信息。
这里我们还使用了 @nestjs/config 模块来动态读取环境变量，这样在不同环境中可以使用不同的数据库配置。
import { ConfigService } from '@nestjs/config';import { DataSource, DataSourceOptions } from 'typeorm';import { config } from 'dotenv';config();const configService = new ConfigService();const dataSourceOptions: DataSourceOptions = {  type: configService.get('DB_TYPE', 'mysql'),  host: configService.get('DB_HOST'),  port: configService.get('DB_PORT'),  username: configService.get('DB_USER'),  password: configService.get('DB_PASSWORD'),  database: configService.get('DB_NAME'),  synchronize: configService.get('APP_ENV') === 'development',  entities: ['dist/entities/*.entity{.ts,.js}'],  migrations: ['dist/migrations/*{.ts,.js}'],  subscribers: []};export default new DataSource(dataSourceOptions);
type：指定数据库类型，这里我们通过环境变量 DB_TYPE 来设置，默认为 MySQL
host、port、username、password、database：这些参数是数据库连接的必要信息，都可以通过环境变量配置
synchronize：如果 APP_ENV 为 development，则会启用同步模式，让 TypeORM 自动更新数据库表结构注意：生产环境下建议禁用此项
entities 和 migrations：指定实体和迁移文件的路径。TypeORM 会使用这些路径找到相关文件
 2.3. 生成数据库迁移文件
当配置完成后，我们可以通过以下命令来生成用于初始化数据库的迁移文件：
yarn migration:initialize
这条命令会自动构建项目，并使用 TypeORM 生成一个迁移文件（位于 src/migrations，且默认命名为 数字数字数字-InitialMigration.ts）。
这个文件会包含创建、修改或删除表结构的 SQL 语句。例如，如果你添加了一个新的字段，生成的迁移文件就会包含一个 ALTER TABLE 语句。
 2.4. 执行迁移
生成迁移文件后，使用以下命令将其应用到数据库：
yarn migration:run
此命令会检查并执行所有尚未在数据库中应用的迁移。这样可以确保你的数据库结构与最新的迁移文件一致。
 2.5. 回滚迁移
在开发过程中，偶尔可能需要回滚上次迁移，例如在测试或调试时。使用以下命令可以撤销上一次迁移：
yarn migration:revert
TypeORM 会自动识别上次执行的迁移，并撤销相应的更改，恢复到之前的数据库结构。
 3. 设置数据库索引
在开发应用程序时，尤其是当数据库中的数据量越来越大时，查询性能变得至关重要。
数据库索引是一种数据结构，它帮助数据库管理系统（DBMS）高效地检索数据。索引就像书籍中的目录，它可以快速定位到某个数据的位置，而不是扫描整个表。当我们对数据库表进行查询时，索引可以显著提高查询性能，尤其是在处理大量数据时。
在 MySQL 中，索引通常应用于那些需要频繁查询的字段。常见的索引类型有：
主键索引：自动为表的主键字段创建
唯一索引：确保每个值唯一
普通索引：加速数据检索，但不强制唯一性
全文索引：用于加速文本内容的检索
没有索引的情况下，数据库在执行查询时必须扫描整个表，逐行比较数据。这种方式在小型表中可能没什么问题，但在数据量较大时，会导致性能急剧下降。
假设我们的购物平台，数据库中存储了数百万条订单记录。当用户搜索特定订单时，如果没有适当的索引，系统可能会扫描整个订单表来找到匹配的记录。随着数据量增加，查询速度变得非常慢，甚至可能导致系统响应延迟。
使用索引后，数据库不再需要扫描整个表，而是通过索引快速定位到目标数据，从而显著提升查询速度。
在 NestJS 中，我们可以通过 TypeORM 为实体字段添加索引。TypeORM 提供了 @Index() 装饰器，允许我们在数据库表的字段上添加索引。
 3.1. 用户
@Index()@CreateDateColumn()created_at: Date;
在 Users 实体中，我们使用了 @Index() 装饰器来为 created_at 字段添加索引。
在大多数应用程序中，created_at 字段通常用于按照时间排序或进行时间范围查询。
例如，用户可能需要查看某一时间段内的所有注册用户，或者获取最近创建的用户列表。
假设在应用程序中，用户经常执行以下查询：
查询某个时间段内注册的用户。
按照注册时间排序显示用户列表。
如果没有为 created_at 字段添加索引，数据库会需要扫描整个用户表来执行这些查询，这样会导致性能问题。添加索引后，数据库可以通过索引快速查找和排序数据，显著提高查询速度，尤其是在数据量较大的情况下。
 3.1.1. 关系字段为何不需要索引？
这时候就有人问了：「难道像 orders、cart 这些字段，用户就不会查询了吗？如果经常用到，为什么不为它们加个索引呢？」答案是：确实不需要。
在 TypeORM 中，关系字段（比如 orders 和 cart）通常是外键字段，数据库会自动为这些字段创建索引。例如，在 Users 实体中，orders 字段是通过 @OneToMany 与 Orders 实体关联的。虽然我们没有显式地为 orders 字段添加索引，但在 Orders 表中，user 字段作为外键会自动被索引。
这意味着，当我们查询某个用户的所有订单时，数据库会直接利用 Orders 表中自动创建的 user 索引，来加速查询。而我们不需要额外为 orders 字段添加索引，TypeORM 和数据库已经为我们处理好了这部分的优化。
 3.2. 商品
@Index()@Column('decimal')price: number;
price 字段通常会用于以下几种查询：
按照价格范围查询产品，例如查找价格低于某个值的所有产品
按照价格排序，例如将产品列表按价格从低到高或从高到低排序
@Index()@Column()stock: number;
stock 字段通常用于以下查询场景：
查找库存数量为零或低于某个值的产品（例如「缺货」产品或「库存预警」产品）
按照库存数量排序，帮助商家快速查看库存最少的产品
@Index()@CreateDateColumn()created_at: Date;
所有的 created_at 字段都需要添加索引。
 3.3. 支付
@Index()@CreateDateColumn()created_at: Date;
 3.4. 订单
@Index()@Column()status: string;
status 字段通常用于查询订单的状态，例如：
查询某一状态的订单（如「待处理」、「已发货」、「已完成」等）
按照订单状态统计订单数量
@Index()@CreateDateColumn()created_at: Date;
 3.5. 订单项
@Index()@Column()quantity: number;
quantity 字段通常在以下情况中用于查询：
查询具有特定数量的订单项（例如查询某种商品的批量购买情况）
按照数量对订单项进行筛选或排序
 3.6. 类别
@Index()@Column()name: string;
name 字段是分类的唯一标识，用于以下情况：
按类别名称搜索产品类别（例如，用户希望快速找到特定名称的类别）
在名称字段上进行排序或进行自动完成的匹配查询
@Index()@CreateDateColumn()created_at: Date;
 3.7. 购物车
@Index()@CreateDateColumn()created_at: Date;
 3.8. 地址
@Index()@Column()postal_code: string;
在地址系统中，postal_code（邮政编码）字段可能用于以下场景：
按邮政编码筛选地址。例如，在电商系统中，按邮政编码筛选用户地址，以确定是否支持配送
邮政编码的批量统计或区域分析，例如确定特定邮政编码区域的用户密度
@Index()@CreateDateColumn()created_at: Date;
 3.9. 库存日志
@Index()@CreateDateColumn()created_at: Date;
接下来，我们可以使用以下命令生成数据库迁移文件：
yarn migration:generate src/migrations/CreateIndex
然后使用以下命令应用迁移并更新数据库：
yarn migration:run


React + NestJS 购物平台练习【2】后端项目框架搭建
2024-11-04T05:00:00.000Z
搭建基础的 NestJS 项目框架，包括以下内容：
初始化 NestJS 项目
配置环境变量
配置数据库连接
配置 Swagger 文档
设置基础中间件
配置日志系统
 1. 初始化 NestJS 项目
 1.1. 安装 NestJS CLI 工具
全局安装 NestJS 的 CLI 工具：
yarn global add @nestjs/cli
确保全局安装的包路径已被添加到环境变量 PATH 中，否则无法在终端中使用 nest 命令。
可以使用以下命令查看 Yarn 的全局包路径：
yarn global bin
将输出的路径添加到 PATH 中。
 1.2. 创建新的 NestJS 项目
执行以下命令，创建一个名为 shopping-nest-server 的新项目：
nest new shopping-nest-server
运行后，NestJS CLI 会提示选择包管理工具，选择 Yarn，等待其自动安装所需的依赖。
项目生成后，NestJS CLI 默认会在根目录下生成一个 test 目录和一些单元测试文件（.spec.ts）。我暂时不需要测试，所以删去了这些内容。
NestJS CLI 创建的 NestJS 项目会自带 ESLint 和 Prettier，我们只需要将 上一章 配置好的 .prettierrc 复制过来、确保前端后端都遵循相同的代码规范即可：
{  "printWidth": 120,  "tabWidth": 2,  "useTabs": false,  "semi": true,  "singleQuote": true,  "trailingComma": "none",  "bracketSpacing":true,  "bracketSameLine": true,  "arrowParens": "avoid"}
 2. 配置环境变量和配置文件
在实际配置前，我们先来考虑一下，什么是需要配置的：
应用基本配置
APP_PORT：定义应用监听的端口号
APP_ENV：表示当前的应用环境。应用将根据环境做出一些环境特定的设置，比方说日志的详细级别
核心数据库配置
数据库是应用的核心部分，用于存储应用的持久化数据。
DB_TYPE：数据库的类型。我选择使用 mysql 或者 postgres
DB_HOST、DB_PORT、DB_USER、DB_PASSWORD、DB_NAME：这些参数确保应用能连接到正确的数据库实例。不同环境中的数据库配置往往不尽相同，开发环境中可能连接到本地数据库、生产环境中可能连接到远程数据库
缓存配置
缓存系统是提升应用性能的重要手段。
Redis 是一个高效的内存缓存数据库，常用于缓存频繁访问的数据，从而减轻数据库负载、提升响应速度。
REDIS_HOST、REDIS_PORT：让应用访问正确的 Redis 实例
REDIS_PASSWORD 部分 Redis 服务需要密码验证，通过密码可以保障缓存数据的安全
REDIS_DB：指定 Redis 数据库编号，有助于在同一 Redis 实例中隔离不同用途的数据
Elasticsearch 配置
Elasticsearch 是一个分布式搜索和分析引擎，适用于海量数据的全文检索和分析。
ELASTICSEARCH_HOST、ELASTICSEARCH_PORT：定义了 Elasticsearch 服务的位置和端口
ELASTICSEARCH_USERNAME、ELASTICSEARCH_PASSWORD：通过用户名和密码的方式实现对 Elasticsearch 集群的访问控制
ELASTICSEARCH_INDEX：定义应用使用的索引。索引类似于数据库中的表，是 Elasticsearch 存储和查询数据的基本单位
文件存储配置
对于需要上传文件（如用户头像、商品图片等）的应用来说，文件存储服务是不可或缺的。
很多应用会选择云存储服务（如 Amazon S3、Aliyun OSS）或者本地可用的 MinIO 来满足存储需求。
STORAGE_ENDPOINT：指定文件存储服务的 API 端点，便于与远程存储服务连接
STORAGE_ACCESS_KEY 和 STORAGE_SECRET_KEY：用于认证的密钥对，保障文件存储服务的安全访问
STORAGE_BUCKET、STORAGE_REGION：定义存储的目标存储桶和区域位置，以便更合理地管理文件资源，减少延迟
STORAGE_USE_SSL：配置是否启用 HTTPS，以增强数据传输的安全性
JWT 配置
JWT 用于实现用户身份验证和会话管理，是一种轻量的认证方式。
在过去的 React + NestJS + SocketIO 教程文章 中，我们已经讲过了 JWT，感兴趣的可以看看。
JWT_SECRET：用于签发和验证 JWT 的密钥，确保身份认证的安全性。设计一个足够强度的密钥并保持其私密性至关重要
JWT_TOKEN_AUDIENCE：指定 JWT 的受众，即令牌面向的服务或应用。设置受众可以帮助确保令牌仅被指定应用使用，提高认证的安全性
JWT_TOKEN_ISSUER：用于声明 JWT 的发布者，一般设置为认证服务器的标识，确保 JWT 的来源是可信的
JWT_ACCESS_TOKEN_TTL：JWT 访问令牌的有效时间，单位为秒。合理设置过期时间既能提升安全性（防止会话过长导致会话劫持风险），又可避免用户频繁重新登录带来的不便
 2.1. 安装必要依赖
首先安装 @nestjs/config、dotenv 以及数据库驱动和 TypeORM，以支持加载环境变量、进行数据库连接和配置。
yarn add @nestjs/configyarn add dotenv -Dyarn add @nestjs/typeorm typeorm mysql2 # 替换 mysql2 为 pg 以使用 PostgreSQL
@nestjs/config 是 NestJS 提供的官方配置模块，专为加载、管理和验证环境变量而设计
dotenv 是配置模块的底层依赖，通过 .env 文件加载环境变量
TypeORM 是一个 TypeScript 支持的 ORM（对象关系映射），能够与关系型数据库集成
 2.2. 创建环境变量文件
在项目根目录下创建 .env 文件：
# 应用APP_PORT=4000APP_ENV=development# 核心数据库DB_TYPE=mysqlDB_HOST=localhostDB_PORT=3306DB_USER=用户名DB_PASSWORD=密码DB_NAME=数据库名称# Redis 缓存REDIS_HOST=localhostREDIS_PORT=6379REDIS_PASSWORD=密码REDIS_DB=0# ElasticsearchELASTICSEARCH_HOST=localhostELASTICSEARCH_PORT=9200ELASTICSEARCH_USERNAME=用户名ELASTICSEARCH_PASSWORD=密码ELASTICSEARCH_INDEX=products# 文件存储STORAGE_ENDPOINT=STORAGE_ACCESS_KEY=access_key_idSTORAGE_SECRET_KEY=secret_access_keySTORAGE_BUCKET=桶名STORAGE_REGION=STORAGE_USE_SSL=true# JWTJWT_SECRET=secretJWT_TOKEN_AUDIENCE=localhost:4000JWT_TOKEN_ISSUER=localhost:4000JWT_ACCESS_TOKEN_TTL=3600
这里的环境变量覆盖了不同模块所需的配置项，确保各模块配置的灵活性。
 2.3. 引入配置模块和验证
在 AppModule 中配置 @nestjs/config，使用 Joi 对环境变量进行验证，确保每个变量都满足格式要求：
import { Module } from '@nestjs/common';import { ConfigModule } from '@nestjs/config';import { AppController } from './app.controller';import { AppService } from './app.service';import { DatabaseModule } from './database/database.module';import * as Joi from 'joi';@Module({  imports: [    ConfigModule.forRoot({      isGlobal: true, // 让 ConfigModule 全局可用      validationSchema: Joi.object({        APP_PORT: Joi.number().default(4000),        APP_ENV: Joi.string().valid('development', 'production', 'test').default('development'),        // 核心数据库        DB_TYPE: Joi.string().valid('mysql', 'postgres').default('mysql'),        DB_HOST: Joi.string().required(),        DB_PORT: Joi.number().default(3306),        DB_USER: Joi.string().required(),        DB_PASSWORD: Joi.string().required(),        DB_NAME: Joi.string().required(),        // Redis 缓存        REDIS_HOST: Joi.string().required(),        REDIS_PORT: Joi.number().default(6379),        REDIS_PASSWORD: Joi.string().allow(''),        REDIS_DB: Joi.number().default(0),        // Elasticsearch        ELASTICSEARCH_HOST: Joi.string().required(),        ELASTICSEARCH_PORT: Joi.number().default(9200),        ELASTICSEARCH_USER: Joi.string().required(),        ELASTICSEARCH_PASSWORD: Joi.string().required(),        ELASTICSEARCH_INDEX: Joi.string().required(),        // 文件存储        STORAGE_ENDPOINT: Joi.string().allow(''),        STORAGE_ACCESS_KEY: Joi.string().required(),        STORAGE_SECRET_KEY: Joi.string().required(),        STORAGE_BUCKET: Joi.string().required(),        STORAGE_REGION: Joi.string().allow(''),        STORAGE_USE_SSL: Joi.boolean().default(true),        // JWT        JWT_SECRET: Joi.string().required(),        JWT_TOKEN_AUDIENCE: Joi.string().required(),        JWT_TOKEN_ISSUER: Joi.string().required(),        JWT_ACCESS_TOKEN_TTL: Joi.number().default(3600)      })    }),    DatabaseModule  ],  controllers: [AppController],  providers: [AppService]})export class AppModule {}
isGlobal：将配置模块设为全局模块，避免在其他模块中重复引入
validationSchema：通过 Joi 验证环境变量的值，确保值类型与业务需求匹配；例如 DB_HOST 需要是字符串，APP_PORT 应为数值，且数据库和 JWT 密钥都必须存在
Joi 是一个 JavaScript 数据验证库，通常用来确保应用中的数据符合特定的规则或格式。
 2.3.1. 基本用法
Joi 提供了一个简单的链式 API 来定义验证规则。验证的流程一般是：定义 schema（验证规则） -> 验证数据 -> 获取结果或错误。
const Joi = require('joi');// 定义 schemaconst schema = Joi.object({  name: Joi.string().min(3).max(30).required(),  age: Joi.number().integer().min(0).max(120),  email: Joi.string().email()});// 验证数据const result = schema.validate({ name: 'Alice', age: 25, email: 'alice@example.com' });// 检查结果if (result.error) {  console.log(result.error.details);} else {  console.log(result.value);}
 2.3.2. 基本类型验证
Joi 支持的基本类型包括：string、number、boolean、array、object 等。每种类型可以组合其他规则，如最小/最大值、必填/选填、格式限制等。
字符串验证
Joi.string()  // 定义为字符串类型Joi.string().min(3)  // 最小长度Joi.string().max(30)  // 最大长度Joi.string().email()  // 必须是电子邮箱格式Joi.string().regex(/^[a-zA-Z0-9]{3,30}$/)  // 使用正则表达式验证格式
数字验证
Joi.number()  // 定义为数字类型Joi.number().integer()  // 必须是整数Joi.number().min(0)  // 最小值Joi.number().max(100)  // 最大值Joi.number().positive()  // 必须是正数Joi.number().negative()  // 必须是负数
布尔值验证
Joi.boolean()  // 定义为布尔类型
数组验证
Joi.array()  // 定义为数组类型Joi.array().items(Joi.number())  // 数组中每项都必须是数字Joi.array().min(1).max(5)  // 数组长度限制Joi.array().unique()  // 数组中的每个元素必须唯一
对象验证
Joi.object({  username: Joi.string().required(),  password: Joi.string().min(8).required(),})
 2.3.3. 条件验证
条件验证允许定义复杂的规则，如基于字段值的条件或逻辑分支。
when 条件验证：
const schema = Joi.object({  password: Joi.string().min(8).required(),  confirmPassword: Joi.string().valid(Joi.ref('password')).when('password', {    is: Joi.exist(),  // 如果 password 存在……    then: Joi.required(),  // ……confirmPassword 也是必填    otherwise: Joi.forbidden()  // 否则不允许出现 confirmPassword  })});
 2.3.4. 嵌套对象和数组验证
Joi 允许定义嵌套结构，如对象嵌套和数组嵌套。
嵌套对象
const schema = Joi.object({  user: Joi.object({    name: Joi.string().required(),    age: Joi.number().min(0)  }).required()});
嵌套数组
const schema = Joi.array().items(  Joi.object({    id: Joi.number().required(),    name: Joi.string().required()  }));
 2.3.5. 自定义验证器
Joi 支持自定义验证函数，用于更复杂的场景。
const schema = Joi.string().custom((value, helpers) => {  if (!/^[a-zA-Z]+$/.test(value)) {    return helpers.error('any.invalid');  // 返回一个自定义错误  }  return value;  // 验证通过}, 'Custom alphabet validation');
 2.3.6. 配合 NestJS 使用
在 NestJS 中，可以结合 @nestjs/config 模块来使用 Joi 验证配置文件。
import { Module } from '@nestjs/common';import { ConfigModule } from '@nestjs/config';import * as Joi from 'joi';@Module({  imports: [    ConfigModule.forRoot({      validationSchema: Joi.object({        // 假设有核心数据库的配置        DB_HOST: Joi.string().required(),        DB_PORT: Joi.number().default(5432),      })    })  ],})export class AppModule {}
 2.3.7. 错误处理与自定义错误消息
Joi 会在验证失败时返回详细的错误信息，可以自定义错误消息。
const schema = Joi.object({  name: Joi.string().min(3).required().messages({    'string.base': `"name" should be a type of 'text'`,    'string.empty': `"name" cannot be an empty field`,    'string.min': `"name" should have a minimum length of {#limit}`,    'any.required': `"name" is a required field`  })});
 2.4. 使用配置
作为一个使用 ConfigService 的例子，我们将从 .env 中读取 APP_PORT 的值，并将其作为应用的启动端口。
import { NestFactory } from '@nestjs/core';import { ConfigService } from '@nestjs/config';import { AppModule } from './app.module';async function bootstrap() {  const app = await NestFactory.create(AppModule);  const configService = app.get(ConfigService);  const port = configService.get('APP_PORT') || 4000;  await app.listen(port);}bootstrap();
运行 nest start 来查看是否有任何问题。
 3. 设置数据库连接
首先，确保自己的本机环境中有安装 MySQL 或者 PostgreSQL。
安装教程请自行在网上搜索，本篇文档将只会使用 8.0.40 MySQL Community。
挖坑：未来可能会添加支持其他数据库的功能。
 3.1. 配置 MySQL
打开 MySQL CLI（或者使用 mysql -u root -p 来进行连接）
创建数据库：
 CREATE DATABASE 数据库名称;
数据库名称 要匹配 .env 中的：
 DB_NAME=数据库名称
创建用户：
 CREATE USER '用户名'@'localhost' IDENTIFIED BY '密码';
这里的内容要匹配 .env 中的这一段内容：
 DB_USER=用户名DB_PASSWORD=密码
设置权限：
 GRANT ALL PRIVILEGES ON 数据库名称.* TO '用户名'@'localhost';FLUSH PRIVILEGES;
设置完后可以测试一下：
 mysql -u 用户名 -p -h localhost -P 3306 数据库名称
 3.2. 创建 DatabaseModule
在 NestJS 项目中，集中管理数据库连接的配置非常重要，尤其是在需要支持多种环境（如开发、测试、生产）时。
创建 DatabaseModule 能让我们将数据库的配置代码分离出来，以便在不同的环境中灵活调整配置，比如使用 ConfigService 来获取环境变量。
通过 TypeOrmModule.forRootAsync 方法，我们可以使用异步的方式配置 TypeORM。这样可以确保数据库配置在应用初始化时依赖于环境变量，如 DB_HOST、DB_USER、DB_PASSWORD 等，从而增强配置的灵活性和安全性。
import { Module } from '@nestjs/common';import { TypeOrmModule } from '@nestjs/typeorm';import { ConfigModule, ConfigService } from '@nestjs/config';@Module({  imports: [    ConfigModule,    TypeOrmModule.forRootAsync({      imports: [ConfigModule],      inject: [ConfigService],      useFactory: (configService: ConfigService) => ({        type: configService.get<'mysql' | 'postgres'>('DB_TYPE'),        host: configService.get('DB_HOST'),        port: configService.get('DB_PORT'),        username: configService.get('DB_USER'),        password: configService.get('DB_PASSWORD'),        database: configService.get('DB_NAME'),        autoLoadEntities: true,        synchronize: configService.get('APP_ENV') === 'development'      })    })  ]})export class DatabaseModule {}
ConfigService：用于从环境变量获取配置，确保 DB_TYPE 等参数的灵活性
forRootAsync：动态配置 TypeOrmModule，适用于需要依赖环境变量初始化的模块
autoLoadEntities: true：TypeORM 会自动加载应用中定义的所有实体。这让我们可以在项目中自由地添加新的实体，而不需要每次手动导入
synchronize：将其设置为 true 会在开发环境中自动同步数据库表结构，以便在本地开发时快速响应数据结构的修改。但在生产环境中，建议关闭 synchronize，以防止意外数据丢失或表结构破坏
 4. 配置 Swagger 文档
在现代 Web 开发中，API 文档对于开发人员和用户来说都是至关重要的，特别是在团队协作中，清晰的 API 文档可以大大提高开发效率。
NestJS 提供了内置的 Swagger 支持，允许我们快速生成符合 OpenAPI 标准的文档，为用户提供更好的接口可视化。
OpenAPI 是一种用于描述 RESTful API 的规范，它提供了一种标准化的格式，用于定义 API 的端点、请求、响应、认证等内容。
它的前身是 Swagger 规范，因此你可能听过 Swagger 和 OpenAPI 这两个词被混用。
OpenAPI 的主要目标是使 API 设计、文档、测试和集成过程更为高效和一致。
 4.1. 安装依赖
首先，我们需要安装 @nestjs/swagger 和 swagger-ui-express 两个模块。
@nestjs/swagger 提供了 NestJS 对 Swagger 的支持
swagger-ui-express 是 Swagger UI 的依赖包，用于在浏览器中显示 API 文档
在项目根目录下运行以下命令来安装它们：
yarn add @nestjs/swagger swagger-ui-express
 4.2. 配置 Swagger
打开 main.ts 并添加以下代码：
// ...import { DocumentBuilder, SwaggerModule } from '@nestjs/swagger';async function bootstrap() {  // ...  const swaggerConfig = new DocumentBuilder()    .setTitle('API 文档')    .setDescription('Shopping-Nest 的 API 文档')    .setVersion('1.0')    .addBearerAuth()    .build();  const document = SwaggerModule.createDocument(app, swaggerConfig);  SwaggerModule.setup('api-docs', app, document);  // ...}
在这里，我们使用 DocumentBuilder 来创建 Swagger 文档的基本信息。常见的配置项有：
.setTitle()：设置 API 文档的标题
.setDescription()：提供 API 的描述信息
.setVersion()：指定 API 的版本号
.addBearerAuth()：如果 API 需要 JWT 认证（通常用于保护 API），可以添加 Bearer 认证支持
SwaggerModule.setup() 方法将 Swagger UI 绑定到指定的路由路径（这里是 /api-docs），之后，我们可以通过访问 http://localhost:APP_PORT/api-docs 来查看生成的文档。
 4.3. 如何使用 Swagger
在我们完成 Swagger 的基础配置后，接下来的步骤将详细介绍如何利用 Swagger 注释来生成清晰的 API 文档。这一部分将涵盖如何为控制器、DTO（数据传输对象）和请求参数添加 Swagger 装饰器，以便 Swagger 能够生成准确且全面的 API 文档。
 4.3.1. 为控制器添加注释
在 NestJS 中，控制器负责处理客户端请求并返回响应。我们可以使用 Swagger 提供的装饰器为控制器中的每个方法添加注释，以描述其功能、请求参数和返回结果。
import { Controller, Get, Post, Body } from '@nestjs/common';import { ApiTags, ApiOperation, ApiResponse } from '@nestjs/swagger';import { CreateUserDto } from './dto/create-user.dto';@ApiTags('Users')  // 给控制器添加标签@Controller('users')export class UserController {    @Post()  @ApiOperation({ summary: 'Create a new user' })  // 描述此 API 的作用  @ApiResponse({ status: 201, description: 'The user has been successfully created.' })  // 201 状态响应  @ApiResponse({ status: 400, description: 'Invalid input data.' })  // 400 状态响应  create(@Body() createUserDto: CreateUserDto) {    return 'This action adds a new user';  }  @Get()  @ApiOperation({ summary: 'Retrieve a list of users' })  // 描述此 API 的作用  @ApiResponse({ status: 200, description: 'A list of users.' })  // 200 状态响应  getAllUsers() {    return [{ id: 1, name: 'John Doe' }];  }}
 4.3.2. 为 DTO 添加注释
DTO（数据传输对象）用于定义请求和响应的结构。使用 Swagger 的 @ApiProperty 装饰器，可以清晰地说明每个字段的含义和要求。
import { ApiProperty } from '@nestjs/swagger';export class CreateUserDto {  @ApiProperty({ description: 'The name of the user' })  // 描述 name 字段  name: string;  @ApiProperty({ description: 'The age of the user', minimum: 1 })  // 描述 age 字段并设置最小值  age: number;  @ApiProperty({ description: 'The email of the user', required: true })  // 描述 email 字段  email: string;}
在上面的例子中，CreateUserDto 包含了三个属性：name、age 和 email。每个属性都使用了 @ApiProperty 装饰器来提供详细描述，并且可以设置字段的其他约束（如是否必填、类型等）。
 4.3.3. 为请求参数添加注释
如果你的 API 需要接受路径参数、查询参数或请求体中的数据，Swagger 也提供了相关的装饰器来帮助描述这些参数。
import { Controller, Get, Param } from '@nestjs/common';import { ApiParam } from '@nestjs/swagger';@Controller('users')export class UserController {  @Get(':id')  @ApiOperation({ summary: 'Retrieve a user by ID' })  // 描述此 API 的作用  @ApiParam({ name: 'id', required: true, description: 'The ID of the user to retrieve', type: Number })  // 描述路径参数  getUserById(@Param('id') id: number) {    return { id, name: 'John Doe' };  // 示例返回  }}
在这个示例中，@ApiParam 用于描述路径参数 id。它帮助用户理解这个参数是必须的，且应该是一个数字。
 5. 设置基础中间件
在现代 Web 开发中，处理安全性、请求速率限制、响应压缩以及自定义日志记录是打造可靠、高效应用的基础。
NestJS 提供了简单灵活的中间件配置支持，通过整合 helmet、@nestjs/throttler、compression 等库，开发者可以轻松地实现这些功能。
 5.1. 添加 CORS 支持
首先，我们需要确保应用支持跨域请求（CORS），特别是在前后端分离的情况下。以下是启用和配置 CORS 的方法：
async function bootstrap() {  // ...  const corsOrigin = configService.get('CORS_ORIGIN');  app.enableCors({    origin: corsOrigin,    methods: 'GET,POST',    credentials: true,  });  // ...}
在 .env 中添加：
CORS_ORIGIN=http://localhost:3000
使用 http://localhost:3000 是因为 React 本地环境默认运行在 localhost:3000。
 5.2. 增强安全性
helmet 是一组帮助设置安全 HTTP 头的中间件，能够防范常见的 Web 攻击（例如，XSS 攻击和点击劫持）。
安装 helmet 库：
yarn add helmet
开启 helmet 保护：
import helmet from 'helmet';async function bootstrap() {  // ...    app.use(helmet());  // ...}
通过这段简单的代码，helmet 会自动添加一组常用的安全头（以下信息来自于 npm）：
Content-Security-Policy：一个强大的允许清单，控制页面上可以发生的操作，有助于缓解多种攻击
Cross-Origin-Opener-Policy：帮助页面实现进程隔离
Cross-Origin-Resource-Policy：阻止其他网站跨域加载您的资源
Origin-Agent-Cluster：将进程隔离改为基于源的方式
Referrer-Policy：控制 Referer 请求头
Strict-Transport-Security：告知浏览器优先使用 HTTPS
X-Content-Type-Options：避免 MIME 类型嗅探
X-DNS-Prefetch-Control：控制 DNS 预取
X-Download-Options：强制将下载的文件保存到本地（仅适用于 Internet Explorer）
X-Frame-Options：传统的标头，用于防范点击劫持攻击
X-Permitted-Cross-Domain-Policies：控制 Adobe 产品（如 Acrobat）的跨域行为
X-Powered-By：关于 Web 服务器的信息，已移除，以防止简单攻击利用该信息
X-XSS-Protection：传统的标头，旨在防止 XSS 攻击，但通常效果不佳，因此 Helmet 将其禁用
 5.3. 压缩响应
压缩响应能够有效减少传输的数据量，提升页面加载速度。
安装 compression 库：
yarn add compression
配置压缩的级别和触发条件：
import * as compression from 'compression';async function bootstrap() {  // ...  const compressionLevel = configService.get('COMPRESSION_LEVEL') || 6;  const compressionThreshold = configService.get('COMPRESSION_THRESHOLD') || 1024;  app.use(    compression({      level: compressionLevel,      threshold: compressionThreshold,    })  );  // ...}
在 .env 中添加：
# 响应压缩COMPRESSION_LEVEL=6COMPRESSION_THRESHOLD=1024
在上面的代码中，level 设置了压缩级别（范围从 0-9，数字越大压缩越强，但 CPU 负荷越高），而 threshold 设置了触发压缩的响应体积阈值（单位为字节）。
 5.4. 限制请求速率
防止滥用 API 资源是每个 Web 应用的核心需求之一。我们可以使用 @nestjs/throttler 模块对请求速率进行限制，确保服务不会被大量请求淹没。
yarn add @nestjs/throttler
我们在 AppModule 中通过 ThrottlerModule.forRootAsync 配置速率限制。利用 ConfigService 从 .env 文件中获取 ttl（时间窗口）和 limit（最大请求数）参数：
import { ThrottlerModule, ThrottlerModuleOptions } from '@nestjs/throttler';@Module({  imports: [    // ...    ThrottlerModule.forRootAsync({      inject: [ConfigService],      useFactory: (configService: ConfigService): ThrottlerModuleOptions => [        {          ttl: configService.get('THROTTLE_TTL') || 60,          limit: configService.get('THROTTLE_LIMIT') || 10        }      ]    }),  ],})
在 .env 中添加：
# 速率限制THROTTLE_TTL=60THROTTLE_LIMIT=10
 5.4.1. 使用例子
配置后，系统会自动为所有 API 路由设置速率限制。也可以在特定控制器或路由中通过 @Throttle 装饰器进行覆盖：
import { Controller, Get } from '@nestjs/common';import { Throttle } from '@nestjs/throttler';@Controller('test')export class TestController {  @Throttle(5, 10)  // 每 10 秒最多 5 个请求  @Get()  testRoute() {    return "Testing rate limiting";  }}
 5.5. 自定义日志记录
为了记录请求信息，我们可以实现一个简单的 LoggerMiddleware，并在 AppModule 中配置它：
import { Injectable, NestMiddleware } from '@nestjs/common';import { Request, Response, NextFunction } from 'express';@Injectable()export class LoggerMiddleware implements NestMiddleware {  use(req: Request, res: Response, next: NextFunction) {    console.log(`Request... ${req.method} ${req.url}`);    next();  }}
在 AppModule 中使用 configure 方法应用此中间件：
import { MiddlewareConsumer, Module, NestModule } from '@nestjs/common';import { LoggerMiddleware } from './middlewares/logger.middleware';@Module({  imports: [/* 其他模块 */],})export class AppModule implements NestModule {  configure(consumer: MiddlewareConsumer) {    consumer.apply(LoggerMiddleware).forRoutes('*');  }}
这样，每次请求都会在控制台输出请求方法和 URL 路径，帮助我们跟踪请求流向和响应情况。
启动 NestJS 项目，在浏览器中访问 localhost:APP_PORT（或者默认的 localhost:4000），就能在终端中看到 Request... GET / 的字眼。
 5.6. 设置全局错误处理
为了统一错误响应格式，可以创建自定义异常过滤器来捕获异常，并返回标准化的错误信息。
我们在项目中定义 HttpExceptionFilter 类，并将其注册为全局过滤器：
import { ExceptionFilter, Catch, ArgumentsHost, HttpException, HttpStatus } from '@nestjs/common';@Catch()export class HttpExceptionFilter implements ExceptionFilter {  catch(exception: unknown, host: ArgumentsHost) {    const ctx = host.switchToHttp();    const response = ctx.getResponse();    const request = ctx.getRequest();    const status = exception instanceof HttpException ? exception.getStatus() : HttpStatus.INTERNAL_SERVER_ERROR;    const errorResponse = {      statusCode: status,      timestamp: new Date().toISOString(),      path: request.url,      message: exception instanceof HttpException ? exception.getResponse() : 'Internal server error'    };    response.status(status).json(errorResponse);  }}
接着在 main.ts 中注册过滤器：
import { HttpExceptionFilter } from './filters/http-exception.filter';async function bootstrap() {  // ...  app.useGlobalFilters(new HttpExceptionFilter());  // ...}
通过此过滤器，所有未处理的异常都会以标准格式返回。
 6. 配置日志系统
在开发和运维中，日志记录是至关重要的一部分。通过详细的日志记录，我们可以更好地了解应用的运行状态、排查错误，甚至帮助团队进行性能优化。
在开发或生产环境中，可能会遇到以下问题：
控制台日志输出过于混乱：控制台日志输出没有明显的视觉区分，开发者难以快速找到关键信息
文件日志管理不当：日志文件没有分目录管理，日志存储时间不固定，且文件体积容易过大
日志轮转：没有对日志文件进行按日期轮换，容易导致单个日志文件过大，不利于维护
 6.1. 安装依赖
我们首先需要安装 chalk、nest-winston、winston 和 winston-daily-rotate-file 这些依赖。
yarn add chalk@^4 nest-winston winston winston-daily-rotate-file
注意：由于我的 NestJS 项目使用的是 CommonJS 模块系统，和使用 ESM 的 chalk@5 不兼容，所以我采用的最简单直接的方法就是降级到 chalk@4。
 6.2. 配置 winston 日志文件
在 NestJS 项目中创建一个 winston.logger.ts 文件，用于配置 winston 的日志记录选项，包括日志等级、日志格式、文件轮转等。
 6.2.1. 配置日志目录
我们将设置不同的日志目录来分别存储错误日志、警告日志和常规应用日志。
使用 fs 来检查目录是否存在，不存在时自动创建：
import * as fs from 'fs';import * as path from 'path';const logDirectories = ['logs/errors', 'logs/warnings', 'logs/app'];logDirectories.forEach(dir => {  const fullPath = path.join(__dirname, '..', '..', dir);  try {    if (!fs.existsSync(fullPath)) {      console.log(`Creating directory at: ${fullPath}`);      fs.mkdirSync(fullPath, { recursive: true });    }  } catch (error) {    console.error(`Error creating directory ${fullPath}:`, error);  }});
这段代码创建了 logs/errors、logs/warnings 和 logs/app 三个目录，用于分别保存错误、警告和常规日志。
 6.2.2. 定义日志颜色
接下来，通过 chalk 为不同的日志级别定义颜色。这样在控制台输出时，不同的日志级别会有明显的颜色区分：
import * as chalk from 'chalk';const getChalkColor = (level: string): chalk.Chalk => {  switch (level) {    case 'error':      return chalk.red;    case 'warn':      return chalk.yellow;    case 'info':      return chalk.green;    case 'debug':      return chalk.blue;    case 'verbose':      return chalk.cyan;    default:      return chalk.white;  }};
这样做的好处是，可以根据日志等级设置不同颜色，从而在控制台中快速识别重要的日志信息。
 6.2.3. 配置 winston 日志选项
接下来，我们配置 winston 的核心功能，包括日志格式、日志文件轮转和控制台输出：
import { createLogger, format, transports } from 'winston';import * as DailyRotateFile from 'winston-daily-rotate-file';const winstonLogger = createLogger({  format: format.combine(format.timestamp(), format.errors({ stack: true }), format.splat(), format.json()),  defaultMeta: { service: 'log-service' },  transports: [    new DailyRotateFile({      filename: path.join(__dirname, '..', '..', 'logs/errors/error-%DATE%.log'),      datePattern: 'YYYY-MM-DD-HH-mm-ss',      zippedArchive: true,      maxSize: '20m',      maxFiles: '14d',      level: 'error'    }),    new DailyRotateFile({      filename: path.join(__dirname, '..', '..', 'logs/warnings/warning-%DATE%.log'),      datePattern: 'YYYY-MM-DD-HH-mm-ss',      zippedArchive: true,      maxSize: '20m',      maxFiles: '14d',      level: 'warn'    }),    new DailyRotateFile({      filename: path.join(__dirname, '..', '..', 'logs/app/app-%DATE%.log'),      datePattern: 'YYYY-MM-DD-HH-mm-ss',      zippedArchive: true,      maxSize: '20m',      maxFiles: '14d'    }),    new transports.Console({      format: format.combine(        format.colorize(),        format.simple(),        format.printf(info => {          const level = info.level.toLowerCase();          const chalkColor = getChalkColor(level);          return `${chalkColor(`${info.timestamp} - ${info.level}:`)} ${info.message}`;        })      ),      level: 'debug'    })  ]});export default winstonLogger;
这段配置实现了以下几个功能：
DailyRotateFile：设置了日志文件的轮转，每个日志类型（错误、警告、应用）都将按日期命名并存储
控制台输出：控制台输出带有颜色区分，并包含时间戳和日志级别，便于快速读取
日志格式：定义了 json 格式日志输出，并包含 timestamp 和 stack 信息
 6.3. 引入日志配置
在 AppModule 中通过 WinstonModule 引入 winstonLogger，使日志系统能够全局生效：
import { WinstonModule } from 'nest-winston';import winstonLogger from './loggers/winston.logger';@Module({  imports: [    // ...    WinstonModule.forRoot({      transports: winstonLogger.transports,      format: winstonLogger.format,      defaultMeta: winstonLogger.defaultMeta,      exitOnError: false    })  ]});
通过 WinstonModule.forRoot() 配置，我们将之前定义的 winstonLogger 作为全局日志管理器，使 NestJS 自动将应用日志转发到 winston。
 6.4. 应用日志系统
为了启用配置的日志系统，我们需要在 main.ts 中将其应用到应用程序：
import { WINSTON_MODULE_NEST_PROVIDER } from 'nest-winston';async function bootstrap() {  // ...    app.useLogger(app.get(WINSTON_MODULE_NEST_PROVIDER));  // ...}
这样就将 winston 配置的日志记录器注入到应用中，使日志管理器可以通过 NestJS 的日志 API 来记录日志。
 6.5. 修改 LoggerMiddleware
最后，我们来修改一下 LoggerMiddleware，将其记录下每个请求的详细信息，包括：
请求方法
URL
IP
HTTP 版本
状态码
响应时间等
这在调试和性能分析时尤为有用。
import { Injectable, Logger, NestMiddleware } from '@nestjs/common';import { Request, Response, NextFunction } from 'express';import * as dayjs from 'dayjs';@Injectable()export class LoggerMiddleware implements NestMiddleware {  private logger = new Logger();  use(req: Request, res: Response, next: NextFunction) {    const start = Date.now();    const { method, originalUrl, ip, httpVersion, headers } = req;    const { statusCode } = res;    res.on('finish', () => {      const end = Date.now();      const duration = end - start;      const logFormat = `${dayjs().valueOf()} ${method} ${originalUrl} HTTP/${httpVersion} ${ip} ${statusCode} ${duration}ms ${headers['user-agent']}`;      if (statusCode >= 500) {        this.logger.error(logFormat, originalUrl);      } else if (statusCode >= 400) {        this.logger.warn(logFormat, originalUrl);      } else {        this.logger.log(logFormat, originalUrl);      }    });    next();  }}
事件监听：使用 finish 事件来确保所有响应数据都已发送
日志格式：每个请求记录的格式包括请求时间、请求方法、URL、IP、状态码、响应耗时等信息
自动区分日志级别：根据响应的状态码自动设置日志等级错误状态码（500+）记录为 error
客户端错误（400+）记录为 warn
其他成功请求则都记录为 log


React + NestJS 购物平台练习【1】前端项目框架搭建
2024-10-29T04:00:00.000Z
在现代电子商务发展迅速的今天，构建一个高效、易用的购物平台是开发者的一项关键技能。
该系列是全栈实践新坑，使用 React 和 NestJS 的技术栈、从零开始开发一个完整的购物平台（其实是先前开的几个全栈实践坑都让我意识到自己基础实力不足）。
 1. 初始化 React + TypeScript 项目
使用以下命令创建 React 项目：
 yarn create react-app shopping-nest --template typescript
导航至 shopping-nest 目录：
 cd shopping-nest
使用 Yarn 安装依赖：
 // 安装 ESLint 和 Prettier 相关依赖yarn add @typescript-eslint/eslint-plugin @typescript-eslint/parseryarn add -D eslint prettier eslint-config-prettier eslint-plugin-prettieryarn add -D eslint-config-react-app// 安装 react-router-domyarn add react-router-dom @types/react-router-dom// 安装 axiosyarn add axios// 安装 TailwindCSS 相关依赖yarn add tailwindcss postcss autoprefixer// 安装 UI 组件和图标库yarn add @headlessui/reactyarn add lucide-react
运行 yarn run start 检查一下是否会出问题。
 2. 配置 ESLint 和 Prettier
我使用的是 Jetbrains WebStorm，记得要更新到 2024 的版本喔。
ESLint 的版本为 9.13.0。
Prettier 的版本为 3.3.3。
 2.1. 配置 ESLint
运行以下命令：
 npx eslint --init
根据自己的习惯选择。
生成的 mjs 配置文件差不多如下，我自己修改了 files 值为 src 目录下的文件。
 import globals from "globals";import pluginJs from "@eslint/js";import tseslint from "typescript-eslint";import pluginReact from "eslint-plugin-react";export default [  {files: ["src/**/*.{js,mjs,cjs,ts,jsx,tsx}"]},  {languageOptions: { globals: globals.browser }},  pluginJs.configs.recommended,  ...tseslint.configs.recommended,  pluginReact.configs.flat.recommended,];
可以查看 ESLint 官方文档 或者 TypeScript-ESLint 文档 自行修改。我自己就保留默认的了。
 2.2. 配置 Prettier
在项目目录处创建 .prettierrc 文件一个（项目目录这里默认为 package.json 所在的目录）。
除了查看 Prettier 官方文档 自己填写外，还可以使用一些工具生成 Prettier 配置内容。
我这里用了 Prettier Config Generator 生成：
 {  "printWidth": 120,  "tabWidth": 2,  "useTabs": false,  "semi": true,  "singleQuote": true,  "trailingComma": "none",  "bracketSpacing":true,  "bracketSameLine": true,  "arrowParens": "avoid"}
 3. 配置 Tailwind CSS
 3.1. 安装并初始化 TailWind CSS 配置
在项目目录下使用以下命令来生成 tailwind.config.js 和 postcss.config.js：
npx tailwindcss init -p
然后修改 tailwind.config.js 的内容，将 content 配置为监控 src 文件夹下的所有文件，以便在这些文件中应用 TailWind 的样式：
/** @type {import('tailwindcss').Config} */export default {  content: [],  theme: {    extend: {},  },  plugins: []};
在 src/index.css 文件的顶部添加以下内容，导入 TailWind 的核心样式、组件和工具：
@tailwind base;@tailwind components;@tailwind utilities;
 3.2. 安装并配置 daisyUI 组件库
为了方便开发，安装 daisyUI 组件库，它提供了丰富的组件和自定义主题功能：
yarn add daisyui
然后在 tailwind.config.js 文件中引入 daisyUI 插件：
import daisyui from "daisyui";// ...export default {  // ...  plugins: [    daisyui,  ],  daisyui: {}}
对于 daisyUI 的配置，可以根据其 文档 进行修改。
我安装 daisyUI 还有一个目的，那就是其自定义主题的功能。
在 daisyUI 的 主题生成器 里，你可以选择自己设计一套颜色方案，或者说随机出一套颜色方案。该页面中还有预览页面可供参考。
我对颜色不敏感，设计能力也很遭殃。这是我随机出的：
export default {  // ...  daisyui: {    themes: [      {        mytheme: {          "primary": "#60a5fa",          "primary-content": "#030a15",          "secondary": "#00b7ac",          "secondary-content": "#000c0b",          "accent": "#d68900",          "accent-content": "#100700",          "neutral": "#182f19",          "neutral-content": "#ccd1cc",          "base-100": "#32253a",          "base-200": "#2a1f31",          "base-300": "#221928",          "base-content": "#d2cfd4",          "info": "#00a7c9",          "info-content": "#000a0f",          "success": "#67c400",          "success-content": "#040e00",          "warning": "#f97316",          "warning-content": "#150500",          "error": "#dc2626",          "error-content": "#ffd9d4",        }      }    ]  }}
 3.3. 配置 PostCSS
根据 PostCSS 官方 说的：
PostCSS 是一种利用 JS 插件转换样式的工具。
这些插件可以检查 CSS、支持变量和混合体、转译未来的 CSS 语法、内联图片等。
postcss.config.js 的初始配置如下：
export default {  plugins: {    tailwindcss: {},    autoprefixer: {},  },};
目前这是基本的配置。如果需要更多 PostCSS 功能，可以根据需求进一步配置。
 4. 设置路由基础结构
路由系统是管理不同 URL 对应显示不同页面内容的机制。
 4.1. 创建统一布局
作为开发者，在构建 Web 应用时，创建一个统一的布局非常重要。因为它能够为用户提供一致的界面的导航体验。
在大多数应用中，我们会有一些固定的部分，比方说导航栏、页脚，以及一个用于动态展示内容的区域。
import React from 'react';import { Outlet } from 'react-router-dom';
首先引入 Outlet，它是 react-router-dom 提供的一个工具，允许在布局中插入不同的内容。
通过 Outlet，我们可以渲染由路由定义的组件，也就是首页啦、关于页这些，也不需要每次都重写导航和布局。
const MainLayout = () => {  return (                            {/* TODO: 导航内容 */}        
      
用 
 标签来定义页面的头部，这里我之后会引入导航栏组件，先放个 TODO 马克一下。
                                
      
      );};
接下来是 
 标签，它是页面的核心内容区域。
 会根据当前路由，动态渲染不同的组件。在开发中，这个设计的好处是我们可以轻松地切换页面，并保持一致的布局框架。
 4.2. 路由配置
在单页面应用，也就是 SPA 中，路由是关键。它决定了用户访问某个路径时应该显示哪个组件。
我们现在需要一个机制，让用户能够在不同页面之间切换，比如从首页切换到用户账户信息页。路由能够帮助我们将 URL 和组件相互关联，确保用户在访问特定路径时，看到对应的页面。
import { createBrowserRouter } from 'react-router-dom';import MainLayout from './layouts/MainLayout';
首先导入 createBrowserRouter，用它可以创建一个支持浏览器历史记录的路由系统。接着我们将先前定义好的 MainLayout 引入作为根布局。
const router = createBrowserRouter([  {    path: '/',    element:   }]);
这意味着，无论用户访问的子页面是什么，MainLayout 的结构都会保持一致，而页面主体部分会根据路由变化而动态加载。
 4.3. 设置应用入口
App 组件是整个应用的入口。它负责将路由系统注入到 React 的组件树中，这样其他组件才能知道根据不同的路径应该显示什么内容。
为了加载整个路由配置，我们需要一个统一的入口，因此需要用到 RouterProvider。它将之前配置的路由传递给应用，让各个子组件能够根据 URL 做出相应的渲染。
import { RouterProvider } from 'react-router-dom';import router from './router';
引入 RouterProvider 和先前定义好的 router 配置。
const App = () => {  return ;};
用 RouterProvider 包裹住应用的根组件，并把 router 传递给它。通过这种方式，整个应用的路由系统就生效了。
虽然话是这么说，但因为内部什么组件都没写好，运行时还是什么都看不到的……
 5. 配置状态管理工具
在开发中，状态管理是前端应用的核心部分之一，尤其是在涉及到用户登录、登出、数据持久化等功能时。
Zustand 是一个轻量级的状态管理库，它相比于 Redux 等传统工具更加简洁易用。因为是个练习项目，我便选择了这个更小巧的状态管理库。
 5.1. 简单的例子
 5.1.1. 初始化 Zustand 状态管理器
在 src 目录下创建一个 stores 目录，用于存放状态管理相关的文件。
在本例子中，代码结构分为三部分：状态定义和处理（UserState、actions.ts），Zustand 状态创建和持久化（index.ts），以及一些辅助函数（api.ts、log.ts 和 selector.ts）。
使用以下命令安装 Zustand：
yarn add zustand
stores 目录下创建 index.ts，用作状态管理的入口，这样在应用的其他部分就可以方便地引入状态管理逻辑。
import useUserStore from './user';
作为一个大致的参考，我选择去写一个用户状态。这里先引入一下这个还未开始写的自定义钩子，理想情况下，它应当允许我们访问和操作与用户相关的状态。
在整个应用中，我们将通过这个钩子获取当前用户信息或调用登录操作。
 5.1.2. 定义用户状态类型和接口
stores 目录下创建 user 目录，接着又在 user 目录下创建 types.ts。
export interface User {  id: string;  name: string;  email: string;}export interface UserState {  user: User | null;  isLoading: boolean;  error: string | null;}
TypeScript 中的 interface 用于定义用户状态的结构。使用 interface 能更直观地展示用户状态中的各项属性，同时在项目扩展时易于维护
这里定义了 User 和 UserState，这两个接口分别描述了用户对象的结构和与用户相关的状态。
当然，作为一个参考，这些值后续一定会进行修改或者扩展。
User 接口不用多说。UserState 接口包括了：
user：当前登录的用户信息；没有用户登录的话就是 null
isLoading：是否正在进行异步操作，比如登录请求
error：当然是错误信息啦
setUser 是一个函数属性，接收一个 User 或者 null 类型的参数
login 函数属性接收 LoginCredentials 参数，并返回一个 Promise（使用 TypeScript 的时候这样写有助于检查函数的参数和返回值类型，减少类型错误）
 5.1.3. 创建 Zustand 状态管理器
user 目录下创建 index.ts。
我们通过 Zustand 来创建一个用户状态管理器。
import { create } from 'zustand';import { devtools, persist } from 'zustand/middleware';import { UserState } from './types';import createUserSlice from './actions';const useUserStore = create()(  devtools(    persist(      createUserSlice,      {        name: 'user-storage'      }    )  ));export default useUserStore;
这里我们引入了 Zustand 的两个中间件：devtools 和 persist。
devtools 允许我们在开发时使用 Redux DevTools 进行状态调试，方便查看状态的变化
persist 实现状态的持久化，将用户状态保存在 localStorage 中（先前使用 Redux 的时候，都是要手动使用 localStorage 进行持久性保存。Zustand 则可以直接使用 persist 中间件实现状态的持久化）。这样即使用户刷新页面，用户信息依然保留name: 'user-storage' 指定了持久化状态的存储键名
 5.1.4. 定义用户状态的操作与异步行为
user 目录下创建 actions.ts，定义状态和异步操作。
import { StateCreator } from 'zustand';import { User, UserState } from './types';const createUserSlice: StateCreator = (set) => ({  user: null,  isLoading: false,  error: null,  setUser: (user: User | null) => set({ user }),  login: async (credentials: { email: string; password: string }) => {    set({ isLoading: true, error: null });    try {      // TODO: 调用API      set({ isLoading: false, user: response.data });    } catch (error) {      set({ isLoading: false, error: error.message });    }  }});export default createUserSlice;
在这个文件中，我们定义了用户状态的操作逻辑和异步操作。
对于大多数应用来说，登录是一个异步过程，我们需要在发起请求时更新 isLoading 状态，同时在请求失败时记录错误信息。
初始状态，也就是用户未登录时，user 设为 null、isLoading 为 false，error 也为空。
setUser 是一个简单的同步方法，用于手动设置用户信息。
login 是一个异步函数，用于处理登录逻辑。
开发中，典型的流程是：
设置 isLoading 为 true，以便显示加载状态
发起登录请求（因为还没写，就用 TODO 标记了。注意哈，现在这个时候跑指定报错）
请求成功后，将返回的用户信息存储到状态中，并重置 isLoading 为 false
如果请求失败，捕获错误，并更新 error 状态，用户可看到错误提示（现在当然不行）
 5.2. 进阶配置
我们已经配置了 Zustand 的基本用户状态管理。接下来，我们将借助 TypeScript，进一步优化和扩展状态管理的功能，包括状态持久化、自定义中间件和选择器等。
 5.2.1. 状态持久化与部分存储
在生产环境中，为了提升用户体验，状态持久化是一个常见需求。Zustand 提供了 persist 中间件，帮助我们将部分状态保存在 localStorage 或其他存储中，以确保页面刷新后状态不会丢失。
在 stores/user/index.ts 中，我们定义了 persistOptions，并在其中使用了 partialize 功能，将状态中关键的部分（如用户信息和更新时间）持久化：
import { create } from 'zustand';import { devtools, persist, subscribeWithSelector } from 'zustand/middleware';import type { PersistOptions } from 'zustand/middleware';import { UserState } from './types';import createUserSlice from './actions';import { log } from '../common/log';import { createSelectors } from '../common/selector';type UserPersist = Pick;const persistOptions: PersistOptions = {  name: 'user-storage',  partialize: (state) => ({    user: state.user,    lastUpdated: state.lastUpdated,  }),};
Pick：使用 Pick 类型将 UserState 中的 user 和 lastUpdated 属性挑选出来，简化了持久化的内容
PersistOptions 类型：类型声明让我们清楚地知道哪些状态会被持久化，避免错误持久化不必要的数据partialize 是一个用于选择性地存储状态对象中部分属性的函数。在我们的 persistOptions 里，它的作用是从 UserState 状态中挑出 user 和 lastUpdated 这两个属性，并将其存储到持久化的存储中
 5.2.2. 订阅特定的状态
subscribeWithSelector 允许我们订阅特定的状态属性变化。与直接订阅整个状态的变化不同，它可以细化到仅在某些具体属性更新时触发回调，从而减少不必要的订阅响应。
继续写 stores/user/index.ts：
const useUserStoreBase = create()(  devtools(    persist(      subscribeWithSelector(        log(createUserSlice),      ),      persistOptions,    )  ));
通过组合其他的 Zustand 插件，我们创建了一个订阅机制。这样做的好处是提高性能、避免不必要的渲染。
接下来这段代码订阅了 useUserStoreBase 中的 user 属性：
useUserStoreBase.subscribe(  (state) => state.user,  (user) => {    if (user) {      console.log('User logged in: ', user.name);    } else {      console.log('User logged out');    }  })export const useUserStore = createSelectors(useUserStoreBase);
(state) => state.user 是一个选择器函数，只返回 state 中的 user 属性，从而使订阅仅响应 user 的变化
当 user 属性变化时，回调触发。回调会根据 user 是否存在（如 user 为 null，或者用户登陆了新的信息）来输出不同的登录状态信息
 5.2.3. 自定义日志中间件
为了方便调试，我们可以创建一个日志中间件。这个中间件会在每次状态更新时，记录状态变化信息。
在 stores/common/log.ts 中定义 log 函数，扩展 Zustand 的 set 方法，使其在应用状态变化时输出变更详情。
先写一个泛型类型，用于定义 set 函数所接收的各种更新方式：
import { StateCreator } from 'zustand';type SetStateAction = T | Partial | ((state: T) => T | Partial);
SetStateAction 的作用是确保状态的更新类型符合期望，允许直接提供新的状态值、部分更新或基于当前状态的更新函数T：泛型参数，表示整个状态对象的类型，例如 UserState
类型定义：T：可以直接传入整个状态对象，用于完全替换现有状态
Partial：可以传入部分状态对象，即只更新部分属性。Partial 将状态对象的所有属性变为可选
(state: T) => T | Partial：可以传入一个函数，这个函数接收当前状态作为参数，并返回新的状态或部分状态。这种方式允许在回调中基于现有状态动态生成更新值
这样写的目的是为了更灵活的状态更新方式，不仅可以直接替换状态，也可以部分更新或在回调函数中动态更新。
export const log = (  config: StateCreator): StateCreator =>  (set, get, api) => config(    (partial: SetStateAction, replace?: boolean) => {      console.log('Applying', { partial, replace });      if (replace) {        set(partial as T | ((state: T) => T), true);      } else {        set(partial as SetStateAction);      }      console.log('New state: ', get());    },    get,    api  );
log 是一个高阶函数（也就是 HOC），接受一个 Zustand 的 StateCreator 配置函数，并返回一个经过增强的 StateCreator，用于记录状态的变化。
log 的作用是对传入的 config 配置函数进行包装，以便在状态更新时打印更新的内容和更新后的状态，用于调试。
log 的内部逻辑：
参数：
config：一个 Zustand 的 StateCreator 函数，负责创建状态。此函数会调用 set 函数来更新状态
返回值：一个增强的 StateCreator 函数，用于替代原始 config 函数
内部逻辑：
包装 set 函数：调用 config 时，将自定义的 set 函数传入
自定义的 set 函数接收 partial 和 replace 两个参数：
partial：可以是新的状态值、部分状态值，也可以是一个返回状态的函数
replace：布尔值，表示是否完全替换现有状态
日志输出：
console.log('Applying', { partial, replace }) 在更新前输出即将应用的部分状态或新状态
console.log('New state: ', get()) 在更新后输出新的
更新逻辑：
若 replace 为 true，则完全替换当前状态；否则只应用部分更新
调用 get 获取新的状态并打印日志
 5.2.4. 状态选择器
在状态管理中，我们通常需要对状态进行选择，以便在不同组件中访问特定的状态字段。
createSelectors 帮助我们自动生成访问器，减少在不同组件中冗余的状态逻辑。
stores/common/selector.ts 中定义 createSelectors，它会为状态中的每个字段创建一个 getter 函数，便于状态的解耦：
import { StoreApi, UseBoundStore } from 'zustand';type WithSelectors = S extends { getState: () => infer T }  ? S & { use: { [K in keyof T]: () => T[K] } }  : never;
WithSelectors 定义了一个条件类型，用于增强传入的 store 类型 SS extends { getState: () => infer T } 检查 S 是否包含 getState 方法，并从中推断出 T 类型（状态对象的类型）
返回：若 S 满足条件，则返回 S 并附加一个 use 属性use 是一个对象，包含状态对象中每个键对应的 getter 方法，这些方法返回 T[K]，即每个状态属性的值
若 S 不满足条件，则返回 never
export const createSelectors = <  S extends UseBoundStore>,  T extends object>(_store: S) => {  const store = _store as WithSelectors;  store.use = {} as { [K in keyof T]: () => T[K] };  const state = store.getState();  for (const k of Object.keys(state) as Array) {    store.use[k] = () => state[k];  }  return store;}
createSelectors 函数：
参数：接收一个 Zustand store 实例 _store
类型约束：S extends UseBoundStore>：约束 S 必须是一个 UseBoundStore 类型的 store
T extends object：状态对象 T 必须是一个对象
逻辑：将传入的 store _store 进行类型转换，以便使用 WithSelectors 增强后的类型
为 store 增加 use 属性（一个空对象），作为存放每个状态属性 getter 方法的容器
获取当前 store 的 state 对象
for 循环遍历 state 对象的键（即状态对象的属性）对每个键 k，在 store.use 中创建一个对应的 getter 方法 store.use[k]，返回 state[k] 的值
返回增强后的 store 实例 store，其中包含 use 对象和对应的 getter 方法
假设 store 的状态对象如下：
const useStore = createSelectors(  create((set) => ({    user: { name: "Alice", age: 30 },    loggedIn: true  })));
那么调用 useStore.use.user() 就会返回：
{ name: "Alice", age: 30 }
 5.2.5. API 请求的配置和错误处理
在前端状态管理中，一般会包含 API 请求的逻辑。
我们在 stores/user/actions 中，定义一个 createUserSlice 函数，它是 Zustand 中 UserState 的部分实现，用于管理用户相关的状态和操作。
首先导入依赖：
import { StateCreator } from 'zustand';import { AxiosResponse } from 'axios';import { User, UserState, LoginCredentials } from './types';import api from '../common/api';
定义状态和操作：
const createUserSlice: StateCreator = (set) => ({  user: null,  isLoading: false,  error: null,  lastUpdated: null,  // ...
user：存储当前用户信息
isLoading：指示登录操作是否正在进行中
error：保存登录过程中发生的错误信息
lastUpdated：记录上次用户数据更新的时间戳
// ...setUser: (user: User | null) => set({ user }),// ...
setUser：一个同步方法，用于直接设置 user 状态。接收一个 User 对象或者 null，并调用 set 更新状态
// ...login: async (credentials: LoginCredentials) => {  set({ isLoading: true, error: null });  try {    const response: AxiosResponse = await api.post('/auth/login', credentials);    const user = response.data;    set({      user,      isLoading: false,      lastUpdated: Date.now(),      error: null    });    return user;  } catch (error) {    const errorMessage = error instanceof Error      ? error.message      : 'An unexpected error occurred during login';    set({      isLoading: false,      error: errorMessage,      user: null    });    throw error;  }},// ...
login 方法：
启动加载状态：调用 set({ isLoading: true, error: null }) 将 isLoading 设置为 true，并清除之前的错误
API 请求：await api.post('/auth/login', credentials) 向服务器发送登录请求。返回的 response.data 包含了用户信息
成功处理：若请求成功，set 更新状态，存储用户数据、停止加载、设置 lastUpdated 时间戳，并清除错误
返回 user，便于在调用 login 的地方使用
错误处理：如果请求失败，捕获 error 并生成错误消息
更新 set 将 isLoading 设置为 false，保存 error 信息，并将 user 设置为 null
抛出错误，以便调用 login 的组件也能捕获并处理该错误
  // ...  logout: () => {    set({      user: null,      error: null,      lastUpdated: null    });  }});export default createUserSlice;
logout 方法是登出功能，说白了就是将所有的状态设置为 null，从而达到清除当前用户信息和错误的效果。
 6. 设置 API 请求封装
至于 API 嘛，写在了 stores/common/api.ts 中：
import axios from 'axios';const api = axios.create({  baseURL: process.env.REACT_APP_API_URL,  timeout: 10000});
axios 配置了一个 API 实例 api，设置了基本的请求和响应拦截器。
baseURL 为环境变量 REACT_APP_API_URL，还设置了 10 秒的超时时间
api.interceptors.request.use(  (config) => {    // TODO: 添加认证信息    return config;  },  (error) => Promise.reject(error));
请求拦截器 api.interceptors.request.use 提供了请求发送前的自定义逻辑处理。可以在 config 中添加认证信息（也就是老生常谈的 JWT Authorization 头）。
如果请求在发送前就失败了，那么拦截器将直接拒绝该错误
api.interceptors.response.use(  (response) => response,  (error) => {    // TODO: 统一错误信息    return Promise.reject(error);  });export default api;
响应拦截器 api.interceptors.response.use 允许在接收到响应时进行自定义处理。
响应成功会直接返回数据
请求出错，error 就会被统一处理，然后传递给调用方处理
有很多功能先放 TODO 了，能差不多 GET 到意思就好。

HTTP 状态码	`HttpStatus` 枚举值
`200`	`OK`
`201`	`CREATED`
`204`	`NO_CONTENT`
`400`	`BAD_REQUEST`
`401`	`UNAUTHORIZED`
`404`	`NOT_FOUND`
`409`	`CONFLICT`
`500`	`INTERNAL_SERVER_ERROR`

周期	GPU 模式号	时间消耗（`t` 时钟周期）	描述
OAM 搜索	2	80	GPU 扫描 OAM 获取当前扫描线上的精灵信息。
像素传输	3	172	GPU 从 VRAM 读取图块和地图数据并渲染像素。
水平消隐	0	204	当前扫描线渲染完成后的等待期。
一条扫描线总时间		456	(80 + 172 + 204)
垂直消隐	1	4560（10 行）	所有可见扫描线渲染完成后的等待期。
一帧总时间		70224	（456 * 154 行）

地址区域	用途
`0x8000` - `0x8FFF`	瓦片集 #1
`0x9000` - `0x97FF`	瓦片集 #2
`0x9800` - `0x9BFF`	瓦片地图 #0
`0x9C00` - `0x9FFF`	瓦片地图 #1

Cytrogen 的个人博客（中文）

写写废文

教小孩子的时候家长要闭嘴

八月份的结尾

唱 K 真好玩

自制麻酱

投影仪

爱尔兰酒吧

夜驱

Ai Fuji Market

Golang 学习笔记・壹：基础知识直到 struct

基础知识

类型

条件

函数

struct

回一趟父母家：更好的搜索、困难模式、野生动物

给博客做 embedding 然后就能更好搜索了

不带手机出去溜个弯儿呗

野猫泛滥

RE：覺得訂閱制軟體很貴，大概是你太窮，不懂商業邏輯

表象

权威

讽刺

版权

温和的建议

自己绘制的图片

想法在丙午中秋迭代

RE：The ordinariness of evil

AI 技术并不万能

AI 的经济泡沫

与 AI 相关的政治承诺

为什么老板和政客们还在继续投入？

我们该怎么做？

LLMorphism

和「权利」相关的延伸思考

结束

做导游的这几天：星期三

RE：The Becoming Chinese Trend Is Nonsense

牛郎织女和父权

公众号文章的简述

牛郎织女传说的各个版本

什么是女性主义？

什么是批判理论？

Freud 精神分析

心灵的地形学模型

心灵的结构模型

驱力理论

性心理发展阶段

俄狄浦斯情结

Lacan 精神分析

三个界域

欲望与 对象小 a（Objet petit a）

菲勒斯与阳具中心主义

什么是父权制？

不同流派对父权制的看法

父权制能否被终结？

父权制是有意识的阴谋吗？

Irigaray 对 Lacan 的批判

回到对公众号文章的解析

意识形态的自然化

Lacan 的能指分析应用

Swan Maiden 母题

公众号文章的政治立场

公众号文章的问题所在

父权制没有意识

Lacan 的能指分析要求差异

「强奸」到底是什么？

女人是男人的幻想工具人吗？

循环论证问题

深度展开循环论证

谁被献祭给了什么？

王母娘娘是解救者吗？

大他者是抽象的

公众号文章的修辞

对主要反对意见的回应

故事传颂是因为人民群众的美好愿望

如果父权意识形态筛选版本，更应该筛选出「天帝安排」版本

流传最广的版本是温和的，即牛郎归还了衣服、织女自愿留下，不存在偷窥和胁迫

牛郎织女更接近一种得不到的粉色幻想，即性转版的「霸道总裁爱上平凡的我」

`struct`

欲望与对象小 a（Objet petit a）

RE：美国梦与美国痛华裔新移民青少年帮派犯罪