是必须的。控制台会复用当前浏览器的登录状态，普通窗口已经登录了个人账号，点开实验控制台就直接进了自己的账号，不会切到实验下发的临时沙箱账号。正确做法是把实验页的「打开控制台」链接复制到无痕窗口打开，用实验页提供的沙箱账号和密码登录，进去后右上角显示的是 Sandbox-user 就对了；实验结束后沙箱会自动回收，不用自己去删资源，但在普通窗口里误开在个人账号下的资源需要手动清理。

容易丢失的业务规则字段值域、枚举限制（比如订单状态只能是指定值）跨实体的校验规则（比如下单时库存≥购买数量）关系约束（一对一 / 一对多的业务限制）派生计算逻辑（如实付金额 = 原价 - 优惠）

数据库建模完整流程 + 方法主流标准是IDEF1X / 实体关系ER建模，工程上一般分成：需求分析 → 概念模型 → 逻辑模型 → 物理模型 → 验证评审 → 落地迭代，同时配套范式、命名、约束规范。一句话区分三层模型：概念模型：业务有哪些东西、什么关系（不管数据库）逻辑模型：表、字段、主键外键、类型（还不绑定MySQL/Oracle）物理模型：引擎、索引、分区、存储参数、字符集（贴合具体数据库）一、1. 需求调研与梳理（建模起点）目标：搞清楚业务实体、业务规则、数据要存什么、查询场景梳理业务流程、报表、表单、接口文档识别实体（对象）：比如用户、订单、商品识别属性：实体身上的信息，订单号、下单时间识别业务规则：一个用户可以多个订单，一个订单属于一个用户（一对多）订单和商品是多对多，需要订单明细表做中间表记录访问模式：哪些查询多？哪些写入多？（后面用来反范式、建索引）产出物：业务字典、需求清单二、2. 概念数据模型 CDM（Conceptual）用ER图表达，不考虑数据库、不考虑字段类型元素：实体、属性、实体之间关系（1:1 / 1:N / M:N）多对多必须拆成关联实体（中间表） ✅ 示例：学生 -> 课程（多对多）→ 新建【选课】实体产出物：ER图（CDM） 常用工具：PowerDesigner、Navicat Data Modeler、DBeaver、DrawIO、PDManer三、3. 逻辑数据模型 LDM（Logical）把CDM翻译成表结构，还不绑定具体数据库，重点做规范化实体 → 表；属性 → 字段定义主键PK、外键FK、唯一键UK应用数据库范式（重点前3范式）1NF：字段不可再拆分（不要把多个值塞一个字段，比如标签不要逗号分隔）2NF：消除部分依赖，非主键字段完全依赖整个主键（针对联合主键）3NF：消除传递依赖，非主键不能依赖别的非主键大部分业务库做到 3NF；报表、大数据库经常主动反范式（冗余字段换查询速度）确定值域、约束：非空、枚举、校验规则产出物：逻辑表结构、关系图⚠️ 取舍：范式不是越高越好。高频联表查询会考虑适当冗余（反范式），比如订单表冗余商品名称，避免每次join商品表。四、4. 物理数据模型 PDM（Physical）落地到具体数据库（MySQL / PostgreSQL / SQL Server）给字段指定真实数据类型：varchar(64)、bigint、datetime、decimal主键策略选择：自增ID / UUID / 雪花ID（雪花ID适合分布式）建立索引：普通索引、联合索引、唯一索引（根据查询条件）数据库专属配置：MySQL：InnoDB引擎、字符集utf8mb4、排序规则分区表、分库分表规划（量大的时候）定义注释、统一命名规范（蛇形命名：user_id，禁止中文表名）产出物：PDM图、建表SQL脚本五、5. 校验、评审重点检查：主键是否稳定（不要用业务字段当主键，比如手机号会变）外键约束要不要开启（高并发系统很多业务层做关联校验，不开数据库外键）有没有循环依赖索引会不会过多（索引加速查询、拖慢写入）边界场景：软删除（is_deleted）、创建/更新时间 create_time/update_time权限、数据脱敏字段（手机号、身份证）六、6. 上线、迭代维护先在测试库执行建表脚本，验证CRUD版本管理：DDL脚本纳入Git，线上禁止直接删字段，优先新增、兼容旧接口随业务变更迭代模型，变更前评估数据迁移成本常用建模方法ER实体关系法（最通用，上面这套流程就是），适合绝大多数业务系统IDEF1X：偏严谨、适合政企大型系统，是ER的标准化版本维度建模（星型/雪花模型）：数据仓库、BI报表专用，不是OLTP业务库事实表：订单流水、支付记录（度量值：金额、数量）维度表：时间、用户、商品面向对象建模（UML类图转数据库）：后端DDD领域建模常用，类映射表 

多厂商设备没有统一 SDK 时，结论是协议归一放边缘、语义归一放平台：Modbus、BACnet、OPC UA 或厂商私有 TCP、私有 SDK 这些差异，都应该在边缘侧（比如部署在智能边缘平台 IEF 或园区边缘网关上的一个协议适配容器）转成标准 MQTT 加结构化 JSON，消息里固定带上 product_id、device_id、属性或事件名、原始时间戳和序列号，然后向上只吐这一种格式；而物模型的语义定义——属性、事件、服务、单位、枚举——必须留在 IoTDA 产品模型里统一维护，不能下沉到边缘写死，否则每接一家设备就得改一次代码、上层订阅也会各说各话。如果设备本身支持标准 MQTT/HTTPS，或者门禁摄像机能走 GB/T 28181 这类国标，且点位不多、不需要本地实时联动、网络也稳定,那就直接一机一密注册设备、用规则引擎把数据转发给 FunctionGraph 或 DMS 消费，一行适配代码都不用写；只有碰到四种情况才值得自建适配层：设备只有私有 SDK 或裸 TCP 协议没有标准出口、道闸消防这类需要毫秒级就近联动不能依赖云端往返、弱网断网必须本地自治并在恢复后补传、以及视频门禁这类大流量或强安全边界的数据不该混进遥测通道而要单独走视图接入。真要做适配层,最容易翻车的是把厂商字段到物模型字段的映射、量纲、时区、枚举值写进代码,应该做成配置或映射表,让新增设备只加配置不发版；转换前先保留原始报文落 OBS 或队列，映射出问题能回放、能追溯；子设备不要各自建连接，用网关加子设备代理注册，鉴权和在线状态才管得住，厂商侧的账号密钥放 DEW/KMS 托管而不是硬编码；最后以 device_id 加序列号或时间戳做幂等键，同一告警在窗口内合并做抖动抑制，因为噪声收敛不及时，园区事件中心最早爆掉的往往就是这里。

从节点不会自己主动去清理过期键。当主节点（Master）通过惰性删除或定期删除删除了一个过期 key 时，主节点会向所有从节点（Slave）发送一条 DEL 命令。从节点接收到这条 DEL 命令后，才会把对应的 key 删掉。在主节点真正删除并下发 DEL 命令之前，如果客户端在从节点读取这个过期的 key，从节点会假装这个 key 依然存在（返回正常数据），从而保证主从数据的一致性。

从节点不会自己主动去清理过期键。当主节点（Master）通过惰性删除或定期删除删除了一个过期 key 时，主节点会向所有从节点（Slave）发送一条 DEL 命令。从节点接收到这条 DEL 命令后，才会把对应的 key 删掉。在主节点真正删除并下发 DEL 命令之前，如果客户端在从节点读取这个过期的 key，从节点会假装这个 key 依然存在（返回正常数据），从而保证主从数据的一致性。

JWT 只解决一件事：让服务端在不查库的前提下确认“这串东西是我自己签发的、没被改过”。它是签名，不是加密。 【结构】header.payload.signature 三段。前两段只是 Base64URL，任何人拿到 token 都能直接读出 payload 里的用户 ID、角色、过期时间；第三段才是用密钥算出来的签名（HS256 用对称密钥，RS256 用私钥）。校验时服务端重算一遍签名比对。所以第一条铁律：payload 不要放手机号、身份证、密码这类东西，它等于明文。 【常见的坑，按严重程度排】 1、算法混淆与 alg:none。服务端必须写死“只接受哪一种算法”，绝不能从 header 里的 alg 读。否则把 alg 改成 none，或者把 RS256 降成 HS256、再拿公钥当 HMAC 密钥签名，就能伪造任意身份。 2、密钥太短或可猜。用项目名、域名当 secret 等于没有签名；同时要预留轮换（header 里带 kid，旧密钥保留一段时间），不然泄露只能全量下线。 3、写了 exp 但服务端没校验。exp/nbf/iat 都要手动判，注意单位是秒不是毫秒；只靠前端拦截等于没拦。 4、无状态的真实代价：无法主动作废。改密码、降权、删号都不会让已签发的 token 失效。两种解法：payload 里带版本号或 jti，校验时和当前配置比对（我把 role 写进 token，校验时拿 token 里的 role 和配置里的 role 比一次，配置一改旧 token 自然作废，不用等过期）；或者上 Redis 存黑名单，但那就放弃了无状态的好处。 5、存哪里。localStorage 方便，但 XSS 一抖 token 全走；HttpOnly + Secure + SameSite=Lax 的 Cookie 能挡住脚本窃取，但要自己处理 CSRF（最省事的办法是所有写接口要求一个自定义请求头，跨站表单发不出自定义头）。 6、反向代理后 secure cookie 被丢。应用如果以为自己跑在 HTTP 上，下发的 secure cookie 会被浏览器扔掉，现象是“登录成功但刷新又要密码”，很容易查错方向。 7、不校验 aud / iss。同一密钥给多个服务签发时，A 服务的 token 能直接拿去调 B 服务。 8、权限判断写在客户端。前端根据 role 隐藏按钮只是体验，服务端必须再拦一次，否则改一下前端就能越权。 【什么时候不该用 JWT】单体应用、单进程、需要“改密码立即失效”、纯内部接口，直接用服务端 session 更简单也更安全。JWT 的价值在于多服务多实例不共享存储，代价就是上面第 4 条那一堆作废问题。

JWT 只解决一件事：让服务端在不查库的前提下确认“这串东西是我自己签发的、没被改过”。它是签名，不是加密。 【结构】header.payload.signature 三段。前两段只是 Base64URL，任何人拿到 token 都能直接读出 payload 里的用户 ID、角色、过期时间；第三段才是用密钥算出来的签名（HS256 用对称密钥，RS256 用私钥）。校验时服务端重算签名比对。所以第一条铁律：payload 不要放手机号、身份证、密码这类东西，它等于明文。 【常见的坑，按严重程度排】 1. 算法混淆和 alg:none。服务端必须写死“只接受哪一种算法”，绝不能从 header 里的 alg 读。否则把 alg 改成 none，或者把 RS256 降成 HS256、再拿公钥当 HMAC 密钥签名，就能伪造任意身份。 2. 密钥太短或可猜。用项目名、域名当 secret 等于没有签名。同时要考虑轮换（header 里带 kid，旧密钥保留一段时间），不然泄露了只能全量下线。 3. 写了 exp 但服务端没校验。exp/nbf/iat 都要手动判，注意单位是秒不是毫秒；只靠前端拦截等于没拦。 4. 无状态的真实代价：无法主动作废。改密码、降权、删号都不会让已签发的 token 失效。两种解法：payload 里带版本号或 jti，校验时和当前配置比对（我把 role 写进 token，校验时拿 token 里的 role 和配置里的 role 比一次，配置一改旧 token 自然作废，不用等过期）；或者上 Redis 存黑名单，但那就放弃了无状态的好处。 5. 存哪里。localStorage 方便，但 XSS 一抖 token 全走；HttpOnly + Secure + SameSite=Lax 的 Cookie 能挡住脚本窃取，但要自己处理 CSRF（最省事的办法是所有写接口要求一个自定义请求头，跨站表单发不出自定义头）。 6. 反向代理后面 secure cookie 被丢。应用如果以为自己跑在 HTTP 上，下发的 secure cookie 会被浏览器扔掉，现象是“登录成功但刷新又要密码”，很容易查错方向。 7. 不校验 aud / iss。同一密钥给多个服务签发时，A 服务的 token 能直接拿去调 B 服务。 8. 权限判断写在客户端。前端根据 role 隐藏按钮只是体验，服务端必须再拦一次，否则改一下前端就能越权。 【什么时候不该用 JWT】单体应用、单进程、需要“改密码立即失效”、纯内部接口，直接用服务端 session 更简单也更安全。JWT 的价值在于多服务多实例不共享存储，代价就是上面第 4 条那一堆作废问题。