项目经理必看：2026年精选5大jQuery工作流设计器，哪个最适合你？

《项目经理必看：2026年精选5大jQuery工作流设计器，哪个最适合你？》这个问题里，最容易踩的坑不是选错画布，而是把“能拖节点、能连线”误当成“能设计并运行工作流”。我在做前端方案评审时，通常先问团队两个问题：你们要画的是自由流程图，还是符合 BPMN 规范的业务流程？保存之后，流程只是展示，还是要交给后端执行？这两个答案，往往比“是不是 jQuery 插件”更能决定选型。

项目经理必看：2026年精选5大jQuery工作流设计器，哪个最适合你？

一、核心结论：先选工作流类型，再选设计器

1. 五个候选不是五个同类产品

先说结论：如果你的项目已经深度使用 jQuery，且只需要做一个轻量、可编辑的流程图，优先试用 jquery.flowchart.js；如果重点是节点拖放和连线控制，评估 jsPlumb；如果要长期维护复杂的自定义图形，关注 JointJS；如果商业项目需要成熟的图形交互能力，可以评估 GoJS；如果目标是标准业务流程建模，应从 bpmn-js 开始。

这五个候选的技术定位并不相同。jquery.flowchart.js 是 jQuery 插件；jsPlumb、JointJS、GoJS 和 bpmn-js 都可以嵌入 jQuery 页面，但不应被称为“原生 jQuery 工作流插件”。把这一点说清楚，比凑出五个名字更重要，因为它决定依赖、维护和后续升级方式。

我的核心判断是：jQuery 只是页面技术栈，不是工作流建模标准。一个设计器能否满足业务需求，主要看数据模型、连接规则、校验能力、保存格式、后端执行衔接和维护状态，而不只是看它能否在 jQuery 页面里运行。

需要注意，表中的“适合”是选型入口，不是性能排名。不同产品的许可证、功能分层和维护情况会变化，正式采购或上线前应查看项目官网、仓库和当前版本说明，并用自己的流程样本验证。仅凭“免费”“开源”或演示页面流畅，无法判断其是否适合生产环境。

2. 如果只记住一条选型原则

先把“设计器负责什么”写成一句话，再开始看产品。比如：“业务人员需要绘制符合 BPMN 2.0 的审批流程，导出标准模型，由后端引擎执行。”这句话指向 bpmn-js 加后端执行组件；如果需求是“管理员在页面上画服务依赖关系”，则应优先考察图形库，而不必套用 BPMN。

相反，如果需求描述只有“我们想要一个能拖拽节点的工作流设计器”，那还不具备选型条件。节点种类、连接限制、流程发布方式、版本回滚和执行日志都没有定义，任何演示看起来都可能合适，接入后却会发现业务规则全靠项目组补写。

二、背景和真实场景：为什么 jQuery 项目还在找流程设计器

1. 旧系统改造时，前端栈通常不能一次换完

许多企业系统仍有大量 jQuery 页面：审批后台、运维门户、配置管理页、内部报表系统。它们可能经过多年维护，页面模板、权限校验、弹窗、表单和后端接口都围绕现有架构构建。团队想新增流程画布，却不一定有预算把整个前端重写成现代框架。

这时真正的问题并不是“能不能在 jQuery 里调用新库”，而是引入之后谁负责状态、事件和组件生命周期。一个现代图形库即使可以通过脚本加载，也可能需要独立管理画布状态、销毁实例、同步旧页面表单、处理异步接口，以及避免全局变量冲突。

我会把这类接入拆成三个边界：第一，图形库负责画布和交互；第二，应用层负责业务规则和数据转换；第三，服务端负责权限、持久化与流程执行。边界越清楚，未来替换画布或升级页面技术栈时，返工就越少。

2. “流程设计器”至少有三种不同含义

第一种是流程图编辑器。用户把矩形、判断节点和箭头拖到画布上，主要需求是可视化表达和保存。对于这类需求，轻量插件或图形库可能足够，没必要因为名字带“工作流”就引入完整 BPMN 体系。

第二种是业务流程建模器。它需要节点类型、网关、事件、泳道、变量、表单绑定、角色权限和模型校验。此时画面只是入口，标准化数据模型与约束机制才是核心。自由连线如果没有规则，用户可以画出无法解释或无法运行的流程。

第三种是流程运行平台。除了建模，还要负责任务派发、状态推进、超时处理、并行分支、失败重试、审计与历史版本。前端设计器通常不承担这些职责。把设计器接到后端执行系统，才构成可运行的工作流产品。

3. jQuery 兼容不等于零改造

浏览器里的 JavaScript 库可以在不同前端栈中组合使用，但“能够加载”不代表“接入成本低”。需要核查的细节包括：是否依赖全局对象、是否使用自己的事件系统、是否能在容器尺寸变化后重绘、是否支持安全销毁、是否会覆盖页面样式，以及是否能在现有打包或静态资源策略下部署。

尤其是老系统常有全局 CSS 和多个插件共同操作 DOM。画布初始化后，如果外层弹窗尚未显示，容器宽高可能为零；如果页面局部刷新但画布实例没有销毁，重复绑定的事件可能让一次拖动触发多次保存。这些问题在产品演示中很少出现，却会在真实页面里影响稳定性。

三、拆解常见误区：漂亮演示不等于能长期用

1. 误区一：能画节点，就能做工作流

节点和连线只是视觉结构。业务流程还需要明确开始与结束条件、分支表达、循环限制、并行汇合、节点权限、输入输出变量、表单版本和异常处理。若这些概念没有进入数据模型，团队最后往往把规则写在前端事件回调里，后续改流程就要同时改界面、接口和执行逻辑。

我会要求产品或项目负责人先交付一份最小流程样本：至少包含开始节点、审批节点、条件分支、结束节点，以及一条非法连线。让候选方案现场展示“合法流程如何保存”和“非法流程如何报错”，比只看拖拽效果更有判断价值。

2. 误区二：JSON 能保存，就说明格式可靠

不同库导出的 JSON 可能只是各自的内部图形状态，包含节点位置、样式、端口等信息，却未必定义统一的业务语义。更换图形库时，如果业务规则直接依附于该 JSON，迁移就可能变成逐条重写。

在项目中，我倾向于让应用层维护独立的领域模型。例如，节点有稳定的业务类型、配置结构和版本号；画布坐标、颜色和缩放级别作为展示数据保存；连线关系转换为明确的业务引用。这样即使未来更换渲染库，业务层也不会完全依赖画布格式。

{
"schemaVersion": 1,

"nodes": [

{

"id": "review-01",

"type": "approval",

"config": {

"role": "department_owner",

"timeoutHours": 24

},

"position": {

"x": 320,

"y": 180

}

}

],

"edges": [

{

"source": "start-01",

"target": "review-01",

"condition": "always"

}

]

}

这段结构只是表达分层思路的示例，不是某个候选库的官方格式。重点是把节点业务语义与坐标等展示信息区分开，并为模型版本预留空间；具体字段应由项目的执行规则决定。

3. 误区三：开源免费就没有长期成本

采购价格只是成本的一部分。开源项目也需要评估维护活跃度、问题响应、浏览器兼容、升级迁移、内部二次开发、许可证义务和关键人员离职风险。商业产品则要额外核查授权范围、部署方式、版本升级政策和是否有运行时限制。

我建议把成本拆成“首版接入成本”和“每次变更成本”。一个看起来免费的轻量插件，首版可能一天就能显示画布；但若增加泳道、键盘无障碍、复杂校验和版本迁移都要自行实现，后续每个需求都会累积工程成本。反过来，商业库虽有授权费用，但若减少大量自研交互，也可能更经济。

4. 误区四：把 BPMN 编辑器当成流程引擎

bpmn-js 的定位是 BPMN 建模相关工具，适合在浏览器里查看或编辑 BPMN 图形。流程模型如何被校验、部署、执行、记录任务状态，仍要结合后端流程引擎和应用服务设计。采购或排期时若把“建模器已经完成”当作“流程系统已经完成”，项目进度通常会被严重低估。

同样，使用自由图形库也不意味着不能实现工作流。只是团队需要明确承担数据规范、流程校验、版本兼容和执行集成的责任。不要让“标准”或“灵活”两个词替代具体的架构评估。

四、专业判断逻辑：用六个维度筛掉不合适的候选

1. 先确定流程语义和标准要求

第一步要回答：团队需要 BPMN 2.0 这类可交换的建模标准，还是内部定义的轻量流程格式？如果流程需要与其他系统交换、由兼容的后端组件解析，优先验证标准建模工具；如果流程只是产品内的可视化配置，领域模型可能更直接。

标准不是越多越好。采用 BPMN 会增加学习、校验和建模约束，但能让流程模型有更明确的语义；自定义模型上手可能较快，但要自行管理规范和演进。选择哪一边，取决于组织是否需要跨系统协作，以及谁负责后续维护。

2. 画出最小闭环，而不是只测拖拽

我会把候选方案放进一个小型验证任务：创建节点、连线、配置节点、校验错误、保存、关闭页面、重新打开、恢复布局、导出模型，并由服务端读取关键业务字段。若任务涉及发布，再增加草稿发布、旧版本回滚和执行状态展示。

验证过程要记录的不只是“成功或失败”，还包括需要多少自定义代码、谁能维护、异常如何定位、能否写自动化测试。一个交互顺手但无法稳定恢复状态的工具，未必比一个视觉朴素但数据可控的方案更适合企业项目。

3. 把 jQuery 集成风险单列出来

在旧页面中嵌入新画布时，建议针对实际应用环境测试：弹窗打开后初始化、容器缩放、局部刷新、重复挂载、销毁实例、浏览器前进后退、权限切换和慢网速加载。若页面使用多个 jQuery 版本、旧版 UI 插件或较多全局 CSS，至少要做一轮隔离测试。

团队还要确认依赖是否可以通过当前构建链管理。若只能手工复制静态文件，应建立版本记录、来源校验和升级流程，避免开发环境与生产环境加载的库版本不一致。这个问题看起来不像选型，却会直接影响后续安全更新和排障效率。

4. 按生命周期核算工程成本

评估成本时，我会用至少三个阶段拆解：首版接入、业务变化、技术升级。首版接入关注可用性和基础功能；业务变化关注新增节点、权限、规则与模型迁移；技术升级则关注浏览器变化、依赖漏洞和库版本兼容。只看第一阶段，容易低估长期投入。

可以先以人日建立相对估算，不需要假装有精确的行业均值。关键是把各团队的假设写明，比如是否已有后端引擎、是否要实现权限与版本管理、是否要求流程模型导入导出。假设不同，估算就不能直接横向比较。

5. 为每个候选设定不可妥协项

在试用前先写出三到五项硬性条件，例如必须能够离线部署、必须支持流程模型导出、必须有明确许可证、必须能在旧页面销毁重建、必须满足键盘操作要求。不能满足硬性条件的候选应尽早淘汰，而不是因为演示效果好就继续投入。

硬性条件之外再做加权比较。比如标准化、扩展能力、jQuery 集成、维护风险、总拥有成本分别赋权。权重由项目风险决定：业务审计严格的系统应提高模型可追溯性权重；短期内部工具则可以更看重上线速度。

五、五种候选方案逐一拆解：适用点、限制与验证方法

1. jquery.flowchart.js：适合轻量流程图，不宜默认承担复杂引擎职责

jquery.flowchart.js 是五个候选中最贴近“jQuery 插件”这一称呼的方案。它更适合在已有 jQuery 页面中快速搭建节点与连线式编辑界面，用来做内部配置工具、流程草图或概念验证，尤其是团队希望先验证用户是否需要可视化编辑，而不是一开始建设完整流程平台时。

它的优势是概念直接，通常比较容易放进传统页面中试验；需要重点检查的则是项目维护状态、当前浏览器支持、复杂节点配置、模型格式、无障碍交互和大规模画布体验。对生产系统而言，不能仅凭一个可运行的示例判断它足以承担所有业务规则。

我的建议是把它定位为“轻量编辑界面候选”。先实现三种节点、两类连线、一种错误校验，再观察代码是否保持可读。如果需求很快出现泳道、并行网关、版本回滚和权限矩阵，就应重新评估架构，而不是持续往插件周围堆补丁。

2. jsPlumb：连接交互强，流程语义要由应用补齐

jsPlumb 常用于构建可视化连接界面，适合需要节点、端点、连线和拖动交互的应用。对于 jQuery 项目，它可以作为画布交互方案进行评估，但要注意它并不意味着工作流规则已经定义好。不同版本与产品形态的 API、功能范围和授权也应以当前官方资料为准。

它适合“节点和连线是核心难点，业务语义由团队控制”的场景。例如服务依赖关系、任务编排草图或内部流程配置。如果业务团队要求大量标准化流程构件、模型交换与执行闭环，单独使用连接库的自研范围会明显扩大。

验证时应测试连接约束、端点行为、节点移动后的关系稳定性、删除节点时的清理逻辑，以及画布状态如何序列化。还要检查页面局部销毁时事件监听是否正确移除。若这些工作都需要项目组从零处理，应把维护成本纳入总拥有成本。

3. JointJS：适合复杂自定义图形，前提是愿意建设领域模型

JointJS 更像一套图形与关系建模基础设施，而不是开箱即用的业务流程产品。它适合需要自定义节点形状、端口、连线表现和图形行为的团队。若产品的核心差异就在画布表达方式，或者流程对象有独特的领域结构，它可能比简单插件更有扩展空间。

相应地，团队要为建模体验投入工程能力：节点定义、校验规则、属性面板、键盘交互、保存格式、性能测试和版本演进。若只想快速做一个审批流程配置页，先评估更轻的方案可能更合理；否则容易为暂时用不到的扩展空间付出过多开发成本。

评估时不要只看自定义图形演示，而要把真实业务节点放进去，检查属性编辑如何组织、不同节点类型能否稳定区分、模型升级是否可控，以及开发者能否写单元测试。还应区分基础库与商业扩展的功能范围，并核对许可证和支持政策。

4. GoJS：交互能力值得评估，授权和依赖要同步评估

GoJS 是成熟的图形交互库，可用于复杂图表和可视化编辑场景。它不是 jQuery 插件，但可作为独立 JavaScript 库集成到使用 jQuery 的页面中。对于希望减少画布交互自研、并且愿意评估商业授权的团队，它是值得纳入验证清单的候选。

选型时要认真核查当前授权条款、商业使用要求、部署和分发条件，以及试用版本与正式版本的差异。不要把“能在开发机跑起来”视作许可证已满足，也不要只按照授权价格比较；还要比较少写的交互代码是否真的覆盖了团队的业务需求。

验证重点应是实际工作流，而不是通用图表样例：批量节点、复杂连线、撤销重做、复制粘贴、布局恢复、导出与导入、容器缩放和旧页面兼容。若团队不熟悉其数据模型，先做小型技术验证，再讨论采购，比直接承诺长期使用稳妥。

5. bpmn-js：需要 BPMN 建模时优先验证，但不要误认为包含执行服务

bpmn-js 面向 BPMN 2.0 建模与展示，适用于需要规范化流程图、标准化语义或与 BPMN 生态衔接的项目。它不是 jQuery 依赖型插件，但可以在既有 jQuery 页面中通过合适的模块集成方式使用。选择它的理由应是“业务要 BPMN”，而不是“它看起来像工作流设计器”。

BPMN 能帮助团队表达事件、任务、网关和流程关系，但前提是产品、研发和业务人员对建模规则有基本共识。对只需要几个审批节点的内部工具，完整标准可能带来不必要的复杂度；对需要交换、审计或流程治理的组织，标准语义则可能减少各系统之间的解释歧义。

最重要的边界是：浏览器里完成 BPMN 编辑，不代表流程可以自动运行。项目仍要明确模型校验、部署接口、执行引擎、任务中心、权限、审计与错误恢复由谁提供。若团队只采购了建模器，就应把后端运行能力作为独立项目范围估算。

六、案例与数据观察：用同一个审批流程做公平对比

1. 建议用“最小但真实”的流程样本试用

假设一个企业后台要配置部门费用审批，流程包括开始、直属主管审批、金额判断、财务复核、结束，以及“退回修改”路径。样本还要包含一条不合法连接，例如让结束节点再流向普通审批节点。这样的流程不算复杂，却足以暴露数据模型、规则校验和用户引导方面的问题。

我会给每个候选相同的验证时间和同一份验收清单，不让供应商或开发人员用最熟悉的演示模板。试用者应包含一名前端工程师、一名业务产品人员和一名流程维护者，因为工程可行不代表业务人员能独立维护。

2. 记录可复核的指标，而不只凭感觉打分

至少记录五类结果：从空白画布完成样例所需时间、非法流程被发现的比例、保存后重新打开的恢复成功率、生成业务规则所需的自定义代码量，以及新增一种节点所需的人日。若要上线，还应测试导入导出、版本回滚、并发编辑和审计记录。

指标要带清楚口径。例如“完成时间”从用户打开空白编辑器开始，到流程通过校验并成功保存为止；“恢复成功率”则需比较重新打开后节点、连线、属性和版本信息是否一致。只测试节点位置还原，会高估数据可靠性。

如果试用只有一两个样本，结果适合作为项目内部的对比证据，不适合宣称为产品普遍性能。把样本、浏览器、机器环境和测试者经验记录下来，结论才有复核价值。

3. 一组排期示意：原型时间和生产时间要分开估算

对于已经有 jQuery 后台、但没有现成流程建模平台的团队，可以先估一个短期验证迭代：用少量节点确认画布嵌入、模型保存和错误提示是否可行。此阶段的目标是回答“方向值不值得继续”，而不是交付可供全组织使用的生产功能。

进入生产阶段后，排期需要增加权限、版本、并发处理、审计、执行接口、监控与回滚。项目应从范围中明确哪些由图形库提供、哪些由团队开发、哪些由后端服务承担。否则不同候选方案的工作量比较没有意义，也容易把遗漏项留到上线前集中爆发。

下面的图表采用情景模拟数据，展示从演示原型到生产闭环的投入增长方式。数字不是行业均值，也不适合作为报价依据；真正有价值的是成本分布和未覆盖职责。

七、按不同项目情况制定行动建议

1. 你只需要内部流程图或配置原型

优先控制范围，不要把“工作流平台”作为首期目标。选择一款轻量候选做小样，确保能创建、保存、重新打开和导出基本数据。将流程规则写在应用层，先验证用户是否真的需要编辑器，再决定是否增加权限、版本和复杂节点。

如果流程只由工程师维护，静态配置或受控表单有时比可视化画布更稳妥。画布带来的自由度越高，校验和支持成本通常也越高。先确认用户需要的是“看得懂”，还是“自己能改”，两者对应的产品复杂度完全不同。

2. 你的系统已经使用 jQuery，暂时不能升级前端

可以采用渐进接入策略：把设计器放进一个独立容器，尽可能通过模块边界与旧页面隔离；业务模型走稳定接口，不让画布对象直接成为全系统的数据契约；在页面销毁时释放监听和实例，并记录静态资源版本。

上线前至少验证弹窗尺寸变化、重复打开、浏览器回退、慢接口、权限变更和不同分辨率。若库依赖与旧 jQuery 版本冲突，先评估隔离加载方案和维护成本，不要用全局覆盖去快速消除错误，因为它可能引入其他页面的隐蔽故障。

3. 你的流程需要 BPMN 或与其他系统交换

先让业务与技术共同确认 BPMN 的使用边界，再以 bpmn-js 做可行性验证。验证不应止于画出图形，还要确保模型能导出、服务端能解析、规则能校验，并明确部署到哪个执行组件。若后端尚无执行能力，应把它列为独立建设范围。

同时安排一名流程建模负责人，建立节点规范、命名规则和示例流程。标准工具可以减少格式歧义，却不能替团队自动建立治理制度。没有建模规范，标准模型也可能被画成难以理解、难以维护的复杂图。

4. 你要建设组织级、多人使用的流程配置平台

不要按单个设计器组件立项，应按平台能力拆分：模型管理、权限控制、版本发布、执行服务、任务处理、通知、审计、监控和运营支持。设计器只是其中一个模块，平台的可靠性来自这些模块的闭环，而不是画布有多少种节点形状。

在中大型组织里，还要确认谁有权发布流程、是否支持测试环境、能否比较版本差异、如何处理旧流程实例，以及变更后如何通知受影响的团队。若有多个业务部门共同维护，优先建立流程治理和责任机制，再扩大编辑权限。

5. 你目前无法确定该自研还是采购

建议先做一个有时间上限的验证迭代，而不是立刻承诺完整平台。验证内容包括一条真实流程、一次模型迁移、一次非法配置拦截，以及一次页面重复挂载与销毁。迭代结束后再比较自研维护成本、商业授权与支持、开源方案的升级责任。

如果候选工具能满足画布需求，但模型格式不适配，先估算适配层成本；如果模型适配，却缺少关键交互，再评估自研交互的边界。不要因为已经写了大量代码就继续投入，早期验证的价值恰恰是及时发现不匹配。

八、不同情况下的取舍：什么时候应该选，什么时候应该放弃

1. 追求最快上线，接受功能边界清晰

若流程简单、使用人数有限、规则变化少，可以优先评估 jquery.flowchart.js 或其他轻量方案。取舍是减少首版成本，同时接受部分能力需要自行补足。要提前设定退出条件：一旦出现复杂权限、模型版本或多种分支，就重新审视是否继续扩展。

轻量方案不意味着随意保存。即使是内部原型，也应保存模型版本并实现基本校验，否则两个月后新增需求时，团队可能无法判断已有数据能否继续读取。

2. 追求图形自由度，愿意承担定制开发

若流程图形本身就是产品能力，且业务对象有特别的节点、端口和交互，jsPlumb 或 JointJS 一类基础库值得验证。好处是建模方式可控，代价是团队需要承担更多规则、测试和维护。

取舍的关键不是“库够不够强”，而是团队是否有持续建设编辑器的能力。如果没有专门维护者，定制能力越多，后续越可能变成只有原作者敢改的代码。评估结果应包含交接成本，而不是只记下开发者的主观满意度。

3. 追求成熟交互，同时接受商业依赖

若项目预算允许，且复杂画布交互对业务体验至关重要，可以评估 GoJS 等商业图形库。授权和供应商依赖并非天然缺点，但必须透明：谁负责续费、许可覆盖哪些部署环境、未来退出时数据如何迁移、遇到问题有哪些支持渠道。

采购决策不要只比较年度授权费用。还应估算自研替代交互的人日、升级风险、缺陷修复周期和团队培训成本。把这些因素放在一起，才能比较总拥有成本；只拿开源“零许可费”对比商业报价，结论通常不完整。

4. 追求流程标准化，接受学习和治理成本

若组织需要跨系统交换流程、明确业务语义，或要建立统一建模治理，应认真评估 bpmn-js 等 BPMN 建模工具。它的代价是培训、规范制定、模型校验和后端集成；若这些投入没有预算，仅使用标准图形编辑器也不会自动带来标准化收益。

当流程只是简单的线性审批，业务人员并不需要理解复杂建模概念时，自定义轻量模型可能更容易维护。应以实际的协作、交换和治理需求决定是否采用标准，而不是把“标准”当作项目先进性的标签。

5. 无论选择哪种方案，都不要省略迁移预案

在第一版就约定模型版本、导出格式和最低限度的迁移策略。即使暂时不会更换库，也应把画布展示状态与业务语义分开保存。这样未来更换图形组件、升级 jQuery 页面或迁移到其他前端架构时，至少有机会保留业务模型。

还要准备一个退出问题的答案：如果维护者停止更新、授权条件改变或浏览器兼容性出现问题，团队怎样导出数据、转换模型并维持已发布流程运行？没有退出方案的选型，不是节省成本，而是把成本推迟到最难处理的时候。

九、结论：别问哪个设计器最强，问谁对流程全生命周期负责

1. 最终选择建议

如果你要的是 jQuery 页面里的轻量流程图，先试 jquery.flowchart.js；如果画布连接交互是核心，评估 jsPlumb；如果要构建高度定制的图形模型，评估 JointJS；如果需要丰富的图形交互并能接受商业授权，评估 GoJS；如果业务明确要求 BPMN 建模和标准化，再验证 bpmn-js。

这不是从第一名排到第五名的榜单。五种方案解决的问题不同，单靠“是否兼容 jQuery”无法决定优劣。团队真正应该比较的是：目标流程能否表达、规则能否验证、模型能否长期演进、旧页面能否稳定集成，以及后端能否执行和审计。

2. 下一步怎么做

你可以在本周完成三个动作：先写清流程属于流程图、业务建模还是运行平台；再拿一条真实审批流程做候选验证；最后记录接入代码量、模型恢复结果、规则校验覆盖和全生命周期责任人。评估结论要写明测试环境和假设，避免把一次演示结果误当成长期保证。

我最看重的选型信号，不是画布有多炫，而是流程编辑器能不能把业务规则说清楚，并让团队在两年后仍有办法维护它。如果项目还没回答谁管理模型、谁负责执行、谁处理版本升级，那么先补齐这些答案，再决定用哪个设计器，通常比立刻选库更省时间。