如何存储当前Method并在操作完库存系统后重新调用该方法

这个需求属于典型的上下文挂起-恢复模式，在各类带GUI交互的库存系统中应用非常广泛，完全可以实现。

核心实现逻辑 #

触发库存打开前，将当前待执行方法的上下文（方法本身、绑定宿主、入参、执行状态）暂存到全局容器中，监听库存操作完成/关闭事件，事件触发后取出暂存的方法上下文执行即可。

常见实现方案 #

1. 委托/回调暂存方案（通用性最高，适配C#/Java/JS/TS等绝大多数语言） #

• 提前定义统一的回调签名约束，比如C#使用Action/Func，JS直接存储函数对象
• 打开库存前，将需要恢复执行的方法、绑定的this对象、入参一起存入全局的PendingMethod变量/容器
• 监听库存界面的操作完成/关闭事件，事件触发后调用暂存的回调，执行完成后清空PendingMethod避免重复调用

示例伪代码（C#为例）：

// 全局暂存变量，多场景排队的话可以替换为Stack<Action>栈结构
public static Action PendingOperation;

// 触发打开库存前的业务逻辑
public void OnTriggerInventoryOpen()
{
    // 把后续要执行的逻辑封装为匿名方法存入暂存变量
    PendingOperation = () => ContinueCurrentOperation(currentPlayer, targetObject);
    OpenInventoryUI();
}

// 库存界面关闭回调
public void OnInventoryClosed()
{
    // 存在待执行逻辑就调用，调用后清空
    PendingOperation?.Invoke();
    PendingOperation = null;
}

2. 协程/生成器方案（适配支持协程特性的语言，比如Unity C#/Python） #

• 将完整交互逻辑拆分为两段，用协程的yield return语法挂起执行，直到收到库存关闭信号后再恢复后续逻辑
• 不需要额外存储回调，协程本身会保留当前的执行上下文，代码结构更简洁

3. 状态机方案（适配多分支复杂交互场景） #

• 将当前操作的状态标记为等待库存操作完成，存入玩家/交互对象的状态字段
• 通过帧轮询或者事件触发检测状态，如果状态为等待库存完成且库存已关闭，就执行对应的后续方法

注意事项 #

• 暂存方法如果携带引用类型入参，需要注意对象生命周期管理，避免出现空引用异常
• 如果存在多弹窗叠加、多个待恢复方法的场景，建议用栈结构Stack<T>存储待执行队列，后进先出的规则完全匹配弹窗的打开关闭顺序
• 如果库存支持取消操作，可以根据业务需求加判断条件，决定是否要执行暂存的方法

内容的提问来源于stack exchange，提问作者Leo Christensson