根据Slug向WordPress查询，拿到ID后，执行更新文章和发布文章

这是一个非常核心的技术细节。简单来说，因为 WordPress 官方提供的 REST API 在设计规范上，要求必须通过“数字 ID”来精准定位要修改的资源。

我们可以把更新文章想象成去寄宿制学校找学生修改档案：

• Slug（别名） 就像是学生的“身份证号/名字”（虽然唯一，但生活老师需要去系统里查一下他具体住在哪个宿舍）。
• Post ID（文章ID） 就像是学生的“宿舍号+床位号”（只要拿到这个，宿管阿姨就能直接开门进去改档案）。

下面通过具体的 API 设计原理和对比，帮你彻底理清为什么要多这“先查询、后更新”的一步：

1. WordPress REST API 的路由设计限制

WordPress 的更新接口是严格按照 RESTful 规范 设计的。它的更新路由结构是固定的：

$$\text{POST } /wp-json/wp/v2/posts/{id}$$

注意看，这个路由的末尾只接受数字 ID（例如 /wp-json/wp/v2/posts/1024）。WordPress 没有提供类似于 POST /wp-json/wp/v2/posts/slug/how-to-use-github-actions 这种直接通过别名更新的接口。

所以，你的 NodeJS 脚本如果不知道 ID，就根本无法拼接出正确的请求 URL。

2. “先查后改”的具体数据流向

当你运行 git push 触发脚本时，整个过程在后台是这样两步走的：

🔄 第一步：通过 Slug 问路（GET 请求）

NodeJS 脚本向 WordPress 发起询问：

“嘿，WP！我这里有一个 slug 叫 how-to-use-github-actions 的文章，你帮我查查它在你的数据库里排第几？”

• 请求： GET /wp-json/wp/v2/posts?slug=how-to-use-github-actions
• WordPress 返回： 一个 JSON 数组。如果找到了，里面会包含这篇文章的所有完整数据，其中就包括 "id": 1234。

💾 第二步：拿着 ID 砸门（POST/PUT 请求）

NodeJS 脚本拿到 1234 这个数字后，立刻组装真正的更新请求：

“找到了！现在把数据库里 ID 为 1234 的文章内容，替换成我最新的 Markdown 文本。”

• 请求： POST /wp-json/wp/v2/posts/1234 （Body 里带着最新的文章标题、内容等）
• WordPress 返回： 更新成功状态码 200 OK。

3. 为什么不直接把 ID 写在 Markdown 里？（方案对比）

你可能会问：“既然最终都要用 ID，那我第一次发布成功后，把 WP 生成的 ID 写回到我本地的 Markdown 文件里（比如在 Frontmatter 加上 wp_id: 1234），下次直接用，不就省去了第一步的查询吗？”

这就是为什么推荐 Slug 匹配的原因。我们来对比一下两种策略：

方案	流程与体验	优缺点
方案 A：本地存 ID	1. 发现新文章 ➔ 2. 调用发布接口 ➔ 3. 脚本修改本地 Markdown 文件，写入 ID ➔ 4. 脚本自动执行一次 git commit & push 把 ID 推回仓库。	❌ 非常痛苦。 脚本会自动修改你的本地源码并自动触发 Git 提交，这会导致本地代码库产生大量自动生成的 Commit 记录，极易引发 Git 冲突。
方案 B：Slug 匹配 (推荐)	1. 发现更新文章 ➔ 2. 用 Slug 查 ID ➔ 3. 用 ID 更新文章。	优雅、单向。 你的 Git 仓库只负责“只读”输出，脚本不需要对你的本地文件做任何修改。你写完代码 git push 就彻底完事了，仓库干干净净。