C3.15.4Pull-to-refresh redundant under auto-refresh设计研究
自动刷新场景下该手势变为冗余
别名: 自动刷新 · silent refresh · 下拉多余
概念解释
信息流若在回到前台、网络恢复、轮询或推送到达时已经自己更新，下拉刷新就不再提供新的能力，只剩一条与滚动冲突的越界动作。冗余不是“多一个入口也好”，而是多一次误触发和多一段必须滚到顶才能用的空操作。该出手势让路的时候，应让路。
机制
人手动拉刷新，是因为系统不能保证“现在看到的就是最新”。一旦产品已经用前台刷新、增量推送、可见的“刚刚更新于”把这个保证补上，手势的信息价值掉到接近零，成本却还在：顶部越界、与搜索冲突、弱网时拉出转圈。更糟的是自动刷新若在人下拉的同时插入内容，列表会跳，人以为是自己的手势造成了错位。冗余手势还会训练过时模型——以为不拉就没有新内容——从而掩盖自动通道已经失败的情况。
怎么研究
比较“仅自动”“仅下拉”“两者都有”。在有可靠推送的流上，测下拉的实际使用率、因下拉导致的误触发、以及关掉下拉后“错过新内容”的投诉。若使用率极低且投诉不升，冗余成立。再人为让自动通道静默失败，看用户会不会去拉——这是手势作为故障备用的价值，要和日常冗余分开报。
边界
邮件、社交时间线在自动通道不可靠或资费敏感时，下拉仍是用户能理解的“我现在就要”。后台被系统杀掉、推送权限未开，自动刷新名存实亡，手势不是冗余。协作文档的刷新语义是冲突合并，不是信息流拉新，不能用同一条冗余结论。
怎么落地
- 自动通道稳定的消费型信息流，可以去掉下拉刷新，改用顶栏时间戳或静默插入。
- 保留下拉时，自动插入不要和手势越界抢同一动画；失败时让下拉成为明确的重试。
- 看一周日志：下拉次数、其中多少发生在自动刷新刚完成后的几秒内。若大量是“刚更新完又拉”，手势在日常里已是空操作。再关掉下拉做一次发布，盯投诉是不是真的在涨。