C# 高效能開發實戰：解決 ASP.NET 樹狀列表控件載入緩慢的效能瓶頸（上）

前言：從發現問題開始

在 ASP.NET 專案開發中，樹狀列表是常見的 UI 元件。近期發現有專案採用名為 dtree 的樹狀列表組件，但在資料量稍大時載入速度明顯緩慢，甚至導致 IE 瀏覽器彈出「指令碼執行過久」的提示。這正是本文探討的起點。正如毛主席所言：「做事要發現問題、分析問題、解決問題。」我們已發現既有控件效能不佳的問題，接著便要深入分析其根本成因。

剖析 dtree 的運作流程

透過程式碼分析，dtree 生成樹狀列表的流程如下圖所示：

具體步驟為：

1. 伺服器端 C# 程式碼查詢資料庫。
2. 根據查詢結果，透過字串拼湊生成一段 JavaScript 代碼字串。
3. 將該 JavaScript 字串傳送至客戶端瀏覽器。
4. 瀏覽器接收並執行 JavaScript，腳本內部再次以字串拼湊方式產出 HTML 字串。
5. 呼叫 document.write 或設定 innerHTML 將 HTML 填入頁面呈現。

其他同類樹狀列表控件的運作邏輯大同小異。

效能瓶頸定位分析

依據上述流程，我們逐一排查各環節耗時：

1. 伺服器端內部處理 —— 非瓶頸

• 資料庫查詢： 通常資料庫與 ASP.NET 應用程式部署於同一台主機或高速區域網路，查詢速度無虞。
• 資料傳遞至 C#： 同機或高速 LAN 環境下，網路延遲可忽略。
• C# 生成 JavaScript 字串： C# 執行效能優異，搭配 StringBuilder 優化字串拼接，只要演算法邏輯合理，速度有保障。

結論：伺服器端內部處理並無明顯效能問題。

2. 網路傳輸 —— 視環境而定

傳輸耗時 = JavaScript 字串長度 ÷ 網路頻寬。若系統運行於高速區域網，此環節非主要問題；但若部署於廣域網或 Internet，龐大的腳本字串將嚴重拖慢首屏載入。本文案例系統主要部署於區域網，故網路傳輸非核心瓶頸。

3. 客戶端瀏覽器執行 JavaScript 生成 HTML —— 核心瓶頸

此為最關鍵的效能殺手：

• JavaScript 為直譯執行，執行速度遠慢於編譯型語言。
• 大量字串拼接操作在 JavaScript 中極為低效，且缺乏類似 StringBuilder 的優化機制。
• 當樹狀列表節點達數千個時，JS 需拼接數百 KB 甚至超過 1 MB 的 HTML 字串，極易觸發 IE 的「指令碼執行過久」警告。

4. 瀏覽器解析 HTML（document.write / innerHTML） —— 非可優化點

此步驟由瀏覽器內核原生處理，外部程式無法干預，且速度尚可接受，無優化空間。

優化策略鎖定

綜上分析，整個渲染鏈路中 「客戶端 JavaScript 拼接 HTML 字串」 為首要優化目標，其次為「伺服器到客戶端的資料傳輸量」。新一代高效能樹狀列表控件的設計核心，便圍繞解決這兩大痛點展開。