drawio-desktop：一个刻意断网的绘图客户端，以及它的取舍
Draw.io 的官方电子版本。如果您不更改代码并接受“按原样”提供，则可以将其用于任何目的。
秒懂
- 它是什么？
- drawio-desktop 是 diagrams.net 官方维护的 Electron 桌面版，核心卖点不是功能，而是网络隔离。本文基于仓库文档，拆解它的安装方式、安全模型、开发流程和适用边界。
- 适合谁用？
- 如果你需要一款不依赖浏览器的离线绘图工具，且能接受 Apache-2.0 下「按原样提供」的条款，drawio-desktop 是合理选择。它适合个人用户、内网环境或对数据外发零容忍的组织。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 JavaScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，给谁用
drawio-desktop 解决的问题很具体：把 diagrams.net 的网页编辑器变成一个本地应用。对普通用户，这意味着没有浏览器标签页干扰，文件直接存在磁盘上。对组织用户，这意味着可以部署一个完全不依赖外网的绘图环境。文档开篇就写明，应用「designed to be completely isolated from the Internet」，除了更新检查，没有任何默认的网络连接。这个定位决定了它的目标人群：需要离线绘图的内网员工，对数据外发敏感的单位，以及不想为绘图工具付费的个人。它不是给那些需要多人实时协作或云端存储的人准备的，那些需求应该用网页版或商业产品。
安全模型：CSP 如何把应用锁在本地
这个项目最值得注意的设计是它的内容安全策略。文档明确说，所有 JavaScript 文件都是自包含的，CSP 禁止加载远程脚本，同时限制应用自身的网络连接只能指向自己。这意味着即使某个图表文件被恶意构造，它也无法通过脚本注入来外传数据。但有一个例外需要看清楚：图表可以引用外部媒体，比如嵌入的图片、背景或字体。当打开一个来自不可信来源的图表时，应用会去请求这些 URL，从而暴露你的 IP 地址。文档明确说「no diagram content is transmitted」，但元数据泄露是真实存在的风险。这个设计是刻意的取舍，开发团队在文档里直接表态：任何要求默认启用外部连接的请求都会被拒绝。如果你需要加载外部资源，只能自己改代码，而改代码就脱离了「as-is」的免费使用前提。
Windows 安装的三种形态，以及权限差异
Windows 用户面对三个下载选项，它们之间的区别不是大小，而是权限模型。NSIS 安装器（draw.io-<version>-windows-installer.exe）按机器安装，写入 Program Files，需要管理员权限。MSI 安装器（draw.io-<version>.msi）按用户安装，写入用户配置文件，不需要管理员权限。便携版（draw.io-<version>-windows-no-installer.exe）完全免安装，也不需要管理员权限，但不会注册文件关联。微软商店的 APPX 版本同样支持按用户安装。这个区分对 IT 管理员很重要：如果你管理的机器上用户没有本地管理员权限，MSI 或商店版是唯一可行的部署路径。便携版适合临时使用，但代价是双击 .drawio 文件时系统不会自动用 draw.io 打开。文档没有提到 Linux 和 macOS 的安装细节，但仓库的 releases 页面应该提供对应包。
更新机制与禁用方法
应用启动时会检查 github.com 上的新版本，然后从 GitHub 拥有的 AWS S3 桶下载更新。这是文档里唯一被允许的外部连接。对集中管理的环境，文档给出了两个禁用方式：设置环境变量 DRAWIO_DISABLE_UPDATE=true，或者在启动时加参数 --disable-update。这个设计比大多数 Electron 应用保守，但仍有隐患：如果用户的机器无法访问 github.com，启动时更新检查可能会延迟应用启动，或者产生错误提示。实际行为文档没有描述，但一个依赖外部网络的检查在离线环境里总是需要验证的。另外，更新检查本身会暴露用户的 IP 给 GitHub，这与应用声称的「完全隔离」存在细微出入。文档用「apart from the update process」这句话承认了这一点，所以它不是矛盾，而是设计上的明确边界。
从源码运行与开发流程
drawio-desktop 把核心编辑器 drawio 作为 git 子模块。要获取完整源码，必须用 git clone --recursive https://github.com/jgraph/drawio-desktop.git。之后在仓库根目录执行 npm install，再运行 npm start 即可启动应用。调试模式用 npm start --enable-logging。文档特别提醒，如果用符号链接代替子模块指向 drawio 仓库，需要同时把 node_modules 链接到 drawio/src/main/webapp 目录下。这个细节说明项目依赖关系比较脆弱，不是简单的 npm 依赖。开发者还需要注意，构建发布流程涉及 Travis CI 和 AppVeyor，Windows 可执行文件要用 signtool 签名，命令是 signtool sign /a /tr http://rfc3161timestamp.globalsign.com/advanced /td SHA256 c:/path/to/your/file.exe。整个流程对个人开发者来说不算友好，但文档提供了 doc/BUILDING_FOR_PERSONAL_USE.md 指导如何构建未签名的个人版本。
一个重要的限制：不接受外部贡献
这个仓库明确标注为「Not open-contribution」。文档解释，项目复杂度高，简单改动可能破坏大量相关功能，测试成本远超表面。如果收到 PR，维护者基本上会丢弃重写。这意味着你无法通过提交代码来修复 bug 或添加功能，只能提交 issue 和 feature request。对采用者来说，这个策略有实际影响：如果你依赖某个特定功能，而它不存在，你不能指望社区补丁，只能自己 fork 并维护。但 fork 之后你就脱离了官方更新流，每次上游版本更新都需要手动合并。文档提到支持「reasonable business constraints basis」，但没有合同约束，也不提供非付费用户的私有工单。购买 draw.io for Confluence 或 Jira 并不附带桌面版商业支持。所以，如果你需要 SLA 级别的支持，这个项目不适合。
替代方案与本质区别
最直接的替代是 diagrams.net 网页版。两者共享同一套核心编辑器，但桌面版的价值在于网络隔离和本地文件访问。网页版天然需要浏览器网络连接，无法满足内网隔离需求。另一个替代是开源的 draw.io 核心仓库（jgraph/drawio），你可以自己构建 web 应用并部署到内网服务器，这样既能控制更新，又能保留浏览器界面。区别在于，drawio-desktop 是一个 Electron 壳，它把 web 内容包在本地进程中，而自部署方案需要你自己管理服务器、认证和 HTTPS。还有一个方向是使用其他桌面绘图工具，比如 LibreOffice Draw 或 diagrams.net 的竞争对手如 Excalidraw，但它们的文件格式和功能集不同，迁移成本高。选择的关键不是功能对比，而是你能否接受 Electron 的资源占用和更新机制。
维护与升级的现实成本
从仓库的提交记录看，项目保持活跃，最近一次推送在 2026 年 8 月，版本号到 v31.3.2。升级成本主要体现在两个方面。第一，由于核心编辑器是子模块，升级意味着要同步更新 drawio 子模块，然后重新构建和签名。对于使用预编译二进制的用户，升级只是下载新安装包，但需要重新验证安全策略是否变化。第二，文档没有提供 LTS 或长期支持版本，所以每个新版本都可能引入行为变化。对于内网部署，建议在测试环境验证新版本后再推广。许可证是 Apache-2.0，允许商用和修改，但文档强调「as-is」条款，意味着没有担保。如果你修改了代码，就不再符合免费使用的前提，但许可证本身不禁止。具体法律解释需要咨询专业人士，这里只陈述文档内容。
编辑结论
如果你需要一款不依赖浏览器的离线绘图工具，且能接受 Apache-2.0 下「按原样提供」的条款，drawio-desktop 是合理选择。它适合个人用户、内网环境或对数据外发零容忍的组织。不适合需要深度定制或希望参与代码演进的人，因为仓库明确关闭了外部贡献。采用前先验证两件事：第一，确认你的网络策略允许启动时对 github.com 的更新检查，或提前设置 DRAWIO_DISABLE_UPDATE=true；第二，检查你的团队是否依赖微软商店或 MSI 的免管理员安装，否则 NSIS 安装包会要求提升权限。最后，任何来自不可信来源的 .drawio 文件都可能触发外部资源请求，这一点在安全要求高的环境里必须先做制度约束。
社区笔记