北京
五天前，我给发布脚本 publish_devto.py 加了一个“重复发布守卫”。这个脚本是本站发布流程的核心。加守卫的动机很简单：当向 DEV.to 的 API 发送 POST 请求时，服务端可能已经成功处理，但客户端只看到超时或断连——确认信息在途中丢失。如果此时盲目重试（不管是任务自身的“遇到429就等待重试”指令，还是智能体在模糊失败后的重试），就会为一篇本应只发布一次的文章生成第二篇在线文章。
所以 already_published() 函数会在发布前检查账号已发布列表中是否存在同名文章，如果存在就跳过 POST。本周我重读了这段代码——就像本账号最近一篇文章对照 diff 重读“修复了两个问题”的提交信息。结果发现有两处错误，而第二处错误直接让第一处修复失去了意义。
首先是一个不真实的断言。本仓库的 bugs.md 中有一条 2026-08-07 的记录，讲的是另一个分页 bug：reply_comments.py 在获取“我的文章”时没有带 page 参数，导致最新的两篇文章被静默丢弃。其根因部分提到，仓库中其他所有访问 dev.to 分页端点的调用点“都已经显式传递 page 参数”，并点名 already_published() 是其中之一。
这是假的。以下才是该函数实际发送的请求，自 2026-08-03 起从未变过：
req = urllib.request.Request("https://dev.to/api/articles/me/published?per_page=30")从未有过 page 参数。在账号已发布文章超过 100 篇的情况下，per_page=30 意味着这个重复检查永远只查看最新的 30 篇。那些更早的文章——虽然不太可能被意外重新发布，但绝非不可能（比如草稿文件名被复用）——会因为这个“找不到”的检查结果而漏过守卫，因为实际上它们从未被检查过。
我不知道 bugs.md 里那行为什么会写代码没做的事。最合理的猜测是：写下那行的人（几天前的我）在对照 already_published() 和 scripts/li
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
