白天在 NX 里录一段改注释的 journal，点运行，注释按预期替换；同一份文件交给 run_journal 在批处理里跑，却在当前部件为空后，下一行取注释时报错 NullReferenceException。最容易走偏的，是把它当成许可不够，先去查服务器。这个错误说的是某个对象是空的，而不是某项授权取不到。

报错停在哪一行，比报错内容更能说明问题

原问里的 journal 是 NX 8.5 录制的：取当前显示的部件，遍历注释，替换一段文字。交互执行时一切正常，因为屏幕上确实开着一个部件，“当前显示部件”总有东西可取。

换成批处理，这一句就落空了。批处理没有 NX 的交互界面，也不存在“你正在看的那个部件”。同一份代码在两种执行方式下读到的是不同的会话状态，报错行号正好指出这一点。

第二行是关键。交互执行时，当前部件、当前视图都是“顺手就有”的状态，录制的代码会继承它们，看起来像代码自己完成了工作，实际是环境替它补了前提。

批处理不是把同一个窗口藏起来

Siemens 在 NX 2212 系列 NX Open Programmer's Guide 中区分了执行方式：交互模式运行在 NX 会话中，显示窗口、菜单和工具条可用；批处理模式没有交互界面，应用能访问部件模型，但不能执行显示类操作，用户界面需由应用提供。文档还说明，批处理应用只能从命令行启动，通常用于耗时较长、人工介入较少的任务。

窗口不存在，依赖窗口的状态也就不存在，凡是从“当前显示”“当前选择”取值的地方都要显式指定。另一层差别是安静：交互出错会弹提示，批处理里没人守着，错误只留在退出信息和日志里。

一次最小复测，把部件交进去

原问讨论中最终可用的做法，是把部件作为参数交给 journal，由它自己打开、处理、保存，再用命令行重跑一次：

1. 命令写全：run_journal 指向 journal 文件，用 -args 传入部件完整路径，路径带空格时加引号。

1. journal 接收参数，用打开部件的方法载入，再从会话取显示部件和工作部件，不假设已经有一个。

1. 处理完显式保存；不保存等于只在内存里改了一遍。

1. 把输出重定向到文本文件：讨论中的做法是，批处理下写入列表窗口的内容会送到标准输出。只重跑一次，留下命令、版本、部件路径和输出文件；仍失败说明还有前提没补上。

换机器、换账号、换启动方式时，只要这些前提写在 journal 里，结果至少不再依赖某个人打开了什么。

什么情况才轮到查许可

NX Open 的许可检查按功能走。同一份文档说明，应用运行时使用基于功能的许可检查：只有所用能力对应的 NX 许可可用时才运行，生成几何需要建模许可，生成制图尺寸需要制图许可，标准是交互完成同样结果所需的许可集合。缺少许可时，界面弹出许可错误，缺失的功能许可名称写入 NX 日志，随后应用退出。

文档还说明：如果 NX 会话已保留某个许可，应用不会重复签出，而是继续用会话中已生效的那一份，应用取消加载时未使用的许可被释放；应用也可以用许可管理接口预留和释放功能许可，只有在没被其他应用占用时，释放的许可才回到公共池。所以占不占许可，不能只看进程是否开着。

版本关系要单独说明：原问发生在 NX 8.5，上述说明出自 NX 2212 系列文档。该文档限定 journal 回放限于 Windows 上的 Python、Visual Basic .NET 和 C# .NET，.NET journal 只能调用随 NX 链接的少数库，超出的功能需要编译成应用。

把这类任务纳入日常观察

批处理和自动化任务有个共同点：不吵。往往等到下一道工序要用文件时才发现。许可层面也一样，夜间提交的任务可能整段占着建模或制图许可，白天的人却在排队。

对已接入的 NX 浮动许可环境，浮点许可优化管理软件可以把许可资源纳入统一管理，实时监控当前占用，并用历史分析看某段时间里是谁、以什么方式使用。把批处理任务的启动记录与许可使用曲线对上，才能分清是任务真的多，还是交互会话结束后没有归还。无人操作、没有界面，都不能单独当作闲置依据。

真正可优化的，是已确认结束、使用者也不再需要的占用；优化应建立在记录上，而不是“看起来没人用”的判断上。

广州浮点信息科技有限公司通过浮点许可优化管理软件，帮助客户掌握浮动版软件的使用数据，提升许可证使用效率，助力企业降本增效。如有NX/UG许可证管理与优化方面的需求，欢迎联系我们。