发布：更新：阅读：1912
内容人员发布一篇新文章，栏目第一页已经出现新标题。翻到第二页后，第一页末尾那篇又出现一次，原本位于第二页末尾的旧文却找不到了。刷新页面时重复项偶尔消失，换一台手机又会出现。只检查新文章是否进入第一页，很容易漏掉分页边界的问题。
接近分页容量时，发布记录要保存栏目总数、每页条数和前两页内容 ID。标题可能修改，也可能截断显示，内容 ID 与正式 href 更适合判断同一条记录。记录时同时保留列表顺序、发布日期和后台 sorting，后面才能看出哪一条被推到下一页。
例如每页显示十篇，发布前第一页与第二页合计应有二十个不同 ID。新增一篇后，第一篇进入列表，原第一页末尾的内容应移动到第二页开头。检查人员不用凭标题位置猜测，把两页 ID 连起来比较，就能发现重复项、缺失项或顺序跳动。
栏目里若有置顶、推荐或不同内容类型，基线要单独标明。置顶内容可能不参与普通列表位移，专题卡片也可能由另一套调用规则生成。没有分清列表来源，测试人员会把模板设计当成分页错误，也可能漏掉普通文章实际少了一条。
验收时连续获取第一页和第二页，记录每个列表项的内容 ID、标题、href 与日期。两页数据应来自同一轮发布状态；如果中间又有人新增或下线内容，页码边界自然会变化，需要重新取样。检查结果里应保存抓取时间和当时的栏目总数。
分页查询需要稳定的排序条件。多篇文章使用相同发布时间时，程序还要用 sorting 或内容 ID 确定先后；只按日期排序，数据库在不同请求里可能返回不同顺序。内容人员可以先查看重复项是否集中在相同时间，再让开发人员核对列表查询的第二排序字段。
页面链接也要逐个打开。第二页 URL 应直接返回 200，页码按钮、上一页和下一页 href 要指向同一套伪静态规则。模板若输出 canonical，需要核对它与当前分页策略一致；错误指向另一栏目或不存在的地址时，应先修正模板变量。列表项 href 还要与文章自引用 canonical 对上。
栏目页可能同时存在程序缓存、反向代理缓存和浏览器缓存。第一页已经更新而第二页仍是旧版本时，两页边界就会重复；两页都使用新版本后，排序本身可能没有问题。测试人员应记录响应时间和缓存标识，在无痕窗口或另一网络复核，避免只清自己的浏览器缓存。
清理站点缓存后，再按相同方式读取前两页。如果重复消失，处理记录应写明影响的是哪一层缓存以及清理动作；如果仍有重复，则回到数据库排序、置顶规则和分页参数检查。分页按钮显示的总页数也要与内容总数和每页条数相符，不能只看两页列表。
验收通过后，把新文章 ID、受影响页码、两页 ID 集合和检查时间写入发布台账。后续新增内容只需重点检查发生位移的页码，同时抽查较后页面。若栏目总数刚好跨过新的页数边界，还要打开新生成的末页，确认它能从页码导航进入且没有空白列表。
