PlantUML 所见即所得编辑器：图表能否拖放？

PlantUML 本身是一种从文本生成图表的语言，而不是可自由定位的绘图画布。某个编辑器可以添加实时预览、表单、代码片段或拖放交互，但这些是编辑器功能，并非 PlantUML 格式所保证的能力。

评估“PlantUML 所见即所得编辑器”时，这一区别至关重要。你需要的是实时渲染、直接移动节点、双向源代码同步，还是仅仅希望更快插入语法？如需用于测试候选编辑器的示例，请参阅 PlantUML 示例指南。

OnUML 在其图表编辑器中直接体现了这一边界：PlantUML 模式是由源代码生成并预览图表的文本驱动工作流，因此不能在渲染画布上拖动 PlantUML 元素。如果需要直接操作，请切换到 draw.io 模式，在画布上添加、移动和拖放图表形状。

要点总结

PlantUML 源代码描述元素和关系；渲染器负责计算布局。

“所见即所得”可能指实时预览、属性面板或真正可拖动的画布，使用前应明确具体含义。

只有编辑器能够保留或重新生成易于理解的 PlantUML 源代码，拖动元素才真正有价值。

文本优先编辑适合源代码评审和可重复变更；可视化编辑适合探索和空间调整。

OnUML 不会将 PlantUML 源代码转换为 draw.io XML，也不会将 draw.io 修改转换回 PlantUML。

最后更新： 2026 年 7 月 29 日。编辑器能力会发生变化，请根据产品当前版本核实相关说明。

了解 PlantUML 编辑器

PlantUML 是所见即所得格式吗？

不是。PlantUML 的官方模式是根据简单、易读的文本生成图表。PlantUML 首页和入门指南介绍的是以 @startuml 和 @enduml 为边界的源代码，而不是基于坐标的画布格式。

编辑器仍然可以通过类似所见即所得的界面呈现这种格式。该标签描述的是编辑体验，而不是底层语言。

可以拖放 PlantUML 图表元素吗？

这不是语言级操作。PlantUML 的常规建模原语不会存储“将这个框移动到 x=420, y=180”。第三方编辑器可以将拖动转换为关系方向、隐藏约束、顺序或重新生成的源代码。

某些第三方工具声称支持 PlantUML 双向往返，但 OnUML 的两个模式并非如此。在 OnUML 中：

PlantUML 模式接受 PlantUML 文本并渲染预览。
draw.io 模式使用 draw.io 自己的 XML 图表格式，支持直接画布编辑。
切换模式不会把当前 PlantUML 源代码转换成可拖动的 draw.io 形状。
在 draw.io 中编辑不会重新生成 PlantUML 源代码。

请根据所需产物选择模式，不要期待两者之间能自动往返转换。

实时预览提供什么能力？

实时预览会在你输入源代码时进行渲染，通常显示在编辑器旁边的窗格中。它缩短了反馈周期，但不会让预览本身变得可直接编辑。

@startuml
actor User
participant Browser
participant API

User -> Browser: Submit form
Browser -> API: POST /orders
API --> Browser: 201 Created
Browser --> User: Show confirmation
@enduml

将该示例粘贴到编辑器中，调整参与者顺序并观察预览。这个测试可以区分响应式渲染与真正的画布编辑。

官方 Web 编辑器与第三方集成是否相同？

不同。PlantUML 提供官方 Web 编辑器，还记录了许多运行环境和集成。每种前端都可以实现不同的存储、预览、导出、协作和导航行为。

不要因为某项功能在一个集成中可用，就推断所有集成都支持它。

选择合适的编辑模式

何时最适合使用文本优先的 PlantUML 编辑器？

图表结构需要保持可读、可重复时，文本优先编辑器最合适。源代码别名、引用、宏和一致渲染更容易显式管理。

非常适合：

维护文本优先图表的开发者
使用自动化构建的文档团队
复用主题和标准库宏的架构师

不太适合：

参与者需要自由草绘的研讨会
像素级演示布局
无法检查或维护生成源代码的用户

源代码准备完成后，请按照 PlantUML 导出指南下载 PNG/SVG 并保存 OnUML 项目。

何时应选择可视化编辑器？

如果需要快速进行空间探索、自由白板绘制，或用户习惯直接操作形状，可视化编辑器更合适。如果必须导出 PlantUML，请确认导出结果是整洁、可编辑的源代码，而不是扁平化图片。

需求	文本优先编辑器	可视化画布	混合编辑器
可评审的源代码变更	强	通常较弱	取决于生成的源代码
直接移动节点	有限	强	因产品而异
可复用宏	强	有限	因产品而异
像素级控制	弱	强	中等
跨工具 PlantUML 可移植性	强	不适用	必须测试

“双向编辑”应该意味着什么？

双向编辑应该意味着源代码变更会更新画布，而可视化变更也会更新为有效且易于理解的源代码。达不到这一标准的只是预览加工具栏工作流，它仍然可能有用，但应准确描述。

请测试别名、注释、分组、主题和引用，而不只是两个框与一条箭头。

常见工作流问题

可以在可视化编辑器中使用现有 PlantUML 源代码吗？

在 OnUML 中，请将源代码粘贴到 PlantUML 模式，以文本方式编辑并渲染预览。当前 draw.io 模式不会将 PlantUML 源代码转换为可拖动形状。

可以把拖动后的图表导出回 PlantUML 吗？

OnUML 的 draw.io 模式不支持。Draw.io 图表使用自身基于 XML 的源代码，可作为 OnUML 项目内容保存，也可导出为 PNG 或 SVG，但不会转换成 PlantUML 文本。

为什么编辑源代码后 PlantUML 会重新排列元素？

PlantUML 使用自动布局，因此关系变化和渲染器版本可能影响元素位置。方向、容器和布局提示可以影响结果，但它们不是通用的像素定位系统。可控方法请参阅 PlantUML 布局指南。

拖放能让图表更正确吗？

不能。拖动可以提高可读性，却不会验证 UML 语义、API 行为、数据库约束或架构边界。请将模型评审与布局分开。

团队应如何评估 PlantUML 编辑器？

使用有代表性的项目场景，对以下能力评分：

与团队固定 PlantUML 版本的源代码兼容性
可视化编辑后能否产生清晰的源代码变更
是否支持引用、主题和别名
能否导出所需格式
键盘无障碍性和协作能力
离线与数据处理要求

PlantUML 在线编辑器等同于所见即所得编辑器吗？

不等同。“在线”说明编辑器在哪里运行；“所见即所得”描述编辑界面与输出的相似程度。浏览器编辑器完全可以保持文本优先。

可以只用拖放调整布局吗？

OnUML 的 PlantUML 模式不支持。需要直接操作布局时，请使用 draw.io 模式，但要注意结果仍是 draw.io 图表，而不是更新后的 PlantUML 源代码。

如果既需要白板协作，又需要可维护文档，该怎么办？

采用两阶段工作流：先在画布上协作草绘，再将达成共识的模型转换为 PlantUML。设计稳定后，以 PlantUML 源代码为权威。这样可以避免把探索阶段的坐标强塞进可维护的文本模型。

实用评估示例

使用这个类图测试候选编辑器是否能保留有意义的关系：

@startuml
interface PaymentGateway
class CheckoutService
class StripeGateway
class Order

PaymentGateway <|.. StripeGateway
CheckoutService --> PaymentGateway : charges through
CheckoutService --> Order : completes
@enduml

在声称支持 PlantUML 双向编辑的工具中，拖动 StripeGateway、添加注释、重命名别名，然后检查生成的源代码。在 OnUML 中，使用 PlantUML 模式进行文本驱动的生成和预览；需要直接移动形状时使用 draw.io 模式。两种模式使用不同的源代码格式，因此 draw.io 变更不会作为重新生成的 PlantUML 出现。

需要注意的限制

PlantUML 官方来源可以证明核心工作流由文本驱动，并且存在许多集成，但无法证明每个编辑器都缺少拖放功能，或某个第三方产品目前支持特定交互。产品能力需要根据当前版本测试。

同样，文本优先编辑并非始终更优。它用直接空间操作换取可移植性、自动化和可评审性。

还有问题？

请用一个真实项目场景测试编辑器，而不是只看营销演示。你可以打开 OnUML 编辑器，使用文本驱动的 PlantUML 生成，也可以切换到 draw.io 进行直接拖放编辑。如果评估中包含多页渲染，请继续阅读 PlantUML newpage 修复指南。