這是一個關于性能的問題，比什么都重要。
Node 公開了三種不同型別的方法來完成各種檔案系統任務：
- 承諾 API（異步）
- 回呼 API（異步）
- 同步 API（同步）
我讀過的文章和 stackoverflow 的答案比我能數的要多，所有這些都聲稱永遠不需要同步方法。
我最近撰寫了一個腳本，如果它們不存在，則需要創建幾個目錄。在此期間，我注意到如果我使用 async/await 方法（主要是fs.promises.mkdir和fs.promises.access），事件回圈將簡單地繼續到下一個異步代碼位，而不管下一個位需要這些目錄。這是預期的行為，畢竟它是異步的。
我知道這可以通過一個不錯的小回呼地獄 sesh 來解決，但這不是問題，而 promise api 可以用于所有其他方法的想法是。
那么問題就變成了：
在相同的異步方法上使用 Node 的檔案系統同步方法會更好嗎？
在這種情況下是否真的需要阻止該程序？
或者換一種說法：
是否可以完全避免同步方法并且只使用 promises api （不是 promises 回呼）？
似乎使用同步方法（考慮到我上面的情況，在進行任何其他呼叫之前目錄必須存在）對于撰寫可讀、清晰的代碼非常有用，即使它可能會對性能產生負面影響。
話雖如此，有大量資訊表明同步 api 完全沒用且從不需要。
同樣，這純粹是為了迎合 promise api。是的，回呼和承諾都是異步的，但是作業和訊息佇列之間的差異使得這兩個 api 在這種情況下完全不同。
PS：對于示例的附加背景關系，我提供了一個代碼示例，因此您不必想象我的示例；）
謝謝！:)
// Checks if dir exists, if not, creates it. (not the actual code, just an example)
// Sync version
if (!fs.existsSync(dirPath)) {
fs.mkdirSync(dirPath);
}
// Async version
try {
await fs.promises.access(dirPath);
} catch {
await fs.promises.mkdir(dirPath);
}
uj5u.com熱心網友回復：
這取決于實際情況。同步方法的主要好處是它們可以更輕松地使用其結果，主要缺點是它們會阻止所有其他代碼在作業時執行。
如果您發現自己處于其他代碼無法回應事件不是問題的情況下，您可能會認為使用同步方法是合理的 - 如果有問題的代碼沒有機會或理由并行運行與其他任何東西。
例如，您絕對不想在處理請求的服務器內部使用同步方法。
如果您的代碼在腳本首次運行時需要讀取一些組態檔（或創建一些檔案夾），并且它們的數量不足以使并行性受益，那么您可以考慮使用同步方法。
也就是說，即使您當前的實作不需要并行性，要記住的是，如果情況發生變化并且您發現您確實需要允許并行處理，您不必對如果您一開始就使用基于 Promise 的方法，那么您現有的代碼 - 如果您理解該語言，正確使用 Promises 應該很容易，所以如果有機會，您可以考慮使用 Promises反正。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/480046.html
標籤：javascript 节点.js 表现 fs