开源设计工具迁移实战：Figma、Penpot与自托管方案深度对比

1. 从一次团队协作卡顿说起为什么我开始认真考虑开源设计工具去年秋天我们团队接了一个中型产品的改版项目设计侧三个人前端侧四个人产品经理两个。项目启动第一周设计负责人在群里发了一条消息“Figma 的协作席位又不够了谁最近用得少先让出来。”这条消息像一颗小石子扔进了平静的水面接下来两天团队里断断续续在讨论席位分配、文件权限、版本历史这些原本不该占用太多精力的事情。我当时负责前端对接看着设计稿里那些标注、切图、组件状态心里想的却是另一个问题我们真的需要把整个设计协作流程绑在一个商业 SaaS 上吗这个问题不是突然冒出来的。过去两年我陆续接触过一些开源设计工具比如Penpot、OpenPencil也帮朋友搭过自托管的设计协作环境。一开始只是出于好奇想看看开源方案到底能做到什么程度。但那次席位风波之后我开始认真评估如果团队整体迁移到开源设计工具到底会失去什么又能得到什么。这篇文章就是那次评估的完整记录包含了我对Figma、Penpot、OpenPencil以及自托管方案的实测对比、迁移思路和踩坑经验。如果你也在纠结要不要换工具或者单纯想了解开源设计工具现在发展到哪一步了下面的内容应该能帮你省下不少调研时间。先说结论这不是一个“Figma 好不好”的问题而是一个“你的团队处在什么阶段、最在意什么”的问题。Figma 在云端协作、生态插件、社区资源方面依然是标杆但开源工具在数据主权、成本可控、定制自由度上的优势正在被越来越多的团队认真对待。尤其是当“自托管”这个词从运维圈渗透到设计圈之后事情变得更有意思了。2. 先搞清楚你到底在为什么付费Figma 的核心价值拆解2.1 云端协作不是简单的“文件放网上”很多人把 Figma 的核心竞争力归结为“云端”这个说法太粗糙了。我用了四年 Figma真正让它难以替代的是基于浏览器的实时多人协作模型。注意这里的关键词是“实时”和“多人”。你可以同时和三个设计师在同一个画板上操作每个人的光标位置、选中状态、正在编辑的图层都实时同步延迟低到几乎感觉不到。这种体验背后是一整套复杂的冲突解决机制不是简单地把文件存到服务器上就能实现的。我试过用一些早期的在线设计工具多人同时编辑同一个图层时会出现覆盖、闪烁、甚至文件损坏。Figma 在这方面的工程积累确实深厚。另外它的组件系统和自动布局也是很多团队离不开的功能。组件变体、实例覆盖、嵌套组件这些概念在 Figma 里已经打磨得非常成熟。前端开发者可以直接从设计稿里复制 CSS 代码片段虽然不能直接用但至少省去了手动测量间距的麻烦。还有一个容易被低估的价值社区和插件生态。Figma 社区里有海量的免费 UI Kit、图标库、插画资源插件市场里有自动生成色板、批量重命名、无障碍检查等各种工具。这些东西看起来是“锦上添花”但实际工作中能省下大量重复劳动。比如我常用的一个插件可以一键导出所有图标的 SVG 并自动压缩另一个插件可以检查对比度是否符合 WCAG 标准。这些生态优势是开源工具短期内很难追上的。2.2 席位制收费背后的隐性成本Figma 的定价模式是按席位收费专业版每个编辑席位每月 12 美元左右组织版更贵。对于小团队来说这个价格不算离谱但问题在于席位的刚性。一个项目来了你需要给所有参与编辑的人开席位项目结束了席位又不能立刻回收因为可能还要改。更麻烦的是有些角色比如产品经理、市场运营他们只需要看设计稿、留评论不需要编辑权限但 Figma 的查看席位和编辑席位之间的功能差异有时候会让协作变得别扭。我算过一笔账一个十人团队其中三个设计师需要编辑权限两个产品经理需要评论权限五个前端需要查看和标注权限。如果全部按编辑席位算一年下来是一笔不小的开支。如果按查看席位算又会有各种权限限制。这还不包括有时候需要临时给外部合作方开权限的情况。隐性成本还包括文件数量多了之后的管理成本、版本历史占用的存储空间、以及团队成员离职后席位回收的流程成本。注意Figma 的教育版和免费版有文件数量限制团队规模稍微大一点就会碰到天花板。很多团队一开始用免费版后来发现文件数量不够用只能升级这个过程中积累的文件迁移成本也不低。2.3 数据主权一个越来越无法回避的问题“数据主权”这个词听起来有点宏大但落到实际工作中很具体你的设计稿存在别人的服务器上你无法完全控制谁能访问、数据存在哪个区域、备份策略是什么。对于大多数商业项目来说这可能不是问题但对于涉及敏感业务、或者有合规要求的团队来说这就是一个必须考虑的因素。我接触过一些做企业级产品的团队他们的设计稿里包含未发布的功能逻辑、业务流程图、甚至部分数据模型。这些东西如果放在第三方 SaaS 上安全团队会反复追问数据加密了吗访问日志能审计吗能不能私有化部署Figma 的企业版提供了一些合规功能但价格也上去了。而开源工具的自托管方案恰好能解决这个问题——数据完全在你自己的服务器上访问控制、备份策略、审计日志都由你自己决定。3. 开源设计工具现在到底能不能打Penpot 与 OpenPencil 实测3.1 Penpot最接近 Figma 体验的开源选择Penpot 是我用得最久的开源设计工具前后大概有八个月。它基于 Web 技术构建支持自托管也可以直接用官方提供的云端版本。第一次打开 Penpot 的时候我的感觉是“像 Figma 的简化版”。界面布局、工具栏位置、图层面板结构都很相似上手成本很低。它支持组件、变体、自动布局、约束、原型交互这些核心功能对于大多数 UI 设计场景来说够用了。但“够用”和“好用”之间还有距离。Penpot 的性能是我遇到的第一个问题。当画板上的图层数量超过一定规模比如一个复杂的后台管理界面缩放和拖拽会明显卡顿。我试过在一个画板里放两百多个图层操作延迟大概有半秒左右虽然不至于无法工作但和 Figma 的流畅度差距明显。第二个问题是字体渲染。Penpot 对中文字体的支持不如 Figma 完善有些字体在编辑器里显示正常导出后会出现字重不对、字形缺失的情况。我后来养成了一个习惯所有中文字体都先导出测试一遍确认没问题再用。不过 Penpot 有一个让我很惊喜的功能代码导出。它可以直接把选中的元素导出为 SVG、PNG甚至生成对应的 CSS 和 HTML 代码片段。虽然生成的代码不能直接用于生产环境但作为前端开发的参考非常方便。另外Penpot 的插件系统也在逐步完善虽然数量远不如 Figma但一些基础插件比如图标库、色板生成器已经有了。3.2 OpenPencil轻量但定位不同的选择OpenPencil 的定位和 Penpot 不太一样。它更偏向于原型设计和线框图而不是高保真 UI 设计。我第一次用 OpenPencil 的时候感觉它更像是一个“设计草稿工具”。它的界面非常简洁工具栏只有最基本的形状、文本、连线工具。没有复杂的组件系统没有自动布局也没有插件市场。但这不一定是缺点。如果你的工作流程是“先画线框图确认逻辑再进 Figma 做高保真”那 OpenPencil 可以替代第一步。它的优势是启动快、学习成本极低。我让一个完全没用过设计工具的产品经理试了一下十分钟就能画出基本的页面流程图。而且 OpenPencil 也是开源的可以自托管数据同样在自己手里。不过要注意OpenPencil 的协作功能比较基础。它支持多人同时编辑但实时同步的体验不如 Penpot更不如 Figma。如果你需要频繁的多人协作OpenPencil 可能会让你着急。另外它的导出格式比较有限主要是 PNG 和 SVG没有 PDF 导出也没有代码生成功能。3.3 自托管方案数据主权与运维成本的权衡自托管是开源设计工具最大的卖点之一但也是最容易被低估的环节。我帮两个团队搭过 Penpot 的自托管环境一个用的是 Docker Compose另一个用的是 Kubernetes。Docker Compose 方案比较简单一台 4 核 8G 的云服务器就能跑起来数据库用 PostgreSQL对象存储用 MinIO 或者直接挂载本地磁盘。整个部署过程大概半天包括配置域名、SSL 证书、备份策略。但“搭起来”和“稳定运行”是两回事。我遇到的第一个问题是版本升级。Penpot 的迭代速度不慢每次升级都需要备份数据库、拉取新镜像、执行迁移脚本。如果跳过某个中间版本可能会遇到数据库结构不兼容的问题。第二个问题是性能调优。默认配置下Penpot 的图片加载和文件导出会比较慢需要调整缓存策略、增加工作进程数、优化数据库索引。这些都需要一定的运维经验。提示如果你没有专门的运维人员建议先用 Penpot 的官方云端版本或者找一家提供托管服务的供应商。自托管的隐性成本主要在运维上不是搭起来就完事了。下面这张表是我对三个方案的核心对比基于实际使用体验整理对比维度FigmaPenpot自托管OpenPencil自托管核心定位全功能云端设计协作开源 UI 设计与原型轻量原型与线框图实时协作极佳良好基础组件系统非常成熟可用无自动布局支持支持无插件生态丰富初步无中文字体支持优秀一般一般代码导出有限支持 CSS/HTML无数据主权云端完全自控完全自控运维成本无中等低适合团队各类规模中小团队小团队/个人4. 迁移之前必须想清楚的五件事4.1 你的团队真的需要“实时协作”吗这个问题听起来有点奇怪但值得认真问。我观察过很多团队的实际工作模式设计师大部分时间是独立工作的只有在评审和交接的时候才需要多人同时在线。如果你们的协作频率是“每天一次站会同步”那实时协作的优先级可能没那么高。Penpot 的协作体验虽然不如 Figma但应付日常的评审和交接足够了。真正需要高频实时协作的场景是多个设计师同时在一个复杂项目上工作需要频繁看到彼此的修改。这种情况在大型团队里比较常见小团队反而不多。所以先统计一下你们团队过去一个月里有多少次是多人同时编辑同一个文件的。如果次数不多实时协作的权重可以降低。4.2 插件依赖有多深Figma 的插件生态是很多团队离不开的。我见过一些设计师的工作流完全建立在插件上用插件生成色板、用插件批量导出、用插件做无障碍检查、用插件对接项目管理工具。如果你也是这种情况迁移到开源工具之前先列一个插件清单看看哪些是“没有就活不下去”的哪些是“有更好但没有也行”的。Penpot 的插件系统还在发展中目前能替代的 Figma 插件大概只有两三成。如果你重度依赖某个特定插件比如自动生成设计规范的插件那迁移可能会很痛苦。但如果你主要用 Figma 的基础功能插件只是偶尔用用那影响不大。4.3 文件迁移的坑比想象中多从 Figma 导出文件再导入 Penpot这个过程比想象中麻烦。Figma 支持导出.fig文件但 Penpot 不能直接读取。你需要先把 Figma 文件导出为 SVG 或 PDF再导入 Penpot。SVG 导入后图层结构会变得混乱组件会丢失变体关系自动布局会变成普通分组。我试过迁移一个中等复杂度的页面大概花了两个小时重新整理图层和组件。更麻烦的是字体。Figma 里用的字体如果 Penpot 的服务器上没有安装导入后会变成默认字体。你需要提前把所有用到的字体文件上传到 Penpot 的字体管理里或者改用 Penpot 内置的字体。中文字体尤其要注意有些商业字体有版权限制不能随便上传到服务器。4.4 前端交接流程要不要改前端开发者从 Figma 获取设计稿的方式通常是通过 Inspect 面板查看标注、复制 CSS、下载切图。Penpot 也有类似的功能但细节上有差异。比如 Penpot 的 CSS 导出格式和 Figma 不完全一样有些属性需要手动调整。切图的命名规则、导出倍率、格式选项也有区别。如果你的前端团队已经习惯了 Figma 的交接流程迁移后需要一段适应期。我建议在正式迁移之前先让前端和设计一起做一个小的试点项目把交接流程跑通收集反馈再决定是否全面推广。4.5 成本账要算全开源工具看起来免费但成本并没有消失只是转移了。自托管的服务器费用、运维人力、迁移时间、学习成本、效率损失这些都是成本。我算过一个十人团队的账Figma 专业版一年大概一万多人民币自托管 Penpot 的服务器费用一年大概两三千但加上运维人力和迁移成本第一年的总成本可能反而更高。从第二年开始自托管的成本优势才会显现出来。所以如果你的团队规模很小或者项目周期很短Figma 的付费方案可能更划算。如果你的团队规模中等以上项目周期长且对数据主权有要求那自托管开源方案值得认真考虑。5. 实操从零搭建一套可用的开源设计协作环境5.1 服务器选型与基础环境准备如果你决定走自托管路线第一步是选服务器。我的经验是不要用最低配的服务器。Penpot 的前端是 React 应用后端是 Clojure 服务数据库是 PostgreSQL对象存储可以用本地磁盘或 MinIO。最低配置建议 4 核 CPU、8G 内存、100G SSD。如果团队人数超过十人或者文件数量多建议 8 核 16G 起步。操作系统我推荐 Ubuntu 22.04 LTS社区支持好文档全。基础环境需要安装 Docker 和 Docker Compose。如果你用的是其他 Linux 发行版步骤类似但包管理命令不一样。安装完 Docker 后创建一个专用目录比如/opt/penpot用来存放配置文件和持久化数据。# 更新系统包 sudo apt update sudo apt upgrade -y # 安装 Docker curl -fsSL https://get.docker.com | sudo sh # 安装 Docker Compose sudo apt install docker-compose-plugin -y # 创建 Penpot 目录 sudo mkdir -p /opt/penpot cd /opt/penpot5.2 Docker Compose 配置详解Penpot 官方提供了 Docker Compose 模板但默认配置需要根据实际情况调整。我下面这份配置是基于官方模板修改的重点调整了数据库密码、对象存储路径、以及前端和后端的资源限制。version: 3.8 services: penpot-frontend: image: penpotapp/frontend:latest restart: always ports: - 9001:80 volumes: - penpot_assets:/opt/data/assets depends_on: - penpot-backend - penpot-exporter environment: - PENPOT_FLAGSenable-registration enable-login-with-password penpot-backend: image: penpotapp/backend:latest restart: always volumes: - penpot_assets:/opt/data/assets depends_on: - penpot-postgres - penpot-redis environment: - PENPOT_SECRET_KEYyour-secret-key-here - PENPOT_PUBLIC_URIhttp://your-domain.com:9001 - PENPOT_DATABASE_URIpostgresql://penpot:penpotpenpot-postgres/penpot - PENPOT_DATABASE_USERNAMEpenpot - PENPOT_DATABASE_PASSWORDpenpot - PENPOT_REDIS_URIredis://penpot-redis/0 - PENPOT_ASSETS_STORAGE_BACKENDassets-fs - PENPOT_STORAGE_ASSETS_FS_DIRECTORY/opt/data/assets - PENPOT_TELEMETRY_ENABLEDfalse penpot-exporter: image: penpotapp/exporter:latest restart: always environment: - PENPOT_PUBLIC_URIhttp://penpot-frontend - PENPOT_REDIS_URIredis://penpot-redis/0 penpot-postgres: image: postgres:15 restart: always volumes: - penpot_postgres:/var/lib/postgresql/data environment: - POSTGRES_INITDB_ARGS--data-checksums - POSTGRES_DBpenpot - POSTGRES_USERpenpot - POSTGRES_PASSWORDpenpot penpot-redis: image: redis:7 restart: always volumes: penpot_assets: penpot_postgres:几个关键点解释一下。PENPOT_SECRET_KEY必须改成你自己的随机字符串可以用openssl rand -base64 32生成。PENPOT_PUBLIC_URI要改成你的实际域名或 IP 地址否则前端无法正确连接后端。PENPOT_TELEMETRY_ENABLEDfalse是关闭遥测数据上报如果你在意隐私可以关掉。数据库密码建议改掉默认的penpot虽然在内网环境风险不大但好习惯要养成。5.3 反向代理与 HTTPS 配置直接用 IP 加端口访问体验很差而且没有 HTTPS 不安全。我建议用 Nginx 做反向代理配合 Lets Encrypt 的免费证书。下面是一个基本的 Nginx 配置示例server { listen 80; server_name design.yourdomain.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name design.yourdomain.com; ssl_certificate /etc/letsencrypt/live/design.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/design.yourdomain.com/privkey.pem; client_max_body_size 100M; location / { proxy_pass http://127.0.0.1:9001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /assets/ { proxy_pass http://127.0.0.1:9001/assets/; proxy_cache_valid 200 7d; expires 7d; } }client_max_body_size要调大因为设计文件可能包含大图。/assets/路径的缓存配置可以显著提升图片加载速度。证书用 Certbot 自动申请和续期具体命令这里不展开网上教程很多。5.4 字体管理与中文字体支持Penpot 默认只带了少量英文字体中文字体需要手动上传。进入 Penpot 后台管理界面找到“字体”设置上传 TTF 或 OTF 文件。注意上传的字体文件会存储在服务器上所有团队文件都可以使用。如果你用了商业字体确保有相应的授权。我实测下来思源黑体、思源宋体、阿里巴巴普惠体这些开源中文字体在 Penpot 里表现不错。但要注意字体文件不要太大否则会影响编辑器的加载速度。一个中文字体文件动辄十几 MB上传后首次加载会比较慢。建议只上传团队实际用到的字重比如 Regular、Medium、Bold 三个就够了。注意Penpot 的字体渲染在导出时可能会有差异尤其是中文字体的字重和字形。建议在正式使用前用几个典型页面做导出测试确认效果符合预期。5.5 备份策略与数据恢复演练自托管最大的风险是数据丢失。我见过一个团队因为服务器磁盘故障丢失了三个月的设计文件最后只能从导出的 PNG 里重新画。所以备份策略必须提前设计好。我的方案是每天自动备份数据库和资产目录保留最近 30 天的备份每周做一次异地备份。#!/bin/bash # backup-penpot.sh BACKUP_DIR/backup/penpot DATE$(date %Y%m%d) mkdir -p $BACKUP_DIR/$DATE # 备份数据库 docker exec penpot-postgres pg_dump -U penpot penpot | gzip $BACKUP_DIR/$DATE/db.sql.gz # 备份资产文件 tar -czf $BACKUP_DIR/$DATE/assets.tar.gz /opt/penpot/penpot_assets # 删除 30 天前的备份 find $BACKUP_DIR -type d -mtime 30 -exec rm -rf {} \; # 同步到异地示例用 rsync实际可以用对象存储 rsync -avz $BACKUP_DIR/$DATE/ backup-server:/backup/penpot/$DATE/这个脚本放到 crontab 里每天凌晨执行。备份完成后一定要做恢复演练。我建议每季度做一次在一台测试服务器上用备份文件恢复一套完整环境确认数据完整可用。没有经过恢复演练的备份不能算真正的备份。6. 常见问题与排查技巧实录6.1 文件导入后图层混乱怎么办从 Figma 导出 SVG 再导入 Penpot图层结构混乱是最常见的问题。我的处理流程是先在 Figma 里把页面拆分成多个小文件每个文件只包含一个主要模块比如“导航栏”、“侧边栏”、“内容区”。导出 SVG 时取消勾选“包含图层 ID”和“轮廓化文本”这样可以保留文本的可编辑性。导入 Penpot 后手动重建组件和自动布局。这个过程比较耗时但迁移完成后后续维护会方便很多。另一个技巧是如果原文件里有大量重复元素先在 Figma 里把它们转成组件再导出 SVG。Penpot 导入后虽然组件关系会丢失但至少图层命名是清晰的方便你重新创建组件。6.2 编辑器卡顿的性能优化Penpot 编辑器卡顿通常有几个原因图层数量太多、图片太大、浏览器缓存不足。我试过在一个画板里放三百多个图层操作延迟明显。解决办法是拆分画板把一个大页面拆成多个小画板每个画板控制在 100 个图层以内。图片方面导入前先用工具压缩把大图控制在 2000px 宽度以内。浏览器方面Chrome 和 Edge 的表现比 Firefox 好一些建议用 Chromium 内核的浏览器。服务器端也可以优化。增加后端的工作进程数、调整 PostgreSQL 的shared_buffers和work_mem、给 Redis 分配更多内存这些都能提升响应速度。具体参数需要根据服务器配置调整没有万能值。6.3 多人协作时的冲突处理Penpot 的多人协作虽然支持实时同步但在网络不稳定的情况下可能会出现冲突。我遇到过一次两个设计师同时修改同一个组件的不同属性结果一方的修改被覆盖了。Penpot 的冲突解决机制不如 Figma 成熟所以我的建议是建立协作规范。比如约定同一时间只有一个人编辑主组件其他人通过实例覆盖来修改或者用“锁定图层”功能防止误操作。另外Penpot 的版本历史功能可以回溯到之前的版本但粒度比较粗只能按小时或按天回溯。如果发生冲突可以尝试从版本历史里恢复。但最好的办法还是预防提前约定好谁负责哪个模块。6.4 导出文件与前端对接的注意事项Penpot 导出的 CSS 和 Figma 有一些差异。比如Penpot 的 flex 布局导出格式和 Figma 的 auto layout 不完全一样有些属性需要手动调整。切图导出时Penpot 默认导出 1x 和 2x但命名规则和 Figma 不同。我建议前端团队在对接前先和设计一起制定一个导出规范切图命名用“模块-元素-状态”的格式导出倍率固定为 1x、2x、3x格式优先用 SVG位图用 WebP。还有一个细节Penpot 的 Inspect 面板里间距和尺寸的单位是像素但有时候会有小数。前端在实现时要注意四舍五入避免出现 0.5px 这种奇怪的值。6.5 常见问题速查表问题现象可能原因排查步骤解决方案编辑器加载缓慢图层过多/图片过大检查画板图层数查看网络请求大小拆分画板压缩图片字体显示异常字体未上传/格式不支持检查后台字体列表确认字体格式上传 TTF/OTF 字体测试导出多人协作冲突同时编辑同一元素查看版本历史确认冲突时间点建立协作规范使用锁定功能导出 CSS 不准确自动布局差异对比 Figma 和 Penpot 的导出结果手动调整制定导出规范数据库连接失败密码错误/服务未启动检查 Docker 容器状态和日志重启服务核对环境变量资产文件丢失存储路径配置错误检查PENPOT_STORAGE_ASSETS_FS_DIRECTORY修正路径恢复备份7. 我的实际迁移体会与后续扩展思路迁移到 Penpot 之后我们团队的实际感受是前两周最痛苦一个月后基本适应三个月后回不去了。痛苦主要来自习惯的改变快捷键不一样、插件不够用、偶尔的卡顿让人烦躁。但适应之后我们发现一些之前没意识到的好处。比如自托管之后设计文件的访问速度反而更快了因为服务器就在公司内网。再比如我们可以自由地定制 Penpot 的界面和功能虽然改动不大但心理上感觉工具是自己的。成本方面第一年确实没有省多少钱服务器费用加上迁移时间和 Figma 的订阅费差不多。但从第二年开始边际成本几乎为零而且团队规模越大优势越明显。数据主权方面安全团队再也没有追问过设计稿的存储问题这一点对做企业级产品的团队来说很重要。后续我打算做两件事一是把 Penpot 的插件系统研究透看看能不能自己写几个内部插件比如自动生成设计规范、对接内部项目管理工具。二是探索 Penpot 的 API看看能不能把设计稿和前端代码仓库打通实现设计变更自动触发前端构建。这些想法还在早期阶段等有成果了再分享。如果你也在考虑迁移我的建议是先小范围试点再全面推广。找一个不太紧急的项目让设计和前端一起用 Penpot 走一遍完整流程收集反馈解决问题再决定是否推广到整个团队。不要一上来就全员迁移那样风险太大。另外迁移过程中一定要保留 Figma 的订阅至少三个月作为过渡期的备份方案。等团队完全适应了再考虑取消。