环境
- SessionRelay 0.5.1（npm 全局），Windows 11 (22631)，Node v24
- 重度使用场景：ZCode 会话源库 229MB / 1457 个文件；多项目（3 个 .sessionrelay）
- 连续 90 秒 CPU/GPU 采样探针 + 进程级句柄/内存追踪实测
三个问题（均实机复现）
1. watch --foreground 不绑定调用方生命周期 → 孤儿进程累积
父进程（shell / 工具调用 / 子代理）退出后 node 不退出，成为孤儿永久驻留。实测一天内积累 15-18 个并发实例（约 13 个孤儿）；每次 --install-service、演练、测试、甚至多个子代理并行审计时都会新增。启动时间呈成批特征（一次 4 个对应一组并行任务）。
2. 无有效单实例锁
.sessionrelay/lock 文件存在时仍可启动新实例（18 个并发共存）。另外 watch --status 按当前目录的项目锁判断——跨项目查询会误报"未运行"，而实际守护在跑。
3. 句柄与内存持续泄漏
单实例运行 7.9h：
- CPU 累计 3761s（持续占用 6-39% 单核，30 次采样无一空闲）
- 句柄 1409 → 4400（2 分钟内暴涨，泄漏加速）
- 内存锯齿：每 10 秒在 812MB ↔ 1904MB 之间摆动（周期性批量申请/释放约 1GB 内存 + 4300 句柄）
机制
每 7 秒轮询 ZCode 源库（229MB）并以 jieba 全量重建中文索引 → 周期性大批量分配/释放，构成锯齿。
影响
--install-service 直接 spawn 守护（不走 cmd），装完 status 正常 → 用户重启前完全无感，资源被持续吞噬- 多实例并存 = 重复捕获/重复索引风险
- 15 实例合计浪费 ≈1.4h CPU + 2.1GB 内存
建议修复方向
- 启动时检测已有实例（命名互斥体/排他锁），发现即退出或接管
- 排查句柄泄漏（未释放的 watcher / fs 句柄）
- 增量索引代替全量重建（或至少跳过未变更会话）
--foreground 提供绑定父进程存活的选项
复查脚本
探针与复查脚本（CPU/GPU 采样、实例清单）已在本仓库使用方的 reviews/ 留档，可提供。
附
感谢这个项目——上述问题不影响我们对它的正面评价（中文检索/零外呼/HOP 设计），资源卫生修好后就是理想的状态底座。
相关：#1（watch-task.cmd 未转义 node 路径，同属 Windows 自启链问题）
环境
三个问题（均实机复现）
1.
watch --foreground不绑定调用方生命周期 → 孤儿进程累积父进程（shell / 工具调用 / 子代理）退出后 node 不退出，成为孤儿永久驻留。实测一天内积累 15-18 个并发实例（约 13 个孤儿）；每次
--install-service、演练、测试、甚至多个子代理并行审计时都会新增。启动时间呈成批特征（一次 4 个对应一组并行任务）。2. 无有效单实例锁
.sessionrelay/lock文件存在时仍可启动新实例（18 个并发共存）。另外watch --status按当前目录的项目锁判断——跨项目查询会误报"未运行"，而实际守护在跑。3. 句柄与内存持续泄漏
单实例运行 7.9h：
机制
每 7 秒轮询 ZCode 源库（229MB）并以 jieba 全量重建中文索引 → 周期性大批量分配/释放，构成锯齿。
影响
--install-service直接 spawn 守护（不走 cmd），装完 status 正常 → 用户重启前完全无感，资源被持续吞噬建议修复方向
--foreground提供绑定父进程存活的选项复查脚本
探针与复查脚本（CPU/GPU 采样、实例清单）已在本仓库使用方的 reviews/ 留档，可提供。
附
感谢这个项目——上述问题不影响我们对它的正面评价（中文检索/零外呼/HOP 设计），资源卫生修好后就是理想的状态底座。