🐛 修复网站匹配/排除重置后清空列表(应回落脚本自带规则)

[CodFrm]

Checklist / 检查清单

• Fixes mentioned issues / 修复已提及的问题
• Code reviewed by human / 代码通过人工检查
• Changes tested / 已完成测试

Description / 描述

脚本设置 → 网站匹配 / 排除，点击「重置」时列表被整个清空，连脚本自带的 @match / @exclude 规则也一并消失。

根因（SettingsPane.tsx 的 setMatchList）：重置按钮调用 setMatchList(kind, undefined)。后端 resetMatch/resetExclude(uuid, undefined) 会删除用户覆盖（selfMetadataUpdate 传空集即删除该 key），使生效列表回落到脚本自带的 metadata.match / metadata.exclude。但前端用 next ?? []，重置时把可见列表置空并写入 selfMetadata[kind] = []，与后端持久化结果不一致，导致脚本自带规则也被隐藏。

修复：前端乐观更新对齐后端 selfMetadataUpdate 语义——重置时把可见列表回落到脚本自带的 metadata 值并删除覆盖，而非置空为 []。新增 / 删除路径（传入真实数组）行为不变。

测试（TDD，先写失败用例再修）：

• 重置匹配后应恢复脚本自带规则而非清空列表
• 重置排除后应恢复脚本自带规则而非清空列表

SettingsPane.test.tsx 全量 27/27 通过；ESLint、tsc --noEmit 均无报错。

Screenshots / 截图

N/A（逻辑修复，无 UI 视觉变化）

[cyfung1031]

PR 当前针对“重置匹配规则”的修复方向是正确的。

当 next === undefined 时，前端会删除对应的覆盖值并回落到脚本原始的 metadata.match；这与后端 selfMetadataUpdate 的行为一致——传入空集合时删除覆盖项。新增的两个测试也覆盖了这条路径，整体实现没有问题。

不过审查时发现，同一根因下还有一条遗漏路径：逐条删除规则，直到列表为空。

原来的实现中，删除最后一项后会调用：

setMatchList(kind, [])

这里传给后端的是空数组，而不是 undefined。后端经过 resetMatch(uuid, []) 和 new Set([]) 后，仍会进入 selfMetadataUpdate 的删除逻辑，最终移除覆盖值，使实际生效规则回落到脚本自带的 metadata.match。

但前端此时仍显示空列表，并写入 selfMetadata[kind] = []，导致前后端状态不一致。用户会以为脚本已经不再匹配任何网站，实际上脚本仍然按照原始的 @match 规则运行；页面刷新后，这些规则还会再次“复活”。

已在 SettingsPane.tsx 中将空数组和 undefined 统一处理：

const override = next?.length ? next : undefined

这样，无论是点击重置，还是逐条删除到空列表，都会走相同的“删除覆盖并回落原始 metadata”逻辑。

修复过程按照仓库的 TDD 规范进行：先补充失败用例，复现“删除最后一项后前端显示为空，但后端已经回落原始规则”的问题，再修改实现。新增测试为：

删除最后一项匹配后，应回落脚本自带规则，而不是显示为空列表。

---

另外还发现几处同类问题，但与本 PR 的修改范围关系较弱，因此没有一并处理，只建议后续单独跟进：

1. 删除最后一个标签

   commitTags([]) 会调用后端 updateMetadata("tag", [])。空数组同样会导致 selfMetadata.tag 覆盖值被删除，刷新后脚本原始的 metadata.tag 会重新出现，而前端在刷新前仍显示为空。

2. Popup 中删除最后一条排除规则

   script.ts:729 附近的 excludeUrl 也存在类似情况。删除最后一条 exclude 后，覆盖值会被移除，最终回落到原始的 metadata.exclude。

   这类问题的根本原因是当前数据模型无法区分：

   • 没有设置覆盖值，使用脚本原始 metadata
   • 明确设置了一个空列表，表示不使用任何规则

   若要彻底解决，需要后端支持保存“空覆盖”，而不是把空集合统一解释为删除覆盖值。

3. 中文文案已过时

   zh-CN/editor.json:69-70 中，after_deleting_match_item 和 after_deleting_exclude_item 描述的行为与当前实现不一致，其中一条文案本身也存在语义矛盾，建议另开 PR 清理。

4. run-in / run-at 的空数组存储差异

   这两项也存在前后端对 [] 处理不一致的情况，不过当前显示逻辑使用 ?.[0]，空数组与未定义在界面上的表现相同，暂时没有可见影响，不需要在本 PR 中调整。

[cyfung1031]

@CodFrm 那4个交给你了