定义
Static Group（静态分组）指用户手动将设备加入分组，成员固定不变。与 Dynamic Group 动态分组互补，适用于按项目、区域等固定划分的 Device Grouping 场景。
特性与使用方式
静态分组由管理员或授权用户显式添加、移除设备，成员列表明确且可审计。支持批量导入、从 Dynamic Group 快照转静态等操作。分组可设置层级结构（如区域—站点—设备），便于权限继承与批量操作。适用于项目制部署、固定产线、特定客户设备池等成员相对稳定的场景，与按标签、属性自动匹配的动态分组形成互补。
与 DMP 功能的协同
静态分组作为批量操作的目标单元，支持对组内设备统一执行 OTA 升级、配置下发、Remote Maintenance 远程维护等。权限模型可基于分组实现 RBAC 数据隔离；告警规则、运维看板可按分组聚合展示。分组与 Device Tagging 设备标签可组合使用，静态分组侧重人工管理的固定集合，标签侧重灵活的多维分类。
应用场景
适用于能源站点的设备集群、制造产线的工位设备、楼宇的楼层设备等。当设备归属明确、变更频率低时，静态分组便于运维人员快速定位与操作；当设备规模大、属性变化频繁时，可结合动态分组或混合策略，兼顾管理效率与灵活性。
成员名单是显式集合不是查询结果
静态分组保存的是一份被明确加入的设备标识列表。设备改了站点、标签或固件，也不会因此自动进入或离开这张名单。这和按条件即时筛选的动态分组相反：动态分组的成员是查询结果，每次执行都可能变化；静态分组的成员只在有人添加或移除时变化。批量升级、授权和告警订阅若需要“昨天批准的那一批”，就必须用显式名单，而不能用一条今天仍会算出不同结果的查询。
名单里应保存标识，而不是保存当时的显示名或属性副本。显示名会改，副本会过期，真正要约束的是哪一台设备。同一台设备可以同时出现在多个静态分组里，例如既属于某个项目，又属于某个夜间维护批次。权限若按分组授予，重叠时取并集还是交集必须事先定义，否则两个管理员会算出不同的可见集合。移除设备只影响这份名单，不应连带删除设备本身或它在其他分组中的成员资格。
适合成员变更少且需要审计的场合
静态分组适合项目交付清单、一条产线的固定工位、一个站点已经验收的设备。这些集合的变化频率低，而且每一次进出都需要留下是谁在什么时候改的。它不适合“所有温度高于某值的设备”这类时刻在变的集合，那是查询或动态分组的工作。使用前应确认有人负责维护名单；没有负责人的静态分组会在几个月后仍包含已拆除的设备。
从动态分组生成静态快照是合理的交接方式：某一时刻把筛选结果冻结，交给不能承受成员漂移的升级任务。冻结之后，两边不再自动同步。新装设备若也要加入升级，必须再次人工加入或重新冻结。分组上的规则和报表要知道自己读的是冻结名单还是实时查询，不能在配置里只写一个分组名字就假定语义。
把快照分组继续当成动态名单
最常见的错误是把一次导出或一次筛选结果建成静态分组后，仍以为后来满足条件的设备会自己出现。新设备已经入网，升级任务却只覆盖旧名单，漏升的设备在报表里被当成“尚未纳入项目”。任务创建页应显示名单的冻结时间和台数，并在执行前允许对照当前筛选差异，由人决定是否吸收差异。
另一种错误是用静态分组代替权限边界，却允许任何编辑者增删成员。成员可以被加进自己无权限的设备时，分组就成了越权通道。增删成员应再次检查操作者是否本来就能访问该设备。已拆除或已报废的标识若留在名单里，批量任务会反复对它们失败，失败数被误读成升级质量问题。名单维护应把无法再连接且已报废的标识移出，并保留历史成员记录供审计，而不是直接把分组删掉重建，那样会失去“当时批准了哪些设备”的证据。
变更名单时显示将要加入和将要移出的标识，并要求确认，避免一次粘贴把上千台错误导入后只能整组删除。确认记录包括操作者和前后台数。与升级或权限任务绑定时，任务开始后锁定当时的成员副本，执行期间对分组的编辑不影响这一次任务，下一次任务才使用新名单。若不锁定，执行到一半时有人移出设备，结果行会对不上创建时的审批。锁定的副本在任务结束前只读，结束后再按保留期清理。