---

每日一句正能量

一个人越是持续紧绷，越容易疲惫，越懂得保持松弛的状态，越能在关键时刻发力。
持续紧绷 = 提前耗尽燃料。 松弛 ≠ 放弃，而是蓄力。就像心跳：一直快跳会死，有舒张才有收缩的力量。真正的发力，来自懂得休息的肌肉。

标记：参与方向三「毕业季 · 鸿蒙同行」文章投稿。

---

一、选题背景：为什么实验室预约适合用元服务重做

在高校实验教学和毕业设计管理中，实验室预约通常不是一个“没有系统”的问题，而是一个“系统入口太重、流程太长、状态不透明”的问题。

很多学校已经有统一门户、教务系统或资产管理平台，但学生想预约一次实验室，往往要经历登录门户、寻找菜单、选择实验室、填写申请、等待审批、重新进入系统查看结果等多个步骤。对于指导教师和实验室管理员来说，另一个痛点是重复确认：学生不断询问“审批了吗”“今天还能约吗”“预约后怎么签到”，管理员则需要在表格、群聊和系统之间来回核对。

这类场景具有几个鲜明特点：

1. 任务目标明确：用户大多数时候只想完成“查空闲—预约—看状态—签到/取消”。
2. 使用频率不稳定：课程周、竞赛周和毕业季高频使用，其他时间低频使用。
3. 服务链路短：不需要用户长时间停留，也不适合堆叠大量后台管理功能。
4. 状态提醒重要：审批结果、即将开始、超时未签到都需要及时触达。
5. 轻入口价值高：学生不愿为了偶发预约专门安装和学习一个复杂应用。

因此，实验室预约非常适合用 HarmonyOS 元服务承载。元服务强调免安装、轻量、秒开直达、即用即走；服务卡片可以直接展示“今天可预约时段”“最近预约状态”和“立即预约”入口。它不是把传统管理系统缩小，而是重新围绕高频任务设计服务边界。

---

二、毕业设计目标：完成一个小而完整的预约闭环

本项目不追求“大而全”，而是把毕业设计目标拆成三个层次。

2.1 基础目标

• 展示实验室列表、开放时间和设备信息。
• 查询指定日期的空闲时段。
• 提交预约申请。
• 查看预约审批状态。
• 取消预约和到场签到。
• 管理员查看待审批申请。

2.2 HarmonyOS 特性目标

• 通过元服务实现免安装或轻量触达。
• 使用服务卡片展示最近预约和今日空闲情况。
• 通过卡片点击直达预约页或预约详情页。
• 使用 ArkUI 构建手机端自适应界面。
• 使用通知提醒审批结果、预约开始和超时风险。
• 为后续搜索、意图直达和跨设备协同预留能力。

2.3 教学与答辩目标

• 能清楚解释为什么选择元服务，而不是普通应用。
• 能展示完整的数据模型、状态机和冲突检测算法。
• 能说明轻量化边界、安全策略和异常处理。
• 能提供可复现代码、测试数据和改进建议。
• 能在 5～8 分钟答辩中完成核心演示。

---

三、需求分析：四类角色、五条关键业务链

系统包含四类角色：

角色	核心需求	权限边界
学生	查空闲、预约、签到、取消、看结果	只能操作本人预约
指导教师	查看课题组申请、确认用途、补充意见	可审核本课题组或课程
实验室管理员	维护开放时段、审批、释放资源	管理指定实验室
系统管理员	角色、规则、审计、统计	不直接修改业务数据内容

五条关键业务链是：

1. 快速预约链：卡片/搜索进入 → 选实验室 → 选时段 → 填用途 → 提交。
2. 审批链：规则预审 → 自动通过或转人工 → 通知申请人。
3. 履约链：开始前提醒 → 到场签到 → 使用完成 → 评价/归档。
4. 异常链：冲突、取消、驳回、超时、设备停用、临时封闭。
5. 管理链：维护开放计划 → 查看占用 → 调整规则 → 导出统计。

---

四、为什么选元服务，而不是把所有功能塞进 App

元服务适合本项目，并不等于所有管理能力都要做进元服务。真正的轻量化不是“页面少”，而是只保留用户高频、可独立闭环的服务。

元服务端保留：

• 今日空闲时段；
• 实验室快速检索；
• 预约表单；
• 我的预约；
• 签到和取消；
• 审批与提醒结果。

管理后台保留：

• 复杂排班；
• 设备全生命周期；
• 批量导入；
• 多级权限矩阵；
• 统计大屏；
• 审计导出；
• 规则版本管理。

这种边界有三个价值。

第一，用户认知成本低。学生第一次打开就能看懂，不需要学习一个完整资产管理系统。

第二，开发迭代快。毕业设计可以先完成最小闭环，再增加卡片、通知和数据统计，而不是一开始同时开发十几个模块。

第三，答辩主题集中。评委可以清楚看到“元服务如何解决快速预约”，而不是被复杂后台页面分散注意力。

---

五、总体架构：元服务、领域服务和管理端分离

系统采用五层结构：

1. 触达层：服务卡片、桌面入口、系统搜索、通知提醒。
2. 元服务业务层：空闲查询、快速预约、我的预约、签到/取消。
3. 领域服务层：冲突检测、审批策略、额度控制、预约状态机。
4. 数据与安全层：实验室资源、预约记录、账号角色、审计日志。
5. 管理端：实验室维护、批量排期、审批看板、数据统计。

架构设计的关键原则是：页面不直接修改预约状态。所有状态变化必须经过 ReservationService，由领域层校验权限、时段冲突和状态合法性，再写入数据层并记录审计日志。

5.1 推荐工程目录

entry/src/main/ets/
├── entryability/
│   └── EntryAbility.ets
├── pages/
│   ├── HomePage.ets
│   ├── LabDetailPage.ets
│   ├── CreateReservationPage.ets
│   ├── ReservationDetailPage.ets
│   └── MyReservationPage.ets
├── widget/
│   ├── ReservationCard.ets
│   └── ReservationCardFormAbility.ets
├── model/
│   ├── Laboratory.ets
│   ├── Reservation.ets
│   ├── TimeSlot.ets
│   └── UserRole.ets
├── service/
│   ├── LaboratoryService.ets
│   ├── ReservationService.ets
│   ├── ConflictChecker.ets
│   ├── ApprovalPolicy.ets
│   ├── NotificationService.ets
│   └── AuditService.ets
├── repository/
│   ├── ReservationRepository.ets
│   └── LaboratoryRepository.ets
└── common/
    ├── Result.ets
    ├── Logger.ets
    └── Constants.ets

---

六、核心数据模型：先把状态和规则建清楚

毕业设计最常见的问题是先画页面，最后才发现审批、取消和签到状态无法解释。正确顺序应该是先定义领域模型。

export type ReservationStatus =
  'DRAFT' |
  'PENDING' |
  'APPROVED' |
  'REJECTED' |
  'CANCELED' |
  'CHECKED_IN' |
  'COMPLETED' |
  'EXPIRED'

export interface Laboratory {
  id: string
  name: string
  location: string
  capacity: number
  equipmentTags: string[]
  needApproval: boolean
  openTime: string
  enabled: boolean
}

export interface TimeSlot {
  startAt: number
  endAt: number
}

export interface Reservation {
  id: string
  laboratoryId: string
  applicantId: string
  applicantName: string
  projectName: string
  participantCount: number
  slot: TimeSlot
  status: ReservationStatus
  version: number
  createdAt: number
  updatedAt: number
  reviewerId?: string
  reviewComment?: string
}

这里的 version 字段用于乐观锁，避免两名学生同时抢占最后一个时段时发生覆盖。

---

七、预约流程：先预检，再提交

完整流程如下：

1. 用户从卡片或搜索进入元服务。
2. 查看实验室设备、容量和规则。
3. 选择日期和时段。
4. 客户端先执行基础校验：人数、时间、用途是否完整。
5. 服务端执行最终校验：时段冲突、用户资格、预约额度、设备权限。
6. 根据审批策略进入“自动通过”或“待人工审批”。
7. 结果通过通知和服务卡片更新给用户。
8. 用户到场签到，使用完成后归档。
9. 超时未签到则自动释放资源。

7.1 时段重叠判断

两个时间段重叠的通用判断是：

export class ConflictChecker {
  static isOverlap(a: TimeSlot, b: TimeSlot): boolean {
    return a.startAt < b.endAt && b.startAt < a.endAt
  }

  static hasConflict(target: TimeSlot, reservations: Reservation[]): boolean {
    return reservations.some((item: Reservation) => {
      const active = item.status === 'PENDING' ||
        item.status === 'APPROVED' ||
        item.status === 'CHECKED_IN'
      return active && this.isOverlap(target, item.slot)
    })
  }
}

不要使用“开始时间相同才冲突”的错误判断。09:30-10:30 与 10:00-11:00 同样冲突。

7.2 提交预约服务

export interface CreateReservationCommand {
  laboratoryId: string
  applicantId: string
  applicantName: string
  projectName: string
  participantCount: number
  slot: TimeSlot
}

export interface ServiceResult<T> {
  success: boolean
  message: string
  data?: T
}

export class ReservationService {
  constructor(
    private labRepository: LaboratoryRepository,
    private reservationRepository: ReservationRepository,
    private approvalPolicy: ApprovalPolicy,
    private auditService: AuditService
  ) {}

  async create(command: CreateReservationCommand): Promise<ServiceResult<Reservation>> {
    const lab = await this.labRepository.findById(command.laboratoryId)
    if (!lab || !lab.enabled) {
      return { success: false, message: '实验室不存在或已停用' }
    }

    if (command.participantCount <= 0 || command.participantCount > lab.capacity) {
      return { success: false, message: `预约人数应为 1～${lab.capacity} 人` }
    }

    if (command.slot.startAt >= command.slot.endAt) {
      return { success: false, message: '预约时间不合法' }
    }

    const existed = await this.reservationRepository.listByLabAndRange(
      command.laboratoryId,
      command.slot.startAt,
      command.slot.endAt
    )

    if (ConflictChecker.hasConflict(command.slot, existed)) {
      return { success: false, message: '该时段已被占用，请重新选择' }
    }

    const autoApproved = this.approvalPolicy.canAutoApprove(lab, command)
    const now = Date.now()
    const reservation: Reservation = {
      id: `${command.laboratoryId}_${now}`,
      laboratoryId: command.laboratoryId,
      applicantId: command.applicantId,
      applicantName: command.applicantName,
      projectName: command.projectName,
      participantCount: command.participantCount,
      slot: command.slot,
      status: autoApproved ? 'APPROVED' : 'PENDING',
      version: 1,
      createdAt: now,
      updatedAt: now
    }

    const saved = await this.reservationRepository.insertWithLock(reservation)
    if (!saved) {
      return { success: false, message: '该时段刚刚被其他用户预约，请刷新后重试' }
    }

    await this.auditService.record({
      action: 'CREATE_RESERVATION',
      targetId: reservation.id,
      operatorId: command.applicantId,
      createdAt: now
    })

    return {
      success: true,
      message: autoApproved ? '预约成功，已自动通过' : '申请已提交，等待审批',
      data: reservation
    }
  }
}

这段代码体现了四个工程要点：

• 客户端校验只改善体验，服务端仍必须二次校验。
• 冲突检查只统计活跃状态，不统计已取消、已驳回和已完成。
• 最终写入要有并发保护。
• 每次状态变化都记录审计日志。

---

八、审批策略：不是所有预约都走人工

如果所有预约都需要管理员审批，系统只是把微信群审批搬到了线上，效率不会明显提高。更合理的做法是“规则驱动自动审批 + 高风险场景人工审批”。

export class ApprovalPolicy {
  canAutoApprove(lab: Laboratory, command: CreateReservationCommand): boolean {
    if (lab.needApproval) {
      return false
    }

    const hour = new Date(command.slot.startAt).getHours()
    const isNight = hour < 8 || hour >= 21
    if (isNight) {
      return false
    }

    const dangerousEquipment = lab.equipmentTags.some((tag: string) =>
      ['高压', '激光', '化学试剂', '高温'].includes(tag)
    )
    if (dangerousEquipment) {
      return false
    }

    return command.participantCount <= Math.floor(lab.capacity * 0.8)
  }
}

建议人工审批的场景：

• 夜间预约；
• 高风险设备；
• 跨专业团队；
• 超过常规人数；
• 用户存在多次爽约记录；
• 实验室临时维护；
• 需要指导教师确认的毕业设计实验。

---

九、预约状态机：页面按钮必须由状态决定

允许的主要状态流转：

DRAFT -> PENDING
PENDING -> APPROVED
PENDING -> REJECTED
PENDING -> CANCELED
APPROVED -> CHECKED_IN
APPROVED -> CANCELED
APPROVED -> EXPIRED
CHECKED_IN -> COMPLETED

不允许的流转包括：

• COMPLETED -> CANCELED
• REJECTED -> APPROVED（应重新提交或创建新申请）
• EXPIRED -> CHECKED_IN
• 非本人取消他人预约
• 学生直接把 PENDING 改成 APPROVED

export class ReservationStateMachine {
  private static transitions: Map<ReservationStatus, ReservationStatus[]> = new Map([
    ['DRAFT', ['PENDING', 'CANCELED']],
    ['PENDING', ['APPROVED', 'REJECTED', 'CANCELED']],
    ['APPROVED', ['CHECKED_IN', 'CANCELED', 'EXPIRED']],
    ['CHECKED_IN', ['COMPLETED']],
    ['REJECTED', []],
    ['CANCELED', []],
    ['COMPLETED', []],
    ['EXPIRED', []]
  ])

  static canTransfer(from: ReservationStatus, to: ReservationStatus): boolean {
    return this.transitions.get(from)?.includes(to) ?? false
  }
}

---

十、ArkUI 预约页面：把高频任务压缩到一屏

元服务页面应该避免多层跳转。预约页可以把实验室摘要、日期、时段、用途和提交按钮放在一屏内。

@Entry
@Component
struct CreateReservationPage {
  @State selectedLab: string = '物联网实验室'
  @State selectedDate: string = '2026-06-18'
  @State selectedSlot: string = ''
  @State projectName: string = ''
  @State participantCount: number = 1
  @State submitting: boolean = false

  private slots: string[] = [
    '09:00-10:00',
    '10:00-11:00',
    '14:00-15:00',
    '15:00-16:00'
  ]

  build() {
    Column({ space: 16 }) {
      Text('选择预约时段')
        .fontSize(26)
        .fontWeight(FontWeight.Bold)
        .width('100%')

      Text(`实验室：${this.selectedLab}`)
        .fontSize(18)
        .width('100%')

      TextInput({ placeholder: '毕业设计名称或实验用途', text: this.projectName })
        .height(48)
        .onChange((value: string) => {
          this.projectName = value
        })

      Grid() {
        ForEach(this.slots, (item: string) => {
          GridItem() {
            Button(item)
              .type(ButtonType.Normal)
              .backgroundColor(this.selectedSlot === item ? '#3F7BFF' : '#EEF4FF')
              .fontColor(this.selectedSlot === item ? Color.White : '#244273')
              .onClick(() => {
                this.selectedSlot = item
              })
          }
        })
      }
      .columnsTemplate('1fr 1fr')
      .rowsGap(12)
      .columnsGap(12)

      Row({ space: 12 }) {
        Text('参与人数')
        Counter() {
          Text(`${this.participantCount}`)
        }
        .onInc(() => this.participantCount++)
        .onDec(() => {
          this.participantCount = Math.max(1, this.participantCount - 1)
        })
      }
      .width('100%')

      Button(this.submitting ? '正在提交…' : '提交预约')
        .height(52)
        .width('100%')
        .enabled(!this.submitting)
        .onClick(async () => {
          await this.submitReservation()
        })
    }
    .padding(20)
    .width('100%')
    .height('100%')
  }

  private async submitReservation(): Promise<void> {
    if (!this.selectedSlot) {
      promptAction.showToast({ message: '请选择预约时段' })
      return
    }
    if (!this.projectName.trim()) {
      promptAction.showToast({ message: '请填写实验用途' })
      return
    }

    this.submitting = true
    try {
      // 调用 ReservationService 或网络层提交
      promptAction.showToast({ message: '申请已提交' })
    } finally {
      this.submitting = false
    }
  }
}

页面设计要注意：

• 提交期间禁用按钮，避免重复提交。
• 冲突发生后保留已填写用途，不要让用户重填。
• 时间显示使用本地化格式。
• 高风险实验室在提交前明确展示规则。
• 不在卡片或列表中暴露申请人的敏感信息。

---

十一、服务卡片：让“看状态”和“立即预约”不必进入完整页面

服务卡片适合展示三类信息：

1. 今天还有多少可预约时段；
2. 最近一条预约的状态；
3. 快速预约或查看详情入口。

在 ArkTS 卡片中，FormExtensionAbility 负责创建和更新卡片数据，卡片页面负责渲染和点击交互。

11.1 FormExtensionAbility 教学示例

import { formBindingData, FormExtensionAbility } from '@kit.FormKit'
import { Want } from '@kit.AbilityKit'

export default class ReservationCardFormAbility extends FormExtensionAbility {
  onAddForm(want: Want) {
    const data = {
      labName: '物联网实验室',
      availableCount: 8,
      recentStatus: '今天 10:00 · 已通过',
      updatedAt: Date.now()
    }
    return formBindingData.createFormBindingData(data)
  }

  onUpdateForm(formId: string): void {
    // 实际项目中读取缓存或服务端最新摘要，
    // 再调用卡片更新接口刷新内容。
  }

  onFormEvent(formId: string, message: string): void {
    // 处理卡片 message 事件，例如刷新空闲时段。
  }
}

11.2 卡片页面示例

@Entry
@Component
struct ReservationCard {
  @LocalStorageProp('labName') labName: string = '实验室'
  @LocalStorageProp('availableCount') availableCount: number = 0
  @LocalStorageProp('recentStatus') recentStatus: string = '暂无预约'

  build() {
    Column({ space: 8 }) {
      Row() {
        Text('实验室预约')
          .fontSize(18)
          .fontWeight(FontWeight.Bold)
        Blank()
        Text(`${this.availableCount} 个空闲时段`)
          .fontSize(14)
          .fontColor('#3F73D8')
      }

      Text(this.labName)
        .fontSize(16)
        .width('100%')

      Text(this.recentStatus)
        .fontSize(14)
        .fontColor('#68758E')
        .width('100%')

      Button('立即预约')
        .height(36)
        .onClick(() => {
          postCardAction(this, {
            action: 'router',
            abilityName: 'EntryAbility',
            params: {
              targetPage: 'CreateReservationPage',
              source: 'widget'
            }
          })
        })
    }
    .padding(16)
    .width('100%')
    .height('100%')
  }
}

提示：卡片配置文件、支持尺寸和更新机制必须以当前 API 23 SDK 的 Form Kit 文档为准。卡片不适合承载复杂表单；点击卡片后进入元服务页面完成预约，更符合交互与资源边界。

---

十二、快速迭代：六周如何完成可答辩版本

第一轮：V0.1 原型

目标：证明选题可行。

• 首页；
• 实验室列表；
• 实验室详情；
• 预约表单；
• 本地模拟数据。

交付标准：能从首页完整走到“提交预约成功”。

第二轮：V0.5 业务闭环

目标：证明业务逻辑完整。

• 时段冲突检测；
• 自动/人工审批；
• 我的预约；
• 状态机；
• 取消和签到；
• 审计日志。

交付标准：能演示成功、冲突、驳回、取消、超时五种情况。

第三轮：V1.0 答辩版

目标：体现 HarmonyOS 特色与工程质量。

• 服务卡片；
• 通知提醒；
• 异常处理；
• 测试数据；
• 性能优化；
• 答辩素材；
• 代码注释和 README。

交付标准：真机或模拟环境稳定演示，关键路径无崩溃。

---

十三、轻量化开发带来的效率变化

为了说明元服务方案的价值，教学样例对“传统全量应用方案”和“元服务聚焦核心闭环”进行了同口径比较。

指标	传统全量应用方案	元服务核心闭环	说明
首次进入主要步骤	5	2	卡片/搜索直达
完成预约平均点击	7	4	减少菜单层级
核心业务页面数量	12	6	后台治理能力不搬到端侧
首轮可演示时间	10 天	5 天	先完成最小闭环

这些数据是教学样例中的需求和原型对比，不代表所有学校或所有项目。真正值得复用的是方法：减少入口、收窄边界、复用领域服务、每轮交付可运行版本。

---

十四、安全与隐私：实验室预约不是普通待办事项

系统至少需要处理以下风险。

14.1 越权访问

学生只能查看和修改本人预约；指导教师只能查看授权课题组；管理员只能管理负责的实验室。服务端不能相信客户端传入的角色字段。

14.2 重复提交

提交按钮禁用只能改善前端体验，服务端仍需要幂等键。例如：

export interface RequestContext {
  requestId: string
  operatorId: string
  timestamp: number
}

同一 requestId 只允许创建一次预约。

14.3 并发抢占

查询到“空闲”不等于最终一定能预约成功。写入时必须使用事务、唯一约束或乐观锁再次确认。

14.4 敏感信息最小化

卡片中不显示学号、手机号和课题组敏感信息；通知内容只展示必要摘要；审计日志中对个人字段做脱敏。

14.5 预约码防滥用

签到码应设置短有效期，不能只用可长期转发的静态二维码。签到还可以结合实验室范围、时间窗口和账号身份校验。

---

十五、测试方案：不要只展示“正常预约成功”

毕业设计至少应覆盖以下测试。

15.1 单元测试

• 时间段重叠判断；
• 自动审批规则；
• 状态机合法流转；
• 人数和容量校验；
• 超时释放规则。

15.2 集成测试

• 查询空闲后提交；
• 两个用户同时抢占同一时段；
• 审批通过后卡片刷新；
• 取消后时段重新释放；
• 管理员停用实验室后禁止新预约。

15.3 UI 测试

• 不同屏幕尺寸；
• 深浅色模式；
• 长实验室名称；
• 网络失败重试；
• 重复点击提交；
• 无数据、加载中和错误状态。

15.4 体验测试

邀请同学在没有讲解的情况下完成一次预约，观察：

• 是否能找到入口；
• 是否理解“待审批”和“已通过”；
• 是否知道在哪里取消；
• 是否能看懂签到要求；
• 是否会因为卡片信息不足而困惑。

---

十六、导师评价：模拟评审意见与改进建议

以下内容是依据校企合作毕业答辩常见关注点整理的模拟评语。

16.1 指导教师视角

选题贴近学校真实管理场景，功能闭环清楚，能够把元服务的轻量入口与预约状态管理结合起来。建议继续补充角色权限、异常释放和实验室设备安全规则，避免项目只体现界面交互。

改进动作：

• 增加角色权限矩阵；
• 增加超时未签到自动释放；
• 对高风险设备增加人工审批；
• 增加状态机和审计日志章节。

16.2 企业导师视角

项目最大的亮点不是“使用了元服务”，而是把高频预约任务从复杂后台中拆出来。建议进一步说明元服务与管理后台的边界，并用指标证明入口缩短和迭代效率提升。

改进动作：

• 删除端侧低频管理页面；
• 增加轻量化边界图；
• 记录首轮开发时间和点击路径；
• 把卡片定位为状态摘要与入口，不在卡片内做复杂表单。

16.3 答辩评委视角

架构、代码和场景匹配度较好，但演示数据和导师评价要说明来源，避免把教学样例写成真实上线结论。建议增加并发冲突演示和失败场景。

改进动作：

• 所有数据注明样本口径；
• UI 图注明“示意图”；
• 导师评语注明“模拟评审意见”；
• 增加双用户抢占同一时段演示；
• 增加网络失败和重复提交处理。

---

十七、答辩演示建议：五分钟讲清楚一个闭环

第 1 分钟：为什么做

展示传统预约流程的痛点：入口深、状态不透明、管理员重复答疑。

第 2 分钟：为什么用元服务

展示卡片和首页：用户无需在复杂菜单中寻找功能，点击即可预约或查看状态。

第 3 分钟：核心技术

展示架构图、冲突检测、审批策略和状态机。强调业务规则集中在服务层。

第 4 分钟：异常场景

演示两名用户同时预约同一时段，一人成功、一人收到冲突提示；再演示取消后时段释放。

第 5 分钟：成果与改进

展示效率对比、导师模拟评语和下一步计划，包括门禁联动、设备状态接入和跨设备管理看板。

---

十八、项目成果与可继续迭代方向

毕业设计完成后，可以形成以下成果：

• HarmonyOS 元服务工程；
• 实验室预约业务闭环；
• 服务卡片；
• 管理端审批原型；
• 领域模型和状态机；
• 测试报告；
• 技术文章；
• 演示视频；
• 答辩 PPT；
• 作品集页面。

后续可以继续扩展：

1. 门禁联动：预约通过后在有效时段生成门禁权限。
2. 设备状态接入：实验设备维护时自动暂停预约。
3. 课题组额度：不同课题组按周或按月分配预约额度。
4. 跨设备管理：管理员在平板或 PC 查看实验室占用看板。
5. 意图直达：用户说“预约明天下午的物联网实验室”直接进入预填表单。
6. 数据分析：统计使用率、爽约率、审批时长和热门时段。
7. 无障碍体验：优化读屏、焦点顺序、字号缩放和高对比度模式。

---

十九、总结

“鸿蒙元服务驱动的实验室预约管理系统”是一个非常适合毕业设计的选题，因为它同时具备真实痛点、轻量入口、业务规则、数据模型、安全要求和 HarmonyOS 平台特色。

项目的核心不是把一个传统管理平台改写成 ArkTS，而是重新定义服务边界：把学生最常用的“查空闲—预约—看状态—签到/取消”做成秒开直达的元服务，把复杂排班、资产维护和权限治理留在管理后台；用服务卡片承载摘要和入口，用领域服务保证冲突检测与状态一致，用快速迭代方法在有限毕业设计周期内持续交付可运行版本。

从校企合作教学角度看，这个项目既能训练 ArkTS、ArkUI、Stage Model 和服务卡片开发，也能训练需求分析、领域建模、并发控制、隐私安全、测试设计和答辩表达。它不是一个“页面数量很多”的项目，而是一个小而完整、能够解释、能够复现、能够继续迭代的鸿蒙毕业设计案例。

---

转载自：https://blog.csdn.net/u014727709/article/details/162997968
欢迎 👍点赞✍评论⭐收藏，欢迎指正