Solana程序内联调用初始化/更新指令报BorshIoError反序列化失败

我知晓目前最通用、受推荐的实现方式是拆分"initialize初始化"和"update更新"指令，在客户端将二者打包进单笔交易中执行，但我想了解是否可直接在链上程序端实现该类组合逻辑。

我编写了两个所需账户数量、函数入参完全一致的处理函数，二者仅在状态初始化、状态更新的业务逻辑上存在差异。原本预期会收到运行时错误，实际却触发了反序列化失败报错。

希望能得到出现BorshIoError报错的原因解释，以及对应的可行解决方案，相关代码如下：

指令1：process initialize_deposit #

fn process(...)->ProgramResult{  
    // 初始化业务逻辑
    {
        Logic...
    }

    // 直接调用update_deposit指令处理函数
    crate::processor::update_deposit::process(program_id, accounts, update_idx, amount)?;

    Ok(())
}

指令2：process update_deposit #

fn process(program_id, accounts, update_idx, amount)->ProgramResult{
    ...

    let registrar: Registrar = Registrar::try_from_slice(&registrar_info.try_borrow_data()?)?;

    // 此处触发反序列化失败报错
    let mut depositor: Depositor = Voter::try_from_slice(&depositor_info.try_borrow_mut_data()?)?;
}

该实现初始思路参考Anchor框架的公开源码实现。

触发BorshIoError反序列化失败主要有两个核心原因，按排查优先级排序：

• 类型不匹配笔误：从贴出的代码可以看到明显写法问题：声明接收反序列化结果的变量类型为Depositor，但实际调用的是Voter::try_from_slice做反序列化。如果Voter和Depositor两个结构体的Borsh序列化布局不一致，会直接触发反序列化格式错误。
• 账户可变借用冲突：当前实现是在同一个函数栈内直接调用另一个指令的处理函数，和参考实现的CPI跨程序调用逻辑有本质区别：
  • 如果initialize_deposit逻辑中已经持有了depositor_info账户数据的可变借用（比如初始化写入数据后没有主动释放引用），后续update_deposit里再次调用try_borrow_mut_data()时，会拿到被锁定的、可能未完全写入的脏数据
  • Solana账户借用规则明确要求同一时间只能存在一个可变引用，重复获取可变引用本身就可能触发借用冲突，进一步导致Borsh读取数据失败。

按实现稳定性、性能优先级排序：

• 先修正低级笔误：把反序列化调用和接收类型对齐，确认使用Depositor::try_from_slice做反序列化，排除基础错误。
• 最优实现：抽离核心业务逻辑，避免直接嵌套调用指令入口。不要直接复用指令层的process函数，把初始化、更新的核心逻辑拆成独立的内部函数，直接接收已经反序列化好的账户结构体作为参数：初始化逻辑完成Depositor实例创建后，直接把内存中的Depositor可变实例传给更新逻辑函数，全程只持有一次账户数据的可变借用，所有逻辑处理完成后统一序列化写回账户，从根源上避免重复借用、重复反序列化的问题，这也是链上程序实现组合逻辑的标准方案。
• 如果要保留直接调用process函数的写法：在initialize逻辑写完账户数据后，手动drop掉所有持有该账户数据的可变引用（包括反序列化得到的结构体变量、账户数据切片变量），确认所有借用完全释放后，再调用update_deposit的process函数。
• 对齐参考实现逻辑：通过Solana正式CPI接口发起同程序内的跨指令调用，而非直接在栈内调用process函数，由Runtime自动处理账户借用刷新、数据状态同步，缺点是会产生额外的CPI调用开销。

内容的提问来源于stack exchange，提问作者Jarek Lin