Go Goja 脚本被 Interrupt 后再次执行怎么办

Goja 脚本被 Interrupt 打断后，想在同一个 Runtime 里继续执行，关键不是重新调用 RunString，而是先等上一次调用返回，再调用 ClearInterrupt 清除中断标记。需要注意：清除标记只恢复“允许运行”的条件，不会撤销脚本已经写入的变量、对象或宿主回调副作用。

可复用路径是：执行结束 → 判断 *goja.InterruptError → ClearInterrupt → 确认状态可控 → 再次执行；如果脚本已经改坏了业务状态，就重新创建 Runtime。

三点先记住：同一个 Runtime 不要并发使用；旧的超时 goroutine 必须结束或取消；重跑前要区分“中断标记残留”和“脚本半执行状态”。

先等待 RunString 返回并识别 InterruptError

Interrupt 可以从另一个 goroutine 发出，但它只负责设置中断请求。真正的执行 goroutine 仍要从 RunString 或 RunProgram 返回后，才能开始清理和重跑。Goja 官方示例把返回错误识别为 *InterruptError，传给 Interrupt 的值可以从错误中取回。

package main

import (
    "fmt"
    "time"

    "github.com/dop251/goja"
)

func runOnce(vm *goja.Runtime) error {
    done := make(chan struct{})
    defer close(done) // 让超时 goroutine 在本次执行结束后退出

    go func() {
        timer := time.NewTimer(100 * time.Millisecond)
        defer timer.Stop() // 避免定时器资源继续存活
        select {
        case 

这里的重点是生命周期：超时 goroutine 不负责调用第二次脚本，执行方也不能在 RunString 尚未返回时读取或修改 Runtime。若实际项目使用 context.Context，同样应在 ctx.Done() 后发出一次 Interrupt，并等待执行调用结束。

在下一次执行前调用 ClearInterrupt

Goja 的中断状态会留在 Runtime 内部。第一次执行返回后，先在执行线程中调用 ClearInterrupt，再决定是否重跑；不要把它当成“忽略错误”的替代品。中断原因仍应记录，因为超时、用户取消和资源保护通常需要不同的上层处理。

func rerun(vm *goja.Runtime, source string) (goja.Value, error) {
    // 上一次 RunString 已经返回，此时清除残留的中断标记。
    vm.ClearInterrupt()

    // 重新执行仍可能产生新的脚本异常，不能复用上一次的 err。
    value, err := vm.RunString(source)
    if err != nil {
        return nil, fmt.Errorf("rerun failed: %w", err)
    }
    return value, nil
}

如果忘记这一步，第二次运行可能在刚进入解释循环时就再次退出，看起来像“Goja 不能继续执行”。实际原因是上一轮的中断标记还没有被清除。清除动作只针对标记，不会清空全局变量，也不会恢复对象的旧值。

检查脚本状态是否允许复用

ClearInterrupt 解决的是控制状态，不解决业务状态。假设脚本先把 counter 加一，再进入死循环，那么中断后这个加一动作是否已经发生，取决于脚本执行到哪一步。宿主还可能已经写入缓存、发送消息或修改 Go 对象。

可以按下面的边界选择：

另外，Goja 官方说明 Runtime 不能被多个 goroutine 同时使用。负责执行脚本的 goroutine 应串行完成清除、状态判断和重跑；只有触发中断的 goroutine 可以通过公开的 Interrupt 发出请求。

协调超时 goroutine 再次执行

最容易被忽略的故障是：第一次超时后调用了 ClearInterrupt，但旧的定时器随后又触发一次 Interrupt，于是第二次运行再次被打断。解决方法是让每次运行拥有独立的取消通道，并在 RunString 返回前后都保证触发器已经退出。

func runWithRetry(source string) (goja.Value, error) {
    vm := goja.New()
    stop := make(chan struct{})

    go func() {
        timer := time.NewTimer(100 * time.Millisecond)
        defer timer.Stop() // 每次运行只管理自己的定时器
        select {
        case 

生产代码还应等待触发 goroutine 结束，并为每次重试创建新的输入快照。若无法证明脚本副作用可回滚，最稳妥的方案不是反复清标记，而是丢弃旧 Runtime。

用可观测结果验证重跑边界

排查时建议至少记录三类信息：第一次执行返回的错误类型和原因、何时执行了 ClearInterrupt、第二次执行的返回值或新错误。若第二次立即失败且错误仍是中断，优先检查旧触发器和清除时机；若第二次能执行但数据重复，问题在脚本状态或宿主副作用，而不是中断标记。

常见问题

调用 ClearInterrupt 后能恢复脚本断点吗？不能。它只是清除 Runtime 的中断标记，Goja 没有把被打断的脚本自动恢复到原位置的语义；重跑通常意味着从入口重新执行。

可以在另一个 goroutine 里直接 ClearInterrupt 吗？不要这样设计。把 Runtime 的清理和下一次执行放在同一条串行执行路径中，触发中断的 goroutine 只负责调用 Interrupt 并等待退出信号。

什么时候一定要新建 Runtime？当脚本写入了不可逆的宿主状态、全局对象已经不可信，或重跑无法重新构造确定输入时，新建 Runtime 比清标记后继续使用更安全。

本文依据 Goja 项目第一方资料中的 Interrupt 示例、运行时中断接口与 Runtime 并发边界整理，官方地址：https://github.com/dop251/goja。