Workspace.SignalBehavior 屬性控制事件處理程序是立即觸發還是延遲觸發。建議使用 Enum.SignalBehavior.Deferred 選項，這有助於提高引擎的性能和正確性。延遲事件的事件處理程序在下一個 恢復點 恢復執行，並與任何新觸發的事件處理程序一起執行。
Workspace.SignalBehavior 的 Enum.SignalBehavior.Default 值當前等同於 Enum.SignalBehavior.Immediate，但最終將轉變為等同於 Enum.SignalBehavior.Deferred。模板位置預設直接設置為 Enum.SignalBehavior.Deferred。
下面的圖表比較了 Immediate 事件行為和 Deferred 事件行為。
- 使用 Immediate 行為時，如果一個事件觸發了另一個事件，第二個事件處理程序將立即執行。
- 使用 Deferred 行為時，第二個事件會被添加到隊列的後面並稍後運行。
總耗時不變，但順序不同。
“重進入”防止事件在達到某個深度時不斷觸發彼此。目前此限制為10。
延遲事件的好處
Immediate 行為有一些缺點。每當您向遊戲添加實例、更改屬性或觸發其他某個事件時，引擎需要在其他事情發生之前執行 Luau 代碼。
- 要更改1,000個屬性，可能需要在每次更改後運行1,000段代碼。
- 可以出現奇怪的、難以診斷的錯誤，例如，在某些東西甚至尚未添加時就觸發了移除事件。
- 性能關鍵系統可能會觸發事件，要求它們在 Luau 之間來回延遲。
- 事件處理程序可以在每次事件觸發時對位置進行更改或觸發其他事件。
- 一個事件可能多次觸發，儘管是冗餘的，例如屬性兩次更改。
通過在引擎的生命週期中特定的部分讓 Luau 運行，引擎可以通過使用多個假設來提高性能：
- 性能關鍵系統不需要向 Luau 讓步，這導致性能提升。
- 除非引擎本身更改，否則位置在恢復點之外永遠不會更改。
恢復點
在被延遲後，事件處理程序會在下一個恢復點恢復。當前的恢復點集合包括：
- 輸入處理（每個需要處理的輸入恢復一次，見 UserInputService）
- 過時等待腳本恢復，如 wait(), spawn(), 和 delay()
常見受影響的代碼模式
使用遠端事件時，以下示例要麼無法正常工作，要麼表現略有不同；它們依賴事件立即恢復。
在執行過程中觸發和捕獲事件
在此示例中，當啟用延遲事件時，始終返回 false，因為回調尚未執行。要正常工作，線程必須讓步，直到事件應該已經觸發的時候。
local success = false
event:Connect(function ()
success = true
end)
doSomethingToTriggerEvent() -- 使 `event` 觸發
return success
監聽事件的第一次發生
connection = event:Connect(function ()
connection:Disconnect()
-- 做一些事
end)
啟用延遲事件時，在您斷開與事件的連接之前可以排隊多個事件處理程序調用。調用 Disconnect() 會丟棄所有待處理的事件處理程序調用，這與即時事件的行為相同。
除 Disconnect() 之外的任何其他斷開連接方法，例如在 Instance 上調用 Destroy()，會立即斷開信號，但會執行任何仍在等待的事件的相關事件處理程序。
另外，使用 Once() 作為連接到只需要第一次調用的事件的更方便方法。
變更祖先或屬性的事件
延遲事件使處理祖先或屬性變更的事件在更改祖先或屬性後觸發：
local part = Instance.new("Part", workspace)
local function onPartDestroying()
print("在信號中:", part:GetFullName(), #part:GetChildren())
end
part.Destroying:Connect(onPartDestroying)
part:Destroy()
由於 Destroy() 在調用它的腳本讓步後立即工作，因此在調用 onPartDestroying() 時，實例已經被銷毀。欲了解更多示例，請參見 Instance.Destroying。