UCPr

try `--headless=old`

之前我也遇见过此问题但是没有去研究，顺着楼主的思路研究了一下也提出点意见，先理清下思路： 首先会出现这个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](https://github.com/yoimiya-kokomi/Miao-Yunzai/blob/master/plugins/genshin/apps/user.js#L208)中，楼主可以参考一下拨冗给底层pr解决此问题。 最后感谢楼主的这个pr和讲解，帮助我理清了这个问题。 非常好pr，使我大脑思考。

> > 之前我也遇见过此问题但是没有去研究，顺着楼主的思路研究了一下也提出点意见，先理清下思路： > > 首先会出现这个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，这也很合理。...

> > 之前我也遇见过此问题但是没有去研究，顺着楼主的思路研究了一下也提出点意见，先理清下思路： > > 首先会出现这个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，这也很合理。...

> 我说怎么最近docker重启后无法运行还得手动pnpm install呢 是这样的，生产必需依赖放在开发可选依赖里，不知道为啥，还没人改

> 即使自动顺序拉起webview，性能上也可以接受，开源阅读项目就是这么做的，不会卡死，上千个书源顺序校验也不会很夸张 防爬这东西解决起来就和猫鼠游戏一样是个无底洞。既然提到阅读了那你应该也知道阅读的书源规则是支持js的，实际上绝大部分书源都是要编写js才能运作的，没有登录态只靠webview和xpath根本抓不到数据，毕竟很多小说网站不登录根本用不了，而看动漫的话很多可以不登录直接用，目前的解析策略也只能解析这种网站。 最简单的办法就是在规则的高级设置加个cookie头，有能力的用户自己抓填上，至少能用。 真要彻底解决的话，就只能像阅读那样支持webview和xpath的同时用js来解决登录等问题，但是这样的话各方面的开发成本都会高不少😂

> > 即使自动顺序拉起webview，性能上也可以接受，开源阅读项目就是这么做的，不会卡死，上千个书源顺序校验也不会很夸张 > > 防爬这东西解决起来就和猫鼠游戏一样是个无底洞。既然提到阅读了那你应该也知道阅读的书源规则是支持js的，实际上绝大部分书源都是要编写js才能运作的，没有登录态只靠webview和xpath根本抓不到数据，毕竟很多小说网站不登录根本用不了，而看动漫的话很多可以不登录直接用，目前的解析策略也只能解析这种网站。 > > 最简单的办法就是在规则的高级设置加个cookie头，有能力的用户自己抓填上，至少能用。 > > 真要彻底解决的话，就只能像阅读那样支持webview和xpath的同时用js来解决登录等问题，但是这样的话各方面的开发成本都会高不少😂 只是获取cookie的问题的话也还好，和阅读的部分书源一样，在内置浏览器中跳转到目标网页，登录后自动获取cookie，这个办法也不算难事