鸿蒙项目实战：完成随手账本发布检查与最终验收

技术栈：HarmonyOS · ArkUI · ArkTS

在 测试与发布检查 场景中，核心问题是：项目收尾不能只验证界面。自动化测试、源代码版本、构建产物和签名状态都需要逐项检查。
本文以“随手账本”为示例，围绕“完成随手账本发布检查与最终验收”展开，重点讲解界面结构、状态组织、交互逻辑与测试方法。
实现目标是：增加发布检查卡，对功能完整性、构建状态、界面适配、数据安全和测试结果进行汇总；正式发布前仍需完成应用签名与上架配置。

1. 运行效果

2. 实现目标

完成本文后，可以掌握以下内容：

• 理解“完成随手账本发布检查与最终验收”在记账应用中的界面职责和信息层级；
• 掌握相关 ArkUI 组件的组合方式与样式设置；
• 梳理 @State 状态、事件回调和界面刷新之间的关系；
• 通过正常路径、边界输入和页面回归验证实现结果。

3. 开发环境

项目	配置
开发框架 / 语言	HarmonyOS ArkUI / ArkTS
IDE	DevEco Studio 6.1.1 Release
模拟设备	Pura 90
系统版本	HarmonyOS 6.1.1(24)
示例包名	com.huihui.harmony.pocketledger
核心页面文件	Index.ets

4. 方案设计

从业务流程看，该功能位于以下链路中：

纯函数 → 自动化断言 → 设备执行 → 结果审计 → 发布边界

实现“最终验收”前，可以先拆解以下四个问题：

1. 输入是什么：已有账单、页面偏好、用户输入，还是固定演示数据；
2. 状态放哪里：是否需要 @State，还是只做单向展示；
3. 结果在哪里可见：文字、颜色、列表、进度或页面分支如何变化；
4. 失败时怎么办：空输入、取消、越界、异常或未接入系统能力如何说明。

本文采用的设计方案是：增加发布检查卡，集中展示功能完整性、测试结果、界面适配与构建状态。当前 HAP 尚未配置正式签名，因此发布前仍需完成签名与上架配置。

实现时尤其需要注意：本地验收通过不等于具备正式发布条件，应用签名、隐私声明、权限配置和上架资料仍需单独检查。这既关系到代码正确性，也直接影响最终的使用体验。

5. 核心代码解析

以下代码展示了该功能的核心实现：

Column({space:9}) {
  Text('发布检查')
  .fontSize(20)
  .fontWeight(FontWeight.Bold)
  .fontColor(this.mainText());
Text('发布检查已完成')
  .fontSize(16)
  .fontWeight(FontWeight.Bold)
  .fontColor('#315BEA');
Progress({value:100,total:100,type:ProgressType.Linear}).color('#157A5C')
  .height(12)
  .width('100%');
Text('功能、构建、测试与适配检查均已完成')
  .fontSize(13)
  .fontColor(this.subText()) }
  .width('100%')
  .padding(19)
  .backgroundColor(this.cardBackground())
  .borderRadius(22)

组件与状态说明

观察项	说明
组件构成	Column × 1、Text × 3、Progress × 1
链式属性 / 事件	fontSize、fontWeight、fontColor、mainText、color、height、width、subText、padding、backgroundColor、cardBackground、borderRadius
读取状态	this.mainText、this.subText、this.cardBackground
关键文字	“发布检查”、“发布检查已完成”、“100%”、“功能、构建、测试与适配检查均已完成”
显式颜色	#315BEA、#157A5C

阅读代码时，不要只关注组件数量，还要检查数据从哪里来、状态在哪里读取、事件如何写回，以及最终由哪个组件呈现结果。

6. 状态与交互

ArkUI 的响应式更新可以按照“状态声明 → 组件读取 → 事件写入 → 界面刷新”理解。本文涉及的主要状态如下：

@State private budgetText: string = '5000';
@State private largeFont: boolean = false;
@State private reduceMotion: boolean = true;

该区域以数据展示为主，没有新增点击或输入事件。实现重点是保证数据口径一致、视觉层级清晰，并在主题或窗口变化时保持可读性。

7. 深入实现：从可运行到可维护

7.1 先明确功能边界

“发布检查与最终验收”真正需要解决的数据是构建、安装、启动、交互和数据安全检查项，状态核心是验收结果与阻断问题清单。界面完成的标准不只是能看到对应组件，而是从数据进入页面开始，到用户操作、状态更新、结果渲染形成完整闭环。本文实现中的主路径是：逐项检查后得出是否可发布结论。如果只验证静态截图，而没有检查状态变化后的结果，就很容易遗漏看得见但用不稳的问题。

验收时可以把功能拆成四个层次：

1. 数据层：确认字段来源、默认值和计算口径，避免页面中出现多份互相独立的“同一数据”；
2. 状态层：只保存真正会变化且需要驱动界面的值，可由已有数据计算出的结果不重复保存；
3. 视图层：通过组件层级、字号、间距和语义颜色呈现主次关系；
4. 交互层：明确点击、输入、取消、确认和失败后的状态去向。

测试与发布检查的目标是证明关键行为在可控条件下能够重复得到相同结果。自检面板适合快速观察逻辑，但不能代替自动化测试；构建成功只说明代码能够产出安装包，也不能代替安装、启动、数据恢复、异常路径和回归验证。

7.2 组件树与职责划分

当前核心区域使用了 Column × 1、Text × 3、Progress × 1，相关属性和事件包括 fontSize、fontWeight、fontColor、mainText、color、height、width、subText、padding、backgroundColor、cardBackground、borderRadius。这些组件不应该平铺在一个超长的 build() 方法中。更稳妥的拆分方式，是让页面组件负责整体布局，让业务组件接收展示数据和回调，让纯函数负责计算与格式化。例如，页面只把“当前值、是否选中、点击后做什么”传给子组件，子组件不直接修改不属于自己的账单、预算或账户集合。

可以把调用关系整理为：

原始业务数据
   ↓
格式化 / 筛选 / 汇总等纯计算
   ↓
页面展示模型
   ↓
ArkUI 组件读取状态
   ↓
事件回调更新唯一数据源
   ↓
依赖该数据的组件重新渲染

这条链路中最需要避免的是“双向手工同步”。例如同一个结果既保存在页面字段中，又能由账单数组计算得到，那么任何一次新增、编辑或删除都可能只更新其中一份。对于本功能，建议围绕“验收结果与阻断问题清单”建立唯一入口，并让其他显示值按需派生。

7.3 状态更新为什么能驱动界面

文章代码中读取的状态包括 this.mainText、this.subText、this.cardBackground。ArkUI 会跟踪组件在构建阶段读取的响应式状态；当事件回调写入新值后，相关界面会重新计算。这里的重点不是把所有变量都标记为 @State，而是保持状态最小化。临时输入、页面选择和异步结果可以是状态，固定配置、格式化规则和可计算结果则更适合使用普通字段或方法。

质量检查应先准备独立、可重复的初始数据，再按用例执行操作并记录实际结果。每条用例只验证一个明确行为，失败后保留用例名称、输入、期望值和实际值。发布验收则继续核对构建产物、安装、冷启动、数据恢复和关键交互，不能把某一项成功推导为全部通过。

本功能的重点边界是：构建成功不能代替功能、异常和回归验证。边界处理不应只靠禁用按钮，还需要在真正的提交函数中再次校验，因为业务方法未来可能从其他入口被调用。对于金额、比例和日期等数据，还应在进入模型时完成标准化，页面层只负责展示已经可信的结果。

7.4 交互反馈与异常路径

测试与发布类功能需要验证结果本身是否可信：重复运行应得到一致结论，单条失败不能阻断其余用例记录，测试之间不能共享被修改的脏状态。发布检查还应区分阻断问题和一般建议，并验证签名、权限、隐私说明及最终安装包，而不只是开发环境中的界面。

建议至少补充下面这组专项检查：

检查维度	验证内容
初始状态	默认值与页面文案一致，不依赖上一次热更新残留
连续操作	快速点击或重复提交不会生成重复结果
取消恢复	关闭弹层或返回页面后，正式数据没有被草稿污染
极端数据	空值、零值、负值、超长文本或超大金额得到合理处理
主题与布局	深色主题、窄屏和字体放大后仍能识别主要信息
回归验证	修改该功能后，首页汇总、列表、统计或设置中的关联区域保持一致

7.5 面向真实项目的改进方向

发布前应建立分层质量门槛：纯函数使用单元测试，关键组件使用交互测试，核心业务使用设备端流程测试，最终产物再执行安装与冷启动验证。检查结果要能定位到具体失败项，并把阻断发布的问题与一般优化建议分开记录。

针对“发布检查与最终验收”，推荐的重构方向是：把检查清单纳入持续集成和版本发布流程。重构时不要一次改动所有层，可以先把纯计算提取出来并补测试，再拆业务组件，最后接入持久化或系统能力。这样每次调整都有可验证结果，也能减少界面代码与数据逻辑相互牵连。

纯业务函数应进入正式单元测试，关键页面进入组件或设备端交互测试，构建、安装与启动检查进入持续集成或发布脚本。自检面板可以保留为开发工具，但结果应能追溯到具体规则；发布清单则需要和版本号、构建产物及执行时间关联。

8. 关键实现推演

8.1 数据流不能停留在截图层面

“鸿蒙项目实战：完成随手账本发布检查与最终验收”是否真正完成，不能只看目标区域是否已经出现，还要检查数据从产生到显示的全过程。发布检查把功能、构建、安装、启动、适配、数据安全、权限与签名分别列为检查项，并关联当前版本产物。

测试与发布检查的核心是让结果可重复、可追溯。每条用例需要固定前置数据、输入、预期结果和清理动作，不能依赖上一次运行遗留的状态。构建、安装、启动、功能交互、数据恢复与发布合规属于不同验证层级，应分别记录结果；某一层通过不能替代其他层，也不能用总进度掩盖具体失败项。对 ArkUI 页面而言，@State 更适合保存会被交互修改、并且确实需要驱动界面的最小状态；能够由现有数据计算出的标题、金额、选中样式或列表结果，应尽量按需派生。这样既减少同步点，也让问题出现时能够沿着“输入—规则—状态—视图”快速定位。

8.2 设计取舍决定后续维护成本

本功能需要特别坚持的一项取舍是：进度百分之百只有在所有阻断项通过时才成立；开发环境构建成功不代表正式签名和上架资料已经完成。这种约束看似比直接把逻辑写进组件多了一层，但它能避免页面同时承担数据校验、业务计算和视觉呈现，后续修改也更容易控制影响范围。

自检面板适合开发阶段快速观察，但它与被测代码运行在同一应用中，不能完全替代独立自动化测试。纯函数可以进行单元测试，关键组件需要交互测试，核心业务还要在真实或模拟设备上完成端到端验证。发布结论则必须关联版本号、构建产物、签名状态、执行环境和检查时间。实现过程中可以先保证业务语义准确，再逐步调整视觉细节。若数据口径、状态归属或失败路径仍不明确，单纯增加圆角、阴影和动画只会把问题隐藏得更深。

8.3 边界场景要按连续操作验证

本功能的重点边界包括：应覆盖干净安装、升级安装、冷启动、数据恢复、权限拒绝、异常退出、正式签名和最终 HAP 校验。验证时不应只做一次静态操作，而要组成连续路径，例如先改变条件、再执行核心动作、随后切换页面并返回，最后重新启动应用检查状态是否符合预期。连续路径更容易暴露草稿污染、异步覆盖、列表位置变化和派生结果未刷新等问题。

边界用例应从业务规则推导，而不是随意罗列：金额聚合要覆盖零值和精度，日期逻辑要覆盖月末和跨期，导入导出要覆盖损坏数据，异步能力要覆盖超时和权限拒绝。失败时保留实际值、日志和最小复现条件；修复后除重跑失败用例外，还要执行受影响模块的回归范围。每次修复后，除了重测当前功能，还应回归与它共享同一数据源的首页、列表、统计、账户或设置区域，防止局部正确而全局口径失配。

8.4 从示例代码演进到真实项目

继续扩展时，可把清单接入持续集成与发布流程，生成包含版本号、产物摘要、执行环境和时间的验收报告。组件输入尽量保持只读，操作通过语义清晰的回调或命令向上提交；业务层返回成功结果或结构化错误，页面根据结果决定刷新、保留草稿、显示反馈还是允许重试。

成熟项目可以把质量门槛接入持续集成：静态检查与单元测试先执行，随后构建 HAP，再完成安装、冷启动和关键路径测试。任何阻断项都应使发布流程停止，一般建议则进入后续优化清单。最终验收报告保留产物校验信息，确保后续能够确认测试的正是准备发布的那个版本。完成重构后，可以用四个问题做验收：事实数据是否只有一个可信来源、派生结果是否使用统一规则、失败后是否保留可恢复状态、跨页面结果是否保持一致。四项都能回答清楚，功能才算从演示效果进入可维护状态。

9. 测试要点

场景	操作	预期结果
冷启动	停止旧 Ability 后启动应用	能看到“发布检查”，不依赖热更新残留
主路径	逐项检查后得出是否可发布结论	目标区域与关联数据同步更新，页面没有额外副作用
边界路径	验证“构建成功不能代替功能、异常和回归验证”	页面保持可用，正式数据不被无效状态污染
导航回归	切换底部栏目后返回 settings	目标内容仍存在，导航选中态正确
可读性	检查标题、数值、辅助文字、颜色和换行	主结果优先，文字不被遮挡或截断

测试时重点观察：本地验收通过不等于具备正式发布条件，应用签名、隐私声明、权限配置和上架资料仍需单独检查。

展示型功能应检查数据口径、文字换行和不同窗口下的可读性；交互型功能还应覆盖空值、取消、重复点击和返回页面后的状态一致性。

10. 常见问题与排查

坑一：把本地验收通过等同于可以正式发布

本地验收通常使用开发签名、固定设备和可控数据，只能证明当前环境中的主要流程可运行。正式发布还需要核对应用签名、版本号、权限声明、隐私说明、上架资料和最终构建产物。排查时应把“功能验收”和“发布资格”拆成两张清单：前者关注行为是否正确，后者关注产物和合规条件是否完整，任何阻断项未完成都不能给出可发布结论。

坑二：用例应覆盖零值、空数组、超限等边界，而不只验证正常输入。

最终验收的边界应覆盖完整生命周期，而不只是给表单输入极端值。至少要包含干净安装、旧版本升级、首次启动无数据、恢复大量数据、权限拒绝、存储失败、异常退出后重启和清空数据后的再次启动。每个场景都要记录前置版本、操作路径和预期结果，尤其要确认升级与恢复不会造成数据重复、字段丢失或页面长期停留在加载状态。

坑三：BUILD SUCCESSFUL 只代表构建完成，不代表签名和发布已经完成。

看到 BUILD SUCCESSFUL 后，还要确认生成的是准备发布的构建变体，版本号和签名证书正确，产物能够在目标设备完成安装与冷启动。若开发包可以安装而正式包失败，应分别检查签名配置、权限声明、混淆或资源裁剪造成的差异。最终报告应保存 HAP 文件摘要、构建时间和测试环境，保证验收对象与实际提交的产物完全一致。

11. 工程化建议

示例代码可以集中在 Index.ets 中便于理解，但随着功能增加，建议逐步按职责拆分：

• 页面层：负责页面结构与路由切换；
• 业务组件层：封装卡片、表单、列表项和状态提示；
• 模型与计算层：管理账单、账户、预算等数据结构和纯计算逻辑；
• 基础服务层：处理 Preferences、文件导入导出、通知和认证；
• 测试层：覆盖纯函数、组件交互和设备端关键路径。

对于“完成随手账本发布检查与最终验收”，优先保证组件输入、输出和回调职责清晰，避免页面组件直接承担全部业务状态。

12. 总结

本文围绕“发布检查与最终验收”完成了界面与状态逻辑。实现关键是让构建、安装、启动、交互和数据安全检查项拥有明确来源，并由“验收结果与阻断问题清单”驱动 ArkUI 组件刷新。完成主路径后，还需要验证构建成功不能代替功能、异常和回归验证。如果继续用于真实项目，建议把检查清单纳入持续集成和版本发布流程，使界面代码、业务计算与数据保存保持清晰边界。

官方参考资料

• ArkUI 开发指南
• ArkTS 状态管理概述