API 优先还是浏览器自动化？从内容自动发布实践中汲取的经验教训

免费领取国家顶级域名（.cn/.中国）

欢迎加入国家域名信源站点导航

站点智能：AI搭建 AI辅助运营独立站，把生意做到全世界

我们构建了一条流水线，用于生成内容并将其发布到多个平台。事实证明，内容生成只是较简单的一半。发布环节才是真正的工程难点所在——也是我最耗费时间的地方。以下是我会对过去的自己提出的建议。

我总结出的规则：有应用程序接口（API）时用 API，没有时才用浏览器

并非每个平台都提供发布用的应用程序接口（API）。诱人的捷径是在所有地方都使用无头浏览器驱动。切勿如此。原因有二：

1. 某些平台明确禁止此类行为。 X 平台的自动化规则直言不讳：“非基于应用程序接口（API）的自动化形式，例如通过脚本操作 X 网站，可能导致永久封禁。” 如果存在应用程序接口（API），通过脚本操作网站并非聪明的变通之法，而是迟早会导致封禁的行为。
2. 浏览器自动化本质上非常脆弱。 一旦有人重命名了层叠样式表（CSS）类名，它就会立即失效。

因此，规则如下：默认使用应用程序接口（API）适配器。仅在不存在应用程序接口（API）的情况下，且仅针对账户所有者被允许执行的操作，才使用浏览器自动化。

各平台实际允许的操作

我查阅了每个平台的主要文档（而非博客文章）。以下是允许自动化操作自有账户的官方发布应用程序接口（API）：

通用执行规则在所有这些平台上惊人地一致：

将你的内容发布到你的账户：允许。
在多个账户间发布相同内容、批量/激进操作、未经请求的通知垃圾信息：禁止。

针对不同平台调整内容，遵守速率限制，不要自动化互动行为。这就是全部要点。

浏览器自动化的陷阱（代价高昂的那些）

1. “我登录了吗？”——不要依据匿名用户也能看到的文本进行断言

我最初的检查是查找诸如“我的动态”和“撰写”之类的词语。这两者对未登录的访客也是可见的。脚本在完全未认证的状态下，却愉快地报告成功。

应当对不应出现的事物之缺失进行断言：

async function isLoggedIn(page: Page): Promise<boolean> {
  const loginBtn = page.getByRole("button", { name: "Sign in", e

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。