1. 先想清楚为什么值得在 VSCode 里配一套 PlantUMLVSCode PlantUML 这套组合说白了就是让画图这件事回归到写代码的思路里。我最早做架构文档的时候用拖拽式画图工具改一次需求要挪半天框框版本对比更是没法看后来换成用文本描述生成图表整个流程才顺过来。PlantUML 就是干这个的——你用类似伪代码的语法描述图的结构它负责把图渲染出来时序图、类图、用例图、活动图、状态图、组件图基本都能覆盖还能画思维导图和甘特图这类偏文档表达的东西。这套环境配置解决的核心问题有三个第一是可维护性图的内容变成纯文本能进版本库谁改了什么一目了然第二是效率写图不用离开键盘跟写代码一个节奏第三是一致性团队里所有人用同一套语法和主题出图风格统一。适合的人群也很明确后端开发、架构师、写技术文档的同学、做毕业设计需要画各类图的学生只要你有把想法画出来的需求这套东西都能用上。我见过不少人卡在配置这一步装完插件兴冲冲写了第一段语法结果预览一片空白或者报一堆红字然后就放弃了。其实问题大多集中在 Java 依赖、渲染模式、字体这三块。下面我按为什么要这么配和具体怎么配两条线把整套流程拆开讲透。1.1 用文本画图这件事的底层逻辑拖拽类工具的本质是维护一个图形对象的数据结构你每一次拖动都在改这个结构但它藏在一个二进制或私有格式里外人读不懂、也难做差异对比。PlantUML 换了个思路把图形数据变成人眼可读的文本描述渲染过程按需触发。这样做的好处是图变成了源码的一部分有 diff、有 history、有 code review出问题时能追责到具体某次提交。举个直观的例子我给一个订单系统画时序图需求是用户下单后先校验库存、再冻结金额、最后生成订单。用 PlantUML 写出来就是几行 participant 加箭头改动时只要调整某一行重新渲染即可。而拖拽工具里这个改动可能涉及三四个框的位置、多条线的重连稍微手抖就错位。文本方案的边际改动成本几乎为零这是它最值钱的地方。另外PlantUML 的语法是声明式的你描述的是谁和谁之间有什么交互而不是这个框画在坐标 (100, 200)。这种抽象层级更高写起来更像在描述业务逻辑而不是在做排版。对常年写代码的人来说这套语法几乎没有学习曲线半小时能上手大部分常用图类型。1.2 为什么宿主编辑器选 VSCode能跑 PlantUML 的编辑器不止一个IDEA、Eclipse 都有对应插件甚至浏览器里也有在线版。选 VSCode 的理由主要有三条。第一是轻量和跨平台Windows、macOS、Linux 上体验基本一致配置文件还能同步换设备不用重新折腾。第二是插件生态成熟PlantUML 官方维护的插件质量稳定预览、导出、语法高亮都齐了。第三是和其他工作流整合方便你可以在同一个窗口里写 Markdown 文档、写代码、顺便把图渲染好嵌进去。还有一点容易被忽略VSCode 的配置文件是 JSON 格式团队协作时可以把它提交到仓库里新人 clone 下来装个插件就有一致的开发环境。相比之下某些重量级 IDE 的配置藏在各种面板里同步起来麻烦。当然如果你本身就是深度 IDEA 用户用 IDEA 插件也没问题语法和渲染引擎都是同一套本文的配置思路同样适用。2. 开工前的环境盘点三个必须到位的东西配置之前先把家底摸清楚这套环境依赖三个层面的东西Java 运行时PlantUML 本体的运行基础、VSCode 本体编辑器、PlantUML 插件把两者接起来的桥梁。任何一环缺了或者版本不对都可能出现插件装了但预览不出来的情况。我按依赖顺序一个个说。2.1 Java 运行环境是绕不开的第一步PlantUML 的核心是一个 Java 程序它本体打包成一个 jar 文件所以机器上必须有 Java 运行环境JRE 或 JDK。很多人第一次配失败就是因为根本没装 Java或者装了但命令行里java -version报错插件找到不解释器自然渲染失败。版本选择上现在主流推荐JDK 8 以上的 LTS 版本比如 JDK 11、JDK 17、JDK 21 都可以。我不建议用太老的版本一些新的 PlantUML 版本对 Java 版本有要求也不建议追最新的非 LTS 版本稳定性没必要冒险。安装完之后一定要在终端里验证java -version输出里能看到版本号和运行时信息就说明装好了。Windows 用户如果报不是内部或外部命令多半是JAVA_HOME没配或者PATH里没加%JAVA_HOME%\bin去系统环境变量里补上重开终端再试。这一步我强调三遍都不为过因为它是后面一切的前提。注意装了 JDK 不等于插件一定能找到它某些情况下插件读取的是系统默认 Java如果你机器上有多个版本确认一下默认指向的是哪个。2.2 VSCode 本体与中文界面VSCode 去官网下载对应系统的安装包Windows 是 exemacOS 是 dmg 或 zipLinux 有 deb、rpm 和 tar.gz。安装过程没什么坑注意安装向导里有个添加到 PATH的选项Windows建议勾上以后在终端里输code .就能直接打开当前目录。界面语言方面如果你更习惯中文装一个官方简体中文语言包插件即可装完重启会提示切换语言。这个跟 PlantUML 没直接关系但界面顺眼能降低操作时的心理成本。另外建议把 VSCode 更新到较新的稳定版插件对老版本编辑器的兼容性有时会打折扣尤其是 API 相关的功能。2.3 PlantUML 插件与配套依赖插件本身在扩展市场里搜 PlantUML 就能找到认准发布者下载量最高的那个通常就是官方维护的。装完插件还差一块拼图Graphviz。PlantUML 画类图、组件图这类需要自动布局的图时会调用 Graphviz 里的 dot 引擎来算节点位置。如果没装 Graphviz画时序图这种线性图没事但一画类图就报错或者布局乱成一团。所以我的建议是一开始就把 Graphviz 装上省得后面踩坑。Windows 下下载安装包安装时勾选添加到系统 PATHmacOS 用包管理器一行命令搞定Linux 各大发行版的软件源里都有。装完后终端里执行dot -V能打印出版本号就算成功。依赖项作用验证命令常见问题Java 运行时运行 PlantUML jar 本体java -version未配 PATH、多版本冲突VSCode编辑器宿主打开即可版本过旧、插件不兼容PlantUML 插件连接编辑器与渲染引擎扩展面板可见装错插件、未启用Graphviz复杂图自动布局dot -V未加入 PATH类图报错3. 插件配置逐项拆解插件装好只是起点真正决定能不能顺利用的是配置项。打开 VSCode 设置搜 plantuml会看到一堆选项我挑几个真正影响使用的重点讲。3.1 渲染模式本地渲染优先PlantUML 插件支持两种渲染方式调用本地 Java 环境渲染或者把源码发到远程服务器渲染。默认设置下有时会走远程这就带来两个隐患——一是网络不通时直接卡住不出图二是图的内容可能涉及内部系统设计发到外部服务器上从数据安全角度并不理想。我的做法是明确指定本地渲染在设置里找到plantuml.render相关的选项切换成用本地 jar 渲染。插件通常会自带一个 PlantUML jar也可以用plantuml.jar配置项指定你自己下载的版本这样版本可控。本地渲染的第一个好处是不依赖网络第二个好处是内容不出机器第三是速度快尤其画大图时差距明显。如果你确实需要用到较新的语法特性而插件自带 jar 版本偏旧可以单独去下载最新版 jar然后在配置里指向它的绝对路径。这个操作我做过几次注意路径别带中文和空格Windows 下用正斜杠或者双反斜杠都行。3.2 中文乱码和字体的处理中文乱码是这套环境里最高频的问题表现是预览里中文变成方块或者问号。原因通常有两层一是源文件编码不是 UTF-8二是渲染时用的字体没有中文字形。第一层好解决VSCode 新建文件默认就是 UTF-8但要确认右下角的编码标识是 UTF-8 而不是 GBK 之类。如果是从别处复制过来的文件建议另存为 UTF-8。第二层需要在图里显式指定字体比如在图的顶部加startuml skinparam defaultFontName Microsoft YaHei skinparam defaultFontSize 14 后续图形描述 endumlWindows 上可以填微软雅黑、宋体、黑体macOS 上填 PingFang SC 之类的系统字体。把字体配置写死在图里虽然有点笨但它保证了换机器渲染效果一致。更好的做法是抽成一个公共的样式片段每张图引用同一份配置。提示如果设置了字体还是乱码检查一下那台机器上到底有没有装这个字体名字拼错也会静默回退到默认字体。3.3 让写图更顺手的几个设置除了上面两个关键项还有几个配置能明显提升体验。一是自动预览写好语法后不用手动点渲染保存即刷新眼睛能跟得上思路。二是导出格式默认可能只出 png可以配成同时导出 svg矢量图放大不糊放进文档里质量更高。三是主题样式PlantUML 内置了好几套主题比如 cerulean、materia 之类选一套自己喜欢的团队统一用同一套出图就不会一个样。另外建议把常用的skinparam配置整理成模板文件新建图时直接复制。我自己的模板里固定了字体、颜色、箭头样式、页脚信息每次新建只要改主体逻辑省掉重复劳动。4. 实操从零写出第一张图并导出配置讲完来走一遍完整流程。我以一张订单下单的时序图为例把从建文件到出图的每一步都写出来你照着抄就能跑通。4.1 新建文件与文件头在 VSCode 里新建一个文件后缀名用.puml或者.plantuml都行插件靠后缀识别。文件开头必须是startuml结尾是enduml中间才是图形描述。这俩标记不能少少了渲染器会报错。我习惯在startuml后面跟一个文件名参数这样导出的图片文件名就是指定的那个不用手动改。文件头的样式配置我一般放三行字体、字号、主题方向。比如left to right direction控制布局走向时序图用不上但类图和用例图很有用。4.2 时序图实战下面是一段完整的下单时序图我边写边解释startuml order_flow skinparam defaultFontName Microsoft YaHei skinparam sequenceMessageAlign center autonumber actor 用户 as U participant 订单服务 as O participant 库存服务 as S participant 支付服务 as P U - O : 提交订单 O - S : 校验并锁定库存 S -- O : 锁定成功 O - P : 发起支付 P -- O : 支付成功 O - S : 扣减库存 O -- U : 返回下单成功 enduml这段语法里有几个点值得说。autonumber会自动给消息编号省得手动写。actor声明的是角色会渲染成小人图标participant声明的是参与方是矩形框。箭头方向-是请求--是返回用虚线区分。as后面跟的是别名正文里引用的就是别名显示出来的是引号里的中文。写完保存插件会自动在右侧开一个预览面板。如果没自动开用命令面板搜 PlantUML: Preview Current Diagram 手动触发。预览里能看到图就说明环境通了。4.3 预览、导出与接入项目预览满意后导出命令面板里搜 PlantUML: Export Current Diagram会弹格式选项png、svg、pdf 都有。我强烈建议文档场景优先用 svg因为它是矢量的放大缩小都不失真插到网页或 Word 里都清晰。png 适合聊天工具里发但放大就糊。导出路径可以在设置里指定建议固定一个docs/diagrams之类的目录和文档源码放一起。更进一步的做法是把 PlantUML 集成到构建流程里用命令行批量渲染这样文档构建时图会自动更新。命令行大致是java -jar plantuml.jar -tsvg docs/diagrams/*.puml把它写进 CI 脚本或者 Makefile每次提交文档源码图就自动重新生成。这套流程我用了很久图永远不会和文档脱节。导出格式适用场景优点缺点PNG聊天、快速预览通用、体积小放大会模糊SVG文档、网页矢量清晰、可编辑部分老工具支持差PDF打印、正式文档排版稳定不方便网页嵌入5. 常见坑与排查手册前面流程顺下来基本能跑通但实际环境千差万别我把这些年踩过的坑整理成排查表遇到问题对着查就行。5.1 渲染失败排查表现象可能原因排查方法预览一直空白Java 未装或未找到终端执行java -version报 cannot find dotGraphviz 未装或未进 PATH执行dot -V验证中文显示成方块字体不含中文图里指定中文字体文件报编码错误源文件非 UTF-8右下角确认编码并另存类图布局错乱未启用 Graphviz 布局确认 dot 可用重渲染预览超时走了远程渲染切换为本地渲染模式这张表覆盖了九成以上的问题。我特别想强调空白预览这条很多人以为是插件坏了其实十有八九是 Java 环境的问题。养成先验证基础依赖的习惯能省下大量瞎折腾的时间。5.2 性能与缓存图画多了以后你会开始在意渲染速度。PlantUML 有个缓存机制同样的源码不会重复渲染能明显加快预览刷新。但有时候改了配置却看不到变化可能是缓存没刷新这时候手动清一下缓存目录或者重启编辑器就能解决。另一个性能相关的点是图别画得太大。一张图几十个节点加几十条线渲染会变慢布局也可能乱。我的经验是单张图控制在合理规模内复杂流程拆成多张用引用关系串起来。这样既清晰又高效维护起来也轻松。5.3 团队协作中的注意事项如果你要把这套环境推到团队里有几个点值得提前约定。第一是版本统一大家用相近版本的插件和 PlantUML jar避免新语法在老版本上不识别。第二是样式统一把 skinparam 配置抽成公共文件否则每个人出的图配色字体都不一样放一起很难看。第三是目录规范图源文件和导出图放哪、怎么命名提前定好不然后期一片混乱。还有个容易被忽略的问题导出的图片要不要进版本库。我的做法是只提交 .puml 源文件图片由构建流程生成这样仓库干净也不会因为图片二进制文件导致 diff 爆炸。如果团队没有构建流程那就把图片也提交但记得每次改图时同步更新。最后分享一个我自己的习惯——给每张图加一行注释说明用途和最后修改时间放在startuml下面。看起来不起眼但过了半年再回来看能立刻知道这张图是干嘛的、什么时候改的省掉大量翻记录的时间。这套 VSCode PlantUML 的环境真正配顺之后画图就从一件苦差事变成了顺手的事我现在写技术方案基本全程不离开键盘图跟着文字一起出来效率和一致性都不是拖拽工具能比的。 VSCode PlantUML 环境配置：Java、Graphviz、本地渲染
1. 先想清楚为什么值得在 VSCode 里配一套 PlantUMLVSCode PlantUML 这套组合说白了就是让画图这件事回归到写代码的思路里。我最早做架构文档的时候用拖拽式画图工具改一次需求要挪半天框框版本对比更是没法看后来换成用文本描述生成图表整个流程才顺过来。PlantUML 就是干这个的——你用类似伪代码的语法描述图的结构它负责把图渲染出来时序图、类图、用例图、活动图、状态图、组件图基本都能覆盖还能画思维导图和甘特图这类偏文档表达的东西。这套环境配置解决的核心问题有三个第一是可维护性图的内容变成纯文本能进版本库谁改了什么一目了然第二是效率写图不用离开键盘跟写代码一个节奏第三是一致性团队里所有人用同一套语法和主题出图风格统一。适合的人群也很明确后端开发、架构师、写技术文档的同学、做毕业设计需要画各类图的学生只要你有把想法画出来的需求这套东西都能用上。我见过不少人卡在配置这一步装完插件兴冲冲写了第一段语法结果预览一片空白或者报一堆红字然后就放弃了。其实问题大多集中在 Java 依赖、渲染模式、字体这三块。下面我按为什么要这么配和具体怎么配两条线把整套流程拆开讲透。1.1 用文本画图这件事的底层逻辑拖拽类工具的本质是维护一个图形对象的数据结构你每一次拖动都在改这个结构但它藏在一个二进制或私有格式里外人读不懂、也难做差异对比。PlantUML 换了个思路把图形数据变成人眼可读的文本描述渲染过程按需触发。这样做的好处是图变成了源码的一部分有 diff、有 history、有 code review出问题时能追责到具体某次提交。举个直观的例子我给一个订单系统画时序图需求是用户下单后先校验库存、再冻结金额、最后生成订单。用 PlantUML 写出来就是几行 participant 加箭头改动时只要调整某一行重新渲染即可。而拖拽工具里这个改动可能涉及三四个框的位置、多条线的重连稍微手抖就错位。文本方案的边际改动成本几乎为零这是它最值钱的地方。另外PlantUML 的语法是声明式的你描述的是谁和谁之间有什么交互而不是这个框画在坐标 (100, 200)。这种抽象层级更高写起来更像在描述业务逻辑而不是在做排版。对常年写代码的人来说这套语法几乎没有学习曲线半小时能上手大部分常用图类型。1.2 为什么宿主编辑器选 VSCode能跑 PlantUML 的编辑器不止一个IDEA、Eclipse 都有对应插件甚至浏览器里也有在线版。选 VSCode 的理由主要有三条。第一是轻量和跨平台Windows、macOS、Linux 上体验基本一致配置文件还能同步换设备不用重新折腾。第二是插件生态成熟PlantUML 官方维护的插件质量稳定预览、导出、语法高亮都齐了。第三是和其他工作流整合方便你可以在同一个窗口里写 Markdown 文档、写代码、顺便把图渲染好嵌进去。还有一点容易被忽略VSCode 的配置文件是 JSON 格式团队协作时可以把它提交到仓库里新人 clone 下来装个插件就有一致的开发环境。相比之下某些重量级 IDE 的配置藏在各种面板里同步起来麻烦。当然如果你本身就是深度 IDEA 用户用 IDEA 插件也没问题语法和渲染引擎都是同一套本文的配置思路同样适用。2. 开工前的环境盘点三个必须到位的东西配置之前先把家底摸清楚这套环境依赖三个层面的东西Java 运行时PlantUML 本体的运行基础、VSCode 本体编辑器、PlantUML 插件把两者接起来的桥梁。任何一环缺了或者版本不对都可能出现插件装了但预览不出来的情况。我按依赖顺序一个个说。2.1 Java 运行环境是绕不开的第一步PlantUML 的核心是一个 Java 程序它本体打包成一个 jar 文件所以机器上必须有 Java 运行环境JRE 或 JDK。很多人第一次配失败就是因为根本没装 Java或者装了但命令行里java -version报错插件找到不解释器自然渲染失败。版本选择上现在主流推荐JDK 8 以上的 LTS 版本比如 JDK 11、JDK 17、JDK 21 都可以。我不建议用太老的版本一些新的 PlantUML 版本对 Java 版本有要求也不建议追最新的非 LTS 版本稳定性没必要冒险。安装完之后一定要在终端里验证java -version输出里能看到版本号和运行时信息就说明装好了。Windows 用户如果报不是内部或外部命令多半是JAVA_HOME没配或者PATH里没加%JAVA_HOME%\bin去系统环境变量里补上重开终端再试。这一步我强调三遍都不为过因为它是后面一切的前提。注意装了 JDK 不等于插件一定能找到它某些情况下插件读取的是系统默认 Java如果你机器上有多个版本确认一下默认指向的是哪个。2.2 VSCode 本体与中文界面VSCode 去官网下载对应系统的安装包Windows 是 exemacOS 是 dmg 或 zipLinux 有 deb、rpm 和 tar.gz。安装过程没什么坑注意安装向导里有个添加到 PATH的选项Windows建议勾上以后在终端里输code .就能直接打开当前目录。界面语言方面如果你更习惯中文装一个官方简体中文语言包插件即可装完重启会提示切换语言。这个跟 PlantUML 没直接关系但界面顺眼能降低操作时的心理成本。另外建议把 VSCode 更新到较新的稳定版插件对老版本编辑器的兼容性有时会打折扣尤其是 API 相关的功能。2.3 PlantUML 插件与配套依赖插件本身在扩展市场里搜 PlantUML 就能找到认准发布者下载量最高的那个通常就是官方维护的。装完插件还差一块拼图Graphviz。PlantUML 画类图、组件图这类需要自动布局的图时会调用 Graphviz 里的 dot 引擎来算节点位置。如果没装 Graphviz画时序图这种线性图没事但一画类图就报错或者布局乱成一团。所以我的建议是一开始就把 Graphviz 装上省得后面踩坑。Windows 下下载安装包安装时勾选添加到系统 PATHmacOS 用包管理器一行命令搞定Linux 各大发行版的软件源里都有。装完后终端里执行dot -V能打印出版本号就算成功。依赖项作用验证命令常见问题Java 运行时运行 PlantUML jar 本体java -version未配 PATH、多版本冲突VSCode编辑器宿主打开即可版本过旧、插件不兼容PlantUML 插件连接编辑器与渲染引擎扩展面板可见装错插件、未启用Graphviz复杂图自动布局dot -V未加入 PATH类图报错3. 插件配置逐项拆解插件装好只是起点真正决定能不能顺利用的是配置项。打开 VSCode 设置搜 plantuml会看到一堆选项我挑几个真正影响使用的重点讲。3.1 渲染模式本地渲染优先PlantUML 插件支持两种渲染方式调用本地 Java 环境渲染或者把源码发到远程服务器渲染。默认设置下有时会走远程这就带来两个隐患——一是网络不通时直接卡住不出图二是图的内容可能涉及内部系统设计发到外部服务器上从数据安全角度并不理想。我的做法是明确指定本地渲染在设置里找到plantuml.render相关的选项切换成用本地 jar 渲染。插件通常会自带一个 PlantUML jar也可以用plantuml.jar配置项指定你自己下载的版本这样版本可控。本地渲染的第一个好处是不依赖网络第二个好处是内容不出机器第三是速度快尤其画大图时差距明显。如果你确实需要用到较新的语法特性而插件自带 jar 版本偏旧可以单独去下载最新版 jar然后在配置里指向它的绝对路径。这个操作我做过几次注意路径别带中文和空格Windows 下用正斜杠或者双反斜杠都行。3.2 中文乱码和字体的处理中文乱码是这套环境里最高频的问题表现是预览里中文变成方块或者问号。原因通常有两层一是源文件编码不是 UTF-8二是渲染时用的字体没有中文字形。第一层好解决VSCode 新建文件默认就是 UTF-8但要确认右下角的编码标识是 UTF-8 而不是 GBK 之类。如果是从别处复制过来的文件建议另存为 UTF-8。第二层需要在图里显式指定字体比如在图的顶部加startuml skinparam defaultFontName Microsoft YaHei skinparam defaultFontSize 14 后续图形描述 endumlWindows 上可以填微软雅黑、宋体、黑体macOS 上填 PingFang SC 之类的系统字体。把字体配置写死在图里虽然有点笨但它保证了换机器渲染效果一致。更好的做法是抽成一个公共的样式片段每张图引用同一份配置。提示如果设置了字体还是乱码检查一下那台机器上到底有没有装这个字体名字拼错也会静默回退到默认字体。3.3 让写图更顺手的几个设置除了上面两个关键项还有几个配置能明显提升体验。一是自动预览写好语法后不用手动点渲染保存即刷新眼睛能跟得上思路。二是导出格式默认可能只出 png可以配成同时导出 svg矢量图放大不糊放进文档里质量更高。三是主题样式PlantUML 内置了好几套主题比如 cerulean、materia 之类选一套自己喜欢的团队统一用同一套出图就不会一个样。另外建议把常用的skinparam配置整理成模板文件新建图时直接复制。我自己的模板里固定了字体、颜色、箭头样式、页脚信息每次新建只要改主体逻辑省掉重复劳动。4. 实操从零写出第一张图并导出配置讲完来走一遍完整流程。我以一张订单下单的时序图为例把从建文件到出图的每一步都写出来你照着抄就能跑通。4.1 新建文件与文件头在 VSCode 里新建一个文件后缀名用.puml或者.plantuml都行插件靠后缀识别。文件开头必须是startuml结尾是enduml中间才是图形描述。这俩标记不能少少了渲染器会报错。我习惯在startuml后面跟一个文件名参数这样导出的图片文件名就是指定的那个不用手动改。文件头的样式配置我一般放三行字体、字号、主题方向。比如left to right direction控制布局走向时序图用不上但类图和用例图很有用。4.2 时序图实战下面是一段完整的下单时序图我边写边解释startuml order_flow skinparam defaultFontName Microsoft YaHei skinparam sequenceMessageAlign center autonumber actor 用户 as U participant 订单服务 as O participant 库存服务 as S participant 支付服务 as P U - O : 提交订单 O - S : 校验并锁定库存 S -- O : 锁定成功 O - P : 发起支付 P -- O : 支付成功 O - S : 扣减库存 O -- U : 返回下单成功 enduml这段语法里有几个点值得说。autonumber会自动给消息编号省得手动写。actor声明的是角色会渲染成小人图标participant声明的是参与方是矩形框。箭头方向-是请求--是返回用虚线区分。as后面跟的是别名正文里引用的就是别名显示出来的是引号里的中文。写完保存插件会自动在右侧开一个预览面板。如果没自动开用命令面板搜 PlantUML: Preview Current Diagram 手动触发。预览里能看到图就说明环境通了。4.3 预览、导出与接入项目预览满意后导出命令面板里搜 PlantUML: Export Current Diagram会弹格式选项png、svg、pdf 都有。我强烈建议文档场景优先用 svg因为它是矢量的放大缩小都不失真插到网页或 Word 里都清晰。png 适合聊天工具里发但放大就糊。导出路径可以在设置里指定建议固定一个docs/diagrams之类的目录和文档源码放一起。更进一步的做法是把 PlantUML 集成到构建流程里用命令行批量渲染这样文档构建时图会自动更新。命令行大致是java -jar plantuml.jar -tsvg docs/diagrams/*.puml把它写进 CI 脚本或者 Makefile每次提交文档源码图就自动重新生成。这套流程我用了很久图永远不会和文档脱节。导出格式适用场景优点缺点PNG聊天、快速预览通用、体积小放大会模糊SVG文档、网页矢量清晰、可编辑部分老工具支持差PDF打印、正式文档排版稳定不方便网页嵌入5. 常见坑与排查手册前面流程顺下来基本能跑通但实际环境千差万别我把这些年踩过的坑整理成排查表遇到问题对着查就行。5.1 渲染失败排查表现象可能原因排查方法预览一直空白Java 未装或未找到终端执行java -version报 cannot find dotGraphviz 未装或未进 PATH执行dot -V验证中文显示成方块字体不含中文图里指定中文字体文件报编码错误源文件非 UTF-8右下角确认编码并另存类图布局错乱未启用 Graphviz 布局确认 dot 可用重渲染预览超时走了远程渲染切换为本地渲染模式这张表覆盖了九成以上的问题。我特别想强调空白预览这条很多人以为是插件坏了其实十有八九是 Java 环境的问题。养成先验证基础依赖的习惯能省下大量瞎折腾的时间。5.2 性能与缓存图画多了以后你会开始在意渲染速度。PlantUML 有个缓存机制同样的源码不会重复渲染能明显加快预览刷新。但有时候改了配置却看不到变化可能是缓存没刷新这时候手动清一下缓存目录或者重启编辑器就能解决。另一个性能相关的点是图别画得太大。一张图几十个节点加几十条线渲染会变慢布局也可能乱。我的经验是单张图控制在合理规模内复杂流程拆成多张用引用关系串起来。这样既清晰又高效维护起来也轻松。5.3 团队协作中的注意事项如果你要把这套环境推到团队里有几个点值得提前约定。第一是版本统一大家用相近版本的插件和 PlantUML jar避免新语法在老版本上不识别。第二是样式统一把 skinparam 配置抽成公共文件否则每个人出的图配色字体都不一样放一起很难看。第三是目录规范图源文件和导出图放哪、怎么命名提前定好不然后期一片混乱。还有个容易被忽略的问题导出的图片要不要进版本库。我的做法是只提交 .puml 源文件图片由构建流程生成这样仓库干净也不会因为图片二进制文件导致 diff 爆炸。如果团队没有构建流程那就把图片也提交但记得每次改图时同步更新。最后分享一个我自己的习惯——给每张图加一行注释说明用途和最后修改时间放在startuml下面。看起来不起眼但过了半年再回来看能立刻知道这张图是干嘛的、什么时候改的省掉大量翻记录的时间。这套 VSCode PlantUML 的环境真正配顺之后画图就从一件苦差事变成了顺手的事我现在写技术方案基本全程不离开键盘图跟着文字一起出来效率和一致性都不是拖拽工具能比的。