上界通配符（? extends T）是Java泛型的编译期类型约束机制，用于限定消费端只读访问SensorData及其子类，确保类型安全；它不替代运行时沙箱隔离，需与租户感知数据模型、AI沙箱执行环境及eBPF等机制分层协作，共同实现多租户传感器数据的精细管控。
上界通配符（? extends T）本身是 Java 泛型的编译期类型约束机制，不直接参与运行时数据流控制或沙箱隔离。它不能单独“应用”于传感器数据接入或安全隔离——真正起作用的是基于该类型设计思想所支撑的可扩展、只读、类型安全的数据抽象层，配合底层沙箱机制共同实现精细管控。
明确角色分工：泛型约束 ≠ 运行时隔离
上界通配符的核心价值在于限定消费端的数据读取边界。例如：
-
List<? extends SensorEvent>允许你安全地取出SensorEvent或其任意子类（如TempEvent、VibEvent）实例，但禁止向其中添加任何具体类型（除null），防止类型污染； - 在流水线的解析器→过滤器→分发器链路中，用
Consumer<? extends SensorData>声明下游处理单元，可确保它们只能读取公共接口方法（如getTimestamp()、getTenantId()），无法误操作私有字段或触发未授权行为。
这为后续沙箱策略提供了静态可验证的数据契约基础，但不替代运行时防护。
结合租户感知的传感器数据模型定义上界契约
要让上界通配符真正服务于多租户隔离，需从数据建模入手：
- 定义顶层接口
SensorData，内含tenantId()、deviceId()、timestamp()等租户/设备标识字段； - 各传感器类型实现为
TempData implements SensorData、AccelData implements SensorData等； - 流水线输入统一接收
Flux<? extends SensorData>（Reactor）或Stream<? extends SensorData>（Java 8+），强制所有接入数据必须满足该契约。
这样，即使接入协议混杂（MQTT JSON、Modbus 二进制、HTTP Protobuf），只要解析后封装为合规子类，上界通配符就能在编译阶段守住类型入口，避免非法数据混入处理链。
将上界契约与沙箱执行环境联动
静态类型安全需下沉至运行时隔离层才能闭环：
- 每个租户的传感器数据流，在进入处理逻辑前，由 租户上下文注入器 自动绑定其
tenantId，并加载对应沙箱配置（如允许访问的 Kafka Topic 分区、可调用的加密密钥 ID）； - 实际执行代码（如动态生成的规则脚本）运行在 AI Sandbox 中，该沙箱依据
tenantId加载权限策略（PAC）、启用 TEE 内存加密，并通过 eBPF 拦截越权系统调用； - 上界通配符保障了传入沙箱的数据对象是
SensorData的合法子类，而沙箱则确保该对象的tenantId字段不可伪造、其 payload 字段在解密前不可见、其序列化输出受 DMS 数据管理服务自动脱敏。
规避常见误用：不要试图用泛型做权限判断
以下做法无效且危险：
- ❌
if (data instanceof TempData)判断类型来放行——运行时类型检查无法阻止恶意构造的子类绕过； - ❌ 用
List<? extends SensorData>存储原始字节流再手动反序列化——破坏泛型契约，失去编译期保护； - ✅ 正确路径：所有接入数据先经 租户身份验签 + 数据格式校验 + 沙箱预加载 三步，再以
? extends SensorData形式交付给业务逻辑层。
本质是：上界通配符管能读什么，沙箱管在哪读、怎么读、读完能干什么。两者分层协作，缺一不可。
