企业官网建设流程全解析

做WordPress主题的日常里，归档页往往是最容易被忽略的那个。首页、文章页、分类页都有默认的现成模板，唯独归档页要么是系统默认的日期式文章列表，要么就是一行行标题堆到底。我这个系列改主题改到今天已经是第四篇，这一篇干脆把归档页本身当作改造对象——做一个像一把伞一样撑开的时间轴归档页模板。所谓“一把伞”，不是标题党的形容，页面从视觉上看就是伞骨向上收拢、伞柄朝下的形态，所有文章按时间顺序沿着伞骨上的节点铺开。这个模板可以做成主题里的独立页面模板，不需要任何额外插件，核心代码就是一份带查询逻辑的PHP模板文件加一份CSS。

先说明这套东西适合谁：如果你用的是WordPress，有一个文章量在几十到几百篇的博客，想给访客一个清晰、有设计感的归档入口，不想装那些动辄一两MB的归档插件，也不想用第三方短代码方案，那么这个模板思路可以直接拿来改。下面从设计思路、数据查询、样式实现、集成步骤和实际排查五个部分讲完。

1. 为什么要做一个这样的归档模板

绝大多数主题自带的归档页，默认输出逻辑非常朴素：把满足条件的文章标题按时间倒序循环出来，一排一个，配上每篇的日期和评论数。文章到两三百篇以后，一个归档页的标题列表就能滚好几屏，访客想找“上周写的那篇”都费劲，更别提找两年前的旧文。时间轴形态最大的优势就在于，它把时间维度从一维列表变成二维的布局，访客先看年份，再顺着月份节点往下扫，结构感一下子就有了。

1.1 WordPress默认归档页的痛点

打开WordPress传统的日期归档页，实际渲染出来的结构差不多就是一堆标题加时间，全部落在同一个视觉层级里。用户想问“某年某月我到底发了几篇”，需要一屏一屏往下翻。我自己做过几次站点之后发现，归档页其实是最重要的老内容回收站，但它的体验和首页差距太大。后来搜索这类问题时，发现不少人也给归档页做过改造，但大部分只是用列表函数或者插件生成一个下拉列表，观感还是后台工具的味道，放在前台总觉得缺少归属性，更谈不上设计感。

1.2 “一把伞”形态的设计动机

伞这个形态有几个天然优势，正好匹配内容归档的语义。第一，伞骨之间有明确的从属关系，每根伞骨可以代表一个年份，年份下的月份节点就是这把伞的一个个支撑点，文章挂在节点下面，层次天然清晰。第二，伞面的收束性让页面有一个视觉中心，不会像普通列表那样一列到底、无休无止。文章少的时候，这把伞是半开的，骨条稀疏但不虚；文章多的时候，伞面自然饱满，视觉效果也丰富。第三，伞和“雨”的意象是绑定的，雨滴、雨丝的装饰元素可以低成本嵌入，不需要为“看起来复杂”额外找素材。这个隐喻比单纯的时间轴更有记忆点。

1.3 模板实现的技术选型

确定形态以后，紧接着要决定用页面模板还是系统归档模板。我的选择是独立页面模板，后台新建一个归档页面，选择该模板即可。这种方式不会覆盖主题自带的分类页和日期归档逻辑，风险最小，而且页面模板可以被菜单调用、可以被子主题覆盖，几乎适配所有主流主题。后面的章节里我会详细拆这个选择的理由，这里先提一句：页面模板本质上是给某个具体页面单独指定渲染方式，非常适合这种异形布局。

2. 设计思路与文件结构规划

2.1 页面模板和系统归档模板怎么选

很多新手容易一上来就改归档模板文件，觉得这是归档页唯一的入口。但它在WordPress模板层级里的覆盖面太大，分类、标签、日期、作者归档都会走这个文件，一旦在里面写了特殊的循环逻辑，其他归档场景全部被影响。比如分类页本来要显示分类标题和分页，可能就被这套时间轴逻辑给吃掉了。所以更稳妥的方案是创建一个独立页面模板。页面模板的优点是可复用、有后台可见性、通过页面菜单就能嵌入导航，而且它是按需加载的，不干扰系统默认路由。如果之后想让分类页也用时间轴，复制一份改掉查询条件即可。

2.2 模板文件的必备注释与基础结构

页面模板的识别靠文件头部模板名注释，格式不能错：

<?php /** * Template Name: 时间轴归档 */

文件放在主题根目录，WordPress才会在后台页面属性的模板下拉列表中识别到它。如果主题使用了子主题，同样放在子主题根目录。文件再往下就是常规的 get_header、get_footer 和主循环结构。需要注意，模板文件头部注释之前不能有任何输出，哪怕是空行或多一个字符，都可能导致模板下拉列表不显示的诡异问题。我之前就吃过这个亏，用编辑器保存文件时不小心加了UTF-8 BOM，后台找了半天模板列表里就是没有。

2.3 三个文件的职责划分

我实际落地时拆成了三个文件。第一个是模板主文件，负责所有查询逻辑和HTML结构输出，纯粹的服务端部分。第二个是样式文件，负责伞骨架、圆点、雨滴和响应式布局，只影响当前页面。第三个是脚本文件，很小，主要做平滑滚动和年份折叠的交互，其实不用也没关系，属于锦上添花。三份文件都放在子主题目录下，主主题不动，切换主题也不影响已经生成的页面存档。这样的文件拆分看起来多了一份，但好处是后面想换皮、想加样式，都不用翻一整段PHP代码。

2.4 为什么不直接上区块模板

新版WordPress对区块主题支持已经很成熟，理论上可以用站点编辑器配置一个归档页区块模板。但如果你用的是传统PHP主题，为了一个归档页面去迁到区块系统，或者用查询循环区块嵌套实现复杂的分组和裁剪，学习成本和维护成本都偏高。页面模板可以让开发者在PHP循环里完全控制输出结构，这对异形布局尤其重要。以我这个伞状时间轴为例，一个月节点里要同时输出月份标题、文章条数、连线和文章标题，用区块模板要把多个区块组合起来，还得处理条件逻辑，性价比不如几行PHP直接。

3. 核心数据逻辑：按年份与月份分组文章

3.1 使用自定义查询一次性取文章

在页面模板里，如果直接沿用全局循环，页面本身只有一个页面对象，不会自动生成所有文章的列表。要展示所有文章，最直接的做法是新建一个查询对象，指定只取已发布的文章，并忽略置顶：

$archive_posts = new WP_Query( array( 'post_type' => 'post', 'post_status' => 'publish', 'posts_per_page' => -1, 'ignore_sticky_posts' => 1, ) );

posts_per_page 设为 -1 表示取全量，这对大多数个人博客是可行的。我这里没有一上来就加分页，因为归档总览页的分页体验本身就差，如果还要点“下一页”才看到老文章，就失去了总览的初衷。分类页适合分页，归档页不适合。如果你的文章量真的非常大，后面第六节会讲优化方案，这里先按常规方式走。

3.2 分组的数组结构设计

拿到文章集合后，要在PHP层构建一个年份-月份两级分组。我用的结构是：

$grouped_posts = array(); if ( $archive_posts->have_posts() ) { while ( $archive_posts->have_posts() ) { $archive_posts->the_post(); $year = get_the_date( 'Y' ); $month = get_the_date( 'n' ); if ( ! isset( $grouped_posts[ $year ] ) ) { $grouped_posts[ $year ] = array(); } if ( ! isset( $grouped_posts[ $year ][ $month ] ) ) { $grouped_posts[ $year ][ $month ] = array(); } $grouped_posts[ $year ][ $month ][] = get_post(); } } wp_reset_postdata();

这里的日期格式很关键：Y是四位年份，n是不带前导零的月份数字。不要贪省事用 get_the_date( 'Y-m' ) 存字符串键，后续做月份排序和数字统计都要额外拆字符串。分组之后，你就可以从一个数组里拿到任意年份、任意月份的文章列表，方便在模板顶部输出统计导航。数据结构建好了，后面只是渲染问题。

3.3 为什么不能直接在循环里输出

有朋友会问，查询循环一遍直接输出年份标题和月份标题不就行了，为什么要先存数组再渲染第二次？原因有三。第一，我需要统计每个月份的文章数量，如果不提前聚合，每次输出都要重新数一遍文章；第二，我打算做年份折叠交互，默认展开最近两年、旧年份收起，这要求先完整掌握所有年份列表才能渲染导航按钮；第三，伞骨样式需要每个年份整体作为一个节点块，在循环到一半的时候突然插入样式容器，会让HTML片段变得难以维护。先分组后渲染，模板部分可以保持清晰的两层循环，代码可读性和改造成本都更友好。

3.4 输出顺序与年份倒序

时间轴惯例上要最新的在上，所以年份需要倒序输出，月份则从一月到十二月正序。用PHP的 krsort 处理年份、ksort 处理月份：

krsort( $grouped_posts ); foreach ( $grouped_posts as $year => $months ) { ksort( $months ); // 输出一个年份伞骨 }

这样输出结构的语义最接近“从今天往回看”。实际效果是页面上最先看到最近一年的伞骨，往下走年份渐深，符合访客点开归档页的预期。移动端滚动也更顺，最新内容永远在视口附近。

4. 伞骨架视觉样式的实现

4.1 HTML结构设计

数据结构明确后，渲染部分的HTML按“伞柄-伞骨-节点”三层来组织。简化版结构是这样：

<div class="umbrella-timeline"> <div class="umbrella-top"></div> <div class="umbrella-spokes"> <section class="umbrella-spoke">.umbrella-handle { position: absolute; left: 50%; top: 0; bottom: 0; width: 2px; background: linear-gradient(180deg, transparent, #333); }

伞骨则是每个月份节点内部用伪元素画一条微微倾斜的细线，从月份圆点向文章列表方向伸出：

.spoke-month { position: relative; padding-left: 30px; } .spoke-month::before { content: ""; position: absolute; left: 0; top: 0.6em; width: 18px; height: 2px; background: #999; transform: rotate(-15deg); transform-origin: left center; }

这样每根骨线其实很短，但配合中央竖柄后，从整体上看就像无数细分伞骨整齐排列。如果你想要更夸张的张角效果，也可以把横线改成更长的横向虚线。有一点要提醒：不要给所有月份节点设置同一个固定的逆时针旋转角度，否则左右两侧视觉上会不统一。

4.3 月份圆点与年份节点

月份节点是伞骨上的铆钉。我把它做成一个小圆点，用空span撑开：

.month-dot { display: inline-block; width: 10px; height: 10px; border-radius: 50%; background: #c0392b; box-shadow: 0 0 0 4px rgba(192,57,43,0.15); margin-right: 8px; }

年份本身在伞顶的位置做成一个卡片，不直接平铺在伞柄上。这样整个页面从上往下读，能明显感到年份标题是伞面的主节点，月份小圆点是次节点，文章列表作为分支依附在下方。视觉层级一旦拉开，用户就不容易迷路。这也是我在打磨过程中最满意的一步：最初的版本里，所有年份和月份都用同一种字号，结果整个页面看起来像一张没层次的大纲，改成分级圆点和卡片后，扫视效率大幅提升。

4.4 伞面收束区域和装饰元素

一把伞要有顶，我通过一个顶部区域实现。它可以是一个半圆形的渐变背景，或者干脆用上下对称的圆角容器做出收束感：

.umbrella-top { width: 120px; height: 60px; margin: 0 auto; background: radial-gradient(circle at 50% 0%, #444, #222); border-radius: 60px 60px 0 0; position: relative; }

这个顶部的意义是把左侧伞骨和右侧伞骨意象性地收拢在一起，避免页面看起来像两根平行的竖线。雨滴装饰我用的是 box-shadow 把若干个白色小点散布在页面空白区域，少而密，透明度控制在0.3以下，纯点缀，不干扰文字阅读。不需要额外图片，页面加载时图片请求数也完全不受影响。

4.5 响应式退化为竖排单列

伞面这种水平摊开的形态在手机上会出问题。我的做法是在768px断点以下用一个媒体查询，让所有月份节点的左内边距统一收窄，中央竖柄仍然保留在最左侧，不再居中对齐，伞骨伪元素消失，圆点直接贴在文章标题左侧。移动端的“伞”其实退化成一条流畅的纵向时间轴，但伞的隐喻还在，因为视觉元素和颜色没变。这一步是必须做的，否则手机端会看到一堆杂乱的斜线。移动端适配不能靠压缩字号，而是改变布局结构本身。

5. 集成到主题与WordPress细节

5.1 正确加载CSS避免全局污染

只把样式写在模板文件里当然也能工作，但每次切换主题或更新模板都得找半天。规范做法是在主题函数文件中加一个判断，仅当当前页面是时间轴归档页时加载对应样式：

function load_archive_timeline_assets() { if ( is_page_template( 'page-archive.php' ) ) { wp_enqueue_style( 'archive-timeline', get_stylesheet_directory_uri() . '/archive-timeline.css' ); wp_enqueue_script( 'archive-timeline', get_stylesheet_directory_uri() . '/archive-timeline.js', array(), '1.0', true ); } } add_action( 'wp_enqueue_scripts', 'load_archive_timeline_assets' );

函数名和入队句柄都要保持唯一，避免和其它插件同名冲突。这里有个小坑：如果主题的子主题复写了这个模板，文件名不变，但实际路径会变，is_page_template 依然能正确识别，因为它依赖模板名注释而非路径。脚本放尾部加载，CSS正常入队，不会和其它页面互相干扰。

5.2 用body_class隔离样式作用域

即便样式只在归档模板页面加载，主题自带的全局样式仍可能影响模板内的标签。例如主题的标题、段落、链接都有全局样式，我在写CSS时必须用更具体的选择器避免冲突。最简单的办法是给body增加一个自定义类，所有归档页样式都挂在它下面：

function archive_timeline_body_class( $classes ) { if ( is_page_template( 'page-archive.php' ) ) { $classes[] = 'archive-timeline'; } return $classes; } add_filter( 'body_class', 'archive_timeline_body_class' );

这样所有CSS选择器都以 body.archive-timeline 开头，优先级瞬间压过大部分全局样式。遇到实在压不过的，我再针对那条规则单独加属性，而不是无脑用 !important。这个习惯很重要，因为主题升级以后，新的全局样式可能会覆盖这里面的元素，作用域隔离能大幅减少回归风险。

5.3 页面标题、面包屑和评论的处理

页面模板本质上是页面，许多主题会照常输出页面标题、面包屑、评论区。但归档页不是普通文章，页面标题重复出现不好看，评论区更是怪事。在模板里要主动绕开这些部分。通常模板文件会调用 get_header()，面包屑是在头部区域里生成的，所以主题层面如果可配置就关闭；评论区则直接不要调用评论模板函数。页面标题可以在模板循环里判断是否是页面且是否这个模板，然后跳过标题的输出。如果模板结构里本身没有大循环就更简单，直接只输出自定义查询的内容，走完 get_footer 即可。

5.4 输出转义与安全细节

这个模板涉及很多文章标题输出，凡是输出到HTML的地方都要做转义，不能因为内部小站就省略。用 the_title、the_permalink、the_excerpt 这些模板函数输出是安全的，因为它们内部已包含转义逻辑。唯一要注意的是如果自行拼接标题字符串，一定套上转义函数或内容清洗函数。另外，自定义查询循环内调用这些模板函数时要注意上下文，确保当前文章对象是正确的，否则可能输出页面本身的标题。这个坑在页面模板里很容易出现，因为页面本身也是一个文章对象。

6. 实战问题排查与优化选型

6.1 模板下拉列表里不显示

排这个问题的经验是：原因无外乎三种。第一种是文件头部注释写错或写在了输出之后，模板注释必须发生在任何输出之前，包括空格和BOM。第二种是模板文件没有放在主题根目录，而是放进了子目录，WordPress默认只在当前主题根目录扫描页面模板，放子目录需要额外代码支持。第三种是对象缓存插件缓存了模板列表，清理一下就好。如果你换用不同主题后没看到模板，先检查新主题根目录是否真的存在这个文件。

6.2 查询结果为空或时间不对

页面模板默认会出现当前页面的文章循环，但你新建了查询对象之后，如果循环内忘记调用每个文章的初始化函数，就取不到文章数据。另外，查询默认文章类型就是博客文章，但如果你要在自定义文章类型做归档，就必须显式传文章类型参数。时间字段不对的常见原因是日期函数依赖文章对象的日期字段被修改，或者某个插件改变了查询的日期条件。排查思路：先在循环里打印文章ID确认文章对象，再看带不带时区问题，最后检查有没有钩子改了日期相关的前缀参数。

6.3 伞骨线条错位和伪元素计算不一致

伪元素的倾斜线如果用旋转加百分比宽度，在部分浏览器下会因为百分比宽度是相对父元素而非自身而错位。我最终统一改成固定像素宽，并让线条从圆点左侧直接横向延伸，再加一个极小的旋转角度。这样在任何浏览器里都不可能出现“线条和圆点不连上”的视觉问题。另外一个隐患是：绝对定位元素的父级要设置相对定位，否则伪元素会对更上层容器定位。一旦页面结构里多套了一层容器，伞骨线的位置就会莫名其妙跑偏。

6.4 移动端布局塌陷

如果你在桌面端用了左右对称的伞骨布局——一部分分支朝左、一部分朝右，到移动端不处理必塌。最简单的方案是一律转成左对齐列表，中央竖柄不要居中而是固定到左侧固定像素位置，月份圆点作为左列起点，文章标题缩进。我实测中这样做之后移动端几乎不需要额外调边距。要记住：手机上不需要“撑开的伞”，只需要“伞的感觉”。这个问题如果不提前处理，上线后在手机上看归档页基本就是一场灾难。

6.5 全量查询可能带来的性能和内存问题

文章特别多的站点，一次性输出所有标题，在首次渲染时PHP内存占用会偏高，HTML体积也会非常大。有两条改善路线。路线一是在查询时只取文章ID，遍历ID后再按需调取标题和链接，这样内存占用大幅下降。路线二是用“最近几年全量，老年份折叠”的交互：PHP依然全量分组，但渲染时旧年份内容用一个隐藏容器存放，配合JS点击展开，或者干脆只读取最近五年数组，老年份只统计不输出。折中体验和实现成本，我建议普通博客全量加载即可，到千篇级再优化。还要记得给数组分组代码加上一个判断，防止文章数量为空时遍历报错。

6.6 与缓存插件的兼容

页面模板输出跟普通页面一样会被缓存插件缓存。如果你修改了模板代码，后台看到的是旧版本，这是一个常见的坑。解决办法是清理缓存，或者在开发阶段给这个页面设置不缓存。文章新增后，缓存会导致归档页暂时看不到新文章，通常按小时级缓存周期可以接受。如果你希望新文章实时可见，可以把页面加入缓存插件的白名单或禁用该页缓存。我自己的习惯是开发时不开缓存，上线前最后清一次所有缓存，然后观察一两天确认没有异常。

7. 一点实操补充

补充两个在正式上线时容易被忽略的小细节。第一，这个归档页不要放分页，如果文章量到几千篇需要分页，建议按年份做二级页面，而不是给时间轴分页，否则伞骨要断掉。第二，如果主题的字体库包含中文粗体，月份数字建议用等宽数字变体，这样年份和月份数字扫读时不会跳动。

我自己在几个主题里反复试过，这套模板最稳定的用法是：新建一个空白页面，选时间轴归档模板，菜单里直接指向这个页面，再把这个页面的标题和描述按归档页语义配置好。整站上线后用移动端测一把，缩到360px宽度看伞骨是否塌，再开一个无痕窗口检查缓存是否输出正确版本，基本就稳了。后续如果要扩展，还可以给模板加一个年份参数，在年份伞骨上放筛选链接，这类功能属于锦上添花，先把基础版跑通再谈。