鸿蒙实践中心每日任务判定机制实测：dwell 会话与 GitCode Star 的 external_check

今天在鸿蒙开发实践中心（harmonybp）做每日积分任务时，顺手观察了它的任务判定机制，记录几个实测结论，供同样在做鸿蒙生态任务的开发者参考。

1. 浏览案例（dwell 判定）不是"打开页面"就行

「每日浏览一个案例」任务描述是"打开案例详情页并保持浏览 30 秒"。实测发现，仅打开案例详情页停留再久，elapsed_seconds 始终是 0。该任务的 evaluator 是 dwell，需要前端通过站点自身的会话接口上报：先 POST /api/growth/tasks/case-view-daily/sessions（body 里带 case_id，也就是案例 URL 中 /cases/<32位hex> 那一段），拿到 session_id 后，每隔不超过 max_gap_ms（实测 15 秒）向 /api/growth/sessions/<sid>/heartbeat 发一次心跳，累计 counted_ms 达到 30000 后 completed 变 true，today_status 才翻成 done。

两个容易踩的坑：一是心跳间隔要留出请求耗时余量，一旦 gap 超过 15 秒，accumulated_ms 会归零重算（我第二次心跳 gap 到 17 秒就断了）；二是响应里回传的 session_id 与请求用的不一致，后续心跳要改用响应里回传的那个 id，否则累计不连续。

2. Star 任务是 external_check，站点侧状态天然滞后

「Star 鸿蒙案例代码仓」的 evaluator 是 external_check：完成 Star 动作后，harmonybp 的 /api/growth/tasks 接口里 today_status 可能仍是 todo，这是华为服务端异步去 GitCode 核查的正常延迟，不要当天反复重做。另外任务配置里 repos 为空、orgs 只限定 harmony-practice-center、match 为 any，也就是说该组织下任意一个仓库的 Star 都能被识别，遇到某个案例仓 404 时换一个仓库即可。

3. 成长中心侧的 is_finish 同步更晚

harmonybp 自己的任务接口显示 done 之后，developer.huaweicloud.com/grow 成长中心的任务面板（query-mission-list-by-condition 接口）的 is_finish 还会再滞后一段时间才变成 1。判断任务是否真的完成，建议直接查 harmonybp 的 /api/growth/tasks，而不是只看成长中心面板。

总体来说，这套积分任务体系的判定都是服务端行为驱动：dwell 靠心跳、Star 靠外部核查、云端实践靠报表，前端页面状态只是展示层。理解了这一点，就不会在"明明操作了但面板没变"上浪费排查时间。