从知乎图片问题联想到特殊情况管理

date

Feb 13, 2021

slug

abnormal-problem-thinking-from-zhihu

status

Published

summary

知乎的搜索信息流中，如果图片宽高比中高度过大，会占据屏幕中非常大的位置

一、网络

💡

通常是加载失败、加载慢等

从前端或者客户端来说，通常体现在无法获取到接口的数据，这个时候接口通常是报错的状态；可以通过在其他页面预先请求部分数据（公用），然后在报错页提示网络问题，并提供刷新功能，刷新功能用于请求当前页面所需的数据。

对于后端，在一些业务比较复杂的场景中通常会有和第三方接口对接的情况，因此会增加网络的复杂性，比如说服务器在请求对方接口时，有时会出现超时的情况。

这种情况下最好的办法当然是和对方沟通解决网络问题了，但是线上的用户已经受到了影响，因此临时处理可以考虑修改接口数据的取用逻辑，例如：定时分批请求对方的接口，缓存数据到 MySQL或 Redis中，提供给前端的时候优先取用缓存的数据，如果没有再去访问对方服务器。这个时候如果对方服务器报错，也可以考虑采用上述说到的前端页面提示。

二、空数据

💡

搜索结果为空、无订单、无收藏等

这一部分通常出现在新用户（未使用过产品功能的用户）身上，但是对于这部分用户没有必要做过度处理，因为处理得不好，容易造成用力过度反而影响用户体验造成流失（例如在空订单页显示很多营销信息），只需简单提示即可。

而对于一些特殊功能下的空数据就有点麻烦了，很多情况下都是由于产品数据量或者技术上出现问题，例如搜索结果为空，订单筛选为空；

其中，搜索结果为空可能是由于确实没有相关数据，也有可能是因为关键词匹配没有做好，不过这一部分扩展起来就很复杂了，现在还没有能力阐述得比较清楚，希望之后能找到机会单独写一篇。

不过对于这一部分，成本最低的是当数据为空时，展示给用户更多的不相关内容，比如说最新的文章之类的。

三、样式尺寸

💡

宽高未设限、图片比例失调等

这一类的异常，一般有一些经验的前端或者客户端开发都是会自己处理和规避的，不过产品也有必要懂得一些基础的东西：

3.1 高度未设限

上面知乎那种就叫高度未设限；原则上 UI 设计稿或者需求文档中都会对图片展示的具体宽高做出限制，但是为了避免出现知乎那种情况，建议产品验收时应该多用几种特殊比例的图片做测试；

3.2 宽高失调

当图片被限制在一个固定的范围时，默认的处理方式都是展示完全图片，但是会修改宽高比例，如下图：

所以通常会用 object-fit: cover 去剪裁掉一部分内容以保持图片比例，如下图：

当然，如果是营销性的 Banner 之类的图片，要尽量保证图片完整露出，所以最好是在管理中后台中提示或限制图片宽高比，并展示效果；

四、字数限制 OR 数据长度限制

这种情况有时候会被遗忘，因为似乎绝大部分用户都不会触及到上限；但是在有些情况下，这个问题一旦出现就会比较严重；

之前有一个项目需要用户在一个含有超过 2000 条数据的列表中选择一条数据并通过 ID绑定，但是由于当时绑定ID的字段被开发设定成了 tinyint ……结果导致了 ID超过 255 的数据统统作为 255 保存；

测试下来流程中没有发现任何问题，上线后用户使用起来也很顺利，直到运营需要导出数据的时候……

这算是一次比较严重的错误了，而且不只是数字，如果产品中有大量的富文本内容，那么字符串的大小长度也是应该考虑的。