非常感谢！是的，我会这么做的！我特别想找的是页面浏览量（登录用户、匿名用户、爬虫），但在 API 文档中找不到。有什么提示吗？
有些管理员特定的调用不在 API 文档中
我会打开网络选项卡，转到管理员页面，查看包含您想要检索数据的那份报告，然后检查网络选项卡以查看浏览器加载了什么。
这实际上是 Reverse engineer the Discourse API 的摘要
我会使用数据探索器插件来获取你想要的所有内容，然后你可以通过 API 将其拉取下来。使用 Discourse API 运行数据探索器查询
当然；如果您想要与管理面板中已提供的不同数据，那么使用 DE 是可行的方法。
它还保证这些查询在更新后不会返回不同的数据，但底层结构也可能会发生变化，您可能需要维护查询。
无论哪种方式都有取舍。
感谢你们两位！我用“逆向工程”方法加上 API 密钥成功了！非常感谢！
这个话题稍微有点晚了（好吧，是它的延伸部分 :p），但我也曾想从 Discourse 论坛抓取数据，又不想折腾设置 API 密钥。如果你（或任何人）想要一个简单的封装工具来从任意 Discourse 论坛抓取帖子，可以看看这个 链接。
已发布到 PyPi，使用 pip/uv 安装非常方便，自动处理速率限制，并用 Pydantic 进行了类型注解（我认为这能带来更好的开发体验）。用法如下：
from discourse_reader import DiscourseClient
client = DiscourseClient("https://meta.discourse.org")
# 浏览分类
for cat in client.categories():
print(f"{cat.name}: {cat.topic_count} 个主题")
# 获取某个主题及其所有帖子
topic = client.topics.get(12345)
print(topic.title)
print(topic.opening_post.cooked) # 原始帖子（HTML）
print(topic.accepted_answer) # 已采纳的回答或 None
for reply in topic.posts.replies():
print(reply.username, reply.cooked)
它不如 pydiscourse 功能全面，但这是有意为之，因为它无需 API 密钥即可运行。当然，它也不会比数据探索器插件提供更优或更快的数据，但如果你只是想快速抓取一批帖子或简单的站点统计信息，我觉得它还是很不错的 
我有一种感觉，这种做法可能违反了本论坛的服务条款以及 Discourse 论坛的默认服务条款。
您不得自动化访问论坛或监控论坛，例如使用网络爬虫、浏览器插件或附加组件，或其他非网络浏览器的计算机程序。如果您运营的是公开可用的搜索引擎，则可以爬取论坛以对其进行索引。
嗯，我想我并没有做什么特别的事情，无非是将原本需要通过 curl 请求访问的公开 API 端点进行封装。不过，如果 @Discourse 团队对我的创作有任何不满，请随时告知。
就我个人而言，我认为该包本身并未违反任何服务条款（ToS），因为遵守论坛条款的责任始终在于使用该工具的开发者。该包仅访问公开且文档化的 API 端点；如果开发者怀有恶意意图去抓取或监控论坛，这实际上本来就是一个轻而易举的任务。
顺便提一下，pydiscourse 提供了相同的功能，唯一的区别是需要 API 密钥（我不确定作为普通用户获取密钥是否容易）。一旦获得密钥，它同样可能被用来违反任何论坛的服务条款。因此，如果默认规则是不允许自动化访问论坛，那么 pydiscourse 和 discourse2 是否也不应被视为违反服务条款？discourse2 甚至在其功能列表中宣传：若未提供 API 密钥，仍可访问公开数据：
同时适用于服务器和浏览器*环境（*适用于在相关源上查询公开数据而无需 API 密钥，例如获取最新主题等）
其他语言中可能还有更多支持此类访问的包。
补充一些背景信息：我开发这个工具是为了方便从我们的一位客户托管的论坛中提取数据（但我们没有直接的数据库访问权限）。它让我的工作流程更加简洁，我也希望能为处于同样境地的其他人提供帮助。
关键在于，生成 API 密钥首先需要访问管理界面（管理 > 高级 > API 密钥），因此提供 API 密钥是管理员希望主动进行的操作；任何普通用户都无法自行获取。
是的，如果获取 API 密钥的唯一途径是通过管理界面，那么这个包可能会简化违反特定论坛服务条款（ToS）的行为。
不过，我仍希望讨论我之前提到的其他几点，并听听大家对这些观点的看法，即：任何人都已经可以轻松地使用 curl 或 requests 进行爬取或监控。责任是否应该由开发者承担，即他们不应违反服务条款？还是说责任应归于他们所使用的工具本身？
对于 discourse2 及类似的包，它们用途更广泛，但 discourse2 仍然宣传在没有提供 API 密钥的情况下也能操作公共端点。这是否在同等程度上助长了违反服务条款的行为？
此外，由于 Discourse 采用 GPLv2 许可证，创建像 discourse-reader 这样的工具是否本身就直接违反了任何条款？
很想知道大家对这些问题的看法。
官方 discourse_api Ruby gem 也支持在不使用 API 密钥的情况下访问公开数据。因此，我认为该工具的存在是合理的。用户有责任确保其操作符合特定论坛的服务条款（ToS）。
（这是我的个人观点，并非 CDCK 的官方法律声明 
）
此外值得一提的是，未经验证的“机器人”请求会受到更严格的速率限制，并可能面临其他“机器人防护”安全层（例如 Cloudflare）的拦截。因此，如果条件允许，始终建议使用 API 密钥。
感谢您的回复！目前，我已在我的包的 README 中更新了一条免责声明，提醒开发者在使用该包时务必遵守目标网站的服务条款（ToS）。
在开发此包时，我完全不知道这一默认的服务条款规定。希望未来任何打算使用该包的人也能了解到这一点
是的，这完全呼应了之前关于录像机（VCR）的论点……同样，开锁工具也是如此。工具既有合法用途也有非法用途，关键在于操作者是否负责任。
再次声明，我不是律师，这也不是官方声明，但我认为这准确反映了我们对此的看法：
使用工具进行善意的探索（例如 此处）与设置自动化之间存在巨大差异。
我们不会因为人们使用此类工具访问 meta 而生气，尤其是当他们正在开发功能或学习如何与 Discourse API 交互时。我们会鼓励这种行为，前提是您不进行批量抓取数据、不会造成不必要的负载，也不会影响他人的体验。