归档页里有一块内容特别适合单独拿出来：总览统计卡。
它的任务非常明确：
- 显示一个 label
- 显示一个值
- 用统一的卡片视觉排成网格
这种结构如果继续内联在页面里，后面每次想复用时都得重新写一遍 dl + dt + dd + card styles。所以这次把它抽成了：
src/components/content/SummaryStatGrid.astro
输入很小，只服务“统计卡”这件事
这个组件没有试图做复杂的 dashboard，它只认一种输入：
type SummaryStatItem = {
label: string;
value: string | number;
};页面只需要把展示文案整理成数组，再交给组件：
<SummaryStatGrid
items={[
{ label: copy.archive.totalCountLabel, value: totalItemCount },
{ label: copy.archive.articleCountLabel, value: articleCount },
{ label: copy.archive.chapterCountLabel, value: chapterCount },
{ label: copy.archive.latestUpdateLabel, value: latestUpdate ? formatContentDate(latestUpdate) : "" },
]}
/>这样归档页自己就不再关心 dl 结构和样式细节，只负责提供真正的数据。
为什么它不放进 ArchivePageView 里
因为它的职责其实并不属于“归档”。
它属于一种更通用的页面元素：
- 一组概览数值
- 每个数值都带一个小标签
- 以卡片网格形式出现
今天它先服务归档页，明天也完全可以服务：
- 关于页的站点统计
- 系列页的章节/卷数概览
- 首页的内容总览
把它提前抽出来，后面这些场景就不必重新长一套近似组件。
它帮页面文件减掉了低价值噪音
归档页真正重要的逻辑，其实是这些：
- 处理分页状态
- 处理语言切换页码
- 渲染归档索引列表
- 组织总览数据
dl 结构和四张卡的样式，对页面来说都只是噪音。
把这层挪进 SummaryStatGrid 之后，ArchivePageView.astro 更接近它应该扮演的角色：
- 页面级装配
- 数据整理
- 组件组合
而不是同时兼任一份小型 UI 组件实现。
为什么这种小组件值得保留
很多重复代码不是大块重复，而是这种“看起来很小，复制起来很快”的结构。
但正因为它小，最容易被反复复制，最后散在多个页面里：
- 文案层级稍有不同
- 卡片 padding 稍有不同
- 响应式列数稍有不同
SummaryStatGrid 的价值，就是尽早阻止这种漂移。
它不是一个复杂组件，却很适合当内容站里的“结构钉子”，把概览类卡片固定成同一种语言。