Penpot开源设计工具实测：从Figma迁移到自托管的设计协作方案

最近项目组在设计稿交付这件事上，踩了不少坑。UI标注改了又改，前端工程师对着设计稿一像素一像素地量，状态切换、组件命名、间距圆角这些细节，设计师解释一遍，开发理解一遍，最后还原度全靠临场发挥。有个同事突然甩过来一个链接，说要不试试开源的 Penpot，我把 GitHub 仓库翻了一遍，4.4 万 Star 摆在那里，心里就有了数——这项目不是小打小闹。

Penpot 是一个基于 Web 的开源设计工具，主打 UI/UX 设计与原型制作，同时特别强调"设计和代码之间的无缝协作"。它和 Figma 的核心功能高度重合，但最大的不同在于：Penpot 完全开源、可自托管，数据掌握在自己手里。这篇文章我会从功能对比、代码协作、私有化部署、适用场景四个角度，把我自己实测两周的真实体验写出来，适合正在评估设计工具选型的技术负责人、设计团队负责人，以及想少走弯路的独立开发者。

1. 从"开源替代品"这个说法讲起：Penpot真正解决的痛点

1.1 设计工具这件事，为什么需要开源选项

说句实话，Figma 是很优秀的产品。它的协作体验、插件生态、团队资产库，都是目前行业里做得最成熟的。但成熟归成熟，不代表所有团队都适合。

首先，设计数据是团队的核心资产。界面设计稿、交互流程、组件规范、用户研究素材，这些东西每天都在沉淀。放在别人的云服务上，团队对数据的控制力其实是有限的。尤其当团队面向的客户对数据本地化、私有化有明确要求时，云端部署的工具天然不能满足条件。

其次是预算问题。Figma 按席位订阅，看起来单价不贵，但一个几十人的产品团队加设计团队，一年累积下来也是一笔不小的开支持续支出。而且它的高级功能往往和付费档位绑定，比如设计系统、共享组件库这些真正提升效率的能力，要上更高档位才开放。

开源工具的意义，在于给团队多了一个选择。不是所有团队都必须要自建一套，但"能不能自建"决定了议价权和主动权。Penpot 的出现，恰好填补了高性能开源设计工具这个空白。它不是那种只能画几个原型图的玩具，而是真的能承担日常 UI 设计、原型制作、切图交付完整工作流的工具。

1.2 4.4万Star背后的含金量

GitHub 上的 Star 数容易刷，但 Penpot 这 4.4 万 Star 的成色，要结合项目的底色来看。

Penpot 背后的公司叫 Kaleidos，是做开源起家的技术团队，项目从 2018 年开始孵化，核心代码仓库长期保持非常高的活跃度。它的技术路线也很有意思：前端用 ClojureScript 编译成 JavaScript 运行在浏览器里，图形渲染层以 SVG 为核心，因此在缩放、导出、代码还原这些场景里有一些天然优势，后面我会展开讲。

Star 数代表的是关注，但决定一个开源项目工程质量的是 commit 频率、issue 响应速度和发布节奏。Penpot 在这几方面的表现，在我实际使用中有明显感知：Bug 修得快，新功能迭代节奏稳定，社区里也能看到官方积极回复问题。这种"背后有一家专业公司全职维护"的开源项目，用起来比那种个人开发者抛出的半成品要安心得多。

2. 实测两周：Penpot与Figma的功能对比和真实使用感受

2.1 核心功能对照表

先把两张表放在前面，一张是功能层面的对比，一张是我自己主观体验后的结论。为了公平起见，对比的基准版本是我当前使用的最新稳定版 Penpot 和团队还在用的 Figma 专业版。

2.2 上手迁移的真实体验

我团队里既有设计师也有开发，我让他们分别从 Figma 转 Penpot 试了两周，反馈很有意思。

设计师的第一反应是：快捷键不习惯。Penpot 和 Figma 很多基础操作的快捷键不一样，比如选择工具、缩放、切图快捷键，肌肉记忆需要时间迁移。这其实不是 Penpot 的短板，只要在设置里把偏好调一遍，大部分常用操作都能找到替代。真正让设计师满意的点是 SVG 渲染带来的缩放体验：在画布里放大到极小或极大时，图形边缘始终保持锐利，导出 SVG 和 PDF 时细节还原度非常高，这对需要输出图标、插画资源的团队是实打实的加分项。

开发人员的反馈更直接：代码查看面板太好用了。选中任意一个图层，右侧就能直接看到它的 CSS 属性——宽高、间距、圆角、填充、边框、阴影，甚至 transform 变换。设计师把视觉稿的间距从 16px 改成 12px，开发不用再去拿标尺测，直接看 CSS 面板里的数值就对上了。

2.3 中文界面、字体管理和本地化的细节

热搜上经常有人问"Figma 怎么汉化""Figma 安装字体不生效"，这些困扰说明中文用户对本地化体验是很敏感的。使用 Penpot 的时候，我发现它对中文界面和多语言的支持做得比较自然，界面本身有多语言版本，团队里英文不太好的成员用起来不费劲。

字体的处理方式也和 Figma 的逻辑不同。Penpot 支持在系统内上传字体文件，然后项目内所有成员都能使用这个字体。团队如果用的是自定义字体或者国内厂商的字体授权，不用每台机器手动装一遍，直接传上去共享就行。这个点对国内团队尤其友好，避免了很多"我这台机器看不到这个字体"的扯皮场景。

3. 设计到代码的"最后一公里"：Penpot的协作价值拆解

3.1 静态标注变成实时属性，开发不用再"量图"

传统设计交付流程里，最容易被吐槽的就是标注。设计师在稿子里标了间距、字号、颜色，开发者照着还原，但稿子改了一版之后标注经常没同步更新，开发按旧数据显示，还原度就打了折扣。

Penpot 的处理方式绕开了标注这个环节。因为它是 SVG 优先的渲染架构，所以每个元素的位置、尺寸、颜色、圆角、阴影这些信息本来就是结构化数据，属性检查器里直接呈现的就是真实代码层级的属性值。设计师改完画布，CSS 视图里的数据同步更新，开发不用等标注，随时打开都是最新的。用团队里前端的一句话来讲：这相当于把设计稿变成了一个可视化调试器，能看到我真正需要的样式值。

3.2 设计 Token：把设计规范变成团队共识

如果说实时属性解决的是"单个元素怎么还原"，那设计 Token 解决的是"整套规范怎么统一"。

我可以在 Penpot 里定义颜色、字体、间距、圆角等基础 Token，组件库里的所有元素都引用这些 Token。以后调品牌色，只需要改 Token 的值，全项目所有用到这个颜色的地方统一更新。这听起来像设计系统该做的事，但放到协作语境里的意义是：Token 的定义方式和前端代码里的 CSS 变量、设计令牌概念是对齐的，设计师用的 Token 名和工程师代码里的变量名可以统一。

实际操作中，我会列一张 Token 与前端变量的对照关系表，比如颜色 Primary500 对应前端组件库的 color-primary-500。团队约定保持一致，设计师作图、开发写码就是同一套词表，沟通成本大幅下降。Penpot 在这个方向上的支持基础已经可用，社区也在迭代更完整的管理界面。

3.3 一条更轻的协作工作流

我实际在团队里跑通的一条工作流是这样的：设计师在 Penpot 里完成界面稿，组件基础引用 Token；分享评审链接给产品和开发，在线评论直接留在画布上；前端开发的时候开两个窗口，左边 Penpot 看视觉稿，右边 IDE 写代码，需要数值直接抄属性检查器。

这个过程省掉了原先的标注、导出、命名规范文档、设计走查记录等多个环节的文件传递。虽然单看哪个环节都不复杂，但一整条链路省下来，实际节省的时间非常可观。我粗略统计过，一个中等复杂度页面的交付周期，从原来的三天压缩到一天半左右，这个收益不是工具本身带来的，而是工具把信息的流转路径变短了。

4. 从零跑通 Penpot：私有化部署的完整步骤和踩坑记录

4.1 为什么我优先考虑自托管，而不是直接用官方版

Penpot 也提供官方云端服务，注册账号就能用，跟 Figma 的体验差不多。但我个人的主张是：既然选 Penpot，自托管的意义不能忽略。

一方面，自托管意味着数据完全在自己的服务器上，不经过任何第三方平台，这对有保密要求的产品研发来说是一条硬约束的解决方案。另一方面，自托管还意味着可以自定义基础设施。想要它跑在内网，部署一套；想要接入自己的统一登录认证，改造起来也有抓手。这种自由度，是任何商业 SaaS 都很难给的。

当然，自托管也有代价，就是需要团队里有懂运维的人，Docker、Nginx、数据库这些基础概念得有人能接住。如果团队完全没有运维能力，那可以先用官方的在线版，把设计协作跑起来再说。

4.2 Docker Compose 部署的完整流程

Penpot 官方提供了完善的 Docker 化部署方案，我实测下来流程非常顺滑，大约一个小时以内可以跑通。下面是完整的部署步骤。

前置条件：一台能运行 Docker 的 Linux 服务器，内存建议至少 4GB（我 2GB 的小机器也跑通过，但多人并发时会比较吃力），安装好 Docker 和 Docker Compose 插件。

第一步，创建项目目录并准备 Compose 文件。

mkdir ~/penpot && cd ~/penpot

然后从 Penpot 官方 GitHub 仓库或官方文档里找到标准的 docker-compose 编排文件，保存到这个目录。整个编排一般包含前端 Nginx 容器、后端服务容器、PostgreSQL、Redis 和对象存储组件，帮你把基础依赖全部串联好。

第二步，修改关键环境变量。自托管场景下，你需要把数据库密码、自动生成的密钥、对外访问地址这几项改成自己的值。举个例子，如果你的服务将通过 https://design.example.com 访问，那环境变量里的 public URI 要对应改成这个地址。数据库密码建议用一个足够长的随机串，避免默认弱口令暴露在公网上。

第三步，启动服务。

docker compose up -d docker compose logs -f

等前端和后端容器都进入运行状态，浏览器访问服务器 IP 或配置好的域名，就能看到 Penpot 的登录页。第一次访问时可以注册第一个账号，系统会自动把它设为管理员。

4.3 部署过程中我踩过的三个坑

第一个坑是端口占用。Penpot 默认通过 Nginx 暴露 80 端口，如果服务器上已经跑了其他 Web 服务，端口就冲突了。解决方案有两个：一个是改 Compose 里 Nginx 的端口映射，比如把 80:80 改成 8080:80；另一个是用已有的反向代理把子域名转发到 Penpot 的端口。我更推荐第二种，因为后面如果要挂 HTTPS 证书，反向代理层处理起来更顺手。

第二个坑是邮件服务。默认配置里邮件服务没有真正对接外部 SMTP，所以系统里"忘记密码""邮件验证"这些功能是发不出邮件的。第一次搭建时如果只靠密码登录，这个问题感知不大，但如果你想开团队协作、邀请成员，最好提前配置一个 SMTP 服务，常见的邮件服务商都可以，配置好之后邀请和通知才走得通。

第三个坑是备份。Penpot 的数据分两大部分：数据库（PostgreSQL）里存的是设计稿的元数据和结构信息，对象存储（默认本地磁盘）里存的是图片、字体等文件资产。备份时必须两个都备份，只备份数据库会导致附件丢失。我现在的做法是写一个定时脚本，每天凌晨把 PostgreSQL 的数据 dump 出来，同时把对象存储的目录打包上传到远端存储，双保险。

4.4 内网环境的分发与日常维护

部署好之后，团队内部使用是完全没问题的。为了让大家访问方便，我做了几个小优化：配置好 HTTPS 证书，让浏览器不出现安全警告；在登录页上绑定团队域名，方便记忆；在管理员后台创建好项目空间，邀请成员时会收到邮件通知。日常维护的话，Penpot 的升级也挺简单的，docker compose pull 拉新的镜像，再 docker compose up -d 重启，旧数据会自动保留。

自托管版本最让我安心的点是：升级、回滚、数据导出这些操作，主动权都在自己手里。不会因为服务商策略变动，被迫改工作流。

注意：如果你准备把 Penpot 长期作为团队正式工具，建议从第一天就把"数据备份"和"访问安全"这两件事做好，后续会省掉很多补救工作。

5. 哪些团队适合切换到 Penpot，哪些需要再等等

5.1 我推荐的切换场景

第一类，数据敏感型团队。不管是做政企项目、金融行业还是医疗相关的产品，数据不出内网往往是一条硬性规定。Penpot 自托管的部署方式可以把设计数据完全留在私有网络，满足合规要求的同时不牺牲协作效率。

第二类，中小规模设计与开发团队。比如团队的设计师人数在十人以内，开发二十人以内，没有太复杂的组织架构和权限层级，Penpot 的能力足够覆盖日常需求。这类团队最容易被订阅费用拖累，切换到 Penpot 后每年省下的成本相当可观。

第三类，需要和开源流程深度整合的团队。如果团队本身用 GitLab、开源项目管理工具、开源监控体系，那再引入一个开源的 Penpot 也是很和谐的组合。需要批量导出设计资源、脚本处理设计稿、做自动化检查，Penpot 的开放性都能提供更多操作空间。

5.2 暂时不建议切换的场景

如果你的团队重度依赖 Figma 的插件生态，比如依赖 Content Reel、Iconify、各种图表生成插件，那 Penpot 现在的插件生态还撑不起这个工作量。我建议先观望，等插件市场更丰富之后再评估。

另外一个场景是大型设计系统。如果你的组件库规模很大、交互状态特别多、依赖非常精细的变体和自动布局能力，Figma 在设计系统管理上的成熟度目前仍然领先 Penpot。不是说 Penpot 做不了，而是迁移和重建的投入产出比在现阶段还不够理想。

5.3 我的迁移建议和一些心里话

我自己的建议是：不要一刀切。Penpot 和 Figma 完全可以并行跑。先把非核心的、低敏感度的项目放到 Penpot 上试错，跑顺之后再把边界逐渐扩大；Figma 上已经建立好的核心组件库暂时不用迁移，等团队对 Penpot 有了充足信心后再动手也不迟。

可能有人会问，既然 Figma 这么强，为什么还要折腾 Penpot？我的看法是：设计工具不应该只有一家独大的选择。一个再好的商业工具，也不能成为团队长期唯一依赖的基础设施。开源工具带来的是选择权和主动权，Penpot 在这个方向上已经走出了非常扎实的一步。

最后分享一个我在实际使用中的体会：工具选型这事，真的不是比谁功能列表更长，而是看在你的团队具体工作流里，它能帮你省下多少无效沟通。Penpot 让我感受最深的就是，设计稿不再是一张"图片"，而是一份能被工程师直接读取的数据源。如果你也想试试这种协作方式，建议直接部署一套自己玩玩，比看一百篇文章都有用。