fix. 修复uid与qq号对应关系不刷新的问题

[lhhxxxxx]

此前遇到了一个bug：当uid被其他人抢先绑定之后，即使对方取消绑定，无论如何操作，排行榜等处显示的头像仍然会显示对方的头像。

经过分析，该bug问题在于redis数据库miao:rank:uid-info:{uid}内存储的qq号不刷新，而更新该处数据库的方法为setUidInfo。该方法只在两处被调用，其一：

并不会实际更新数据库，其二来自本pr修改的render函数，其首先定义了isSelfUid：

然后传入setUidInfo：

内部更新qq号逻辑如下：

因此，qq号当前仅当当前uid在getCkUidList返回的uid列表中时会被更新。虽然getCkUidList函数名已经暗示了其用途，但鉴于是第一次接触本项目代码，确认了一下其逻辑：

因此显然，getCkUidList只会返回绑定了cookie的uid。

综上，bug的原因在于，只要没有绑定过cookie，只要被人绑定过的uid，其uid-qq对应关系就不再会发生改变，故做出此修改及pr。

此外，本修改不会影响系统健壮性与安全性，毕竟初始的uid-qq对应关系本就是无权鉴的，且本修改涉及的变量均只影响setUidInfo函数的uidType参数，该参数只涉及对应qq号的更新逻辑。

[UCPr251]

之前我也遇见过此问题但是没有去研究，顺着楼主的思路研究了一下也提出点意见，先理清下思路：
首先会出现这个bug的最根本原因在于redis数据库中miao:rank:uid-info:${uid}对应的数据中的qq没有更新，而该数据只会在setUidInfo方法中进行更新，更新逻辑如下：

可以看出，当且仅当调用setUidInfo时传入的uidType为非bind时，才会更新数据库中的qq指向。

而setUidInfo只会在两个地方被调用（如楼主所说）：
第一处调用是刷新排行操作（见楼主图一），而这只会更新数据库中的面板数据却不会修改qq的指向（此时setUidInfo中的data.qq和qq是同一数据）；

第二处调用是更新面板操作，这里决定调用uidType参数的关键是isSelfUid是否为true（见楼主图二）。若isSelfUid为true，则uidType为ck，更新数据库中qq指向为当前使用者的qq；反之，只会更新数据库中的面板数据而不会修改qq指向。

这里的关键在于isSelfUid这段代码的作用是什么？
其实就是isSelfUid的字面意思，判断该uid账号是否是该用户自己的账号uid。
设想一个情景：多个人都绑定了同一个uid（比如绑定别人uid看面板数据，这很常见），但其中有一个人绑定了ck，那么我们有理由认为绑定了ck的这个用户才是真的uid所有者。isSelfUid这段代码的逻辑就是处理这个问题的：如果使用当前uid的用户绑定了ck，那么就把这个uid的qq数据绑定为该用户；反之则无法判断这个uid的所有权，保持原qq绑定不变。而如果使用某个uid的用户都没有绑定ck，那么这个uid的qq数据就始终会是第一个绑定的那个人的qq，这也很合理。

由上，这段逻辑本身是没问题的，唯一的问题是在都没有绑定ck的情况下，第一个绑定的用户即使解绑了，数据库中该uid的数据里qq的指向仍然是他，这才是真正有问题的地方。

楼主的修改是可以解决排名中显示的qq头像错误的问题的，但是也会导致其他问题：isSelfUid和uidType会变成无效数据。因为如果按照楼主的修改，那么所有uid数据中的uidType都会变成ck，进而导致无法判断谁才是真正的号主，isSelfUid这段代码和setUidInfo中修改qq绑定的这段代码都会无法发挥其原本的作用。

综上，其实最大的问题是在第一个绑定的用户解除绑定时没有同步解除数据库中miao:rank:uid-info:${uid}的qq绑定，所以最好的办法应该是在解除绑定时同时解除qq绑定，而不是直接修改楼主所修改的这部分逻辑。建议改成：解除uid绑定时，查询miao:rank:uid-info:${uid}数据，如果存在且其中的qq指向为当前用户，则解除该qq绑定（面板数据可以留着）。这样，当其他绑定了这个uid的账号更新面板时，即使他没有绑定ck，qq指向也会自动变成这个用户。删除uid绑定这个逻辑在崽底层plugins/genshin/apps/user.js中，楼主可以参考一下拨冗给底层pr解决此问题。

最后感谢楼主的这个pr和讲解，帮助我理清了这个问题。
非常好pr，使我大脑思考。

[lhhxxxxx]

之前我也遇见过此问题但是没有去研究，顺着楼主的思路研究了一下也提出点意见，先理清下思路：
首先会出现这个bug的最根本原因在于redis数据库中miao:rank:uid-info:${uid}对应的数据中的qq没有更新，而该数据只会在setUidInfo方法中进行更新，更新逻辑如下：

可以看出，当且仅当调用setUidInfo时传入的uidType为非bind时，才会更新数据库中的qq指向。

而setUidInfo只会在两个地方被调用（如楼主所说）：
第一处调用是刷新排行操作（见楼主图一），而这只会更新数据库中的面板数据却不会修改qq的指向（此时setUidInfo中的data.qq和qq是同一数据）；

第二处调用是更新面板操作，这里决定调用uidType参数的关键是isSelfUid是否为true（见楼主图二）。若isSelfUid为true，则uidType为ck，更新数据库中qq指向为当前使用者的qq；反之，只会更新数据库中的面板数据而不会修改qq指向。

这里的关键在于isSelfUid这段代码的作用是什么？
其实就是isSelfUid的字面意思，判断该uid账号是否是该用户自己的账号uid。
设想一个情景：多个人都绑定了同一个uid（比如绑定别人uid看面板数据，这很常见），但其中有一个人绑定了ck，那么我们有理由认为绑定了ck的这个用户才是真的uid所有者。isSelfUid这段代码的逻辑就是处理这个问题的：如果使用当前uid的用户绑定了ck，那么就把这个uid的qq数据绑定为该用户；反之则无法判断这个uid的所有权，保持原qq绑定不变。而如果使用某个uid的用户都没有绑定ck，那么这个uid的qq数据就始终会是第一个绑定的那个人的qq，这也很合理。

由上，这段逻辑本身是没问题的，唯一的问题是在都没有绑定ck的情况下，第一个绑定的用户即使解绑了，数据库中该uid的数据里qq的指向仍然是他，这才是真正有问题的地方。

楼主的修改是可以解决排名中显示的qq头像错误的问题的，但是也会导致其他问题：isSelfUid和uidType会变成无效数据。因为如果按照楼主的修改，那么所有uid数据中的uidType都会变成ck，进而导致无法判断谁才是真正的号主，isSelfUid这段代码和setUidInfo中修改qq绑定的这段代码都会无法发挥其原本的作用。

综上，其实最大的问题是在第一个绑定的用户解除绑定时没有同步解除数据库中miao:rank:uid-info:${uid}的qq绑定，所以最好的办法应该是在解除绑定时同时解除qq绑定，而不是直接修改楼主所修改的这部分逻辑。建议改成：解除uid绑定时，查询miao:rank:uid-info:${uid}数据，如果存在且其中的qq指向为当前用户，则解除该qq绑定（面板数据可以留着）。这样，当其他绑定了这个uid的账号更新面板时，即使他没有绑定ck，qq指向也会自动变成这个用户。删除uid绑定这个逻辑在崽底层plugins/genshin/apps/user.js中，楼主可以参考一下拨冗给底层pr解决此问题。

最后感谢楼主的这个pr和讲解，帮助我理清了这个问题。
非常好pr，使我大脑思考。

您好，为方便后续沟通，我向您的邮箱发了一封邮件。我注意到该邮件尚未被查看，方便的话能否查阅并回复一下，谢谢。

[UCPr251]

之前我也遇见过此问题但是没有去研究，顺着楼主的思路研究了一下也提出点意见，先理清下思路：
首先会出现这个bug的最根本原因在于redis数据库中miao:rank:uid-info:${uid}对应的数据中的qq没有更新，而该数据只会在setUidInfo方法中进行更新，更新逻辑如下：

可以看出，当且仅当调用setUidInfo时传入的uidType为非bind时，才会更新数据库中的qq指向。
而setUidInfo只会在两个地方被调用（如楼主所说）：
第一处调用是刷新排行操作（见楼主图一），而这只会更新数据库中的面板数据却不会修改qq的指向（此时setUidInfo中的data.qq和qq是同一数据）；
第二处调用是更新面板操作，这里决定调用uidType参数的关键是isSelfUid是否为true（见楼主图二）。若isSelfUid为true，则uidType为ck，更新数据库中qq指向为当前使用者的qq；反之，只会更新数据库中的面板数据而不会修改qq指向。
这里的关键在于isSelfUid这段代码的作用是什么？
其实就是isSelfUid的字面意思，判断该uid账号是否是该用户自己的账号uid。
设想一个情景：多个人都绑定了同一个uid（比如绑定别人uid看面板数据，这很常见），但其中有一个人绑定了ck，那么我们有理由认为绑定了ck的这个用户才是真的uid所有者。isSelfUid这段代码的逻辑就是处理这个问题的：如果使用当前uid的用户绑定了ck，那么就把这个uid的qq数据绑定为该用户；反之则无法判断这个uid的所有权，保持原qq绑定不变。而如果使用某个uid的用户都没有绑定ck，那么这个uid的qq数据就始终会是第一个绑定的那个人的qq，这也很合理。
由上，这段逻辑本身是没问题的，唯一的问题是在都没有绑定ck的情况下，第一个绑定的用户即使解绑了，数据库中该uid的数据里qq的指向仍然是他，这才是真正有问题的地方。
楼主的修改是可以解决排名中显示的qq头像错误的问题的，但是也会导致其他问题：isSelfUid和uidType会变成无效数据。因为如果按照楼主的修改，那么所有uid数据中的uidType都会变成ck，进而导致无法判断谁才是真正的号主，isSelfUid这段代码和setUidInfo中修改qq绑定的这段代码都会无法发挥其原本的作用。
综上，其实最大的问题是在第一个绑定的用户解除绑定时没有同步解除数据库中miao:rank:uid-info:${uid}的qq绑定，所以最好的办法应该是在解除绑定时同时解除qq绑定，而不是直接修改楼主所修改的这部分逻辑。建议改成：解除uid绑定时，查询miao:rank:uid-info:${uid}数据，如果存在且其中的qq指向为当前用户，则解除该qq绑定（面板数据可以留着）。这样，当其他绑定了这个uid的账号更新面板时，即使他没有绑定ck，qq指向也会自动变成这个用户。删除uid绑定这个逻辑在崽底层plugins/genshin/apps/user.js中，楼主可以参考一下拨冗给底层pr解决此问题。
最后感谢楼主的这个pr和讲解，帮助我理清了这个问题。
非常好pr，使我大脑思考。

您好，为方便后续沟通，我向您的邮箱发了一封邮件。我注意到该邮件尚未被查看，方便的话能否查阅并回复一下，谢谢。

刚看了看邮箱，发现在垃圾邮箱里的 😂 已回复

[UCPr251]

之前我也遇见过此问题但是没有去研究，顺着楼主的思路研究了一下也提出点意见，先理清下思路：
首先会出现这个bug的最根本原因在于redis数据库中miao:rank:uid-info:${uid}对应的数据中的qq没有更新，而该数据只会在setUidInfo方法中进行更新，更新逻辑如下：

可以看出，当且仅当调用setUidInfo时传入的uidType为非bind时，才会更新数据库中的qq指向。
而setUidInfo只会在两个地方被调用（如楼主所说）：
第一处调用是刷新排行操作（见楼主图一），而这只会更新数据库中的面板数据却不会修改qq的指向（此时setUidInfo中的data.qq和qq是同一数据）；
第二处调用是更新面板操作，这里决定调用uidType参数的关键是isSelfUid是否为true（见楼主图二）。若isSelfUid为true，则uidType为ck，更新数据库中qq指向为当前使用者的qq；反之，只会更新数据库中的面板数据而不会修改qq指向。
这里的关键在于isSelfUid这段代码的作用是什么？
其实就是isSelfUid的字面意思，判断该uid账号是否是该用户自己的账号uid。
设想一个情景：多个人都绑定了同一个uid（比如绑定别人uid看面板数据，这很常见），但其中有一个人绑定了ck，那么我们有理由认为绑定了ck的这个用户才是真的uid所有者。isSelfUid这段代码的逻辑就是处理这个问题的：如果使用当前uid的用户绑定了ck，那么就把这个uid的qq数据绑定为该用户；反之则无法判断这个uid的所有权，保持原qq绑定不变。而如果使用某个uid的用户都没有绑定ck，那么这个uid的qq数据就始终会是第一个绑定的那个人的qq，这也很合理。
由上，这段逻辑本身是没问题的，唯一的问题是在都没有绑定ck的情况下，第一个绑定的用户即使解绑了，数据库中该uid的数据里qq的指向仍然是他，这才是真正有问题的地方。
楼主的修改是可以解决排名中显示的qq头像错误的问题的，但是也会导致其他问题：isSelfUid和uidType会变成无效数据。因为如果按照楼主的修改，那么所有uid数据中的uidType都会变成ck，进而导致无法判断谁才是真正的号主，isSelfUid这段代码和setUidInfo中修改qq绑定的这段代码都会无法发挥其原本的作用。
综上，其实最大的问题是在第一个绑定的用户解除绑定时没有同步解除数据库中miao:rank:uid-info:${uid}的qq绑定，所以最好的办法应该是在解除绑定时同时解除qq绑定，而不是直接修改楼主所修改的这部分逻辑。建议改成：解除uid绑定时，查询miao:rank:uid-info:${uid}数据，如果存在且其中的qq指向为当前用户，则解除该qq绑定（面板数据可以留着）。这样，当其他绑定了这个uid的账号更新面板时，即使他没有绑定ck，qq指向也会自动变成这个用户。删除uid绑定这个逻辑在崽底层plugins/genshin/apps/user.js中，楼主可以参考一下拨冗给底层pr解决此问题。
最后感谢楼主的这个pr和讲解，帮助我理清了这个问题。
非常好pr，使我大脑思考。

您好，为方便后续沟通，我向您的邮箱发了一封邮件。我注意到该邮件尚未被查看，方便的话能否查阅并回复一下，谢谢。

请问pr有在准备继续吗，如果没时间的话要不我直接给崽底层pr了？已经过挺久了。