QClaw实战：用它我踩过的那些坑

写在前面的话：这篇不是教程，是我真实踩坑的记录。如果你也在用QClaw（或者打算用），希望能帮你少走点弯路。

坑一：网站突然显示PHP源码，我以为是服务器崩了

某天早上起来，正常访问我的网站 yhyylm.cn，结果页面上直接显示了大段PHP代码——就是那种的源码，而不是正常的网页。

我当时脑子一片空白：“我服务器被黑了？数据库没了？”

折腾了半小时，最后发现原因特别蠢：

我在改 WordPress 主题文件 header.php 的时候，想把百度统计代码贴进去。结果贴错位置了——把统计代码贴在了一个 PHP 代码块里面，而且没有正确闭合 ?> 就和 HTML 混在一起了。

PHP 解释器遇到这行”半截代码”，直接罢工了，把后面的内容当纯文本输出……

修复方法： 通过 SSH 连上服务器，用 echo -e 重写了一遍 header.php，文件从 3KB 变成 358 字节，网站瞬间恢复正常。

教训： 改主题文件一定要备份！最好在本地先测试，或者用子主题（Child Theme），别直接在线上改。

坑二：批量发布文章，一口气发了31篇”未分类”

这个坑更离谱。

我当时想批量发布一批文章，写了一个 Node.js 脚本，通过 WordPress 的 XML-RPC 接口发布。

第一版脚本（publish_daily.js）写完，测试的时候发现：所有文章都发成功了，但分类全是”未分类”。

排查了半天，发现是 terms_names 这个参数的问题。WordPress XML-RPC 对分类的处理有点迷，用分类名称（terms_names）经常不生效，必须传分类ID（terms）。

改完重新发，结果因为脚本里没做去重，31篇文章重复发了两次，而且还是”未分类”……

最后只能手动去 WordPress 后台一篇一篇删，删到手酸。

正确的做法： 用 terms 传分类ID数组，比如 terms: { category: [5, 42] }，并且在发布前先检查文章标题是否已存在。

坑三：测试脚本，不小心”炸”了100篇文章

这个是我踩过的最大的坑，现在想起来都后怕。

我当时在写一个 Python 版的自动发布脚本（publish_daily_v3.py），想测试一下”发布单篇文章”的功能。

Python 有个坑：如果你用 exec(open('script.py').read()) 来执行脚本，脚本里即使写了 if __name__ == '__main__':，这段代码也会执行。

结果就是：我的测试命令，意外触发了完整的”批量发布100篇文章”的逻辑……

一瞬间，网站多了100篇内容是乱码、分类错误、标题重复的文章。

抢救过程：
1. 立刻登录 WordPress 后台
2. 用批量删除功能，按文章ID范围删除
3. 写了个清理脚本（cleanup_100articles.py），专门用来删除指定ID范围内的文章
4. 花了1小时，把垃圾文章全部清理干净

教训：
– 测试脚本绝对不要用 exec() 或 python -c "exec(...)" 这种方式
– 测试时应该用一个单独的 test() 函数，只在明确调用时才执行
– 或者更简单的：测试前先把发布功能注释掉 😅

坑四：PowerShell 里跑 Node.js，特殊字符全乱了

我是 Windows 用户，经常用 PowerShell 跑 Node.js 脚本。

某次我想快速测试一段 Node.js 代码，用了 node -e "..." 这种方式（直接在命令行里执行 JS 代码）。

结果因为代码里有引号、&&、<、> 这些特殊字符，PowerShell 把它们解释成了自己的命令，导致 Node.js 收到的代码是乱的，直接报语法错误。

解决方法： 别偷懒，把代码存成 .js 文件，然后用 node script.js 执行。虽然多一步，但不会踩字符转义的坑。

坑五：文章发布了，但前台显示404

有一次我通过 XML-RPC 发布了一篇文章，接口返回”发布成功”，文章ID也有。

但打开网站首页，点文章链接，却是 404 Not Found。

排查过程：
1. 检查文章状态：是 publish（已发布），不是草稿
2. 检查分类：分类存在，文章也关联了
3. 手动在 WordPress 后台编辑那篇文章，点”更新”，结果前台就能访问了

原因： WordPress 的伪静态规则（Permalink）有时候会”卡住”，新发布的文章没有被正确写入重写规则缓存。

解决方法： 在 WordPress 后台，进入”设置 → 固定链接”，什么都不改，直接点”保存”——这会刷新重写规则，404 问题就消失了。

总结：踩坑是常态，重要的是别放弃

我用 QClaw 这几个月，踩的坑远不止上面这5个。

有次因为定时任务配置错误，网站每分钟自动发布一篇文章，半夜发了500多篇；还有次因为 Cookie 过期，自动化脚本全部失效，排查了两天才发现是登录态丢了……

但说实话，踩坑的过程也是学习的过程。

每次解决一个问题，我对 WordPress、对自动化、对服务器运维的理解就深一分。现在再遇到类似问题，基本半小时就能搞定，而刚开始可能需要一整天。

如果你也在用 QClaw，或者打算用自动化工具来运营网站，我的建议是：

1. 从小规模开始：别一上来就批量发布100篇，先发1篇，确认整个流程没问题，再扩大规模
2. 做好备份：数据库备份、网站文件备份，最好每天自动备份
3. 日志记录：每次执行自动化任务，把结果写到日志文件里，出问题了方便排查
4. 别怕踩坑：踩坑不可怕，可怕的是踩了同一个坑两次（我现在有个 memory/2026-05-10.md 文件，专门记录踩过的坑，避免重复）

*我是老Q，一个用自动化工具折腾网站的普通博主。这篇是我真实经历的记录，没有教程，只有踩坑。如果你也有类似经历，欢迎评论区交流～*

*顺便提一句：我现在的网站 yhyylm.cn 就是用 QClaw + 腾讯云服务器搭建的，如果你也想试试，可以用我的推广链接买服务器：https://curl.qcloud.com/7Znu7m7b （有返利，对我是个支持，对你也有优惠）*

QClaw实战：用它我踩过的那些坑