|
|
c426921847
|
fix(plugin): 外部插件的 auto_start 从未生效 —— 补三态启动门
## 缺陷
`plugin.json` 的 `auto_start` 一路写得出来（hmapdev 打包会写），
但 **Load 的目录扫描从不读它**：`loadOne` 里只有持久禁用门与运行态门。
也就是说这个字段在**外部插件上完全不生效** —— 声明 `auto_start: false`
的插件照样开机自启。
（内置模块那条走 `kernelboot/scheduler.go` 的 `p.AutoStart`，与外部插件
是两条路，所以缺陷只暴露在外部插件上。）
## 三态语义（现在三条都成立）
自动启动 auto_start 缺省/true + 启动扫描 ⇒ 拉起
启用但不自启 auto_start=false + 启动扫描 ⇒ 跳过
同上 + plugin_start ⇒ 拉起
禁用 持久禁用清单 + 任何路径 ⇒ 拒绝（plugin_start 也拒）
★ `explicitStart` 是这次的关键设计点：`auto_start: false` 的含义是
"**别在开机时拉起我**"，不是"永远不许启动"。少了这个区分，
按需加载的插件就再也起不来了 —— 比不声明更糟。
## 判据（4 条）
· auto_start=false 在启动扫描时被拦（且不调用 Start）
· 同一插件经显式启动**真的加载并 Start**（plugin_start 可用）
· 未声明 auto_start ⇒ 自启（不误伤存量插件）
· plugin.json 读不到 ⇒ 默认自启（清单损坏不该让插件静默消失）
## ★ 判据第一版是假绿（变异不咬）
第一版直接断言 `loadOneOpt` 返回 true/false。但 **false 有两个来源**：
① 被 auto_start 门拦住（正确）② 没有 plugin.bin 加载失败（噪音）。
两者无法区分 ⇒ 删掉 auto_start 门后判据照样通过。
改成用 `RegisterNative` 注册一个**真能 Start 的**假插件：
返回 true 必然意味着门没拦它，返回 false 必然意味着门拦了它，语义唯一。
修完两个变异都准确咬住（删门 / 忽略 explicitStart）。
|
2026-10-18 11:24:14 +08:00 |
|
