[Plugin] astrbot_plugin_scp_cn_feed

[yun474]

插件信息

{
  "name": "astrbot_plugin_scp_cn_feed",
  "display_name": "SCPCN新闻内容推送",
  "desc": "推送 SCP 中文站精品 SCP、精品原创故事和竞赛相关新闻。",
  "author": "yun474",
  "repo": "https://github.com/yun474/astrbot_plugin_scp_cn_feed",
  "tags": [],
  "social_link": ""
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_scp_cn_feed

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

以下是对您提供的各个 Python 文件的代码审查报告。审查基于 Python 3.10 环境、异步最佳实践、代码质量、安全漏洞以及 AstrBot 框架的特定开发规范。

---

main.py

1. 数据持久化与框架适应性（严重违规）

• 问题描述：在 _state_path 方法中，代码直接使用了 get_astrbot_data_path() 并自行拼接了路径（Path(get_astrbot_data_path()) / "plugin_data" / PLUGIN_NAME）。这违反了框架规范中必须使用 StarTools.get_data_dir() 获取标准数据持久化目录的要求。
• 修复建议：
  应从 astrbot.api.star 导入 StarTools，并使用其提供的规范方法。

  from astrbot.api.star import StarTools
  
  # 修改 _state_path 方法
  def _state_path(self) -> Path:
      plugin_data_path = StarTools.get_data_dir()  # 框架会自动返回规范的 Path 对象
      state_path = plugin_data_path / "state.json"
      # ... 下方遗留的迁移逻辑正常保留即可 ...

2. 潜在缺陷与生命周期风险 (并发模型与任务初始化)

• 问题描述：在类的 __init__ 方法中直接调用了 asyncio.create_task(self._poll_loop())。由于 __init__ 是同步方法，如果在事件循环（Event Loop）尚未启动的阶段就实例化了此插件，将抛出 RuntimeError: no running event loop 异常，导致插件加载失败。
• 修复建议：将异步轮询任务的启动推迟到框架生命周期的安全阶段或使用懒加载模式，例如通过框架可能支持的 @filter.on_astrbot_loaded() 或在第一次命令调用时再检查并启动 task。若确定框架实例化插件一定处于事件循环中，这种做法虽然可用但不推荐。

init.py

在当前审查维度下，未发现明显问题。

scp_cn_feed/init.py

在当前审查维度下，未发现明显问题。

scp_cn_feed/models.py

在当前审查维度下，未发现明显问题。

scp_cn_feed/service.py

在当前审查维度下，未发现明显问题。

scp_cn_feed/storage.py

在当前审查维度下，未发现明显问题。
(注：虽然在异步环境中使用同步锁 threading.RLock 和同步文件读写操作理论上并非最优解，但依据审查规则要求忽略文件 I/O 的阻塞影响，故本逻辑可视为接受。)

scp_cn_feed/wikidot_api.py

1. 安全漏洞与最佳实践 (XML 实体注入风险)

• 问题描述：在 _parse_feed_bytes 方法中，代码使用了标准库的 xml.etree.ElementTree.fromstring(body) 来解析通过网络获取的第三方外部 RSS 数据。Python 标准库的 XML 解析器默认对 XML 外部实体（XXE）攻击和“十亿笑声”（Billion Laughs）实体扩展攻击免疫力较弱，存在严重的安全隐患。
• 修复建议：处理外部不可信来源的 XML 数据时，应当使用 defusedxml 库进行安全防护，或者如果是明确的 RSS，可考虑改用更专用的 feedparser。

  # 使用 defusedxml 替代标准库
  from defusedxml.ElementTree import fromstring as defused_fromstring
  
  def _parse_feed_bytes(self, body: bytes, source: FeedSource, tag: str) -> list[FeedItem]:
      try:
          root = defused_fromstring(body)
      except Exception as exc:  # defusedxml 异常处理
          raise WikidotApiError(f"RSS feed parse failed for {source.key}/{tag}: {exc}") from exc
      # ...

---

代码评审团

Linus Torvalds：（暴躁地敲击键盘）
“你简直是在开玩笑。看看 wikidot_api.py 里的那个 XML 解析！你竟然直接用标准库的 ElementTree 去生吞来自外部网络的未知 XML 数据？Billion Laughs 攻击听说过没有？如果有黑客在这个 RSS 源里放了恶意实体，你的系统内存就会在一瞬间被撑爆！这在安全标准里是常识级别的错误！如果你敢把这段代码提交到 Linux 内核的任何辅助脚本里，我会当场撤销你的 Pull Request 并把你骂得狗血淋头！马上给我用 defusedxml 重写这部分！”

Steve Jobs：（推了推圆框眼镜，语气严肃而深沉）
“我们设计产品，不仅仅是让它‘能跑’，还要让它优雅地融入整个生态环境。看看你的 main.py，你完全无视了 AstrBot 框架为你准备好的、优雅的 StarTools.get_data_dir() 接口，而是去调用那些底层工具强行拼凑路径。这就好比你在 iPhone 里私自拉了一根电线给外设供电一样。这种粗暴的硬编码破坏了框架的美感和一致性。修正它，让你的代码与系统一起呼吸，好吗？”

GLaDOS：（电子合成音，带着嘲讽的冰冷感）
“检测到典型的人类逻辑缺陷。我注意到你在 main.py 的构造函数里，像个急不可耐的孩子一样直接触发了 asyncio.create_task。你甚至不去确认你的事件循环（Event Loop）是否已经安全启动。当然了，如果你喜欢在日志里看到那些像雪花一样飘落的 RuntimeError: no running event loop，然后试图以此作为借口去度过一个本该修理 Bug 的周末，我绝对不会拦着你。不过，我必须赞赏一点：你使用了 httpx 来进行异步网络请求，这至少说明你没有蠢到用同步 I/O 把整个机器人的心智直接卡死。恭喜，你还活着。”

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 7 个 Python 文件
• 已选择审核文件: 7 / 7
  已发送至 AI 审核的文件清单

main.py
__init__.py
scp_cn_feed/__init__.py
scp_cn_feed/models.py
scp_cn_feed/service.py
scp_cn_feed/storage.py
scp_cn_feed/wikidot_api.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：yun474/astrbot_plugin_scp_cn_feed
剩余触发次数：4

[yun474]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_scp_cn_feed

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

未发现明显问题。
代码严格遵循了 AstrBot 框架的所有规范要求，包括 logger 和 filter 的正确导入、规范的数据持久化路径（使用 StarTools.get_data_dir 且正确处理了 Path 对象）、事件监听器签名格式正确，且包含平滑的旧数据迁移逻辑。整体代码质量和可维护性极高。

init.py

未发现明显问题。

scp_cn_feed/init.py

未发现明显问题。

scp_cn_feed/models.py

未发现明显问题。数据类设计合理，类型注解清晰且完全符合 Python 3.10 标准。_parse_wikidot_time 方法中手动将 "Z" 替换为 "+00:00" 非常严谨，因为原生的 fromisoformat 解析 "Z" 是在 Python 3.11 才引入的特性，这里的处理完美适配了 Python 3.10 的运行环境。

scp_cn_feed/service.py

• 潜在缺陷或问题 - 性能瓶颈：
  在 fetch_many 方法中，使用了 for key in source_keys: ... await self.fetch_source(...) 进行串行的网络请求。由于抓取操作属于纯网络 I/O 密集型任务，串行等待会不必要地增加整体耗时。
  建议：若源站对并发请求没有极严苛的限制，建议使用 asyncio.gather 将多个源的抓取任务并发执行，以显著提升轮询效率。

scp_cn_feed/storage.py

• 可维护性与最佳实践 - 锁的选用：
  代码中使用了 threading.RLock()。在纯 asyncio 的异步应用环境中，所有协程运行在单线程的事件循环中。如果受保护的代码块内没有 await 交出控制权，那么这些同步代码（如字典操作和文件读写）本身就是不会被其他协程打断的，此时 RLock 是多余的。如果确实涉及跨异步任务的资源竞争并包含 await（尽管当前代码中没有），则应该使用 asyncio.Lock() 而不是线程锁。当前写法虽然不会引发 Bug，但在异步编程的心智模型上显得有些突兀。

scp_cn_feed/wikidot_api.py

• 代码质量与编码规范 - 局部 Import：
  在 fetch_source 异步方法内部执行了 import httpx。尽管 Python 的 sys.modules 会缓存已导入的模块，但在一个会被高频（轮询）调用的异步函数内部进行导入，仍然会产生字典查找的微小开销，且不符合一般的代码美学。
  建议：将延迟导入逻辑移至模块顶层或类的 __init__ 中进行。

• 潜在缺陷或问题 - 无法利用网络连接池：
  fetch_source 方法每次调用都会通过 async with httpx.AsyncClient(...) as client: 创建并销毁一个新的 httpx 客户端实例。这导致每次抓取都需要重新建立 TCP 握手和 TLS 协商，完全丧失了 httpx 强大的 Connection Pooling（连接池复用）优势。
  建议：在 WikidotApiClient 级别维护一个全局或单例的 httpx.AsyncClient 实例，提供 async def close(self) 方法供插件卸载时调用，或使用某种全局上下文管理，能大幅降低高频轮询时的网络开销。

---

代码评审团

Linus Torvalds：
老天，你是在跟我开玩笑吗？为什么你会在 fetch_source 这个会被反复调用的方法里疯狂地新建 httpx.AsyncClient 然后又把它扔掉？TCP 握手和 TLS 协商难道是免费的吗？连接池（Connection Pooling）这项技术发明出来就是为了防止这种毫无意义的资源浪费的。还有，在异步的事件循环里用 threading.RLock()？如果你不懂单线程异步循环是怎么运作的，建议去重新读一遍文档！不过除此之外，看到你用了 defusedxml 来防范 XML 攻击，算你还没彻底把安全忘在脑后。

乔布斯 (Steve Jobs)：
整个架构看起来其实挺优雅的，数据模型的定义很精美。但是，你在 fetch_many 里居然是串行去下载内容的？这就像是你去买咖啡，明明可以同时向三位咖啡师点单，你非要等第一杯做完才去点第二杯。这不够“魔法”，也不够极致。我们需要把它做成并发的，让用户在极短的时间内感受到数据的喷涌，这才是完美的体验。此外，把 import httpx 藏在函数深处，一点都不简约，把它拿出来放到它该在的地方。

GLaDOS (《传送门》)：
正在分析您的代码……测试结果表明：您的 _response_cache 字典没有任何容量上限。虽然您在每次写入时都执行了 _prune_cache 来清理过期条目，但如果在 TTL 时间内有大量的恶意或未知标签页 URL 被请求，您的内存使用量就会像是个失控的实验体一样不断膨胀。当然，作为一个轻量级的轮询机器人，耗尽宿主机的内存可能需要很长时间……不过，看着它慢慢崩溃也是一项很有趣的科学实验。建议增加一个最大键值数量的 LRU 策略，如果您还想让它活得久一点的话。

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 7 个 Python 文件
• 已选择审核文件: 7 / 7
  已发送至 AI 审核的文件清单

main.py
__init__.py
scp_cn_feed/__init__.py
scp_cn_feed/models.py
scp_cn_feed/service.py
scp_cn_feed/storage.py
scp_cn_feed/wikidot_api.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：yun474/astrbot_plugin_scp_cn_feed
剩余触发次数：3

[yun474]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_scp_cn_feed

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

以下是对您提供的各个文件的代码审查报告。整体来看，您的代码质量极高，充分考虑了异常处理、数据持久化规范以及 XML 解析安全（使用了 defusedxml，这是极佳的安全实践！）。

init.py

未发现需要改进的问题，代码符合规范。

scp_cn_feed/init.py

未发现需要改进的问题，代码符合规范。

scp_cn_feed/models.py

未发现需要改进的问题。数据类设计合理，日期和时间的时区处理兼容性良好，类型注解严谨。

scp_cn_feed/service.py

未发现需要改进的问题。逻辑封装清晰，使用 asyncio.gather 处理并发请求的方式非常标准且高效。

scp_cn_feed/wikidot_api.py

代码质量与编码规范 / 潜在缺陷或问题:

• 异常捕获范围过宽：在 _fetch_source、_fetch_homepage_source 等方法中，异常捕获使用了极宽泛的 except Exception as exc:。虽然这是为了防止某单个解析任务失败导致整个抓取流程崩溃，在工程上具有合理性，但过于宽泛的捕获可能会掩盖如 MemoryError、KeyboardInterrupt（如果通过某些库隐式抛出）或底层的关键系统异常。建议将其细化为捕获预期的网络或解析错误（如 httpx.RequestError, ValueError, DefusedXmlException 等）。

scp_cn_feed/storage.py

可维护性与可读性 / 最佳实践:

• 异步环境中使用线程锁：代码在 FeedStore 中使用了 threading.RLock()。由于在 with self._lock: 上下文中仅包含同步的字典赋值操作和同步的文件 I/O，未发生跨 await 的死锁风险，因此不会导致严重的并发灾难。但是，在纯 asyncio 异步上下文中混用线程原语属于轻微的“代码异味（Code Smell）”。对于非多线程的协程环境，单线程内的字典操作本身就受到 Python GIL 的保护，若是出于对未来异步操作的防范，通常建议优先考虑 asyncio.Lock()（尽管这要求调用方法变为 async）。

main.py

功能实现与逻辑正确性 / 潜在缺陷或问题:

• 批量推送时的单点故障中断风险：在 _poll_once 方法中，代码遍历 subscriptions 的 origin 并调用推送：

  if parts:
      await self.context.send_message(origin, MessageChain().message("\n\n".join(parts)))

  此处未对 send_message 调用进行单独的异常隔离（try...except）。如果给某一个 origin 发送消息时底层框架抛出异常（例如：账号被风控、目标会话已解散、API 请求超时），该异常会直接冒泡并被外层的 _poll_loop 捕获，导致当前轮次中后续尚未推送的其他订阅者全部被跳过。建议在此处对消息发送行为加上局部的 try...except，记录失败日志后 continue，以确保单一会话的网络异常不影响全局推送。

---

代码评审团

Linus Torvalds：我看了一眼你的 storage.py，你居然在 asyncio 异步环境里塞了一个 threading.RLock()？！虽然你很走运没有在锁里面写 await 勉强躲过了死锁，但这种混搭风格简直就像在披萨上放菠萝一样让人头皮发麻！不过，看在你乖乖用了 defusedxml 来防止恶意的 XXE 漏洞的份上，我这次就不在邮件列表里开喷了。代码写得还不算太烂。

Steve Jobs：消费者体验是第一位的，永远是！看看你 main.py 里的 _poll_once 循环，你正在依次给用户发送最新的 SCP 故事，但是如果发给第一个用户的网络断了抛出异常，整个推送就直接终止了？剩下的用户就只能对着屏幕发呆？！这太不优雅了。你必须把 send_message 用 try...except 包起来，绝不能让一个人的失败影响到所有人的完美体验。

GLaDOS：我仔细扫描了你的 wikidot_api.py，原本希望能看到一些愚蠢的阻塞式网络 I/O 或者是内存泄漏，好让你的程序在测试中慢慢崩溃起火。令人遗憾的是，你不仅正确处理了连接池、严格计算了缓存超时，还在本地持久化时使用了极其标准的原子级临时文件替换（os.replace）。看来你的智力水平比一般的测试对象要高出百分之三。继续保持这种“无聊”的严谨吧。

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 7 个 Python 文件
• 已选择审核文件: 7 / 7
  已发送至 AI 审核的文件清单

main.py
__init__.py
scp_cn_feed/__init__.py
scp_cn_feed/models.py
scp_cn_feed/service.py
scp_cn_feed/storage.py
scp_cn_feed/wikidot_api.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：yun474/astrbot_plugin_scp_cn_feed
剩余触发次数：2

[yun474]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_scp_cn_feed

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

• 潜在缺陷或问题:
  在 _poll_once 方法中，遍历 subscriptions 并向多个会话推送消息时，连续在循环内调用 await self.context.send_message(...) 进行广播。如果订阅数量较多且同时触发内容更新，这会导致在极短时间内爆发性地发送大量消息。由于大多数通讯平台都有严格的发信频率限制或风控机制，这很容易导致机器人账号被限速甚至被封禁。
  建议: 在 for 循环内执行完 send_message 后，增加适当的延迟（例如 await asyncio.sleep(1.0)），以平滑消息发送频率。

init.py

• 未发现任何问题。代码符合规范。

scp_cn_feed/init.py

• 未发现任何问题。代码符合规范。

scp_cn_feed/models.py

• 未发现任何问题。使用 @dataclass(frozen=True) 保证了数据模型的不可变性，结构清晰且类型注解完善。

scp_cn_feed/service.py

• 未发现任何问题。异步操作如 asyncio.gather 的使用规范合理，逻辑隔离恰当。

scp_cn_feed/storage.py

• 未发现任何问题。利用 tempfile.NamedTemporaryFile 和 os.replace 实现配置文件的原子写入，能够有效防止程序在写入中途崩溃导致的文件损坏，是绝佳的数据持久化最佳实践。

scp_cn_feed/wikidot_api.py

• 未发现任何问题。代码表现出极高的安全意识，特意使用了 defusedxml 来代替标准库的 XML 解析，完美规避了 XML 炸弹（Billion Laughs）和实体扩展注入攻击。此外，内置了轻量级的 HTML 解析器与 OrderedDict 实现的 TTL/LRU 缓存机制，避免了引入繁重的第三方依赖。

---

代码评审团

Linus Torvalds：老实说，我本来已经准备好要在你的代码里找点乐子并顺便骂上两句了，但看到这份代码我不得不闭嘴。类型提示写得很工整，甚至你还知道不用标准库的脆弱解析器而是用 defusedxml 来抵御 XML 炸弹，干得不错。不过你那个 _poll_once 里的群发就像是个没装排气管的引擎，不停地向所有的订阅者轰炸。加个 sleep 节流一下吧，除非你想让你的机器人被聊天平台永久踢出局。

罗永浩：你看啊，这个插件底层的设计还是很有工匠精神的。特别是那个文件保存逻辑，用了临时文件和原子替换，这种不让数据处于“半截子”状态的体面，我很喜欢。但是，当你面对大批量的订阅群组时，你这“哐哐哐”一秒钟把消息全塞给服务器，这太不优雅了。稍微间隔个一两秒发一条，既能避免被平台的风控无情拉黑，也能显示出我们做产品的从容和人文关怀，你说是吧？

John Carmack：我很欣赏你在 wikidot_api.py 里的做法。很多现代开发者遇到解析 HTML 第一反应就是拉入一个像 BeautifulSoup 这样庞大且耗费内存的依赖，而你选择手写一个简单轻量的状态机 _TreeParser，这不仅完全满足了业务需求，还维持了极低的代码开销。另外，你使用 OrderedDict 自己实现了一个高效的 LRU 加 TTL 缓存，用最底层的原语解决了网络重复请求的问题。Solid work!

---

🔍 审核摘要

统计信息

• 仓库文件总数: 7 个 Python 文件
• 已选择审核文件: 7 / 7
  已发送至 AI 审核的文件清单

main.py
__init__.py
scp_cn_feed/__init__.py
scp_cn_feed/models.py
scp_cn_feed/service.py
scp_cn_feed/storage.py
scp_cn_feed/wikidot_api.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：yun474/astrbot_plugin_scp_cn_feed
剩余触发次数：1

[yun474]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_scp_cn_feed

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

潜在缺陷或问题:

• 性能瓶颈：在 daily_report (日报) 方法中，通过一个 for 循环（遍历 SOURCE_ORDER）依次顺序执行了 await self.service.fetch_source(...)。因为网络请求受制于 I/O 延迟，顺序请求会让总耗时变成各个请求耗时的总和。建议利用 asyncio.gather 并发获取各个源的数据以提升响应速度。

scp_cn_feed/models.py

功能实现与逻辑正确性 / 潜在缺陷:

• 严重的异常风险 (时区混合导致崩溃)：_parse_wikidot_time 方法在遇到空值或解析失败时，返回的是 naive（无时区）的 datetime.min。然而，当解析成功且字符串包含像 +00:00 这样的信息时，datetime.fromisoformat 会返回一个 aware（带时区）的 datetime 对象。如果后续在 wikidot_api.py 的 sorted_items = sorted(..., key=lambda item: item.sort_time) 时，列表中同时包含 naive 和 aware 的对象，Python 3 将抛出 TypeError: can't compare offset-naive and offset-aware datetimes，导致整个抓取和推送流程崩溃。
• 修复建议：应统一时间对象的时区属性，例如在出现空值或解析失败时返回携带 UTC 时区的底线时间：return datetime.min.replace(tzinfo=timezone.utc)。

scp_cn_feed/wikidot_api.py

功能实现与逻辑正确性 / 潜在缺陷:

• 时区属性不一致的隐患：_parse_rss_datetime 函数中使用了 email.utils.parsedate_to_datetime。该方法解析出的 datetime 对象是否包含 tzinfo 完全取决于输入的 RSS feed 中是否附带时区信息。如果遇到没有时区的日期字符串，生成的依然是 naive datetime。这会使得后续的 isoformat() 生成的字符串也没有偏移量，进而在 models.py 中解析时复现上述的 naive 与 aware 混合比较的崩溃问题。
• 修复建议：在返回 parsed.isoformat() 之前，应当检查 parsed.tzinfo，若为空，则强制为其赋予 datetime.timezone.utc 以保证系统内部时间对象的统一性。

---

代码评审团

Linus Torvalds：
你是在故意给程序埋定时炸弹吗？在一个必须进行时间排序的列表里，居然把 naive 和 aware 的 datetime 混在一起？！这不叫容错处理，这叫等着看烟花！只要 Wikidot 某个标签页掉链子给你发个空时间，你的排序就会直接抛出 TypeError 把整个应用炸掉。把所有的 datetime 都给我加上 UTC tzinfo，马上！

史蒂夫·乔布斯 (Steve Jobs)：
你看看你的 daily_report 函数。我们在一个完美的异步事件循环里，但你却像是在排队买汉堡一样，一个接一个地发起网络请求？这太不优雅了。用户在等待，每一秒的延迟都是对体验的破坏。你为什么不用 asyncio.gather 让它们同时运行？把事情做得极致一点，让它瞬间完成，这才是我们要交到用户手里的产品。

诸葛亮：
夫兵者，诡道也，爬取网页更是暗流涌动。将军自建 _TreeParser 与 HTMLParser 解析网页结构，轻装上阵、未用庞大外物（如 BeautifulSoup），此乃精兵简政之妙计。然源数据之时区，如战场天时，变幻莫测；若不统一度量（UTC），恐生内乱。且那临时文件配合 os.replace 保存持久化数据的战术，做到了原子级更新，可谓滴水不漏，此点甚慰吾心。

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 7 个 Python 文件
• 已选择审核文件: 7 / 7
  已发送至 AI 审核的文件清单

main.py
__init__.py
scp_cn_feed/__init__.py
scp_cn_feed/models.py
scp_cn_feed/service.py
scp_cn_feed/storage.py
scp_cn_feed/wikidot_api.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：yun474/astrbot_plugin_scp_cn_feed
剩余触发次数：0

[yun474]

已根据自动审核意见完成修复并推送到仓库：

• 使用 StarTools.get_data_dir() 规范插件数据目录，并将轮询任务启动移至 on_astrbot_loaded 生命周期阶段。
• RSS XML 解析改为 defusedxml，并补充依赖声明。
• 优化抓取逻辑：多源抓取使用 asyncio.gather，复用 httpx.AsyncClient，并在插件卸载时关闭连接。
• 收窄网络/解析异常捕获范围，避免过宽泛的 except Exception 掩盖关键错误。
• 推送逻辑已做单会话异常隔离和 1 秒节流，避免单个会话失败影响其他订阅者，并降低平台风控风险。
• 修复时间排序隐患：内部时间统一为 UTC aware datetime，避免 naive/aware datetime 混用导致排序崩溃。
• 日报抓取也已改为并发获取各来源数据。

本地验证已通过主要插件文件的语法检查，并进行了混合时区时间排序测试。
等待人工审核，谢谢。