简介：面向UE4开发者的Steam Friends API集成演示项目，以C++实现，展示了如何在UE4中调用Steam Friends并完成好友邀请、列表获取与加入会话的完整流程。项目代码按功能拆分为三个核心模块：GetFriendsListCallBackProxy作为蓝图节点封装异步获取好友列表的逻辑，NetBlueprintFunctionLibrary提供邀请好友的标准蓝图函数库，NetGameInstance则在邀请被接受时自动加入目标会话，三者配合可直接参考或移植到自己的联机项目中。压缩包仅7KB，共7个文件，包括3个头文件、3个C++源文件及1个Markdown说明文档，并保留了Source目录下Public与Private的标准UE4工程组织方式，便于快速定位好友列表获取、邀请发送以及会话加入等关键流程。已有311人学习下载，适合刚接触Steam API集成或希望了解UE4中异步等待与蓝图函数库扩展写法的中初级开发者，通过阅读源码可以快速掌握网络回调代理、游戏实例与会话加入的基本设计思路。
1. 这个 UE4 项目到底解决什么问题
做联机的开发大多遇到过这种尴尬：项目里明明已经接了 OnlineSubsystemSteam，好友列表却只能拿到一个空壳，想显示好友昵称、在线状态、正在玩的游戏，翻遍蓝图节点都找不到入口。这个 demo 把 UE4 的 Online Subsystem 黑匣子掀开，直接调 Steamworks SDK 里最原始的 Steam Friends API，用 C++ 把「好友列表拉取 → 状态变化监听 → 游戏邀请」整条链路做完整了。适合正在做联机社交功能、或者被引擎封装层憋得想骂人的开发者。它不解决匹配和联机传输，只专注解决一件事：让游戏的社交面板真正见到 Steam 好友数据。
2. 集成准备：Steam SDK 与在线子系统的初始化配置
2.1 技术栈分工：Steamworks SDK、OnlineSubsystemSteam 与中间层
这个项目的技术栈不算花哨，核心是三层：底层是 Steamworks SDK 提供的 C 风格接口，中间是 UE4 自带的 Online Subsystem 插件，最上面是自定义的 C++ 管理类。三层各有分工，不能互相替代。
SDK 层拿到的是 Steam 客户端的原生数据，比如好友 ID、昵称、在线状态、当前运行的游戏，这些接口性能好、实时性高，缺点是纯 C 风格结构体，直接暴露给蓝图不现实。OnlineSubsystemSteam 是引擎对 SDK 的封装，好处是有了统一的跨平台接口，坏处是它的 IOnlineFriends 接口针对全平台抽象，平台特有信息大量丢失。这个 demo 的做法是：保留 OSS 做会话管理，好友数据一律走 SteamFriends() 原始接口，再包一层 UFriendManager 转成蓝图能消费的 USTRUCT。这样的中间层大约四百行代码，就把平台差异和 UI 需求隔离开了。
UE4 项目里接入第三方 SDK 有个讲究：头文件包含要克制。steam_api.h 里一堆平台宏和 CSteamID 类型，一旦被蓝图相关的 generated.h 间接包含，编译报错能让你排查一下午。所以这个 demo 的设计原则是——头文件里只出现 int64、FString 这类 UE 类型，所有 CSteamID、ISteamFriends 相关逻辑全部下沉到 .cpp 文件。后面所有代码都会遵守这条约定。
2.2 Build.cs 模块引用：先把编译链路打通
工程要想编译过，第一步是让 Build.cs 把需要的模块挂上。这个 demo 的核心模块文件长这样：
// SteamFriendsDemo.Build.cs using UnrealBuildTool; public class SteamFriendsDemo : ModuleRules { public SteamFriendsDemo(ReadOnlyTargetRules Target) : base(Target) { PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs; PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "UMG" // UI 层要用的 Slate/UMG 模块 }); PrivateDependencyModuleNames.AddRange(new string[] { "OnlineSubsystem", // 引擎的在线抽象层，负责初始化判断 "OnlineSubsystemSteam", // Steam 平台的 OSS 实现 "Steamworks" // Steam 官方 SDK 的 UE 模块包装 }); } }Public 和 Private 的区分有实际意义。UMG 放进 Public 是因为 UI 相关的 USTRUCT 会被其他模块引用；而 Steamworks 放进 Private 是因为我不想让 steam_api.h 泄漏到依赖这个模块的上层代码里。如果你项目里没有现成的 Steamworks 模块，可以在 Plugins 目录下手动建一个包装插件，或者直接把 SDK 的 Include 目录加到 VC 项目的包含路径里。
Target.cs 里通常不需要特殊处理，但如果你是自己链接 steam_api64.lib，要在 Target 的 ExtraModuleNames 之外再补一段构造函数逻辑，把库路径指到第三方目录。这个 demo 因为是模块化引用，少了很多这类手工活。编译过了不代表初始化没问题，下一节说的 steam_appid.txt 才是新手最容易翻车的地方。
2.3 steam_appid.txt 与初始化顺序
Steam 客户端只愿意把好友数据交给「正在运行的、已被当前账号持有」的游戏。编辑器里跑 demo 的时候，项目经常不是通过 Steam 客户端启动的，这时候 SteamAPI_Init() 大概率失败。常规做法是在工程根目录放一个 steam_appid.txt，内容只写当前项目的 AppID，这个文件是官方允许的开发调试手段，让 SDK 在未启动游戏的状态下也能连上本地 Steam 客户端。
初始化顺序也值得较真。如果你已经启用了 OnlineSubsystemSteam，引擎启动时其实已经调用过一次 SteamAPI_Init，此时你再手动调一次会返回 false，容易误判成初始化失败。这个 demo 的做法是双保险判断：
// FriendManager.cpp 初始化 bool UFriendManager::Init() { // 优先检查引擎 OSS 是否已经把 Steam 拉起来了 IOnlineSubsystem* Sub = IOnlineSubsystem::Get(); if (Sub != nullptr && Sub->GetSubsystemName() == TEXT("Steam")) { UE_LOG(LogTemp, Log, TEXT("[FriendManager] 已通过 OSS 初始化 Steam")); return true; } // 独立初始化路径（不启 OSS 时的后备方案） if (!SteamAPI_Init()) { UE_LOG(LogTemp, Error, TEXT("[FriendManager] SteamAPI 初始化失败，检查 steam_appid.txt")); return false; } // 保存回调注册句柄，防止对象被 GC 后回调丢失 RegisterSteamCallbacks(); return true; }这段代码的说明：IOnlineSubsystem::Get() 拿到的是引擎当前启用的在线子系统实例，GetSubsystemName() 是 FName 类型，比较平台名用 TEXT("Steam") 而不是字符串字面量。RegisterSteamCallbacks() 是后面章节要展开的回调注册方法，放在 Init 末尾是为了确保任何 UI 操作都在初始化完成之后。如果 Init 返回 false，UI 层应该直接隐藏好友入口，而不是弹一个错误提示——给玩家看 Steam 初始化失败没有任何意义，只会让用户困惑。
3. 核心模块拆解：好友列表从 Steam 拉回到 UI 展示的完整链路
3.1 FFriendData 与 UFriendManager：数据结构和类职责
好友信息如果直接拿 SDK 的 FriendGameInfo_t 往 UI 传，蓝图侧根本没法用。demo 定义了一个纯 UE 类型的 USTRUCT，把需要展示的字段挑出来：
#pragma once #include "CoreMinimal.h" #include "FriendData.generated.h" // 只存 UI 需要的字段，避免把 SDK 类型暴露给蓝图 USTRUCT(BlueprintType) struct FFriendData { GENERATED_BODY() // 好友的 64 位 Steam ID，存为字符串避免蓝图侧 int64 精度丢失 UPROPERTY(BlueprintReadOnly, Category = "Steam|Friends") FString SteamId; // 当前昵称，随时间会变，不要当唯一标识 UPROPERTY(BlueprintReadOnly, Category = "Steam|Friends") FString NickName; // 0=离线 1=在线 2=忙碌 3=离开 4=打盹 5=想交易 6=想玩 UPROPERTY(BlueprintReadOnly, Category = "Steam|Friends") int32 State; // 好友正在玩的 AppID，0 表示没在玩游戏 UPROPERTY(BlueprintReadOnly, Category = "Steam|Friends") int32 PlayingAppId; };注意 SteamId 我坚持用 FString 而不是 int64。蓝图侧的 int64 虽然类型上标记了 BlueprintType，但做比较和存储时经常被隐式转成 float，精度一丢好友就认不出来了。存成字符串虽然丑一点，但在蓝图层做 == 比较绝对可靠。
UFriendManager 本身是个普通的 UObject，没有继承 UActorComponent，因为好友数据不依赖关卡存在，挂 GameInstance 或子系统里更合理。类里暴露一个动态多播委托，好友列表刷新后通知所有监听者：
// FriendManager.h 关键声明 DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam( FOnFriendListUpdated, const TArray<FFriendData>&, FriendList ); UCLASS(BlueprintType) class UFriendManager : public UObject { GENERATED_BODY() public: UFUNCTION(BlueprintCallable, Category = "Steam|Friends") void Init(); UFUNCTION(BlueprintCallable, Category = "Steam|Friends") void RefreshFriendList(); UPROPERTY(BlueprintAssignable, Category = "Steam|Friends") FOnFriendListUpdated OnFriendListUpdated; private: // 当前缓存的好友数据，UI 也可以同步读这个 UPROPERTY() TArray<FFriendData> CachedFriendList; };这里有个设计取舍：缓存数据的同时又广播委托，UI 存在双份数据源。我一般会让 UI 只吃委托事件，CachedFriendList 留给调试和序列化，不鼓励 UI 主动来拿。这样数据流是单向的，避免 UI 和缓存互相穿透之后逻辑乱掉。
3.2 拉取好友列表：三个关键 API 的组合
Steam Friends API 拉列表不是一次调用拿全量，而是「先问数量，再按索引取 ID，再拿 ID 换详情」的三步走。第一次接触这套接口的人容易被绕晕，习惯就好：
void UFriendManager::RefreshFriendList() { if (!SteamFriends()) { UE_LOG(LogTemp, Error, TEXT("[FriendManager] SteamFriends 不可用，确认初始化完成")); return; } // 第一步：问 Steam 客户端当前账号有多少个直接好友 int32 FriendCount = SteamFriends()->GetFriendCount(k_EFriendFlagImmediate); if (FriendCount <= 0) { CachedFriendList.Empty(); OnFriendListUpdated.Broadcast(CachedFriendList); return; } // 第二步和第三步：按索引遍历，逐个人取 ID 和详情 TArray<FFriendData> NewList; NewList.Reserve(FriendCount); for (int32 i = 0; i < FriendCount; ++i) { // 取第 i 个好友的 CSteamID CSteamID FriendId = SteamFriends()->GetFriendByIndex(i, k_EFriendFlagImmediate); if (!FriendId.IsValid()) { continue; } FFriendData Data; Data.SteamId = FString::Printf(TEXT("%llu"), FriendId.ConvertToUint64()); Data.NickName = FString(UTF8_TO_TCHAR(SteamFriends()->GetFriendPersonaName(FriendId))); Data.State = static_cast<int32>(SteamFriends()->GetFriendPersonaState(FriendId)); // 查好友当前是否在运行某个游戏 FriendGameInfo_t GameInfo; if (SteamFriends()->GetFriendGamePlayed(FriendId, &GameInfo)) { Data.PlayingAppId = GameInfo.m_gameID.AppID(); } else { Data.PlayingAppId = 0; } NewList.Add(Data); } CachedFriendList = MoveTemp(NewList); OnFriendListUpdated.Broadcast(CachedFriendList); }逐段说明。GetFriendCount 的参数k_EFriendFlagImmediate表示「已经是好友的」，区别于k_EFriendFlagAll（好友 + 待处理的好友请求）。如果项目需要显示好友申请列表，那要用 k_EFriendFlagRequestPending 单独拉，千万别在好友列表里混两种状态，会给自己制造麻烦。
GetFriendByIndex 的返回值是 CSteamID，它是个 64 位结构体，所以先调 ConvertToUint64() 再格式化成字符串。UTF8_TO_TCHAR 这个宏值得记住，Steam 接口返回的是 UTF-8 编码的 const char*，直接 FString() 构造在中文昵称场景下会乱码。GetFriendGamePlayed 的第二个参数是出参，函数返回值表示「是否真的在玩游戏」，而 GameInfo.m_gameID 是一个 CGameID 对象，AppID() 方法取到的才是我们认识的商店 AppID。这两个概念丢一个，玩没玩游戏就判断错了。
3.3 同步到 UMG：委托广播与列表控件绑定
数据拿到之后，UI 层不需要轮询，监听 OnFriendListUpdated 就行。在 WidgetBlueprint 里你会先创建一个ListView控件，Item 类型选一个UUserWidget子类（比如叫 WBP_FriendRow），然后在事件图表里做两件事：
听蓝图事件的过程是：在 Widget 的 Construct 事件里调用一次BindEventToFriendManager，这个函数内部拿到 GameInstance 里的 FriendManager 实例，然后拖出 OnFriendListUpdated 委托，用 AddDynamic 把自己蓝图里的自定义事件接上去。事件执行时，入口参数 FriendList 会提供给列表控件，调用 ListView 的 ClearListItems 清空旧数据，再用 ForEachLoop 遍历 FriendList，逐个 AddItem 添加行数据，最后重建列表项。WBP_FriendRow 里再监听 OnListItemObjectSet，把行里的 TextBlock 的 Text 绑定到当前项的 NickName。
纯 C++ 路径也可以走 AddDynamic，但我建议这个 demo 里 UI 层用蓝图，逻辑层用 C++。蓝图改 UI 布局不用重编 C++，迭代效率高不少，而且数据绑定这件事蓝图本质做的也是拖拽 Node，不容易写错。真正的性能瓶颈在大量好友同时刷新头像时，列表项频繁重建会卡顿——那是后话，优化方案放到最后一章。
4. 状态监听与游戏邀请：回调驱动的事件总线
4.1 Steam 回调机制与生命周期管理
好友列表是「拉取」出来的，状态变化却是「推」过来的。SteamFriends 提供回调通知：某个好友上线、改昵称、开始玩游戏，都会触发对应的回调结构体。这一章的代码是 demo 里最需要注意 JS 生命周期管理的地方，踩过的坑都是血泪。
// FriendManager.cpp 内联实现回调注册 void UFriendManager::RegisterSteamCallbacks() { // 好友个人信息变化：上线/离线/改名/头像更换都会触发 m_CallbackPersonaStateChange = SteamFriends()->RegisterCallback( PersonaStateChange_t::k_iCallback, [this](PersonaStateChange_t* pParam) { if (pParam == nullptr) return; // m_ulSteamID 是触发本次变化的那个好友 CSteamID ChangedFriend(pParam->m_ulSteamID); UE_LOG(LogTemp, Log, TEXT("[FriendManager] 好友状态变化: %llu, 变化类型 %d"), pParam->m_ulSteamID, pParam->m_iPersonaStateChange); // 直接全量刷新比精准更新单行更简单，代价可控 RefreshFriendList(); } ); // 收到好友发来的「邀请你加入他的游戏」请求 m_CallbackGameJoinRequested = SteamFriends()->RegisterCallback( GameRichPresenceJoinRequested_t::k_iCallback, [this](GameRichPresenceJoinRequested_t* pParam) { if (pParam == nullptr) return; CSteamID FriendId(pParam->m_steamIDFriend); FString ConnectString = FString(UTF8_TO_TCHAR(pParam->m_rgchConnect)); OnGameJoinRequested.Broadcast(FriendId.ConvertToUint64(), ConnectString); } ); }回调理解的难点在于 Steam 回调有两种注册方式。上面用的是 RegisterCallback 函数模板，它的特点是绑定对象和回调对象要能访问 m_Callback 成员，所以我把回调句柄 m_CallbackGameJoinRequested 声明成类成员变量——这一点非常重要，局部变量在函数结束时就析构了，回调会被反注册，表现就是「回调偶尔触发一次，之后就再也不来了」。
还有一种是 STEAM_CALLBACK 宏喷射式的声明方式，它会自动把回调对象插入类内部。那个方式代码少，但头文件里必须包含对应的 callback 类型头，容易造成编译污染。demo 里用 RegisterCallback + lambda 就是为了把回调跟 UI 类型解耦。
4.2 好友详情与头像：不只要名字
列表能显示了，接着发现需求比想象的细：光有昵称不够，得显示头像对吧？头像不在 GetFriendPersonaName 里，要走另一套接口：GetSmallFriendAvatar拿到的是 Steam Image 句柄，然后再调SteamUtils()->GetImageRGBA把头像像素拷出来，转成 UTexture2D。这段逻辑在 demo 里做了简化封装：
UTexture2D* UFriendManager::GetAvatarTexture(int64 FriendId) { // Steam Image 句柄，不是直接的文件路径 int32 ImageHandle = SteamFriends()->GetSmallFriendAvatar(CSteamID((uint64)FriendId)); if (ImageHandle == 0) { // 对方没头像时返回一个默认占位图，避免 UI 空指针 return GetDefaultAvatar(); } // 查询图片尺寸，SDK 要求先问大小再读像素 uint32 Width = 0, Height = 0; if (!SteamUtils()->GetImageSize(ImageHandle, &Width, &Height) || Width == 0) { return nullptr; } // 申请缓冲区并读取 BGRA 像素数据 TArray<uint8> RawData; RawData.SetNum(Width * Height * 4); if (!SteamUtils()->GetImageRGBA(ImageHandle, RawData.GetData(), RawData.Num())) { return nullptr; } // 用像素数据创建一个动态贴图，注意平台纹理格式 UTexture2D* Tex = UTexture2D::CreateTransient(Width, Height, PF_B8G8R8A8); if (Tex != nullptr) { void* TextureData = Tex->GetPlatformData()->Mips[0].BulkData.Lock(LOCK_READ_WRITE); FMemory::Memcpy(TextureData, RawData.GetData(), RawData.Num()); Tex->GetPlatformData()->Mips[0].BulkData.Unlock(); Tex->UpdateResource(); } return Tex; }这里有几个细节值得说。GetSmallFriendAvatar 返回 0 表示没有头像，这个分支千万别忘了。CreateTransient 创建出来的纹理是临时资源，不放进资源包，所以要在贴图数据锁定的生命周期内完成像素拷贝，主线程上做没问题，但别在异步线程里碰 UpdateResource。头像数据是 BGRA 排列，如果你直接把 RawData 塞给默认按 RGBA 处理的管线，颜色会全县红，这个可以写入经验库。
4.3 邀请加入会话：从好友行按钮到联机层
Steam Friends API 的邀请其实分两种：邀请对方加入你自己的游戏，以及响应对方的加入请求。第一个是主动行为，UI 上通常是好友行上的一个「邀请」按钮：
void UFriendManager::InviteToGame(const FString& FriendSteamIdStr, const FString& ConnectString) { // 从 UI 传入的字符串 ID 还原成 CSteamID uint64 FriendId = FCString::Strtoui64(*FriendSteamIdStr, nullptr, 10); CSteamID TargetId(FriendId); // ConnectString 是联机层给出来的会话连接串，一般是公网 IP:端口 bool bInvited = SteamFriends()->InviteUserToGame(TargetId, TCHAR_TO_UTF8(*ConnectString)); if (bInvited) { UE_LOG(LogTemp, Log, TEXT("[FriendManager] 邀请 %s 进入游戏"), *FriendSteamIdStr); } }ConnectString 怎么来？在监听服务器或者 listen 服务器建好会话之后，从 GameSession 拿，常见做法是UGameInstance::GetGameSession()->GetConnectString()。角色扮演一下：你在好友列表点击「加入游戏」，回调会告诉你m_rgchConnect就是对方会话里写好的连接串，你不需要自己拼 IP。
还有个容易误解的是 InviteUserToGame 只是把邀请通知推给对方，对方接受后走的是GameRichPresenceJoinRequested_t回调，所以这章开头那段回调注册代码才重要。整个链路是「UI 按钮 → C++ 邀请函数 → Steam 客户端弹邀请 → 对方接受 → 对方的回调 → 你的联机层跳转」，缺中间任何一环，邀请都会静默失败。调试时用两个 Steam 账号开两个客户端，观察双方的日志输出，别只盯自己的日志。
5. 避坑指南：UE4 集成 Steam Friends API 的常见问题排查
5.1 编译期与初始化类问题
现象一：GetFriendCount 永远返回 0，日志里连错误都没有。原因大概率不是代码，而是 steam_appid.txt 没放对位置，或者 Steam 客户端根本没跑起来。解决：先确认客户端在登录状态，把 steam_appid.txt 放到项目 Binaries 输出目录（比如 Binaries/Win64）和工程根目录各一份，然后调用处打印 SteamAPI_IsSteamRunning() 的结果，这个接口能快速定位是不是客户端没起。这个坑是初始化时序里最普遍的一个，很多项目上线后突然拉不到好友，多半是打包机器的 AppID 配置被环境变量覆盖了。
现象二：编译报错无法解析的外部符号，报错里能看到 steam_api 相关字样。原因：SDK 库没链进来。Build.cs 里加了 Steamworks 模块但 Target.cs 没把库路径传给链接器，或者模块名大小写不对导致没走指定的链接规则。解决：在 Target.cs 构造函数里用string SteamLibPath = Path.Combine(ModuleDirectory, ".../steam_api64.lib")手动加到 PublicAdditionalLibraries，同时确认 steam_api64.dll 会拷贝到打包输出的 Binaries 目录，只用 lib 不发布 dll，人家拿到你的成品一跑就崩。
现象三：重复调用 SteamAPI_Init()返回 false。原因：如果你的项目同时挂了 OnlineSubsystemSteam，引擎启动阶段已经初始化过一次，重复调用 SDK 自己的初始化函数会返回 false。解决：走双保险判断，优先用 IOnlineSubsystem::Get() 看平台是不是 Steam，不要一开始就裸调 SteamAPI_Init。这个在 2.3 节代码里写的就是这个逻辑，直接抄就行。
5.2 运行期与回调类问题
现象四：好友状态变化回调只有主动 RefreshFriendList 时才触发一次，之后再也不动。这基本是回调句柄生命周期问题。RegisterCallback 返回的回调对象如果被释放，Steam 回调系统会认为你不再关注这类事件。解决：回调成员变量声明与初值在 Init 里完成，不要放在局部函数里也不要用裸指针，确认 UFriendManager 本身是 GameInstance 持有的单例，不能在 Widget 里 new 一个用完就丢。
现象五：中文昵称显示成乱码。这个最玄学但原因也最明确：Steam 返回 UTF-8，你直接把 char* 给了 FString 构造函数，FString 默认按 TCHAR 解释。解决：统一用UTF8_TO_TCHAR()做一次转换，别手写 FString(ANSI_TO_TCHAR())，那个宏在 UE4 的 Linux 打包环境下不是 UTF-8 安全的。这个坑只出现在中文和日文昵称上，英文昵称一切正常，所以很多人上线很久才被海外用户反馈。
另外一个容易被忽略的：GetFriendGamePlayed返回的 m_gameID 是 CGameID 类型，不是单纯 AppID，直接转 int 会得到奇怪的负值。一定要先m_gameID.AppID()再赋给 int32。demo 里 3.2 节代码已经处理了这个，二次开发时千万别按自己直觉拆结构体。
6. 二次开发：把好友系统改造成可复用组件
最后一次动手前，先想清楚你项目里需要的是什么形态。如果只是某个页面要显示好友，现在的 UFriendManager 够用了；如果整个游戏有大厅、队伍、聊天等多个页面都要用好友数据，建议把它升级成 GameInstanceSubsystem，而不是挂在具体 Widget 上。
升级第一步是把 Init 从 BlueprintCallable 改成子系统自动初始化。继承 UGameInstanceSubsystem 后，Initialize 会在游戏实例创建时自动执行，不用再手动调 Init。第二步是把状态机抽出来：加一个 ESteamFriendState 枚举，别用裸 int32，蓝图侧做可读性会好很多。第三步，把委托拆成两个：一个是全量列表刷新 OnFriendListUpdated，一个是单条状态变化 OnFriendStateChanged，UI 根据自己需要订阅，列表页面订阅全量，头像小组件订阅单条，避免一次全刷新把几个列表同时洗掉。
头像加载建议加一层缓存。Steam 的 GetImageRGBA 每次都要拷贝整张图，好友列表 50 人全刷一遍，低端机直接掉帧。我一般会维护一张 TMap<FString, UTexture2D*> 存头像，查询时先看缓存，没命中再走 Steam 接口，并且把刷头像的操作隔帧做，每帧最多处理两个头像请求，保证 UI 不卡死。
最后给你一个可复现的验证技巧：不要一上来就接 UI。把 FriendManager 先挂在 GameInstance 上，用一个临时 Actor 在 BeginPlay 里调用 Init 和 RefreshFriendList，日志里打印列表数量和每个好友的昵称。这一步确认 Steam 链路通了你再做 UI 绑定，排查范围直接缩小一半。我自己的习惯是先跑一圈纯 C++ 验证再碰界面，这个顺序帮我少走了很多弯路。如果 UI 绑定完发现列表没出来，先看角落里 UE_LOG 有没有「SteamFriends 不可用」的报错，八成是初始化没走完就在 Widget Construct 里调了接口。希望帮到你。
本文还有配套的精品资源，点击获取
