從小程式開始公測第一天“所有的技術群都成了小程式群”，所有的開發者都成了小程式開發者，所有的公眾號都成了小程式的義務宣傳隊，所有的App都像是頭上長了刪除號在瑟瑟發抖，所有的16G使用者都在高呼苦盡甘來的“全民高潮”。

由此來看，小程式確實給疲軟已久的移動網際網路生態打了一針強心劑。讓那些推廣無門、流量成本高啟、App的死衚衕越走越窄的創業者抓住了一根救命稻草。

在iPhone誕生10週年之際，時光彷彿倒轉到數年之前，人們第一次解鎖智慧手機，然後盡情肆意地在應用商店的海洋裡遨遊，迫不及待地讓空空如也的桌面被填滿。人們與智慧手機、App“七年之癢”般的關係新鮮如初。智慧手機再次成為人們手上無所不能、最炫最酷的玩具。

然後呢？然後可能就沒有然後了。

小程式並沒有解決App們的“流量焦慮”與“入口危機”

那些興高采烈地喊著要解除安裝掉桌面上App的人們，只不過是把App挪了一個地方而已。小程式作為lite版或閹割版的App，先撇開線下入口這一小程式的“撒手鐗”不說，只說如今試圖“搶灘”小程式中以“拔得頭籌”的虛擬類App（指純線上，不存線上下入口可能的App，如今日頭條、輕芒雜誌等閱讀類App，京東、什麼值得買等電商App等），並沒有解決自身已經陷入困境的App弊病。

App為什麼會從智慧手機青春期的“掌中寵兒”淪落為智慧手機中年期的“滿屏雞肋”？這要從App的誕生開始說起。

為什麼手機的中心是桌面而不是瀏覽器，為什麼手機的需求解決中心是App Store而不是搜尋引擎？為什麼我們的電腦桌面上沒有放滿網站的快捷方式？為什麼我們在電腦上時在百度上搜索蘿蔔燉牛腩的做法，而在手機上則是直接開啟豆果美食或下廚房？

在PC網際網路上，搜尋引擎才是你的“資訊管家”，承擔你幾乎一切的需求響應，然而註定難以應對你的每一種精細需求。而App則是對搜尋引擎任務的拆解，先確定你的需求下載相應的App ，然後再在App裡實現更加精細的資訊篩選（比較一下在百度裡搜尋雪地靴和淘寶搜尋雪地靴的不同）。

App相當於對於搜尋引擎的分散瓦解，用“先確認需求、再篩選資訊”的方式來滿足數億使用者的精細化資訊、服務獲取需求。而一個App就是一個封裝好的內容集合，是開發者自己根據使用者需求、場景對於資訊的再組織。

這就形成了App相當於網頁的缺陷所在——一個封閉的“黑箱”，資訊組織方式各個不同，所以無法被搜尋引擎“爬蟲”，各個App互相成為資料孤島。App Store僅能搜尋App本身，而不能搜尋App裡的內容。這帶來的一個問題就是——App入口的單一化。

鈦媒體之前的文章《豆瓣十年，一朝重來》中曾經分析過為什麼豆瓣移動化轉型不算成功——豆瓣在搜尋引擎中有著極高的權重，1800萬條目都是一個個通向豆瓣的入口，這為豆瓣帶來了源源不斷的流量。而到了移動端，通往豆瓣的入口只剩下了AppStore，你再也不能通過一本書、一部電影、一張專輯直接進入豆瓣。

App入口的單一化、App的孤島化帶來是App推廣成本的一路上揚，應用分發網站的蜂擁而起，App預裝大行其道，App Store刷榜現象的屢禁不止，App Store搜尋位置的明爭暗搶、擁擠異常（蘋果在推出搜尋廣告時透露：60%的應用是通過搜尋發現的）。

對於使用者來說，則是高頻需求早已被滿足，而長尾低頻需求的App越來越難發現。一旦發現成本超過了一定限度，他們就選擇了放棄探索新的App，對App開始意興闌珊。

不僅如此，這種需要先“確認需求”的方式會要求使用者記得自己下過的一個又一個App，以便在下次有需求的時候隨時呼叫。這會給使用者造成越來越大的“心智負擔”與記憶體負擔，尤其是在任何一種細分需求都有一款App的情況下。

小程式並沒有解決App們的“流量焦慮”與“入口危機”。張小龍明確表示不做另一個App Store，不做分類、搜尋、應用分發，雖然小程式可以通過好友、微信群傳播，但少了朋友圈這樣一個“流著奶與蜜”之地，很難享受到微信的流量紅利（想象一下如果公號文章不能分享到朋友圈），只不過是將自己的使用者從原生App轉移一部分過來而已。

而張小龍之所以一再強調小程式的特點是“即用即走”，也是不想讓小程式像微信公號一樣成為一個個“流量黑洞”（詳見鈦媒體文章《同是靠廣告“掘金”，微信為什麼遠沒有 Facebook能賺錢？》），擠佔個人狀態及人際交流的時間，從而危及微信的社交根基。雖然在產品設計上，微信巧妙地平衡了聊天與小程式之間的切換問題，然而在小程式中長時間的內容消費、逛店等行為肯定是張小龍不希望看到的。畢竟，微信不只是承載應用的桌面，還是一個聊天工具。

如果每個小程式都想盡辦法“拖住”使用者，爭搶更多的使用者時間，就意味著對聊天及朋友圈使用時長的“侵佔”。而在應用與聊天視窗之間的頻繁切換，也會使越來越多的使用者開始傾向於輕量級的聊天工具。

線下世界正在快速“數字化”，沒有多少掃一掃入口

而目前熱火朝天的小程式開發熱潮只是“小程式革命”的前奏而已，因為張小龍的野心在於把小程式作為打通線上、線下的入口，讓二維碼嵌入線下任何一個消費場景，從而徹底“收割”線下流量。

張小龍曾經提到：移動網際網路時代企業商家與使用者的接觸反而比PC時代更難。其實我們可以再延伸一下：比前網際網路時代更難。

為什麼？因為在前網際網路時代，開在街頭的店鋪是會有“自然流量”的（因為人口的均勻分佈，人流的運動會導致店鋪有自然露出的機會），而商家企業也可以通過戶外廣告、傳單、條幅等手段接觸到消費者（雖然無效曝光比例很高）。

而在網際網路上，商家企業的“自然流量”消失了，流量的分配權被掌握在搜尋引擎、電商平臺手中。他們連發傳單平臺都會從中抽成（團購之所以難以為繼是因為線上發傳單也是有成本的，且成本難以收回，線下店鋪之所以生存艱難，就是因為他們要同時承擔線上、線下雙重流量成本）。

如果說線下的商店除了進駐萬達這樣的商業綜合體，還可以選擇開在人流如織的路口，在線上它們除了進駐電商平臺幾乎沒有別的選擇。它們不再有消費者可以直接進店的入口，而只能臣服於電商的流量邏輯之下。這或許就是張小龍所說的意思

小程式要做線下世界到線上世界的入口，但問題是線下店鋪已經有了線上的入口（點評，美團，餓了麼，去哪兒），而且是擺脫了實體世界的束縛，可以按照消費者需求重新組織（排序，篩選，搜尋）的入口（萬達雖然精心設計了每一層的業態，然而大家現在都是循著手機指示直奔目標而去，繞過了實體世界的商場設計。阿里去年和萬達一起推出的喵街試圖為線下的店鋪分佈畫一張地圖，讓使用者按圖索驥。然而使用者既然可以在點評美團上按照自己的需求對商家排序，篩選，為什麼還要按照你的地圖來呢？）而小程式這種必須通過掃一掃來實現線上、線下一一對映的入口，就顯得像是倒退了。

隨著“點外賣”成為年輕人的一種生活方式，連低端餐飲業都已經被“電商化”了。使用者就像在淘寶上買衣服一樣瀏覽附近店鋪的菜食，不存在掃一掃點餐、掃一掃取號、掃一掃付款這樣的小程式使用場景。而對於自帶流量的高階餐飲業來說，與服務號相比，小程式並沒有提供更多的價值。

這種需要“眼睛看到實物”甚至用手機掃一掃的應用場景侷限太大了：如果我身在臥室卻想關掉客廳的燈呢？Google Glass這種模擬人的視覺的“掃描式互動”的問題也在於：實體世界與虛擬世界要通過掃描一一對應，自由的虛擬世界反而要受限於限制重重的實體世界，效率太低了。

實際上，智慧家居早就提供了更加方便的操作體驗。手機與家用電器之間一次連線，然後隨時遠端控制，還可以設定IFTTT協同控制。如果你覺得用手機調節燈光亮度太麻煩，Amazon、Google、Facebook都推出了智慧語音助理。

而最有可能快速普及的小程式應用場景——掃一掃騎走單車，也並非完美無缺。用摩拜掃一掃騎車和用微信小程式掃一掃哪個更方便？首次騎車當然是無需下載App的小程式更方便。然而，掃一掃並不是解鎖的終極形態，摩拜的解鎖會不斷進化到NFC解鎖，甚至距離感應自動解鎖。

二維碼是技術領域“worse is better”的典型例證。掃一掃支付的大獲全勝給了張小龍充分的信心，拿著錘子滿世界找釘子。

正如很多人已經指出的，二維碼之所以戰勝了NFC，就是因為其零布設成本，上至五星級酒店，下至烤紅薯攤販，都可以快速接入微信支付體系，從而線上下消費中幾乎無所不在。然而支付這種通用型場景的全民普及並不代表“worse is better”會在其他場景中一再發生。

正是因為支付這種通用型場景“普及度大於一切”，所以二維碼才勝出。而對於其他情況各異的場景，完全可能有更加適合的解決方案。比如，迪斯尼樂園使用的是自己研發的魔法手環，和信用卡繫結，入園、排隊、消費、小費，只需要滴一下就可以了。

小程式的未來將會何如發展，在這個瞬息萬變的網際網路時代，誰也說不準。

如果你依然在程式設計的世界裡迷茫，不知道自己的未來規劃，可以加入web前端學習交流群：731771211 裡面可以與大神一起交流並走出迷茫。小白可進群免費領取學習資料，看看前輩們是如何在程式設計的世界裡傲然前行！群裡不停更新最新的教程和學習方法（進群送web前端系統學習路線，詳細的前端專案實戰教學視訊），有想學習web前端的，或是轉行，或是大學生，還有工作中想提升自己能力的，正在學習的小夥伴歡迎加入學習。

點選：加入