首先谢谢提供建议与Api信息。

其实这个需求之前考虑过，但就我自身的情况来说，我关注了很多up主，其实在我关注的这么多up里，我也是有优先等级的。所以就设计的简单粗暴点，直接配置了up主Id。

获取“特别关注”的up主，我倒是没有想到，这个想法很赞，后面会加入版本迭代中。

投币的逻辑现在其实已经写的有点复杂了，主要的难点是在，一个视频的可投币次数是有限制的（目前看是2次），所以并不是随机获取到一个视频就可以投币成功的。

然而，“当前视频是否可以投币”需要单独调用另一个Api获知，在获取视频详情Api中并不会返回该信息。这样就导致会调用很多次接口，如果一个up有100个视频，那调用100次显然是不合适的。

当前的投币逻辑是设置了尝试次数，尝试一定次数后，如果随机获取到的视频都不能投币，那就去排行榜中随机获取其他视频进行投币。

如果有朋友有更好的想法，或者发现更有用的投币相关的api，也欢迎提供思路，谢谢。

大多数人都是会用特殊关注组的,也可以专门为自动投币做一个组,但是觉得没必要.就用特殊关注组 就挺好的.

其实你说的问题,有一个思路可以解决.
有一个一周硬币历史记录API,我们可以通过这个来解决.

当任务执行的时候

• 1 先获取最近一周的硬币记录
• 2 获取 关注UP主的 视频
  • 条件是符合最近6天的更新的视频
• 结合 1和2 的信息 得出满足数量即可, 若不满足 从其他途径获取视频来投币,因为可能有些人关注UP主数量少,更新视频少导致获取不足

最近一周的硬币变化接口

curl 'https://api.bilibili.com/x/member/web/coin/log?jsonp=jsonp' \
  -H 'authority: api.bilibili.com' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36' \
  -H 'origin: https://account.bilibili.com' \
  -H 'sec-fetch-site: same-site' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-dest: empty' \
  -H 'referer: https://account.bilibili.com/account/coin' \
  -H 'accept-language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7,zh-TW;q=0.6' \
  -H $'cookie: {跟之前的一样}' \
  --compressed

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

他是说优先up主引起的问题，如果是每天只从排行榜随机选，就没问题，因为重复投的几率不大。
优先up的话，就可能出现尝试很多次都失败的问题。
比如，一个人只配置了一个up主ID（或者只关注了一个），这个up有100个视频，那需要每天调用100次“判断是否投过”的接口吗？

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

他是说优先up主引起的问题，如果是每天只从排行榜随机选，就没问题，因为重复投的几率不大。
优先up的话，就可能出现尝试很多次都失败的问题。
比如，一个人只配置了一个up主ID（或者只关注了一个），这个up有100个视频，那需要每天调用100次“判断是否投过”的接口吗？

如果不是运行在actions上的用户，相关数据持久化到本地就好了。

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

他是说优先up主引起的问题，如果是每天只从排行榜随机选，就没问题，因为重复投的几率不大。
优先up的话，就可能出现尝试很多次都失败的问题。
比如，一个人只配置了一个up主ID（或者只关注了一个），这个up有100个视频，那需要每天调用100次“判断是否投过”的接口吗？

如果不是运行在actions上的用户，相关数据持久化到本地就好了。

其实没必要持久化到本地, 特别是有些新闻媒体比如CCTV的频道 一天几次投稿.随随便便就搞定了...

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

他是说优先up主引起的问题，如果是每天只从排行榜随机选，就没问题，因为重复投的几率不大。
优先up的话，就可能出现尝试很多次都失败的问题。
比如，一个人只配置了一个up主ID（或者只关注了一个），这个up有100个视频，那需要每天调用100次“判断是否投过”的接口吗？

如果不是运行在actions上的用户，相关数据持久化到本地就好了。

其实没必要持久化到本地, 特别是有些新闻媒体比如CCTV的频道 一天几次投稿.随随便便就搞定了...

那问题就来了，投币给CCTV和投币给热榜的的视频也没什么区别呀，背离了最初的功能需求：投币给关注的列表

那问题就来了，投币给CCTV和投币给热榜的的视频也没什么区别呀，背离了最初的功能需求：投币给关注的列表

我只是举个类似CCTV的例子,你没仔细看需求造成的问题..你特殊关注的主播,可能每天不够完成经验任务,这时候就需要投给其他视频.

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

他是说优先up主引起的问题，如果是每天只从排行榜随机选，就没问题，因为重复投的几率不大。
优先up的话，就可能出现尝试很多次都失败的问题。
比如，一个人只配置了一个up主ID（或者只关注了一个），这个up有100个视频，那需要每天调用100次“判断是否投过”的接口吗？

如果不是运行在actions上的用户，相关数据持久化到本地就好了。

数据持久化可以考虑 leancloud？

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

他是说优先up主引起的问题，如果是每天只从排行榜随机选，就没问题，因为重复投的几率不大。
优先up的话，就可能出现尝试很多次都失败的问题。
比如，一个人只配置了一个up主ID（或者只关注了一个），这个up有100个视频，那需要每天调用100次“判断是否投过”的接口吗？

如果不是运行在actions上的用户，相关数据持久化到本地就好了。

其实没必要持久化到本地, 特别是有些新闻媒体比如CCTV的频道 一天几次投稿.随随便便就搞定了...

那问题就来了，投币给CCTV和投币给热榜的的视频也没什么区别呀，背离了最初的功能需求：投币给关注的列表

@JunzhouLiu
谈一下我自己的投币实现逻辑

模式1:随机抽取视频6个视频进行投币

模式2:让用户配置文件从关注列表，关注组列表，自定义列表中三选一作为up主来源，从up主中抽取最新的m个视频和n个专栏进行投币(m,n由用户配置文件指定，专栏和视频谁优先由用户指定，up主稿件不足以实际数量为准)，投币失败则轮到下一个up主继续

模式3:让用户配置文件指定任意个关键字(可额外包括视频时长约束，专区约束，排序依据约束和每个关键字最大获得的视频数约束)，通过主站搜索引擎搜索关键字得到视频列表，全部投币失败则搜索下一个关键字继续

用户配置文件指定一个或多个模式进行排列组合，任一个模式投币失败继续进行后面的模式

其他细节方面：只请求一次硬币经验接口内部计数本次投币数量，投币失败与成功与否只判断投币接口的返回值，不提前判断是否投过币，每个视频无论是否原创仅投一个币，除了接口返回超过投币数量的错误会继续进行投币外，返回其他一切错误立即退出投币(包括网络异常等其他异常)，不尝试重试，所有模式获取到的所有视频均投币失败，退出投币不尝试重试。

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

他是说优先up主引起的问题，如果是每天只从排行榜随机选，就没问题，因为重复投的几率不大。
优先up的话，就可能出现尝试很多次都失败的问题。
比如，一个人只配置了一个up主ID（或者只关注了一个），这个up有100个视频，那需要每天调用100次“判断是否投过”的接口吗？

如果不是运行在actions上的用户，相关数据持久化到本地就好了。

其实没必要持久化到本地, 特别是有些新闻媒体比如CCTV的频道 一天几次投稿.随随便便就搞定了...

那问题就来了，投币给CCTV和投币给热榜的的视频也没什么区别呀，背离了最初的功能需求：投币给关注的列表

@JunzhouLiu
谈一下我自己的投币实现逻辑

模式1:随机抽取视频6个视频进行投币

模式2:让用户配置文件从关注列表，关注组列表，自定义列表中三选一作为up主来源，从up主中抽取最新的m个视频和n个专栏进行投币(m,n由用户配置文件指定，专栏和视频谁优先由用户指定，up主稿件不足以实际数量为准)，投币失败则轮到下一个up主继续

模式3:让用户配置文件指定任意个关键字(可额外包括视频时长约束，专区约束，排序依据约束和每个关键字最大获得的视频数约束)，通过主站搜索引擎搜索关键字得到视频列表，全部投币失败则搜索下一个关键字继续

用户配置文件指定一个或多个模式进行排列组合，任一个模式投币失败继续进行后面的模式

其他细节方面：只请求一次硬币经验接口内部计数本次投币数量，投币失败与成功与否只判断投币接口的返回值，不提前判断是否投过币，每个视频无论是否原创仅投一个币，除了接口返回超过投币数量的错误会继续进行投币外，返回其他一切错误立即退出投币(包括网络异常等其他异常)，不尝试重试，所有模式获取到的所有视频均投币失败，退出投币不尝试重试。

这个功能我已经简单实现了，逻辑挺简单的。

我看到很多投币失败的情况，这时投币前判断下有没有投过就好了。不用这么复杂@JonoloLuo

他是说优先up主引起的问题，如果是每天只从排行榜随机选，就没问题，因为重复投的几率不大。
优先up的话，就可能出现尝试很多次都失败的问题。
比如，一个人只配置了一个up主ID（或者只关注了一个），这个up有100个视频，那需要每天调用100次“判断是否投过”的接口吗？

如果不是运行在actions上的用户，相关数据持久化到本地就好了。

其实没必要持久化到本地, 特别是有些新闻媒体比如CCTV的频道 一天几次投稿.随随便便就搞定了...

那问题就来了，投币给CCTV和投币给热榜的的视频也没什么区别呀，背离了最初的功能需求：投币给关注的列表

@JunzhouLiu
谈一下我自己的投币实现逻辑
模式1:随机抽取视频6个视频进行投币
模式2:让用户配置文件从关注列表，关注组列表，自定义列表中三选一作为up主来源，从up主中抽取最新的m个视频和n个专栏进行投币(m,n由用户配置文件指定，专栏和视频谁优先由用户指定，up主稿件不足以实际数量为准)，投币失败则轮到下一个up主继续
模式3:让用户配置文件指定任意个关键字(可额外包括视频时长约束，专区约束，排序依据约束和每个关键字最大获得的视频数约束)，通过主站搜索引擎搜索关键字得到视频列表，全部投币失败则搜索下一个关键字继续
用户配置文件指定一个或多个模式进行排列组合，任一个模式投币失败继续进行后面的模式
其他细节方面：只请求一次硬币经验接口内部计数本次投币数量，投币失败与成功与否只判断投币接口的返回值，不提前判断是否投过币，每个视频无论是否原创仅投一个币，除了接口返回超过投币数量的错误会继续进行投币外，返回其他一切错误立即退出投币(包括网络异常等其他异常)，不尝试重试，所有模式获取到的所有视频均投币失败，退出投币不尝试重试。

这个功能我已经简单实现了，逻辑挺简单的。

哦哦，我看你配置文件里并没有涉及到这些配置

@JunzhouLiu 配置里只涉及到了优先策略，优先从关注的up主发布的视频投币，如果没有拿到相关数据或者说不足与完成任务，此时请求热榜。

@JunzhouLiu 配置里只涉及到了优先策略，优先从关注的up主发布的视频投币，如果没有拿到相关数据或者说不足与完成任务，此时请求热榜。

BiliBiliTool一直就是这种策略，只是这种策略并不算完美，因为会出现：明明关注的UP主还有视频可以投，但是实际却投了热榜随机的（因为只是尝试，并不是枚举up的所有视频）。
除非是有个接口，可以在返回up主视频列表信息里直接就有已投币数量，否则解决不了上述问题。

@JunzhouLiu 配置里只涉及到了优先策略，优先从关注的up主发布的视频投币，如果没有拿到相关数据或者说不足与完成任务，此时请求热榜。

BiliBiliTool就是这种策略，但是这种策略会出现：明明关注的UP主还有视频可以投，但是实际却投了热榜随机的（因为只是尝试，并不是枚举up的所有视频）。
除非是有个接口，可以在返回up主视频列表信息里直接就有已投币数量，否则解决不了上述问题。

关于策略，我觉得应该采用一般人策略

一般人想投币，会提前去找想投给的up主，观看视频后投币，如果看了几个视频都没把币投出去就换一个up主(没有哪个一般人会去枚举别人up主视频，试几个就得了)

换了几个up主都不能把币投出去，就去搜索自己想看的其他视频了，再取几个自己感兴趣的关键字视频投币

还不能把币投出去，就随机抽几个了视频投了

我认为我上面的投币策略是按照一般人策略走的

@JunzhouLiu 配置里只涉及到了优先策略，优先从关注的up主发布的视频投币，如果没有拿到相关数据或者说不足与完成任务，此时请求热榜。

BiliBiliTool一直就是这种策略，只是这种策略并不算完美，因为会出现：明明关注的UP主还有视频可以投，但是实际却投了热榜随机的（因为只是尝试，并不是枚举up的所有视频）。
除非是有个接口，可以在返回up主视频列表信息里直接就有已投币数量，否则解决不了上述问题。

不需要枚举，如果关注的up不是太少或者年更up，拉取当天的更新就够了。

@JunzhouLiu 配置里只涉及到了优先策略，优先从关注的up主发布的视频投币，如果没有拿到相关数据或者说不足与完成任务，此时请求热榜。

BiliBiliTool就是这种策略，但是这种策略会出现：明明关注的UP主还有视频可以投，但是实际却投了热榜随机的（因为只是尝试，并不是枚举up的所有视频）。
除非是有个接口，可以在返回up主视频列表信息里直接就有已投币数量，否则解决不了上述问题。

关于策略，我觉得应该采用一般人策略

一般人想投币，会提前去找想投给的up主，观看视频后投币，如果看了几个视频都没把币投出去就换一个up主(没有哪个一般人会去枚举别人up主视频，试几个就得了)

换了几个up主都不能把币投出去，就去搜索自己想看的其他视频了，再取几个自己感兴趣的关键字视频投币

还不能把币投出去，就随机抽几个了视频投了

我认为我上面的投币策略是按照一般人策略走的

啊 这就进入了逻辑怪圈了，用户使用这个的工具的目的其实就是解放劳动力，拿到经验。 给喜欢的up投币，反而不是很重要，这部分需求才是小众的。

是的，参杂了我个人的一些执念。以前没有投币习惯，现在既然开了任务要每天投，就想顺便给以前亏欠某些特别喜欢的up的都给补给回去。。。