第一个情景，原来登录注册更新用户资料是分开的3个接口，那么容易想到的是注册之后不更新资料，但是又登录了的（修改资料当然需要登录）。根据墨菲定律，凡是可能会出问题的地方则迟早出现问题。果然产品上线3个月后数据库出现了几百条仅仅注册但是没有更新资料但登录了的用户。更要命的是，这些用户的资料随着一些业务逻辑线进入了solr，污染了附近用户相关的业务的数据导致周围的人以及查询出现空白资料的用户。
第二个情景，因为用户编辑广播消息或者图文资料的时候对图文的存储没有依照惯例进行处理也就是text中插入标记，然后将图片和text id绑定。而是使用的json分割记录的办法。其实这样做本质上并没有问题，但是问题出在我们用了ali的oss的服务以及我们的实习生能力真有问题还有就是我因为太忙了没有能够review他们的逻辑。事情是这样的，oss做了防盗链，图片获取是有时间限制的，所以我们不得不将oss的图片地址获取放到我们服务器上，一篇文章中可能出现很多的图片，小学生跟前端商量的结果居然是一次一次的去请求。。。。。。。。。
准备下班，先写道这里，回去再写剩下的，以及最后的解决方案和启示
1.从产品设计开始，一定需要将前端开发和后端开发拉上一起开会，方便对接口进行规划，在产品设计的初期一定要力求接口的简洁和合理。那么，如何算是简洁，如何算是合理呢？其实这两者是一个相悖的方向，简洁要求一个功能一个接口，但是app开发的合理却要求一次请求尽可能获得更多的有用信息。那么从中找到合理的平衡点就很重要，特别是需要进行几步连贯操作的时候，尽可能的把逻辑放在app用一次或者尽可能少的请求次数达成，这样才能较为容易的保证数据的完整性，否则就会陷入请求和交互的烂泥中。
2.再处理长文字附带图片的内容的时候，尽可能的让客户端去自定义其格式，服务器端尽可能的避免对这个东西的干涉。但是图片的来源要做到可追溯。app根据公司的人手再决定是否需要防止盗链的功能，人手如果不足（比如楼主这一次被坑）那么防盗链功能很可能成为一个工作量爆发的地方，应该极力避免。