iframe（內嵌框架）是HTML元素，用於在一個網頁中嵌入另一個HTML文件。它通常用於顯示外部內容，如YouTube影片、Google Maps，甚至Google One Tap 認證等快速集成服務。
無法成為微前端主要架構
在實作微前端專案的時候，通常會選用一個主要架構，例如:
- iFrame
- Web Components
- ModuleFederation
雖然iFrame可以用來實作微前端，但在現代的微前端技術架構中，我們幾乎不會以它成為實作微前端架構的首選。
使用iFrame實作微前端的問題
用戶體驗差
微前端的特點是讓許多分散的網頁組合在一起，讓用戶看起來像只有一個網頁一樣。但透過iframe所組合起來的網頁排版容易混亂，尤其是數量多的時候，容易讓用戶陷入某個iframe中無法離開，又或是導致用戶無一致性操作。
SEO不理想
搜尋引擎爬蟲通常無法有效索引iFrame中的內容，這會對網站的搜尋引擎優化（SEO）產生負面影響，降低頁面在搜尋結果中的排名。
性能
每個iFrame都需要獨立載入和渲染，這增加了頁面的HTTP請求數量(其中可能有很多不是你需要的HTTP請求)，可能導致載入速度變慢，特別是在大型網站中。
開發體驗差
以軟體開發彈性程度來說，iFrame是難以跟其他方法批敵的。iFrame是嵌入整個網頁，如果只需要網頁中的一小區塊(小元件)，就會導致元件提供方需要再獨立一個網頁出來(至少需要獨立另一個路徑出來)。非常容易違反軟體開發的漸進增強原則，修改大量非核心商業邏輯。
你說iFrame是專門是用來給人家組合插入的元素，但是專門做組合元件的專案不會以它為技術首選?!
iFrame仍發揮著不可忽視的作用
上面列了這麼多缺點，難道iFrame就沒有其他用處了嗎?
上面列的是iFrame在微前端架構中所面臨的問題，但是在嵌入單一複雜組件、創建隔離環境，以及實現跨界元件 中發揮著不可忽視的作用。
iFrame 常見使用場景
嵌入小型 UI 組件
如果你的iFrame內容夠小、夠通用、夠精確，那麼iFrame仍是相當方便的嵌入或分享元件的手段。
案例：
- YouTube 播放器
- Google 地圖或第三方表單。
這些元件可以隨插隨用，因為iFrame目前大部分瀏覽器都支援，而且導入的對象是一個完整的site，非部分元件，比較不會有只有元件載入頁面但是Http Request失效的問題。
替這些元件提供全域API
案例：
- Spotiy iFrame API https://developer.spotify.com/documentation/embeds/tutorials/using-the-iframe-api
- Youtube iFrame API
https://developers.google.com/youtube/iframe_api_reference?hl=zh-tw - WorkAdventure
https://docs.workadventu.re/developer/map-scripting/
這類API通常會跟另外iFrame元件有一定程度的相依關係，
- 例如:先嵌入播放器，再透過這個API去控制。
實際作法都是在瀏覽器的全域window底下新增一個一個物件，透過這物件來提供全域API。
如果仔細去看Youtube或是WA的程式，就會看到這種程式碼
window.YT = ...
window.WA = ....
iFrame雖然不適合作為主要的微前端架構，但卻非常適合用來分享小型元件。這些iFrame元件幾乎可以忽略不同瀏覽器或前端框架（如React、Vue、Angular）之間的差異，在大多數情況下都能通用。我們只需確保這些iFrame元件的切割合理，並提供適當的全域API，即可順利運作。
混用
在我的專案中，我們已經使用Webpack的ModuleFederation架構超過兩年了。曾經有客戶希望將我們的ModuleFederation元件嵌入他們運行多年的舊有前端專案中。
由於我們無法為客戶調整其前端框架，也不願針對單一客戶開發客製化的程式碼，最終為了不影響我們元件的邏輯架構，我們決定讓他們使用iFrame將我們的元件包裝起來使用。
結論
在當前的前端技術中，iFrame確實不適合作為微前端實作的主要技術架構。然而，在某些特殊情境下，或在元件規劃足夠嚴謹的情況下，iFrame依然有其不可或缺的作用。
沒有不對的技術，只有適不適合的應用場景，希望我們都能找到最適合自身需求的方法。
