基于《鑫潼智电系统需求分析报告 V1.0》，按功能模块拆解为后端、前端、小程序、APP 的完整系统实现架构。覆盖 ICC 平台 API 对接、数据隔离、权限控制等关键设计决策。
JWT 双 Token
多端统一登录态
/admin · /ops · /worker
/customer 分组路由
Interceptor 注入过滤
给什么数据看什么
rate-limiter
操作审计 winston
客户/部门
建筑/房间
账号分配
勘察/方案
合同/安装
验收/回访
ICC 设备同步
线路分配
部门/房间映射
勘察/安装
报警/报修/维保
全生命周期
定时拉取
队列缓冲
清洗映射
多维用电统计
月度报告生成
报酬计算
水印拍照取证
合同/验收存档
月报文件
APP 推送
微信订阅消息
短信（按需）
用户/角色/菜单
数据字典
日志审计
JWT 签发校验
微信 openid 登录
RBAC 权限
业务数据（customer_id 逻辑隔离）
用电采集数据（按月分区）
TypeORM + 声明式分区
JWT 会话 Token
数据字典/热点配置
BullMQ 队列底层
取证照片（水印）
合同/验收/方案文件
月度报告文档
国产 · S3 兼容 · Apache 2.0
ICC 拉取数据缓冲
报警事件异步处理
基于 Redis 轻量级
运营管理员使用：审批、配置、报表、系统设置
Vue3 + Ant Design Vue业务员移动办公：客户管理、项目跟进、现场勘察回访
uni-app (iOS / Android)共享电工接单、现场拍照取证、报酬查询
uni-app (iOS / Android)客户查看用电/报警/月报、报修申请、评分
uni-app → 微信小程序设备数据采集平台（厂家后台，非自研）· API 对接
外部系统 · HTTP RESTJWT Token 签发与校验，多端统一登录态
Midway Guard + JWT按端区分路由前缀：/admin · /ops · /worker · /customer
Midway Controller 分组接口决定可见数据范围，APP/小程序给什么看什么
Guard + Interceptor常规 ERP 并发量，请求日志与操作审计
rate-limiter + winston客户/部门/建筑/房间、勘察/方案/合同/验收/回访
Customer · Project Service报警派单、报修派单、维保派单、安装派单
Dispatch Service设备信息同步、线路分配、设备状态管理
Device · Line Service多维度用电统计、月度报告、共享电工报酬
Report Service定时拉取设备/报警/用电数据，缓冲写入
ICC Sync Service + 定时任务现场拍照取证、合同/验收/方案文件存档
File Service + 对象存储用户、角色、菜单权限（RBAC）、字典、日志
System Service报警推送到 APP、派单提醒、微信消息
Notify Service业务数据（逻辑隔离）+ 用电采集数据（按月分区）
TypeORM + 声明式分区会话 Token、数据字典、热点配置、限流计数
ioredis取证照片、合同/验收/方案电子文件、月度报告
RustFS（国产 · S3 兼容）ICC 拉取数据缓冲、报警事件异步处理
BullMQ (Redis 队列)设备信息、设备状态、报警数据、用电采集数据
HTTP REST · 主动拉取小程序登录授权（openid）、消息订阅推送
微信登录 + 订阅消息客户账号初始密码、报警短信通知（按需）
阿里云短信网关/探测器 → ICC 平台采集 → 鑫潼系统拉取
不直接对接① 不直接对接硬件：所有设备数据通过大华 ICC 平台 API 拉取，鑫潼系统只做数据消费方。② 五端共享一套后端：Midway.js 统一提供 /admin（Web管理台）、/ops（运营APP）、/worker（电工APP）、/customer（小程序）四组路由，避免重复开发。③ 运营方双端同一套账号：运营管理平台（Web）和运营管理 APP（业务员）共用 sys_user 表，通过角色区分权限，共用 RBAC 体系。④ ICC 内部虽实时推送，但鑫潼侧采用主动拉取，通过定时任务按采集频次拉取，进入 BullMQ 队列缓冲后写入分区表。
| 层级 | 技术选型 | 版本/说明 | 选型理由 |
|---|---|---|---|
| 后端框架 | Midway.js | Node.js · IoC + TypeORM | 阿里出品，TypeScript 原生支持，装饰器风格，模块化清晰 |
| 前端框架 | Vue 3 + Ant Design Vue | Composition API | AntDV 组件丰富，适合中后台 ERP 型管理系统 |
| 共享电工 APP | uni-app | 跨 iOS / Android | 一套代码多端发布，共享电工端仅需移动 App |
| 运营管理 APP | uni-app | 跨 iOS / Android | 业务员移动办公，共用 sys_user 表，复用 uni-app 技术栈 |
| 小程序 | uni-app → 微信小程序 | 客户端使用 | 复用 uni-app 技术栈，降低学习成本 |
| 数据库 | PostgreSQL | 15+ | 时序数据分区成熟、多维聚合分析强、JSONB 灵活（详见下方对比） |
| ORM | TypeORM | Midway 内置集成 | 与 Midway 深度集成，支持 PostgreSQL 分区表 |
| 缓存 | Redis | 7.x | 会话、字典缓存、限流、BullMQ 队列底层 |
| 消息队列 | BullMQ | 基于 Redis | 轻量级，无需额外引入 Kafka，满足常规 ERP 并发 |
| 对象存储 | RustFS（国产） | S3 兼容 · Apache 2.0 | 取证照片、合同/验收文件、月度报告存档，替代 MinIO |
| 鉴权 | JWT | 双 Token 刷新 | 多端统一，无状态易扩展 |
基于本系统的数据特征（时序用电数据 + 多维统计报表 + ICC 灵活设备数据）进行对比。
本系统最核心的数据特征是用电采集数据持续增长（时序）和月度报告多维统计。PostgreSQL 的声明式分区能直接解决您担心的"数据量暴涨"问题——按月分区后，单表数据被切分为多个物理子表，查询只扫描相关分区，性能稳定。配合物化视图预聚合月度统计，即使客户和设备数量增长，报表查询依然高效。
客户信息（省市县分类）、客户部门、客户访问账号分配
建筑/房间、勘察派单、智电方案、合同、安装、验收、回访
ICC 设备信息同步、智电设备/网关/探测器、线路分配（部门/房间）
勘察/安装/报警/报修/维保五类派单全生命周期管理
定时拉取设备/报警/用电数据，队列缓冲，写入分区表
按部门/楼栋/楼层/房间维度用电统计，月度报告生成，报酬计算
现场拍照取证（水印）、合同/验收/方案/月报文件存档
APP 推送（报警/派单）、微信订阅消息、短信（按需）
用户/角色/菜单（RBAC）、数据字典、操作日志、定时任务
JWT 签发校验、微信 openid 登录、接口级数据权限拦截
全局数据概览、报警总览、派单总览、待办事项
方案审批、合同审批、派单规则配置、数据字典
报警派单（从 ICC 拉取报警）、报修派单、维保派单、评分管理
设备列表、线路分配（部门/房间）、设备状态、报警查询
多维度用电统计、月度报告生成下载、共享电工报酬统计
用户/角色/菜单权限配置、员工管理、日志审计
客户档案查看、联系人管理、客户项目列表（和后台功能一致，移动端适配）
项目跟进、勘察任务、方案查看、合同查看、验收与回访
负责客户的派单进度跟踪、报警处理进度、报修处理进度
现场拍照记录、巡查日志提交、问题上报
派单提醒、报警推送、客户消息、系统通知
个人信息、修改密码、负责客户统计、业绩查看
勘察/安装/报警/报修/维保五类派单推送与接单确认
安装派单自动生成设备/耗材领用单，领料确认
配电井/箱位置记录、按标准流程处置、水印拍照取证上传
处理完成后照片上传、提交派单、查看历史任务
月度派单完成统计、单笔/月度收入明细查询
业务员回访记录上传（拍照+意见）
所属设备在线状态、线路用电实时数据
设备报警记录查询、处理进度跟踪
按部门/楼栋/楼层/房间多维度用电查询、节电情况
当月用电统计查看、用电及改善报告文件下载
水电问题报修提交（描述+拍照）、报修进度查询
报修/维保派单完成后对共享电工评分
ICC 录入意向客户 → 推送到运营管理平台
网关/探测器设备数据同步到运营管理平台
用电实时数据按采集频次同步拉取
设备运行状态、预警类型、报警数值拉取
ICC 平台内部是实时推送机制，但鑫潼系统侧采用主动拉取（定时任务调 ICC OpenAPI）。ICC 接口文档待研究，当前按通用 REST API 模式设计，后续接入时按实际文档调整鉴权方式（AppKey/Token）和接口字段。
| 拉取数据 | 拉取频次（建议） | 写入目标 | 消费方 |
|---|---|---|---|
| 客户信息 | 事件触发 / 每小时 | 业务表 | 客户管理模块 |
| 设备信息（网关/探测器） | 每小时 | 设备表 + 线路表 | 设备管理模块 |
| 用电采集数据 | 5~15 分钟（按 ICC 采集频次） | 用电采集分区表（按月） | 统计报表 / 月度报告 |
| 设备报警数据 | 1 分钟 | 报警表 | 报警派单服务 → APP 推送 |
鑫潼是唯一运营主体，客户（学校/医院）是平台上的数据主体而非独立租户，因此不需要严格多租户架构。采用逻辑隔离（customer_id 行级隔离）+ 时序数据按月分区的混合方案，兼顾性能与运维成本。
客户、合同、派单、设备等业务表数据量有限，通过 customer_id 字段 + 索引隔离。
数据量增量大头。按采集时间分区，查询只扫描相关月份分区，性能稳定。
| 方案 | 是否采用 | 适用数据 | 理由 |
|---|---|---|---|
| 逻辑隔离（customer_id 行级） | 采用 | 业务数据（客户/合同/派单/设备） | 数据量有限，索引隔离足够，支持跨客户运营统计 |
| 时序数据按月分区 | 采用 | 用电采集数据 | 解决数据量暴涨问题，查询只扫相关分区 |
| 物理分库（每客户独立库） | 不采用 | — | 运维成本高，跨客户统计困难，无合规强制要求 |
| 独立 Schema 隔离 | 不采用 | — | 增加复杂度但收益有限，逻辑隔离已满足 |
| 严格多租户（Tenant 模型） | 不采用 | — | 鑫潼是单一运营方，客户非独立租户 |
数据增长的大头是用电采集数据（每条线路按采集频次持续写入），而非业务数据。业务数据（客户/合同/派单）即使客户增长到上千家，数据量仍在百万级以内，逻辑隔离 + 索引完全够用。用电采集数据通过按月分区 + 物化视图预聚合月度统计，即使积累数年数据，查询也只扫描目标月份分区，性能可控。不需要物理分库。
现阶段权限粗放管理：运营方双端（Web + APP）共用 sys_user 表，采用 RBAC 菜单级权限（角色绑定菜单/按钮）；共享电工 APP 和客户小程序的数据权限由接口定义——接口返回什么数据，端上就只能看到什么数据，不在端上做复杂权限判断。
运营方双端：账号密码（sys_user）
电工APP：账号密码（worker）
小程序：微信 openid
Token 携带：userId、user_type、role、customerId
双 Token 刷新
运营方双端：RBAC 角色 → 菜单
电工APP/小程序：固定功能页
接口根据 user_type + role 过滤数据
给什么看什么
| 角色 | 使用端 | 账号表 | 菜单权限（RBAC） | 接口数据权限 |
|---|---|---|---|---|
| 运营管理员 | 运营管理平台（Web） | sys_user | 全部菜单：工作台/审批/派单/设备/报表/系统管理 | 全量数据，所有客户和派单 |
| 业务员 | 运营管理平台（Web）+ 运营管理 APP | sys_user | 客户/项目/派单查看/报表查看（按需配置） | 仅自己负责的客户（salesman_id 过滤） |
| 共享电工 | 共享电工 APP | worker | —（APP 固定功能页） | 仅分配给自己的派单、个人报酬明细 |
| 客户 | 微信小程序 | customer_account | —（小程序固定功能页） | 仅本客户设备/用电/报警/月报/报修记录 |
① 共享电工：查询派单接口自动按 worker_id = 当前用户 过滤；报酬接口只返回本人数据。② 客户：查询设备/用电/报警接口自动按 customer_id = 当前客户 过滤；报修只能提交本客户的。③ 业务员（运营管理 APP + Web）：查询客户/项目/派单接口按 salesman_id = 当前用户 过滤，只能看自己负责的客户数据（运营管理员不受限）。④ 运营方双端共用一套 RBAC：Web 管理台和运营管理 APP 共用 sys_user 表 + 角色体系，菜单权限由后端统一返回，前端/APP 根据返回动态渲染。通过 Midway Interceptor 统一注入过滤条件，避免每个接口手动处理。
| 假设项 | 假设内容 | 来源 |
|---|---|---|
| 运营主体 | 鑫潼为唯一运营方，不做白标输出 | 用户确认 |
| 多租户 | 不需要严格多租户，采用逻辑隔离 | 用户确认 + 架构建议 |
| 分库 | 不做物理分库，用电数据按月分区 | 架构建议（解决数据量问题） |
| ICC 对接 | 主动拉取（定时任务），非 ICC 推送 | 用户确认 |
| ICC 接口文档 | 待研究，按通用 REST API 模式预留 | 用户确认 |
| 后台权限 | RBAC 菜单级，现阶段粗放管理 | 用户确认 |
| APP/小程序数据权限 | 接口定义数据范围，给什么看什么 | 用户确认 |
| 共享电工 APP 技术栈 | uni-app 跨 iOS/Android | 用户确认 |
| 运营管理 APP | uni-app，业务员使用，功能与后台一致，共用 sys_user 表 | 用户确认 |
| 客户小程序 | 微信小程序，运营后台分配账号 | 用户确认 |
| 子账号 | 待定，当前按单账号预留扩展 | 用户确认（待定） |
| 电子签章 | 不需要，但需取证拍照（水印） | 用户确认 |
| 并发量 | 常规 ERP 级，无需特殊高并发架构 | 用户确认 |
| 数据库 | PostgreSQL（架构建议，用户待定） | 架构建议 |
| 消息队列 | BullMQ（Redis 基础），不引入 Kafka | 架构建议（匹配并发量） |
| 后端框架 | Midway.js + TypeORM | 用户确认 |
| 前端框架 | Vue3 + Ant Design Vue | 用户确认 |