分离部署项目优劣分析

目前有四个主要的可用项目可以实现 OneBot 协议的 QQ 机器人 API，它们分别是 Lagrange（lgr/拉格兰）、Napcat（nc）、LiteloaderOneBot（LLOB） 和 Shamrock（四叶草）。这些项目各有优劣，没有绝对的优劣之分。归根结底，只要能满足你的需求和预期，那就是合适的选择，同理对其他人也是这样，你可以推荐，但不应该存在什么“鄙视链”。接下来，我将尽量客观地分析它们的优缺点和可能存在的问题，供你参考。

---

运行原理概述

当前 QQ 的非官方机器人实现，主要分为两种运行途径：协议端 和 Hook。

---

项目分析

• Lagrange：

Sealdice 选定 Lagrange 作为内置客户端上游，还受到绝大多数视频和博客站等的推荐，作为一个协议端，Lagrange 的兼容性和性能无疑是极好的。它能在各种设备环境下运行，甚至连路由器上都可以（没错我真这么干过）。
理论上，它的低资源占用使其能够处理更多的大型机器人账号，是资源有限的最佳选择，大型机器人的唯一选择。

然而，Lagrange 的核心问题在于签名服务。由于各种因素，Lagrange 需要通过签名才能使用，签名服务并非开源，Lagrange 官方只提供了一个公共签名服务，且主机位于海外，并使用 Cloudflare 保护的服务器提供。对网络极为玄学的中国大陆用户来说，Cloudflare 的访问体验简直是抽抽又象象。如果你部署在国外，体验会更好些。

如果你的主机在国内，可以尝试雪桃的反代签名。你可以直接使用 雪桃 の Lagrange 一键包生成器 生成使用了雪桃反代签名的 Lagrange 一键包。

此外，由于它是“假的 QQ 客户端”，相较于在 Linux 系统部署的 Hook 式协议端，更容易被腾讯察觉。拦截消息，踢下线甚至封号的概率理论上会更高。另外，Lagrange的协议版本更新横向对比 LiteloaderOneBot 和 Napcat 是偏慢的，有些天选之人 QQ 账号可能被腾讯强制要求使用最新的 NTQQ 版本登入，这种情况下 Lagrange 将不再是一个选项。

Lagrange 官方是有一个 fork 的 GOCQ 的。需要注意的是，本质上这玩意就是一个低占用版的 Lagrange，和各位熟知的并非是一个 GOCQ 哦~

---

• Napcat:

Napcat 属于 Hook 式项目，是我个人非常喜欢并且强烈推荐的一种分离部署方案。它拥有漂亮的 WebUI，配置操作非常直观简便。在 Linux 环境下，Napcat 还提供了一个 CLI 工具（napcat cli），便于进行命令行操作和一键脚本的编写与执行。
日志读取优雅，直接在 WebUI 中即可查看。更重要的是，它支持“无头运行”——无需渲染 NTQQ 页面，从而大幅降低资源占用。

并且，Napcat 最大的优势在于其反检测能力：在 NTQQ 高版本中，它可以成功拦截检测包，并绕过部分检测点，有很不错的稳定性。

• 但也有限制：由于 Hook 的运行机制，本质上仍然是启动了一个修改后的 NTQQ，即使无头运行也会有不小的资源开销。因此 Napcat 并不适合承担大体量机器人账号的任务。

除此之外，Napcat 几乎都是优点。

如果你打算部署 Napcat，我推荐使用 Linux 环境部署，因为在 Linux 上运行的 NTQQ 几乎没有检测机制，Linux 上的 Napcat 几乎是最稳的选择之一。

如果你仍希望在 Windows 环境部署，以下是一些建议：

• 进阶用户：推荐使用 Docker 部署 Napcat。Napcat 官方 Docker 镜像
• 新手用户：可以尝试安装 NTQQ 的 27597 版本并登入账号。若可成功登入，可继续使用该版本搭配 Napcat Framework 安装方式（该方式没有反检测，但此版本是最后一个未强制检测的 NTQQ 版本）。历史版本 NTQQ 存档
• 如果账号无法登入 27597 版本，可退而求其次使用 Napcat 的一键包（在 Napcat GitHub Release 获取）。一键包已集成反检测机制，能拦截大部分检测，但仍建议避免用于新注册账号或风险偏高的账号，以防被封。
  ⚠️ 请不要在 27597 之后的版本使用 Framework 安装方式，检测包拦截将无法完全生效。

---

• LiteloaderOneBot：

LiteloaderOneBot 和 Napcat 的实现原理基本类似，都是通过 Hook NTQQ 并以插件方式加载，实现 OneBot 协议的对接。但客观来说，我并不推荐这个项目，主要原因如下：

1. 日志查看极其不便。如果你在运行中遇到协议端问题，必须自己手动进入文件夹层层翻找日志文件，调试体验极差；如果你想在群里反馈问题，还得先经历一轮“翻山越岭”式的日志提取流程。
2. 它存在一些玄学问题。例如前端显示已连接，后端 LiteloaderOneBot 实际却没有任何数据传输。我自己就多次遇到过这种情况，在群里也看到很多类似报告。此类问题通常只能通过重启 NTQQ 甚至重启整台主机来解决，有时还需要多次重启才能恢复正常运行。

虽然从功能上来说，它和 Napcat 基本相当，但 Napcat 支持无头与有头双模式运行，而 LiteloaderOneBot 只能运行在有头模式下，这意味着它的资源占用会更高。

总而言之：Napcat 目前已经集成了较为完善的反检测手段，而 LiteloaderOneBot 仍未解决这些基础性问题。在高版本 NTQQ 上使用 LLOB 存在不小的封号风险。低版本可用且使用体验比 Napcat 好一些，因此，我仅推荐在 Windows 端 在低版本NTQQ 上使用这个项目，其他情况下则不建议使用，因为相比之下，Napcat 在体验与稳定性方面都更胜一筹。

---

• Shamrock：

Shamrock 是我另一个非常喜欢的项目，虽然它已经归档不再维护。它也是 Hook 式的实现，但不同于 Napcat 和 LiteloaderOneBot，它修补的是安卓端 QQ 客户端。

由于它使用安卓端 QQ，于是就可以在这个模块以外使用其他模块，通过搭配 QAuxiliary 模块，使用它的 禁用热补丁 和 环境检测 功能，从而实现高稳定性运行。这一套操作下来，Shamrock 的稳定性表现的上限会比使用 NTQQ 的 Hook 项目更好。

• 缺点也很明显：
• 操作复杂：需要 Android 设备，并进行 Root 或使用 LSPatch，安装模块，还要配置保活，会很麻烦，也稍微需要写技术。
• 已归档：不再开发维护，随着时间推移会逐渐不可用，并且 Github 上 Action 内容已经全部过期无法下载。不过，我有对它最后一次 Action 进行存档，感兴趣的话可以在我的杂货铺找到。

---

总结

根据当前的项目现状和实际需求，我的建议是:

希望这篇总结能帮你找到最适合的部署方式，让你的 QQ 机器人稳如老狗！
最后，祝你家 bot 成为耐活王，随一首 See You Again 加速版冲出火葬场！（x）

本文更新时间为 2025 年 4 月 23 日，未来可能会因项目更新或环境变化与我的描述有所出入，但对于协议端和Hook的区别，大体逻辑不会变。希望能帮到你！