Penpot 2.0 开源设计工具深度解析：原则、架构与实践

本文覆盖范围

1. Penpot 的设计理念——为何选择「设计即代码」路线
2. Penpot 的技术栈选择与整体架构
3. Penpot 2.0 版本的关键新特性（CSS Grid Layout、组件系统、设计令牌）
4. 如何快速上手与自托管部署
5. 如何参与 Penpot 的插件开发与源码贡献

一、为什么需要 Penpot

设计工具的历史遗留问题

在 Penpot 诞生之前，设计工具市场被几家闭源产品牢牢把控。这些工具虽然功能强大，但存在几个根本性矛盾：

设计资产与代码割裂。设计师在专属格式中创作，开发者再从设计稿中手工提取样式信息。标注、交接、版本同步——这些本不该存在的行政成本消耗了大量团队时间。

锁定效应（Vendor Lock-in）。当你的所有设计稿都依赖某个厂商的文件格式，一旦该厂商调整定价策略或改变产品方向，迁移成本极高。

协作壁垒。闭源设计工具需要团队成员各自购买许可证才能参与协作，中小团队和开源社区的进入门槛因此长期偏高。

Penpot 的解题思路

Penpot 的主张是：设计即代码（Design as Code）。

设计即代码不只是口号，它直接体现在 Penpot 的每一个设计决策中：

• 设计稿以开放标准格式存储（SVG 为底层渲染格式，CSS/HTML/JSON 为导出格式）
• 设计师和开发者基于同一份设计资产工作，不再有「交接」动作
• 代码即设计——开发者可以直接复用 Penpot 导出的 CSS，设计师可以直接引用代码中的颜色变量
• 完全免费且开源，任何人都可以自建实例

这种思路解决了三个问题：格式锁定、协作壁垒、成本门槛。

💡 类比理解：Penpot 更像是一个「设计领域的 Git」——分布式的（可自托管）、开放的可协作的、版本可控的。

二、技术栈与架构设计

语言选择：Clojure

Penpot 选择 Clojure 作为主力开发语言，这是一个在设计工具领域相当罕见的选择。主流设计工具（如 Figma、Sketch）几乎无一例外地采用 TypeScript/JavaScript 或 C++。理解 Penpot 为何走这条路线，有助于理解它的技术性格。

Clojure 的优势：

当然，Clojure 也有代价：学习曲线陡峭（括号多、思维模式不同于主流语言）、社区小、人才难找。Penpot 团队显然认为这些 Trade-off 对于他们要解决的问题是可以接受的。

整体架构概览

Penpot 采用典型的 前后端分离架构，但细节上有很多设计工具特有的考量：

┌─────────────────────────────────────────┐
│              客户端（Browser）            │
│  ClojureScript → React（渲染层）        │
│  Fulcro（数据同步）                      │
└─────────────────────────────────────────┘
                      │
                 HTTP / WebSocket
                      │
┌─────────────────────────────────────────┐
│              服务端（Backend）            │
│  Clojure + JVM                           │
│  PostgreSQL（主数据）                    │
│  Redis（缓存 / 会话 / 实时协作）          │
│  ElasticStorage（文件存储）              │
└─────────────────────────────────────────┘

各层职责：

• 前端（ClojureScript + React）：负责 UI 渲染、画布交互、设计元素编辑。使用 Fulcro 框架实现数据同步和实时协作状态管理。
• 后端（Clojure/JVM）：处理业务逻辑、文件持久化、权限管理、API 路由。核心渲染引擎（Penpotqa）也运行在服务端，用于生成最终输出。
• 数据库（PostgreSQL）：存储用户数据、项目信息、设计文档版本历史。
• 缓存与实时（Redis）：WebSocket 实时协作的消息总线、设计稿缓存。
• 对象存储：大文件（图片、字体、设计资源包）的持久化存储。

实时协作的实现

设计工具的实时协作（多人同时编辑同一个画布）是一个技术难点。Penpot 的做法基于 操作变换（Operational Transformation, OT） 思路：

1. 每个用户操作被捕获并转化为操作意图（而不是最终状态）
2. 操作通过 WebSocket 发送到服务端
3. 服务端作为「权威节点」对并发操作进行转换和排序
4. 转换后的操作广播给所有参与者
5. 客户端在本地重放操作，更新本地状态

这种架构保证了：

• 乐观更新：用户操作立即反映在本地，不需要等待服务端确认
• 冲突解决：服务端作为单一权威源解决并发冲突
• 状态一致性：所有参与者最终看到相同的画面

文件格式与开放标准

Penpot 将设计文档存储为结构化的开放数据，而非专有二进制格式。具体来说：

• 设计文档：存储为 JSON 结构，包含页面、图层、样式、组件的完整描述
• 矢量图形：底层渲染基于 SVG 标准
• 样式导出：支持导出为标准 CSS
• 代码预览：支持导出为 HTML + CSS 片段

这种做法带来的直接好处是：Penpot 的设计文件不依赖 Penpot 本身才能读取。任何理解 JSON/SVG 的工具都可以解析 Penpot 的输出。

三、Penpot 2.0：关键特性解析

CSS Grid Layout

Penpot 2.0 引入了完整的 CSS Grid Layout 支持，这是其在布局能力上的一次重大升级。

此前 Penpot 已经支持 Flexbox 布局，2.0 补全了 Grid 能力，意味着 Penpot 可以精确模拟现代 Web 布局中的所有常见模式。

对于开发者而言，在 Penpot 中设计的网格系统，可以直接对应到生产环境中的 CSS Grid 代码。不再有「设计稿上是 Grid，生产代码里用 Flexbox 勉强凑」的割裂感。

全新的组件系统

Penpot 2.0 重写了组件系统，引入了更完善的：

• 组件嵌套：组件内部可以包含其他组件，形成组件树
• ** Variants（变体）**：同一个组件可以定义多个状态变体（如按钮的 default/hover/disabled 状态），类似于 Figma 的 Component Properties
• Overrides（覆盖）：在实例层面可以覆盖组件的某些属性（如替换图片、修改文本），而不影响主组件

这套组件系统的设计思路，是让设计师能够在 Penpot 中构建可扩展的设计系统——而设计系统恰恰是大型团队维持设计一致性的核心工具。

原生设计令牌（Design Tokens）

设计令牌是设计系统中最重要的概念之一：它是「设计决策」的抽象表示。

例如，一个颜色令牌 color-primary: #6366F1 代表了「品牌主色」这个设计决策。当品牌色需要从 #6366F1 调整为 #8B5CF6 时，只需修改令牌定义，所有使用该令牌的地方自动更新，无需逐个手动替换。

Penpot 是首个将设计令牌作为一等公民集成到核心功能中的设计工具。这与其他工具通常通过插件或第三方集成实现令牌的做法形成鲜明对比。

令牌在 Penpot 中的实际表现：

• 颜色、字体、间距、阴影等设计变量可以定义为令牌
• 令牌可以在组件和样式中引用
• 修改令牌值，引用该令牌的所有设计元素自动更新
• 令牌可以导出为 CSS 自定义属性（--color-primary: #6366F1）供开发团队使用

UI 全新设计

Penpot 2.0 伴随着完整的 UI 重设计。新界面更简洁、更现代，也更符合当今设计工具的交互范式。侧边栏、属性面板、图层面板的布局都经过了重新组织。

四、快速上手

使用 Penpot 官方服务（最简方式）

Penpot 提供了官方托管版本，访问 https://design.penpot.app 即可开始使用。

1. 注册账号（支持 GitHub 登录）
2. 创建团队和项目
3. 开始设计

官方服务永久免费，适合个人开发者和小型团队快速验证。

Docker 自托管

如果需要私有部署，Penpot 提供了 Docker 一键部署方案：

# 克隆仓库
git clone https://github.com/penpot/penpot.git
cd penpot

# 复制并编辑配置
cp .env.example .env
# 编辑 .env，配置数据库连接、管理员账号等

# 启动所有服务（PostgreSQL + Redis + Penpot）
docker-compose up -d

启动后访问 http://localhost:9000 即可。

Kubernetes 部署

对于需要生产级部署的团队，Penpot 提供了 Helm Chart 支持：

helm repo add penpot https://penpot.github.io/helm-charts
helm install penpot penpot/penpot -n penpot --create-namespace

生产部署还需要考虑：

• 外部 PostgreSQL（Penpot Docker 内置的 PostgreSQL 仅适合开发环境）
• S3 兼容的对象存储（用于存储上传的资源和导出文件）
• 邮件发送服务配置（用户注册、密码重置等）
• 域名和 HTTPS 配置

五、从设计到代码：Inspect 模式

Penpot 为开发者提供了强大的 Inspect 模式，这是设计到代码工作流的核心环节。

在 Inspect 模式下，开发者点击任意设计元素，可以看到：

SVG 代码：元素的矢量路径数据，可以直接复制使用

CSS 代码：元素的样式规则（位置、尺寸、颜色、边框、阴影等），可以直接应用到生产代码

HTML 代码：元素对应的 HTML 结构

设计属性：

• 精确的像素尺寸
• 颜色值（支持 HEX、RGB、HSL）
• 字体信息（字体族、字号、行高、字重）
• 间距与对齐信息

设计师完成设计 → 开发者打开 Inspect → 直接获取可用代码，整个流程无需任何第三方工具或插件。

六、插件系统与扩展开发

插件架构

Penpot 提供了一套完整的插件 API，允许开发者扩展平台能力。插件可以：

• 添加自定义面板到 Penpot UI
• 与外部应用集成
• 实现自动化工作流
• 添加新的设计功能

插件使用标准的 Web 技术栈（HTML + CSS + JavaScript）开发，通过 Penpot 的插件市场分发。

贡献源码

Penpot 欢迎各种形式的贡献，包括但不限于：

• 代码贡献：修复 Bug、实现新功能（前端 ClojureScript 或后端 Clojure）
• 翻译贡献：Penpot 已支持多语言，可以参与翻译工作
• 文档贡献：帮助完善官方文档和社区教程
• 模板与库：在社区分享设计模板和组件库

贡献流程：

1. 在 GitHub 上 Fork 仓库
2. 创建特性分支
3. 编写代码和测试
4. 提交 Pull Request
5. 等待 Code Review

官方提供了详细的贡献指南，涵盖了开发环境搭建、本地运行方法、代码规范等内容。

七、常见问题

Q: Penpot 和 Figma 有什么区别？

核心差异在于：

• 许可证：Figma 闭源商业产品，Penpot 完全开源免费
• 部署方式：Figma 仅有云服务，Penpot 支持自托管
• 平台哲学：Figma 追求功能丰富度，Penpot 更强调开放标准和代码导向
• 语言栈：Figma 使用 TypeScript/C++，Penpot 使用 Clojure/ClojureScript

Q: Clojure 写的后端性能如何？

Penpot 的渲染性能对于大多数用例已经足够。对于超大型项目（数千个复杂画布），官方也在持续优化。在生产环境中，建议分配至少 4GB 内存。

Q: 设计文件格式是否会被锁定？

不会。Penpot 导出的文件基于开放标准（SVG、JSON、HTML）。即便有一天 Penpot 项目终止，你的设计资产仍然完全可访问。

八、总结

Penpot 代表了一种独特的路线选择：用函数式语言 Clojure 构建一个完全开源的设计工具，并通过「设计即代码」的理念重新定义设计师和开发者的协作方式。

它的价值主张：

• 打破锁定：不再依赖任何厂商的文件格式和服务
• 降低成本：免费开源，中小团队无需购买昂贵的商业许可证
• 开放标准：设计资产以 SVG/CSS/HTML/JSON 等开放格式存在
• 开发者友好：Inspect 模式让开发者直接获取可用代码
• 设计系统优先：原生支持设计令牌和组件变体，适合大型团队

Penpot 2.0 是该项目的一个重要里程碑，CSS Grid Layout、全新组件系统和设计令牌的深度集成，让它从一个有趣的开源实验逐步成长为一个可以胜任真实生产项目的选择。

如果你对开源设计工具、设计系统构建或 Clojure 在前端的应用感兴趣，Penpot 都是一个值得深入研究的项目。

📚 进阶资源

文档信息 难度：⭐⭐⭐ | 类型：进阶分析 | 更新日期：2026-04-27 | 预计阅读时间：25 分钟