docusaurus文档数量达到3000篇以上时，构建会非常吃力

让我搜索一下确认这个说法的具体出处。我需要纠正一下之前的说法——这句”官方文档承认几千篇是’能用但吃力’区间”是我表述不准确,并没有这样一个官方页面直接这么说。抱歉误导了。

实际情况是这样的

Docusaurus 官方 GitHub Discussions(算是核心维护者/官方团队的半官方回应,不是正式文档页面),具体来源:

真正的”官方”来源(维护者回应)

1. Discussion #10159 “3000 documents too much for Docusaurus?” 核心维护者 slorber 回复

   ,这高度取决于页面内容、机器的内存/CPU,以及你如何定义”太长”。他建议做一个包含 3000 篇代表性内容的概念验证(POC)构建,看看是否可接受。

2. Discussion #10895 “Problems when building very large website with Docusaurus” 这里维护者的回应更直接

   Docusaurus,虽然有一些因为从代码生成大量 API 参考文档而变得很大的社区网站。他举例说 xsoar.pan.dev 的 sitemap 显示有 4000 个页面。他说无法确定 Docusaurus 是否能支撑 1.2 万或 7 万页面,如果构建这类网站,可能静态站点生成器并不是理想选择,因为构建时间长,而且当你只是想修正一个文档的错字时,重新部署效率很低。有用户反馈,用 1.68 万篇文档时用 npm run build 会遇到问题,改用 WSL 才解决,但会消耗大量内存且耗时超过一小时。

3. Discussion #11171 “best practices for managing large documentation websites” 核心维护者原话

   终究是一个静态站点生成器(SSG),所以随着文档数量增加构建时间也会增加;团队一直在努力改善构建时间,但没法完全消除这个问题。

真实案例数据(供参考)

• Discussion #11140

  1.1 万个 Markdown 文件,在 16 核 64GB 内存的 Linux 机器上,构建耗时 约一小时十五分钟。

• Discussion #3132(较早案例)

  720 个 mdx 文件(两个版本各 360 篇),就需要 16GB 内存参数才能构建完成,耗时约 26 分钟,内存峰值一度超过 10GB。

所以准确的说法应该是:Docusaurus 官方并没有一份文档明确写”几千篇是吃力区间”,但维护者在多个 GitHub Discussion 里反复承认构建时间会随文档量增长、且没有明确上限估算,并建议大规模场景考虑拆分站点或做 POC 测试。这是来自真实维护者互动,比正式文档更可信,但严格说不算”官方文档声明”。

抱歉刚才的措辞给你的印象是有具体文档页面,实际是我记忆模糊导致的不准确表述。