企业官网建设流程全解析

1. 设计工具选型的十字路口

最近半年，我所在的几个设计群、前端群、独立开发者社区里，关于"要不要从 Figma 迁走"的讨论明显变多了。触发点很集中：订阅价格调整、团队席位计费方式变化、以及一部分人对"设计资产到底放在谁家服务器上"这件事越来越在意。与此同时，Penpot、OpenPencil 这类开源设计工具被反复提起，"自托管"这个词也从运维圈渗透到了设计师的日常聊天里。

我自己是从 2019 年开始重度使用 Figma 的，做过组件库、设计系统、多人协作项目，也踩过插件崩溃、字体缺失、文件权限混乱的坑。2023 年底我开始认真评估开源替代方案，把 Penpot 自托管跑起来，也试了 OpenPencil 这类偏轻量的工具，前后折腾了小半年。这篇文章不是要给你一个"必须换"或者"千万别换"的结论，而是把我评估过程中真正关心的维度、实测下来的体验、以及那些文档里不会写的坑，完整摊开讲一遍。

如果你正在纠结这个问题，先明确一下这篇文章适合谁看：一是中小团队的设计负责人，需要算清楚成本和迁移代价；二是独立开发者或自由设计师，想找一个不依赖订阅、数据自己掌控的方案；三是对自托管感兴趣、但不确定技术门槛有多高的设计师。我会尽量把技术部分讲得让非运维背景的人也能看懂，同时把设计工作流的部分讲得让工程师也能理解。

先说一个我自己的判断："放弃 Figma"这个说法本身有点极端。更现实的问法是——你的团队在什么阶段、什么规模、什么合规要求下，应该把哪一部分工作流迁移到开源工具上。全量替换和部分并行，是完全不同的两件事，代价也差得很远。

2. 为什么大家开始认真考虑开源设计工具

2.1 成本结构的变化：从"够用就行"到"按人头算账"

早期 Figma 的免费额度对个人和小团队非常友好，三个协作文件、无限草稿，很多人靠这个就能干活。但随着团队扩张，席位费用是按编辑者数量线性增长的。一个 10 人团队，如果设计、产品、前端都要编辑权限，一年下来的订阅成本是实打实的预算项。

我帮一个朋友的小团队算过一笔账：8 个编辑席位，按年付，加上偶尔要用的高级功能，一年支出接近五位数人民币。这笔钱对成熟公司不算什么，但对刚起步的团队、或者预算被砍的部门来说，就值得重新评估了。开源工具的核心吸引力就在这里——软件本身零授权成本，你付出的主要是服务器和运维时间。

但这里有个常见的误区：很多人以为"开源=免费"。实际上自托管方案的成本要拆开看：

所以真正的对比不是"付费 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 布局，概念相似但实现细节不同，没法一键完美转换。

我的实操路径是这样的：

1. 先迁基础样式：颜色、字体、间距、圆角、阴影，这些先转成 Penpot 的设计令牌。令牌是后面所有组件的基础，必须先立住。
2. 再迁原子组件：按钮、输入框、标签、图标这类最小单元，手动重建。数量不多但复用率最高，值得花时间做扎实。
3. 然后迁复合组件：卡片、表单、导航栏，基于原子组件拼装。
4. 最后处理变体：把 Figma 的变体逻辑在 Penpot 里用组件变体重建，注意状态命名要统一。

这个过程我实测下来，一个中等规模的设计系统（约 80 个组件）大概需要 2 到 3 个工作日。听起来不多，但前提是你对两边的工具都熟。如果团队里没人熟 Penpot，时间要翻倍。

注意：不要试图用第三方转换脚本一键迁移组件库。我试过几个，结果都是样式丢失、层级错乱，后期修复的时间比手动重建还长。基础样式和原子组件老老实实手动做，反而最快。

4.3 字体与中文显示：容易被忽略的坑

字体是迁移里特别容易翻车的地方。Figma 的字体管理和 Penpot 不一样，尤其是中文字体。

我在自托管 Penpot 时遇到的第一个问题就是中文字体显示异常。原因是服务器上没有安装对应字体，浏览器端渲染时回退到了默认字体，导致排版全乱。解决办法是在服务器上安装字体，或者用 Web Font 方式引入。

具体操作上，如果你用 Docker 部署，可以在镜像里加一层安装字体的步骤，把常用的中文字体（比如思源黑体、思源宋体这类开源字体）装进去。这样团队所有人打开文件看到的都是同一套字体，不会出现"我这边正常你那边乱码"的情况。

另外提醒一点：商用字体要注意授权。自托管环境下，字体是装在你自己的服务器上的，但授权范围仍然要遵守字体厂商的规定。开源字体在这点上省心很多，团队项目我一般优先推荐开源字体。

4.4 文件导入导出的现实预期

Penpot 支持导入 Figma 文件（通过 .fig 格式），但别期待完美还原。我实测的体验是：基础图层、颜色、文本能进来，但组件关系、自动布局、复杂效果大概率会丢或变形。

所以我的建议是：把导入功能当成"参考"而不是"迁移"。你可以把 Figma 文件导进来对照着重建，但不要指望导进来就能直接用。真正靠谱的迁移还是手动重建关键资产。

导出方面，Penpot 支持导出 SVG、PNG、PDF，SVG 导出质量不错，给前端切图用基本够。这一点比某些工具强，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 部署与运行类问题

自托管过程中遇到的问题，八成集中在部署和运行环节。我把高频问题整理成一张速查表：

这张表是我实际遇到并解决过的问题汇总，基本覆盖了新手自托管 80% 的坑。

6.2 设计工作流类问题

工具层面的问题解决了，工作流层面还有一批坑。

组件变体命名混乱是最常见的。Figma 里大家习惯随意命名，迁到 Penpot 后如果还这样，组件库很快就没法维护。我的做法是迁移时强制统一命名规范，比如"组件名/状态/尺寸"这种结构，一次性理顺。

自动布局转换后错位也很常见。Figma 的自动布局和 Penpot 的 Flex Layout 参数逻辑不同，转换后经常需要手动调。建议迁移时逐个检查，别批量处理。

设计令牌和组件脱节是进阶问题。令牌改了，组件没跟着更新，导致样式不一致。Penpot 的令牌绑定机制需要手动维护，团队里要约定好"改令牌必须同步检查组件"。

6.3 独家避坑心得

分享几个文档里不会写、但实际很关键的经验。

第一，先小范围试点，别全团队一刀切。我建议先让一两个设计师用开源工具做一个真实项目，跑通完整流程，再决定要不要推广。试点阶段暴露的问题，比全团队迁移后才发现要划算得多。

第二，保留 Figma 作为过渡。迁移不是一夜之间的事。我自己的做法是核心新项目用开源工具，历史项目和紧急交付继续用 Figma，等开源工具用顺了再逐步切换。这样风险可控。

第三，把运维当成项目的一部分。很多团队低估了自托管的运维投入。部署只是开始，后面的升级、备份、监控、故障处理才是长期成本。如果团队里没人愿意长期负责这块，自托管方案要慎重。

第四，文档要跟上。自托管工具没有官方客服，遇到问题只能靠社区和自己。团队内部要维护一份部署文档、故障处理手册、常用操作指南，新人来了能快速上手。

7. 到底该不该换：一份决策参考

聊了这么多，回到最初的问题。我不打算给你一个非黑即白的答案，而是给一套判断框架。

适合考虑开源自托管的情况：团队有明确的成本压力或数据合规要求；团队里有懂运维或愿意学运维的人；设计工作流以 UI 和组件为主，不依赖大量第三方插件；能接受协作体验上的一些妥协。

建议继续用 Figma 的情况：团队规模小、预算不敏感；设计工作流高度依赖插件生态；没有运维人力，也不想投入；对实时协作流畅度要求极高。

折中方案：核心资产和敏感项目用自托管开源工具，日常协作和对外交付继续用 Figma。这种混合模式我实测下来最现实，既拿到了数据掌控和成本优势，又保留了成熟工具的便利。

我个人现在的状态就是混合使用：设计系统和核心产品文件放在自托管的 Penpot 上，快速草图和对外协作还是用 Figma。踩过几次坑之后我发现，工具选型从来不是"哪个更好"的问题，而是"哪个更适合你当前阶段"的问题。开源工具这两年进步很快，值得认真评估，但也没必要为了开源而开源。先把你的真实需求列清楚，再对照着选，比听任何人的结论都靠谱。