當您對 Windows 篩選平臺回呼驅動程式進行程式設計時，請考慮下列主題。
使用者模式與核心模式
如果可以使用 Windows 篩選平臺內建的標準篩選功能來完成所需的篩選，獨立軟體廠商 （ISV） 應該撰寫使用者模式管理應用程式來設定篩選引擎，而不是撰寫核心模式圖說文字驅動程式。 只有當您必須以無法用標準內建篩選功能處理的方式來處理網路資料時，才應該撰寫核心模式呼叫描述元驅動程式。 如需如何撰寫使用者模式 Windows 篩選平臺管理應用程式的相關資訊，請參閱 Microsoft Windows SDK 中的 Windows 篩選平臺 檔。
過濾層的選擇
呼叫驅動程式應該在網路堆疊中盡可能高的篩選層對網路數據進行篩選。 例如，如果可以在串流層處理所需的篩選工作，則不應在網路層實作。 如需有關驅動程式應使用的篩選層以保證在 Windows 中與 IPsec 相容性的建議的詳細資訊，請參閱 開發 IPsec-Compatible Callout 驅動程式。
在應用層強制執行 (ALE) 的流建立層進行封鎖
通常，如果標註已新增至篩選引擎的其中一個 ALE 流程建立篩選層（FWPM_LAYER_ALE_FLOW_ESTABLISHED_V4 或 FWPM_LAYER_ALE_FLOW_ESTABLISHED_V6），則其 classifyFn 標註函式不應該傳回用於動作的 FWP_ACTION_BLOCK。 不應在其中一個 ALE 流程已建立的過濾層上做出授權或拒絕連線的決定。 這類決定應該一律在其他的 ALE 篩選層之一做出。
這類 classifyFn 函式唯一有效的情況是在發生可能導致安全性風險的錯誤時，傳回動作FWP_ACTION_BLOCK，以中止已建立的連線。 在此情況下，傳回 FWP_ACTION_BLOCK 作為動作將關閉連線，以防止潛在的安全性風險被利用。
標註函數執行時間
因為篩選引擎通常會在 IRQL = DISPATCH_LEVEL 呼叫回呼函式，因此請確保這些函式儘快完成執行，以保持系統的高效運行。 在 IRQL = DISPATCH_LEVEL 時延長執行可能會對系統的整體效能產生負面影響。
插入接收資料路徑
程序應該在呼叫 封包插入函式 之前重新計算 IP 檢查碼，因為當封包從 IP 封包片段重組時，原始封包中的檢查碼可能不正確。 沒有可靠的機制可指出網路緩衝區清單是否從片段重組。
從傳輸層內聯注入TCP資料包
由於 TCP 堆疊的鎖定行為，傳輸層的插入程式無法從 classifyFn 回呼函式注入新的或複製的 TCP 封包。 如果需要內嵌注入，呼叫必須將 DPC 排入佇列才能執行注入。
傳出 IP 標頭對齊方式
當使用其中一個封包注入功能將封包資料注入至傳出路徑時，描述網路緩衝區清單 (NET_BUFFER_CURRENT_MDL(NET_BUFFER_LIST_FIRST_NB(netBufferList))) 中 IP 標頭的 MDL 必須以指針對齊。 因為傳入封包的 IP 標頭 MDL 可能會指標對齊，所以在將傳入封包注入傳出路徑時，必須重建 IP 標頭（如果尚未對齊）。