控件先佔地、網頁再縮水：蘋果承認 iPhone Duo 外屏 Safari 的空間帳，正在找新的分法

10 月 24 日，科技媒體 9to5Mac 引述蘋果 WebKit 團隊最新博文指出，蘋果已著手處理 iPhone Duo 外屏上 Safari 控件佔用過多空間的問題。這距離這款 15999 元起售的首款折疊 iPhone 全球開賣，只過了幾天（可參考我們先前的iPhone Duo 定價與成本結構分析）。

問題本身不複雜。iPhone Duo 的外屏形態特殊，Safari 將刷新、地址欄等控件右對齊放置後，佔掉了外屏相當比例的區域，網頁正文與圖片被壓縮，可用內容寬度明顯小於展開後的內屏。多家媒體在評測中均指出，現有網站尚未針對這種螢幕形態做最佳化。

蘋果承認了什麼，拒絕了什麼

在介紹 Safari 27.1 的部落格文章中，WebKit 團隊的 Jen Simmons 承認了這個限制：目前網站無法延伸到 Safari 控件後方，開發者難以利用外屏的全部寬度來設計頁面。

但蘋果沒有選擇最直接的解法。Simmons 解釋，如果僅透過 HTML 的 viewport-fit=“cover” 讓網頁延伸到控件後面，許多網站並沒有為安全區域做好適配，結果可能是重要按鈕、文字被遮擋，使用者體驗反而倒退。蘋果目前的方向是研究一種更可靠、對開發者負擔更低的方案，並邀請開發者提交建議。

這個取捨值得攤開來看。對蘋果而言，放開限制的成本幾乎為零，真正被轉嫁成本的是全球數百萬個網站的開發與維護方：每一個未被適配的網站，都會變成使用者的抱怨，而抱怨的出口是瀏覽器與硬體廠商，不是網站本身。蘋果選擇把適配成本留在平臺端消化，而非外部化給長尾開發者。

這筆帳在先前的折疊適配討論裡已經出現過

這類安全區域與適配成本的分工問題，在折疊裝置生態裡並非第一次被量化。跨平臺框架早已把遮擋區域座標轉換列為必須處理的工程項目，例如我們先前分析的Flutter 插件處理 iPhone Duo 遮擋區域的適配帳與CPF-Flutter 的折疊屏分欄方案，都在回答同一個問題：多形態裝置的 UI 適配，成本該記在框架、網站還是平臺哪一欄。

差別在於，框架方案把成本攤給主動接入的開發者，蘋果這次面對的是整個開放 Web，無法逐一要求網站配合。這也解釋了為何蘋果不直接沿用 viewport-fit=“cover” 這個既有開關，而要另尋機制：受影響的主體太多，逐站適配的總成本太高。

影響推演

短期內，使用者承壓。在修復方案落地前，外屏 Safari 的瀏覽體驗維持現狀，內容寬度受限的問題會持續存在，這對以外屏為主要互動介面的輕量使用場景（快速查詢、閱讀）影響最直接。

中期看，開發者相對受惠於蘋果「平臺端解決」的路線。若蘋果提出的方案能讓網站在不修改代碼的情況下獲得更完整的可用寬度，適配負擔就不會擴散到 Web 開發社羣。反之，若最終方案仍需要開發者配合宣告安全區域，適配成本就會沿著與 iOS 劉海時代 env(safe-area-inset-) 相同的路徑，逐站轉嫁出去。

對競爭格局的意涵有限但方向明確。折疊形態的網頁內容呈現是所有折疊機廠商共同面對的問題，蘋果以 WebKit 部落格公開承認限制並徵集建議，把一個產品缺陷轉化為與開發者社羣的對話管道。修復方案的具體形態與落地時間，來源均未提及，這部分暫時保留。

收束

這件事的規模不大，但它示範了折疊時代的一個結構性問題：硬體形態創新所創造的新遮擋區域，最終都要有人付適配成本。蘋果這次選擇不把帳單寄給開發者，代價是修復時程的不確定。方案何時推出、以何種機制呈現，是後續觀察 Safari 27.x 更新節奏的具體指標。