那天，产品小刘和开发老王对完方案后，在开发具体实施过程中老王问了小刘一个问题：

"用户点击拉黑按钮后，响应是要前置还是后置？"

首先我们要理解开发口中说的"响应前置"和"响应后置"的含义，先从用户点击按钮那一刻分析一下流程：

- 响应前置：用户点击按钮后，客户端立即给予点击成功的响应，然后再向服务器发送用户点击操作的请求。

- 响应后置：用户点击按钮后，先向服务器发送点击操作的请求，在服务器回包之前客户端一直展示loading状态，待服务器回包后，给予用户点击成功的响应。

这两种不同的响应方式的使用场景，作为产品经理应该十分清楚，错误的处理可能会破坏用户使用流畅度，甚至可能给用户造成困惑。

我们先来提出几个小问题，你来思考一下下面这些场景，响应是要前置还是后置？

- 用户点赞

- 用户删除内容

- 用户发表评论

- 用户移除粉丝

- 用户添加他人进入黑名单

要明确一个行为是要前置还是后置，我们先引入一个概念"平台熵"，"平台熵"可以用来表示一个平台的活跃度，平台上的内容和互动越活跃，"平台熵"越大。

任何一个行为都会对平台产生一定的影响，这种影响可以被分为两类，一类是让平台看起来更活跃，会让"平台熵"增加，比如：点赞、发评论；另外一种行为则让平台互动减少，会让"平台熵"降低，比如：拉黑、删除等。

那么这里有一个比较通用的公式是：

让"平台熵"增加的用户行为，采用"响应前置"，也就是点击即给予用户成功的响应；而让"平台熵"减少的用户，采用"响应后置"。

接着我们分析一下上面公式的背后原理：

对于会增加"平台熵"的用户行为，比如点赞、发评论等，是用户在输出自己的观点，是平台积极倡导的行为，应该保证用户表达这些行为的流畅性，用户点击即基于其成功的响应，比如点赞立马就把小红心点亮、评论后立马就出现在评论框里。可能会有一定的几率服务器会返回失败，但与用户发表观点的流畅体验相比，这种失败的几率可以被忽视。

可以想象一下：在玩抖音时，如果你每次点赞都不能实时出点赞的小爱心，而一定要等到服务器给回成功的响应时才展示小爱心，那用户体验会有多差。

对于减少"平台熵"的用户行为，比如删除内容、移除粉丝等，人都期望被他人关注。但用户在即使会损失部分关注的前提下，也进行了这些"熵减"行为，可见他们是遇到了比被他人关注还重要的事情，可能是之前发的内容被投诉，也可能是某个假粉丝肆意造谣等。

所以对于删除内容等操作，一定要先加载loading，等服务器真正删除成功后，才给用户操作成功的提示。

可以想象一下：某个明星的工作室在紧急删帖时，如果执行"响应前置"的操作，那么他在自己的手机上删除这条帖子后，手机会立即展示删除成功，但若这时手机网络不佳，实际上并没有将删除的请求带给服务器，那么其实其他粉丝也还是会看到这条帖子，但工作室却以为已经删除了，这是多么可怕的一件事。

最后我们来揭秘一下上面这个问题的答案：

- 用户点赞 : 熵增操作，响应前置，立刻响应

- 用户删除内容 : 熵减操作，响应后置，先展示loading

- 用户发表评论 : 熵增操作，响应前置，立刻响应

- 用户移除粉丝 : 熵减操作，响应后置，先展示loading

- 用户添加他人进入黑名单 : 熵减操作，响应后置，先展示loading