簡介
　　詳情頁也叫做單品頁，域名以「item.jd.com/skuid.html」為格式的頁面。是負責展示京東商品SKU的落地頁面。主要任務是展示商品相關信息，如價格、促銷、庫存、推薦，從而引導用戶進入購買流程。同時單品頁有很多版本。一般分為兩類。一類我們通常看到的「通用類目詳情頁」——所有類目都可以使用，一類是不經常看到的「垂直屬性詳情頁」——一些有特殊屬性的商品集合
　　
　　首先，由于詳情頁量大（SKU數十億）、高并發（日PV數十億）等特性，在很長的一段時間里，單品頁都是后端程序生成靜態頁面使用CDN來解決量大、高并發的問題。
　　其次。單品頁涉及的「三方」系統特別多，比如促銷、庫存、合約、秒殺、預售、推薦、IM、店鋪、評價社區等。而單品頁的主要任務就是展示這些系統的信息，并且適當的處理他們之間的邏輯關系，而這些系統的接口一般都使用異步Ajax來完成，因為其一CDN無法做到頁面的動態化，其二一些系統的信息對實時性要求特別高（價格、秒殺），即使使用后端動態渲染也很難做到無緩存零延遲。
　　基于上面兩個原因，注定了單品頁是一種重多系統業務邏輯展示型頁面，重前端頁面。我大概匯總了一下頁面上異步接口，總共約有30個，頁首屏的接口特別重要，接口之間幾乎都有耦合關系：
　　
　　前端的發展歷程
　　混沌時期
　　混沌時期的單品頁并沒有前端開發的概念。核心的功能腳本只有三個：促銷價格（promotion.js）、庫存地區（iplocation.js）、其它邏輯（pshow.js）。這三個腳本分別是三個不同團隊的同事負責維護，當時我剛進入京東的時候在UED部門，負責頁面腳本整體的維護工作和pshow的開發。那時候我自己維護的pshow.js腳本壓縮后只有80kb，所有的代碼都是過程式的，沒有任何使用模式和代碼技巧，JS最多也只被用來做個判斷渲染DOM。那時候的前端工作內容只在UI層面，寫樣式和一些交互腳本。
　　這個階段給我最深刻的感覺是單品頁后端模板很少維護（后端架構是最老的aspx版本）。大多數的改動都要用Java去動態渲染。因為后端頁面是一個生成器生成的。如果頁面后端模板有改動那么就需要全量的生成一次，過程可能需要幾個小時。
　　初見端倪
　　當我接手這個項目時剛好有一次大改版，就在這時候老大說頁面上的腳本都要放在我們手里維護。然后就是一大波的重構、重寫。基本上pshow被重寫了大概80%其它的因為業務邏輯的問題并沒有完全重寫，只是做了些代碼層面的優化。
　　有一個模板引擎叫trimPath，知道這個的估計都算老前端了。最早的客戶端Java MVC模式代表作品，只到現在還在使用。這個階段像評價這種完全異步加載的模塊特別適合使用模板引擎來減少維護的工作量。這個時候雖然頁面上的代碼并不都是我們寫的，但基本上前端對頁面的Java有了控制權，接下來的事情就是尋找機會逐個優化。
　　這段時間是最痛苦的時候，維護的工作統一到前端。然后后端幾乎沒有變化，只是在一段時間將后臺的架構從aspx過渡到了java。本質上并沒有什么改變。前端卻做了比以前更多的事情，也是在這個時候我接手了大量的維護工作（包含全站公共庫的維護）使得我意識到了一些自動化、工程化方面的重要性，后文會主要講解，順便說下，那時候前端自動化工具Grunt剛面世，但是我自己卻用的是apache ant，不過不久就切換到了Grunt來構建項目。
　　撥云見日
　　單品頁不僅重系統邏輯，也重維護。在這段時間里一方面有正常的維護類需求要做，一方面自己也不斷的學習新知識為以后的改版做鋪墊。不過就在這時單品頁有歷史意義的一次技改出現了——單品頁動態化技改。關于后端部分的改造細節可以去億級商品詳情頁架構演進技術解密了解。
　　總的來說這次的改版后很多數據直接從后端讀取，不再從前端異步獲取而且我們也做過一些異步加載的優化，多接口combo從統一服務吐出給前端使用。這時前端就不用再為異步接口的加載時苦腦了，只需要專注系統接口的邏輯。
　　隨著這次技改，前端的代碼也迎來了模塊化的時代。我們把所有的前端代碼都進行了模塊化然后基于SeaJS重寫，配合Nginx concat功能實現了本地模塊化開發，線上服務端合并。