羽球联盟 HarmonyOS NEXT 实战系列 (19/20)：构建、静态检查与质量门禁

文章导读一个 HarmonyOS 工程能不能交付不能只看“代码写完了没有”还要看构建、模块、权限和关键路径是否闭合。构建成功只是底线不是结论首页能打开、详情能进入、设置能生效才说明应用真的站住了。对系列文章来说质量门禁同样适用正文证据要和应用行为一一对应。页面效果质量门禁本身不是一个界面功能但它会决定读者和用户最后看到的到底是什么。如果工程构建不过、入口模块配置有问题或者联网权限没配好前面讲过的首页、赛事页、球员页、个人中心都只是静态草图。对教程项目来说这一点尤其关键因为读者最在意的往往不是你写了多少代码而是他跟着做能不能真的跑起来。羽球联盟的门禁思路比较适合中小型应用先确保工程结构没断再确认主要业务路径可走最后回看文章里的截图和代码有没有指向同一套真实行为。这样做不花哨但非常实用。实战拆解这个项目的工程层次其实很清楚entry负责应用入口和页面承接common负责通用颜色、尺寸、导航和基础组件features负责首页、赛事、球员、个人中心这些业务页面。只要这三层职责清楚构建出问题时就不至于满工程乱查。从构建配置看项目已经做了两件很正确的事。第一显式声明了三个模块避免业务页和公共能力全部压到入口层。第二打开了strictMode里的caseSensitiveCheck和useNormalizedOHMUrl。前者能提前发现大小写不一致带来的隐患后者能减少模块引用路径不规范造成的问题。对 ArkTS 项目来说这类静态约束越早开后面返工越少。入口模块还声明了联网相关权限这和项目里的远程刷新能力是对得上的。球员页和赛事页都能下拉刷新内容如果权限层面没准备好业务层再漂亮也只是摆设。也就是说质量门禁不只是“代码有没有报错”还包括工程配置是否真正在支撑业务。接下来才是最容易被忽略的一层关键路径验证。构建成功只能说明工程没断不代表业务已经通过。首页能不能打开、赛事详情能不能进入、球员关注是否同步、设置里的深浅色模式是否真的切换这些都要看运行结果。对当前项目来说做一轮首页、赛事、球员、个人中心的关键路径检查比盲目追求更复杂的自动化更值。关键代码{products:[{targetSdkVersion:6.0.2(22),compatibleSdkVersion:6.0.0(20),runtimeOS:HarmonyOS,buildOption:{strictMode:{caseSensitiveCheck:true,useNormalizedOHMUrl:true}},requestPermissions:[ohos.permission.INTERNET,ohos.permission.GET_NETWORK_INFO]}],modules:[{name:entry},{name:common},{name:features}]}这个配置片段很适合作为第 19 篇的正文证据因为它把门禁的底座说清楚了。目标平台版本、严格模式和模块拆分都在这里。一旦这里的结构混乱后面的页面验证就会变成无根之木。设计落点工程构建、静态一致性、关键路径验证必须分层看不要混成一句“已经没问题”。模块结构和权限声明要直接支撑业务场景而不是为了配配置而配配置。文章里的截图、代码和验证结论也要接受同样的门禁约束。易踩坑不要把一次构建成功当成所有问题都解决了运行态问题往往还在后面。遇到刷新失败、页面空白或资源丢失时要先分清是工程配置问题还是业务实现问题。严格模式不要嫌麻烦很多大小写和引用问题越晚暴露修起来越贵。文章里不要写“已验证”这种空话最好明确到“验证了哪条路径、看到了什么结果”。验证方式检查工程是否能顺利构建确认入口模块、公共模块和业务模块之间没有结构性错误。打开首页、赛事页、球员页和个人中心确认主要页面都可达关键入口不会断。触发一次赛事刷新、一次球员关注、一次深浅色切换确认联网、共享状态和设置行为都真实生效。回看文章中的截图、代码片段和验证步骤确认它们确实对应同一版应用行为。参考资料Hvigor 构建工具说明HarmonyOS 工程配置概览HDC 设备调试工具小结第 19 篇真正想建立的是一种交付习惯。构建成功只是第一步模块结构、权限配置、关键路径和正文证据都要能对得上。只有这些层次一起成立项目才不只是“看起来完成”文章也才不是“像在复盘”。