博客发布脚本检测不到文章？一个日期字段引发的隐身bug

博客发布脚本检测不到文章？一个日期字段引发的隐身 bug

2026-07-22，kb-writer 为《OpenClaw 内存膨胀排查与修复》生成了完整的博客文章，包括 frontmatter、正文、封面图和 3 张文内插图。文章质量没问题，但用户运行发布脚本时，却发现这篇文章在列表里"凭空消失"了。

更奇怪的是，同一天刚写的另一篇博客《OpenClaw Agent 首次激活与批量管理实战》却能正常检测到并成功发布。

同一套脚本，同一份 frontmatter，为什么有的能看见，有的看不见？

排查过程

第一步：确认文章本身没问题

先检查生成的文章文件：

ls -la /home/oklife/Obsidian-oklife-ub/AI/OpenClaw/06-排障/2026-07-22-1046-openclaw-memory-bloat-troubleshooting.md

文件存在，frontmatter 完整：

• content_type: blog-post
• slug: openclaw-memory-bloat-troubleshooting
• featuredImage 和 images 都已正确设置

肉眼检查没有发现明显问题。

第二步：对比"能发布"和"不能发布"的文章

取两篇文章的 frontmatter 做对比：

看起来两篇文章都符合博客标准，那问题出在哪？

第三步：读脚本源码

直接看 publish-technical.mjs 的扫描逻辑：

// 过滤出未发布的文章提供给用户选择
const unpublished = displayList.filter(a => !a.isPublished);

关键在 displayList 是怎么来的：

// 按日期降序排列（最新的在前），然后取最多 10 篇
articles.sort((a, b) => {
  const dA = a.date ? new Date(a.date).getTime() : 0;
  const dB = b.date ? new Date(b.date).getTime() : 0;
  return dB - dA;
});
const displayList = articles.slice(0, 10);

根因找到了：脚本只取前 10 篇。

根因

publish-technical.mjs 的设计逻辑是：

1. 扫描整个 Obsidian 仓库，找出所有 content_type: blog-post 或带 featuredImage 的 Markdown 文件
2. 按 date 字段降序排列
3. 只取前 10 篇放入 displayList
4. 从这 10 篇里再过滤出未发布的文章供用户选择

问题在于：内存膨胀这篇文章的 date 是 2026-06-30，而仓库里已经有 44 篇博客草稿，大部分日期都是 2026-07-21 或 2026-07-22。

排序结果：

• 第 1 名：2026-07-22 的文章
• 第 2 名：2026-07-22 的文章
• …
• 第 10 名：2026-07-20 的文章
• 第 43 名：2026-06-30 的内存膨胀文章

因为只取前 10 篇，第 43 名的文章直接被脚本"隐身"了。这不是 frontmatter 错误，也不是路径错误，而是脚本的硬性截断导致的 silently drop。

修复方案

方案一：修改文章 date（推荐）

把文章的 date 改成今天：

sed -i 's/^date: 2026-06-30$/date: 2026-07-22/' \
  /home/oklife/Obsidian-oklife-ub/AI/OpenClaw/06-排障/2026-07-22-1046-openclaw-memory-bloat-troubleshooting.md

修改后重新扫描，这篇文章立即排到第 1 位，发布脚本正常显示。

方案二：修改脚本显示上限（治本）

如果经常有旧文章需要补发，可以修改 publish-technical.mjs：

// 原来：只显示前 10 篇
const displayList = articles.slice(0, 10);

// 建议：显示前 50 篇，或去掉截断
const displayList = articles.slice(0, 50);
// 或者：
// const displayList = articles;

这样可以避免旧文章被 silently 过滤。

方案三：增加搜索/筛选功能

最理想的发布工具应该支持：

• 按 slug 搜索文章
• 按日期范围筛选
• 显示所有未发布文章，而不只是最近 10 篇

验证结果

修改 date 后，用 Python 模拟脚本逻辑验证：

python3 scan_blog_articles.py

输出：

前 10 篇:
[1] OpenClaw 内存膨胀排查与修复：从 70GB 到 780MB | 日期: 2026-07-22
...

目标文章排名: 1
✅ 已进入前 10 篇

重新运行发布脚本，文章已成功检测到并发布。

经验教训

1. 脚本限制比 frontmatter 错误更难排查：这篇文章的 frontmatter 完全合规，问题出在脚本的 slice(0, 10) 硬截断。排查时容易先入为主地检查 YAML 格式，忽略业务逻辑。
2. date 字段不只是时间戳：在这个脚本里，date 直接决定文章在列表中的排序，进而决定是否能进入显示范围。补发旧文章时，date 应该设为发布日期，而不是原始写作日期。
3. Silent drop 是最危险的 bug：脚本没有报错、没有警告，只是单纯地把文章从列表里去掉。用户看不到任何提示，只能怀疑自己是不是写错了什么。
4. 对比法比单点检查更有效：把"能发布"和"不能发布"的两篇文章并排对比，差异点立刻显现（date: 2026-07-22 vs date: 2026-06-30）。

后续建议

如果你也是用这套发布脚本，建议：

• 把 displayList = articles.slice(0, 10) 改成更大的值，或加上按 slug 搜索
• frontmatter 里的 date 使用发布日期，原始写作日期可以记在正文里
• 脚本增加日志输出，明确显示"跳过 N 篇旧文章"

关联阅读

• [[OpenClaw 内存膨胀排查与修复：从 70GB 到 780MB]]
• [[子代理无法启动？一次 sessions_spawn 危险工具权限引发的问题排查]]

参考来源

• 发布脚本：/data/oklifeme/publish-technical.mjs
• 会话记录：agent:kb-writer:dashboard:39eb467a-e577-4a29-b9ce-a63db3049355

–全文完–

若你有故事想讲、有困惑想聊、或是想找个人说说心里话，甚至只是吐槽发泄一下情绪，都欢迎来找我聊聊：　　　《内容已折叠，点击展开》

希望我写的每一个字，成为我自己和某个人活下去、拼下去的力量。　　　　　　　　　　　　　　　　　　　　　《内容已折叠，点击展开》

“技术终归是工具，而我们一次次认真把问题理顺，守住的其实不只是页面样式和代码输出，还有那一点不愿被混乱打败的心气，是每一个深夜仍愿点灯前行的人。”

转载请注明来自https://oklife.me。