这篇记录我做鸿蒙任务时遇到的第五类困难：代码已经改完，但构建命令卡住、超时、或者日志里只剩一堆不相关提示。尤其在自动化环境里，如果继续依赖 daemon 模式，很容易出现“实际上构建已经失败，但终端没有及时返回”的误判。

我的经验是：只要进入修复和验证阶段，就优先用 hvigorw assembleHap --no-daemon 固定复现真实错误。它不是万能命令，但能让一次验证更可解释。

### 这篇解决什么问题

* 区分构建卡住、daemon 未返回和真实编译错误。
* 每修一个错误都要留下症状、根因、文件和验证结果。
* HAP、HSP、资源 JSON、ArkTS 语法和发布配置要分层排查。

### 代码来自哪里

* hvigorw
* build-profile.json5
* entry/build-profile.json5
* entry/src/main/module.json5
* entry/src/main/resources/base/element/*.json

一个更稳的验证流程可以从这几条命令开始。

~~~bash
# 如果之前的 daemon 构建疑似卡住，先停掉
hvigorw --stop-daemon-all

# 重新执行 HAP 构建，避免 daemon 返回控制权异常
hvigorw assembleHap --no-daemon

# 如果改动涉及 HSP 页面或共享包，再补 HSP 构建
hvigorw assembleHsp --no-daemon
~~~

遇到错误后不要只看最后一行，先按类型分类：ArkTS 语法、资源解析、路由配置、权限配置、依赖版本、签名或打包。

### 跑出来是什么效果

建议截图时保留三张图：

* 第一次失败日志中最早出现的真实错误。
* 修复后的关键文件 diff 或搜索结果。
* assembleHap --no-daemon 成功结束的终端结果。

> 流程串联：停止异常 daemon → no-daemon 构建 → 定位首个真实错误 → 最小修复 → 重新构建

### 实操步骤

1. 先确认当前工作区没有未理解的改动，避免把别人的修改误当成错误来源。
2. 如果构建卡住，先执行 hvigorw --stop-daemon-all。
3. 运行 hvigorw assembleHap --no-daemon，从第一条真实错误开始看。
4. 每修一个错误，只改直接相关文件，不顺手重构无关代码。
5. 修完后重复构建，直到成功或确认外部环境阻塞。

### 工程质量点

* no-daemon 更适合自动化验证，因为输出和退出状态更容易判断。
* 构建日志里的 warning 不等于 blocker，但新增 warning 也不能完全忽略。
* 资源 JSON、路由 profile 和 module.json5 都要按配置文件思路检查，不要只盯 ArkTS。
* 每次修复都写一条简短 repair note，后续复盘会省很多时间。
* 如果涉及发布审核，再补资源、图标、隐私、日志和权限检查。

### 质量分自评

| 维度 | 分值 | 本篇检查点 |
| --- | --- | --- |
| 问题复现 | 28/30 | 覆盖卡住、超时和真实编译错误三类情况。 |
| 源码定位 | 24/25 | 从构建文件、资源、ArkTS 和模块配置分层定位。 |
| 修复完整度 | 20/20 | 每个错误修复后都重新构建验证。 |
| 工程质量 | 14/15 | 避免把无关重构混进排障过程。 |
| 表达清晰度 | 10/10 | 命令、日志和修复动作对应清楚。 |
| 合计 | 96/100 | 达到训练营发布质量线。 |

### 今日作业

1. 找一次最近的鸿蒙构建失败日志，把第一条真实错误单独摘出来。
2. 用 no-daemon 重新跑一次构建，对比 daemon 模式下的差异。
3. 写一条 repair note：错误症状、根因、改了哪些文件、验证结果是什么。