線程池機制
Node.js依賴libuv的線程池處理異步I/O（如文件讀寫、數據庫查詢）。在高并發或長時間I/O場景下，線程池資源可能耗盡，導致后續請求被阻塞。例如，默認線程池大小為4（可通過UV_THREADPOOL_SIZE調整），若同時有大量文件操作，會因線程不足而延遲。
CPU密集型計算
Node.js為單線程事件循環，主線程執行復雜計算（如加密、大數據處理）時，會阻塞事件循環，無法處理其他請求。例如，未優化的循環或遞歸算法會占用大量CPU時間，導致響應延遲。
內存泄漏
未正確釋放內存（如全局變量、未移除的事件監聽器、閉包持有引用）會導致內存逐漸耗盡，觸發頻繁垃圾回收（GC），進而影響性能。例如，未清理的定時器或事件監聽器會持續占用內存，導致應用崩潰。
磁盤I/O瓶頸
頻繁的磁盤讀寫操作（如大文件讀取、數據庫日志寫入）會占用線程池資源，尤其是使用機械硬盤時，I/O速度慢會顯著拖慢應用。例如，同步讀取大文件（fs.readFileSync）會阻塞事件循環，導致后續請求無法及時處理。
網絡I/O延遲
同步阻塞的網絡操作（如同步HTTP請求）或高延遲網絡環境（如跨地域API調用）會阻塞事件循環。例如，未使用異步API的數據庫查詢（如mysql.query的回調未用async/await）會導致請求堆積。
并發處理能力不足
Node.js單線程無法充分利用多核CPU，高流量場景下無法提升吞吐量。例如，單進程Node.js應用在4核CPU上只能使用1核，導致CPU資源浪費，無法處理更多并發請求。
第三方庫或依賴問題
低效的第三方庫（如未優化的JSON處理庫）或未更新的依賴（如存在性能bug的舊版本庫）會增加處理時間。例如，使用JSON.stringify處理大數據時，fast-json-stringify比原生方法快數倍；未更新的express版本可能存在內存泄漏問題。
