我的代碼節點一直在超時。但它以前運作得很好。我認為這不是很複雜的代碼。
以下是代碼：
const rawDate = $input.item.json.Date;
const rawTime = $input.item.json.Current_Time;
const parts = rawDate.split(‘-’);
const day = parts[0].padStart(2, ‘0’);
const monthMap = { Jan:‘01’, Feb:‘02’, Mar:‘03’, Apr:‘04’, May:‘05’, Jun:‘06’, Jul:‘07’, Aug:‘08’, Sep:‘09’, Oct:‘10’, Nov:‘11’, Dec:‘12’ };
const mm = monthMap[parts[1]];
const yyyy = 20${parts[2]};
const timeWithMs = rawTime.split(‘T’)[1];
const timePart = timeWithMs.split(‘.’)[0];
const offsetPart = timeWithMs.includes(‘+’) ? +${timeWithMs.split('+')[1]} : -${timeWithMs.split('-')[1]};
return {
…$input.item.json,
Formatted_Date: ${yyyy}-${mm}-${day}T${timePart}${offsetPart}
};
1個讚
const { Date: d, Current_Time: t } = $input.item.json;
const [day, mon, yr] = d.split(‘-’);
const month = {
Jan:‘01’, Feb:‘02’, Mar:‘03’, Apr:‘04’,
May:‘05’, Jun:‘06’, Jul:‘07’, Aug:‘08’,
Sep:‘09’, Oct:‘10’, Nov:‘11’, Dec:‘12’
}[mon];
const time = t.split(‘T’)[1];
const [hms, offset] = time.split(‘.’);
return [
{
json: {
…$input.item.json,
Formatted_Date: 20${yr}-${month}-${day.padStart(2,'0')}T${hms}.${offset || ''}
}
}
];
歡迎 @Elan_Savan！
這段程式碼太簡單了，無法自行觸發 60 秒的限制 - 像這樣的日期字串解析在 1 毫秒以內就能完成。最可能的原因是流入節點的項目數量：程式碼節點預設會針對每個項目執行一次，所以如果你的上游資料量增加了（比如電子表格中有 200 多列），總執行時間會堆積起來，可能會觸發逾時。在編輯器中點擊該節點，檢查一下其輸入端有多少個項目。
如果項目數量看起來正常，也可能是暫時的 Cloud 工作執行器容量問題 - 試著關閉工作流程再打開，然後以測試模式重新執行，看看是否能持續重現此問題。
1個讚
感謝您的見解，@nguyenthieutoan。
您說得對，程式碼本身是輕量級的，通常不應該觸發60秒的執行時間限制。我首先會檢查進入Code節點的項目數量，因為n8n預設會為每個傳入的項目執行程式碼。如果上游來源返回數百筆記錄，累積的執行時間可能會變得很大。
我也建議檢查：
• 工作流程是否以「為每個項目執行一次」或「為所有項目執行一次」模式運行。
• 執行日誌，以識別哪個節點實際消耗了大部分執行時間。
• 任何上游節點，例如HTTP要求、資料庫查詢或試算表操作，這些可能在Code節點執行前引入延遲。
• 如果在n8n Cloud上運行，請檢查記憶體使用情況和工作流程執行歷史，因為暫時的任務執行器壅塞偶爾會影響執行時間。
為了優化，日期轉換也可以使用JavaScript的原生Date處理函式來簡化，減少所需的字串解析量。
