企业官网建设流程全解析

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 的官方云端版本，或者找一家提供托管服务的供应商。自托管的隐性成本主要在运维上，不是搭起来就完事了。

下面这张表是我对三个方案的核心对比，基于实际使用体验整理：

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/penpot

5.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_FLAGS=enable-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_KEY=your-secret-key-here - PENPOT_PUBLIC_URI=http://your-domain.com:9001 - PENPOT_DATABASE_URI=postgresql://penpot:penpot@penpot-postgres/penpot - PENPOT_DATABASE_USERNAME=penpot - PENPOT_DATABASE_PASSWORD=penpot - PENPOT_REDIS_URI=redis://penpot-redis/0 - PENPOT_ASSETS_STORAGE_BACKEND=assets-fs - PENPOT_STORAGE_ASSETS_FS_DIRECTORY=/opt/data/assets - PENPOT_TELEMETRY_ENABLED=false penpot-exporter: image: penpotapp/exporter:latest restart: always environment: - PENPOT_PUBLIC_URI=http://penpot-frontend - PENPOT_REDIS_URI=redis://penpot-redis/0 penpot-postgres: image: postgres:15 restart: always volumes: - penpot_postgres:/var/lib/postgresql/data environment: - POSTGRES_INITDB_ARGS=--data-checksums - POSTGRES_DB=penpot - POSTGRES_USER=penpot - POSTGRES_PASSWORD=penpot 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_ENABLED=false是关闭遥测数据上报，如果你在意隐私可以关掉。数据库密码建议改掉默认的penpot，虽然在内网环境风险不大，但好习惯要养成。

5.3 反向代理与 HTTPS 配置

直接用 IP 加端口访问体验很差，而且没有 HTTPS 不安全。我建议用 Nginx 做反向代理，配合 Let's 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 常见问题速查表

7. 我的实际迁移体会与后续扩展思路

迁移到 Penpot 之后，我们团队的实际感受是：前两周最痛苦，一个月后基本适应，三个月后回不去了。痛苦主要来自习惯的改变：快捷键不一样、插件不够用、偶尔的卡顿让人烦躁。但适应之后，我们发现一些之前没意识到的好处。比如，自托管之后，设计文件的访问速度反而更快了，因为服务器就在公司内网。再比如，我们可以自由地定制 Penpot 的界面和功能，虽然改动不大，但心理上感觉工具是自己的。

成本方面，第一年确实没有省多少钱，服务器费用加上迁移时间，和 Figma 的订阅费差不多。但从第二年开始，边际成本几乎为零，而且团队规模越大，优势越明显。数据主权方面，安全团队再也没有追问过设计稿的存储问题，这一点对做企业级产品的团队来说很重要。

后续我打算做两件事：一是把 Penpot 的插件系统研究透，看看能不能自己写几个内部插件，比如自动生成设计规范、对接内部项目管理工具。二是探索 Penpot 的 API，看看能不能把设计稿和前端代码仓库打通，实现设计变更自动触发前端构建。这些想法还在早期阶段，等有成果了再分享。

如果你也在考虑迁移，我的建议是：先小范围试点，再全面推广。找一个不太紧急的项目，让设计和前端一起用 Penpot 走一遍完整流程，收集反馈，解决问题，再决定是否推广到整个团队。不要一上来就全员迁移，那样风险太大。另外，迁移过程中一定要保留 Figma 的订阅至少三个月，作为过渡期的备份方案。等团队完全适应了，再考虑取消。