1. 设计工具选型的十字路口最近半年我所在的几个设计群、前端群、独立开发者社区里关于要不要从 Figma 迁走的讨论明显变多了。触发点很集中订阅价格调整、团队席位计费方式变化、以及一部分人对设计资产到底放在谁家服务器上这件事越来越在意。与此同时Penpot、OpenPencil 这类开源设计工具被反复提起自托管这个词也从运维圈渗透到了设计师的日常聊天里。我自己是从 2019 年开始重度使用 Figma 的做过组件库、设计系统、多人协作项目也踩过插件崩溃、字体缺失、文件权限混乱的坑。2023 年底我开始认真评估开源替代方案把 Penpot 自托管跑起来也试了 OpenPencil 这类偏轻量的工具前后折腾了小半年。这篇文章不是要给你一个必须换或者千万别换的结论而是把我评估过程中真正关心的维度、实测下来的体验、以及那些文档里不会写的坑完整摊开讲一遍。如果你正在纠结这个问题先明确一下这篇文章适合谁看一是中小团队的设计负责人需要算清楚成本和迁移代价二是独立开发者或自由设计师想找一个不依赖订阅、数据自己掌控的方案三是对自托管感兴趣、但不确定技术门槛有多高的设计师。我会尽量把技术部分讲得让非运维背景的人也能看懂同时把设计工作流的部分讲得让工程师也能理解。先说一个我自己的判断放弃 Figma这个说法本身有点极端。更现实的问法是——你的团队在什么阶段、什么规模、什么合规要求下应该把哪一部分工作流迁移到开源工具上。全量替换和部分并行是完全不同的两件事代价也差得很远。2. 为什么大家开始认真考虑开源设计工具2.1 成本结构的变化从够用就行到按人头算账早期 Figma 的免费额度对个人和小团队非常友好三个协作文件、无限草稿很多人靠这个就能干活。但随着团队扩张席位费用是按编辑者数量线性增长的。一个 10 人团队如果设计、产品、前端都要编辑权限一年下来的订阅成本是实打实的预算项。我帮一个朋友的小团队算过一笔账8 个编辑席位按年付加上偶尔要用的高级功能一年支出接近五位数人民币。这笔钱对成熟公司不算什么但对刚起步的团队、或者预算被砍的部门来说就值得重新评估了。开源工具的核心吸引力就在这里——软件本身零授权成本你付出的主要是服务器和运维时间。但这里有个常见的误区很多人以为开源免费。实际上自托管方案的成本要拆开看成本项Figma 订阅制自托管开源方案软件授权按席位年付0服务器0厂商承担云主机或自有硬件约每月几十到几百元运维人力0部署、升级、备份、故障处理学习成本低中到高数据掌控厂商服务器完全自主所以真正的对比不是付费 vs 免费而是付钱买省心 vs 花时间换掌控。这个取舍没有标准答案取决于你的团队里有没有人愿意且能够承担运维。2.2 数据主权与合规诉求设计资产也是资产第二个推动力是数据归属。设计文件里往往包含未发布的产品界面、品牌规范、用户流程这些在某种程度上比代码还敏感。把设计资产放在第三方服务器上对很多有合规要求的团队来说是个需要评估的风险点。自托管方案在这里的优势很直接文件存在你自己的服务器上访问权限、备份策略、数据导出全部由你控制。我接触过几个做企业级产品的团队他们的法务或安全部门明确要求核心设计资产不能放在外部 SaaS 上这种情况下开源自托管几乎是唯一选择。不过要提醒一句自托管不等于自动安全。你自己搭的服务器如果配置不当、没有 HTTPS、没有访问控制风险可能比成熟的商业服务还高。数据主权的前提是你有能力把安全做好这一点后面会详细讲。2.3 开源生态的成熟从能用到好用的临界点几年前开源设计工具的问题是功能差太多画个复杂界面都费劲。但这两年情况变了。Penpot 已经支持组件、变体、自动布局他们叫 Flex Layout 和 Grid Layout、原型交互、设计令牌日常 UI 设计工作流基本能覆盖。OpenPencil 这类工具则走轻量路线适合快速画线框和简单界面。更关键的是文件格式。Penpot 用的是开放的 SVG 和自身格式导出、迁移相对透明。这一点对担心被锁定的团队很重要——你的设计资产不会因为某家公司改政策就取不出来。我在实测中发现开源工具真正追平商业工具的地方是基础设计能力差距主要在协作体验的细节和插件生态上。比如实时多人协作的流畅度、评论和审批流、第三方插件数量这些开源方案还在追赶。所以选型时要分清你团队的核心痛点到底是功能不够还是成本和数据。3. 主流开源设计工具横向拆解3.1 Penpot目前最接近开源版 Figma的选择Penpot 是我投入时间最多的一个。它的定位很明确——面向团队的开源设计与原型工具支持自托管。技术栈上前端是 ClojureScript后端也是 Clojure数据库用 PostgreSQL对象存储可以用本地文件系统或 S3 兼容服务。它的核心能力包括组件与变体支持主组件、实例、变体切换逻辑和 Figma 类似但操作习惯需要适应。布局系统Flex Layout 对应自动布局Grid Layout 对应网格参数命名和 Figma 不同但概念相通。设计令牌原生支持颜色、字体、间距等令牌对做设计系统很友好。原型交互支持页面跳转、覆盖层、滚动等基础交互。实时协作多人同时编辑光标和选区可见。我实测下来Penpot 做中等复杂度的后台界面、移动端页面完全没问题。复杂插画和大量位图处理会吃力一些但这类工作本来也不该全压在设计工具里。3.2 OpenPencil轻量路线的取舍OpenPencil 走的是另一条路更偏向轻量、快速、低门槛。它适合画线框图、简单界面、快速原型启动快、依赖少。如果你的需求是快速把想法画出来给团队看而不是维护一套长期演进的设计系统这类工具反而更顺手。但轻量也意味着功能边界明显组件系统、复杂布局、设计令牌这些能力相对弱。我一般把它定位成个人快速草图工具而不是团队主力设计平台。3.3 自托管这件事门槛到底在哪自托管是这波讨论里出现频率最高的词之一。很多人一听自己搭服务器就头大其实要分情况看。如果你只是个人用最省事的方式是用 Docker 在本地或一台小云主机上跑起来。Penpot 官方提供了 Docker Compose 配置基本是拉镜像、改几个环境变量、启动三步。我第一版就是这么跑的一台 2 核 4G 的云主机足够几个人用。如果是团队用要考虑的东西就多了域名和 HTTPS、反向代理、数据库备份、对象存储、升级策略、监控告警。这部分确实需要有人懂运维或者至少愿意学。我的建议是团队自托管前先问三个问题谁负责部署、谁负责升级、出故障谁处理。如果这三个问题没有明确答案先别急着上。4. 从 Figma 迁移到开源工具的真实操作路径4.1 迁移前的资产盘点别一上来就搬文件我见过太多人一冲动就把 Figma 文件往新工具里导结果一团乱。正确的第一步是盘点不是迁移。你需要先搞清楚自己有多少资产、哪些是活的、哪些是死的。我的做法是建一张表把文件按类型和状态分类资产类型是否迁移迁移优先级备注活跃产品设计文件是高正在迭代的优先迁设计系统/组件库是最高迁移难度最大先做历史归档文件否低留在原处只读即可一次性草图/废弃稿否无直接放弃品牌规范文档视情况中可转成令牌或文档盘点的目的是避免为了迁移而迁移。很多历史文件你根本不会再打开搬过去只是增加维护负担。4.2 设计系统迁移最硬的一块骨头组件库是迁移中最麻烦的部分。Figma 的组件、变体、自动布局和 Penpot 的组件、变体、Flex/Grid 布局概念相似但实现细节不同没法一键完美转换。我的实操路径是这样的先迁基础样式颜色、字体、间距、圆角、阴影这些先转成 Penpot 的设计令牌。令牌是后面所有组件的基础必须先立住。再迁原子组件按钮、输入框、标签、图标这类最小单元手动重建。数量不多但复用率最高值得花时间做扎实。然后迁复合组件卡片、表单、导航栏基于原子组件拼装。最后处理变体把 Figma 的变体逻辑在 Penpot 里用组件变体重建注意状态命名要统一。这个过程我实测下来一个中等规模的设计系统约 80 个组件大概需要 2 到 3 个工作日。听起来不多但前提是你对两边的工具都熟。如果团队里没人熟 Penpot时间要翻倍。注意不要试图用第三方转换脚本一键迁移组件库。我试过几个结果都是样式丢失、层级错乱后期修复的时间比手动重建还长。基础样式和原子组件老老实实手动做反而最快。4.3 字体与中文显示容易被忽略的坑字体是迁移里特别容易翻车的地方。Figma 的字体管理和 Penpot 不一样尤其是中文字体。我在自托管 Penpot 时遇到的第一个问题就是中文字体显示异常。原因是服务器上没有安装对应字体浏览器端渲染时回退到了默认字体导致排版全乱。解决办法是在服务器上安装字体或者用 Web Font 方式引入。具体操作上如果你用 Docker 部署可以在镜像里加一层安装字体的步骤把常用的中文字体比如思源黑体、思源宋体这类开源字体装进去。这样团队所有人打开文件看到的都是同一套字体不会出现我这边正常你那边乱码的情况。另外提醒一点商用字体要注意授权。自托管环境下字体是装在你自己的服务器上的但授权范围仍然要遵守字体厂商的规定。开源字体在这点上省心很多团队项目我一般优先推荐开源字体。4.4 文件导入导出的现实预期Penpot 支持导入 Figma 文件通过 .fig 格式但别期待完美还原。我实测的体验是基础图层、颜色、文本能进来但组件关系、自动布局、复杂效果大概率会丢或变形。所以我的建议是把导入功能当成参考而不是迁移。你可以把 Figma 文件导进来对照着重建但不要指望导进来就能直接用。真正靠谱的迁移还是手动重建关键资产。导出方面Penpot 支持导出 SVG、PNG、PDFSVG 导出质量不错给前端切图用基本够。这一点比某些工具强SVG 是开放格式后续处理灵活。5. 自托管部署实操与避坑指南5.1 最小可用部署Docker Compose 三步走如果你只是想先跑起来看看用 Docker Compose 是最快的。Penpot 官方仓库里有现成的 compose 文件核心是三个服务前端、后端、PostgreSQL。对象存储可以先用本地卷规模大了再换 S3 兼容服务。大致流程是# 1. 拉取官方 compose 配置 git clone https://github.com/penpot/penpot.git cd penpot/docker/images # 2. 准备环境变量文件设置域名、密钥、数据库密码 cp .env.example .env # 编辑 .env至少改 PENPOT_PUBLIC_URI、数据库密码、密钥 # 3. 启动 docker compose -f docker-compose.yaml up -d启动后访问你配置的域名或 IP 加端口就能看到登录页。第一次跑起来大概几分钟取决于镜像拉取速度。这里有几个环境变量必须改不能偷懒用默认值PENPOT_PUBLIC_URI你的访问地址写错会导致资源加载失败。数据库密码默认密码是公开的必须改。密钥相关变量用于会话和加密必须换成随机值。5.2 生产环境必须补上的几件事最小部署能跑但离能放心给团队用还差几步。我踩过的坑主要集中在下面这些地方。第一HTTPS 和反向代理。直接用 IP 加端口访问浏览器会各种警告而且不安全。标准做法是前面挂一个 Nginx 或 Caddy 做反向代理配好证书。Caddy 的好处是自动申请和续期证书配置也简单我个人更推荐。第二数据库备份。自托管最大的风险就是数据丢失。PostgreSQL 要配定期备份最好异地存一份。我用的方案是每天定时 dump 数据库同步到另一台机器或对象存储。备份脚本要测试恢复流程不然真出事时发现备份是坏的那就白搭了。第三对象存储。本地卷在小规模下能用但文件多了、多人并发上传时容易出问题。规模上来后换成 S3 兼容的对象存储比如 MinIO 自建或云厂商的对象存储服务稳定性和扩展性都好很多。第四升级策略。开源项目迭代快升级前一定要看 release notes注意数据库迁移说明。我的习惯是先在测试环境升一遍确认没问题再动生产。升级前手动备份一次数据库这是底线。5.3 权限与协作配置团队用的话权限配置不能马虎。Penpot 支持团队、项目、文件多级权限要提前规划好谁能编辑、谁只能查看、谁能管理成员。我的经验是权限宁紧勿松。一开始就给所有人编辑权限后期文件一多谁改了什么根本说不清。建议按角色分设计师编辑权限产品和前端查看加评论权限外部协作者单独开临时权限。另外自托管环境下账号体系是自己管的没有第三方登录的便利。如果团队人多可以考虑对接内部的身份系统但这属于进阶需求小团队手动管理账号也够用。6. 常见问题与排查技巧实录6.1 部署与运行类问题自托管过程中遇到的问题八成集中在部署和运行环节。我把高频问题整理成一张速查表现象可能原因排查方向页面打不开或白屏反向代理配置错误、URI 不匹配检查 PENPOT_PUBLIC_URI 和代理转发规则上传文件失败对象存储未配置或权限不足检查存储配置和磁盘空间中文字体显示异常服务器缺字体在镜像中安装开源中文字体协作光标不同步WebSocket 未正确代理检查代理是否转发 WebSocket升级后报错数据库未迁移查看 release notes执行迁移步骤登录后频繁掉线密钥配置不一致检查多实例间密钥是否统一这张表是我实际遇到并解决过的问题汇总基本覆盖了新手自托管 80% 的坑。6.2 设计工作流类问题工具层面的问题解决了工作流层面还有一批坑。组件变体命名混乱是最常见的。Figma 里大家习惯随意命名迁到 Penpot 后如果还这样组件库很快就没法维护。我的做法是迁移时强制统一命名规范比如组件名/状态/尺寸这种结构一次性理顺。自动布局转换后错位也很常见。Figma 的自动布局和 Penpot 的 Flex Layout 参数逻辑不同转换后经常需要手动调。建议迁移时逐个检查别批量处理。设计令牌和组件脱节是进阶问题。令牌改了组件没跟着更新导致样式不一致。Penpot 的令牌绑定机制需要手动维护团队里要约定好改令牌必须同步检查组件。6.3 独家避坑心得分享几个文档里不会写、但实际很关键的经验。第一先小范围试点别全团队一刀切。我建议先让一两个设计师用开源工具做一个真实项目跑通完整流程再决定要不要推广。试点阶段暴露的问题比全团队迁移后才发现要划算得多。第二保留 Figma 作为过渡。迁移不是一夜之间的事。我自己的做法是核心新项目用开源工具历史项目和紧急交付继续用 Figma等开源工具用顺了再逐步切换。这样风险可控。第三把运维当成项目的一部分。很多团队低估了自托管的运维投入。部署只是开始后面的升级、备份、监控、故障处理才是长期成本。如果团队里没人愿意长期负责这块自托管方案要慎重。第四文档要跟上。自托管工具没有官方客服遇到问题只能靠社区和自己。团队内部要维护一份部署文档、故障处理手册、常用操作指南新人来了能快速上手。7. 到底该不该换一份决策参考聊了这么多回到最初的问题。我不打算给你一个非黑即白的答案而是给一套判断框架。适合考虑开源自托管的情况团队有明确的成本压力或数据合规要求团队里有懂运维或愿意学运维的人设计工作流以 UI 和组件为主不依赖大量第三方插件能接受协作体验上的一些妥协。建议继续用 Figma 的情况团队规模小、预算不敏感设计工作流高度依赖插件生态没有运维人力也不想投入对实时协作流畅度要求极高。折中方案核心资产和敏感项目用自托管开源工具日常协作和对外交付继续用 Figma。这种混合模式我实测下来最现实既拿到了数据掌控和成本优势又保留了成熟工具的便利。我个人现在的状态就是混合使用设计系统和核心产品文件放在自托管的 Penpot 上快速草图和对外协作还是用 Figma。踩过几次坑之后我发现工具选型从来不是哪个更好的问题而是哪个更适合你当前阶段的问题。开源工具这两年进步很快值得认真评估但也没必要为了开源而开源。先把你的真实需求列清楚再对照着选比听任何人的结论都靠谱。
