From d05161ac8dc89244178fcac1a8bbc12e483019ac Mon Sep 17 00:00:00 2001 From: JianFeeeee Date: Mon, 21 Sep 2026 10:34:41 +0800 Subject: [PATCH] =?UTF-8?q?fix(plugin):=20=E9=80=80=E9=81=BF=E6=B3=A8?= =?UTF-8?q?=E9=87=8A=E9=87=8C=E6=97=A0=E5=AE=9E=E6=B5=8B=E6=94=AF=E6=92=91?= =?UTF-8?q?=E7=9A=84=E3=80=8C=E6=84=9F=E7=9F=A5=E4=B8=8D=E5=88=B0=E5=B7=A5?= =?UTF-8?q?=E5=85=B7=E7=BC=BA=E5=B8=AD=E3=80=8D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `scheduleProcRestart` 的注释写： 线性退避：1 次→1s，2 次→2s，3 次→3s。崩溃循环时不至于打满 CPU， 又足够快到用户感知不到工具缺席。 前半句是事实（退避确实只为防崩溃循环打满 CPU），后半句是主观断言： 首次重启就要等 1s，这 1s 内该插件的工具是缺席的、调用会直接报错。 「用户感知不到」既无实测支撑，也会让读代码的人误以为是无感恢复。 这正是另一处文档（README「崩溃到恢复 <1s」）同源的问题 —— 实测退避为 1s/2s/3s，故 <1s 从未成立（`procRestartBackoff = time.Second` 由 02cc74c 引入，且该提交是 v1.0.0 的祖先）。 改为写明真实代价与插件侧的正确做法（在 OnStart 里自建重连与状态重建）， 与 SDK 仓 README 刚补的说明保持一致。 --- internal/plugin/dynamic_proc.go | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/internal/plugin/dynamic_proc.go b/internal/plugin/dynamic_proc.go index deafe4e..32faa54 100644 --- a/internal/plugin/dynamic_proc.go +++ b/internal/plugin/dynamic_proc.go @@ -211,8 +211,10 @@ func (r *Registry) scheduleProcRestart(name string, cause error) { return } - // 线性退避：1 次→1s，2 次→2s，3 次→3s。崩溃循环时不至于打满 CPU， - // 又足够快到用户感知不到工具缺席。 + // 线性退避：1 次→1s，2 次→2s，3 次→3s。 + // 目的只是崩溃循环时不至于打满 CPU。 + // 注意这**不是**无感恢复：首次就要等 1s，期间该插件的工具是缺席的， + // 调用会直接报错。需要秒级就位的插件应在 OnStart 里自建重连与状态重建。 delay := time.Duration(n) * procRestartBackoff time.Sleep(delay)