1. 先看状态表

内容的 status 字段不是简单的「开 / 关」，它有五种取值：

只有 1 会在前台展示。这是「后台能看到、前台看不到」类问题的第一排查点。

2. 最常见的两种踩坑

2.1 传了 status=1，结果还是待审核

外部 API 和 MCP 写入时明明传了 status: 1，内容却变成了 -1 待审核。原因是敏感词检查：内容命中敏感词时，系统会把状态强制设为待审核，需要人工过一遍。

这不是接口 bug，是预期行为。批量导入内容时尤其容易遇到——导完发现前台一篇都没有，其实全在待审核队列里。

2.2 status 传 0，含义完全不同

这是最容易出错的地方：同一个数字 0，在写入和筛选两个场景里含义相反。

也就是说：想改状态时不能传 0，传了等于没改；想看全部内容时要传 0，不传则按其他默认处理。弄反了会出现「改了没生效」或「少了一堆内容」的错觉。

3. 排查顺序

1. 看内容状态是不是 1。后台列表里确认，别只看「我保存过了」。
2. 看栏目是否启用。内容状态正常但栏目被禁用，前台同样看不到。
3. 看是不是待审核。批量导入后尤其要查这一项。
4. 看栏目模板有没有写死过滤条件。模板里如果加了额外的状态或字段过滤，状态对了也不显示。
5. 清缓存再试。内容发布后前台缓存会失效，但如果读的是缓存，可能短暂不一致。

4. 批量导入内容的建议

• 导入后第一时间筛一遍待审核状态，别等前台反馈。
• 如果确定内容无需审核，去后台确认敏感词配置是否符合预期。
• 用 list_articles 核对时，记得传 status: 0 才能看到全部状态的条目，否则容易误判「导入失败」。
• 导入后按返回的 id 建立本地映射，后续更新删除直接用 id，不用再查一次列表。

5. 相关字段

留言和评论（互动数据）用的是另一套状态：1 通过、-1 待审核、2 拒绝。前台提交留言默认就是 -1 待审核，需要在后台审核后才会公开显示——如果留言一直不出现，先去审核列表看。