WordPress 自动发布去重与 undefined 正文修复:如何避免重复草稿与空正文问题

内容自动化流程中,Node.js 脚本驱动 WordPress REST API 已成为技术博客的标配。但实际部署中,开发者常因忽略边界条件导致重复草稿堆积、正文字段 undefined 或 Markdown 渲染异常等问题。本文基于 LearnCode 实战案例,拆解本地脚本优化方案,确保内容分发可靠性。

为什么要改

早期流程依赖 HTTP POST 创建文章,但随着发文频率提升和 AI 生成内容引入,出现两个核心问题:

  1. 重复发布风险:网络波动或 CI/CD 流水线并发执行时,相同标题的文章会被多次创建为草稿。这导致数据库冗余、RSS 订阅源重复条目,甚至破坏依赖唯一 Post ID 的数据关联。
  2. 正文为空陷阱:模板填充或 AI 生成环节若字段缺失、解析错误或被截断,content 字段可能变为 undefined 或空字符串。WordPress API 有时接受空内容但显示空白,或返回静默失败。这种脏数据入库后清理成本高,严重影响阅读体验。

这些问题不仅浪费存储资源,更破坏内容排期准确性。需要更健壮的发布层,而非依赖上游生成质量。

关键决策

为解决上述问题,我们决定在发布环节引入本地校验与去重逻辑,而非完全依赖 AI Agent 或云端服务。决策依据如下:

  • 可控性与低成本:将去重和校验逻辑封装在本地 Node.js 脚本中,无需额外部署 Redis 或消息队列服务。参考 OpenClaw 自动化设计原则,强调本地优先处理效率。
  • 即时反馈:在发送 HTTP 请求前拦截错误,避免无效网络往返和 API 配额消耗。相比等待服务器返回 400 错误再重试,本地预检能节省大量时间。
  • 兼容性优先:利用 WordPress REST API 标准特性(如按标题查询),无需修改 WP 核心代码或安装插件,保持系统轻量。

更多自动化降本案例可查阅 自动发文成本优化案例

实施过程

改造主要涉及两个核心脚本文件的逻辑增强:build-post-draft.js(构建阶段)和 publish-wp-draft.js(发布阶段)。

1. 正文完整性校验

publish-wp-draft.js 中,我们增加了严格的正文检查函数。若检测到 content 为 null、undefined 或仅包含空白字符,脚本直接终止发布并抛出明确错误,防止脏数据入库。

// publish wp draft.js 片段:正文校验
function validateContent(content) {
  // 检查类型和非空性,防止 undefined 被隐式转换
  if (!content || typeof content !== 'string' || content.trim() === '') {
    throw new Error('Post content is empty or undefined. Skipping publish to prevent blank posts.');
  }
  return true;
}

2. 智能去重策略

为避免重复创建,脚本在发布前通过 REST API 查询现有草稿。关键在于标题标准化:去除空格、特殊符号并统一转为小写,以应对细微差异导致的漏判。若发现同名草稿,则更新该草稿 ID 而非新建,保证唯一性。

// 标题标准化函数,消除格式差异
function normalizeTitle(t) {
  return String(t || '')
    .replace(/\s+/g, '')       // 移除所有空格
    .replace(/[ –—]/g, '')     // 移除破折号等特殊符号
    .toLowerCase();            // 统一小写
}

// 查找重复草稿
async function findDuplicateDraft(title) {
  const base = (process.env.WP_BASE_URL || 'https://www.learncode.college').replace(/\/$/, '');
  const url = new URL(`${base}/wp-json/wp/v2/posts`);
  url.searchParams.set('status', 'draft');
  url.search

3. Markdown 转 HTML 处理

确保传入 WordPress 的内容是有效 HTML。虽然 WordPress 支持 Gutenberg 块编辑,但在 API 层面,传统 HTML 格式兼容性更好且更稳定。构建脚本负责将 Markdown 中的 H1、表格、代码块正确转换为 HTML 标签,避免前端渲染错乱。例如,确保代码块使用

 包裹,表格使用标准  结构。

结果与数据

改造后自动化发布流程稳定性显著提升:

  • 零重复草稿:通过标题去重逻辑,成功避免因重试导致的重复文章创建。测试中连续执行 10 次相同内容的发布任务,最终仅保留一篇最新状态的草稿。
  • 空正文拦截率 100%:所有包含 undefined 内容的发布请求被本地脚本拦截,未产生任何无效 API 调用。日志中清晰记录被拦截原因,便于排查上游生成问题。
  • 效率提升:相比人工检查,脚本处理耗时减少至毫秒级,且无需等待服务器响应即可提前报错。

*注:具体性能指标如高并发下的 QPS 提升比例,仍需验证实际生产环境的大规模数据。*

可复用清单

如果你正在构建类似自动化系统,请对照以下清单进行检查:

  1. 前置校验:在发送 API 请求前,务必校验关键字段(如 title, content)的非空性和类型。
  2. 幂等性设计:实现基于业务键(如标题)的去重逻辑,支持“存在则更新,不存在则创建”。
  3. 标题规范化:对比较用的文本进行标准化处理(去空格、转小写、去标点),以应对细微差异。
  4. 错误日志:记录被拦截的请求详情,特别是 undefined 的来源,以便回溯上游生成逻辑。
  5. 不适用场景:对于极高并发(每秒数百次以上)的场景,频繁查询 WP API 可能造成性能瓶颈,建议引入 Redis 缓存去重状态或使用 Webhook 机制。

 

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。