在线人员列表逻辑混乱的七个问题：
1.类中写了公共变量导致数据混乱现象
2.保存数据没有考虑业务的隔夜覆盖导致的逻辑漏洞
3.如果涉及到继承，你这个this，如果父类有同样的成员，你最终用哪个呢？
4.参数传递问题
5.参数不一致导致后续维护混乱
6.雪花算法的外键使用varchar类型，后续级联导致类型不一致而产生的索引失效问题；进而产生慢SQL
7.SQL不考虑业务导致的明确的逻辑漏洞
问题分析：
1.类中写了公共变量导致数据混乱现象
既然是公共变量，那么在业务中就是共享的，涉及到修改这个变量的地方可能有很多，同时在可能存在的高并发多线程的状态下，作为线程共享的全局变量。容易出现数据显示混乱的问题
2.保存数据没有考虑业务的隔夜覆盖导致的逻辑漏洞
考虑问题不能只被当前的时间所局限，如果查询加入了createDate，那么如果出现了一个学生从第一天到第二天一直在线的话，那么就查询不到第二天的在线数据。然后导致重复插入的连锁反应。
3.如果涉及到继承，你这个this，如果父类有同样的成员，你最终用哪个呢？
这个问题体现了一个边界是否清晰的问题，成员变量和全局变量之间的边界是要清晰的，否则容易导致数据混乱。如果涉及到继承，这个this，如果父类有同样的成员你最终用的是哪个呢？
5.参数不一致导致后续维护混乱
原本入参里面已经包括了所有需要传的参数，而实体里的参数可以赋不同的值，比如红框里表示状态的参数是“1”，但涉及到了不同的状态也可能是0或者2，那么这里参数写1就不合适了，所以要保持和方法传进来的入参一致。这也可以理解为一种对数据的抽象，支持变化和拓展。
6.雪花算法的外键使用varchar类型，后续级联导致类型不一致而产生的索引失效问题；进而产生慢SQL
7.SQL不考虑业务导致的明确的逻辑漏洞
问题1：update_time=NOW()，在这里的作用是，把所有人的最近登陆时间都修改成了当前时间，表里的最近登录时间变成了一样的，显然这样是不符合逻辑的。
问题2：create_date与接收的createDate一致的时候，条件才成立，但是问题来了，这个字段的值是具体到日期的时间，所以只有在当天两个值才相等，超过24点，则createDate日期加一，那么就不会满足这个条件了，所有在线的人就无法下线了
思想总结：
在做项目的时候，不能只顾着逻辑实现，还要从需求的角度，实际使用的角度，结合业务场景来思考。毕竟项目最终是需要现实中的用户使用的，要避免不合常理的逻辑问题。
