带心跳上报的迭代器通过每次取元素时同步发送心跳，实现长路径扫描任务的实时健康监控；它强制在每个有效迭代点“报平安”，避免卡死时无人知晓，而普通循环无法区分“忙碌”与“僵死”。
直接用带心跳上报的迭代器监控长路径扫描任务，核心在于把“遍历动作”和“健康信号”绑定在一起——每次取一个元素，就同步发一次心跳，而不是等整个任务跑完才汇报。这能避免任务卡死、超时或资源耗尽时无人知晓。
为什么普通循环做不到实时健康反馈
传统 for 或 while 遍历深层目录或海量文件时，一旦在某层卡住（比如权限拒绝、挂载点异常、网络存储响应延迟），程序可能长时间静默，监控系统无法区分是“还在忙”还是“已僵死”。而心跳上报迭代器强制在每个有效迭代点主动“报平安”，天然具备运行时存活证据。
构造带心跳的迭代器的关键结构
需满足三个基本能力：可暂停/恢复的遍历逻辑、可配置的心跳触发时机、支持外部注入的上报通道。示例如下（Python）：
- 封装 os.walk 或 pathlib.Path.rglob 为生成器，每 yield 一个路径前调用一次 heartbeat() 函数
- heartbeat() 不直接阻塞主流程，而是写入线程安全队列，由独立守护线程异步 POST 到监控端点（如 /health/ping?task=scan-20260518）
- 心跳携带关键上下文：当前路径深度、已处理条目数、最近一次成功访问耗时（ms）、内存占用快照（psutil.Process().memory_info().rss）
实战中必须设置的熔断与降级策略
仅发心跳不够，还要能响应异常信号及时干预：
- 监控服务连续 3 次未收到心跳 → 触发告警并标记该扫描任务为“疑似挂起”
- 单次路径访问耗时超过阈值（如 5s）→ 记录 warn 日志，并自动跳过该子树（避免阻塞全局）
- 内存增长速率异常（如 10 秒内上涨 >200MB）→ 主动 yield None 并 raise MemoryPressureError，交由外层捕获后终止或切片重试
与 4G 模块心跳机制的逻辑一致性
这种设计思路其实和 EC03-DNC 模块的 AT+HEARTM 指令一脉相承：不是靠 TCP 连接保活，而是靠业务层主动“发声”。模块每 60 秒发一次 PING，你的迭代器可以按“每处理 100 个路径”或“每秒至少 1 次”来节奏化心跳。关键是让监控端看到的是“业务进度心跳”，而非“连接存在心跳”——前者才能真实反映任务健康度。
