修正雙重Promise (double-wrapped)

[cyfung1031]

不好意思，改动有点多

主要是我看到有很多写法都是用async/await, 但最后回传却是 Promise.resolve Promise.reject这样的双重Promise写法。
ScriptCat的写法大多都是同步处理，不用异步的 new Promise (...) 这种格式
那麼都改成 async/await 比较好。代码较短也易维护。
必要的地方才使用Promise.resolve Promise.reject吧

---

有几个地方好像原本的Logic有问题
维持了本来的Logic但加了註解

有空就看一下吧。

---

针对 Promise 处理，有几个位置明显有问题，或者是明显有更好写法的部份，也改动了
反正用Git比对一下新旧代码就看得出来吧
如果有些部份未能理解，也可以提出

[Copilot]

Pull Request Overview

This PR refactors the code to remove double-wrapped promises by converting returns of Promise.resolve/Promise.reject into direct async/await returns and throws. Key changes include cleaning up promise handling in utility and service modules, streamlining error reporting, and improving overall code maintainability.

Reviewed Changes

Copilot reviewed 35 out of 35 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tests/utils.ts	Simplified inline promise returns in Blob text method.
src/pkg/utils/script.ts	Replaced Promise.resolve with direct object returns.
src/pkg/backup/import.ts	Consolidated promise handling in file import logic.
src/pkg/backup/export.ts	Converted Promise.resolve calls in export functions.
src/pages/store/utils.ts	Removed unnecessary promise wrapping in mapping functions.
src/app/service/*	Updated promise rejections to async throws across services.
packages/filesystem/*	Standardized async/await usage in filesystem API methods.

Comments suppressed due to low confidence (1)

src/app/service/service_worker/runtime.ts:391

• [nitpick] Using '__' as a discard variable may be unclear. Consider renaming it to a more descriptive placeholder such as '_unused' or omitting the value if it is not needed.

    const [scriptFlag, __] = await Promise.all([this.getMessageFlag(), this.loadScriptMatchInfo()]); // 只执行 loadScriptMatchInfo 但不获取结果

[CodFrm]

看起来没问题，我测试一下，感谢🙏

Logic有问题的地方是// 不处理 Promise.reject ?这些么？

[cyfung1031]

看起来没问题，我测试一下，感谢🙏

Logic有问题的地方是// 不处理 Promise.reject ?这些么？

我看到腳本有些是 Promise.all, 有些是Promise.allSettled

---

Promise.all 的話，裡面其中一個報錯，錯誤會反映到這個all的Promise上。

promise3 = Promise.all([ promise1, promise2 ]).catch((e)=>console.log("err"))

promise1 或 promise2錯， 會導致promise3報錯 （出現err）

---

Promise.allSettled 的話，是已經預期裡面會有錯。錯誤不會導致promise3報錯。
這樣聽起來不錯。但要有相對應的處理

promise3 = Promise.allSettled([ promise1, promise2 ])

await promise3 的結果裡，會顯示哪些成功，哪些失敗

---

Promise.all 例

const f1 = async () =>{
  console.log(1);
  return 1;
}
const f2 = async () =>{
  console.log(2);
  throw new Error("XXX")
  return 2;
}

(async ()=>{

const r = await Promise.all(
  [
    f1(),
    f2()
  ]
)
console.log(3, r)
})()

---

Promise.allSettled 例

const f1 = async () =>{
  console.log(1);
  return 1;
}
const f2 = async () =>{
  console.log(2);
  throw new Error("XXX")
  return 2;
}

(async ()=>{

const r = await Promise.allSettled(
  [
    f1(),
    f2()
  ]
)
console.log(3, r)
})()

[cyfung1031]

所以我看到你有故意加 reject ( 其他的要一層層Promise看，不容易看出來）
就在想這應該會把整個Promise.all 都報錯然後執行不了下去

呀，migrateToChromeStorage 這個有try catch, 應該還好
getScriptBackupData 那個就好像沒有try catch處理吧

[CodFrm]

我知道Promise.all与Promise.allSettled的区别，有些地方，如果报错影响比起忽略，我更希望直接结束流程，不往后面继续。有的地方又希望忽略错误，不让一部分错误影响全局。主要是基于业务情况去考虑（像getResourceByType和importByUrls就是Promise.allSettled）

不过像：migrateToChromeStorage 一部分失败，直接停止迁移流程并打印错误，这是合理的

getScriptBackupData 这块没有try，但是在最上层，有try的处理（options.html页面会调用），失败了会在页面上显示消息

不过总而言之，这些错误处理其实也都没有做得那么严格规范啦

[cyfung1031]

// 只执行 loadScriptMatchInfo 但不获取结果

scriptcat/src/app/service/service_worker/runtime.ts

Line 391 in 49020ea

const [scriptFlag, __] = await Promise.all([this.getMessageFlag(), this.loadScriptMatchInfo()]); // 只执行 loadScriptMatchInfo 但不获取结果

雖然我也會這樣寫，但ScriptCat裡好像只有這一句是這樣寫。 （其他都是用async/await的直觀流程）
不清楚是不是故意

---

// 无视检查结果，立即回传true

scriptcat/src/app/service/service_worker/script.ts

Line 525 in 3da78e4

return Promise.resolve(true); // 无视检查结果，立即回传true

寫法是沒問題。不知道是不是故意這樣寫。（不理會 批量检查更新 成功與否）

[CodFrm]

// 只执行 loadScriptMatchInfo 但不获取结果

这里是为了加载下面用到的this.scriptMatchCache缓存，由于ServiceWorker的特性，每隔一段时间就会释放掉内存，所以每次匹配脚本时都需要做一次加载，这块逻辑确实有点晦涩难懂

// 无视检查结果，立即回传true

这里是批量的检查更新，批量的数据会很多，无需等待，这个结果对触发端也没有意义，会由ServiceWorker继续处理，有更新的会直接处理更新