上一节解决的是“点哪台就打开哪台”的 ID 与页面状态链路。本篇继续停留在MachineDetail但关注点转为详情页内部一台机台的基本属性、运行状态、关联产品、调机记录和异常信息怎样围绕同一个machineId组织而不是散落在互相独立的页面里。机台详情不是把列表字段放大以后重新排版。列表面向快速扫读重点是编号、名称和当前状态详情页则要让使用者先确认自己查看的是哪台设备再理解它的基础条件和现场关联。页面结构必须帮助用户从“这是什么机台”逐步走到“它关联了哪些业务对象”。一、详情页的输入仍然只有一个 machineId详情组件位于entry/src/main/ets/features/machines/MachineDetail.ets。它接收机台 ID 和三个回调返回列表、打开产品、打开调机记录。Componentexportstruct MachineDetail{machineId:string;onBack:()void(){};onOpenProduct:(productId:string)void(){};onOpenDebug:(recordId:string)void(){};}页面没有再接收一整条Machine对象。这保证了详情页始终按当前 ID 从数据层读取对象也使产品、调机记录等下钻入口能继续把各自的稳定 ID 交给页面容器。详情组件不用知道外层如何切换路由只关心“给定这个机台 ID应该展示什么”。二、先判断对象存在再进入完整内容详情页先调用exists()检查 Repository 中是否有目标对象privateexists():boolean{returndemoBusinessRepository.machineById(this.machineId)!undefined;}这个判断放在整个Scroll外层。不存在时页面显示“未找到机台档案”和返回按钮存在时才渲染完整内容。这样可以避免在空对象上继续访问编号、状态或关联数据。if(!this.exists()){Column({space:12}){Text(未找到机台档案)Text(该演示机台可能已被重置请返回机台列表重新选择。)Button(返回机台列表).onClick(()this.onBack())}}else{Scroll(){// 完整详情内容}}这是一条防御性界面规则不是网络同步已经完成的证明。当前项目使用本地脱敏演示数据未来接入远端接口时还要区分加载中、请求失败、权限拒绝和对象已删除等状态。三、用 currentMachine 统一读取当前对象详情页通过currentMachine()获取被查看对象privatecurrentMachine():Machine{constfound:Machine|undefineddemoBusinessRepository.machineById(this.machineId);returnfoundundefined?newMachine(missing,,,0,,idle):found;}exists()决定是否进入完整页面currentMachine()则为后续渲染提供统一入口。代码中多次调用它看上去像是重复查找但表达了一个清晰边界标题、状态、基础信息和关联查询都基于同一台机台。如果后续数据源改为异步请求可以把查询结果缓存为页面状态减少重复读取但无论怎样优化都不应让标题来自一个对象、关联产品来自另一个 ID。详情页最重要的正确性是所有区块的上下文一致。四、顶部先给出返回入口和状态标签详情内容的第一行放置返回按钮和状态标签Row(){Button(返回).onClick(()this.onBack())Blank()Text(this.currentMachine().statusLabel()).fontColor(this.statusColor(this.currentMachine()))}Blank()把返回和状态推到两端。用户刚进入详情时最先需要确认两个信息是否能安全回到上一层以及当前机台的运行状态。把状态标签放在标题区附近能避免用户滚动到页面中部才发现设备处于维护中。状态颜色由statusColor()统一判断运行中使用成功色维护中使用警示色待机使用另一种提示色。颜色只是辅助状态文字仍然保留不能只依赖颜色传达“运行中”或“维护中”。五、标题区展示识别信息不重复堆叠字段标题区使用机台编号和名称Column({space:6}){Text(this.currentMachine().code).fontSize(24).fontWeight(FontWeight.Bold)Text(this.currentMachine().name).fontSize(14).fontColor(ThemeTokens.textSecondary)}编号是现场识别设备的主要线索因此使用更大的字号和粗体名称解释编号代表的设备用途使用较弱的视觉层级。这个安排与列表卡片一致但详情页不再需要把全部摘要字段挤在一行而是留出空间建立清楚的身份锚点。如果把位置、锁模力和状态都放进标题区用户会在进入页面的第一秒接收过多同层信息。当前写法先回答“我看的是什么”再在下一张信息卡中回答“它在哪里、能力如何、当前怎样”。六、基础信息卡描述机台的稳定属性基础信息区块集中展示锁模力、位置和状态Column({space:10}){Text(基础信息)Text(锁模力${this.currentMachine().tonnage}T)Text(位置${this.currentMachine().location})Text(当前状态${this.currentMachine().statusLabel()})}这三个字段分别回答能力、物理位置和运行状态。Machine构造函数会把锁模力限制为不小于零的值避免演示模型出现负数能力值状态文本则集中由statusLabel()生成列表与详情使用同一套中文标签。需要区分的是锁模力和位置是当前模型中的基础属性状态是当前演示数据的页面状态。它们在详情页并排展示并不意味着已经完成实时设备采集或工业协议接入。七、关联产品区块从 machineId 查询机台详情接下来展示关联产品if(demoBusinessRepository.productsForMachine(this.currentMachine().id).length0){Text(暂无关联产品)}else{ForEach(demoBusinessRepository.productsForMachine(this.currentMachine().id),(product:Product){Button(${product.code}·${product.name}).onClick(()this.onOpenProduct(product.id))},(product:Product)product.id)}这里的重点不是按钮样式而是查询参数始终是currentMachine().id。Repository 的productsForMachine(machineId)会筛选产品模型中的machineIds集合因此产品区块与当前详情对象天然绑定。空集合也有明确文案。没有关联产品不一定是错误可能是设备尚未配置产品也可能是当前演示数据没有覆盖该关系。把“暂无关联产品”写出来比留下一块空白更能帮助使用者判断下一步应该检查配置还是返回列表。八、现场关联把调机记录和异常放在同一语境“现场关联”区块先统计调机记录再显示异常计数privatedebugRecords():DebugRecord[]{returndemoBusinessRepository.debugForMachine(this.currentMachine().id);}Text(最近调机记录${this.debugRecords().length}条)Text(待处理异常${demoBusinessRepository.openExceptionsForMachine(this.currentMachine().id).length}项)调机记录和异常都属于“这台机台正在发生什么”的上下文。把它们放在基础信息之后读者先知道设备能力和位置再看到与现场处理有关的对象信息顺序更接近工程师的实际判断路径。有调机记录时ForEach为每条记录提供可点击入口并把record.id交给onOpenDebug。没有记录时则显示“暂无关联调机记录”。异常数量用强调色提示但页面仍显示具体文字和数量避免颜色成为唯一线索。九、为什么关联查询不在列表页提前完成一种看似省事的做法是在机台列表加载时就把产品、调机记录和异常全部拼到每张卡片里。这会让列表承担大量不必要的数据组织工作也会让滚动列表变得难以阅读。当前实现把卡片保持为摘要把关联查询放到详情页。用户主动打开一台设备时才需要读取与它相关的产品和现场记录。即使当前 Repository 是内存数据这个职责边界仍有价值将来数据量扩大时它也能自然演进为按详情 ID 请求关联信息。十、可复核的检查路径可以使用一台有完整关联数据的机台进行检查从机台列表打开IM-120T-11。核对标题区的编号、名称和状态标签。核对基础信息区的锁模力、位置和当前状态。查看关联产品区是否出现产品条目。查看现场关联区的调机记录数量、记录入口和待处理异常数量。点击返回确认回到机台列表点击关联对象时则应交给页面容器继续打开相应详情。这些检查验证的是当前本地演示数据下的详情组织和 ID 关联。它们不能推导出真实设备数据已经同步也不能替代生产环境中的权限、刷新和异常处理验证。十一、常见错误与排查方法1. 标题和基础信息显示的不是同一台设备先检查是否所有字段都通过currentMachine()获取再检查传入的machineId是否被中途改写为展示编号。详情页应只有一个当前对象来源。2. 关联产品区一直为空检查productsForMachine()的入参是否为机台 ID并确认产品模型的machineIds中包含该 ID。不要用产品名称或机台编号去比较稳定键。3. 调机记录数量正确但点击后没有打开记录检查onOpenDebug(record.id)是否仍把记录 ID 交给页面容器若把machineId误传给调机详情后续组件会找不到对应记录。4. 维护中状态只显示颜色没有文字检查状态标签是否保留statusLabel()返回值。颜色用于加快识别状态文本才是可访问、可复制和可明确沟通的信息。十二、小结本文 让机台详情围绕一个machineId展开顶部确认返回和状态标题区确认设备身份基础信息说明能力与位置关联产品与现场关联则从同一 ID 查询并继续下钻。附录工程配置与版本说明为了便于读者复现本文中的代码片段和运行现象这里把当前文章系列对应的工程基线单独列出。本文所说的“当前工程”指e_notebook项目的 HarmonyOS ArkTS 客户端应用名称为“注塑工程师助手”主要用于脱敏演示机台档案、产品档案、调机记录、参数模板、异常闭环、生产批次和看板报表等业务路径。1. 应用与模块配置应用包名com.atan.enotebook。应用版本versionName为1.0.0versionCode为1000000。工程模型ArkTS / ArkUI Stage 模型。主模块entry模块类型为entry。入口 AbilityEntryAbility入口文件为entry/src/main/ets/entryability/EntryAbility.ets。主页面配置模块通过pages: $profile:main_pages读取页面列表。设备类型当前模块声明支持phone、tablet和2in1。安装方式deliveryWithInstall为trueinstallationFree为false属于随应用安装的普通 entry 模块。2. SDK 与 API 版本DevEco Studio 版本DevEco Studio Beta26.0.0.461。编译 SDKHarmonyOS SDK API 26 Beta1SDK 包版本为26.0.0.23。SDK 平台信息apiVersion为26platformVersion为26.0.0releaseType/stage为Beta1。targetSdkVersion26.0.0。compatibleSdkVersion6.1.1(24)。API 口径说明文章系列以 API 24 作为兼容目标进行表述当前工程实际由 API 26 Beta SDK 编译并在 API 24 模拟器上做过安装、启动和交互观察。因此文中的“API 24 运行观察”表示兼容目标环境下的模拟器验证结果不等同于使用 API 24 SDK 重新完成编译验证。3. 构建与运行工具开发工具 IDEDevEco Studio Beta安装目录指向D:/Program Files/Huawei/DevEco Studio Beta。SDK 路径D:/Program Files/Huawei/DevEco Studio Beta/sdk。构建系统Hvigor工程入口hvigorfile.ts使用ohos/hvigor-ohos-plugin的appTasks。Hvigor 执行配置开启 daemon、incremental、parallel 和 typeCheck日志级别为info。构建脚本本地build.ps1优先使用 DevEco Studio 自带的 JBR、Node.js、SDK 与 Hvigor避免系统环境变量中的 Java 或 Node.js 版本干扰构建结果。调试产物未配置签名时本地构建生成entry/build/default/outputs/default/entry-default-unsigned.hap。这类 unsigned HAP 只用于本地调试和模拟器验证正式发布前需要在 DevEco Studio 中补充签名配置。4. 本系列文章的验证边界本系列代码以脱敏演示数据为主Repository、Store、页面状态和组件边界都围绕本地演示闭环展开。已观察过的运行现象以文中对应截图、布局树和人工核对记录为准没有重新核对的页面不在单篇文章中扩大为完整结论。如果读者使用更新的 DevEco Studio、HarmonyOS SDK 或真机系统版本复现API 差异、控件行为和签名流程可能会发生变化。遇到差异时建议优先核对build-profile.json5、module.json5、SDK Manager 中安装的 API 版本以及当前设备或模拟器的系统 API 等级。附录 2项目目录结构与设计意图下面这份目录说明对应当前 DevEco Studio 中打开的harmonyos-app工程。截图里能看到的目录并不只是文件摆放习惯它反映了一个 ArkTS Stage 工程的分层方式应用级配置、业务模块、页面源码、资源文件、构建配置和过程归档分别放在不同位置方便后续排查问题时先判断“问题属于配置、页面、数据、状态、资源还是构建产物”。harmonyos-app/ ├── AppScope/ # 应用级配置与全局资源入口 │ ├── app.json5 # bundleName、版本号、图标、应用标签等应用级元信息 │ └── resources/ # 应用级图标、字符串和基础资源 ├── entry/ # 主业务模块当前 App 的主要页面和业务代码都在这里 │ ├── src/main/ets/ # ArkTS 源码根目录 │ │ ├── components/ # 可复用 ArkUI 组件如底部导航、数据状态面板 │ │ ├── entryability/ # Stage 模型入口 Ability负责应用启动入口 │ │ ├── features/ # 按业务域拆分的功能页面 │ │ │ ├── debug/ # 调机记录相关页面 │ │ │ ├── exceptions/ # 异常处置与闭环相关页面 │ │ │ ├── home/ # 首页看板与概览入口 │ │ │ ├── machines/ # 机台档案列表、详情和机台相关交互 │ │ │ ├── production/ # 生产批次、报工和结案门禁相关页面 │ │ │ ├── products/ # 产品档案、产品详情和关联信息 │ │ │ ├── reports/ # 周报、月报、班次报表和下钻入口 │ │ │ └── templates/ # 参数模板列表与详情 │ │ ├── models/ # 业务对象的数据结构如 Machine、Product、DebugRecord │ │ ├── pages/ # 页面容器与导航装配如 Index.ets │ │ ├── repositories/ # 脱敏演示数据、查询方法、快照持久化和数据重置边界 │ │ ├── stores/ # 页面路由、导航选择和共享状态规则 │ │ └── utils/ # 主题令牌、校验函数等通用工具 │ ├── src/main/resources/base/ # 模块级资源目录 │ │ ├── element/ # 字符串、颜色等基础资源声明 │ │ ├── media/ # 图标、启动图等媒体资源 │ │ └── profile/ # 页面 profile 配置如 main_pages.json │ ├── src/main/module.json5 # entry 模块配置声明 EntryAbility、设备类型和页面入口 │ ├── build-profile.json5 # 模块级构建目标、混淆和 target 配置 │ └── oh-package.json5 # entry 模块包信息与依赖声明 ├── hvigor/ # Hvigor 构建系统配置 │ └── hvigor-config.json5 # 构建执行参数如增量、并行和类型检查 ├── build-profile.json5 # 工程级 SDK、targetSdkVersion、compatibleSdkVersion 配置 ├── hvigorfile.ts # 工程级构建任务入口接入 appTasks ├── local.properties # 本机 SDK 路径配置 ├── oh-package.json5 # 工程级包信息与依赖声明 ├── build.ps1 # 本地构建脚本固定使用 DevEco Studio 自带工具链 ├── document_claude/ # 开发过程归档、测试记录和验证材料 ├── .hvigor/ # Hvigor 生成的缓存和构建记录不作为手写源码维护 ├── .idea/ # DevEco Studio / IntelliJ 工程配置不承载业务逻辑 └── entry/build/ # 构建输出目录HAP 和中间产物由构建流程生成1. 为什么应用级配置放在AppScopeAppScope负责应用整体身份而不是某个页面的业务逻辑。app.json5中的bundleName、versionName、versionCode、应用图标和应用标签会影响安装包身份、桌面展示和版本识别。把这类配置放在应用级目录可以避免业务页面为了改一个标题或图标而混入应用发布配置。在当前工程中AppScope更像“应用身份证”。它回答的是“这个 App 是谁、版本是多少、展示什么图标”而不是“机台列表怎么筛选、详情页怎么返回”。2. 为什么业务代码集中在entry/src/main/etsentry是当前工程的主业务模块src/main/ets是 ArkTS 源码根目录。截图里打开的MachineDetail.ets就位于features/machines下面说明机台详情页被归入“机台业务域”而不是随意放在全局页面目录中。这种组织方式的好处是定位明确机台问题优先看features/machines产品问题优先看features/products生产批次问题优先看features/production。当文章里讨论某个业务链路时读者也能从目录直接反推代码位置。3.components、features和pages的边界components放的是可复用组件例如底部导航、加载/空态/失败态面板。它们不应该直接知道“当前打开的是哪台机台”而是通过参数和回调服务于不同页面。features放的是业务域页面。每个子目录都围绕一个业务主题组织例如machines负责机台档案templates负责参数模板exceptions负责异常闭环。业务页面可以组合组件也可以读取模型和仓储但应尽量把本业务域的显示和交互留在本目录内。pages更偏页面容器和入口装配。当前Index.ets承担主页面状态切换、底部导航和详情路径分发等职责。它不应该塞满所有业务细节而是负责把用户当前所在位置、打开对象和页面分支组织起来。4.models、repositories和stores分别解决什么问题models定义数据形状例如机台、产品、调机记录、生产批次等对象有哪些字段。它让页面和仓储使用同一套类型语言避免每个页面临时拼对象。repositories定义数据来源和查询边界。当前工程使用脱敏演示数据和本地持久化快照因此仓储层负责“从哪里取数据、按什么 ID 查询、怎样重置演示数据”。页面不直接关心数据是内置数组、Preferences 快照还是后续真实接口。stores定义页面级或应用级状态规则例如当前导航项、路由分支、打开详情的类型和 ID。把状态规则从具体组件中抽出来可以减少“列表、详情、导航互相覆盖状态”的问题。5. 为什么资源放在resources/baseresources/base/element管字符串、颜色等声明resources/base/media管图标和图片resources/base/profile管页面 profile。它们和 ArkTS 页面代码分开是为了让“界面逻辑”和“静态资源”各自清晰。如果页面显示异常先判断是布局代码问题还是资源引用问题。比如图标不显示应优先检查media和资源引用页面无法进入应检查profile/main_pages.json和module.json5的页面声明颜色或字符串不符合预期则回到element下核对。6. 构建目录和生成目录不要手工维护.hvigor、entry/build和部分中间产物目录由构建系统生成主要用于缓存、编译记录、HAP 输出和临时文件。它们可以帮助排查构建结果但不应该作为手写业务代码维护。当前调试 HAP 位于entry/build/default/outputs/default/entry-default-unsigned.hap。这个路径说明构建已经产出安装包但它仍是 unsigned 调试产物正式发布前应回到 DevEco Studio 的签名配置和发布流程而不是直接修改build目录里的文件。