零额外负担：可选功能应该怎么设计

博客主题很容易变成「功能堆叠」：评论、统计、音乐、动画、各种小部件。每加一个功能，作者就多一份配置负担，读者就多一份加载成本。

本站采用一个很朴素的原则：关掉的功能，必须像从未存在过一样。

什么叫「零额外负担」#

一个可选功能在 enable: false 或完全未配置时，应该满足四个条件：

「关掉」不是「隐藏」，而是根本不参与构建。

最简单的做法，是在配置解析阶段就把关闭的功能过滤掉，而不是等渲染时再 if 一下：

1
export const navBarConfig: NavBarConfig = {
2
  links: pruneUnavailableNavLinks(defaultLinks, unavailableFeatureRoutes),
3
};

这样导航、页面入口和站点地图都拿到同一份结果，不会出现「导航没了，但页面还在」的半关闭状态。

有些功能即使开启，也不应该进入首屏主包。例如评论系统和图表渲染，只有在页面真正需要时才动态加载：

flowchart LR
  A[页面构建] --> B{功能开启?}
  B -- 否 --> C[不生成任何资源]
  B -- 是 --> D[生成触发点]
  D --> E{用户触发?}
  E -- 否 --> F[零网络请求]
  E -- 是 --> G[动态加载模块]

未使用的代码不会自动消失。它会进入依赖树、增加构建时间、带来安全更新负担，还会让后来的人误以为它是必要部分。

零负担还有一层含义：不强迫旧内容迁移。新增一个可选字段时，旧文章不需要批量补 frontmatter；字段缺失时应该有合理默认值，而不是构建失败。

这条原则从哪里来？

它来自一次次「只是加个小功能」带来的连锁反应：配置越来越多、页面越来越慢、关掉之后还要清理残留。把约束写进规则，比事后补救更省力。

可选功能的设计难点，不在开启时的效果，而在关闭时的干净程度。一个功能只有做到「开则可用、关则无痕」，才值得长期留在主题里。

这也是本站愿意为一些小功能写更多判断逻辑的原因：复杂度应该由需要它的人承担，而不是由所有人承担。