工作

写代码层面上逃不开的就是LLM了。回想上一年的春节，GPT刚出thinking模式不久，deepseek刚出R1——一个甚至不支持function call的模型。而现在GPT5.3已经出来了，Codex，Claude Code之类的Coding Agents写代码是真的很好。正职工作近一年甚至近两年基本上都是围绕LLM做各种「AI」能力。

各种AI功能，本质都是在做各种各样的Agents，要说2025年前的模型能力大部分「AI功能」只是一个尝试或者宣传的噱头。还记得当时光是让LLM输出合法的JSON就得花一大堆功夫在Prompt Engineering上。为了减少幻觉提升生成的准确率和效果，还得加各种各样的外围工程化的设计。

但现在聪明的模型，只要提供的上下文的内容足够完整，不需要特别的prompt输出已经非常可用了。最大的感受是随着基础模型的进步，之前做的很多工程化尝试，比如知识库RAG，各种调整prompt，设计的router agent，多Agents调用流程的操作都没有了意义。一些不那么聪明的模型，如果能有一个沙箱可以跑通完整的repl，获取错误信息重试的流程多试几次也都大概能改对。

随着模型的能力继续更新，最重要的还是提供沙箱能力，不管是写代码，还是操作浏览器，或者OpenClaw之类通用Agents，要让模型能够拿到反馈，并多次迭代。

AI Coding

當我第一眼看到 vibe coding 時，我就知道這又是個會各說各話的詞了。有些人眼中的 vibe coding 就是跟 AI 協作寫 code，有些人的則局限於「外行人用 AI coding」或者「用 AI coding完就不維護了」之類的。那既然每個人定義都不同，這個詞就沒什麼用處了，除了讓討論的雙方混淆以外，並沒有帶來任何額外的價值，所以我不會用它。
—— https://life.huli.tw/2026/01/03/ai-and-duck-lazy-and-fact/

今年是真正的开始用LLM写代码的一年。以前还停留在tab智能补全，体验下来始终不太好用，甚至妨碍括号闭合，索性关掉了。直到3月份的时候Cursor出了composer模式也就是现在的Agent Mode，可以自己分析理解需求写大段或者整个代码文件，执行命令，构建测试。第一次真正用上是在 beancount-lsp 里让LLM帮我实现拼音首字母补全项筛选的功能，一次就能选型安装依赖，编写代码编译并运行成功完成度相当可以，我就立刻给Cursor充上了值。真正的感受到了生产力的大爆发，快速推进了BeanCount LSP很长时间都没搞或者搞不出来的功能。

在Language Server的开发中，LLM可以充当一个非常强的搜索引擎。比如很多VSCode中有的功能，像点击文件路径跳转，编辑区上面的面包屑导航，都是由LSP提供的，但我并不知道具体是协议里的哪个功能。以前可能要搜半天，如今只需向LLM描述需求即可。VSCode中补全的触发机制会受wordPattern影响，直接问LLM就能弄清具体实现逻辑。

而且由于本身语言服务处理的就是文本，LLM甚至不需要生成临时测试脚本去跑，仅靠自己的深度思考就能推导出正确代码。除了当搜索引擎，也常让LLM以资深用户的角度发散思考新的使用场景，同样好用。像code lens提示账户balance和padding金额这种功能就是跟LLM讨论出来的。

后面模型能力的迭代到了GPT5.2-Codex时代，已经可以完全让GPT编译出pyodide的beancount wheel。对python wheel构建完全不了解，对python的模块系统也不太熟悉，对beancount所使用的构建工具meson更是一窍不通。但Codex经过几轮报错修改的迭代之后已经能编译出可用的wheel并且在demo中成功地跑起来了。这类问题以前可能要研究好几天。

在Coding层面上，LLM对生产力的提升可以说是立竿见影。特别是这些年工作上见过不少奇葩代码后，真心觉得LLM写代码已经比人写得要好了。至少从命名上，从注释上提升是巨大的。也不会出现因为懒得定义struct tags而直接返回嵌套JSON字符串这类情况。LLM还能降低很多沟通层面的消耗。不止一次有同事在问一些SDK API的使用问题。在回复之前就通过类似deepwiki的操作就知道答案。

在让GPT编译beancount wasm过程中，遇到缺少的C/C++编译工具链，Codex一发现缺少就开始用brew安装。但这样的临时做法不够稳定——依赖环境、跨平台问题都容易埋坑。我立刻让它改为创建一个可复现的Dockerfile，在容器中去安装所需的依赖。这个细节体现了人的价值所在：虽然LLM能快速生成代码，但对可维护性的考量、对整体代码结构的设计，依然离不开人的介入。

现在LLM已经把软件的门槛降低了很多，将来的护城河在于服务的场景和完成度。场景上掌握数据的服务和实时通信这类有网络效应的软件服务有护城河，而完成度则是留住用户的关键，假如AI Coding 能做出来可能80分的东西，那同样的场景下决定用户能否留下的就是细节上那20分。

模型，概念涌现

2025年各种概念涌现，MCP、ACP、A2A、Skills层出不穷，似乎每隔一段时间就有新东西"炸裂"。但真正产生影响的只有占据先发优势的MCP，和依靠模型通用能力的Skills。其他的ACP、A2A之类基本没有水花。streamable HTTP出来前SSE transport就一言难尽，整个协议除了tools外其他部分基本没被用起来。到现在还得看cursor/claude desktop这类client实现，用户体验完全取决于client的脸色。现在我还是觉得stdio MCP比不过一个设计优秀，信息完整的CLI，remote MCP比不过一个有优秀设计，文档详尽的API。跟MCP比起来skills设计简单而且可以按需加载，要好上不少。

各种新模型也是层出不穷，每个都说自己是SOTA或者在benchmark里达到了接近SOTA的标准。但是实际上用下来，模型之间的差距真的非常大。在干正事的时候还是得用好的模型，好的模型一次就能成功，因此节约的token和时间成本真的值得多花这些钱。更重要的是用上领先模型之后，对模型能力边界有更好的认知，有一种想象力不会被制约的感觉。但是一些并不在意后续维护，或者后台执行不在意成功与否，允许多次重试的任务用国产便宜模型也未尝不可。

一个相对有难度的自己的评测项目要比看benchmark跑分要有意义的多。这个横评就很不错。

投资

投资是认真在学习，在做的，跟代码一样的终身事业。2025年收益率跟2024年比稍低一点，但是已经超出我的预期，我非常明白不可能每年都这样。

2025年最大的改变就是开始买入AI，年初的deepseek时刻，美股因为对算力需求恐慌大跌了一波。我开始建仓了AI上游的产业，芯片代工厂。当时的思考是下游的盈利能力不好说，但是巨头们在AI上的资本开支对上游来说是实实在在的营收。随后在川普的关税冲击等大跌的时候继续加仓。回头这是相当成功的一笔投资。但当时的我对模型能力仍然没有信心。即便是当时到处「炸裂」的deepseek，我觉得效果只是一般般，幻觉很严重。因此我的投资仍然仅限于上游中的芯片代工厂。心里想的是，代工业务的客户相对分散，也有像iPhone这类消费品的支撑，而没有买入英伟达。

转折发生在Cursor推出parallel agents，它通过git worktree,同时跑不同的模型。这样我似乎就可以不用考虑模型能力，直接看结果选就好了。worktree确实有各种依赖管理问题，细节上也有待打磨，并发烧token钱包也会顶不住。但是如果成本降下来，并发跑Agent是一个范式上的变化，用法上的根本改变。

一旦推理成本持续下降，而在大部分场景下模型的能力拉不开差距，最终token的需求只会继续爆发。但因为API兼容非常轻松，迁移成本几乎为零，光靠卖API没有什么护城河。我选择开始买入上游的英伟达，并且继续看多大模型的应用层增长，加仓做出notebookLM之类应用的谷歌，看空仅靠卖API为生的企业。之后国内上市的两家LLM企业的招股书也说明大部分的利润目前还是在上游。

2026年估值越来越高，风险会更高，应该更小心，要降低预期收益。赚钱靠运气，不亏靠实力。

生活

读书

25年读的书可以分三类，一大类是投资相关的书，第二类是心理学，哲学的书，最后是其他一些非虚构类书籍，像是传记之类的。投资的书看了很多，大部分都是价值投资老生常谈的理论。其中《低风险，高回报》印象最深，主要是作者提供了非常实际的操作路径。书名虽叫低风险，更准确说是低波动、高回报。作者通过各种历史数据分析，证明了低波动的股票组合更有超额收益。

你们只需要考虑低波动率、收益和动量三个因子就能建立一个可以带来高回报和低风险的股票组合。
—— 《低风险高回报》

我觉得这个理论很有道理，开始定投了场外的红利基金。

还有一本《Die With Zero》作者提出的花钱买体验，和记忆股息理论也印象深刻。书中提倡应该在年轻身体好的时候，多体验人生，把钱花在能够长期回忆的人生体验上。并且越早，复利效应越高。

我希望我分享的訊息至少讓你重新思考關於人生那些很制式、傳統看法：要找個好工作，無止境地努力工作，然後在六、七十歲退休，在所謂的「黃金時期」度過自己的人生。　　我希望我分享的消息至少让你重新思考关于人生那些很制式、传统看法：要找个好工作，无止境地努力工作，然后在六、七十岁退休，在所谓的「黄金时期」度过自己的人生。　　可是我要問各位：為什麼要等到你的健康和生命活力都開始消退的時候？與其只顧著積存一大堆很可能一輩子都花不完的錢，不如現在就把自己的生活過得充實些，例如：追尋難忘的生活體驗、在你的孩子最能用到錢的時候把錢給他們、在還活著的時候把錢捐給慈善機構。這才是過人生。記住，歸根結底，人生在世，最重要的事就是要獲得回憶。所以你還在等什麼呢？
—— 《Die with zero》

其他印象深刻的书还有《國家為什麼會失敗》,《一个悲观主义者的积极思考》等，阅读时的划线和当时的一些想法都放在了logseq里，时常回顾一下可能又会有不一样的想法。

2026年不打算读“心理按摩”类型的偏理论书，希望读更多具体公司的传记或者财务分析的书。

旅游

今年去了3次日本，第一次是跟朋友一起抢到清明前的便宜机票，成功在樱花季期间去了关西。

虽然严格来说有些早，山上的樱花都没怎么开，但树与树的体质不能一概而论(误)，京都的樱花数量和赏樱地点非常多总有开的很好的地方。最让我惊讶的是之前去过的八坂神社，河原四条这些地方随处走都能看到一条街的樱花，我之前完全没意识到路边的都是樱花树。只要时间合适，都不需要特意去找就能遇到很美的景色。

端午的时候，直飞广岛，独游了一波。去之前也没做详细攻略，只是定了去哪几个地方，怎么去，什么时候去都没有排。以至于到了广岛市区之后，坐公交去酒店都不知道怎么付钱。上车后，以为跟京都一样统一价，拖着个大箱子上车坐下，都不知道要取乘车券。过了一会发现，这里好像并不是统一价，幸亏后上车的好心人看我懵逼给我递了一张。好在广岛市区的景点，商场都很集中，基本上电车、公交甚至走路都能覆盖，而且该有的都有很适合不愿意走路的我。广岛不同于京都，基本上没有什么古建筑。广岛城也是事后重建的，但不少地方都保留了原爆的痕迹，像是被爆的建筑，被爆树木之类的。

宫岛是广岛之行的重头戏。水上鸟居的景色、鹿、烤生蚝、200yen refill一次的酒，就值得再去一次。后面还留了一天去尾道。一座适合闲逛的小城，俯瞰濑户内海的景色很美。

10月份团建又去了一趟关西。这次去了山崎蒸馏所见学。进到酒厂参观酿造蒸馏，窖藏的过程，真是有趣的体验。酒窖里是真的香。最后还现场品尝了好多不同的威士忌，对比着喝是真能喝出年份酒贵有贵的道理，相对于年份少的要柔和很多。

除了威士忌，还喝了很多啤酒，去了各个品牌的bar。Spring Valley的一个品尝set最让人印象深刻。里面有几款酒真让我品尝出了柑橘风味而且不怎么苦。

还去泡面博物馆尝试自己搭配泡面，神户参观了明石海峡大桥。不得不说日本建筑的夜晚打光水平很高，明暗对比很好看，不是超亮的灯或者高饱和度RGB。

9月份的时候还跟朋友去了泰国。泰国跟日本就很不一样。日本是干净，秩序井然，那泰国就是秩序中又很混乱，但乱的很有生机的感觉。满大街的摩托车，还有小皮卡改的双条车。街上的感觉有种小时候国内的感觉。泰国去的芭提雅曼谷两个地方，印象最深的是711便利店的密集程度我甚至觉得比日本还高。生活成本上，在外面吃饭的价格并不便宜，但是芭提雅的住宿条件和性价比要比日本高得多。按摩、在海岛上玩项目就非常便宜。

广州从10多年前就开始说自己要做国际化大都市，但泰国真让我感觉是国际化大都市。街上的外国人含量很多。可能是生活成本低吧。我觉得真正的国际化并不是建了多少高楼，有多少「xx城」，而是一般服务员都能说上几句英语，即使不那么标准，各种地方不需要注册微信或者关注公众号就能买票，查看信息，不用坐个地铁还得安检。

在国内的自媒体或舆论环境下，泰国常被描述为一个不那么安全的地方，但我一直不相信这些说法，觉得都是在扯淡。这次在曼谷打车去吃饭。朋友吃到一半发现iPhone备用机找不到，我们也不确定在哪里丢了。抱着试一试的态度，通过bolt app给网约车司机打电话用蹩脚的英语问司机有没有看到手机。司机立刻就说有，并且愿意送到吃饭的地方。后面让饭店的服务员跟司机用泰语沟通地点，成功拿回手机。这待遇在国内都不一定能够有。在泰国出行基本上都是靠打车，走高速需要补高速费，这么多次都没有被骗过。遇到不确定或者沟通不顺畅的时候，司机就直接走人工通道把找回来的钱递回来。这些小细节让我对泰国的印象很好。肯定会再去的。

2026年希望可以去更多的地方玩，多见见世面积累记忆股息吧。

• 完 -

10月去了日本旅游，团建4天假加上额外请的一天年假和周末玩了9天。上次出国还是已经是18年去的亚庇。这也是第一次去发达国家，体验非常好，要问有多好，那一句话总结就是：已经开始计划下次啥时候去了。这次坂进京出玩了大阪、京都、东京三个城市。趁现在刚回来没几天我觉得有必要记录一下，相比于记录行程流水账，我更想记录一下感受。但是不按时间轴写，又没点啥命题作文也不知道写啥，所以打算分成衣食住行+玩几部分乱序写一下见闻与感想。

分开讲

衣

走在街上，如果让我区分亚洲面孔人是不是日本人，我觉得是很难的，除了两种 CosPlay 和穿校服的学生。在日本的好几天是工作日，但经常会在我们一般认为的上学时间在外面看到穿校服的学生。几乎每天都会看到有学生在外面秋游，甚至在新干线的站台上。回想以前在学校，体育课还能上就算不错了，坐高铁去旅游属实超纲。上学时间也挺奇妙的，9点多还能在京都街头看到零零散散学生，路过一个中学4点出头，体育馆就传来练习剑道劈砍的声音，学生也陆陆续续放学了。深圳周末晚上地铁上经常能看到学生在争分夺秒做卷子，让人不得不感叹卷都。

CosPlay 的出镜率也非常高，但最让我印象深刻的是最后一天去机场的路上，在池袋可能是什么活动（下周就万圣节了）也可能是日本普通的周日，路上全是CosPlay。其中有一家四口，妈妈扮成了伏拉梅拖着一个芙丽莲女儿，女儿拿着纸皮做成的魔杖提前范起来中二病。爸爸是修塔尔克抱着另一个扮成了菲伦的小女儿。没想到会碰到一家老小一起cos的场面。日本的动漫、游戏文化是真的很流行，最后一天在东京8点多不到九点看到一个店门口排了超长的队伍，走过去一看竟然是个游戏厅。

食

比起讲吃了啥，有啥好吃更想记录一下一些吃饭时候的遭遇。

便利店不能吃东西

在日本这几天的早餐经常就是在便利店买东西吃。在中国全家/711这种有卖盒饭的便利店，基本都有座位能吃东西，但到日本的第一个早上，我们跑去一个全家买了早餐，结完账之后就发现并没有地方坐着吃。正巧碰到一个当地人在里面打热水（应该是在冲泡面或者啥东西），我们以为那个装水的地方就是吃饭的地方，就打算站那里吃。正打开吃的东西，他就跟我们说里面不能吃东西得到外面吃。出门后发现，门口的的停车码表上有好几个饮料瓶，旁边的车上也有人捧着盒饭在吃。后面查了才知道日本便利店买东西吃，如果在里面吃税率是10%，不在里面吃就是8%，很多便利店都撤掉了吃饭的地方。后来在京都碰到一家有吃饭座位的全家，结账的时候收银员就会问你是不是在这吃。

左边是堂食10%，右边8%

27万日元的底薪的餐厅服务员

將工作視為生產，讓我們得以問出這些問題，其重要性無可言喻。然而將工作視為生產的見解，是否給予我們回答問題的憑藉，就不是那麼明朗了。逕自創造一個不同現狀的社會，運行一套不同的規則——這件事的難處，在我看來有跡可循。難就難在，人們得承認有大量工作嚴格說來屬於照護性質，而非生產性質；此外，就連擺明非關個人的工作也有照護的面向。即便我們不喜歡這個世界的樣貌，但事實是我們大部分行動裡有意識的目標（不論行動屬於生產與否），仍舊是善待他人——經常是萬中選一的他人。我們的行動鑲嵌在照護的關係中，不過多數的照護關係都需要我們多少抽離習以為常的世界。 —— 《Bullshit Jobs》

在日本服务非常好，服务员的精神状态也都很好。吃完饭说声delicious，会走出来跟你鞠躬。问个路即便不是工作人员也带你走一大段，走到路口。一个停车场门口两个人指挥交通，过程中手势做足让你听不懂日语也看得懂。都说日本人力成本非常贵，在东京一个吃饭的地方看到，无经验者的餐厅服务员底薪 27万日元。不知道在日本算是什么水平，但换算成人民币是相当高工资了。

行

一个是日本的电车（火车/地铁分不清楚）。它的闸机是长开的，默认选择信任，只有遇到没刷卡冲进去的人之后，才会再关上。车厢里其实没有传的或者想像中的安静，日本人也是会聊天说话的。不过有不少人会拿一本很小的书在看，这是国内很少见到的。

路上走着，红绿灯只要一闪一定过不去，不闪就能过去，不像深圳一上来就闪… 还有一个比较让我吃惊的是日本街头吸烟区竟然是排队吸烟的。一般吸烟区，一群人站一堆吸还挺正常的。但竟然看到有一个吸烟区一人一个格子，格子满了就在外面排队。

住

前面几天在关西住酒店没啥特别的。最后在东京住民宿就体验到了区别。最大的感受有两点，垃圾分类和极差的隔音。垃圾分类分可燃和资源型垃圾，基本上塑料，易拉罐扔资源性垃圾，纸啥的扔可燃型垃圾了。分成两类还挺好区分的，不过属于是没有开火做饭平时垃圾也就那几样。提前分好类当然是比较科学的做法，减轻了后面重新分拣的负担。日本街头很多扔垃圾的地方只能扔饮料瓶易拉罐，其他一些垃圾只能揣一路找便利店去扔，不过大家也都很守规矩。

可能是因为地震还是啥原因，房子都是木，墙很薄，隔音非常差劲，更奇葩的是离铁路非常的近。印象最深刻是江之岛电车基本上贴着居民楼走。虽说经过居民区会减速，但减速刹车本身就很吵。类似这样铁路跟居民楼挨着的情况见的很多，这是我觉得非常难以理解的点。ptt 上类似的疑惑，但并没有非常好的解答我的疑惑

玩

1. 日本确实突出一个信任，很多地方门票都不怎么验，主要靠自觉。比如清水寺的门票就一个书签一样的纸，没有日期，门口也只是看一眼就完了。

2. USJ任天堂（马里奥）世界真的超级帅，刚进去的第一印象无敌。入口是个马里奥绿色水管样式的隧道，光线很暗，然后一出去看到马里奥世界，豁然开朗真的非常帅。

3. 天气很好的京都。雨后的京都街道，蓝天白云。鸭川真有鸭子。

4. 天气不好的镰仓，天气不好，本来想去富士山改去镰仓了。虽然天气不好海边也不怎么好看，但有圣地巡礼加成比东京市区好玩多了。

5. 在东京芝公园拍照，两日本大妈非常热情主动找我搭话，指着旁边一棵树说让我拍这个好。树上只有孤零零一朵樱花，怕我看不到还不停强调这是sakura。我也把上午在新宿御苑拍的樱花给她们看了。日语没白学，至少听懂了，配合手机上图片和文字也是能交流的。图里左边是新宿御苑拍的，右边是芝公园拍的(来自Gemini的辨别)。在日本这段时间没有墙的限制，各种AI随便用真的方便。以至于最后回到深圳的时候用谷歌翻译死活没反应，一段时间过后才反应过来被墙了。

export type ConstructorType<C extends abstract new (...args: any) => any> = (  ...args: ConstructorParameters<C>) => InstanceType<C>;

typeof?

由于 JavaScript 的 class 无法很好 tree shaking，加上函数写起来非常方便，所以平时很少用 class。但最近开始折腾 langchainjs，它基本上是跟 python 版本一一对应的，所以写得很向对象也大量用了 class。我想写一个工厂函数传入一些默认参数，却发现拿不到准确的 constructor 的类型。在 tg 群友的指点下搞懂了这里问题，关键就在于区分实例类型和 constructor 的类型。

import { OpenAI } from "langchain/llms/openai";const createOpenAI: OpenAI["constructor"] = (options, config) => {  //                       ^? Function  return new OpenAI({ temperature: 0, ...options }, config);};

这个问题可以简化成下面的代码：

class Foo {  constructor(foo: string) {}}type A = Foo;type B = typeof Foo;type C = A["constructor"];//   ^? type C = Function

如何从Foo通过类型运算获取到(name: string) => Foo这样的类型，而不是像上面一样拿到的是个Function。

在 TypeScript 中typeof除了运行态的语义外，还可以将 Value 转成 Type 用做类型运算。例如const a: typeof 123 = 456。但上面这个A跟B通过 alias 拿到的都是类型却很不一样。

A 是实例化后的 instanceType，而 B 是构造器 constructor 的 type

在运行态 JavaScript 中实例原型链上的 constructor 字段引用指向Foo，所以A['constructor']会提示Function类型（没有精确的参数类型）。这个 GitHub issue 在讨论这个行为。

const a = new Foo("a");a.constructor === Foo; // true

再来看下面这个例子：

class Foo {  constructor(public bar: string) {}  static baz: 123;}type A = Foo;type B = typeof Foo;type C = A["bar"]; // stringtype D = B["bar"]; // Property 'bar' does not exist on type 'typeof Foo'.(2339)type E = A["baz"]; // Property 'baz' does not exist on type 'Foo'.(2339)type F = B["baz"]; // 123

Foo 中声明了两个 field，其中的 baz 是个 static filed，A 由于是实例化过的所以有 bar 没 baz，而 B 由于是 constructor 所以有 baz，没 bar

infer 实现

实际上 TypeScript 文档 中有提到constructor signature，构造函数类型可以写成new (...args: P) => T

TL;DR 中的实现可以不借助 内置的 Utility Types 而用 infer 实现：Playground。

type ConstructorType<C> = C extends abstract new (...args: infer P) => infer R  ? (...args: P) => R  : never;

Server Component

什么东西会到达 client side

Server Component 的一大亮点就是可以减少 client bundle size，但是究竟减少了什么东西呢。要回答这个问题，我们首先要了解什么东西会被发送到 client side。

在 Server Component 之前 Next.js 提供的 getStaticProps/getServerSideProps 做 SSG/SSR。这两个函数跟 Server Component 一样也是在服务端执行代码。函数返回值里的props 对象能在页面组件的 props 中拿到。如果你研究过 Next.js 生成的页面就会发现，除了 SSR/SSG 生成的 HTML 里有 props 相关的内容，还有一个 id 为_NEXT_DATA的 script tag，把服务端生成的 props 以 json 的形式又存了一遍，用来给 client side 做 hydrate。

getStaticProps/getServerSideProps 在这里作为一个 client/server 的边界，函数内部的依赖只存在于 server，它返回值中的props会序列化成 JSON 送到 client side。除此之外，由于 hydrate 结果需要跟预渲染的 HTML 严格对应，所以所有 Page 组件用到的 JavaScript 都会进 client side。

对于 Server Component 而言，也存在类似的边界。这个边界从 Page 级变为了粒度更细的 Component 级，即 Server Component 和使用 use client 声明的 Client Component 之间的边界。而且由于 Server Compoent 不能使用绑定事件，也不能使用 hook 声明 state，所以 Server Component 不需要经过 hydrate 的过程，相关的依赖不需要发送的 client side。

但数据穿过这个边界的时候，同样也需要发送到 client side，这个过程中同样会经过序列化，所以当我们把函数之类无法序列化的东西从 Server Component 作为 props 时，会报错。这个传输的序列化格式也不是 json，而是 react 实现的特殊格式。

["$","meta",null,{"name":"generator","content":"Hexo.js & Next.js"}]5:I{"id":"9065","name":"","chunks":["313:style9-d090fe9341ff38d2","71:71-82b18e6f5d306cf7","65:65-bf32b72b8c0f255e","467:467-e4e9ede7ad711e5f","605:app/post/[slug]/page-5726ac97dd32c035"],"async":false}

在 Next.js ouput 目录中可以看到.rsc后缀的文件有类似这样的内容，在这个例子中 Client component 操作导致 Server Component 变化也会序列化成这种格式发送。但是对于静态的博客内容就不用考虑了。

Hexo 集成

毕竟有前人经验，所以过程还算顺利。一个遇到的问题是 hexo 中可能是 worker 导致引用不同 instanceof 失效，需要 patch。其他的一些问题只需把相关的包要加到 Next.js 的serverComponentsExternalPackages中让它不走 webpack bundle 就基本没问题了。hexo 初始化完之后基本东西都可以hexo.locals中取到，跟写 ejs 模版区别不大。

相比在getStaticProps中调用 hexo，直接在 Server component 中调用更加自然也不用手动在 client side 代码 从 JSON 构建 ReactNode 了。更细粒度的服务端组件可以更方便的在服务端一些事情。比如在 Image 组件分成两块，Server Compoent 部分可以通过 plaiceholder 获取图片宽高生成占位符，然后再传给 Client Side component 做 lazy load / 点击放大之类的事情。

CSS 方案选择

Atomic CSS 些很有吸引力的好处如：更小而且不容易增长的 css 大小，不用考虑优先级问题等好处。而像 style9 这样的 CSS in JS 库更是把“将一个 CSS 拆成多个原子声明“的过程自动化了。所以最开始一版实现中，我也尝试了使用 style9 但是由于当时对它还有市面上其他支持编译期生成的 CSS in JS 库对 Next 13 的支持都有这样那样的问题。我还是用 tailwindcss 完整实现了一遍而没有用 style9。

Tailwind 的问题

上面提到 Server Component 传给 Client Component 的 props 会被序列化传给 client Side，而 className 也不例外。相当于每次在 className 上写一个 byte client 上就要多下两个 byte（不考虑压缩），一个在 pre rendered 的 HTML 一个在后面的 Wire 格式对象中

style9 有 incrementalClassnames 选项可以生成更短的 className。除此之外还有同样的 class 优先级跟生成的 CSS 顺序有关，难以覆盖的问题，开发体验不是那么好。

迁移到 style9

后来 style9-webpack 支持了 Next.js 13 的 app dir，然后发现了 stailwc 这样的 macro 可以进行转换，决定从 Tailwind 迁移到 style9。这样我既可以用 CSS in JS 更获得更好的开发体验，也不会丢掉 Tailwind 这样的 preset 带来统一的设计风格。

stailwc 和 style9 两者都会在编译期对代码进行操作，stailwc 是一个 swc 插件，style9 是一个 babel 插件。Next.js 中提供了 experimental.swcPlugins 配置，style9 则提供了相关的 Next.js 插件。我首先写出这样的代码

const styles = style9.create({    main: tw`mx-auto max-w-prose`})<div className={styles('main')}></div>

需要先过 swc 将代码转成

const styles = style9.create({    main: { marginLeft: 'auto', marginRight: 'auto', maxWidth: '65ch' }})<div className={styles('main')}></div>

再给到 style9。这里涉及到先后问题，style9-webpack 提供的 webpack 配置把 babel 的 loader 放在前面，需要 patch 来改个顺序。

Tailwind 中除了单个的 CSS Utilities 还有”component“，类似 bluma 那样单个类名带很多样式的传统 CSS 库。它的 typography 插件就提供了一套富文本内容的样式，默认通过 class prose引入。这个对我来说是非常实用，毕竟写一套这样的样式很容易有遗漏的情况。而且对我来说，很容易就陷入整体观感上不好，但是不知道具体哪奇怪怎么改的情况。style9 API 设计上鼓励写原子化 style，不支持任意带 nested selector，所以并不支持用 prose。最后我保留了 Tailwind 并将 Tailwnd 配置的@tailwind utilities;删去，只用它的 base 和 component。utilities 部分给 stailwc 和 style9 生成。

迁移完成后，发现 incrementalClassnames 配置开启后，带缓存的 build 会出现 CSS 声明互相串的问题，所以没有打开。首页的 HTML 反而大了 1 ～ 2KB，但 CSS 文件大小了不少。=_=→
仅仅是把 utilities 部分用 stlye9 重写就能小那么多是出乎我意料的。

迁移到 Next.js 可以让博客有更加现代化的开发和用户体验，在过程中体验了一把 Next.js 13 的部分新功能。虽说用到 Server Component 但是本质上网站还是个静态站，还是希望能够静态部署。目前为止用了 Cloudflare Pages 还无法部署成功。期待 next export 的功能在 app dir 中实现～

自定义 rules

rules 的写法详细的可以看ESLint 文档，不再赘述。
最重要的地方就是 export 的对象的 create 对象。在 create 对象中，key 是一个selector,value 则是对应的 handler，在 handler 就可以通过context.report来对有问题的代码报错。语法树可以用AST Explorer来看。

例子：小程序自定义组件中防止额外触发内置事件

在小程序自定义组件可以通过this.triggerEvent('eventName', ...)来触发eventName事件。但是有一些内置事件是不需要额外触发的，比如tap, longpress 之类的。我们就而可以写一个 rule 来禁止手动触发这些事件。
根据AST，可以写出下面这个 rule。

// 内置事件const bulidinEvents = [  'tap',  'longpress',  'longtap',  // ...  ];/** @type {import('eslint').Rule.RuleModule} */module.exports = {  meta: {    type: 'problem',    docs: {      description: 'disallow trigger builtin events manually in miniprogram',      category: 'Possible Errors',      recommended: true,    },    schema: [      {        enum: ['always', 'never'],      },    ],  },  create: function (context) {    return {      CallExpression: function (node) {        const { callee, arguments: args } = node;        if (callee.type === 'MemberExpression') {          const { object, property } = callee;          if (object.type === 'ThisExpression') {            if (              property.type === 'Identifier' &&              property.name === 'triggerEvent'            ) {              if (args.length > 0) {                const firstArgrament = args[0];                const eventName = firstArgrament.value;                if (bulidinEvents.includes(eventName)) {                  context.report({                    node,                    message: `trigger builtin events manually in miniprogram is forbidden`,                  });                }              }            }          }        }      },    };  },};

rulesdir

要让 rule 生效最简单的方式就是使用runtime rule 的机制，但是不是任何时候我们都有机会去加--rules。例如在一些集成度比较高的框架中比如 CRA 之类，只提供了修改 config 的方式，不支持修改命令行参数。

如果为了项目特异的规则专门发一个 plugin 的 npm 包，不仅显得有些小题大做，还不好维护。最好还是能把 rules 放在主项目内。

这里我们可以用eslint-plugin-rulesdir,它利用了 eslint plugin 的机制，在 rules getter 中获取某个目录内的所有 JS 文件作为 rules, 这样们就能在 rules 配置中通过rulesdir/<fileanme>来使用自定义的 rules 了。

比如将上面我们写的 rule 命名为no-trigger-builtin-events-manually.js，放到对应目录中，就而可以配置

'rulesdir/no-trigger-builtin-events-manually': ['error', 'always']

来禁用多余的手动事件触发。

不言论的自由

我先“抛一下书包”。

黄霑曾写过题为《不言論的自由》的文章，讲了在不想讲的时候可以选择不讲的珍贵。

起初，纳粹抓共产党人的时候，
我沉默，因为我不是共产党人。

当他们抓社会民主主义者的时候，
我沉默，因为我不是社会民主主义者。

当他们抓工会成员的时候，
我沉默，因为我不是工会成员。

当他们抓犹太人的时候，
我沉默，因为我不是犹太人。

最后当他们来抓我时，
再也没有人站起来为我说话了。

《起初他们》则讲了作者对自己『不讲』的忏悔。

一个写的是『不讲』，一个写的是『讲』。现在各路明星都似乎要在“大是大非”上表态，才能在中国市场混下去。其中当属港台明星的境遇最惨了。由于人为的高墙限制，港台与大陆的人所看到的东西有很大的差异，加上交流受限，在这些议题上的观点有非常大的差异。一边是不能不讲，讲了又会伤了另一边的感情，被骂人品有问题实在是难做。

黄霑讲当时欣赏不到的不言论的自由，此刻相信不少人都欣赏到了吧。如果可以选择不讲，大家都不用伤感情，都不戳破这层窗户纸，保留朦胧美，都可以选择相信他们是自己心中的样子。但《起初他们》就告诫我们『不讲』可能带来的后果。关键在于，这一切都是选择，可以选择『讲』，也可以选择『不讲』。但是现在的社会风气，利益等等因素却逼得他们不得不表态。

观点不同，事实不辩

观点不同，事实不辩

这句话是从倪匡的一个访问中听到的，意思是观点不同可以讨论，但是事实是不容争辩的。我非常认同，这也暗含了一个讨论的前提。讨论双方对于事实的认知是对等的。

互联网最大的问题之一大概是，懂得说「我没有足够的信息使得我可以拥有一个观点」的人实在是太少了。

这是一位网友的微博。

在这前几天的中美高层会议，一段 18 秒的视频在各大官媒，自媒体传开。主要内容是我国外交官对美国致开场白严重超时，不遵守基本外交礼节的行为做出严正回应。
当天各大社交媒体，微信都是这一段视频和关于美国致开场白严重超时的报道。但是却没有看到”严重超时“具体究竟超了多久。我们能看到的这段 18 秒的视频，港台同胞相信也可以看到。而在 Facebook 上 ABC News 对此次会谈做了媒体视角的全程直播。这也是港台同胞们能够在 Facebook 看到的东西。很自然的，双方对事实认知的差异在双方的观点上也体现了出来。

然而抛开人为限制造成的困难不说，要改变他人心目中认知的事实是一件很难的事。可能只有自己或身边的人遭遇才能改变一个人的认知的事实。实习期间，一位同样是实习生的同事是新疆汉人。从他口中说出的东西，跟这个人说的(Archive) 对新疆的描述上很相似。当一个人面对面的跟你说这些事情的时候，那种感觉确实是不一样的，这是跟网络世界隔着屏幕看文字报道完全不同的。同理心，或者说换位思考是实习期间另一位实习生同事常说的话。或许我们更多时候应该把注意力从“宏大叙事”转移到个人，将心比心地想一下。

END

至少我自己应该尊重『不讲』的选择。谨记『观点不同，事实不辩』。

。。。。。。

作为一个从小就是看香港电视，电影，听广东歌长大的广东人。衷心希望香港可以加油，再创辉煌。有位我很欣赏的歌手和作曲人林家谦的一段关于广东歌的话。

你很难和人去争论，「点解你不喜欢广东歌」「你一定要支持广东歌的」
这样的争论和强迫人家去接受其实不是好事
你要人家接受，你要先把东西给做好

言者无心，听者有意，我想不只是广东歌是这样的。

NodeRSSBot的公开 Demo @NodeRSS_bot 随着项目的开源一同上线。也运行了有将近两年了。截至今日（2020/11/18）Demo 有活跃订阅源 3900+个。Demo 用 docker 部署在了一台 1C1G 的digitalocean主机上，设定为每十五分钟抓取一次。由于每 15 分钟需要抓取 3k+的源地址是一个不太轻松的活，抓取的部分是单独使用一个 child_process 进行的。随着订阅数的增长，代码中的一些问题也显现了出来。近期发现抓取进程占用的内存相当的高。特别是在网络不畅通的环境（比如墙内），因为got的重试和超时机制，内存占用甚至会突破 Node.js 的限制而导致进程退出。

排查

工具

排查内存占用，首先需要找出哪些东西占用了内存。这就用到了 Chrome Dev Tool 中的 memory 面板，在这里可以加载 v8 的 heapsnapshot 并且提供总览，比较等的视图来查找内存占用（被持有）的原因。具体的用法可以看Google 的官方文档在这里不在赘述。但是官方文档中有部分的东西并没有说的很清楚。比如比较视图的表头几个带#号的含义就困扰了我一阵子。在 tg 群友的推荐下收获这篇文章是个很好的补充。

Node.js 12 中加入了–heapsnapshot-signal选项，可以用来生成 heapshot。

String 占用

找出内存占用最快的方式莫过于将一大一小两个 snapshot 放到对比视图中看差值。kill 一番之后收获.heapsnapshot两个。

可以看出字符串占了很多，比起别的多了一个数量级。具体来说是 feed 的 xml。下面第二大的 ArrayBufferData 也是同样的东西占的最多。具体到代码的话就是res中的body和rawBody。

找到问题了，挑选一个幸运儿，根据幸运儿的 Retainers 调整代码。直到 res 这两个属性的引用全部被 delete。本地运行fetch.js分析 snapshot。

但是发现一个问题，rss-parser 使用的 xml2js 解析整一个 xml string。rss 中的很多 fieldcontent,title等都是这个 string 的 slice。即便除了 sliced string 没有任何别的 retainer，这个 string 也没有被 gc。由于 string 是 read only 的，所以这样的优化有助于计算性能。但是在 RSSBot 中就非常致命了。一个 feed 小的也有几百 KB，snapshot 中看到最大的能有 7M。

解决

考虑到我完全不需要 rss 中除title, link之外的其他 field。所以我决定直接把 rss-parser 拿掉，换用camaro正如 camaro 作者在 README 中写的一样

The whole reason of me creating this is because most of the time, I’m just interested in some of the data in the whole XML mess.

考虑到两次 snapshot 的时间间隔不一致，这样的效果也算是个不小的提升了。但是运行时间长了的话 heap 还是会上到 400MB。还有改进的空间。

p-map => fastq

代码中使用 p-map 控制请求的并发数量。本来以为不会出现如此长的数组。但阅读 p-map 源码之后发现，p-map 并不等于任务队列，整个数组和结果数组都会保存起来。（废话）不然怎么叫 map

解决

是误用了，换掉。我没有选择换成同一系列的p-queue, 因为他的 api 设计不太合适。然后找到了fastq,作者，stars，used by 看下来，再看一下代码。靠谱！果断换掉。

一切看起来是这么的美好~

进一步优化

Manual gc

继续找占用内存的根源，发现还是有一些 xml string 阴魂不散。仔细检查 snapshot，确实应该要被 gc 才对的。于是决定手动 tigger gc。Node.js 提供 --exposed-gc选项。在 child_process 的 execArgv 中加上就能使用global.gc手动触发 gc。递归调用setTimeout做一个定时 3 分钟一次的 gc。效果显著，snapshot 再也没有阴魂不散的 xml string 了。
在本地长期运行，关闭代理模拟大量 feed 出错的情况，多次触发 snapshot，gc 后的 heap 大小表现还是很不错的。

检查 workQueue 情况

用上了fastq之后情况变成了定时向 queue 中 push 要抓取的 feed。这是检查 queue 长度（任务完成/堆积情况）就显得很重要了。受到--heapsnapshot-signal启发。绑定信号 handler，在接收到信号时 log 队列长度。Demo 实测concurrency设置在 500 的情况下，默认 40 秒请求 timeout。一轮 queue 清空约用时 3 分钟。

总结感受

heapsnapshot 是分析内存占用的利器。但是网上的资料还是比较少，google 的官方文档也也没有讲清楚一些细节。这么走下来好像很轻松，但是不太熟悉这样的分析，实际上花了很长时间才定位出问题。必须要感谢 tg 群友的提点。

最后上一幅digitalocean的资源占用图。

看到这一个阶梯，总算觉得时间没有白费。

未来展望

可能会考虑别的 schedule 的方法而不是统一在一个时间内抓取全部 feed。bot 开始的时候设计就是多个用户订阅同一个 feed 不会多次请求。这当然限制了功能，比如说每个抓取间隔是全局的而不是每个 feed 可调节的。Miniflux则是将(feed_id,user_id)作为一个超键。提供了更丰富的功能，但是也导致会对多用户订阅同一个 feed 时会发多个请求。

本文写于 2020 年 3 月 16 日

(async function () {  const $main = document.getElementById("main");  const resp = await fetch("https://v1.jinrishici.com/all.json");  const data = await resp.json();  $main.textContent = data.content;})();

实例的代码很简单。但是用到了 ES2017 的 async 语法。使用的依赖版本可以在package.json中看到就不赘述了。

UglifyJS 只支持 ES5

我们很轻松的就可以写出类似这样的 gulpfile

const gulp = require("gulp");const rename = require("gulp-rename");const uglify = require("gulp-uglify");const babel = require("gulp-babel");gulp.task("js", () => {  return gulp    .src("main.js")    .pipe(uglify())    .pipe(rename({ suffix: ".min" }))    .pipe(gulp.dest("."));});gulp.task("default", gulp.parallel("js"));

一跑就会发现 UglifyJS 报错。

[13:15:26] GulpUglifyError: unable to minify JavaScriptCaused by: SyntaxError: Unexpected token: keyword «function», expected: punc «)»

gulp-uglify使用的UglifyJS只支持 ES5。

有两个方法解决

1. 换用gulp-uglify-es它使用terser支持 ES6+语法压缩。
2. 先用 Babel 降级

如果不用考虑兼容性问题，使用第一种方法就不需要往下看了。如果我早点知道的话就不会花时间去折腾了

我当时很自然的想到用 Babel 降级。

引入 Babel 之后的 gulpfile 长这样。

const gulp = require("gulp");const rename = require("gulp-rename");const uglify = require("gulp-uglify");const babel = require("gulp-babel");gulp.task("js", () => {  return gulp    .src("main.js")    .pipe(      babel({        presets: ["@babel/preset-env"],      })    )    .pipe(uglify())    .pipe(rename({ suffix: ".min" }))    .pipe(gulp.dest("."));});gulp.task("default", gulp.parallel("js"));

async 导致的 Babel Polyfill 缺失

gulp build 没有报错。但是假如你也和例子中一样使用了async的话，运行的时候浏览器会报错。

ReferenceError: regeneratorRuntime is not defined

网上找到的信息多半是安装babel-polyfill,也有说要安装transform-runtime等等方法配置 babel。但是babel-polyfill已经Deprecated了，为了跟得上时代我们还是得跟官方文档，在babel-preset-env 的官方文档就能找了正确的配置方法。我们要引入core-js。

安装好 core-js

npm install core-js@3 --save

并且更改 gulpfile 中的 babel options

{    presets: [        ['@babel/preset-env', { useBuiltIns: 'usage', corejs: 3 }]    ],}

浏览器 Require 缺失

一通操作下来，浏览器仍然会在运行时报错

ReferenceError: require is not defined

说到 require 自然会想到Browserify。于是依照文档借助 Babelify 我们很自然的写出类似这样的 gulpfile

const gulp = require("gulp");const rename = require("gulp-rename");const uglify = require("gulp-uglify");const babel = require("gulp-babel");const browserify = require("browserify");gulp.task("js", () => {  return browserify("main.js")    .transform("babelify", {      presets: [["@babel/preset-env", { useBuiltIns: "usage", corejs: 3 }]],    })    .bundle()    .pipe(uglify())    .pipe(rename({ suffix: ".min" }))    .pipe(gulp.dest("."));});gulp.task("default", gulp.parallel("js"));

build 一下遇到了这样奇怪的错误，

TypeError: file.isNull is not a function

Vinyl stream 不兼容

问题出在 Browserify 的流和 Gulp 的流不兼容。Gulp 的流使用的是Vinyl,而 browserify 使用的 node fs 的流。我们需要额外做一些转换。

安装相关的包。

npm i -D vinyl-source-streamnpm i -D vinyl-buffer

最终 gulpfile

const gulp = require("gulp");const rename = require("gulp-rename");const uglify = require("gulp-uglify");const babel = require("gulp-babel");const browserify = require("browserify");const source = require("vinyl-source-stream");const buffer = require("vinyl-buffer");gulp.task("js", () => {  return browserify("main.js")    .transform("babelify", {      presets: [["@babel/preset-env", { useBuiltIns: "usage", corejs: 3 }]],    })    .bundle()    .pipe(source("main.js"))    .pipe(buffer())    .pipe(uglify())    .pipe(rename({ suffix: ".min" }))    .pipe(gulp.dest("."));});gulp.task("default", gulp.parallel("js"));

总结

至此这么一小段 js 终于被编译成可以运行的 minify 的 ES5 了。可是这么一通操作下来引入了 core-js 做 polyfill 体积不减反增maxify。

4.0K    main.js36K     main.min.js

所以说如果不考虑兼容性就直接用gulp-uglify-es好了。

前端的构建工具大版本总是不兼容，网上的信息也很多已经过时了。这篇文章估计在不久之后也会过时的。不得不说跟上时代最好的方法还是官方文档呀。

实例放在了 GitHub，各个步骤都对应的分支。
我们还可以借助github-history来看 gulpfile 的变化。

缓存替换算法决定了在有限的容量的缓存中，有新的项进入的时候选择哪一项被剔除的问题。
缓存算法有很多

假如我们以K-V形式的缓存为例。通常 KV 形式的缓存为了有O(1)的读取速度都会维护一个HashMap
那么不同的算法的其中一个不同之处就是保存替换时决策所需要的信息而产生的额外的数据结构了。

LRU

LRU(Least recently used) 最近最少使用，实际上就是缓存中最久未被使用的项会被优先剔除。

它的思想是如果一个项很久都没被使用了，那么它应该被剔除缓存。

但是当缓存的访问是循环的顺序遍历，而且缓存容量不足以容纳遍历的项时，缓存项就会频繁进出影响效率。

实现

Leetcode 上有 LRU Cache 的题目

为了知道最近最少访问的信息通常 LRU 的实现会采用双链表保存缓存项。因为缓存的数量会动态变化，所以会选择链表。而且会有不少的删除节点操作，为了达到O(1)的删除操作所以会用双链表。

type CacheNode struct {key   intvalue intprev  *CacheNodenext  *CacheNode}type LRUCache struct {size     intcapacity inthead     *CacheNodetail     *CacheNodecache    map[int]*CacheNode}

我们保存链表的尾指针，每当有缓存项的访问或者新项都将对应的节点移到链表的头。头插入和删除节点的操作都是O(1)

完整实现

hashlru

还有一种近似的 LRU 算法HashLRU通过两个HashMap的交换实现O(1)的复杂度，在实际的Benchmark中的表现也很好。

LFU

LFU(Least Frequently Used) 最近最不频繁使用，缓存中被使用的次数最少的项会被优先剔除。它认为被用的越少的项越应该移除。

LFU 克服了 LRU 在大规模遍历时的缺点。但是容易导致旧数据的积累。同时新数据因为使用次数少容易反复被移出缓存导致长期无法积累跟大的使用次数。

实现

Leetcode 上有 LFU Cache 的题目
为了维护相关的访问频次信息需要额外的数据结构。一种各操作 (增删查) 都为O(1)的形式是使用两个双链表。其中一个保存访问频次，另一个用于保存某频次对应的节点。因为频次链表会经常有增删操作所以使用双链表。而保存某频次对应节点的链表也可以使用 HashMap 或者动态表。

type CacheNode struct {key    intvalue  intprev   *CacheNodenext   *CacheNodeparent *FreqNode}type FreqNode struct {freq inthead *CacheNodetail *CacheNodeprev *FreqNodenext *FreqNode}type LFUCache struct {size intcapacity intcache map[int]*CacheNodelfuHead *FreqNode}

缓存保存一个使用次数为 0 的频次节点的指针。新项加入时，头插入到次数为 1 的频次节点，时间复杂度为O(1)。

当某一个频次的节点 (除 0 以外) 所持有的缓存项个数为 0 时，该频次节点就会被移除。这样保证了 0 频次节点的下一个节点总是缓存中使用次数最少的。

此时，只要在频次节点中维护缓存项链表的尾指针，就知道了缓存中使用此是最少最老旧的缓存项。此番操作 (lfuHead.next.head) 的时间复杂度也是O(1)

完整实现

ARC

ARC(Adaptive replacement cache) 同时使用 LRU 和 LFU。通过动态调整 LRU，LFU 的容量达到自适应的效果。
缓存中除了 LRU 和 LFU 所需的数据结构外，额外增加了两条链表 LRU 和 LFU 各一个称为 Ghost List。
开始时缓存容量被平分 LRU 和 LFU 两部分。当新项加入时，先加入到 LRU 中。当缓存项被访问而 LFU 中没有时，加入到 LFU 中。
如果缓存项被移除则将它的 Key 加入到对应的 Ghost List 中。每当缓存不命中时，都会检查 Ghost List。假如 Ghost List 中含有当前不命中的 Key 则该 Ghost List 对应的缓存的容量应该增加。

参考文章

• Cache Replacement Policy Wiki
• LFU Cache Wiki
• An O(1) algorithm for implementing the LFU cache eviction scheme
• Hash LRU
• Leetcode discuss

前段时间刷推的时候看到了Chrome 开始原生支持 lazy load 的新闻。简单的说就是 Chrome76 开始支持一个 loading 属性。有以下三种取值。

auto: Default lazy-loading behavior of the browser, which is the same as not including the attribute.lazy: Defer loading of the resource until it reaches a calculated distance from the viewport.eager: Load the resource immediately, regardless of where it's located on the page.

想到可以把它放在博客里面作为一种额外的优化。(本博客已经上了大杀器 service worker 其实大部分时候图片都是从 service worker 下载的)

花了点时间写了一个 Hexo 插件hexo-native-lazy-load。

Hexo native lazy load

这个插件要做的事情就是在 img 标签插入loading=lazy的属性。它使用了 Hexo 的filter API

第一次写 Hexo 的插件。Hexo 的文档给我的感觉很不清楚（看不懂）。很多时候数据结构都要试。有个点一开始不知道。

Hexo 插件的入口文件有全局的hexo对象，对象下有hexo.log等价于hexo-log这个 package 不需要额外引入。

经过了一段时间的迭代了，下面说说具体功能

optional fallback

在hexo.config.lazy_load.fallback !== false条件成立时，会给额外加上一个使用lazysizes的 fallback lazy load。像这样

if (!("loading" in HTMLImageElement.prototype)) {  const srp = document.createElement("script");  srp.src = "https://cdn.jsdelivr.net/npm/lazysizes@5.1.1/lazysizes.min.js";  document.body.append(srp);  const imgs = document.querySelectorAll("img");  imgs.forEach((el) => {    el.setAttribute("data-src", el.getAttribute("src"));    el.removeAttribute("src");    el.classList.add("lazyload");  });}

结合对象检测如果不支持 loading 属性则插入 fallback。

添加本地图片的宽高属性

lazy load 需要尽量减少页面的 reflow。可以通过设置固定的宽高实现。我自己的博客的图片都是放在post_asset_folder下面。那么就可以通过本地读取文件的宽高直接添加到 img 元素的属性里。

插件提供了width_height设置项。当hexo.config.post_asset_folder === true && hexo.config.lazy_load.width_height !== false条件成立时将会就会为本地的图片添加宽高。

最终的效果

支持 loading 属性的浏览器。

不支持 loading 属性的浏览器

传送门

SM4 对称分组加密

SM4 算法是一个对称分组加密算法，类似于 DES 或者 AES。对称加密也就是加密与解密的密钥是同一个。加密和解密时会将输入数据按固定的比特长度分块进行加密。不同于 AES 提供多个版本。SM4 的的分组长度为 128bit，密钥长度为 128bit。SM4 的一个有趣的地方在于，生成密钥的算法和加密算法本身是一致的。分组密码实际使用时，对于消息长度不是分组倍数长度的消息要进行 padding，以此也产生出了很多模式。

上一次实现了 SM3 算法之后看了一下 OpenSSL 的实现，觉得自己有必要学习一下 OpenSSL 的函数接口组织。所以这一次先去看了看 OpenSSL 的实现并模仿了它的接口的设计，自己实现了SM4 算法。

具体实现

#ifndef _sm4_H_#define _sm4_H_#include <stdio.h>#include <stdint.h>#define SM4_DECRYPT 0#define SM4_ENCRYPT 1#define SM4_BLOCK_SIZE    16#define SM4_KEY_SCHEDULE  32typedef struct {    int mode; // ENCRYPT OR DECRYPT    uint32_t rk[SM4_KEY_SCHEDULE]; // rotkey}sm4_ctx;    // 对外的接口    int sm4_set_key(const uint8_t *key, sm4_ctx * const ctx); // key 128 bit len 16    void sm4_encrypt(const uint8_t *in, uint8_t *out, const sm4_ctx *ctx);    void sm4_decrypt(const uint8_t *in, uint8_t *out, const sm4_ctx *ctx);    // Util 类函数    static inline uint32_t load_uint32_be(const uint8_t *b, int n);    static inline void store_uint32_be(uint32_t v, uint8_t * const b);    static inline void xor_blk(uint8_t *a, uint8_t *b);    // SM4 主要的置换函数    static inline void SM4_F(uint32_t * const blks, const uint32_t *rkg); // blks len should be 4 as 128bit    static inline uint32_t SM4_T(uint32_t X);    // 对外文件加密接口    void sm4_encrypt_file(FILE *in, FILE *out, sm4_ctx *ctx);    void sm4_decrypt_file(FILE *in, FILE *out, sm4_ctx *ctx);    void sm4_cbc_encrypt_file(FILE *in, FILE *out, sm4_ctx *ctx);    void sm4_cbc_decrypt_file(FILE *in, FILE *out, sm4_ctx *ctx);#endif // _sm4_H_

略过几个 util 类的函数，下面来分析一下算法的一些步骤。
SM4 的操作对象为 128bit 的分块，其中的运算都将 128bit 分为 32bit 的字进行。每个块 4 个字。

生成轮秘钥

此类算法一般都会先生成轮秘钥，SM4 也不例外。SM4 生成轮秘钥的算法和加密算法是几乎一致的，只是中间的一个变换有点区别。按文档实现就好。

其中 SBox 的置换操作对于一个字来说是有四个 SBox 并排置换实现的

    t |= (uint32_t)(SM4_S[(uint8_t) (X>>24)]) << 24;    t |= (uint32_t)(SM4_S[(uint8_t) (X>>16)]) << 16;    t |= (uint32_t)(SM4_S[(uint8_t) (X>>8)]) << 8;    t |= (uint32_t)SM4_S[(uint8_t) X];        t = t ^ ROT32L(t, 13) ^ ROT32L(t, 23);

如果不是提前读了 OpenSSL 的源码，我这里可能会选择强转指针而不是移位加或运算。相对强转指针这样的算法可读性明显更好。

使用轮秘钥进行加密

加密的只要算法就是 SBox 的置换和 L 变换，文档都有详细说明了。

static inline uint32_t SM4_T(uint32_t X) {uint32_t t = 0;t |= ((uint32_t)SM4_S[(uint8_t)(X>>24)]) << 24;t |= ((uint32_t)SM4_S[(uint8_t)(X>>16)]) << 16;t |= ((uint32_t)SM4_S[(uint8_t)(X>>8)]) << 8;t |= ((uint32_t)SM4_S[(uint8_t)(X)]);t ^= ROT32L(t, 2) ^ ROT32L(t, 10) ^ ROT32L(t, 18) ^ ROT32L(t, 24);return t;}

可以看到算法与轮秘钥生成算法是一样的，只是最后的 L 变换有所区别。

解密算法

SM4 解密算法与加密算法一致，只是使用轮秘钥的时候倒序使用

总结

算法实现不难。在如何提升速度方面 OpenSSL 给了一个很好的示范。它先把一个字 (32bit) 的 SBox 的置换和 L 置换的结果提前算了出来。

实际应用 - 加密文件

Padding

实际应用过程中的 message 不一定是 128bit 整数倍的，所以需要进行 padding。padding 要考虑的东西主要是要让 padding 能够被识别出来。由于输入是二进制流所以不能通过 Magic bytes 的形式区分。在网上找相关的资料可以查到不少padding 的算法。

在这里选用 PKCS#5 算法。该算法就是将不足 16byte 的块填充成 16byte，其中填充的每一块的数值都是 padding 的长度。一个特例是，当填充恰好为 16byte 的块的时候仍需填充额外的 16byte。

举个例子。

// 加入最后一块为0x12 0x34 0x56则填充长度为 16-3=13 0x0d0x12 0x34 0x56 0x0d 0x0d 0x0d 0x0d 0x0d 0x0d 0x0d 0x0d 0x0d 0x0d 0x0d 0x0d 0x0d填充恰好 16byte 的块时，仍填充 16bytes 的 0x10

额外填充的目的是确保解密后可以准确将 padding 移除而没有歧义。

CBC

CBC 从英文全称上去理解（Cipher Block Chaining）这种模式下每一个分组的明文经过 cipher 加密之前还会和前一个分组加密后的密文异或。第一个分组则会和一个随机生成的 IV 进行异或。

解密的时候则会将解密后的输出与前一个分组的密文或者 IV 进行异或得到明文。

CBC 模式的优点在于对于重复的明文加密出来的块因为经过上一个块的异或得到的密文会不一样。这样输入与明文没有固定的关系。

具体实现

首先我们生成的 IV 要是密码安全的 random bytes。Uinx 下应该读/dev/urandom可以做到，但是为了能够 Protable 用了一个库randombytes

下面看实现代码，之前有同学问我大文件怎么读。我的想法是只要获取了文件的长度，然后用流的方式一次进一部分就可以了。读到最后一块的时候再来 padding。读取文件长度可以通过fseek+ftell来实现。
需要注意的是大文件（实测 4G 左右）的时候MinGW 编译的 fseek 会出错，我暂时找不到很好的解决方式。有大佬知道的话还请指点一下。

void sm4_cbc_encrypt_file(FILE *in, FILE *out, sm4_ctx *ctx) {uint8_t iv[SM4_BLOCK_SIZE];uint8_t buf[SM4_BLOCK_SIZE], out_buf[SM4_BLOCK_SIZE];long sz, nremain, nread=0, padding_byte_len;fseek(in, 0, SEEK_END);sz = ftell(in);nremain = sz;rewind(in);    // 将 IV 至于加密输出的文件开头 16byterandombytes(iv, SM4_BLOCK_SIZE);fwrite(iv, 1, SM4_BLOCK_SIZE, out);int n=0;memcpy(out_buf, iv, SM4_BLOCK_SIZE);while(nremain >= SM4_BLOCK_SIZE) {n = fread(buf, 1, SM4_BLOCK_SIZE, in);nremain -=n;nread += n;        // SM4 CBC 模式加密xor_blk(buf, out_buf);sm4_encrypt(buf, out_buf, ctx);fwrite(out_buf, 1, SM4_BLOCK_SIZE, out);}padding_byte_len = SM4_BLOCK_SIZE - nremain;memset(buf, 0, SM4_BLOCK_SIZE);n = fread(buf, 1, nremain, in);nremain -= n;nread += n;    // 最后一块 padding 并且加密输出if(padding_byte_len != SM4_BLOCK_SIZE) {fread(buf, 1, nremain, in);memset(buf+n, padding_byte_len, padding_byte_len);xor_blk(buf, out_buf);sm4_encrypt(buf, out_buf, ctx);fwrite(out_buf, 1, SM4_BLOCK_SIZE, out);} else {memset(buf, SM4_BLOCK_SIZE, SM4_BLOCK_SIZE);xor_blk(buf, out_buf);sm4_encrypt(buf, out_buf, ctx);fwrite(out_buf, 1, SM4_BLOCK_SIZE, out);}}

解密的操作类似，知道了文件头 16byte 为 IV，先读出来，然后依次读取并且解密。因为是经过 padding 的所以最后一块一定是有 pading，而且最后一 byte 一定是 padding 长度。然后输出非 padding 部分的明文即可

n = fread(buf, 1, SM4_BLOCK_SIZE, in);sm4_decrypt(buf, out_buf, ctx);xor_blk(out_buf, iv);long padding_byte_len = out_buf[SM4_BLOCK_SIZE-1];fwrite(out_buf, 1, SM4_BLOCK_SIZE-padding_byte_len, out);

体会

学了点对称分组密码的基本结构还有具体实现吧。OpenSSL 为我节省了不少功夫少走的不少弯路。O(∩_∩)O 哈哈~

参考文章

• SM4 文档
• 欣仔带你零基础入门 SM4 加密算法
• AES 加密简介——填充算法
• CBC wiki

SM3 Hash

SM3 是一个哈希算法而不是加密。哈希是将一个任意长的输入映射到一个固定长的输出的函数。在 SM3 中输出为 256bit 长度。它的特点就是具有单向性，并且同样的输入总是映射到同样的输出。单向性从输入能轻松求出输出。但是却很难从输出反推输入。这样的性质让 Hash 有了它的应用。比如说网站后台的密码存储通常不会存储明文而是存储密码的哈希值。在需要验证密码的时候只需要计算并比对哈希值。而比特币的工作量证明也是通过不断尝试 nonce 反推哈希来实现的。

Hash 通用结构

哈希算法总是有通用的结构

1. 将输入 padding 直到恰好可以分组
2. 将输入分成 n 组 $B_{0} \ldots B_{n-1}$
3. 对初始 iv 置数
4. 迭代压缩函数 $IV_{n}=CF \left( IV_{n-1},B_{n-1} \right)$
5. 最后一个 IV 就是 Hash 值

SM3 实现

按照文档和网上查到的资料，我也实现了一个 SM3。代码放在了 GitHub。头文件如下。里面的几个函数分别对应其中的几个步骤。

#ifndef _sm3_H_#define _sm3_H_#include <stddef.h>typedef unsigned char byte;typedef unsigned int word;// paddingbyte *padding(const byte *src, size_t src_len, size_t *out_len);// 生成拓展 Block CF 需要用到word *expand_blk(const char *block, word **W_p);void reverse_by_byte(byte * const le, size_t len);// 初始化 IVvoid iv_init(word * const ivs);// CFvoid CF(word * const iv, byte* blk, const word * const W, const word * const W_p);byte *sm3(const char * const s);#endif

下面从依次分析这几个步骤
操作的层次或者说对象各有不同，主要分为 byte 和 word（根据文档中的定义是 4byte）

具体步骤

padding

padding 的操作对象是 byte，在这一层次上可以忽略大小端。因为对象是一个 byte

Padding 的规则在文档中写的很清楚。

假设消息 m 的长度为 l 比特。首先将比特“1”添加到消息的末尾，再添加 k 个“0”，k 是满 足 l + 1 + k ≡ 448mod512 的最小的非负整数。然后再添加一个 64 位比特串，该比特串是长度 l 的二进 制表示。填充后的消息 m′ 的比特长度为 512 的倍数。

实现上我们首先需要算出最终输出的长度来分配内存。关键需要计算出填充的 0 的个数 k。k 可以通过(448 - ((l % 512) + 1) + 512) % 512算出。加上 512 再模 512 可以避免得到负数的情况。然后只需要分配合适大小的内存置零并将 m 复制过去。这样我们填充 0 的部分和明文部分就算做好了。

然后还有两个步骤，明文后面的一位需要置 1，然后最后的 64 位需要置为明文长度的二进制表示。

明文后一 byte 可以通过 m[l]得到，然后只需要对这一位跟 0x80 做位或运算就好了。
而最后的 64 位长度表示则有大小端的差别在小端机器上需要先转换为大端表示。

拓展消息

拓展消息这里就是按照文档套公式。在实现上由于操作对象变成了 word 需要注意的是大小端问题。因为牵涉到字的位移操作所以大小端尤为重要。在我这个实现中 padding 产生的 bytes 是按照大端排列的。所以需要先转成小端再计算。

CF 压缩函数

CF 也是照着文档套公式实现。因为 + 是模 2^32 加法，所以我们应该选择 unsigned int 来作为 word 的具体数字类型。之后就没有什么特别需要注意了。

注意的点

大小端判断和转换

大小端的判断参考了大佬的博文。通过在内存中分配一个 int 变量，通过强转它的指针为 char 判断低地址 byte 的值判断机器是大端还是小端。

例如

static const int endianTest = 0x12345678;

大端中表示为 0x12 0x34 0x56 0x78
小端中表示为 0x78 0x56 0x34 0x12

转换也是通过强转指针为 char，参考以下代码

void reverse_by_byte(byte * const le, size_t len) {for (size_t i=0;i<len>>1;i++) {byte tmp = le[i];le[i] = le[len-1-i];le[len-1-i]=tmp;}}

循环移位

#define ls_w(a, n) (a >> (32 - n) | a << n)

先保留剩下的位再和要移过去的位或

用移位代替除法

为了效率我们可以使用右移代替除法。乘法一般都能被编译器优化掉。但是除法因为DIV指令会将余数放到寄存器里面所以不能优化掉，可以用右移代替。

体会

算法的实现方面其实不多考虑效率单纯实现的话不难。比较需要注意的就是大小端的问题。C 语言可以直接操作内存所以还是比较舒服的。
至于算法的原理，为什么要那样设计就不知道了。这也应该是正式上课的时候应该注意的问题。

参考文章

• SM3 文档
• SM3 密码杂凑算法实现及说明 by 梁默鱼
• undefined reference when calling inline function
• Calculating k for padding of SHA-256 message

PS: 系统使用的是Manjaro-deepin
持续更新：LastUpdated At 2019/9/12

pacman yay

Manjaro 属于 Arch 系，AUR 的包是真的多而且更新又快，这真的是最大的亮点。新装的系统第一件事当然是更新了。为了能在天朝好好过日子，换源是必须的。

sudo pacman-mirrors -i -c China -m rank #换源

修改/etc/pamac.conf,在末尾添加

[archlinuxcn]SigLevel = Optional TrustedOnlyServer = https://mirrors.tuna.tsinghua.edu.cn/archlinuxcn/$arch

用于添加archlinuxcn源。

sudo pacman -Sy #更新数据库sudo pacman -S archlinuxcn-keyring #更新keyringsudo pacman -S yay #安装yay

VritualBox 相关配置

在安装前应配置显存到最大的 128MB，显卡控制器配置为VBoxSVGA，并且启用 3D 加速。
安装之后不要使用 VirtualBox 安装增强功能的 ISO 安装 guest os module。应该使用包管理器，从源里安装内核对应的版本。

uname -r #查看内核版本yay virtualbox-guest-modules #从中选择对应版本安装yay virtualbox-guest-utils

Home 目录下文件转成英文

export LANG=en_USxdg-user-dirs-gtk-update

输入法

sudo pacman -S fcitx-sogoupinyinsudo pacman -S fcitx-im     # 全部安装sudo pacman -S fcitx-configtool     # 图形化配置工具

.xprofile

在~/.xprofile添加

export LC_CTYPE=zh_CN.UTF-8export XMODIFIERS=@im=fcitxexport GTK_IM_MODULE=fcitxexportQT_IM_MODULE=fcitx

proxychains

yay -S proxychains-ng

在/etc/proxychains.conf末尾添加

socks5  10.0.2.2  1080

至此可以重启一下了

shell

Shell 用的是zsh

yay -S zshchsh -s /usr/bin/zsh

配置方面没有用oh-my-zsh而是用的zplugin。就是为了速度快。
配置放在了这里

git clone git@github.com:fengkx/zshrc.git ~/.zshln -s $HOME/.zsh/zshrc ~/.zshrc

Node

1. nvm
   source 了~/.zshrc之后就应该安装了

nvm install --lts #安装最新LTS版本

2. nrm

npm i -g nrm #安装nrmnrm use taobao #使用淘宝源

neovim

配置放在了这里

yay -S neovim-nightly #安装neovim nightlygit clone git@github.com:fengkx/vimrc.git ~/.config/nvim

vim 中的一些插件配置

vim-go 需要 :GoInstallBinaries
gopls 可能需要自己本地go build然后放在 bin 目录才能用

git clone https://github.com/golang/xerrors #编译需要go get -u golang.org/x/tools/cmd/goplsGOMODULE=on go build

coc extension list

coc-emmetcoc-translatorcoc-wordcoc-gitcoc-pythoncoc-yaml

Python

https://www.fengkx.top/post/pyenv-and-virtualenv/

Pyhon 安装包镜像。版本号可以替换

https://mirrors.sohu.com/python/3.7.4/

Go

export GOPROXY=https://goproxy.io #设置GoProxyexport GOMODULE=on #启用 Go mod

Docker

DaoCloud 文档在这
在/etc/docker/daemon.json 添加

{  "registry-mirror": "http://f1361db2.m.daocloud.io"}

最近 LeanCloud域名被有关部门停止解析了。一纸行政命令下来说停就停真的惨。在国内想要建个网站，做个服务不容易啊。为了合法 LeanCloud 现在要求用户绑定自己的域名当然了，肯定是要实名备案过的。

影响

我的博客之前用了一段时间的 Valine 作为评论系统它使用 LeanCloud 作为后端存储，本来以为是稳稳的了，但是现在看来不备案就要凉了。

但是备案太麻烦了，我也不想实名备案。总感觉备案之后这里就要接受审查。有种Big brother is watching you的感觉。所以评论系统又要换了。想了想用 GitHub Issue 的方案应该是最稳的。于是乎选择了GitTalk。坏处就是要有 GitHub 帐号才能评论了。Valine 的头像使用 gavatar，整体实现的效果其实一般。有帐号要求其实效果可以更好。GitHub Issue 我相信还是很稳的。(奶一口)

从 LeanCloud 管理界面可以看到 23 条评论，可惜了。

更换至 pure 主题

一不做二不休，打算把主题也更新一下。之前的主题一直是 Next5.0。尝试了一下升级 Next 主题大版本的过程实在是太痛苦了。mathjax, wordcount 等插件瞬间爆炸。因为主题装了很多东西，自己改动的也不少。网页的加载速度其实不太妙，全靠 Service Worker 挑大梁。那么既然这样干脆换一个主题吧。于是找到了Pure。该有的东西 wordcount,mathjax 一个不缺，还有 repository 这样的贴心功能。而且好看，简洁。加载速度瞬间上了一个档次。可以说是非常满意了。

所以说不评论一下试试？

准备

这里 下载 handout 和 writeup。

writeup 很重要，一定得看的。解压之后我们可以看到ctarget和 rtarget。分别对应前 3 个 phrase 和后两个 phrase 还有一个用于将 16 进制表示的 byte 转化对应字符串的工具hex2raw。

用法在 writeup 里面有写。简单地说就是标准输入中输入两个一组的十六进制数字表示的 byte。每个 byte 由一个或多个空格分割还可以用/**/写注释。输出为对应的字符串。因为有一些不可见字符键盘是打不出来的所以很有用。

我们可以通过管道或者重定向的操作灵活的使用它

writeup 还讲到了利用gcc和objdump生成机器码的方法

通关过程

首先要先分析程序。我们的输入是过getbuf这个函数读进去的。汇编代码长这样

Dump of assembler code for function getbuf:=> 0x00000000004017a8 <+0>:sub    $0x28,%rsp   0x00000000004017ac <+4>:mov    %rsp,%rdi   0x00000000004017af <+7>:callq  0x401a40 <Gets>   0x00000000004017b4 <+12>:mov    $0x1,%eax   0x00000000004017b9 <+17>:add    $0x28,%rsp   0x00000000004017bd <+21>:retqEnd of assembler dump.

函数分配了0x28也就是 40bytes 的缓冲区，将输入读入到栈中。然后调用ret

栈空间大概长这样

栈是向低地址增长的。代码的运行方向是是从小到大。栈是从栈顶%rsp开始向高地址写的。

超过 40 个 byte 的部分就会覆盖掉返回地址
ctarget 和rtarget``getbuf 部分都是一样的，下面的 phrase 的区别就是要往栈里面放些什么东西让程序执行到我们想要执行到的地方。

phrase1

只要调用 touch1 直接在 40bytes 的任意字符后面放 touch1 的地址就行了。将 touch1 地址写成小端形式输到hex2raw就能生成。

phrase2

这次函数多了一个参数，还判断它和 cookie 一致。那么我们要让 %rdi 等于cookie。我们需要插入代码进去执行。writeup 里说我们在所有控制转移的时候都要通过ret

mov $0x59b997fa, %rdiret

写出汇编代码gcc -c配合objdump拿到 hex 表示。40 个填充字符后的第一个四字写代码所在的地址。后一个四字就是插入的代码中ret跳回的地址。所以后一个四字写 touch2 的地址

phrase3

同样是传参数判断是否与 cookie 相等。不过这此时参数是个字符串，也就是首元素的地址。

这里插入的代码是

mov $0x5561dc78, %rdi #0x5561dc78 = rspret

phrase4

phrase4 用的是rtarget跟ctarget区别就是栈地址有随机化和栈不可执行。然后就要用到 rop。

因为栈的代码不可执行所以利用的是已有的代码。已有的代码指的是从 byte 的角度去看待的代码。然后通过一系列gadgets执行到对应的函数。具体的解释 writeup 有了。
gadgets 的特征就是 c3 结尾。

具体到这一关 writeup 里这么说

All the gadgets you need can be found in the region of the code for rtarget demarcated by the functions start_farm and mid_farm.

要点就是找到 gadgets。

要执行 touch2 并且把 %rdi 置成 cookie。可以直接把 cookie 写在栈里面 pop 到 %rdi 里面。配合 writeup 里的表找gadgets

pop 到 %rdi 要用到的5f没有找到。只能先pop到别的地方再 mov。

于是找到了这样的 gadgets

pop %raxmov %rax, %rdi

对应函数和地址在这90对应的是nop所以可以忽略

00000000004019a7 <addval_219>:  4019a7:8d 87 51 73 58 90    lea    -0x6fa78caf(%rdi),%eax  4019ad:c3

00000000004019c3 <setval_426>:  4019c3:c7 07 48 89 c7 90    movl   $0x90c78948,(%rdi)  4019c9:c3

字符串的组成是

40 offset + pop gadgets + cookie + mov gadgets + touch2 addr

....offset(40 bytes)ab 19 40 00 00 00 00 00 /* pop cookie to rax */fa 97 b9 59 00 00 00 00 /* cookie */c5 19 40 00 00 00 00 00 /* mov rax to rdi */ec 17 40 00 00 00 00 00 /* touch2 */

我报名了去西樵山的考察。原因很简单就是近。其他的路线用时间比较长，只有西樵山是可以一天来回的。不管则么说这也是我第一次参与这样的活动在地理专业的老师领着爬山。这才让我知道爬个山也能那么有趣的那么多隐藏的看点的。

下面便是报告（掺杂着点感悟）

行程记录与观察

山外露头

5 月 12 日，早上 7 点从学校出发去往西樵山。西樵山有着国家地质公园的头衔。能成为国家地质公园当然是有他的特殊之处。其中一个重要的原因是这里原本是一座火山。

那么我们从哪里可以推测出这是一座火山呢？老师首先带我们在山的外部看露头。所谓的露头就是山露出地面的部分

上面的图因为曝光过度很模糊，但是也可以看到山上有很多节理（裂缝的专业术语）。形状比较规则像一个方形。据老师说这也是火山的一个特征，而且是难得一见的景观。

近看山体。上面的图的石头有一个特征就是石头像是一根根方形的石柱嵌在一起似得。这也是火山的一个特征。（大概可以想象外层遇冷凝固的岩浆留下来吧）

蟹眼泉

然后我们就正式进到山里面了。首先我们来到了蟹眼泉

据说上面的泉眼像是螃蟹的眼睛。远看的话发挥一下想象力其实是像的，但是如果不被它的名字引导一下大概是想象不出来的。

这只是西樵山众多的泉眼中的其中之一。之所以有这么多泉眼与它是火山是分不开的。老师引导我们观察泉水的周围和泉眼出口本身。泉水是从石头的孔洞缝隙里流出来的，附近被青苔覆盖而且泉水上方有一个墓。从这些信息里面可以推出什么呢？

1. 上面的墓说明上面的土质比较松软
2. 泉水是从比较硬的石头上冒出来，青苔则说明这块比较潮湿

这里就牵涉到了火山喷发时冒出的物质了。物质分类逃不过那个套路，就是固液气。固体有石块（硬）或者火山灰（软）。液体自然是岩浆。

泉水上面一带多是火山灰，所以多是软质的土，降水可以渗到地下。泉水附近则是固体或者岩浆。因为冷却程度不均一，很容易会产生裂隙水流到一处就形成了西樵山众多的泉水。

这是今天的第一次比较完整的推理。推理也是我觉得这次旅程很有趣的地方，可以从周围的蛛丝马迹推理出数百万年前的情况。

翆岩

然后我们来到了翆岩一个山谷。山谷越往里走越窄，演这山谷有还有溪流。老师继续引导我们通过观察做推理。山谷的形成可以想象因为有东西（例如溪流）把一部分的固体侵蚀掉了。保留下来的部分与被侵蚀掉的有何不同呢？结合外宽内窄的特性。可以推理被侵蚀的是较软的火山灰，岩石或者岩浆因为物理重量原因总是比较靠近火山内部就形成了外宽内窄的情况。

火山口附近

继续前进越来越靠近火山口了。来到了天湖（火山口湖）附近，看到了这样一块石头。

PS: 西樵山属于裂隙式喷发不像富士山那种火山口

这样一块石头，如果不是有专业的老师带着我是绝对不会停下来观察的。但是即便是这样的石头也可以推理一下。观察一下可以看出石头是有几块大石头合在一起的。我们可以看到它们的连接处还有明显地痕迹（脉络）结合这块是火山口附近。大块的石头不想火山灰和小石头会飞的比较远，大石头就在火山口附近堆积起来经过地质作用之后变成了这样岩石。因为是几块岩石集合成一块所以有个专业术语叫做集块岩。

从这块岩石上我们还可以看到风化作用（通俗的理解成破碎）

• 变了颜色（黄色) 说明发生了化学反应的化学风化
• 上面的绿色植物属于生物风化
• 还有无处不在的物理风化

采石场

下一站我们来到了古代采石场。老师给我们科普了一下距今 7000-6000 年前，海平面比现在要高。西樵山在当时算是一座大的岛。当时的人们已经在上面渔猎开发石器了。西樵山是一座火山，自然不缺石头。但也不是什么石头都可以拿来做石器。

进入到滴水岩里面可以看到有两种区别很明显的石头。

应该都看的出来第二种石头有明显被开采过的痕迹。第二种石头更加致密自然更适合来打石器。

这两种差别的原因是因为第二种石头属于喷出岩没有时间与别的物质反应就已经凝固了。

这里可以看到长石的身影。后面老师更我们科普了一下花岗岩（斜长石）和带点红色的钾长石的区别。从化学元素的角度来说斜长石的 Na 或 Ca 被 K 顶掉了。泛红的正长石会带有放射性，在室内装修的时候要谨慎。

生物风化

后面我们还观察了山里面风化现象特别是生物导致的风化现象比较明显的一处。

<img src=https://vip2.loli.io/2023/03/09/4ca7qFRtHkpf1li.webp" alt=“zhiwu” width=“883” height=“662”>
相信不用多说了，一图胜前言

九龙岩

还有这里被叫做九龙岩的地方。但是从科学的角度解释的话就是火山灰和更难侵蚀的岩浆石头混在一起之后，火山灰被侵蚀掉而形成的。

感想

行程最后老师说到我们要保持一颗好奇心。如果没有好奇心觉得知道了这些对我没有什么用就学不到东西的。我很赞同这种说法。的确这些知识对我日后的生活可能并不能派上用场。但是好奇心让我有了动力。这就是兴趣的力量。

这趟旅程我最喜欢的便是老师引导我们进行推理，真是一门难得的好课。老师说这是最后一次开这个课了。真是很可惜啊！有幸选上这样一门绝版好课真是幸运～

准备工作

Bomb Lab 概览

首先要下载Bomb Lab地址在这里选择self study hanout就好了。还有配套的 README 和视频视频里面带着我们复习了一下汇编，还介绍了可能用用到的工具和 gdb 命令。

解压后能看到一个.c文件和一个可执行文件。打开.c文件可以看到程序的主体逻辑，有 6 个 phase 对应 6 个解密字符串。显然我们就是要逆向这个可执行文件找到这六个字符串。

还有一处很人性化的地方就是这个可执行文件提供了一个命令行参数来从文件准行读取输入。这样我们做出来的字符串可以写在一个文件里面，通过 gdb 的set arg命令设置从文件读取就不用重复劳动啦～

gdb

gdb 的默认功能比较简陋，当然选择peda。peda汇编默认用intel语法。把下面这两行注释掉就能换成CSAPP里面使用的AT&T语法了。

756 ~ │ #self.execute(“set disassembly-flavor intel”)
6158 ~ │ #peda.execute(“set disassembly-flavor intel”)

objdump

objdump -t bomb看符号表
objdump -d bomb > asm返汇编重定向到文件

我们可以通过b explode_bomb和b phase_<第几关>在炸弹爆炸前和对应的函数处下断点。

通关流程

第一关

gdb 进到phase_1这个函数看汇编可以轻松看出只要eax为 0 就能通关。eax就是strings_not_equal的返回值。只要字符串相等就能通关。

如果进到strings_not_equal函数看汇编代码可以看到，函数就是先比较我们输入的字符串和0x402400地址处的是否相同相同则继续逐位比较。完全相同则返回 0，否则返回 1。

答案就是Border relations with Canada have never been better.

第二关

同样的方法在phase_2下断点看汇编代码

从偏移地址第 14 处可以看出第一个数是 1

偏移地址 26 处看出后面的一个数是前一个数两倍。

答案就是1 2 4 8 16 32

第三关

看phase_3的汇编， esi被置为0x4025cf,然后调用了有sscanf的函数

可以想象这个就是对应scanf的格式字符串，输入两个数空格分割

紧接着进行判断，判断确定输入了两个数。
偏移地址 34 处可以看出第一个参数要小于等于 7。然后以第一个参数为倍数，0x402470为基址跳转到跳转到对应位置。

对应位置会用一个立即数给eax赋值。最终都会跳转到偏移地址 123 处，将第二个数与eax也就是对应之前那个立即数比较，相等就通关了。

例如 第一个数为 2 时会跳到偏移地址 64，0x2c3 对应十进制数 707。

答案之一就是2 707

第四关

看汇编，同样的套路0x4025cf就是 scanf 的格式字符串，检测输入了两数。

偏移地址 39 处有一个判断，可以看出第一个数要求小于 0xe(14)然后调用了一个func4检查它的返回值eax要为 0。

偏移地址 69 可以看出第二个数的位置经过func4之后要为 0

看func4汇编

看到有移位操作，有递归调用，分支也挺多的。咋一看看不出来，只能耐心的读懂代码

下面是等价的 c 代码

int func4(int a,int b, int c, int d) {    /*    a in %edi, b in %esi, c in %edx, d in %ecx    r in %eax    */    // a 输入的第一个数    c=0xe; // phase_4 调用前 func4 前初始化    b=0    r= c-b;    d = r;    d>>31;    r=r+d;    r>>1;    d=r+b;    if(d<=a) {        r=0;        if(d>=a) {            return r;        } else {            b=d+1;            func4(....);            r=2r+1;            return r;        }    } else {        c=d-1;        func4(....);        r=2r;        return r;    }}

根据已知信息，r 要为 0。而且 func4 没有更改输进去的第二个数。所以第二个数就是要为 0。

看 c 代码可知，使 r 为 0 的条件是d==a。a 就是输入的第一个数。

可以看到d=((c-b) + ((c-b)>>31))>>1 + b。由于 b=0， c=0xe 0xe>0 所以 (c-b)>>31 == 0

化简可知d=c/2,所以第一个数为 7。

答案7 0

第五关

首先判断输入的字符串长度要为 6

然后进入+41 - +74 这个循环。

循环中取输入的字符串每个字符的 ascii 码低四位作为偏移量在 0x4024b0取值存入到栈 (%rsp+10)。

+76 - +98比较生成的字符串和0x40245e的字符串如果相等就通关了。

我们知道数字 0-9 的 ascii 码低四位与数字本身是对应的，范围是0x30 ~ 0x39,用 Python 的chr函数构造处要输入的字符串

答案9?>567

第六关

第六关 gdb 调试发现循环很多一个套一个。然后就选择直接死啃汇编。

Dump of assembler code for function phase_6:=> 0x00000000004010f4 <+0>:push   %r14   0x00000000004010f6 <+2>:push   %r13   0x00000000004010f8 <+4>:push   %r12   0x00000000004010fa <+6>:push   %rbp   0x00000000004010fb <+7>:push   %rbx   0x00000000004010fc <+8>:sub    $0x50,%rsp   0x0000000000401100 <+12>:mov    %rsp,%r13   0x0000000000401103 <+15>:mov    %rsp,%rsi   0x0000000000401106 <+18>:callq  0x40145c <read_six_numbers>   0x000000000040110b <+23>:mov    %rsp,%r14   0x000000000040110e <+26>:mov    $0x0,%r12d   0x0000000000401114 <+32>:mov    %r13,%rbp   0x0000000000401117 <+35>:mov    0x0(%r13),%eax   0x000000000040111b <+39>:sub    $0x1,%eax   0x000000000040111e <+42>:cmp    $0x5,%eax   0x0000000000401121 <+45>:jbe    0x401128 <phase_6+52>   0x0000000000401123 <+47>:callq  0x40143a <explode_bomb>   0x0000000000401128 <+52>:add    $0x1,%r12d   0x000000000040112c <+56>:cmp    $0x6,%r12d   0x0000000000401130 <+60>:je     0x401153 <phase_6+95>   0x0000000000401132 <+62>:mov    %r12d,%ebx   0x0000000000401135 <+65>:movslq %ebx,%rax   0x0000000000401138 <+68>:mov    (%rsp,%rax,4),%eax   0x000000000040113b <+71>:cmp    %eax,0x0(%rbp)   0x000000000040113e <+74>:jne    0x401145 <phase_6+81>   0x0000000000401140 <+76>:callq  0x40143a <explode_bomb>   0x0000000000401145 <+81>:add    $0x1,%ebx   0x0000000000401148 <+84>:cmp    $0x5,%ebx   0x000000000040114b <+87>:jle    0x401135 <phase_6+65>   0x000000000040114d <+89>:add    $0x4,%r13   0x0000000000401151 <+93>:jmp    0x401114 <phase_6+32>   0x0000000000401153 <+95>:lea    0x18(%rsp),%rsi   0x0000000000401158 <+100>:mov    %r14,%rax   0x000000000040115b <+103>:mov    $0x7,%ecx   0x0000000000401160 <+108>:mov    %ecx,%edx   0x0000000000401162 <+110>:sub    (%rax),%edx   0x0000000000401164 <+112>:mov    %edx,(%rax)   0x0000000000401166 <+114>:add    $0x4,%rax   0x000000000040116a <+118>:cmp    %rsi,%rax   0x000000000040116d <+121>:jne    0x401160 <phase_6+108>   0x000000000040116f <+123>:mov    $0x0,%esi   0x0000000000401174 <+128>:jmp    0x401197 <phase_6+163>   0x0000000000401176 <+130>:mov    0x8(%rdx),%rdx   0x000000000040117a <+134>:add    $0x1,%eax   0x000000000040117d <+137>:cmp    %ecx,%eax   0x000000000040117f <+139>:jne    0x401176 <phase_6+130>   0x0000000000401181 <+141>:jmp    0x401188 <phase_6+148>   0x0000000000401183 <+143>:mov    $0x6032d0,%edx   0x0000000000401188 <+148>:mov    %rdx,0x20(%rsp,%rsi,2)   0x000000000040118d <+153>:add    $0x4,%rsi   0x0000000000401191 <+157>:cmp    $0x18,%rsi   0x0000000000401195 <+161>:je     0x4011ab <phase_6+183>   0x0000000000401197 <+163>:mov    (%rsp,%rsi,1),%ecx   0x000000000040119a <+166>:cmp    $0x1,%ecx   0x000000000040119d <+169>:jle    0x401183 <phase_6+143>   0x000000000040119f <+171>:mov    $0x1,%eax   0x00000000004011a4 <+176>:mov    $0x6032d0,%edx   0x00000000004011a9 <+181>:jmp    0x401176 <phase_6+130>   0x00000000004011ab <+183>:mov    0x20(%rsp),%rbx   0x00000000004011b0 <+188>:lea    0x28(%rsp),%rax   0x00000000004011b5 <+193>:lea    0x50(%rsp),%rsi   0x00000000004011ba <+198>:mov    %rbx,%rcx   0x00000000004011bd <+201>:mov    (%rax),%rdx   0x00000000004011c0 <+204>:mov    %rdx,0x8(%rcx)   0x00000000004011c4 <+208>:add    $0x8,%rax   0x00000000004011c8 <+212>:cmp    %rsi,%rax   0x00000000004011cb <+215>:je     0x4011d2 <phase_6+222>   0x00000000004011cd <+217>:mov    %rdx,%rcx   0x00000000004011d0 <+220>:jmp    0x4011bd <phase_6+201>   0x00000000004011d2 <+222>:movq   $0x0,0x8(%rdx)   0x00000000004011da <+230>:mov    $0x5,%ebp   0x00000000004011df <+235>:mov    0x8(%rbx),%rax   0x00000000004011e3 <+239>:mov    (%rax),%eax   0x00000000004011e5 <+241>:cmp    %eax,(%rbx)   0x00000000004011e7 <+243>:jge    0x4011ee <phase_6+250>   0x00000000004011e9 <+245>:callq  0x40143a <explode_bomb>   0x00000000004011ee <+250>:mov    0x8(%rbx),%rbx   0x00000000004011f2 <+254>:sub    $0x1,%ebp   0x00000000004011f5 <+257>:jne    0x4011df <phase_6+235>   0x00000000004011f7 <+259>:add    $0x50,%rsp   0x00000000004011fb <+263>:pop    %rbx   0x00000000004011fc <+264>:pop    %rbp   0x00000000004011fd <+265>:pop    %r12   0x00000000004011ff <+267>:pop    %r13   0x0000000000401201 <+269>:pop    %r14   0x0000000000401203 <+271>:retqEnd of assembler dump.

+32 - +93 和 +65 - +87 是一个两层的嵌套循环。就是判断每个数要不同而且小于等于 6 且 不等于 0，否则炸弹都会爆炸

+108 - +121 循环把输入的每个数都用 7 减去这个数。也就是 a[i] = 7 - a[i]

后面的汇编看了好久也看不出个所以然。于是_～无耻的～打开了 ida 按下了 F5

ida 看 phase_6 印证了前两个循环
可以看到 node 这个东西，点进去看到数据段

node 一共有 6 个 每个 16 byte

gdb 查看字节，可以更直观的看到这是个链表 每个 node 第三个四字指向下一个 node。

伪代码 53 行的 do-while 的意思是按照输入的数字取第 n 个 node 的数值 (int64) 放入栈中

然后每个数都加 8，要求前一个数大于后一个数则通关。

我们可以从 gdb 看到数值，手工排下序得到3 4 5 6 1 2

但是我们输入的数字之前都被用 7 减过，所以答案是 4 3 2 1 6 5

IDA 大法好！

总结

bomb lab真好玩。

看汇编的时候要整体来看，有时候抓住关键的跳转语句，找到循环会好很多。

好像还有隐藏关卡，先留个坑

最近，两个月前开始的，中间鸽了很久。博客也没更很久了打算以社团的名义折腾一个 RSS 的网站放到学校的服务器里。网站的其中一个部分是用RSSHub ,请求外部网站生成 RSS 订阅源。学校的服务器要通过 Http Proxy 才能访问外网。RSSHub 用的是 axios。支持 Promise 兼容浏览器 XMLHttpRequest 和 node 的 http 请求。还有拦截器等各种操作，很爽。但是 http proxy 就出问题了。

axios 中的 HTTP Proxy

axios 本身支持 http proxy

  proxy: {    host: '127.0.0.1',    port: 9000,    auth: {      username: 'mikeymike',      password: 'rapunz3l'    }

本来是很简单很舒服。但是访问 https 网站是就会出现类似这样的东西

Error: write EPROTO 140736379442112:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:794

解决问题

node 不行，但是服务器命令行中用curl访问 https 网站没有问题。
Google 后发现是 axios 的问题，而且已经有修复了 Pre-release(v0.19.0-beta.1)

然而，安了新版之后问题并没有解决，反而多了很多的 501 错误
网络世界那么大，我果然不是第一个遇到问题的人。用axios-https-proxy-fix问题就解决了。
看了一下源代码改动发现用了 HttpsProxyAgent 包的实例 agent 替换了 config 里面的 httpAgent。config 就是 axios 做第二个参数的对象。
这个包没更新到最新的 axios，强迫症的我受不了。于是就模仿这个思路放在了 axios 的拦截器中。

const axios = require("axios");const tunnel = require("tunnel");const agent = tunnel.httpsOverHttp({ proxy: config.proxy });axios.interceptors.request.use(function (config) {  if (config.url.indexOf("https") !== -1) {    config.httpsAgent = agent;    config.proxy = false;  }  return config;});

tunnel和HttpsProxyAgent用法一样但是不用自己手动构造 url。这样就可以满足我追更新的强迫症了。

机械键盘的不爽之处

之前试的那个键盘是以手感偏软著称的红轴，但是用惯了笔记本自带巧克力键盘的我还是觉得太硬了。而且不知道为什么，我老是容易一次按到两个键，这点在巧克力键盘上没有出现过。

最重要的是，我也不是什么用 Vim 的大佬，平时都是 VSCode 或者 JetBrains 全家桶。虽然能用快捷键一般都用，但是鼠标和功能键都不能少啊。用笔记本键盘时，一般拇指可以用上触摸板，手也不用离开键盘。但是如果外接机械键盘的话手还要离开键盘才能用鼠标或者触摸板。真的蛋疼。

适合我的—— thinkpad 指点杆键盘

有了指点杆（还不太习惯）但是双手可以保持原来的姿势，非常适合平时都用快捷键，但有时候用一下鼠标而且穷的我。我选择了一款蓝牙单模（只能连蓝牙不能接线）的 Thinkpad 0B47189

这个键盘，本来设计的使用场景就是带出去用或者接手机 iPad 的，所以很薄便携，用的巧克力键盘。经典 Thinkpad 红黑配色，做工质量不错。价格相比于机械键盘挺便宜了。不怕吵到可爱的舍友们，手不用离开键盘就可以操作鼠标了。总体很满意。
而且还有 thinkpad 信仰加成

不满意的地方

1. 键盘键程没有比笔记本的大多少，TrackPoint 的中键总有中没有按下去的感觉。如果 Thinkpad 肯出带小红点的旧式键盘（就是旧版 Thinkpad 上的）那肯定的剁手啊
2. Thinkpad 的键位还很不习惯。是的说的就是那个 ctrl 和 Fn
3. 单模蓝牙键盘不连蓝牙不能用，也就意味着你不能用它来输开机密码（双模的要贵两百，谁让我穷呢）
4. 这种样式的巧克力键盘，有很大的缝容易藏污纳垢（下图）

双系统的那些坑

刚买回来顺利接上了 Deepin 没什么问题。然后切到 Windows 装了驱动然后就不能在 Linux 连上了。然后找到了解决方案
其实就是键盘连接要配对码，还要验证一个 Key 是否对应。但是因为两个系统是同一台机，MAC 地址相同的，所以不能用两个不同的 Key。而 Linux 对这方面的支持不够好，已经有了一个 key 的设备不会重新配对，还是用回旧的 Key 然后就连不上了。只需要按部就班把 Windows 的 key 搞到 Linux 用就好。多说一句 Linux 里面原有的 Key 字母全都是大写的，为避免出现奇怪的问题。如果当初用的小写字母，就到 Python shell 里.upper()就好了。现在大部分发行版都自带 Python 了。

什么时候能练就小红点打 CS 的神功呢？

EOF

没交钱多了个 close discussion 后的样式

免费，样式和 Next 主题还挺搭。来自俄国，简洁且支持游客评论。虽说加载比较慢 (托慢了整体网站的速度)，用着还是很舒适的。可是 HyperComments 于 2018 年 06 月 15 日不再提供免费服务。

Уважаемые пользователи HyperComments,
Как ранее сообщалось в email-уведомлении от 14.05.2018, мы вынуждены прекратить поддержку бесплатного тарифного плана.

Начиная с 15.06.2018 тарифный пакет «Lite» не доступен.
Для продолжения работы с HyperComments выберите один из платных тарифных планов ниже.
Если Вы не успели выгрузить свои комментарии, Вы можете сделать это с помощью инструкции.

付费最少要 24 刀一年，又翻车了。于是找到了Valine

Valine 是一款基于 Leancloud 的快速、简洁且高效的无后端评论系统。

评论数据在 Leancloud，加载神速，很爽。下面将会进行测试。

其实折腾这么多，评论系统还不是只有我自己在用好吧，到现在为止除了我自己的有过 3 条，现在这么一迁又会没了 (HyperComments 现在连评论管理页都进不去)

对 Next 主题做了些改动，想要换用Valine 可以把下面的这几段代码直接替换相应文件，然后在主题的配置文件加入以下字段就搞定。

# Valinevaline:  enable: true #true or false  appid: appid 获取方式 https://valine.js.org/quickstart/  appkey: 获取方式同上  avatar: "retro" # 可选：https://valine.js.org/configuration/#avatar  placeholder: 评论框的 placeholder  notify: true  verify: false

• 放在 theme/next/layout/_third-party/comments
• 放在 themes/next/layout/_partials/
• 放在 themes/next/layout/_macro

EOF