Thousand Sunny（阳光号）

每次盯着编辑器发呆的时候，脑海里总会浮现出这艘船在海上航行的画面。

说实话，写代码的时候，我有时常常觉得还挺痛苦的。自己像个船长，没有一点思路和灵感，船舵放在手边，周围全是迷雾，迷茫得不知所措。但是万幸，我从这片海域走出来了，并带回了项目代号：Thousand Sunny (阳光号)。

阳光号这艘船，最近刚完成了一次前端底层架构。今天下午闲着没事，想随便写写，聊聊从我未来方向感的选择，遇到了坑，接下来该往哪开，以及我将来的期许和目标。

🚢 阳光号已启航！

欢迎大家来我的新船看看！
🎉 诚邀各位登船，一起见证这艘新战舰的启航：
点击进入：Thousand Sunny (阳光号)

️ 一、旧航图

几个月前，我就下定决心重新将框架更新。心想既然都是同一个框架，逻辑应该不会变动太多。升级过程起初还算顺利，只是安装报错索性装了最新版。但是，当我在本地部署上试了试时，反而不太满意——因为这框架更新后也还是太老了。

底层核心代码和很多插件都是好几年前写的，有些功能随着作者删库而丢失，感觉随时会抛锚。当我试着给它装上 pnpm 时，它根本适应不了，所有输出全在报 Cannot find module 'xxx'。找半天才知道是 pnpm 依赖隔离机制产生的“幽灵依赖”问题。

看着最新框架依然兼容不了 pnpm，动不动就报依赖缺失，老网站也是时不时报错小修小补，我一想这以后不是个事啊。于是我瞬间产生了一个决定：我又要自己弄个新的了。

其实这个想法不是最近才有的，而是好几年前就萌生了。那时候的我还是个半吊字，水平不行还挺畏惧这块的。关于Node.js也没研究透，像Node.js这个核心用的是C++，但整体又是多语言混合的技术栈，日常维护都是JavaScript/TypeScript。而我的 JavaScript 网课只看了一半，都忘得差不多了，很多时候都是找很多库来弄，反而搞得乱七八糟。

于是我更不敢离开原有网站的舒适区，总觉得能稳定运行就行。旧航图虽然不完美，但能用，就一直用着，直到它再也承载不了新的风浪。

我能预感到它将来的死亡，所以我想寻求突破。

️ 二、风向标

最近，因为我决定重组架构，我开始重新下定决心学习Turbopack。在这个过程中，我最大的感悟是：前端构建工具的终极目标，从来不是单纯追求“谁更快”。

以前用 Webpack 时，我常常陷入“唯速度论”的误区，以为只要浏览器请求速度快，构建工具够快，开发效率就会高。但折腾过后老网站是不是弹出各种依赖报错、插件冲突后我才明白，构建工具对效率的影响，80% 来自适配能力和兼容能力，只有 20% 来自绝对速度。

而Turbopack用 Rust 编写的底层和“增量计算”的理念，给了我很大的启发。它就像一个管家，你改了一个组件，它只重新编译这个组件，其余的统统走缓存；浏览器请求什么，它就只编译什么，绝不浪费一丝算力。这种“做最少的工作，享受极速响应”的设计哲学，彻底治好了我在框架组建的最后一丝顾虑。

但Turbopack也让我看到了现代工具链的“双刃剑”。它深度绑定了Next.js生态，对于习惯了Webpack高度自定义和海量插件的我来说，初期的迁移和生态适配往往伴随着一段时间的适应阵痛。这提醒了我，没有绝对完美的工具，只有最适合当下场景的选择。

而在这个过程中，我也看清了这几年另一个不可忽视的未来趋势：现在人们用pc端的时间越来越少，大部分都是移动端以及 AI 收录。

之前我原有框架就是以 PC 端为主体开发的，虽然也做了移动端适配，但技术不行，优化得很少，开发理念上依然抱着主流的“PC为主，手机兼容”的想法。

所以今年我还有额外2个方向，就是老网站的移动端适配优化，以及新框架搭建的核心方向——轻量化，以及从“适配手机”向“移动端原生设计”的彻底跃迁。

️ 三、岛屿架构

所以我最终决定，新框架搭建的方向，就是以移动端原生设计为核心——在手机端做开发，然后在电脑端进行适配。

而这个框架，因为手机屏幕实在太小了，所以最核心的逻辑就是“做减法”。电脑因为屏幕大，可以很轻松地塞下复杂的排版；但在手机上，每一寸空间都寸土寸金。这就注定了我在排版、交互、内容层级等各个方面都要保持极度的克制，不能有一丝冗余。因为一开始没完全吃透这个“减法”的精髓，我在这上面踩了不少坑，甚至推翻重来了很多次。

过去的旧框架就像是一艘装满重型火炮的战列舰，用户只是想看看一页简单的文章，也要被迫加载庞大的JavaScript运行环境，在手机上显得极其臃肿。所以我的框架它完美契合了我的核心理念——“岛屿架构（Islands Architecture）”。

这玩意儿怎么说呢……就是把页面想象成一片由静态 HTML 构成的海洋，而那些需要交互的动态组件，就是散布其中的独立“岛屿”。页面主体被渲染成快速加载的静态 HTML，只有真正需要交互的区域——才会按需加载JavaScript。

每个岛屿在自己的上下文中独立运行，互不干扰。甚至可以混用不同框架——友链用 React，侧边栏用 Vue，在同一个页面里和谐共存。就像组建一支各司其职的船员队伍，每个人都有自己的专长，各自独立，但合在一起就是一艘完整的船。

这种“把大部分内容静态化、仅保留核心交互”的策略。它既保证了极致的加载速度，又留住了最核心的体验。

不过说实话，现在回头看，这个框架我最得意的地方，是岛屿架构带来的“按需注水”。

以前一个页面打开，不管用不用得到，JavaScript全给你塞过来。现在只有真正需要交互的区域才会加载对应的 JS，首屏加载速度有了质的飞跃。

这意味着，阳光号的每一个模块，都可以被无缝嵌入到任何场景中。不管分散到哪个角落，只要需要，就能随时拼装成完整的体验。

完美！

️ 四、暗礁与浅滩

当然，重构不是一帆风顺的。我撞了好几次暗礁，但撞上去的痛感是一样的。

刚开始重构时，虽然想着移动优先，写代码还是习惯性地先铺满大屏布局，再用媒体查询去压缩手机端。结果很多在 PC 上合理的复杂交互，在手机上显得极其臃肿。后来我不得不推翻重来，强迫自己在 375px 的视口里画原型，把核心信息提炼到极致，再考虑 PC 端的扩展。
为了追求极致的加载速度，我曾一度砍掉了所有的过渡动画和微交互。结果页面虽然秒开，但体验像一块冰冷的砖头。用户在滑动时毫无反馈感，点什么都像戳在石头上。后来我才明白，移动端的原生体验不仅仅是“快”，还要“跟手”。我重新引入了时长控制在 0.3 秒内的微动画和骨架屏预加载技术，在性能与体验之间找到了平衡。
在岛屿架构下，各个交互组件是相互独立的。这逼着我重新梳理了状态管理的逻辑，引入了轻量级的全局事件总线，才让各个“岛屿”在移动端真正融为一体。

也就是踩过了这些坑，阳光号的底层框架才算真正稳固。