LibreOffice/core 是什么？

LibreOffice/core 是 LibreOffice 办公套件的核心仓库，面向想要修改 Writer、Calc 或 Draw 的 C++ 开发者。本文基于 README 和仓库结构，分析其模块划分、构建门槛与贡献方式，并指出它不适合哪类人。

LibreOffice/core 可以商用吗？

可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。

LibreOffice/core 还在维护吗？

在维护。仓库在最近一天内有新的提交。

LibreOffice/core 是用什么编程语言写的？

主要是 C++（依据 GitHub 的语言统计）。

LibreOffice/core 代码库解析：模块结构、构建要求与开发入门

Q: LibreOffice/core 还在维护吗？

在维护。仓库在最近一天内有新的提交。

秒懂

它是什么？: LibreOffice/core 是 LibreOffice 办公套件的核心仓库，面向想要修改 Writer、Calc 或 Draw 的 C++ 开发者。本文基于 README 和仓库结构，分析其模块划分、构建门槛与贡献方式，并指出它不适合哪类人。
适合谁用？: LibreOffice/core 适合有扎实 C++ 功底、愿意啃大型代码库的开发者，尤其是想给 Writer、Calc 或 Draw 添加通用功能的场景。不适合只想写个简单宏或小扩展的人，那种需求应走 SDK 和 UNO API。
能商用吗？: 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
还在维护吗？: 在维护。仓库在最近一天内有新的提交。
用什么语言写的？: 主要是 C++（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月8日 · LibreOffice/core

这个仓库解决什么问题，给谁用

LibreOffice/core 是 LibreOffice 办公套件的完整源代码仓库，覆盖 Writer、Calc、Draw、Impress 等应用。它解决的第一个问题是：如何让一个庞大、跨平台、有二十年历史的 C++ 项目保持可维护性。README 明确区分了两种开发方式：一种是使用 SDK 写扩展，另一种是直接改代码库。后者被描述为“最好的方式”，理由是避免脚本 API 的任意限制，对“相当有能力的 C++ 程序员”来说更简单直观。这个仓库的目标读者就是这类人，不是普通用户，也不是只会写 StarBasic 宏的人。它提供的是底层控制力，代价是必须面对极高的构建复杂度和学习曲线。

代码结构：两百个模块，重点在哪儿

README 承认有两百个模块，很多只有外围兴趣，所以给出了一个“重要代码”清单。核心分层很清楚：sal 是系统抽象层，tools 提供 Rectangle、Color 等基础类型，vcl 是控件库和渲染抽象，framework 用 VCL 和 XML 描述构建工具栏和菜单，sfx2 是 Writer、Calc、Draw 的旧核心框架，负责文档模型和读写。应用层则集中在 desktop（main 函数入口）、sw（Writer）、sc（Calc）、sd（Draw/Impress）。图形相关的 basegfx、canvas、cppcanvas、drawinglayer 也被单列出来。这个结构意味着，如果你想改 Calc 的公式引擎，应该去 sc；想动 UI 布局，则要接触 framework 和 uiconfig。没有这个地图，新手很容易在两百个模块里迷路。

构建门槛：编译器、系统与 Java 的硬性要求

README 列出了明确的构建和运行基线，这不是建议而是硬条件。Linux 运行时要求 RHEL 9 或 CentOS 9，构建需要 GCC 13 或 Clang 18；Windows 运行时是 Windows 10，构建用 Visual Studio 2022；macOS 运行时 11，构建用 Xcode 14.3 以上。Java 是构建许多部分所必需的，基线是 JDK 17。Python 基线是 3.11，跟随 SUSE 和 RHEL 的版本。特别的是，如果要在 macOS 上用 Clang 编译器插件，必须自己编译 Clang，因为 Xcode 不提供插件头文件。这些条件意味着，在一台过时的 Linux 机器或旧 Mac 上，你连编译都过不去。对于只想试水的开发者，这本身就是第一道坎。

获取与构建：LODE 脚本和 distro-configs 的用法

README 没有给出完整的编译命令，但指明了路径。Windows 和 macOS 上，官方提供 LODE（LibreOffice Development Environment）脚本来初始化构建环境。Linux 用户则可以在 distro-configs/ 目录找到 TDF 使用的 configure 开关。具体构建步骤要参考 TDF wiki 的 How_to_build 页面。仓库本身是只读的，不接受 pull request，必须使用 Gerrit 提交补丁，而且 README 特别提醒不要下载 zip 压缩包。这意味着你的工作流是：克隆仓库、配置环境、构建、修改、用 Gerrit 提交。没有现成的“一键构建”命令，所有细节都散落在 wiki 和模块内的 README 文件里。

代码规范：include 指令的硬性规则

README 用一整节强调 C/C++ 的 include 规则：只有被包含文件紧邻当前文件时，才用双引号形式，否则一律用尖括号。UNO API 包含文件则例外，始终用双引号，以方便外部使用者。这个规则由 loplugin:includeform（位于 compilerplugins/clang/includeform.cxx）强制检查。也就是说，你的补丁如果违反了这个约定，静态检查就会直接拒绝。这看起来是个小细节，但对一个两百模块的项目来说，统一的 include 形式能显著减少构建系统的歧义。对于新贡献者，这可能是最早遇到的、也是最容易忽略的坑。

静态分析：PVS-Studio 的参与

README 在末尾列出了 SAST 工具，包括 PVS-Studio，一个针对 C、C++、C# 和 Java 的静态分析器。它被用于扫描代码库，但 README 没有说明具体的使用流程或集成方式。这更像是一个事实声明：项目使用了商业静态分析工具，但贡献者是否需要在本地运行它，文档没有提及。从仓库布局看，compilerplugins/ 目录下还有 Clang 插件，比如 includeform，这些是 LibreOffice 自研的检查工具。两套工具并存，说明项目对代码质量有双重把控，但这也增加了构建的复杂度，因为 Clang 插件要求特定版本的 Clang。

替代方案：SDK 扩展开发与 UNO API

README 明确给出了另一条路：使用 SDK 开发扩展，基于 UNO API 和 StarBasic 宏脚本。这条路被描述为“不那么推荐”，但它的门槛低得多，不需要编译整个代码库，也不受编译器基线限制。UNO 是极其通用的接口，扩展可以通过 API 文档和开发者指南学习。区别在于：直接改代码库能获得完全的控制权，但需要面对 C++ 编译和构建的复杂性；用 SDK 则受限于脚本 API 的抽象层，很多底层功能可能无法触达。对于只想给 Writer 加一个小按钮的人，SDK 是更务实的选择。但对于想要改变文档模型或渲染管线的开发者，SDK 根本做不到，只能走 core 仓库。

维护成本与许可证：GPL-3.0 的双重含义

LibreOffice/core 采用 GPL-3.0 许可证，这意味着你的修改如果分发出去，必须开源并保持相同许可证。这不是法律建议，但 README 明确说它是基于 copyleft 许可证的。对于企业或闭源项目，这是个硬约束。维护成本方面，构建基线更新频繁，比如 Linux 要求 GCC 13，这比许多发行版默认版本要新。Java 17 和 Python 3.11 的基线也意味着你的开发环境必须跟上。另外，由于不接受 pull request，你必须熟悉 Gerrit 的提交流程，这本身有学习成本。模块内的 README 文档是分散的，质量不一，你可能要花时间在 docs.libreoffice.org 上寻找信息。

编辑结论

LibreOffice/core 适合有扎实 C++ 功底、愿意啃大型代码库的开发者，尤其是想给 Writer、Calc 或 Draw 添加通用功能的场景。不适合只想写个简单宏或小扩展的人，那种需求应走 SDK 和 UNO API。在提交补丁前，先确认你的编译环境满足 README 列出的基线：Linux 上 GCC 13 或 Clang 18，Windows 上 Visual Studio 2022，macOS 上 Xcode 14.3 以上。还要遵守 include 规则，否则 loplugin:includeform 会拒绝你的代码。这个仓库的复杂度是真实的，但文档和社区（邮件列表、IRC）给出了明确的入口。如果你能接受从构建到提交的漫长周期，它仍是最直接的贡献路径。

官方来源

社区笔记