维护基于Mkdocs的Read-the-Docs项目是否必须安装Mkdocs？

你的理解基本准确，没有本质偏差。
日常更新文档内容的场景下，所有协作者确实只需要往关联的GitHub仓库里提交符合规范的Markdown文件、图片等资源，Read the Docs（以下简称RTD）会自动完成后续的构建、发布流程，不需要所有人都本地安装MkDocs才能参与贡献。

这也是最实用的价值：RTD的自动构建是在内容提交到GitHub之后才会触发，如果改完内容直接推送，一旦出现图片路径写错、Markdown格式异常、导航排序错乱的问题，线上已经发布的文档就会直接出问题。
本地运行mkdocs serve命令可以启动实时预览的本地服务，改完内容立刻就能看到最终渲染效果，能把绝大多数格式问题拦在提交之前，尤其是调整导航结构、插入大量图片、编写复杂格式内容的时候，本地预览能省掉很多「提交-等构建-发现错了-再改-再提交」的无效循环。

• RTD本身没有独立的文档渲染引擎，它的自动构建本质是在自己的服务器上自动安装MkDocs，按照你仓库里的mkdocs.yml配置文件规则完成构建。这个配置文件的语法、支持的功能全是MkDocs定义的，不管是换主题、调整侧边栏导航顺序、开启全局搜索、配置文档多版本，本质上都是按照MkDocs的规则修改这个配置文件，只是改完推到仓库后RTD会自动按新规则重新构建而已。
• 如果后续你需要给文档加自定义功能，比如加全局提示框、内容标签、特殊的排版组件，基本都是通过安装MkDocs第三方插件实现的。这时候需要本地装MkDocs先测试插件兼容性、调试配置效果，确认没问题再把配置推到仓库，不然很容易出现配置不兼容导致RTD构建直接失败的情况。
• 如果碰到RTD构建失败的异常情况，本地安装了MkDocs的话，可以直接拉取最新仓库代码在本地跑构建排查问题，比在RTD后台逐行刷构建日志效率高很多。

如果你们的文档站点已经完全定型，后续不会再调整主题、增加插件、修改全局配置，只是日常更新正文内容、替换图片素材，那哪怕协作者不装MkDocs，直接在GitHub网页端编辑提交Markdown也完全可行，RTD会正常生成可访问的文档。只有需要调整全局配置、调试自定义功能、提前校验复杂排版效果的时候，才需要用到本地安装的MkDocs。

内容的提问来源于stack exchange，提问作者user1682654