xiaoxiaohaoa

虽然时隔两周了还是来更新一下后续吧，结论是确实不是脚本本身的问题，是 dnf 进程的问题。

定位问题进程：dmesg | grep -i memory 输出中包含大量 Out of memory: Killed process ***** (dnf) 的 OOM 报错信息，得以确定是 dnf 相关进程的问题；进一步搜索后确认是由于 dnf 软件包信息更新导致的系统 OOM 崩溃。
解决办法：sudo systemctl disable dnf-makecache.timer

参考：
Linux dmesg 命令介绍 ( https://www.jianshu.com/p/4a029091b705)
解决 centos dnf 自动更新异常问题 ( https://thisblog.cn/2023/05/10/centos-dnf-makecache/)

@harmless 确实有这个可能，用 ps -aux 命令会发现大量不认识的进程，但我个人使用的云实例上除了这个脚本没有主动运行过其他服务，所以一直认为是系统进程。可能有必要实时监控各进程的内存占用并输出日志了。感谢解答！

@Van426326 谢谢指点，但实际看下来，ai 的回答中有效的结果似乎并不是很多？

1.已检查过涉及到写入的文件，大小均不超过 20kb ，应该可以认为不是这个问题；

2.列表改为字典/集合的思路有道理，但有资料说 dict 的内存占用比 list 更大？还是说这里的“内存”概念我理解得不对？
暂时无法发布链接，先引用一段原文：
-和 list 比较，dict 有以下几个特点：
-a.查找和插入的速度极快，不会随着 key 的增加而变慢；
-b.需要占用大量的内存，内存浪费多。
-而 list 相反：
-a.查找和插入的时间随着元素的增加而增加；
-b.占用空间小，浪费内存很少。

3.反复遍历 list 似乎是一个问题，我会试着搜索一下生成器的用法；

4.使用 bilibili_api 库的其他人没有报告过内存泄漏问题，并且不在本人的能力范围内，暂不考虑；

内存监控我也有考虑过，但具体怎么实现还暂时没想好。先试试用其他办法把问题解决了，之后再考虑监控吧。谢谢解答！
@Van426326

@shurimasoul 确实，运行日志记录了一些报错信息，不过没有什么严重的影响所以一直放着没管……我去搜一下异常处理要怎么实现。感谢解答！