ASP.NET Excel 導入進度條實現：長時間操作的用戶體驗優化方案

痛點與解決方案

在企業級應用中，Excel 數據導入數據庫往往涉及數萬行數據，耗時數十秒甚至分鐘。若無進度反饋，用戶會以為系統死機，導致重複提交或投訴。本文方案採用 Response.Flush() 流式輸出 + 前端 JavaScript 動態更新 DOM 技術，實現真實的服務端進度推送至瀏覽器。

架構設計

1. 進度條頁面模板：獨立 HTML 文件 (ProgressBar.htm)，包含進度條 DOM 結構與 JS 控制函數。
2. 服務端流式輸出：導入過程中，通過 Response.Write() 輸出 <script> 代碼塊，調用前端 JS 函數更新進度。
3. 關鍵技術點：Response.Flush() 強制將緩衝區內容發送給客戶端，打破「請求-響應」的單向阻塞模式。

核心組件代碼

1. 進度條 HTML 模板

2. 服務端導入邏輯
 0 
            ? $"完成！共 {totalRows} 行，{errorCount} 行跳過" 
            : "全部導入成功！";
        ExecuteScript($"EndTrans('{msg}');");
    }
    ExecuteScript($"SetTimeInfo('耗時 {DateTime.Now - startTime}');");
}

// 輔助：安全輸出 script 標籤並刷新
private void ExecuteScript(string scriptContent)
{
    Response.Write($"<script>{scriptContent}</script>");
    Response.Flush();
}


3. Excel 讀取輔助方法

關鍵技術點深度解析

為什麼需要 Response.Flush()？
ASP.NET 默認緩衝整個響應，直到頁面生命周期結束才發送給瀏覽器。Response.Flush() 強制將當前緩衝區內容發送，配合 Response.BufferOutput = true (默認)，實現「流式響應」。

瀏覽器渲染機制配合
瀏覽器接收到 <script> 標籤會**立即執行**其中的 JavaScript，即使整個 HTML 文檔尚未傳輸完畢。這就是「腳本流式執行」的基礎。

常見坑與解決

問題
原因
解決

進度條不動，最後一瞬間跳到 100%
未調用 Flush()，或 IIS/代理緩衝
確保每次 Write 後 Flush；檢查 IIS "動態內容壓縮" 可能干扰
前端 JS 報錯 "對象不存在"
腳本執行時 DOM 尚未就緒
模板先輸出 DOM，Flush，Sleep(500)，再發送腳本
大文件導入超時
HTTP 執行超時 (默認 110s)
web.config 設置 <httpRuntime executionTimeout="600" />
Excel 讀取失敗 "未註冊提供程序"
服務器缺 Access Database Engine
安裝 AccessDatabaseEngine.exe (x64 版)



現代化替代方案
對於新項目，強烈建議採用：

前端：Fetch API + ReadableStream 接收服務端發送事件 (SSE) 或 WebSocket。
後端：ASP.NET Core 中使用 IAsyncEnumerable + ControllerBase.Ok() 流式輸出，或 Hangfire/Quartz 後台任務 + SignalR 推送進度。
文件處理：NPOI / EPPlus / ClosedXML 替代 OLEDB，無需安裝 Office 組件，支持 .xls/.xlsx 純托管讀寫。


總結
本文方案基於經典 ASP.NET Web Forms，利用 Response.Flush() 實現無框架依賴的實時進度反饋，適合維護老系統或快速原型。核心思想——**長連接模擬下的服務端主動推送**——在現代架構中演變為 SSE/WebSocket/gRPC Streaming，理解其本質有助於技術選型與遷移。