3. Prompt彈窗
Prompt彈窗是在1995年javascript誕生時和Alert彈窗徘铝、Confirm彈窗一起出現(xiàn)的三大彈窗方式之一微渠，但命運軌跡卻完全不同膜蠢。
我們先來分析一下Prompt彈窗不同于另外兩種彈窗形式的主要特點：Prompt彈窗也是模態(tài)阻斷用戶其他交互行為膜楷，要求用戶首先完成當前彈窗的任務砾嫉，輸入系統(tǒng)要求的信息抡砂，或選擇不輸入任何信息大咱，選擇“取消”按鈕解散彈窗。Prompt彈窗的運行機制如下：
要測試Prompt控件的運行效果注益，可以在瀏覽器地址欄輸入如下代碼：
javascript:if(prompt("早飯吃了什么")=='面包'){alert("面包有益身體健康")}else{alert("很遺憾")}
相較于另外兩種彈窗形式的不可或缺和應用廣泛碴巾，Prompt彈窗似乎難以逃避消亡的最終命運，在PC端的Native Software和瀏覽器里丑搔，基本上已經(jīng)難覓其蹤跡厦瓢，在移動端除了一些操作系統(tǒng)級的交互上偶爾可以見到這個控件之外提揍，移動App里基本上已經(jīng)難覓其蹤跡。
除了這種原生控件旷痕，我們還能見到很多類似的變體碳锈，都算是Prompt控件的延伸和擴展：
造成Prompt彈窗逐漸消亡的原因很多，初步分析下來主要有以下幾個因素導致Prompt逐漸式微：
1. 原生的Prompt彈窗應用場景很少欺抗，而大部分可以使用的場景都可以被其他形式的交互控件替代售碳。?
隨著移動互聯(lián)網(wǎng)技術(shù)的發(fā)展，幾種主要的移動應用類型已經(jīng)基本定型绞呈，同時這些應用內(nèi)部的流程頁面也已經(jīng)基本標準化贸人，登錄、注冊佃声、設置艺智、購買、預訂圾亏、添加十拣、刪除都已經(jīng)有標準的UI控件支持宋梧，在這種情況下惫皱，強提醒、模態(tài)顯示的Prompt就很難再有用武之地了晃痴。
2. 原生的Prompt彈窗校驗機制比較弱曹铃，很難控制用戶輸入信息的類型缰趋，造成臟數(shù)據(jù)和服務器被hack風險。
Prompt控件的先天不足決定了用戶輸入數(shù)據(jù)很難被控制陕见，雖然可以進行簡單的本地校驗秘血，但這種開放性輸入框的用戶體驗非常差。
3. 彈窗形式的不斷發(fā)展和變化拓展和模糊了幾種彈窗形式的邊界评甜。
下面這個登陸界面和驗證碼彈窗灰粮，是否屬于Prompt彈窗的延伸，還是其他控件的延伸忍坷？這些界定已經(jīng)隨著彈窗形式的不斷發(fā)展變化越來越模糊谋竖，很多時候我們只是拿這些界面的功能來標注和稱呼，如“登錄彈窗”承匣，“驗證碼彈窗”蓖乘，而不再考慮它是從那種基礎彈窗形式衍生出來的，又或者韧骗，從這幾大類彈窗形式誕生之初嘉抒，這種分類方式就不是按照很科學的方式來界定的。
4. iOS通過使用Prompt彈窗來界定系統(tǒng)級交互和App級交互的區(qū)別
iOS使用原聲的Prompt彈窗樣式來隱喻系統(tǒng)級的交互袍暴，但這種方式也開始受到黑客和釣魚應用的模仿些侍，目前已經(jīng)出現(xiàn)很多釣魚網(wǎng)站模仿iOS原生Prompt彈窗控件樣式來獲取用戶賬號密碼隶症，而用戶之所以中招，很大程度上也是因為受到這種形式隱喻的暗示影響岗宣，所以蘋果要么加強監(jiān)管審核蚂会，要么可能就要考慮更加安全可控的交互方式，畢竟這種原生的Prompt彈窗的偽造成本太低了耗式。
所以胁住，從某種意義上來說，也可以認為Prompt彈窗并沒有式微刊咳，而是隨著技術(shù)發(fā)展和需求提升以多姿多彩的擴展和變異的形式生存下來彪见，只是這些控件都不再以Prompt為名，但他們身上都有著Prompt彈窗的某些特點和烙印娱挨。
