一月志：

这是继承 Memos 「遗志」的栏目，正如我在 2025 年终总结中谈到的，我打算效仿伏枥，把生活日志按月记录，一月一结。

这样做一方面能满足自己的写作欲和分享欲，另一方面也能稍微克制一下在「写作本身」上投入的时间。很多时候一写起来就会觉得不满意，觉得乱，想改，结果反而把记录这件事拖得越来越长，把时间消耗在一些并没有太大意义的地方（当然，这也有我最近输入太少不知道写什么的原因，缺乏了一颗记录生活的心）。

折腾到最后，除了键盘（或者手机屏幕）磨损增加之外，几乎没有什么实质性的进展。

就比如这个新栏目名字的事，我其实纠结了挺久。想过好几个，都觉得差点意思，最后也没能和自己协商出一个真正满意的结果。于是懒得想，言简意赅，索性就叫「月志」了，符合找不到解决方案就摆烂的我的风格，再用「内容比名字重要得多」这个理由说服自己先写起来。

嗯，是的，这个名字的由来就是这么草率。

然而，令人感慨的是，「月志」在第一期就迟到了。除了上述问题和我改不掉的拖延症之外，第一个原因是卡文，我很想写之前观看 Eva 的感受，但一直憋不出来；而另一个更直接的原因是：我生了一场病，而一生病就什么都不想干，只想躺在床上睡觉了...

所以我顺理成章地再次说服了自己把「一月志」放到了二月来写，这又继承了 2025 年终总结是在 2026 写完的举措，可谓~~承上启下~~。

经历：

生病：

生的病其实不是什么大病，仅仅是一场感冒。

可这次感冒的体感被时间「放大」了——因为我上次感冒还是差不多一年以前。当与感冒「久别重逢」，重新体验到鼻塞和头痛之后，我终于意识到「人生病就会难受」——这听起来和卫宫士郎说「人被杀就会死」一样荒谬，但拥有一个相对健康的身体比较久了之后，对于生病的感受会逐渐模糊，从而觉得生病没什么大不了的。

如果单单是身体上的难受还能通过吃药来缓解，但心理上的胡思乱想就不可避免了。

这来自于睡不着。

感冒的前期，即使吃完了感冒药，身体发热也会让我难以入睡，难以入睡之后就是胡思乱想。而我对于睡不着一向充满着焦虑——这又源自于中学时期担心睡不着影响第二天的状态，别的东西没留下来，这种心态倒是一直延续至今。种种因素叠加下，失眠的我会极度焦虑，而这种极度焦虑的状态显然也影响了我身体免疫系统的发挥，从而让可能不是很严重的感冒症状变得严重了。

大半夜让外卖送布洛芬

感冒的中期是不断地咳嗽与鼻塞，使本就不容易入睡的状态雪上加霜。在失眠的那段时间，我开始认真地思考我会不会因为感冒致死，或者说因为感冒导致的睡眠不足引起猝死。当我发现想不出个所以然之后，神经兮兮的我开始看起了之前一直没看完的书，最后成功以十分亢奋的状态通宵了。

而感冒后期则是不断地干咳，直接地打断我非常长的入睡前摇。

我在整个感冒流程中都没睡过几次好觉，这又导致感冒基本好了之后，每天实习下班回来就什么也不想思考，随便打打游戏看两眼书，就倒头想睡。

一连串经历下来，身体可能离鬼门关还离得很远，心理上可能都已经在里面逛了几圈。

我再次得出一条没有什么用且无法执行的结论：感冒的时候就应该什么都不要想。但相较于这条没什么用的结论，现实且有用一点的，我或许应该去加强锻炼，从源头上切断感冒。

祝愿阅读这篇文章的各位都身体健康，即使感冒了也不要像我一样胡思乱想。

实习：

在一月中旬的时候我在杭州开启了我的第一段实习，实习待的组氛围很不错，我的 mt 对我也非常好，总体体验下来还算满意，但这里面还是有许多槽点...

作为一个没有实际大型项目开发经验的实习生，实习之前，我对于大公司的整个研发流程还是有所期待的，想象着严谨的 prd 和优雅的代码库。

事实证明，我还是想多了。

上来看的第一份代码库是一个 python3.9 写的管理平台后端。几万行的代码中，类型注解的含量为 0，我每次看一个调用链路中的数据结构都要猜来猜去。

我第一次切身体会到「祖传代码」到底是什么样的。值得庆幸的是，现在有 llm 能帮我梳理整个调用链路和数据流动的方向，并且还能为我贴心的加上注解，勉强可以将工作进行下去，但这显然不是一份好玩的工作 : (

糟糕的代码风格只是其一，由于这个安全研发部分的工作主要是针对公司内部的防护，所以并没有配置任何测试、产品等岗位，我们整个组都可以称得上「全干工程师」，从前后端到测试，再到运维部署，全都是工作内容。

虽然我并不反感这一工作内容，甚至自己本身这些东西都或多或少都涉猎过一点，勉强还称得上专业对口，但在实际做的时候东折腾一趟西折腾一趟的体验还是怪怪的，总感觉像上了贼船。

只能说，学到的东西还是不少，大概或许可能这是一个好实习吧，至少氛围不错。

~~实在不行作为实习生也可以随时跑路。~~

输入：

漫画：

一月初的时候，学校考试基本就结束了，而面试也以拿到了两个还算不错的 offer 短暂完结。好久没闲下来的我久违地在没有任何心理压力的状态下看了好几天漫画。

藤本树：

而这其中以藤本树的电锯人 2和短篇漫画集最多。

在不久之前才看完电锯人 tv 版和蕾塞篇我看来，电锯人 2 的作画潦草，分镜诡异，剧情逻辑也十分奇怪，甚至人物更是想画死就画死，除了体现藤本树作为「日本第二自由漫画家」这个头衔外，观感上可谓灾难。

你看到这个分镜的感受是？

与之形成鲜明对比的，是他的短篇漫画，最初的院子里有一只鸡，和在画电锯人 2之前的蓦然回首、再见绘梨。这几部作品就画的十分有趣，在这之中，我最喜欢再见绘梨。

再见绘梨

与漫画中描述的，作品应该添加一抹奇幻色彩。再见绘梨整个故事都给人一种奇幻的感觉，整个漫画就 200 页，我只看了半个多小时，然而看完后思考这个「奇幻」结局则花了好几天，我自己也分不清到底什么时候是电影，什么时候是现实，给我的感觉很像之前看过的一本网文，叫道诡异仙。巧的是，这两位作者我都认为该进精神病院。

故事性之外，再见绘梨的分镜也是藤本树的所有漫画中最好的，非常有电影感的分镜，观感比电锯人 2 好了不知道多少倍，所以藤本树在画再见绘梨和电锯人之间到底经历了什么？

电影：

一月生病的时候把之前朋友推荐的今敏的电影补完了一部分，千年女优 和 东京教父 都很好看，除此之外还看了 机器人之梦。但最让我反复思考的还是千年女优 。在看的时候，联想到了很久之前看的窄门

千年女优：

今敏的 千年女优 里，千代子追逐了一辈子的那个人，其实她根本就不认识，纵观整个影片，连个正脸的镜头都从未给过，千代子自己也承认自己早已记不清楚面容。她爱的根本不是那个人，只是「追逐」这件事本身。她把那个人概念化成了一个完美形象的投射，然后跑了一辈子去追逐这个幻象。

千年女优

整个片子的追逐意向很有叙述性诡计的感觉，电影与现实交杂，看似电影，实际上一直都是在讲千代子自己。

窄门讲的也是同样的故事。两个人明明相爱，却因为宗教信仰和道德洁癖，把「纯洁」概念化成了某种理想状态，然后不断推迟自己的幸福，想要等到完全配得上这份爱的时候才去接受它。可等到真的走到窄门前，才发现门已经关上了。

它们都在讲同一件事：人会把亲密关系里的对方概念化——要么是不认识的「那个人」，要么是道德纯洁的「那个状态」——然后去追逐一个根本不存在的完美幻象。

要爱具体的人胜过爱抽象的人，爱生活胜过爱生活的意义。

但我作为一个 INFP 而言，常常对于亲密关系过于理想化，从而也会误入电影中的理想化追逐困境。也许之后会抽空整理一下类似的感受。

现在，我至少意识到了这一点，当我把某个具体的人概念化成某种完美的形象时，其实那已经根本不是她了。

随想录：

Worse is Better?：

Worse is Better 是软件工程中的一个概念。简单来说，它认为一个先存在、简单但不完美的方案，往往比设计上更优雅但实现更复杂的方案更有生命力。

这听起来非常的 unix 哲学，简单可行然后持续优化，可这实际却会导致大家在开发时不再遵守定义的规范，引发奇怪的兼容性错误。

我在开发一个支付宝小程序的时候就遇到一个奇怪的 bug，从 http 请求可以一路追溯到 ios 和安卓的系统协议栈实现上，而这一切都是「Worse is Better」导致的。

Post or Patch?:

在谈论这个奇怪的 bug 之前，让我们来复习一下 Restful Api 的定义。

REST 是一种架构风格。它假定系统由资源（Resource）组成，每个资源都有唯一的 URI，客户端通过对这些资源施加标准化的操作来表达意图，而不是通过随意命名的接口。

在这个前提下，HTTP 方法并不是实现细节，而是语义本身。

GET 用于获取资源的当前表示，不应产生副作用；
POST 用于在某个资源下创建新资源，或触发一个不可幂等的行为；
PUT 用于用完整的新表示替换目标资源，本质上是一次整体更新；
PATCH 用于对资源进行部分更新，只描述发生变化的字段；
DELETE 用于删除资源。

当然了，在实现上，大家基本不会遵守规范，更新资源部分都是 POST 一把梭。

但我是一个严谨的人，我是一个阅读过 Restful 定义的人！肯定要遵守规范啊！（<- 其实是开发经验不足，以及没有认真阅读支付宝小程序的文档。）

于是我就在开发的时候将一个更新行程的 api 的方法定义成了 Patch。然后诡异的 bug 就出现了，功能上线后，有测试的朋友反馈无法更新行程，但这个 bug 无法在我的手机上复现，并且在我的同学的手机上也无法复现。最后经过控制变量法的排除，我发现只有部分安卓用户会遇到这个问题，而 ios 用户就没有这样的错误。

我重新打印出了日志，然后用我的备用安卓机来模拟测试了请求，发现了问题所在——发过来的 Patch 请求的 body 部分完全是空的。

在查阅了相关文档后，大概得出了结论：

taro （小程序使用的前端框架）在编译的时候的确会把 PATCH 方法成功编译成 js，但由 js 转换成 native code 的时候就会出现问题。

由于 ios 是由苹果官方规定的系统网络协议栈，所以所有 app 的实现基本一致，都会使用提供的 NSURLSession这个 api，转换成的 PATCH 方法也是正确的，因此使用 ios 就不会遇到更新失败的问题。

而 android 手机的话，各个厂商都会对手机 ROM 有不同程度上的魔改，从而导致系统网络协议栈的实现千奇百怪，并且我在查阅了 android 官方文档后发现它压根就没在它的这个 http methods 中提到过 PATCH 请求的支持，即使 PATCH 请求是有对应的 RFC5879 文档的。

压根不存在 patch

再次查询这条 RFC 的发布时间后就可以发现，PATCH 的出现是在 2010 年，比其他 HTTP Method（第一版 RFC2616，就是图片上这些）晚了 11 年，而这个时候，大家早已经养成了习惯，改不过来了，只有我这种涉世未深只看规范的新手才会干出 PATCH 这种事情来。

debug 完成后，将对应的 http 请求改为 POST 方法就再也没出问题了。另外，在结束后我去阅读支付宝文档的时候又发现，支付宝还明确告诉我不支持 PATCH，这种奇怪的 bug 估计也就我能遇上。

Mysql or Postgre?:

事实上，类似的「Worse is Better」的例子还不少。

以数据库举例，MySQL 的 ACID 实现饱经诟病，在某些早期版本中，它甚至不能完全保证事务的原子性。

如果你对此感到好奇，可以阅读对应的文档，或者看一下「全网最尊重 Mysql」的博主：

一代代开发者在前人的坑上继续填坑（比如阿里开发者手册）。MySQL 的各种奇奇怪怪的行为模式成了经验，成了「最佳实践」，成了面试题。我目前还没见到任何一家互联网大公司 jd 上写 Postgre，网络上关于 Postgre 的资料相较于 Mysql 也少得可怜。

我们花在理解和规避这些「历史遗留问题」上的时间，可能比从头学一个正经规范的数据库还多。

有趣的是，截止本文写作时， Mysql 最近的两个月都没有任何更新。我个人非常希望 Oracle 赶紧放弃它，早日让大家摆脱 Mysql 的苦海，从而让大家不用再针对糟糕的 Mysql 设计进行八股背诵，使用这种糟糕的软件也应该算到工伤上面。

mysql

至于迁移适配问题，光是做迁移就可以搞出很多 kpi，这应该不是一件坏事...吧?

总而言之，我觉得「Worse is Better」并不是一件好事，可惜事物的发展并不如同我的想法。

心之壁：

最近读了两篇关于「语言与理解」的文章，我尝试将其与之前看 Eva 时的感受结合起来，谈一谈心之壁这个概念，在阐述这个部分的时候，我也同样无法准确的表达自己的感受，只能将其中一部分传递到文字中，如果表达有些抽象，语义有些模糊，还请不要见怪。

第一篇讲的是语言的边界：

世界本身或许既不模糊也不精确，它就只是"是"而已。是我们非要用语言、概念、数学这些工具去切割它、命名它。维特根斯坦说「语言的边界就是世界的边界」，反过来想，这也意味着我们永远只能触及被语言框定的那部分世界。

所以与其说"世界本质是模糊的"，不如说——世界的本质是溢出的。它永远比我们的精确化工具能捕捉的更多。德里达管这叫"延异"(différance)：意义永远在滑动，每一次定义都同时是一次遗漏。精确化不是在还原真相，而是在建构一个可操作的模型。科学、法律、经济学，全都是这样——它们不是在描摹世界，而是在世界上投下一张网，网眼之外的东西，我们假装它不存在。

也许两者都是。我们一边扩张，一边承认扩张的徒劳。就像西西弗斯推石头，明知道会滚下来，还是要推。

不是因为石头会留在山顶，而是因为推的过程本身就是意义。

—— 网眼之外

另一篇记录了一次与前女友的见面：

我没有询问任何关于她私生活、情感方面的事情，也许有心照不宣的默契，可更多是对推心置腹后，他人闯入自己生活所带来风险与责任的规避。

即便面对如此一位年纪相仿又有过一段情缘的异性，撑在同一把伞下，路上不乏有意无意的肢体接触，在嘈杂中交流时脸快贴到一起。但持续徒步的疲劳与持续交谈的麻木，或许有些悲哀，但有些抗拒来自心理本能，别说旧情复燃，甚至已经毫无性冲动了。。

至此，我开始相信，或许「心之壁」是存在的。

—— 社交距离

读完这两篇文章，我意识到，当我写这篇月志的时候，其实就是在经历这样一个过程。

当我试图把一月的经历转化成文字时，我自己也总是在做选择，哪些该写，哪些不该写。而那些写出来的东西，又总觉得「好像不是那个意思」。那些流动的、模糊的、矛盾的感受，被迫塞进「语言」这个有限容器里，必然会溢出，必然会被简化。

我对你说「我很开心」，你听到的「开心」和我感受到的「开心」，从来都不是同一个东西。它们只是碰巧被同一个词标记了而已。

这里有一段很久之前的摘抄：

我哪里会完全懂你此刻的心情。没有谁有真正的感同身受。

我在体验我热爱的东西的时候，我兴奋不已，却看见你在旁边愁眉不展，我不能理解，甚至怪你在旁煞风景。那一刻我兴奋不已，幸福填满了我的整个胸腔，哪有空间去细细摸索去知晓你当时的苦楚。

让一人开心十倍之物，也可以是让另一人伤心十倍之物。所以自己开心的时候，没有必要要求他人陪着自己享受同等的情绪，我们也要允许他人拥有自己的情绪，让自己做自己，让别人做别人。

这就是心之壁。Eva 里的 A.T.Field，那道永远存在于人与人之间的屏障。

写到这里，我忽然想起圣经里的巴比伦通天塔。人类原本语言相通，想要建造一座塔直通天际，上帝为了阻止他们，打乱了他们的语言，让他们无法沟通合作，塔也就此废弃。

小时候读这个故事，并未觉得有什么奇特，只是感觉需要在中间增加一层翻译来便于协作。但现在想来，这和人类补完计划说的其实是同一件事，只是方向相反。

上帝打乱语言，就是在人类之间制造心之壁。因为一旦语言相通，意义就能无损传递，人类就能像人类补完计划实现后的那样成为某种集体意识。而语言的不完美，那个从心灵到语言、再从语言到他人心灵的多层转换系统，每一次转换都在损失、在溢出、在变形——这正是心之壁技术上可行的实现。

上帝造出语言的不完美，本质上就是在人类之间安插了永恒的心之壁。而这也让我开始理解，为什么 Eva 里的人类补完计划最终被拒绝了。

如果心之壁真的消失了，如果语言真的能完美传达，那「我」也就不复存在了。这和真心为你 的最后大家泡在「橙汁 LCL」思维同化后就只有唯一的个体一致，只有拒绝补完，例如最后的真嗣和明日香，才能有「我」这个形象，从而出现在最后的海滩上。

我以前总觉得心之壁是可悲的，是人与人之间无法跨越的鸿沟。但反过来想，如果人类补完计划真的实现了，如果所有人的心之壁都消失了，如果每个人都能完全理解彼此，那会是怎样的一种景象？

我也许会失去「自我」吧。

正是因为心之壁的存在，我才成为了我。正是因为语言的不完美，我才有机会一遍又一遍地尝试表达，即使知道永远无法完全传达。这种徒劳的努力，这种西西弗斯式的推石头，或许就是「活着」这件事本身。

就像第一篇文章里时歌写到最后的：「不是因为石头会留在山顶，而是因为推的过程本身就是意义。」

我们因各自不同的表达才成为独立的「我」。

写到这里，我发现我还是无法完全的表达出我心中所想的内容，即使我和 llm 聊了很长时间这个话题，自认为已经可以表达出来。这又何尝不是心之壁的体现呢？

但我已经尽力了，再继续写下去也不会更好，和第二篇文章作者感到表达匮乏一样，我想我也应该多读一点书了。

在和拖延症艰难搏斗了一个周之后，我终于拖着我基本康复的身体记下了这份迟到的月志。

二月顺利！