简介：PIPE4.3.0 是一款面向 Petri 网学习与系统行为建模的图形化仿真软件，适合计算机、软件工程及自动化相关专业的学生、教师与工程人员，用于并发系统、同步与竞争流程的形式化分析。压缩包共 2391 个文件，约 28.43MB，以 svn-base 版本库文件、class 编译文件、png/svg 界面素材、entries 元数据及少量 xml、jar、properties 配置为主，保留了较完整的工程源码与运行依赖结构。已有约 1500 人学习下载，说明其在 Petri 网建模入门与课程实践中具有一定参考价值。资源覆盖图形化建模、动态仿真、可达性图与安全性/活性检查等功能，并包含启动脚本和多个视图、查询编辑器相关类文件，便于读者直接运行软件、观察令牌流转过程，也可据此理解 PIPE 的模块组织与二次开发思路。
1. 评审会上的那张网：PIPE 4.3.0 能替你回答什么
流程评审最怕一种场面：图上画得很整齐，有人抬头问一句「这个工位两个班次并起来会不会堆料」，全场沉默。纸面推演答不了并发和资源竞争，Excel 也答不了。Petri 建模仿真的价值就在这儿——把流程拆成库所和变迁，让 token 在网里真的流动，再拿数学工具把「会不会死锁、稳态吞吐多少、缓冲区最小要多大」算出来。
PIPE 4.3.0 就是干这个的：一个 Java 写的 Petri 网建模与仿真工具，支持 P/T 网、GSPN（广义随机 Petri 网）和 CPN，能在画布上建网、跑动画仿真看 token 走向，再用不变量分析、可达图、状态空间和稳态性能分析把结论落到数字上，模型还能导出成 PNML 交给别的工具复用。适合做流程建模、并发协议、资源调度的从业者，也适合课程里需要交一份「可验证模型」而不是一张示意图的人。
2. 环境与工程结构：把 Java 运行时对齐再谈建模
2.1 先定 Java 版本，再谈启动
PIPE 4.3.0 是 Swing 桌面程序，代码年代偏早，用的是老式 Java 类库和反射写法。这类程序在 JDK 8 上基本是稳的；上到 JDK 11 以后，模块化把一批内部 API 收起来了，启动时最容易撞见的就是NoClassDefFoundError或者某个sun.*包找不到。我一般的做法不是去改代码打补丁，而是老老实实给它配一个 JDK 8 的运行环境，用JAVA_HOME做隔离，机器上同时装多个版本互不干扰。
先确认当前 shell 用的是哪个 Java：
# 查看当前默认 Java 版本，PIPE 4.3.0 建议落在 1.8.x java -version # 如果机器上装了多个 JDK，为当前终端单独指向 JDK 8 export JAVA_HOME=/opt/jdk1.8.0_381 export PATH="$JAVA_HOME/bin:$PATH" # 再确认一次，输出里应出现 1.8.0 字样 java -version 2>&1 | head -n 1这里三个动作各自解决一个问题：java -version是摸底，JAVA_HOME是给后续所有java调用定基准，PATH前置是保证 shell 真的用上新基准而不是缓存里的旧路径。第三行那个2>&1不能省，java -version的输出走的是标准错误流，不重定向的话管道拿不到内容，你会看到一个空结果然后误以为命令没执行。
提示：不要在系统级改默认 JDK 去迁就一个工具，机器上其他项目会跟着遭殃。用终端级的
export，或者写一个只在这个窗口生效的启动脚本。
2.2 目录结构与依赖布局
解压出来的包通常长这样：一个主 jar，一个lib目录放第三方依赖，若干examples或models目录放示例网文件。很多人图省事把主 jar 单独拷到桌面双击，然后报类找不到——原因就是lib没跟过来，classpath 断了。判断标准很简单：主 jar 和lib必须保持解压时的相对位置。
| 路径 | 作用 | 能不能动 |
|---|---|---|
主 jar（形如PIPE4.3.0.jar） | 入口，含主类和 UI | 不能改名后随手挪位置 |
lib/ | 第三方依赖 jar，分析模块的矩阵求解常在这里 | 不能删，不能拆散 |
examples/或models/ | 示例 Petri 网文件 | 可读可改，适合当模板抄 |
| 导出的分析结果目录 | 可达图、稳态结果的落盘位置 | 路径别带中文和空格 |
路径带中文和空格是另一个高频翻车点。老式 Java 程序在处理file://URL 和资源加载时，对空格的转义经常处理不干净，表现是能启动但导不出文件，或者一开分析模块就抛MalformedURLException。习惯上我会把整个包解压到D:\work\pipe430或/opt/pipe430这种纯 ASCII、无空格的短路径下，省掉一整类玄学问题。
2.3 启动命令与内存参数
命令行启动比双击更可控，因为你能把堆内存直接写进参数里。状态空间分析是吃内存的大户，默认堆往往不够，跑到一半OutOfMemoryError，前面的建模时间全白费。
cd /opt/pipe430 # -Xms 初始堆，-Xmx 最大堆；分析大网时把 -Xmx 提到物理内存的一半左右 java -Xms256m -Xmx2g \ -Duser.language=en \ -Duser.country=US \ -jar PIPE4.3.0.jar参数逐个说：-Xms256m是初始堆，给太小会让程序反复扩容，启动阶段就会卡顿；-Xmx2g是上限，这个值直接决定你能生成多大的可达图，一般按「状态数 × 单个状态对象开销」粗估，保守给到 2G 到 4G；-Duser.language和-Duser.country把 Locale 固定成英文，作用是让数字格式化统一用点号做小数点——GSPN 里要输入变迁速率0.05这种值，如果 Locale 把它解析成逗号分隔，速率会被读成 5，结果差两个数量级，而且界面上看不出来。
Windows 下把同样内容写进一个start.bat，双击即可，别用javaw，出异常时你看不到控制台输出，等于把唯一的诊断线索掐了。
2.4 第一次启动要核对的三个配置
启动起来先别急着画图，花两分钟核对三处，能省掉后面几小时的排查。第一处是内存，在帮助或关于里确认可用堆和你传的参数一致，不一致说明你启动的不是你以为的那个包。第二处是导出目录，随便建一个空网导出一次 PNML，看文件真的落地了没有，有些环境下临时目录不可写，导出会静默失败。第三处是 Locale，随便在一个速率输入框里敲0.1，看它会不会自动变成0,1或者被拒绝。
这三处对应的是三类事后极难定位的问题：内存不够表现为分析中途崩溃，导出失败表现为「我明明点了保存」，Locale 问题表现为数值全错但界面一切正常。前两个会让你怀疑软件，第三个会让你怀疑自己的模型——后者最伤，因为你可能会去改一个本来没错的网结构。
3. 建一张 P/T 网：库所、变迁、弧权与初始标识
3.1 P/T 网还是 GSPN：先按问题选模型
选错模型类型是新手最容易走的一条弯路。P/T 网（库所/变迁网）只有结构语义，token 是黑的，你能分析可达性、有界性、死锁和守恒性，但得不出「平均吞吐是多少」这种时间相关的结论。GSPN 在变迁上挂了速率，瞬时变迁优先于时间变迁，能生成马尔可夫链，从而算出稳态概率和各变迁吞吐。代价是它默认所有时间变迁服从指数分布，这个假设你不认，结果就不能信。
| 维度 | P/T 网 | GSPN |
|---|---|---|
| 时间语义 | 无 | 时间变迁按指数分布延迟 |
| 核心分析 | 可达图、不变量、死锁 | 稳态概率、吞吐、token 分布 |
| 输出形态 | 结构性质（是/否 + 反例路径） | 数值指标（速率、期望值） |
| 主要风险 | 状态爆炸 | 分布假设不成立导致数值失真 |
| 典型场景 | 协议逻辑、并发正确性 | 产能评估、缓冲区定容 |
判断方法就三问：你要的是「对不对」还是「快不快」？如果是前者，P/T 网足够；如果模型里存在明确的随机服务时间，且你接受指数分布近似，才上 GSPN。第三问是——你的模型有界吗？GSPN 的稳态分析要求网是有界且无死锁的，无界网跑稳态会直接告诉你算不出来，或者给一堆没意义的值。
3.2 画库所和变迁：命名与结构约定
画之前先定命名规范，这不是形式主义。等到不变量分析报出「P7 和 P12 出现在同一个不变量里」时，你如果只记得「那个圆圈」，排查成本会翻倍。我一般用P_前缀给库所、T_前缀给变迁，后面接业务语义，比如P_待加工、T_质检。PIPE 支持中文名，但导出 PNML 后中文在别的工具里可能变乱码，稳妥起见 id 用英文，显示名再写中文。
下面是一个最小可用的两库所一变迁结构的 PNML 形态，按通用 PNML 结构给，字段名在不同导出器和版本间可能略有出入：
<?xml version="1.0" encoding="UTF-8"?> <pnml> <net id="net1" type="P/T net"> <page id="page1"> <!-- 库所：id 全局唯一，name 是显示名，initialMarking 是初始 token 数 --> <place id="P_in"> <name><text>P_in</text></name> <initialMarking><text>3</text></initialMarking> </place> <place id="P_out"> <name><text>P_out</text></name> <initialMarking><text>0</text></initialMarking> </place> <!-- 变迁：无速率表示瞬时变迁，P/T 网里通常不写速率 --> <transition id="T_move"> <name><text>T_move</text></name> </transition> <!-- 弧：source 与 target 必须引用已存在的节点 id --> <arc id="a1" source="P_in" target="T_move"> <inscription><text>1</text></inscription> </arc> <arc id="a2" source="T_move" target="P_out"> <inscription><text>1</text></inscription> </arc> </page> </net> </pnml>这段结构里有三个约束值得记住：place和transition的id必须在整个 net 内唯一，重复 id 会让分析模块报索引冲突；arc的source和target必须指向真实存在的节点，删节点忘了删弧，导出就会留下悬空引用；inscription就是弧权，值为 1 时可以省略，但省略和显式写 1 在某些工具里语义一致、在某些工具里会被当成「未指定」，跨工具交换时建议都写上。
在画布上操作的顺序和上面 XML 是对应的：先放库所，双击改名字和初始 token，再放变迁，最后从一个节点拖到另一个节点生成弧。弧生成后点中它，在属性面板里把权重从默认的 1 改成你要的值。这个面板里还有个方向问题要注意——弧是有向的，从库所指向变迁是消费，从变迁指向库所是产出，拖反了不会报错，但模型语义完全颠倒，而且动画跑起来照样有 token 在动，肉眼很难发现。
3.3 弧权、容量与初始标识
弧权表达的是「一次变迁消耗或产出几个 token」。装配场景里很常见：一个工序消耗 2 个零件产出 1 个组件，那输入弧权就是 2，输出弧权是 1。权重写错的表现是资源凭空多出来或者凭空消失，而不变量分析会用「不守恒」的方式告诉你这件事——如果一条 P-不变量覆盖了你预期的所有资源库所，但加权和前后对不上，八成是某条弧的权重敲错了。
库所容量是另一个易漏项。默认容量是无穷，意味着这个缓冲区可以无限堆料。如果你要验证「缓冲区满了会阻塞上游」，就必须显式给容量赋值，否则模型永远不阻塞，你得到的结论是「系统不会堵」，而这个结论只对无容量限制的假设成立。容量在属性面板里设，导出后在 PNML 里对应capacity字段。
初始标识决定了仿真的起点。做稳态分析时初始标识只影响收敛速度，不影响稳态值；但做可达图分析时初始标识就是根节点，改一个 token 就是换了一棵树。习惯做法是把「系统刚开机」「班次刚开始」这种真实初态写进文档，别凭感觉填。
3.4 动画仿真：步进、随机与录制
动画是 PIPE 最直观的部分，也是最多人被它误导的部分。它能让你看到 token 在动，但动的方式取决于你选的 firing 模式。
| 模式 | 行为 | 什么时候用 |
|---|---|---|
| 手动步进 | 你点哪个可实施变迁就触发哪个 | 验证某条特定路径、给评审演示反例 |
| 随机/自动 | 在可实施集合里按规则挑一个连续触发 | 粗略感受冲突和并发、找卡死点 |
| 单步回溯 | 回到上一个状态 | 复现某个异常状态是怎么走到的 |
手动步进的价值在演示：你想证明「两个订单同时抢一个资源会死锁」，就手动把两条路径都推到临界点，让 token 卡在那里，比讲十分钟理论管用。随机模式的价值在探索：你不知道模型会在哪卡住，让它自己跑几百步，停下来看一眼是不是所有变迁都还有可实施路径。单步回溯是后悔药，跑飞了不用从头来。
动画跑出来的东西不是证据。它只能证明「这条路径可行」，不能证明「所有路径都可行」。要下结论必须回到第 4 章的分析模块，动画只是帮你建立对模型的直觉。
4. 用不变量和可达图把模型跑通：分析与验证的具体参数
4.1 P-不变量与 T-不变量怎么读
不变量分析是 PIPE 里性价比最高的功能，几秒钟出结果，能直接告诉你模型的骨架对不对。P-不变量是一组库所的加权组合，在所有可达标识下 token 加权和恒定；T-不变量是一组变迁的触发次数组合，按这个次数触发一轮之后状态回到原样。
读结果的方法不是看数字，是看覆盖关系和语义映射。把 P-不变量里的库所名换成你的业务对象，然后问一句：这个组合守恒，符合物理现实吗？
| 分析输出 | 字面含义 | 你该追问什么 |
|---|---|---|
| 存在覆盖全部库所的 P-不变量 | 系统资源总量守恒 | 有没有哪个资源本该被消耗掉却没出现在里面 |
| 某个库所不在任何 P-不变量里 | 该库所 token 可无限增长 | 这是不是意料之外的无界缓冲区 |
| 存在正的 T-不变量 | 存在可循环执行的变迁序列 | 这个循环是不是业务上的一个完整周期 |
| 没有任何 T-不变量 | 网里不存在回路 | 单批次流程正常，长期运行模型就是错的 |
第二行那个情况最值得警惕。一个库所如果不在任何 P-不变量里，说明它的 token 数不受任何守恒约束，很可能无界。在 GSPN 上跑稳态分析时，无界直接导致马尔可夫链无限，算不出结果。
4.2 可达图与状态空间：什么时候会炸
可达图把每个可达标识当成一个节点，把变迁触发当成边。它能回答三个问题：有没有死锁（存在没有出边的非终态节点）、某个状态能不能到达、最长的无重复路径有多长。代价是状态数随并发度指数增长，一个看起来只有二十个库所的网，状态数轻易上百万。
PIPE 生成可达图时有几个参数要盯住：状态数上限（防止内存爆掉）、是否做有界性检查、是否只存前驱做回溯。上限调太低会得到一棵被截断的树，你从截断的树上得出的「没有死锁」结论是无效的——因为死锁可能在被截掉的那部分里。这个坑非常隐蔽，界面上不会有醒目提示，只有你在结果里看到「达到上限，已停止」这种字样。
内存不够时的处理顺序是这样的：
# 第一步：先确认当前堆上限，别盲目怀疑模型 java -Xmx2g -jar PIPE4.3.0.jar # 第二步：分析大网时提到物理内存的一半，并留出系统余量 java -Xms1g -Xmx6g -jar PIPE4.3.0.jar # 第三步：如果仍然不够，开 GC 日志看是不是在反复 Full GC java -Xms1g -Xmx6g -Xloggc:gc.log -XX:+PrintGCDetails -jar PIPE4.3.0.jar第三步的诊断意义在于区分两种「慢」：一种是状态数真的爆炸，内存加多少都不够，只能回去简化模型或者做对称性约简；另一种是堆够但 GC 频繁，看gc.log里 Full GC 的间隔和回收量就能判断。分不清这两种，你会一直在加内存和改模型之间来回试。
注意：可达图分析前先把模型里的死变迁（永远不可实施的变迁）清掉。死变迁不会增加状态数，但会让结果里的边统计失真，你按边数估复杂度会估错。
4.3 GSPN 稳态与性能分析
GSPN 分析是 PIPE 区别于普通画图工具的地方。你给每个时间变迁设一个速率（单位时间的平均触发次数），工具会构造出对应的连续时间马尔可夫链，解稳态方程，输出每个标识的稳态概率和各变迁的吞吐。
| 输出项 | 含义 | 常见用法 |
|---|---|---|
| 标识稳态概率 | 系统长期停留在该状态的时间占比 | 判断某条分支是不是热点 |
| 变迁吞吐（throughput） | 该变迁单位时间平均触发次数 | 直接对应产能 |
| token 期望数 | 某库所里平均有多少 token | 缓冲区定容、在制品估算 |
| 平均 token 数 / 容量比 | 库所占用率 | 判断瓶颈工位 |
有三个前提必须同时成立结果才有意义：网是有界的、网是无死锁的（或者你把死锁状态当成吸收态单独看待）、所有时间变迁的延迟服从指数分布。第三条最容易被忽略——现实里的加工时间更接近正态或者固定值，用指数分布去拟合会低估方差，得到的排队长度偏乐观。我一般的处理是把这个结论标注成「在指数分布假设下的下界」，别当成精确预测往汇报材料里写。
参数输入环节有两个细节：速率是「单位时间的平均次数」，不是「平均耗时」。加工一件平均 20 分钟，速率是 3（每小时）而不是 20。填反了结果会离谱到你怀疑软件，实际上是自己把量纲搞反了。第二个细节是小数的写法，前面 2.3 节说的 Locale 问题在这里会直接放大，0.05被读成5，吞吐直接虚高两个数量级。
4.4 分析结果落盘与复核
分析跑完别只看界面，把结果导出来存盘。原因是同一个模型你迟早会改，改完之后需要跟上一版对比，没有基线就没法判断改动是不是让性能变差了。
# 建立版本化目录，模型文件和分析结果放一起 mkdir -p runs/v1 runs/v2 # 命名约定：模型名_版本_分析类型，方便脚本批量比对 cp model.pnml runs/v1/line_model_v1.pnml cp steady.csv runs/v1/line_model_v1_steady.csv # 只看两版吞吐列的差异，定位改动影响 diff <(cut -d, -f1,4 runs/v1/line_model_v1_steady.csv) \ <(cut -d, -f1,4 runs/v2/line_model_v2_steady.csv)这段脚本的重点不在命令本身，在目录约定：runs/vN把「第几版模型」和「那一版的分析结果」绑在一起，diff那一行假定你的导出 CSV 第 1 列是变迁名、第 4 列是吞吐，实际列序要按你的导出格式改。有了这个基线，你改一个弧权之后能立刻看到哪几个变迁的吞吐变了，而不是凭印象说「好像快了点」。
5. 避坑清单：PIPE 4.3.0 上最容易翻车的 5 个现场
5.1 启动就报类找不到或版本不支持
现象：双击 jar 或者命令行启动，抛出UnsupportedClassVersionError，或者NoClassDefFoundError指向某个javax/sun开头的类，界面根本出不来。
原因有两个层面。UnsupportedClassVersionError是 JDK 版本低于 class 文件要求的编译版本，说明你机器上的默认 Java 太老；NoClassDefFoundError更常见的是 JDK 版本太新，模块化之后老的内部 API 不再导出，或者lib目录没跟主 jar 放在一起导致 classpath 断裂。
解决：先java -version确认是 1.8.x，不是就按 2.1 节用JAVA_HOME切过去；确认版本没问题还报类找不到，就去检查lib是否完整、主 jar 和lib的相对位置有没有被破坏。这两步覆盖九成启动失败，剩下的那一成通常是下载包本身不完整，重新解压一份比对文件数量。
5.2 分析卡死或者内存溢出
现象：点开始分析，进度条走到某个百分比不动了，过一会儿弹OutOfMemoryError，或者整个界面假死，风扇狂转。
原因：状态空间随并发度指数增长，一个二十来个库所的网状态数上百万是常事。默认堆往往只有几百兆，撑不住。还有一种情况不是内存问题而是真的算不完——模型里有高并发段，状态数是天文数字，加到多少内存都无解。
解决：先用-Xmx把堆提上去重跑，看是不是内存问题；提了还不行就开 GC 日志确认是不是在反复 Full GC；确认是状态爆炸，就回去做模型简化——合并对称的并发分支、给缓冲区加容量约束切断无限增长、把不关心的子系统抽象成一个库所。硬顶着算不是办法。
5.3 稳态结果是 NaN 或者概率为负
现象：GSPN 稳态分析跑完了，输出的标识概率里出现NaN、负值，或者所有概率加起来不等于 1。
原因：九成是模型本身不满足稳态分析的前提。网里有死锁，马尔可夫链有吸收态，稳态方程无唯一解；或者网无界，状态空间无限，截断之后解出来的东西没有意义。剩下的那一成是数值问题，矩阵规模太大或者条件数太差，求解器精度不够。
解决：先跑可达图，确认没有死锁、没有无界库所，再跑稳态。可达图这一步不能跳，它是最便宜的前置检查。确认结构没问题还是 NaN，把变迁速率的值域收一收——有的速率填得过大或过小（比如1e-9和1e6混在一起），矩阵条件数会很难看，把量纲统一到同一数量级通常能缓解。
5.4 导出的 PNML 在别的工具里打不开
现象：在 PIPE 里一切正常，导出 PNML 拿到另一个建模工具里导入，报解析错误、节点丢失、弧变成悬空引用，或者中文全变问号。
原因：三类。一是 id 重复或者弧引用了已删除的节点，PIPE 内部能容忍，严格的解析器不容忍；二是中文显示名在某些导出路径下没有正确声明编码；三是不同工具对 PNML 的方言支持不一样，某些扩展字段对方不认识。
解决：导出前先做一次自检——把所有节点名改成纯 ASCII 的 id，把删过的节点残留的弧清掉，导出后用一个最简单的 XML 解析器过一遍，看能不能正常读。跨工具交换时优先用最朴素的 P/T 网结构，别带 GSPN 的速率扩展字段，对方认不认是运气问题。
5.5 模型能跑但结论不可信
现象：动画跑得挺欢，可达图也生成了，稳态也出了数，但结论跟现场对不上——比如模型说缓冲区 3 个就够，实际现场天天堵。
原因：模型和现实脱节，而且这种脱节不会以报错的形式出现。典型情况有三种：该加容量约束的库所没加，模型永远不阻塞；把并行的两道工序画成了串行，产能天然偏低；瞬时变迁和时间变迁的优先级用反了，本该被抢占的流程在模型里乖乖排队。
解决：拿现场的一组实测数据做标定，至少对上一个指标（比如某工位的实际小时产出），对不上就回去查结构而不是调参数。参数能凑出正确答案，但那是拟合，不是建模。我吃过这个亏——参数调到看着像了，换个工况立刻崩。
6. 把模型当代码管：PNML 自检脚本与一次回归
模型改到第三版之后，靠眼睛比对已经不可靠了。最省事的办法是写个几十行的脚本，把 PNML 当成结构化数据做一遍体检：节点 id 是否唯一、弧的引用是否都存在、有没有库所初始 token 为负、每个变迁是否至少有一条输入弧和一条输出弧。跑一遍两秒钟，比人工核对靠谱得多。
import xml.etree.ElementTree as ET from collections import Counter def check_pnml(path): # PNML 的元素带命名空间时要去掉，否则 findall 找不到 tree = ET.parse(path) root = tree.getroot() ns = "" if root.tag.startswith("{"): ns = root.tag.split("}")[0] + "}" places = root.findall(f".//{ns}place") trans = root.findall(f".//{ns}transition") arcs = root.findall(f".//{ns}arc") ids = [p.get("id") for p in places] + [t.get("id") for t in trans] dup = [i for i, c in Counter(ids).items() if c > 1] if dup: print(f"[重复id] {dup}") # 弧两端的节点必须存在，悬空引用是跨工具导入失败的头号原因 known = set(ids) for a in arcs: for end in ("source", "target"): if a.get(end) not in known: print(f"[悬空弧] {a.get('id')} 的 {end}={a.get(end)} 不存在") # 每个变迁至少一进一出，否则要么是死变迁要么是凭空产 token for t in trans: tin = [a for a in arcs if a.get("target") == t.get("id")] tout = [a for a in arcs if a.get("source") == t.get("id")] if not tin or not tout: print(f"[孤立变迁] {t.get('id')} 入弧{len(tin)}条 出弧{len(tout)}条") print(f"库所 {len(places)} 变迁 {len(trans)} 弧 {len(arcs)}") check_pnml("runs/v2/line_model_v2.pnml")脚本里三个检查点对应三类事后难查的问题。重复 id 在导出时可能被静默合并，你打开模型发现少了个库所。悬空弧是最常见的跨工具导入失败原因，PIPE 内部能容错，别的解析器直接报错退出。孤立变迁分两种，只有入弧没有出弧是死变迁，只有出弧没有入弧是凭空造 token，后者在稳态分析里会表现成某个库所 token 数持续增长，最后算不出有界解。
命名空间那一段别删。PNML 文件带默认命名空间时，root.tag会变成{http://...}pnml这种形式，直接findall("place")一个都找不到，你会以为文件是空的。脚本里用startswith("{")判断并剥掉前缀，是处理这类 XML 的通用写法。
还有个小技巧：把脚本挂到模型的保存动作之后，每次导出自动跑一遍，输出写到同目录的check.log。模型改十几次之后，你翻这个日志就能看到哪一版引入了悬空弧，比凭记忆回溯快得多。库里再放一份runs/v1的基线 PNML，新版本跑完脚本之后顺手 diff 一下节点数，突然多出五个库所的时候你会立刻警觉。
从那以后我每次改完模型，导出 PNML 都要先跑一遍这个脚本，再去看可达图，顺序不换。因为结构错的时候去看分析结果，很容易被一个「看着挺合理」的数字骗过去，然后带着错结论去开会。希望帮到你。
本文还有配套的精品资源，点击获取
