WebWork檔案上傳機制深度剖析：從Request包裝到臨時檔案管理

上傳流程四階段

1. ServletDispatcher.service()：進入點，呼叫wrapRequest()
2. wrapRequest()：偵測MultiPartRequest.isMultiPart(request)，是則包裝為MultiPartRequestWrapper
3. MultiPartRequestWrapper建構子：讀取webwork.multipart.parser屬性（預設Pell、可選Cos、Jakarta），透過反射實例化對應Parser
4. Parser建構子（以JakartaMultiPartRequest為例）：使用Commons FileUpload的DiskFileUpload，setSizeThreshold(0)強制所有項目（含表單欄位）寫入臨時檔案upload_XXXXXX.tmp

關鍵設計觀察

1. 進入Action前檔案已落地

上傳完成於wrapRequest()階段，Action執行時臨時檔案已存在。檔名為系統產生亂碼（upload_00000017.tmp），難以追蹤對應關係，無法實作上傳進度條。

2. 雙重拷貝效能代價

流程：Request InputStream → 臨時檔案 → 目標路徑。WebWork先將完整請求寫入臨時檔，開發者再從wrapper.getFiles("fieldName")取得File物件搬移。大檔案場景下I/O開銷加倍。

3. 臨時檔案清除機制不明確

非上傳欄位的臨時檔會被刪除，但時機不定（有時極早、有時極晚、甚至不刪），推測有Daemon執行緒定期掃描，開發者無法精確控制。

開發者介入點

// 在Action或Interceptor中
MultiPartRequestWrapper wrapper = (MultiPartRequestWrapper) request;
File[] uploaded = wrapper.getFiles("doc"); // 取得臨時檔案陣列
File target = new File("/target/path/" + wrapper.getFileNames("doc")[0]);
FileUtils.copyFile(uploaded[0], target); // 自行搬移/處理

優化建議

• 若需上傳進度，必須擴展MultiPartRequest實作流式處理，避免全量寫臨時檔
• 大檔案建議調大webwork.multipart.maxSize並監控磁碟空間
• 定期清理saveDir殘留臨時檔，防止磁碟爆滿