经过漫长的等待和几次审核失败，狼人杀卡牌小程序终于在一个安静的下午悄然通过了审核。

我的反手就是服从底线，避免像上次那样陷入困境。

上线两天后，小程序运行良好，可以说超出了我的想象。上线第二天，访问量就突破400人，访问量达到1600人，自发分享也不少。说明小程序的红利还在，世界广阔，潜力巨大。

第二天的数据比第一天增加了12%。但可能因为第一天下午上线，所以只有下午和晚上的数据。所以总体来说并没有出现爆发式的增长。也就是说，该程序成功占领了空间，但没有足够的功能来吸引核心用户。如果这样下去，长期来看用户流失率肯定会很高。 （一脸担忧）

感慨完后，我发现了另一个bug：当主持人创建房间后获取二维码时，如果分配的人数与上一场比赛分配的人数相同，则上次生成的二维码图像会被调用，而不生成新的图像。这样，用户将加入一个“旧的、无人居住的房间，其中所有卡都已分配完毕”。研究了很久，发现很可能是小程序图片加载的缓存机制的原因。因为参数相等的两张图片会被系统认为是同一张图片，所以不会向后台发出请求，而是直接调用缓存中的图片。所以新的房间并没有生成。

聪明的我很快就想到了一个解决办法，就是每次获取二维码的时候添加一个不会重复的参数，这样系统就读不到缓存了，就不会有bug了。一个永远不会重复的参数……最好的选择无疑是时间戳。

添加时间戳并修复各种陷阱和错误后，就完美完成了。

此外，还增加了一个新的身份——女巫。毕竟，这是标准包中最常用的角色。

我在上线后的第一个更新版本中吸取了教训。在后台编辑、调试和修复bug的过程中，由于调试原因，后台界面出现了很多错误，影响了线上小程序的正常使用。可能是因为我开发网络游戏的经验还不够。这种级别的调试在不在线的情况下自然是没有问题的。但如果是已经上线的游戏，每次都犯这样的错误就让人难以忍受，这会导致用户的游戏体验极差。尤其是开发和调试需要花费大量的时间。如果这段时间游戏无法正常使用，那绝对是一场灾难。

这大概是一个基本的常识性错误，但我一开始并没有注意到，这让我感到羞愧。所以我们很快就将运营和开发的后端分开了。因为我们需要保证线上版本——送审版本——以及开发版本的三个后端都能正常运行，而由于某些原因，当送审版本通过审核并正式上线时，后端需要为了做一些调整，所以我干脆加入了。版本控制。这样迭代时，只要不断更新后端版本，就可以滚动启用后端，不会出现重复和冲突。

由于这次后端错误事件，我深深的感觉到需要有一个在错误期间遇到特殊情况时通知用户的功能，所以下一步我打算做的就是发布公告和客服功能，我高兴地决定了。

相关小程序：