自动关联目录：RPC 语义与可靠性

RPC 是"一次性动作"的通道：客户端告诉服务端"我开火了"，服务端告诉客户端"你被击中了"。它不适合持续状态——那是 属性复制 的事。

一句话定位：RPC 能不能执行，取决于调用者是不是这个 Actor 的"拥有者"；RPC 会不会丢，取决于 Reliable 还是 Unreliable。这两条解释了 90% 的"我的 RPC 没跑"。

三种 RPC

UFUNCTION(Server, Reliable, WithValidation)
void ServerFire(FVector_NetQuantize AimDir);

UFUNCTION(Client, Unreliable)
void ClientPlayHitFeedback(FVector_NetQuantize Location);

UFUNCTION(NetMulticast, Unreliable)
void MulticastExplosion(FVector_NetQuantize Location);

NetMulticast 从客户端调用时只在本地执行（不会广播出去）。这是刻意的设计：客户端没有广播权。

为什么"我的 RPC 没跑"

按概率排序：

最高频的一条是"谁拥有这个 Actor"。拾取物、门、箱子这些世界 Actor 默认属于服务端，客户端对它们调 Server RPC 会被丢弃——正确做法是在 PlayerController 或玩家 Pawn 上定义一个"转发用"的 Server RPC，参数里带上目标 Actor。

// 玩家身上：把"我想开这个箱子"发给服务端
UFUNCTION(Server, Reliable)
void ServerInteract(AActor* Target);   // Target 必须是可网络寻址的

拥有者（Ownership）速查

Actor->SetOwner(NewOwner);   // 可以显式转移（如玩家上车后拥有载具）

Reliable vs Unreliable

默认用 Unreliable。Reliable 是稀缺资源：UE 的可靠队列有上限，一个 200 次/秒的 Reliable RPC 在任何弱网下都会把连接挤爆。

// 错误示范：高频状态用 Reliable
UFUNCTION(Server, Reliable)
void ServerSetAim(FVector Dir);      // 每帧调用 → 迟早爆

// 正确：用 Unreliable，或干脆走属性复制/移动组件的输入
UFUNCTION(Server, Unreliable)
void ServerSetAim(FVector_NetQuantizeNormal Dir);

WithValidation

bool AMyActor::ServerFire_Validate(FVector_NetQuantize AimDir)
{
    return AimDir.IsNormalized();       // 返回 false → 判定为作弊/异常 → 断开该连接
}

void AMyActor::ServerFire_Implementation(FVector_NetQuantize AimDir)
{
    // 服务端执行
}

_Validate 返回 false 会直接踢掉连接，所以它只能用来拦"明显不可能"的输入（数值越界、状态机非法），不能用来做"业务上不允许"的判定——那会变成玩家开枪失败就掉线。

业务校验应该在 _Implementation 里做，返回一个 Client RPC 告知失败。

参数与带宽

一条 RPC 的实际成本 = 包头 + 函数标识 + 参数，高频调用时包头开销占比惊人。合并成一次批量 RPC 通常比多次小 RPC 划算。

与休眠、相关性的交互

Actor->FlushNetDormancy();   // 唤醒，下一次复制会处理

"休眠的 Actor 收不到 RPC"是常见困惑：休眠会暂停网络处理，唤醒后才会继续。

常见坑