自动关联目录：目标裁剪：禁用插件列表不是可证明的能力矩阵

核心判断：UE Target 中不断追加 DisablePlugins 能快速缩小包体，却只能表达“不要什么”；可维护的轻量运行时必须先声明“需要哪些能力”，再由构建系统推导模块、插件、代码宏和资产切片。

一、业务冲突

编辑器、普通客户端、DS 和轻量运行时共享玩法与内容契约，但展示、创作、音频、网络和平台 SDK 需求不同。早期 Client/Server Target 主要在配置和少量插件上分叉；轻量目标加入后，需要裁掉编辑 UI、高级几何、部分音频、桌面桥和非目标平台能力。

二、实际实现

工程新增独立轻量 Client Target，显式关闭编辑、复杂 UI、工具桥和本地会话，并禁用一批 UE/业务插件。运行模块同时用 Target 类型、平台和轻量宏裁剪依赖；编辑模块在 DS 或轻量目标中直接抛出 BuildException。验证脚本检查 UBT Manifest、链接证据、Lua 交付内容和运行包字节。

三、值得保留

裁剪已经不只是运行时 if：真正从 Build.cs、插件加载和链接结果移除了代码。独立 Target 也让 DS、编辑器和轻量包能分别构建验证。对不允许进入目标的编辑模块 fail fast，比依赖调用者记住 WITH_EDITOR 更可靠。

四、结构性缺陷

插件黑名单在多个 Target 复制，新增插件默认可能被带入；模块中还存在按 Target 名字符串判断能力。宏、插件、模块和资产规则分别维护，容易出现“代码裁了但插件描述仍要求加载”或“插件禁了但依赖仍链接”的双重配置问题。

五、目标设计

TargetProfile Lightweight {
    capabilities = { Gameplay, BasicUI, HttpClient, LightweightAudio };
    forbidden = { Authoring, DesktopBridge, HighEndGeometry, DedicatedServerSDK };
    assetPolicy = "lightweight-runtime-v1";
};

BuildPlan Resolve(TargetProfile p, DependencyGraph g) {
    auto closure = g.RequiredBy(p.capabilities);
    RequireNone(closure, p.forbidden);
    return GenerateModulesPluginsDefinesAndAssets(closure);
}

能力元数据归属于模块和插件，Target 只选择 Profile。构建后再从 UBT Receipt、链接输入、插件清单和 Pak Manifest 反向证明产物与计划一致。

六、取舍与验证

白名单模式会在迁移初期暴露大量未声明依赖，也需要维护能力图；但新模块默认不进入最小目标，风险方向正确。每个 Target 必须做编译、启动、关键功能和禁入项四类测试，不能以“包体变小”替代功能证明。