安全沙箱：核心限制來源
Applet 運行於瀏覽器 JVM，為防止惡意碼破壞使用者系統，施加嚴格限制：
1. 本地檔案系統完全隔離
- 無法讀寫本地磁碟 (含暫存目錄)
- 無法列舉目錄、建立檔案、執行程式
- 數位簽章 + 使用者授信後可解除 (簽章 Applet)
2. 禁止原生選單與視窗裝飾
- 無
setMenuBar()，無法建立應用程式級選單列
- 彈出視窗 (Frame/Dialog) 標題列會強制顯示「不受信任的 Applet」警告
- 設計考量：防止偽裝成原生應用竊取密碼/信用卡資訊
3. 對話框信任標記
Dialog 標題列永遠附加 "Untrusted Applet" 文字- 嚴重影響使用者體驗，導致極少 Applet 使用對話框
- 新版瀏覽器對受信任簽章 Applet 放寬此限制
部署與架構挑戰
4. JAR 封裝與數位簽章
- Java 1.1 引入 JAR：將所有類別、圖片、聲音打包壓縮，單一 HTTP 請求下載
jar cf app.jar *.class → <applet archive="app.jar" ...>- 數位簽章驗證發布者身分，建立信任鏈
5. 資料庫存取與郵件發送困境
- JDBC 連線需直接連資料庫埠，防火牆通常封鎖
- 解決方案：中介層 (Servlet/RMI/Web Service) 代理存取，但形成效能瓶頸與單點失效
6. 同源政策限制
- Applet 僅能連回原始伺服器 (代碼庫來源)
- 無法直接呼叫第三方 API，需經伺服器端代理
瀏覽器環境生命週期陷阱
7. 狀態無法持久化
- 使用者換頁/關閉瀏覽器 → Applet
stop()/destroy() 被呼叫
- 無機制自動儲存狀態到本地 (沙箱禁止)
- 伺服器端 Session 可輔助，但增加複雜度
8. 瀏覽器行為不一致
- 離開頁面時：IE 呼叫
stop()、Netscape 呼叫 destroy()、部分瀏覽器直接殺進程
- 導致資料遺失、資源洩漏、執行緒殘留
9. 無正式對話框支援
- 使用者可隨時切換標籤/關閉瀏覽器，模態對話框語意失效
- 無法攔截瀏覽器關閉事件進行確認
現代對應與教訓
| Applet 限制 | 現代 Web 對應 |
|---|
| 本地檔案存取 | File System Access API (需使用者手勢授權)、IndexedDB、OPFS |
| 原生選單/視窗 | PWA 獨立視窗模式、Electron/Tauri 原生殼 |
| 跨域請求 | CORS、Proxy、Service Worker |
| 持久化狀態 | LocalStorage、IndexedDB、Cache API、Sync API |
| 生命週期控制 | Page Lifecycle API、beforeunload、Visibility API |
| 部署分發 | CDN + Service Worker 離線快取、Web App Manifest |
總結
Applet 的限制本質上是瀏覽器沙箱模型的早期嘗試。今日 Web 平台在安全前提下，透過使用者授權機制 (Permission API)、漸進式增強 (PWA)、標準化 API 逐步開放能力。對開發者的啟示：
- 永遠在沙箱邊界設計應用，預期權限可能被拒絕。
- 狀態持久化不能依賴記憶體，需明確儲存策略。
- 生命週期不可控，需實作優雅降級與狀態恢復。
- 跨平台一致性需大量實測，不能假設規格完美實作。
理解 Applet 的限制與失敗，能幫助我們在現代 Web/WASM/桌面混合開發中做出更審慎的架構決策。
