手機平台：網頁、App 與相容性

行動網頁與原生 App

可在手機瀏覽器開啟的服務，不代表有原生 App。原生程式要另行確認商店發行者、作業系統版本與地區供應。瀏覽器捷徑也不等於商店應用程式。

小螢幕操作的檢查點

小螢幕上，表格是否可橫向查看、按鈕是否容易操作與文字是否可放大，比畫面是否縮小更重要。使用者也需要辨認付款狀態與返回流程，避免重要通知被遮住。

相容性是具體條件

Android、iPhone 和 iPad 支援資訊應各自確認。支援某裝置不代表所有版本、所有瀏覽器或所有功能都一致，閱讀相容性資料時要注意適用範圍。

先分辨三種行動入口

「手機可用」可能指行動瀏覽器中的響應式網站、加入主畫面的網頁捷徑，或經 App Store、Google Play 等商店發行的原生程式。它們的更新方式、權限、發行者與相容性證據不同。查核時記錄具體入口、商店或網域、發行主體、作業系統版本及地區供應；只看到手機畫面，不能推定另有原生 App 或相同功能。[4][3]

商店上架是一項可查證的發行狀態，不等於該程式在每個地區都能下載，也不保證商店頁所述功能在目前版本一致。Apple 的審查規則只適用於其 App Store 發行環境，不能代替其他商店政策或各地服務資格。若商店頁、官方網站與實際版本資料互相不一致，應記錄差異和日期，而不是挑選最方便的一項宣稱。[4]

把核心任務放進真實畫面

行動相容性不能只靠首頁截圖判斷。可用固定任務檢查：讀懂付款條件、找到狀態說明、比較兩個平台、展開長篇目錄、調整文字大小，以及在中斷後回到原位置。每項任務都記錄裝置、瀏覽器、方向、縮放與完成結果。這能區分版面能顯示和流程真的可操作，避免把「能載入」誤寫成「完整支援」。[1][3]

觸控也改變錯誤的成本。小型連結若靠滑鼠懸停才顯示條件，手指使用者可能根本看不到；密集表格若沒有固定欄名，橫向滑動時容易失去比較對象。W3C 的行動無障礙資料將觸控、螢幕尺寸與不同輸入方式納入標準脈絡。檢查不應只量按鈕尺寸，也應測試標籤、間距、鍵盤遮擋與操作後回饋。[1][2]

網頁與原生程式各自的限制

行動網頁可以沿用一般網址、由瀏覽器更新，也能以回應式排版適應不同寬度；但瀏覽器支援、離線行為與裝置功能仍受環境限制。原生 App 可以使用作業系統提供的能力，卻需管理商店上架、版本、權限和發行者。MDN 的回應式設計說明的是排版適應方法，不是特定網站已通過各種裝置驗證的證明。[3][5]

因此，目錄應把 mobile web、Android 和 iOS 欄位分開，並為每項留下可追溯來源與查核日期。若僅找到官方網站的行動版入口，應只確認該入口，不把「手機友善」推論為原生程式。未知值也應說明缺少哪一種證據，例如找不到發行者頁面或版本支援清單；這使後續編輯能針對缺口補查，而非重新猜測。[4][1]

兼容性會隨版本與時間變動

瀏覽器、作業系統、螢幕輔助功能與網站版本都可能更新，因此一次測試只支持特定日期和環境下的結論。維護記錄應包含測試日期、版本、主要任務與已知問題，並在重大更新後重驗。不同語言頁面的文字長度也會改變換行和按鈕排列，應將繁體、簡體和英文都納入關鍵路徑，而非只測一種語言。[6][3]

評估報告應描述實際可觀察結果，例如「在某版本瀏覽器中，文章目錄可鍵盤操作」，而不是籠統地稱「全面相容」。同理，未測試的平台保持未知，已知限制則具體列出。這種狹義但可重現的說法，對讀者比籠統的綠色勾選更有用，也讓供應者知道需要改善哪一段操作。[1][2]

流程與可觀察紀錄｜先分辨三種行動入口

從「行動網頁與原生 App」這個問題開始，先畫出讀者實際會遇到的步驟：誰提出請求、哪個系統接收、哪個紀錄代表狀態改變，以及何時才有外部可核對的結果。這張流程圖不必假設所有服務採用相同架構；它的用途是把介面用語拆成可驗證的事件。以「手機網頁」為例，可在行動瀏覽器使用的網頁服務，與原生 App 或商店供應不同。因此，讀者應追問資料由誰產生、是否能重現，以及這項描述適用於哪個版本與地區。若頁面只說「支援」而沒有交代條件，合理結論是資料不足，而不是替它補上常見做法。[1]

用一個具體情境檢查本文概念：假設使用者在網路訊號不穩時送出請求，畫面停在處理中，之後又收到另一個系統的通知。不能只憑其中一個畫面判斷成功或失敗；要比對時間、識別碼、方向與記錄來源，並說明每筆資料能證明哪個階段。「原生 App」在此提供的判讀線索是：為特定作業系統提供的程式，需確認發行者、系統版本與正式下載來源。這個例子是流程分析方法，不是任何特定平台的功能承諾。若缺少可識別的紀錄，文章應保留不確定性，並指出讀者還需要哪一種資料才能完成判斷。[2]

來源範圍與比較條件｜把核心任務放進真實畫面

「Responsive web design」由 MDN Web Docs 發布，本文引用它來支持的範圍是：介紹回應式版面、流動文字與多螢幕設計原則。引用時要把文件的直接陳述與編輯推論分開：前者可用來源連結重查，後者則應以「這表示」「因此可推論」等語句標示，並解釋推理步驟。相容性是具體條件涉及的「平台相容性」則是另一層概念：服務對裝置、瀏覽器與系統的支援範圍，需分別驗證具体版本。來源未談到的產品、司法管轄區、版本或使用者條件，都不能從文件沉默中推得答案。這樣標示證據邊界，讀者才能知道一個結論是否可以移植到自己的問題上。[3]

最容易造成誤讀的不是單一名詞，而是把相鄰階段合併。例如，提出請求、取得授權、完成處理、帳戶顯示更新，可能分別由不同系統記錄。若文章把它們都叫作「完成」，讀者無法知道發生了什麼，也不知道遇到差異時該詢問誰。把「手機網頁」放回它的邊界：可在行動瀏覽器使用的網頁服務，與原生 App 或商店供應不同。逐一檢查主詞、動詞、時間點和記錄來源，能暴露省略的步驟。若各方文件使用不同定義，應並列原詞及其含義，不要為了行文順暢把它們改寫成同義詞。[4]

讀者判讀與更新方法｜網頁與原生程式各自的限制

比較資料前，先寫下可比條件：相同對象、相同定義、相同期間、相同流程方向與相同計算方式。以「原生 App」為例，為特定作業系統提供的程式，需確認發行者、系統版本與正式下載來源；如果兩份資料的分母、版本或觀察窗口不同，數字就不能直接並排。讀者可以把缺少的欄位標為未知，並說明它如何限制結論，而不必用估算填空。這也避免把方便閱讀的表格誤認為精確排名。若目前無法對齊條件，最有資訊量的結果可能是「不可比較」，接著列出重新比較所需的資料。[1]