dsh-websearch-direct

LIMITATIONS

Known limitations

内置源的 `routeExtras`（自定义加速入口）**停用状态按 label 存**（如 `github|自定义代理 2`），而删除/重写时 label 会随位置重排 ⇒ 出现： 1. 内置源（如 github）有 ≥2 条 extra，用户停用了**第 2 条 B**； 2. 再删除 **A**（B 前面的那条）； 3. B 的停用状态会**静默转移到错误的行**：从未停用的 B 被误关，用户视角是「我关的是 A，怎么 B 被关了」。 **世代说明**：t6 起（当前哈希 `t6`），停用逻辑迁入 `routeExtras[i].enabled`，旧版依赖 `routeOverrides` 键的方式在**新序列下不再写入该键**。因此「键仍在」只对≤BC7BC505 的旧哈希成立； 当前哈希上，删除前的旧键若已存在会被保留，但**不会新生成**。 **qf-a 补丁效果**：实测「每次重写都带 `enabled`」**能消除本次错位面**；「固化默认启用」是另一类设计权衡， 不应当作「不解决本缺陷」的理由。 > ⚠️ **切勿采用「重写时补写 `enabled`」的修法**：它把「默认启用」固化成条目字段， > 并可能**覆盖 `routeOverrides` 里用户的显式停用** —— 那是把状态来源从「一个」变成「两个」，正是 F1 的成因。 > 正确方向是**位置锚定迁移**（见下），与 v3 对 `custom.proxies` 的做法对齐。 **评估：不阻塞本次发布。** 触发条件较窄 —— 需同时满足 ①内置源有 **≥2 条** extra；②停用的是**非首条**；③再**删除它前面**的条目。 后续任务应做**位置锚定迁移**（给 extra 路由加 `extraIndex`，状态按位置回查条目本身）， 即可与 v3 对自定义代理的处理完全对齐、彻底消除本限制。 **后果只是转移**：停用 A、删 A 后，**从未停用的 B 会突然被停用**。不是「丢失」，而是 **转移到错误的行** —— 用户操作的是 A，B 却莫名其妙变成停用状态。 规避方法： - 操作前先在设置里把目标条目改为「启用」，或 - 完成删除后重新设置一次（关闭再打开该条目的代理开关）。 以上断言全部通过。回归脚本见 `test-v0.3.mjs`，重跑命令： `DSH_HOME=D:/dsh-1 node test-v0.3.mjs all`