项目（3）——微信小程序*预约小游戏开发

主要需求描述:

游戏还有半年要上线，上线之前需要开发一些活动向玩家推送活动，该版本主要对应的场地是微信小程序。主要核心功能:  探险，玩家在平台浏览/阅读/做任务/组队的时候，会获取到很多道具和积分，迷宫探宝，玩家在探险里面获取的道具碎片可以合成游戏里面的道具，获取的积分可以在探宝里面抽取对应的游戏道具或者实物道具。

主要涉及到的核心功能，小程序的登录设计/活动订阅/预约通知/定时消息推送/小程序的分享。

主要使用到的技术栈:

后端: Thinkphp6.0+Vue3+ElementPlus +Redis +MYSQL  
 前端: 微信小程序

主要涉及到的技术点:

1. 用户注册逻辑复杂，分8种情况  全新用户（游戏方平台历史没有数据，彻底的新号码，这个时候需要做黑产判断还有合法性API进行校验）|新用户（游戏方有历史，但是平台没有数据，由于游戏并未开始，所以新用户只是预约用户，并不是游戏用户，需要与后期的游戏用户进行区分开）|预约未绑定微信用户（通过其他宣发渠道可能预约过，但是没有绑定任何微信用户）|预约并且绑定的用户（最稳定的逻辑实现用户）|微信登录用户（微信登录了，但是没有绑定我们的信息）|官方用户（官方有账号，到平台里面来）|渠道用户（各种测试渠道的账号）|账密用户（老平台用户）
     由于用户来源的各种可能性，导致写登录/注册，还有做身份校验的业务考虑到的东西很多，需要反复和产品进行沟通。甚至产品自己在设计登录的时候，都没有那么清晰，只是要一个能登录全部。需求的不明确，注定导致开发工作量大幅度增加。
2. 由于存在版本升级，升级后，要让用户的登录全部失效，需要强制重新登录。防止出现版本升级后，新老任务重叠，而出现多领奖品的过期显示，还有一些游戏版本和宣传活动资料上的重叠，可能这个版本出现了A道具，但是游戏改进，A道具变成了B道具。所以系统升级，需要将全部的人T出平台升级。由于是连续性的平台开发，需要对版本发布有严格的逻辑限定。
3. 小程序的登录记录，因为涉及到宣传画和视频的弹出控制。并且只对第一次到平台的用户进行播放，所以需要将用户是否历史登录过，需要记录。成功后，再进行是否注册到平台的逻辑。需要整合到平台的登录逻辑里面。缓存无法使用，只能使用数据库进行单独映射记录。
4. 用户的任务体系，涉及到每日任务（签到-分享） 周期任务（知识了解——卡片——论坛互动），所以需要涉及任务表。
5. 微信体系的开发，包括微信的订阅——推送——通知——站外分享跳转，微信小程序领域的开发全面知识点。基本小程序领域的开发核心营销知识点。
6. 迷宫探宝活动，先到先得原则，按照对应概率抽奖，奖品存在数量限制，但是好处是单一的抽奖。需要了解使用系统的抽奖相关函数。

开发设计注意点:

1. 由于存在版本升级需要T出人的概念，每个用户登录的时候，都需要储存token到redis里面，检查token对应的key是否还存在登录状态。所以每个人登录都是凭借自己的临时token登录，而且每次操作都需要检查用户该用户是否过期失效。每次升级，需要将登陆标志的token清空。
2. 签到的逻辑设计有俩种，一种是在用户每次访问签到的时候，生成一次当前周期未签到的记录字段，批量写入签到里面。后面每天补上对应的签到状态即可。这种方便理解，也很容易实现。有个巨大的问题，会让表的储存量多很多倍。假如一个人一星期只是登录下，签到一次，而数据库里面，记录了该用户的1次签到和6次未签到记录，对数据库的整体是浪费。而第二种实现，只记录签到的时间和状态，未读取到的时间全部用空读取，数据量只有几分之一，考虑到每日签到的唯一性，最好uid+signdate（20240802）这种设计唯一索引，也就是数据表额外加个signdate字段，普通的设计只是记录sign_time  2024-08-01 10:05:36 这种，直接导致查询一些特殊的签到统计性能非常低。
3. 小程序的推送——微信对推送标题有严格的数量限定，15个字以内，超过字数的时候，会导致推送失败。我们前期推送任务的失败，都没找到原因，后面才发现推送消息是严格限制标题和内容数据的。
4. 定时任务的设计—— 一想到定时任务，我们第一反应是写个php的CLI运行脚本。经过测试。但是这种实现存在一个想不到的问题，当你没有服务器管理权限的时候，一旦脚本运行异常，你查询不到原因。运行异常可能是正式服务器上的数据量太大导致卡死，或者其他进程导致运行失败，或者没测试出来的逻辑缺陷。在这个设计开发上，吃了个大亏，定时任务运行一定需要可监控，在系统设计上，性能并不是首要目标，可控和安全才是。采用官方推荐的CLI定时任务运行，是所有理想条件下采取的方案，比如具备服务器的运维权限/你的定时任务代码不怎么需要经常改动/你能随时查看相关运行日志/你的定时任务一次就写成功了。

而另外一个可行的方案，对定时要求不那么高的情况下，比如订阅的通知迟几秒是允许的。其实可以使用URL开放给外部运行的模式。具体做法其实就是写个需要加密token才能访问的API,同时加上set_time_limit(0)//忽略执行时间的限制  ignore_user_abort()；//忽略终端访问的断开，然后再在这个API里面加入相关监控日志。

小结:这是该系统这是第一个版本，每个版本都出现了一些巨大的意想不到的情况，也获得了很多宝贵的经验。由于第一个版本是测试版，引入用户和对安全校验相对比较少，以核心上线为第一期目标。