Puerts项目中C调用ExecuteModule时模块语法错误导致Unity崩溃问题分析

问题背景

在Unity项目中使用Puerts进行JavaScript/TypeScript脚本集成时，开发人员发现了一个严重的稳定性问题：当通过C#代码调用JsEnv的ExecuteModule方法加载包含语法错误的ES模块时，会导致Unity编辑器直接崩溃。

问题现象

开发人员提供了一个完整的复现案例，主要场景如下：

1. 创建自定义的JSLoader继承自DefaultLoader，用于加载JavaScript模块
2. 在C#代码中通过JsEnv.ExecuteModule方法加载一个ES模块(AModule.mjs)
3. 当被加载的模块中存在语法错误时，Unity编辑器会直接崩溃
4. 崩溃时产生的错误信息显示V8引擎内部断言失败："Check failed: has_pending_exception()"

技术分析

根本原因

这个问题源于Puerts在处理ES模块加载时的异常处理机制不完善。当V8引擎在解析和执行模块时遇到语法错误，会设置pending exception，但Puerts的Native层代码没有正确处理这种异常情况，导致V8的断言失败。

调用栈分析

从崩溃堆栈可以看出：

1. 调用链从C#的ExecuteModule开始
2. 经过Puerts的Native层(puerts::esmodule::ExecuteModule)
3. 进入V8引擎的模块实例化流程(v8::Module::InstantiateModule)
4. 当遇到语法错误时，V8尝试传播异常但失败
5. 最终触发V8的致命错误断言

影响范围

这个问题会影响所有使用Puerts进行ES模块加载的场景，特别是：

1. 动态加载外部JavaScript模块
2. 热更新场景下的模块加载
3. 开发阶段频繁修改模块代码的情况

解决方案

Puerts团队已经通过以下方式解决了这个问题：

1. 添加了专门的单元测试用例来验证修复
2. 在Native层完善了异常处理机制
3. 确保在模块加载失败时能够正确捕获并传播异常，而不是导致崩溃

最佳实践建议

为了避免类似问题，开发人员在使用Puerts时应注意：

1. 在开发阶段对关键JavaScript模块进行预校验
2. 实现模块加载的异常捕获机制
3. 考虑在正式环境中使用编译后的代码而非原始模块
4. 建立模块加载的日志记录系统，便于追踪问题

总结

这个案例展示了JavaScript引擎与Unity交互时异常处理的重要性。Puerts作为桥梁，需要确保两端都能正确处理各种边界情况。通过这个问题的修复，Puerts在稳定性方面又向前迈进了一步，为开发者提供了更可靠的JavaScript/TypeScript集成方案。