Files
soft_vue/前端设计说明.md
flowerstonezl fa137c7fa0 first commit
2026-04-20 16:49:18 +08:00

1115 lines
25 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# SoftBus 运维控制台前端设计说明
## 1. 文档说明
本文档用于定义 `softbus_daemon` 运维控制台的界面功能设计,目标不是单纯罗列接口字段,而是明确以下内容:
- 当前控制台面向哪些角色
- 页面为什么存在,各自解决什么任务
- 页面之间如何组成一条完整的操作闭环
- 每个页面依赖哪些接口与状态数据
- 哪些能力属于当前核心版本,哪些属于后续扩展版本
本文档覆盖两类范围:
- 当前已形成原型方向的核心页面
- 已进入产品规划、尚未全部实现的扩展页面
## 2. 产品定位与设计目标
### 2.1 产品定位
SoftBus 运维控制台是一个面向设备接入、运行监控、规则配置和数据映射的后台管理界面,主要服务于以下角色:
- 设备接入调试人员
- 协议与插件开发人员
- 运维人员
- 配置管理人员
- 前后端联调人员
### 2.2 核心目标
控制台需要同时承担四类职责:
- 查看系统当前运行状态,包括健康、版本、计数器、异常和规则状态
- 支撑 discovery 到 mapping 的接入配置流程
- 支撑 filter、transform、mapping 三类规则的查看与配置
- 为设备、Pipeline、插件、Metadata、Profiles 等信息提供统一的浏览入口
### 2.3 设计原则
- 以工作流为核心组织页面,而不是仅按接口目录平铺
- 首页负责判断状态和分发任务,不承载所有详情
- 高频配置优先采用“筛选区 + 列表/表格 + 抽屉/侧栏”的后台交互模型
- 对“已生效”和“仅注册未接入执行链路”的能力必须明确区分
- 对实时状态、空态、异常态和后端能力边界做清晰提示
## 3. 信息架构与导航设计
### 3.1 总体导航结构
建议后台采用左侧导航,结构如下:
- 总览 Dashboard
- 发现接入工作台
- 规则映射中心
- 过滤规则
- 转换规则
- 映射规则
- 设备管理
- Pipeline 监控
- 插件中心
- Metadata
- Profiles
### 3.2 当前原型与规划页面分层
当前文档需要明确区分“已经进入当前原型主线”的页面与“后续继续建设”的页面:
- 当前核心原型页
- Dashboard
- 发现接入工作台
- 过滤规则
- 转换规则
- 映射规则
- 规划扩展页
- 设备管理
- Pipeline 监控
- 插件中心
- Metadata
- Profiles
### 3.3 页面关系图
```mermaid
flowchart TD
dashboard[总览Dashboard]
discoveryWorkbench[发现接入工作台]
rulesCenter[规则映射中心]
deviceCenter[设备管理]
pipelineCenter[Pipeline监控]
pluginCenter[插件中心]
metadataCenter[Metadata与Profiles]
dashboard --> discoveryWorkbench
dashboard --> rulesCenter
dashboard --> pipelineCenter
dashboard --> deviceCenter
discoveryWorkbench --> mappingFlow[发现到映射闭环]
rulesCenter --> filterRules[过滤规则]
rulesCenter --> transformRules[转换规则]
rulesCenter --> mappingRules[映射规则]
deviceCenter --> deviceTree[设备树]
deviceCenter --> deviceRuntime[运行态设备]
pluginCenter --> protocolMatrix[协议能力矩阵]
metadataCenter --> metadataPage[Metadata]
metadataCenter --> profilesPage[Profiles]
```
### 3.4 当前原型对应关系
当前项目已经围绕以下结构形成原型入口:
- `Dashboard` 作为系统总览首页
- `发现接入` 作为 discovery 和 mapping 的工作流页
- `规则映射` 作为规则中心,拆分为过滤、转换、映射三个页面
这一结构已经体现在路由层:
```33:109:src/router/index.js
export const constantRoutes = [
{
path: '/',
component: Layout,
redirect: '/dashboard',
children: [{
path: 'dashboard',
name: 'Dashboard',
component: () => import('@/views/dashboard/index'),
meta: { title: 'Dashboard', icon: 'dashboard', affix: true }
}]
},
{
path: '/discovery',
component: Layout,
children: [
{
path: 'index',
name: 'DiscoveryWorkbench',
component: () => import('@/views/prototype/discovery/index'),
meta: { title: '发现接入', icon: 'search' }
}
]
},
{
path: '/rules',
component: Layout,
redirect: '/rules/filter',
name: 'RuleCenter',
meta: { title: '规则映射', icon: 'table' },
children: [
// ...
]
}
]
```
## 4. 当前核心工作流
### 4.1 首页总览工作流
首页的职责不是展示所有细节,而是让用户在进入系统后立刻判断:
- 系统是否健康
- 当前是否存在错误、丢包和风险提示
- Discovery 是否活跃
- 当前规则配置状态是否正常
- 下一步应进入哪个功能页继续操作
### 4.2 发现到映射闭环
核心业务闭环应围绕以下路径组织:
1. 开启 Discovery
2. 查看发现样本
3. 识别 `compositeKey` 与业务语义
4. 绑定 `domPath`
5. 配置 `scale / offset / unit`
6. 按需联动创建 filter 或 transform 规则
7. 回到状态页验证结果
### 4.3 规则配置闭环
规则中心负责承接工作流中的沉淀配置,功能上分为三类:
- 过滤规则:负责注册和条件约束,但需强调其执行链路边界
- 转换规则:负责换算和单位转换,当前已进入执行链路
- 映射规则:负责 `compositeKey -> domPath` 的绑定关系维护
## 5. 页面功能设计
本章按统一模板描述每个页面:
- 页面定位
- 目标用户与核心任务
- 页面布局
- 核心模块
- 关键交互
- 接口来源
- 状态与异常提示
- 页面关系
### 5.1 Dashboard
#### 页面定位
Dashboard 是控制台首屏,负责承接控制面信息、全局状态判断和任务分流。
#### 目标用户与核心任务
- 运维人员快速判断系统健康
- 接入人员判断是否需要进入 Discovery 工作台
- 配置人员判断当前规则数量和规则状态
#### 页面布局
建议采用“顶部页头 + 指标卡片 + 左右两列摘要区”的结构:
- 顶部页头:页面标题、说明、主操作按钮
- 第一屏卡片区设备、规则、Discovery、错误等核心指标
- 中部区域Pipeline 计数器与系统控制面
- 下部区域:规则状态摘要与风险提示
当前原型已经采用这一结构:
```1:18:src/views/dashboard/index.vue
<proto-page-header
eyebrow="Control Plane"
title="softbus_daemon 总览"
description="围绕系统状态、规则注册、Discovery 活跃度与 Pipeline 运行质量构建首页总览..."
tag="高保真原型"
tag-type="primary"
>
```
#### 核心模块
1. 状态卡片
- 在线设备
- 规则总数
- Discovery 样本数
- Pipeline 错误数
2. Pipeline 摘要
- `in / out / drop / error / mergeDrop`
- 趋势图或柱状图摘要
3. 系统控制面
- 健康检查结果
- 当前版本
- PID
- Discovery 开关状态
4. 规则状态摘要
- 过滤规则数量
- 转换规则数量
- 映射规则数量
- 规则生效范围说明
5. 风险提示区
- filter 是否只注册未执行
- transform 是否已生效
- mapping 是否已形成闭环
#### 关键交互
- 点击卡片跳转对应详情页
- 支持导出状态快照
- 支持从首页直接进入发现接入页
- 错误和异常使用醒目标签或提示卡片
#### 接口来源
- `GET /v1/status`
- `GET /health`
- `GET /api/v1/rules/status`
- `GET /api/v1/pipeline/status`
- `GET /api/v1/pipeline/counters`
- `GET /api/v1/discovery/status`
- `GET /api/v1/devices`
#### 状态与异常提示
- `running = false` 时置顶异常提示
- `drop > 0` 或 `error > 0` 时高亮 counters
- filter 类规则必须显示“注册中/实验性”提示
#### 页面关系
- 跳转到 `发现接入工作台`
- 跳转到 `规则映射中心`
- 跳转到 `Pipeline 监控`
- 跳转到 `设备管理`
### 5.2 发现接入工作台
#### 页面定位
发现接入工作台是本系统最核心的业务流程页,用于承接 discovery、mapping 和规则补充配置。
#### 目标用户与核心任务
- 设备接入调试人员发现未映射字段
- 配置人员建立字段映射关系
- 规则配置人员在映射过程中补充转换或过滤规则
#### 页面布局
建议采用三栏布局:
- 左栏:样本筛选与样本列表
- 中栏:字段解析与映射建议
- 右栏:映射绑定表单与补充规则入口
- 底部:最近操作与校验反馈
当前原型已经围绕该模型实现:
```16:33:src/views/prototype/discovery/index.vue
<div class="prototype-grid three-columns">
<proto-section-card title="样本筛选" subtitle="对应 /api/v1/discovery/samples...">
<div class="proto-toolbar">
<div class="proto-filter-group">
<el-select v-model="protocol" class="toolbar-item">
```
#### 核心模块
1. Discovery 控制区
- 开启 Discovery
- 停止 Discovery
- 清空发现池
- 显示 TTL 与当前状态
2. 样本筛选区
- 按 `protocol` 筛选
- 按 `endpointHash` 搜索
- 列表按更新时间倒序显示
3. 字段解析区
- 展示 `sampleId`
- 展示 `protocol`
- 展示 `endpointHash`
- 展示 `stableKey`
- 展示 `compositeKey`
- 展示 `valuePreview`
4. 映射建议区
- 推荐 `domPath`
- 推荐单位
- 推荐置信度
5. 映射绑定区
- 绑定 `compositeKey`
- 选择 `domPath`
- 设置 `scale`
- 设置 `offset`
- 设置 `unit`
- 按需勾选创建过滤规则或转换规则
6. 结果验证区
- 最近操作时间线
- 绑定结果
- 规则联动结果
- 校验状态
#### 关键交互
- 选中样本后,中右两栏自动联动
- 绑定成功后支持直接联动创建转换规则
- 已映射样本在列表中自动弱化或过滤
- 最近操作区展示闭环反馈
#### 接口来源
- `POST /api/v1/discovery/start`
- `POST /api/v1/discovery/stop`
- `POST /api/v1/discovery/clear`
- `GET /api/v1/discovery/status`
- `GET /api/v1/discovery/samples`
- `POST /api/v1/mapping/bind`
- `POST /api/v1/mapping/unbind`
- `GET /api/v1/mapping/list`
- `POST /api/v1/rules/filter`
- `POST /api/v1/rules/transform`
#### 状态与异常提示
- Discovery 未启动时,顶部显示空态引导
- 样本为空时,提示继续采样或检查协议链路
- 绑定失败时,在右栏表单下展示字段级错误
#### 页面关系
- 可跳转到 `映射规则`
- 可跳转到 `转换规则`
- 可从 `Dashboard` 直接进入
### 5.3 过滤规则
#### 页面定位
过滤规则页负责管理过滤条件的注册与查看,并明确说明该能力当前更偏规则注册表管理。
#### 目标用户与核心任务
- 配置人员录入过滤规则
- 联调人员验证条件表达式
- 运维人员区分“已注册”和“已真正生效”的规则状态
#### 页面布局
推荐采用统一的后台页面模型:
- 顶部页头
- 筛选区
- 规则表格
- 右侧抽屉表单或详情抽屉
#### 核心模块
1. 列表区
- 规则 ID
- 作用范围
- 条件表达式
- 执行说明
- 状态
- 更新时间
2. 表单区
- `id`
- `endpointHash`
- `deviceId`
- `stableKey`
- `condition`
3. 状态提示区
- 强调“注册中”
- 标明当前执行链路边界
#### 关键交互
- 支持按 `id`、`stableKey`、`scope` 搜索
- 支持新建、查看详情、删除
- 保存后刷新状态摘要
#### 接口来源
- `GET /api/v1/rules/status`
- `POST /api/v1/rules/filter`
- `DELETE /api/v1/rules/filter/{id}`
#### 状态与异常提示
- 必须在显眼位置展示“当前主要是注册表管理能力”
- 对未知表达式、非法参数和删除失败给出明确反馈
#### 页面关系
- 可由 `发现接入工作台` 在绑定后联动跳入
- 可返回 `规则映射中心`
### 5.4 转换规则
#### 页面定位
转换规则页用于管理数值换算、偏移量和单位配置,是规则中心中的高频操作页。
#### 目标用户与核心任务
- 配置人员维护转换参数
- 运维人员确认规则是否已实际生效
- 联调人员验证单位转换是否正确
#### 页面布局
与过滤规则保持一致,统一为:
- 筛选区
- 表格区
- 抽屉表单
#### 核心模块
1. 列表字段
- 规则 ID
- 作用范围
- `scale`
- `offset`
- `unit`
- 执行说明
- 状态
2. 表单字段
- `id`
- `endpointHash`
- `deviceId`
- `stableKey`
- `scale`
- `offset`
- `unit`
3. 状态说明
- 明确标记“已生效”
- 说明当前在 Pipeline 中的执行位置
#### 关键交互
- 支持新增、删除、校验和批量检查
- 从映射工作流中带入默认参数
- 编辑后支持回看最近变更
#### 接口来源
- `GET /api/v1/rules/status`
- `POST /api/v1/rules/transform`
- `DELETE /api/v1/rules/transform/{id}`
#### 状态与异常提示
- 转换参数缺失时禁止提交
- 单位异常或非法数值范围要在表单层直接提示
#### 页面关系
- 与 `发现接入工作台` 双向跳转
- 与 `映射规则` 形成配置链路
### 5.5 映射规则
#### 页面定位
映射规则页负责沉淀 `compositeKey -> domPath` 的绑定结果,是工作流页之后的规则归档中心。
#### 目标用户与核心任务
- 查看当前所有映射关系
- 对已绑定规则进行维护、导出或解绑
- 从规则中心回看业务域路径映射状态
#### 页面布局
保持与规则中心一致:
- 筛选区
- 表格区
- 抽屉表单
#### 核心模块
1. 映射列表
- `compositeKey`
- `domPath`
- `scale`
- `offset`
- `unit`
- 状态
- 更新时间
2. 编辑表单
- `compositeKey`
- `domPath`
- `scale`
- `offset`
- `unit`
3. 关系说明
- 映射与 Discovery 工作台的来源关系
- 映射与转换规则的联动关系
#### 关键交互
- 支持按 `compositeKey` 与 `domPath` 搜索
- 支持新建、查看、解绑和导出
- 支持从工作台带着上下文跳入
#### 接口来源
- `GET /api/v1/mapping/list`
- `POST /api/v1/mapping/bind`
- `POST /api/v1/mapping/unbind`
#### 状态与异常提示
- 已绑定状态使用明确视觉标签
- 解绑操作应有二次确认
#### 页面关系
- 来源于 `发现接入工作台`
- 与 `转换规则` 共享换算参数上下文
### 5.6 设备管理
#### 页面定位
设备管理页用于展示设备树、运行态设备和节点详情,是配置管理和设备排查的基础页面。
#### 目标用户与核心任务
- 查看设备树结构
- 查看设备在线状态与运行态信息
- 编辑可变节点字段
#### 页面布局
建议采用左中右结构或双栏结构:
- 左侧:设备树或树形筛选面板
- 中间:节点详情 / 运行态列表切换
- 右侧:编辑表单或详情抽屉
也可以采用两个页签:
- `设备树`
- `运行态设备`
#### 核心模块
1. 设备树
- 展示 `id`
- 展示 `name`
- 展示 `type`
- 展示 `endpoint`
- 展示 `enabled`
- 展示 `params.online`
- 支持树形展开
2. 节点详情
- 基础字段
- 运行态字段
- 识别字段
- 关联能力字段
3. 节点编辑
- 可编辑 `name`
- 可编辑 `enabled`
- 可编辑 `type`
- 可编辑 `endpoint`
- 可编辑 `driver`
- 可编辑 `capabilitiesRef`
- 可编辑业务配置型 `params`
4. 运行态设备列表
- 展示 `id`
- 展示 `name`
- 展示 `protocol`
- 展示 `kind`
- 展示在线状态
- 展示最近活跃时间
#### 关键交互
- 点击设备树节点刷新右侧详情
- 保存后同步刷新树和运行态设备列表
- 运行态设备支持按类型、状态和关键字筛选
#### 接口来源
- `GET /api/v1/device-tree`
- `PATCH /api/v1/device-tree/nodes/{id}`
- `GET /api/v1/devices`
- `GET /api/v1/devices/{id}`
#### 状态与异常提示
- 以下字段前端视为只读:
- `id`
- `params.stableKey`
- `params.online`
- `params.lastSeenTs`
- 节点不存在、保存失败和字段冲突要明确提示
#### 页面关系
- 可从 Dashboard 的设备卡片进入
- 可在设备详情中联动查看相关 Profiles
### 5.7 Pipeline 监控
#### 页面定位
Pipeline 监控页用于定位吞吐、丢包、错误、线程状态和运行配置问题,是面向运维和排障的关键页面。
#### 目标用户与核心任务
- 观察运行状态是否稳定
- 排查 counters 异常
- 确认运行配置是否符合当前环境
- 查看插件加载摘要
#### 页面布局
建议采用“状态卡片 + counters 区 + 配置区 + 插件摘要区”的结构。
#### 核心模块
1. 运行状态区
- `running`
- `parseWorkerCount`
- `framerSessionCount`
- `parserSessionCount`
- `mapperSessionCount`
- `endpointFramerCount`
- `trackedEndpointCount`
- `hasPluginManager`
2. Counters 区
- `in`
- `out`
- `drop`
- `error`
- `mergeDrop`
- 关键派生指标:`dropRate`、`errorRate`、`out/in`
3. 运行配置区
- `parallelPipeline`
- `orderedEgress`
- `parseWorkerCount`
- `framedQueueMax`
- `maxReorderDepth`
4. 插件摘要区
- `parserPlugins`
- `framerPlugins`
- `mapperPlugins`
#### 关键交互
- 自动轮询刷新
- 支持手动刷新
- 支持暂停轮询
- 支持对异常阈值进行高亮
#### 接口来源
- `GET /api/v1/pipeline/status`
- `GET /api/v1/pipeline/counters`
- `GET /api/v1/pipeline/config`
#### 状态与异常提示
- `drop > 0` 与 `error > 0` 使用告警颜色
- 配置为空或状态不可用时,使用区域级空态说明
#### 页面关系
- 可从 Dashboard 的计数器区域跳入
- 与插件中心共享插件摘要信息
### 5.8 插件中心
#### 页面定位
插件中心用于确认 parser、framer、mapper 三类插件是否完整加载,是协议能力检查页。
#### 目标用户与核心任务
- 协议开发人员确认插件加载结果
- 运维人员查看能力完整性
- 联调人员快速判断协议链路缺口
#### 页面布局
建议拆为三个功能区:
- 插件列表
- 协议能力矩阵
- Mapper 专项视图
#### 核心模块
1. 插件列表
- `category`
- `pluginId`
- `protocol`
- `protocolValue`
2. 协议能力矩阵
- 每个协议是否具备 parser
- 每个协议是否具备 framer
- 每个协议是否具备 mapper
3. Mapper 视图
- mapper 列表
- 所属协议
- pluginId
#### 关键交互
- 支持按插件类别筛选
- 支持按 `pluginId` 和 `protocol` 搜索
- 支持从协议矩阵跳转到插件列表
#### 接口来源
- `GET /api/v1/plugins`
- `GET /api/v1/plugins/protocols`
- `GET /api/v1/plugins/mappers`
#### 状态与异常提示
- 协议能力缺项要明确标注
- 插件为空时给出“未加载/未注册/接口异常”区分提示
#### 页面关系
- 与 `Pipeline 监控` 共享插件摘要概念
- 与 `发现接入工作台` 共享协议上下文
### 5.9 Metadata
#### 页面定位
Metadata 页面是数据字典与语义定义中心,用于说明业务含义、单位、读写能力和边界。
#### 目标用户与核心任务
- 配置人员查看语义定义
- 联调人员确认数据字段口径
- Profiles 页面联动查看 metadata 详情
#### 页面布局
建议采用“列表 + 详情抽屉”或“左列表右详情”的结构。
#### 核心模块
1. Metadata 列表
- `metadataId`
- `name`
- `domain`
- `semanticType`
- `unit`
- `minValue`
- `maxValue`
- `deadband`
- `isWriteable`
2. Metadata 详情
- 完整元数据定义
- 字段说明
- 业务解释
- 可选关联 profile 数量
#### 关键交互
- 支持按 `metadataId` 搜索
- 支持按 `domain` 筛选
- 支持点击行查看详情
#### 接口来源
- `GET /api/v1/metadata`
- `GET /api/v1/metadata/{metadataId}`
#### 状态与异常提示
- 字典为空时明确提示“未配置”而不是“加载失败”
- 详情不存在时提示 metadata 已失效或未注册
#### 页面关系
- 可从 Profiles 页联动进入
### 5.10 Profiles
#### 页面定位
Profiles 页面用于展示设备画像及点位映射结构,是设备与语义之间的桥梁页面。
#### 目标用户与核心任务
- 查看某设备的 profile 快照
- 查看点位与 metadata 的映射关系
- 为后续接入和排障提供结构化参考
#### 页面布局
建议采用“左侧设备列表 / 右侧 mappings 详情表”的双栏布局。
#### 核心模块
1. Profiles 列表
- `deviceId`
- `protocol`
- `mappings.length`
2. 点位映射详情
- `pointId`
- `metadataId`
- `registerAddress`
- `byteOffset`
- `byteLength`
- `bitOffset`
- `endianness`
- `rawType`
- `scaleFactor`
- `offsetFactor`
- `expression`
#### 关键交互
- 点击设备切换右侧 mappings
- 点击 `metadataId` 联动 Metadata 详情
- 支持按 `deviceId` 搜索
#### 接口来源
- `GET /api/v1/profiles`
- `GET /api/v1/profiles/{deviceId}`
#### 状态与异常提示
- profile 不存在时明确提示设备尚未生成画像
- 详情为空时提示当前设备未配置 mappings
#### 页面关系
- 与 `设备管理` 共享设备上下文
- 与 `Metadata` 页面双向联动
## 6. 通用交互规范
### 6.1 统一布局规范
后台页面统一采用以下视觉模型:
- 顶部页头:标题、说明、状态标签、主操作按钮
- 内容区优先使用卡片承载信息模块
- 列表类页面统一采用“筛选区 + 表格/列表 + 抽屉”
- 流程页优先采用多栏工作台布局
- 只读信息优先使用详情面板,减少重复跳页
### 6.2 页面跳转规范
- Dashboard 负责主分流
- Discovery 工作台负责流程内操作
- 规则页负责配置沉淀
- 设备、Pipeline、插件、Metadata、Profiles 负责浏览和验证
### 6.3 状态标签规范
建议统一使用以下语义:
- `success`:已生效、已绑定、运行正常
- `warning`:注册中、待确认、部分异常
- `danger`:错误、失败、关键告警
- `info`:只读、未启用、等待中
- `primary`:当前主路径或推荐操作
### 6.4 表单与操作规范
- 所有危险操作使用二次确认
- 保存成功后提示并刷新当前视图
- 删除成功后应自动刷新列表
- 表单校验失败时优先在字段旁提示,不仅依赖全局 message
## 7. 数据刷新与异常处理
### 7.1 刷新策略
| 页面 | 刷新方式 | 建议周期 |
|---|---|---|
| Dashboard | 自动轮询 + 手动刷新 | 3~5 秒 |
| 发现接入工作台 | Discovery 状态自动刷新,样本按需刷新 | 3~5 秒 |
| 过滤规则 | 手动刷新 | 按需 |
| 转换规则 | 手动刷新 | 按需 |
| 映射规则 | 手动刷新 | 按需 |
| 设备管理 | 手动刷新 + 保存后刷新 | 按需 |
| Pipeline 监控 | 自动轮询 + 暂停轮询 | 2 秒 |
| 插件中心 | 首次加载 + 手动刷新 | 不轮询 |
| Metadata | 首次加载即可 | 不轮询 |
| Profiles | 首次加载 + 切换设备时刷新 | 按需 |
### 7.2 错误处理原则
前端统一处理以下几类异常:
- 网络失败
- 接口返回失败
- 空数据
- 权限或状态不满足
- 参数校验失败
建议统一提供:
- 顶部 `message` 提示
- 区域级错误占位
- 表格空态文案
- 关键模块重试按钮
### 7.3 特殊业务提示
- filter 规则必须明确标注“仅注册,不保证已参与真实过滤”
- transform 规则必须标注“已进入执行链路”
- mapping 绑定失败必须保留上下文,避免用户重复填写
- Discovery 样本为空时优先引导检查采集状态,而不是简单提示空列表
## 8. 组件抽象建议
以下模块适合抽成通用组件:
- `PageHeader`
- `StatusCard`
- `MetricCard`
- `SectionCard`
- `RuleWorkspace`
- `DiscoverySamplesList`
- `DiscoveryBindingForm`
- `DeviceTreePanel`
- `DeviceDetailDrawer`
- `PipelineCountersPanel`
- `ProtocolCapabilityMatrix`
- `MetadataTable`
- `ProfileMappingsTable`
## 9. 版本范围与迭代顺序
### 9.1 当前核心版本
当前版本优先围绕三条主线建设:
1. Dashboard 总览
2. 发现接入工作台
3. 规则映射中心
原因:
- 这三部分已经能构成状态查看、发现、绑定、规则沉淀的主闭环
- 最能体现 `softbus_daemon` 当前接口文档的核心价值
- 也是最适合形成高保真原型的界面范围
### 9.2 第二阶段
第二阶段重点补齐浏览与验证能力:
1. 设备管理
2. Pipeline 监控
3. 插件中心
### 9.3 第三阶段
第三阶段补齐语义与画像能力:
1. Metadata
2. Profiles
## 10. 附录:当前原型页对齐说明
当前设计说明已与现有原型方向对齐,主要依据如下:
- 首页强调状态总览、规则状态、Discovery 活跃度和风险提示
- 发现接入页采用三栏工作台布局
- 规则中心拆分为过滤、转换、映射三个页面
示例数据结构也已经体现这一方向:
```1:44:src/views/prototype/mock-data.js
export const statusCards = [
{
label: '在线设备',
value: '128',
trend: '+12.4%',
trendType: 'up',
hint: '来自 /api/v1/devices'
},
{
label: '规则总数',
value: '42',
trend: '+6',
trendType: 'up',
hint: 'filter / transform / mapping'
},
{
label: 'Discovery 样本',
value: '1,284',
trend: '运行中',
trendType: 'neutral',
hint: '来自 /api/v1/discovery/status'
}
]
```
以及规则中心的数据分类:
```112:173:src/views/prototype/mock-data.js
export const ruleFilters = {
filter: [
{
id: 'flt_temp_guard',
scope: 'stableKey: boiler_temp',
condition: 'value >= -40 && value <= 180',
status: 'registered'
}
],
transform: [
{
id: 'tr_temp_celsius',
scope: 'stableKey: boiler_temp',
scale: '1.0',
offset: '0',
unit: 'C',
status: 'active'
}
],
mapping: [
{
compositeKey: 'boiler.temp.01',
domPath: 'site.boiler.temperature',
status: 'bound'
}
]
}
```