自由学习记录（181）

​

AirGlow

一个 StaticMesh，可能是空气辉光、雾感、柔光体积、背景氛围用的装饰网格。

LightM_Rotator

看名字像灯光旋转控制器，下面挂了 FillLight_Rect、FillLight_Spot、KeyLight_Rect、KeyLight_Spot。这说明这个场景重点之一是 灯光布置：Key Light 主光、Fill Light 补光、Rect Light 面光、Spot Light 聚光灯。

所以这个场景想示例的不是"壁炉玩法"，而是一个 Fireside 风格的展示环境 ：暖色、柔和、像坐在火边聊天或展示角色的氛围。英文里 fireside 字面是"炉火旁 / 壁炉边"，语感上常指温暖、私密、柔和、室内感的场景，不一定真的要有一个可交互的 fireplace。

Fireside 是主场景，也就是 Persistent Level。
L_BaseEnvironment 是被放进 Fireside 里的一个子 Level / 环境层。

Persistent Level / 主关卡 。
Fireside (Persistent) 的意思是：Fireside 是当前这个组合场景的主容器。它不是"一个模型"，也不是"一个文件夹"，而是主 Level。UE 的多关卡系统里，Levels 窗口就是用来管理 Persistent Level 和 Sublevels 的。

L_BaseEnvironment 就是一个子 Level。它被加载进 Fireside 里，所以你在 Viewport 里能看到它里面的东西。

它为什么会显示在这里：因为你当前场景里存在不止一个可编辑的 Level，上面有 Persistent Level 和 L_BaseEnvironment。当 UE 发现你在一个多 Level / 多编辑上下文的场景里选中了 Actor，它就会在 Viewport 右下角显示这个浮层，告诉你两件事：第一，当前选中的 Actor 属于哪个 Level；第二，当前新增 Actor 会被放进哪个 Level。UE 官方多 Level 文档里说，Levels 窗口可以管理多个 Level，并且可把某个 Level 设为 current/current level；官方 World Composition 文档也明确写过，Levels 窗口里蓝色名称代表 current level，loaded levels 会有对应标记。Epic Games Developers+1

这个 UI 不是"选中 Actor 后才临时生成的属性显示" 。它是 Viewport 常驻的 当前编辑上下文选择器。选中 Actor 时，它会额外显示"Selected Actor(s) in ..."；不选中 Actor 时，它仍然存在，因为它负责的是"当前编辑上下文"，不是"当前选中对象属性"。

Current Context 是一个 全局编辑状态 。

它决定你接下来在 Viewport 里新建、拖入、粘贴的 Actor 默认放进哪个 Level。

所以即使你什么都没选中，它也有意义。因为你随时可能从 Content Browser 拖一个 Static Mesh、放一个 Light、创建一个 Blueprint Actor。这时 UE 需要知道：这个新 Actor 应该写入 Fireside (Persistent)，还是写入 L_BaseEnvironment。

这两个选项不是来自某个 Actor，而是来自当前 World 已经加载的 Level 列表：

Fireside (Persistent)：主 Level。
L_BaseEnvironment：被加载进来的子 Level / Sublevel。

Streaming Levels 可以和 Persistent Level 重叠 ，也可以 偏移 用来组成更大的世界。这个说法很关键：如果它们可以重叠，就说明 Sublevel 不必天然代表"地图上的一块区域"。它也可以只是"同一空间里的某一类内容层"。Epic Games Developers

一种是 空间切割。例如开放世界、室内外切换、大地图分块。A 区域是一个 Level，B 区域是另一个 Level，玩家走近时加载，走远时卸载。这时 Level 像"地图瓦片"。这种切法主要服务于加载、内存、性能、流送。

另一种是 责任切割 / Context 切割 。例如同一个展示空间里，把基础环境放进 L_BaseEnvironment，灯光方案放进 Lighting Level，角色展示放进 Character Level，Cinematic 放进 Sequence Level。

它们在物理空间上可以完全重叠，但保存、编辑、协作、隐藏、替换时是分开的。

​

"Streaming Level"是运行时/加载管理概念。

它表示这个 Level 可以被加载、卸载、显示、隐藏。官方说 Level Streaming 的作用就是把 map files 加载到内存、从内存卸载，并在运行时切换可见性。Epic Games Developers

"Current Context"是编辑器写入目标概念。

它表示你现在在编辑器里新建、拖入、粘贴 Actor 时，默认写进哪个 Level。官方的多 Level 工作流里，可以在 Levels 窗口管理 Persistent Level 和 Sublevels，也可以把某个 Level 设为当前工作 Level。Epic Games Developers

所以一个 Level 只要被加载到当前 World 里、可以作为编辑目标，它就可能出现在这个 Current Context 下拉框里。它是不是 Streaming Level，不影响它作为"编辑上下文"的身份。

你图里的情况可以理解成：

Fireside (Persistent) 是主 Level。
L_BaseEnvironment 是一个被放进来的子 Level。

如果它被设置为 Streaming Level，它仍然可以在编辑器里作为 Current Context。

你选 L_BaseEnvironment 后，新建的 Actor 就会保存进 L_BaseEnvironment.umap，而不是 Fireside.umap。

Sublevel / Streaming Level：被挂进来的子地图文件。

Streaming Level 主要描述的是 加载控制关系：某个 Level 在运行时或编辑器中可以被加载、卸载、显示、隐藏，加载方式可能是 Always Loaded、Blueprint 控制、Volume 控制、World Partition/Data Layer 等。

维度	问题	例子
Sublevel 维度	这个 .umap 是否被挂在当前 Persistent Level 下面参与编辑？	L_BaseEnvironment 出现在 Levels 面板里
Streaming 维度	这个 .umap 是否/如何被加载卸载？	Always Loaded、Blueprint Streaming、Streaming Volume

因此一个 Level 可以是：

Sublevel + Always Loaded

它是子 Level，但不做动态流送。主要用于团队协作、内容分层、文件拆分。比如环境层、灯光层、角色层。

Sublevel + Streamed

它是子 Level，同时运行时会按条件加载/卸载。比如玩家走近建筑内部才加载室内 Level。

Not in Persistent Levels list + Dynamically streamed

通过 LevelStreamingDynamic 在运行时加载。官方 Python API 里就写到，动态加载的 level 不一定要在 persistent map 的 Levels list 里，只要打包时包含即可。也就是说，"能被 streaming 加载"不等于"必须是当前 Persistent Level 的传统子 Level"。

Flatness = 平坦度 / 扁平程度
Detection = 检测
Level = 一个 UE 地图 / 关卡资产

所以它大概率不是一个普通"游戏地图"，而是 Content Examples 里的一个 功能演示关卡：用来演示某种"平坦度检测"逻辑。比如检测表面是否足够平、坡度是否满足条件、地形/网格局部是否可放置、是否可以贴合、是否可以作为生成/摆放条件等。

常见输入包括 PCG Volume、Landscape、Spline、Static Mesh、Actor、已有点数据等。

Get Landscape Data 就是在拿 Landscape 作为检测/采样的输入表面。

PCG 的核心中间数据经常是 Point。点不是只有位置，它还可以带 rotation、scale、density、bounds、seed、attributes 等属性。

第三层：过滤 / 判断 / 筛选。

PCG 很多节点不是"生成东西"，而是在筛数据。

比如按坡度、密度、标签、距离、碰撞、属性值筛选

Discard Points on Irregular Surface 就很典型：它会丢掉不规则表面上的点，只留下更适合放置的点。

这就是 FlatnessDetection 的主题：判断哪里足够平。

术语的起源可以追溯到 90 年代早期的 3D 游戏引擎（如 Quake 和 Unreal Engine 1 ），它反映了当时构建 3D 世界的一种核心哲学：构造实体几何 (Constructive Solid Geometry, 简称 CSG)。

• 术语沿用 ：随着引擎的发展，虽然现在主要的场景构建已转向 Static Mesh （静态网格体），但引擎依然保留了 Brush 这一术语，用于指代那些由引擎实时计算形状的几何体或 Volume（体积）区域。

"建筑上的笔触"。就像建筑师在图纸上落笔划定区域一样，关卡设计师使用 Brush 在 3D 空间中划定固体（Additive ）或空洞（Subtractive）的区域。

• Volume（体积）逻辑 ：当 Brush 用于 Trigger Volume 时，它变成了一个看不见的"功能刷"。你在关卡中放置它，相当于在特定空间内"刷"上了一层逻辑触发区域。例如，如果你布置了一个会导致 elimination （消除）的区域，你实际上是使用 Brush 划定了一个执行 elimination 逻辑的物理范围。

合并 / 分支 / 组织数据。PCG Graph 里经常会把多路点数据合并、相交、相减、Union。你截图右侧的 Union 就是把多路筛选后的点合并成一个输出集合。

最终把点变成 Static Mesh Instance、Actor、Spline、Volume、Attribute Set，或者把结果输出给下游 Graph/Subgraph。

• Inherited Status : Because the component is "hard-coded" into parent classes like ABrush or AVolume , it is labeled as Inherited. This ensures the core functionality of the volume or brush remains intact and cannot be accidentally broken by removing the root.
• Native Naming : The suffix "BrushComponent0 " is a native internal name assigned by the engine's reflection system to distinguish this specific instance of the class within the Actor hierarchy.
• Property Control : While the component itself cannot be deleted, you can still modify its Transform settings or specific Brush Settings (such as Brush Type or Solidity ) within the Details panel to change how the geometry interacts with the level.

PCGVolume 里面会有 BrushComponent：PCGVolume 需要一个体积边界，告诉 PCG "在哪个空间范围内生成/采样/计算"。这个边界不是 StaticMesh，也不是 Landscape，而是沿用了 UE 里 Volume 系统的老式几何表示：BrushComponent。

所以它不改名，主要不是因为名字好，而是因为它在引擎底层已经是一个长期存在的类型名。ABrush、UBrushComponent、Volume、BSP、Geometry Brush 这些系统有历史继承关系。官方 Geometry Brush 文档也仍然使用 "Geometry Brush Actors" 这个名称，并把它和编辑器里的几何体/关卡块体搭建联系在一起。

"lock in" 本来是体育、游戏、学习语境里的说法，意思是进入高度专注状态，比如：

Bro, lock in.

BrushComponent 不是"Volume 本身"，而是 Volume 用来表达边界形状的底层组件。

BrushComponent 不只服务 Volume。它也服务 BSP / Geometry Brush 体系。

Volume 是 Actor 层语义，不是组件层语义 。PCGVolume、PostProcessVolume、TriggerVolume、BlockingVolume 这些是不同 Actor 类型。它们都可以用 BrushComponent 定义空间边界，但它们的行为完全不同：PCGVolume 用来限定 PCG 生成范围，PostProcessVolume 用来限定后期影响范围，TriggerVolume 用来检测进入/离开，BlockingVolume 用来阻挡。把内部组件叫 VolumeComponent，会把"形状边界"和"Volume 行为"混在一起。

"形状边界"和"Volume 行为"混在一起。

ISM_PCG_Cube_8、ISM_PCG_Cube_9 这种组件，通常是 PCG Graph 执行后自动生成 / 管理的输出组件。

PCGVolume 上有 PCG 相关执行环境。

PCG Graph 运行，产生一批 Points。

Graph 里的 Static Mesh Spawner / Spawn Static Mesh 类节点读取这些 Points。

每个 Point 提供一个 transform：位置、旋转、缩放、seed、bounds、属性。

Spawner 根据 mesh 类型，把同一种 Static Mesh 的大量点合并进一个 Instanced Static Mesh Component。

于是你在 Details 组件树里看到 ISM_PCG_Cube_8 这种自动挂出来的组件。

先有 PCGVolume / PCGComponent / PCG Graph，后有这些 ISM 生成结果。

不是像普通 Blueprint 那样，你先手动 Add 一个 InstancedStaticMeshComponent，然后自己写循环 Add Instance。PCG 是根据 Graph 的结果自动创建和维护这些组件。官方 PCG 节点参考里也把 Static Mesh Spawner 归为把点生成 Static Mesh 的输出节点；

PCG 重新生成时，如果每次都把成百上千个 cube 烘焙成一个新 Static Mesh，就涉及创建/更新 Mesh 资产或运行时 mesh buffer。ISM 只需要维护"同一个 mesh + 一堆 transform"，更适合频繁重算。

统一 SM 会复制所有 cube 的顶点数据；ISM 共享一份 mesh 顶点数据

剔除、LOD、实例管理更自然。ISM/HISM 这一类系统就是为"大量重复物体"准备的。比如草、石头、树、碎石、瓦片、重复建筑件。统一大 SM 虽然也可能减少 draw call，但它会把所有东西变成一个整体，粒度太粗；ISM 至少保留"这些都是同类实例"的结构。

手动挂 ISM 也可以，但那是你自己写生成系统；PCG 默认就是自动帮你挂和维护。

静态交付

​

​

"tinynocky / tiny / 10/07/2025 08:00" 这一行很像聊天软件或社区消息的头部。它不像 Blender、Notion、Google Docs 这类文档 UI，更像 Discord 风格：头像、用户名、身份/昵称标签、时间戳、消息内容。不能百分百确定是 Discord，因为画面被虚化和遮挡，但从布局上看，最接近"社区聊天消息"而不是正式剧本文档。

CU 基本就是影视分镜/镜头语言里的 Close-Up，也就是"特写"。所以他不是随便写日记，而是在写一个短动画的镜头分解：主角、手部特写、黑暗空间、敌人/小喽啰、眼神对视、动作突然停止之类。

"goons" 是口语，指小喽啰、打手、杂兵，不是正式奇幻术语。说明这可能是博主自己在社区里随手写的创意，不是完整剧本。

10/07/2025 08:00 。但这里有美式/英式日期歧义：

美式可能是 2025 年 10 月 7 日 08:00 ；

日/月/年格式也可能是 2025 年 7 月 10 日 08:00 。

因为用户名和英语社区语境偏美式，但不能仅凭截图定论。

"这只是写成文字的想法。但我们不是那种只会写 prompt 的人。光有文字是不够的。"

这里的 prompt bro 是近几年 AI 语境里的半调侃/半贬义说法，指那种主要靠写 AI prompt、说自己有创意、但不真正动手建模/动画/制作的人。类似中文里可以翻成：

"提示词哥"

"只会写 prompt 的人"

"AI 口嗨创作者"

"只会把想法写出来但不落地的人"

This glue should do the trick.

这个胶水应该能解决问题。

A restart might do the trick.

重启一下可能就好了。

Words alone won't do the trick.

光靠文字不会让这个东西真正成立。

不是在强调"trick 技巧"，而是在说"文字本身不能把这个创意变成成品"。语气比 Words alone are insufficient 轻很多，也更像创作者视频里的自然口吻。

It's not all sunshine and rainbows.

事情没那么美好。

常用于反讽：

会故意加入一些很私人的身体经验、尴尬细节、身份暗示和反差梗。

​

更倾向于 A-pose，因为 A-pose 的肩膀和上臂位置更接近自然站立状态，

更适合他后续的建模、雕刻或绑定需求。

​

​

你厌恶的是：别人给你一套看起来很合理、很成熟、很职业化的话术，然后你发现自己如果接受它，就像是在放弃自己的第一性判断。

Issue / Pull Request 模板

例如：

.github/ISSUE_TEMPLATE/
.github/PULL_REQUEST_TEMPLATE.md

作用是别人提交 bug、功能请求、PR 的时候，GitHub 自动套用模板。

比如 bug report 会要求填写：

Unreal Engine version:
Plugin version:
Steps to reproduce:
Expected behavior:
Actual behavior:
Logs:

Release / Changelog 自动化配置

例如：

.github/release-drafter.yml
.github/labeler.yml
.github/changelog.yml

作用是根据 PR、tag、commit 自动生成 release note。

仓库确实接入了 Smithery ，并且有一个叫 production 的部署环境。Smithery 是 MCP server 托管/发布平台之一，所以这里不是单纯的 GitHub Pages，而是把这个 MCP server 发布到了 Smithery 的服务器环境。

如果工具必须靠近用户本地软件，比如 Unreal Editor、Blender、Unity Editor、本地文件系统，通常更适合本地运行；如果工具只是访问云 API，比如 GitHub、Notion、数据库、网页服务，远程托管更合理。

只要它是符合 MCP 规范的 server，就可以发布/接入 Smithery；领域不限制。

它可以是 Unreal、Blender、Unity、数据库、浏览器自动化、文件系统、搜索、CRM、财务、文档检索、运维部署、设计工具等。Smithery 自己的定位就是 MCP server 的发布、分发、连接和观测平台。

目前 Smithery 文档里明确说，已经部署在别处的 MCP server 可以用 URL method 发布，只要 server 暴露 Streamable HTTP 就兼容；如果是本地 stdio 型 MCP server，则可以通过 MCPB bundle 这种本地包形式发布。

例如 Unreal MCP 可以放上去，是因为它的 MCP server 层可以作为一个可连接的 MCP endpoint 发布。但真正控制 UE Editor 的部分，通常还依赖你本机的 Unreal 插件/bridge。

Smithery 上托管/分发的是 MCP server 接口层

本机 Unreal Editor 里的插件负责执行具体 UE 操作

把一个 MCP 加到 Smithery，核心要符合这几类条件：

第一，必须是真正的 MCP server，不只是一个普通插件或脚本。

也就是它要能暴露 MCP 的能力对象：tools、resources、prompts 等。Smithery 发布时会扫描 server，提取这些 metadata，用来生成 server 页面；公开 server 会自动扫描，需要鉴权的 server 需要你先认证，扫不到时可以提供静态 server card。Smithery

第二，传输方式要符合 Smithery 支持的发布形态。

如果你的 MCP server 已经部署在别的服务器上，最直接的是 URL method ，要求 server 暴露 Streamable HTTP transport 。如果是本地 stdio 类型的 MCP server，则可以通过 MCPB bundle 发布成本地包。Smithery 文档明确说：任何暴露 Streamable HTTP 的 server 都兼容；本地 stdio server 可以用 MCPB bundle 发布。Smithery

第三，如果你的 server 需要登录或 API Key，要支持 Smithery 能处理的认证/配置方式。

URL 发布的要求里写得很直接：需要 Streamable HTTP transport；如果需要 auth，则需要 OAuth support。Smithery 会自动处理 client registration，不需要你手工注册 client。Smithery

如果只是用户输入 API Key、路径、偏好参数这类配置，Smithery 的 session config 会根据 server 类型传入：远程 HTTP server 通过 query parameters 或 HTTP headers，本地 stdio server 通过 command-line arguments。Smithery

第四，如果你想让 GitHub 仓库自动同步/自动部署，要安装 Smithery GitHub App。

Smithery 官方说明 GitHub App 用于自动部署 MCP server、创建 PR 状态检查、提供实时部署反馈。它需要 repository metadata、checks、commit status、deployments、issues、repository hooks 等权限；repository hooks 用来在代码变化时通知 Smithery，deployments 权限用于创建和管理部署流程。Smithery

也就是说你截图里的 Deploying to production by smithery 就来自这一套：

GitHub repo 更新
→ webhook 通知 Smithery
→ Smithery 尝试构建/部署
→ GitHub Deployments 页面显示状态

第五，如果它必须访问你本机的软件，例如 Unreal Editor、Blender、Chrome、本地数据库，就不能只靠云端托管。

这种情况要么设计成"云端 MCP server + 本地 bridge"，要么用 Smithery 的 Uplink。Smithery Uplink 的用途就是把运行在任意机器上的 MCP server 暴露为 Smithery connection；CLI 会保持安全隧道，把 Smithery 请求转发给本地进程。官方文档举例包括本地浏览器、本地数据库、SSH key、代码编辑器等只在特定机器上可访问的东西。

Smithery 的服务器列表页面本身就是一个 MCP server catalog，描述为"浏览 MCP servers，扩展 AI agent 的能力，查找并连接社区构建的 MCP servers"。Smithery 它还提供 REST interface，让开发者不用自己完整处理 MCP protocol、OAuth flow 和 credentials。Smithery

但 MCP 官方也有自己的 registry。官方 MCP Registry 的定位是"公开 MCP servers 的 primary source of truth"，同时允许组织创建 sub-registries。Model Context Protocol Blog 这说明生态结构不是"Smithery = 官方核心"，而是：

官方 MCP Registry
→ 协议生态的公共索引 / source of truth

Smithery
→ 商业化、工程化、易用化的平台层

GitHub modelcontextprotocol/servers
→ 官方/社区 reference implementation 和示例集合

Raycast、mcp.directory、Context7 等
→ 其他 registry / discovery / client ecosystem

Smithery 是怎么来的？它是在 MCP 变成一种事实标准之后出现的"基础设施层"。MCP 由 Anthropic 在 2024 年底推出，用来标准化 LLM 调用外部工具和数据源的方式；后续 MCP server 数量迅速增加，开发者需要 registry、安装器、托管、认证、部署平台。研究论文也把 MCP 描述为 2024 年底被引入、随后成为工具生态的 de facto standard。arXiv Smithery 的公开定位是帮助 AI agents 通过 MCPs 和 Skills 扩展能力。

类比会更清楚：

MCP specification
≈ USB 协议规范

MCP server
≈ 一个 USB 设备，比如键盘、相机、硬盘

Smithery
≈ 设备市场 + 驱动安装器 + 云托管 + 账号权限管理

Claude / Cursor / Copilot / Agent
≈ 使用这些设备的主机

它为什么重要？因为 MCP 的价值不在"协议文件本身"，而在"可调用工具集合的规模"。

.jules 是一个 隐藏配置目录 ，通常和 Google Jules AI coding agent 有关。

在 GitHub 里，以 . 开头的目录一般是工具配置目录，比如 .github 是 GitHub Actions / issue template / PR template 配置；.vscode 是 VS Code 配置；.jules 则大概率是给 Jules 这个 AI 编程代理看的配置、指令或运行辅助文件。

Jules 是 Google 的异步代码代理：它可以接入 GitHub 仓库，理解代码库，修改代码，运行测试，然后生成 diff、branch 或 PR。Google 官方说明里说 Jules 会和 GitHub 集成，用于修 bug、写文档、构建新功能，并且能在你不一直盯着的情况下异步处理任务。Jules+1

所以这个 .jules 目录的含义大致是：

它不是 UE 插件本体，也不是 MCP 运行核心。

它更像是：这个仓库曾经或正在被 Google Jules 这类 AI agent 操作、配置、检查或自动开发。

JavaScript 原本主要跑在浏览器里，用来写网页交互。Node.js 是把 JavaScript 运行时搬到浏览器外面，让 JS 可以在本机/服务器上运行。 所以 Node.js 可以写命令行工具、后端 API、文件处理脚本、构建工具、MCP Server。Node 官方也把 npm 解释为 Node.js 的标准包管理器，npm 生态有大量包，最早用于 Node 包依赖管理，后来也被前端广泛使用。Node.js

更准确的关系是：

JavaScript 是语言
TypeScript 是 JavaScript 的超集语言
Node.js 是 JavaScript 的运行时环境

也就是：

TypeScript
   ↓ 编译 / 转译
JavaScript
   ↓ 运行在
Node.js / 浏览器 / Deno / Bun / Electron / Cloudflare Workers 等环境

TypeScript 本质上是在 JavaScript 上加了类型系统，例如：

TypeScript

function add(a: number, b: number): number {
  return a + b;
}

这段 .ts 文件不能直接被传统 Node.js 当成普通 JS 执行，通常要先经过 TypeScript compiler，也就是 tsc，转成 JavaScript：

JavaScript

function add(a, b) {
  return a + b;
}

然后这个 JavaScript 才交给 Node.js 运行。

官方 MCP TypeScript SDK 很成熟。MCP 官方 SDK 页面列出 TypeScript SDK；官方 GitHub 说明这个 SDK 可以运行在 Node.js、Bun、Deno 上，并用于实现 MCP 规范。Model Context Protocol+1 对开源作者来说，用 TypeScript 写 MCP Server 成本很低。

安装路径简单。很多 MCP Server 不需要你先 clone 仓库，而是直接：

Bash

npx -y some-mcp-server

或者 Claude Desktop 配置里写：

JSON

{
  "command": "npx",
  "args": ["-y", "xxx-mcp-server"]
}

npx 会临时拉 npm 包并运行。这个体验非常适合 MCP：用户只要装 Node.js，就能启动大量工具服务器。

按 MCP 协议收发消息，就可以是任何语言。

Node.js 这个名字确实容易误导，因为它听起来像一个单独的 .js 文件。但它实际不是"一个脚本"，而是一个 JavaScript runtime environment，也就是"让 JavaScript 在浏览器外运行的一整套运行环境"。

名字可以拆成两层：

Node：强调它是网络程序里的一个"节点"。
.js：说明它运行的是 JavaScript。

类似地，很多 JS 生态项目也喜欢带 .js 后缀，比如：

React.js
Vue.js
Express.js
Three.js
Next.js

这里的 .js 通常不是指"一个脚本文件"，而是指"这是 JavaScript 生态里的一个技术/框架/库/运行时"。

React.js / Vue.js

主要是前端 UI 框架。它们的核心任务是描述和更新界面，也就是把数据状态映射到页面视图。React/Vue 本身更偏"界面层"。

Three.js

也是前端常见，但不是普通 UI 框架。它是 WebGL 3D 图形库，用 JavaScript 封装浏览器里的 GPU 图形 API，让你在网页里做 3D 场景、材质、相机、灯光、模型加载。它显示东西，但显示的是 3D 图形，不是按钮表单那种 UI。

Express.js

不是界面框架。它是 Node.js 后端 Web framework，用来写 HTTP API、路由、中间件、服务器逻辑。比如：

TypeScript 本质上是在 JavaScript 上加了类型系统