Anchor框架下如何正确实现Solana PDA账户间的关联引用

Account<'info, T> 是Anchor框架专门用于指令账户上下文的类型，它绑定了单次指令执行的生命周期，持有对传入指令的账户数据的引用，本身不具备序列化到链上持久存储的能力，因此不能直接作为#[account]标记的链上存储结构体的字段。编译器提示的添加生命周期参数的方案仅能绕过表层编译检查，本质不符合Solana的账户模型——链上账户是独立的存储单元，你无法在一个账户的存储空间里直接嵌套存储另一个完整账户的带引用结构。

链上存储关联账户的标准做法是：直接存储关联账户的公钥（Pubkey类型，固定32字节），需要访问关联账户数据时，在指令的账户上下文里把对应账户作为独立参数传入，再校验传入账户的地址和存储的公钥匹配即可。

修正后的存储结构体代码 #

use anchor_lang::prelude::*;

#[account]
pub struct MyNodes {
    xyz: u32,
    abc: u32,
    etc: u64,
    // 存储推荐人PDA的公钥，支持序列化持久化
    aff_account: Pubkey,
}

如果允许用户无推荐人，可以将字段改为Option<Pubkey>，无推荐人时存None即可，Anchor会自动处理可选字段的序列化逻辑。

关联关系校验示例（奖励结算指令） #

在需要读取推荐人数据做奖励结算的指令中，将推荐人PDA作为独立账户传入，通过Anchor的账户约束自动校验地址匹配，避免传入错误账户：

#[derive(Accounts)]
pub struct SettleReferralReward<'info> {
    // 当前用户的MyNodes PDA，按你的种子规则校验地址合法性
    #[account(
        seeds = [user.key().as_ref()],
        bump,
    )]
    pub user_nodes: Account<'info, MyNodes>,

    // 推荐人的MyNodes PDA，自动校验地址和user_nodes中存储的公钥一致
    #[account(
        address = user_nodes.aff_account,
        // 可补充自定义PDA种子校验逻辑，进一步确认传入的是合法MyNodes账户
        seeds = [aff_user.key().as_ref()],
        bump,
    )]
    pub aff_nodes: Account<'info, MyNodes>,

    #[account(mut)]
    pub user: Signer<'info>,
    /// CHECK: 仅作为推荐人PDA的种子校验用，不需要读写其原生账户数据
    pub aff_user: UncheckedAccount<'info>,
}

• 所有标记#[account]的链上存储结构体，字段必须是实现了AnchorSerialize/AnchorDeserialize的固定大小自有类型，所有带'info生命周期的类型（Account、Signer、UncheckedAccount等）只能用在标记#[derive(Accounts)]的指令上下文结构体中，不能存入链上持久存储。
• 不要尝试在一个账户中嵌套存储另一个账户的完整数据：Solana的账户是独立存储单元，跨账户访问必须将目标账户显式传入指令，这种设计也能避免单账户数据超过Solana 10MB的单账户大小上限。

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