第4篇｜构建日志已经 BUILD SUCCESSFUL，终端却不返回？hvigorw --no-daemon 更适合排障

摘要：很多鸿蒙构建问题不难，难的是“你以为它成功了，脚本却说超时；你以为它失败了，日志里又已经成功”。这类问题我后来几乎都统一收敛到一个做法：排障和自动化验证时，优先使用 hvigorw assembleHap --no-daemon。

如果你做鸿蒙项目做得稍微久一点，大概率都会碰到过类似场景：日志里已经出现 BUILD SUCCESSFUL，可终端就是迟迟不退出；或者脚本层面判定它超时了，搞得你分不清到底是构建本身失败，还是 daemon 没把控制权还回来。

这类问题最恶心的地方在于，它会把“真正的构建失败”和“工具行为不稳定”混在一起。最后你不是在修业务问题，而是在和执行环境扯皮。

问题现象

• 构建日志里已经出现 BUILD SUCCESSFUL，但终端不返回。
• 自动化脚本偶发超时，导致结果难以复现。
• 同一条命令，有时成功退出，有时卡住不动。

根因分析

我后来发现，这类问题很多时候不是业务代码出了多大错，而是 daemon 机制让“成功”“失败”“未退出”这三种状态混在了一起。

对于日常本地开发来说，daemon 确实有提速价值；但对于排障、自动化验证、交付前复查来说，你更需要的是结果稳定、错误直接，而不是“偶尔更快”。

华为官方文档里也明确提供了 --no-daemon 和 --stop-daemon-all 这类参数，本质上就是给这类场景准备的。

我是怎么修的

1. 先停掉已有 daemon，避免旧状态干扰

如果我已经怀疑 daemon 行为不稳定，第一步不会立刻盲重试，而是先把环境清干净：

hvigorw --stop-daemon-all

这个动作的意义不是碰运气，而是避免旧进程继续污染当前判断。

2. 用 --no-daemon 重新跑完整构建

hvigorw assembleHap --no-daemon

如果是在 Windows 环境下：

.\hvigorw.bat assembleHap --no-daemon

我现在基本把这条命令当成鸿蒙项目排障的标准入口，因为它更容易稳定暴露第一条真实错误。

3. 看第一条关键错误，不要被后置噪音带偏

构建日志越往后通常越嘈杂，尤其脚本包装层多了以后，最后那行提示未必是根因。真正有价值的往往是：

• 第一条编译错误
• 第一条依赖错误
• 第一条任务执行异常

4. 把 --no-daemon 固化到自动化验证里

我后来把这个习惯写死在自己的流程里，尤其是下面这些场景：

• 修完 bug 后的回归构建
• 交付前最后一轮检查
• Agent 或脚本自动化执行
• 远程环境和 CI 环境构建

这样做的好处是：构建成功就是成功，失败就是失败，至少结果边界清楚。

修完以后怎么验证

验证很简单，但必须做：

1. 先执行 hvigorw --stop-daemon-all
2. 再执行 hvigorw assembleHap --no-daemon
3. 观察终端是否稳定返回，且错误或成功信息是否清晰

如果这一步都不稳定，后面再谈业务修复意义不大。

这次踩坑我得出的结论

• daemon 适合提速，不适合当排障真相来源。
• 自动化环境里，终端能否稳定返回，本身就是质量要求。
• 构建成功和脚本成功不是一回事，不能混着看。
• 真正要定位问题时，优先追第一条有效错误，而不是最后一行噪音提示。

可以直接带走的排查顺序

如果你也遇到“日志像成功，但结果像失败”的构建问题，我建议按这个顺序查：

1. 先执行 hvigorw --stop-daemon-all
2. 再执行 hvigorw assembleHap --no-daemon
3. 先看第一条关键错误，而不是最后一行
4. 自动化和交付验证统一到 --no-daemon

很多构建排障之所以越查越乱，不是因为问题有多深，而是命令入口一开始就没选对。