提交前检查
问题类型
脚本管理 / 回收站
问题描述
回收站启用状态（trash_enabled）在选项页通过 useSystemConfig("trash_enabled") 异步加载，加载完成前该 hook 返回 undefined。多处前端代码以 trashEnabled ?? true 兜底判断"回收站是否开启"（例如 src/pages/options/routes/ScriptList/index.tsx:223、components.tsx:395、BatchActionsBar.tsx:43、TrashTable.tsx:92/95/215）。
而 Service Worker 端的真实删除逻辑（src/app/service/service_worker/script.ts:550）读取的是 this.systemConfig.getTrashEnabled() 的权威配置值，不受前端加载时序影响。
当用户实际已关闭回收站（trash_enabled = false），但选项页配置尚未加载完成（trashEnabled === undefined）时打开脚本列表并删除脚本：
- 前端
!(undefined ?? true) = false，误判为"回收站已开启"，走可撤销分支，弹出带"撤销"按钮的删除成功提示。
- 但 Service Worker 因为读到真实的
trash_enabled = false，已经调用 destroyActiveScripts 彻底销毁脚本，并未写入回收站。
- 用户点击"撤销"后触发
requestRestoreScripts → restoreScripts（script.ts:644-648），因为回收站里根本没有该脚本记录，抛出 trash scripts not found，前端展示 trash_undo_failed 错误提示。
结果是：界面向用户承诺了一个实际不可能成功的"撤销"操作，脚本其实已经被永久删除，用户会以为撤销失败是偶发故障，而不知道脚本已经无法恢复。
最小复现步骤
- 打开 ScriptCat 选项页的设置页，关闭"回收站"（
trash_enabled 设为 false）。
- 立刻切换到"脚本列表"页面（尽量在系统配置尚未从
chrome.storage 异步加载完成前操作，例如清空缓存后首次打开或极快速切换页面）。
- 在配置仍处于
undefined 的短暂窗口内，删除一个脚本。
- 观察到删除提示中出现"撤销"按钮。
- 点击"撤销"。
期望行为 vs 实际行为
期望：回收站关闭时删除脚本应直接提示"删除成功"，不应出现"撤销"入口，因为脚本已被彻底销毁、无法恢复。
实际：配置加载完成前的短暂窗口内，前端仍按"回收站已开启"处理并展示可撤销的删除提示；点击撤销后失败，报错 trash scripts not found，脚本实际已无法找回。
ScriptCat 版本
v1.5.0-beta
ScriptCat 渠道
自行构建 / dev
Manifest / 扩展模式
MV3
操作系统
不限
浏览器及版本
不限（任意 Chromium/Firefox）
设备类型
桌面端
浏览器/扩展状态
相关用户脚本 / 配置
不涉及特定用户脚本内容；问题与"回收站启用状态"配置项的前端异步加载时序有关，触发窗口为配置加载完成之前的短暂时间段。
日志 / 错误信息 / 截图
点击撤销按钮后，requestRestoreScripts 抛出 trash scripts not found，前端展示 script:trash_undo_failed 对应的错误文案。未提供截图（复现窗口极短，需在配置加载完成前操作）。
是否有临时解决办法
暂未发现。等待系统配置加载完成后再进行删除操作可规避（但用户无法直接感知"是否已加载完成"）。
补充说明（根因与建议修复方向）
根因是把"配置未加载完成"和"回收站已开启"合并成同一个默认值 true，导致这两种状态在关闭态短暂重叠。建议 trashEnabled 为 undefined 时不要用 ?? true 兜底展示可撤销文案，而是在配置未加载完成前禁用删除操作，或改用一个显式的"加载中"状态区分于"已确认开启"。
本 issue 源自对 PR #1585（回收站功能）合并后的复审，对应该 PR 讨论中"设计层面的观察 6"这一项：#1585 (comment) 。复审同时确认了讨论中列出的其余 6 项设计观察（1/2/3/4/7 已在当前代码中修复或本就不构成问题，5 属于既定产品边界），仅此第 6 项在当前主分支代码中仍然存在。
提交前检查
问题类型
脚本管理 / 回收站
问题描述
回收站启用状态（
trash_enabled）在选项页通过useSystemConfig("trash_enabled")异步加载，加载完成前该 hook 返回undefined。多处前端代码以trashEnabled ?? true兜底判断"回收站是否开启"（例如src/pages/options/routes/ScriptList/index.tsx:223、components.tsx:395、BatchActionsBar.tsx:43、TrashTable.tsx:92/95/215）。而 Service Worker 端的真实删除逻辑（
src/app/service/service_worker/script.ts:550）读取的是this.systemConfig.getTrashEnabled()的权威配置值，不受前端加载时序影响。当用户实际已关闭回收站（
trash_enabled = false），但选项页配置尚未加载完成（trashEnabled === undefined）时打开脚本列表并删除脚本：!(undefined ?? true)=false，误判为"回收站已开启"，走可撤销分支，弹出带"撤销"按钮的删除成功提示。trash_enabled = false，已经调用destroyActiveScripts彻底销毁脚本，并未写入回收站。requestRestoreScripts→restoreScripts（script.ts:644-648），因为回收站里根本没有该脚本记录，抛出trash scripts not found，前端展示trash_undo_failed错误提示。结果是：界面向用户承诺了一个实际不可能成功的"撤销"操作，脚本其实已经被永久删除，用户会以为撤销失败是偶发故障，而不知道脚本已经无法恢复。
最小复现步骤
trash_enabled设为false）。chrome.storage异步加载完成前操作，例如清空缓存后首次打开或极快速切换页面）。undefined的短暂窗口内，删除一个脚本。期望行为 vs 实际行为
期望：回收站关闭时删除脚本应直接提示"删除成功"，不应出现"撤销"入口，因为脚本已被彻底销毁、无法恢复。
实际：配置加载完成前的短暂窗口内，前端仍按"回收站已开启"处理并展示可撤销的删除提示；点击撤销后失败，报错
trash scripts not found，脚本实际已无法找回。ScriptCat 版本
v1.5.0-beta
ScriptCat 渠道
自行构建 / dev
Manifest / 扩展模式
MV3
操作系统
不限
浏览器及版本
不限（任意 Chromium/Firefox）
设备类型
桌面端
浏览器/扩展状态
相关用户脚本 / 配置
不涉及特定用户脚本内容；问题与"回收站启用状态"配置项的前端异步加载时序有关，触发窗口为配置加载完成之前的短暂时间段。
日志 / 错误信息 / 截图
点击撤销按钮后，
requestRestoreScripts抛出trash scripts not found，前端展示script:trash_undo_failed对应的错误文案。未提供截图（复现窗口极短，需在配置加载完成前操作）。是否有临时解决办法
暂未发现。等待系统配置加载完成后再进行删除操作可规避（但用户无法直接感知"是否已加载完成"）。
补充说明（根因与建议修复方向）
根因是把"配置未加载完成"和"回收站已开启"合并成同一个默认值
true，导致这两种状态在关闭态短暂重叠。建议trashEnabled为undefined时不要用?? true兜底展示可撤销文案，而是在配置未加载完成前禁用删除操作，或改用一个显式的"加载中"状态区分于"已确认开启"。本 issue 源自对 PR #1585（回收站功能）合并后的复审，对应该 PR 讨论中"设计层面的观察 6"这一项：#1585 (comment) 。复审同时确认了讨论中列出的其余 6 项设计观察（1/2/3/4/7 已在当前代码中修复或本就不构成问题，5 属于既定产品边界），仅此第 6 项在当前主分支代码中仍然存在。