Interface over frameworks

这是一篇替代占位文章，用来保证新的博客集合、首页 recent posts 区块和文章详情路由都能稳定工作。

先定界面，再定抽象

这次重写的目标不是把技术栈换新，而是把网站做得更轻、更快，也更像一个成熟的个人站，而不是一个模板工程。

框架很重要，但它只在某个层面上重要。对一个内容型个人站来说，用户最先感知到的不是你用了什么元框架，而是这个页面是否安静、清楚、打开就能读。

所以我会更倾向于先问：

• 这个页面一打开是不是就像一页写好的文章
• 导航和模块是否知道自己是配角
• 项目页和博客页是不是属于同一个系统
• 细节有没有帮助阅读，而不是只是“看起来做了很多”

视觉系统比技术选型更关键

如果排版、留白和信息层级没有处理好，再新的框架也只会把问题更快地输出成网页。

很多站点的问题，不是因为技术栈老，而是因为视觉语言没有建立起来。比如：

• 首页和详情页不像同一个站
• 列表页像模板，详情页像文档
• 导航太重，正文太轻
• 每个模块都在抢用户注意力

这些问题没有一个是“换框架”能自动解决的。

真正需要设计的是关系

设计系统不是只决定按钮和颜色，它更决定这些关系：

• 首页和文章页之间的关系
• 标题和摘要之间的关系
• 正文和侧栏之间的关系
• 内容和互动模块之间的关系

一旦这些关系清楚，很多组件其实会自然长出来。

组件不该抢正文的戏

详情页里的目录、meta rail 和跳转链接应该服务阅读，而不是变成又一层花哨的 UI 组件展示。

这也是为什么我会对很多“看起来很高级”的实现保持怀疑。一个目录如果总是在滚动时吸走你的注意力，一个评论入口如果比正文还显眼，一个 hover 效果如果比句子本身更有存在感，那它们实际上都在伤害阅读。

功能可以晚一点

功能顺序也会影响最终界面质量。比如把评论放到后面做，并不只是工程排期，更是为了避免在结构还没定的时候就让动态模块绑架页面。

先把这些东西做好：

• 标题区
• 正文宽度
• 目录跳转
• 收尾节奏

然后再接：

• reaction
• 阅读量
• 评论
• 访客地理

这会让页面天然更稳。

什么样的细节值得留下

我喜欢的细节通常都具备几个特点：

• 只在用户真的需要时才出现
• 在鼠标或滚动中轻轻提示，而不是大声提醒
• 不需要多余解释
• 失败时不影响主体

比如一个好的 navbar，不是“动画很多”，而是它在静止时足够克制，在 hover 时又有一点点质感。一个好的 TOC，也不是永远占据视线，而是在你需要找位置时才真正有用。

不值得留下的复杂度

相反，有些复杂度很容易在前期看起来诱人，但后期会一直拖累：

• 过重的客户端状态
• 依赖 portal/modal 才成立的小功能
• 只为炫技存在的 hover preview
• 只有全局运行时才能完成的视觉效果

这些东西不是绝对不能做，而是对这个项目当前阶段来说不值。

最终想得到的不是“更现代”

如果最后这个站点只是看起来用了更新的技术，但打开速度、阅读体验和内容秩序都没有明显变好，那这次重写其实没有成功。

我真正想看到的是：

• 首页和详情页属于同一个世界
• 文章像文章，项目像项目
• 动态模块存在，但不喧宾夺主
• 多语言可以加入，但不会破坏内容结构

如果能做到这些，那么它自然会比“功能更多”的模板站更耐看。

工具应该服务长期写作

最后，内容站终究还是为了写作和记录。如果一个系统让你每发一篇文章都要重新适应页面、重新处理路径、重新担心性能，那这个系统即使技术上再先进，也不适合长期用。

真正好的基础设施应该让这些事情变得更自然：

• 写作
• 组织内容
• 发布多语版本
• 给页面留出讨论和演化空间

等这些环节都顺下来，框架本身反而会退到背景里。这其实是最理想的状态。