为什么自动发布接口需要单独设计

个人博客一旦接入自动化写作，就不能再只依赖后台人工发文流程。后台表单适合人使用，自动发布接口适合程序使用。两者如果混在一起，后期很容易出现权限过大、日志不清、失败难排查等问题。

一个稳妥的 Flask 自动发布接口，至少要解决五件事：调用方如何鉴权，文章 JSON 如何校验，发布失败如何重试，URL slug 如何保持稳定，发布后如何确认真的写入线上数据库。

用独立 Token 保护机器接口

自动化脚本不应该保存管理员账号密码。更好的方式是给机器接口配置独立 Token：

POST /api/articles/publish
Authorization: Bearer <AUTO_PUBLISH_TOKEN>

Token 放在服务器 .env 中，本机自动化环境保存同一份值。这样即使 Token 泄露，也只需要替换环境变量，不必改管理员密码。

接口内部可以用常量时间比较，避免简单字符串比较带来的细节风险：

import secrets

secrets.compare_digest(supplied_token, expected_token)

发布前校验 JSON

自动化生成的内容不能默认可信。发布脚本至少要检查：标题不能为空，摘要不能超过数据库长度，正文不能为空，分类 slug 必须存在或允许自动创建，状态只能是 draft、submitted、published，tags 必须是列表。

如果校验失败，应返回明确的 400；Token 错误返回 401；数据库唯一冲突返回 409。这样自动化日志能直接看出问题，而不是只看到“发布失败”。

slug 必须使用 ASCII

中文标题可以很好，但 URL slug 最好保持 ASCII。原因很现实：不同终端、日志、搜索提交脚本和 HTTP 客户端对中文路径显示方式不一致，容易出现看似乱码的日志。ASCII slug 能降低排查成本，也更适合自动化。

推荐格式：

flask-auto-publish-token-retry-check-zh
flask-auto-publish-token-retry-check-en

中文文章和英文文章应使用不同 slug。中文可以用 -zh 或 -cn，英文用 -en。

发布失败要重试，但不能盲目重试

网络中断、临时 502、连接超时，这类问题适合重试一次。参数错误、鉴权失败、正文为空，则不应该重试，因为重试只会重复失败。

发布脚本可以把错误分成两类：

• 4xx 参数或权限错误：立即失败，提示修配置。
• 网络错误或 5xx：等待几秒后重试一次。

这样既能提高成功率，也不会把真正的配置错误隐藏掉。

发布后要核对线上结果

接口返回成功不等于前台一定展示正常。至少要拿到返回的 id、slug、status，拼出文章 URL，再做一次 HTTP 检查。如果是正式发布，前台 URL 应该返回 200。

还可以定期查线上数据库最近文章：

select id, status, slug, title, published_at
from article
order by id desc
limit 20;

这一步能快速发现“自动化跑了，但没有写入线上”的问题。

发布后再做收录提交

文章写入成功后，可以等待 10 到 30 分钟，再向搜索平台提交 URL 或 sitemap。等待的意义是让站点缓存、sitemap、页面渲染都有时间稳定下来。

如果百度或 Google 凭据没配置，脚本应该明确报告缺失项，而不是假装提交成功。自动化任务的结果报告，应包含文章 URL、发布状态和收录提交状态。

总结

Flask 博客自动发布接口不复杂，但要把边界做清楚：后台给人用，API 给机器用；Token 独立配置；JSON 严格校验；slug 使用 ASCII；网络失败可以重试；发布后必须核对线上结果。这样自动化发文才不是“看起来跑了”，而是真正可追踪、可恢复、可长期维护。