技术选型的取舍——三端技术栈为什么这样选 旦阅诞生记 · 第 03 篇 上一篇把旦阅的整体架构摊开讲了一遍：三端一套算法，靠一份跨端契约（BookKey + 进度参数）把手机、电脑、服务端绑成一个整体。这一篇往回退一步，讲讲这三端的技术栈是怎么选出来的——以及每一个"选了它"的背后，都对应着一个"放
先从一个具体场景说起。 你在手机上读到某本小说的第 4743 章、第 904 个字，合上手机，打开电脑。电脑上也有同一本书的 TXT，你希望打开时落在哪里？ 答案只能是：第 4743 章、第 904 个字。不多不少。 这个需求看上去很简单，但它牵出一串问题： 电脑怎么知道这本书，和手机上那本是"同一
手机和电脑之间，书签对不上这件事，我忍了很久。 小说是在手机上看的，挤地铁、排队、睡前刷几章。可一到电脑前——写代码的间隙想接着看，进度就对不上了。试过好几个阅读器，要么强制登录，要么要联网传书，要么两头都得开会员。我只想把一本本地的 TXT，在两台设备之间接起来，就这么难？ 于是有了旦阅。 想法很
重建博客到现在十来天，拢共就写了一篇《断舍离》。不是没话说，是每次想写的时候，一想到还要开后台、建文章、传图、排版，那点兴致就先耗掉一半。 写东西这事，最怕"麻烦"两个字。 前几天琢磨：博客是 Halo 搭的，API 都是现成的，能不能让 AI 直接对接上去，替我干这些杂活？说干就干，给它签了个个人
