E5.08.3load more for finite footered lists设计
适合内容有限且需要页脚的场景
别名: 有限目录加载更多 · when to use load more
概念解释
加载更多不是通用的「比分页时髦、比无限滚动安全」的折中。它适合有限且需要页脚的列表（load more for finite footered lists）：全集存在、人需要在某时刻到达文档末尾，同时又不值得为这批内容维护页码坐标。场景选错时，门闩和页脚可达都救不了——要么该用分页的定位，要么该用自动追加的连续扫视。
机制
有限，意味着存在耗尽：加载若干批之后应当出现「没有更多了」，页脚或结束说明可以稳定停留。需要页脚，意味着末尾那些链接、汇总、导出不是装饰，必须在不点「更多」的情况下也够得着——或者在耗尽后够得着，但不能永远被下一批挡住。不值得分页，通常是因为结果不拿来引用、分享某一页，也不需要跳到第 n 块：目录、通知、中等长度的搜索、设置里的日志，都属于「扫完一批再决定要不要下一批」。
一旦全集实际上无穷（社交信息流），或任务是「回到上周三那一屏」（需要坐标），或法律入口只活在页脚却永远追加（页脚死了），这个模式就在用错误的门闩解决别人的问题。选择依据是任务结构：有没有终点、终点上有没有必须到达的东西、有没有把某一段当成地址。三条里前两条为真、第三条为假，加载更多才是对口的容器。
边界
总量已知但极大、人明确要跳到后段时，应上分页而不是让人点二十次更多。总量未知但用户必须停得下来时，加载更多仍可用，只要耗尽或主动停止时页脚出现。电商筛选结果经常需要「第 3 页的那件」给客服，看起来像目录，其实需要坐标。内部工具的审计表需要导出和页脚汇总，也需要可引用的页，这时分页加页脚比加载更多完整。移动信息流几乎永远不需要页脚，用这个模式只是在制造额外点击。
怎么落地
- 选模式前写三句话：有没有耗尽、末尾有没有必须到达的内容、用户会不会引用某一段。只有「有、有、不会」时才用加载更多。
- 把耗尽做成产品状态：最后一批之后换掉按钮，让页脚或汇总留下，而不是继续显示可点的更多。
- 若第三条后来变成「会引用」，就迁到带地址的分页，不要在加载更多上补假页码。
- 验证：找真实任务各走一遍——到页脚办一件事、看完有限目录、向别人描述某一条所在位置。第一件和第二件应不费力，第三件若经常发生，模式就选错了。