new.target 仅能检测构造函数是否被 new 调用，无法保障材质派生的安全性；真正安全依赖资源预加载、technique 索引校验、defines 同步及 pipeline states 显式设置等引擎原生机制。
new.target 本身是 JavaScript 的运行时元属性，用于检测构造函数是否被 new 调用，它不直接参与图形引擎的材质系统设计，也不具备类型约束、继承校验或资源安全派生能力。在 Cocos Creator、Unity 或 Unreal 等主流图形引擎中，材质的“派生”本质上是数据实例化过程（如从 Effect 创建 Material 实例），而非 JavaScript 类的继承行为。
材质派生的真实机制不在 new.target 上
以 Cocos Creator 3.x 为例：
- 材质系统核心是
Material（实例）、Effect（着色器定义）、Technique和Pass四层结构，全部基于资源配置和运行时绑定 -
Material实例由编辑器或脚本通过new Material()创建，但其有效性取决于是否正确关联了已加载的EffectAsset - 所谓“派生”，实际是复用同一
Effect并差异化配置defines（宏开关）、properties（uniform 值）或technique索引——这些都在运行时校验，与new.target无关
强行用 new.target 做基础防护效果有限
若坚持在自定义材质类封装中引入 new.target，仅能做最表层的调用检查：
- 可防止用户误写
MyCustomMaterial()（非 new 调用），抛出错误提示 - 无法阻止传入非法
effectAsset、未加载的资源、错配的technique索引等真正导致渲染失败的问题 - 引擎底层（如 Cocos 的
Material类）本身并不依赖new.target做安全控制，它的健壮性来自资源加载状态管理与 shader 元信息校验
真正保障材质安全派生的关键点
应聚焦引擎原生机制和工程实践：
-
强制资源预加载校验：在创建
Material前，确保effectAsset已完成加载且有效（例如用resources.load+Promise链式等待） -
Technique 索引边界检查：手动设置
material.technique时，先读取effectAsset techniques.length，越界则 fallback 到默认项 -
Defines 动态同步：修改宏（如
USE_NORMAL_MAP）后，需显式调用material.define('USE_NORMAL_MAP', true)并触发重编译，避免静默失效 -
PipelineStates 显式声明：v3.0 新增的
depthStencilState、cullMode等必须按需设置，不可依赖引擎默认值，尤其在透明/遮罩材质中
把精力放在资源生命周期管理和 shader 元信息匹配上，比依赖 new.target 更直接有效。图形引擎的材质安全，本质是数据契约的落实，不是构造方式的语法限制。
