媒體融合應建立符合主流價值觀的評估體系

體融合價值評估體系的建立不是簡單地對轉型過程中的各種嘗試進行對或不對的評判，而是通過各種維度來衡量媒體融合的進程。其核心是圍繞傳播力、影響力、引導力、公信力以及變現能力等建立評價體系，從而實現融合過程中的糾錯功能。媒體融合的價值評估體系必須在堅持“三個價值”統一的基礎上，量化互聯網運用指數，并建立退出機制，實現傳播業態的供給側改革。

媒體融合評估體系主流價值觀

從“你中有我，我中有你”,到“你就是我，我就是你”，從“ 互聯網”到“互聯網 ”。以2014年8月18日習近平總書記在中央全面深化改革領導小組第四次會議上的重要講話為起點，媒體融合在國內已有四年的探索與實踐。這4年，媒體融合基本完成了從理論認知到全面實證的過程，中央廚房和移動優先戰略成為一種共識，不管是報業領域還是廣電傳媒，在融合的探索與實踐中均有不菲的業績出現。各具特色的融合模式令人耳目一新，呈現出色彩斑斕的繽紛世界。但繁華的背后亦不乏深深的憂慮。評判媒體融合的實際效果需要建構一套“價值評估體系”，從頂層設計入手，以量化指標來分析和甄別媒體融合的實證效應。

媒介與傳播形態的演變

什么是媒體？這問題有點老套，但必須得重新探究。

媒體(Media)一詞來源于拉丁語“Medius”，音譯為媒介，意為兩者之間。媒體是指傳播信息的媒介。它是指人借助用來傳遞信息與獲取信息的工具、渠道、載體、中介物或技術手段。美國傳播學者威爾伯·施拉姆在《傳播學概論》一書中說：“媒介就是傳播過程中，用以擴大并延伸信息傳送的工具”。①

其實從理論上來說，媒體和媒介還是有區別的：媒介是信息傳播所需要的載體、介質或通道。媒體是媒介內容體系的組合，擁有后端內容架構、生產流程、編讀互動等系統支撐。也就是說媒體應該是借助媒介對內容進行傳播的一種組織架構。

加拿大傳播學者馬歇爾·麥克盧漢在《理解媒介》一書中認為，“媒介即訊息”。他說：“任何媒介對個人和社會的任何影響，都是由于新的尺度產生的。”②麥克盧漢把媒介的研究方向做了新的解構，他提出了研究媒介應該從研究內容的傳播效果反轉到對媒介的傳播工具的研究。《特倫斯·戈登序》中說：“麥克盧漢對傳播媒介的理解是，媒介是人體和心靈的技術延伸，任何技術、一切技術都是媒介?！雹?/p>

1440年，古騰堡的印刷機帶來了報紙的誕生。之后廣播來了，電視出現了。再之后互聯網問世了，智能手機(移動終端)誕生了。直至今天，微信、微博被廣泛地使用。當人們很嫻熟地按照各自的喜好選擇不同的媒介來獲取和傳播信息，也印證了麥克盧漢所說的：“技術創造新環境，新環境引起痛苦，人體的神經系統就‘關閉’和‘截除’?！雹艿藗儭瓣P閉”和“截除”的是某些不需要的傳播渠道，并不是“關閉”和“截除”媒介存在的形態。

從這一理論出發，我們應該很好理解當今各種媒介形態存在和人們選擇媒介形態的合理性。技術推進媒體形態的發展，而這發展和變化是永恒的，或許未來會有更多新的媒介形態出現。而使用哪種媒介形態仍然取決于科技進步給傳播帶來的便利性。

這就是媒介與傳播生態。從媒介誕生之日起，媒介就在不斷地分化，從單一到多元，從供應到共建。

媒體為什么要“融合”

“媒體融合”(media convergence)，最早由尼古拉斯·尼葛洛龐蒂提出。美國馬薩諸塞州理工大學教授浦爾認為媒介融合是指各種媒介呈現多功能一體化的趨勢。

媒體融合是傳統媒體自我“救贖”的手段，是由下往上行的被動的過程。媒體融合是傳統媒體面對因技術演變帶來的媒介生態變化，通過與技術的嫁接，打通傳統媒體和以互聯網技術為核心的新媒體之間的壁壘，借助技術手段改變傳統媒體單一的點對面的傳播形態，從而去拉動那些已“關閉”和“截除”傳統媒體的人，讓他們在傳統媒體設置的新的傳輸平臺上，獲取需要的內容，最終在新的媒介形態上讓用戶回歸“傳統”的方式。這里所說的“傳統”是傳統的品牌，而不是傳統的表現方式。當好酒遇到了“巷子深”的問題，唯一的出路就是走出去，融入到大的集市中。

中宣部媒體融合專家組成員、中國人民大學教授、媒體融合實驗室總干事宋建武認為，新聞媒體的融合發展之路其實是傳統媒體的互聯網改造之路。國家行政學院高級經濟師、媒體融合專家郭全中說：“媒體融合的核心問題就在于重建用戶連接，必須以用戶為中心，破解觀念、技術、機制、資金等方面的難題，在創新中贏得未來?！雹菰戏綀髽I掌門人，現暨南大學新聞學院院長范以錦先生說：“隨著內容創業熱潮的興起，媒體人更加重視內容的打造。此外，如何將媒體內容打造的品牌價值延伸到新的領域？如何通過新媒體連接產業，找到新的商業模式？已成為各大媒體機構關注并積極探索的問題?！雹?/p>

梳理三位專家的觀點，我們可以給媒體融合整理出這樣一個邏輯思路：媒體融合必須要有互聯網思維，通過互聯網改造傳統；媒體融合要破解觀念、技術、機制、資金等方面的難題；媒體融合最終的目的是通過內容建設形成的品牌價值來連接平臺和用戶，拓展新的產業，在其基礎上找到新的商業模式。

媒體融合的實證效果

4年的探索與實踐，不管是理論的認知還是融合的實踐都取得了不菲的成績。從認知上來看，以下三個方面應該是共識：理清了一個思路——媒體融合是傳統媒體互聯網化的過程；認清了一個方向——媒體融合的路徑必須是技術迭代、用戶體驗和大數據營銷；完成了互聯網的過程——“93%的報紙創辦了自有APP，99%的報紙內容入駐各類聚合類客戶端?！雹?/p>

從實踐上來看，不管是報業還是廣電，都形成了具有鮮明特色的融合模式：

報紙系統大致形成了四種融合模式：人民日報完成了從中央廚房到全國黨媒信息公共平臺的搭建。全國黨媒信息公共平臺,旨在構建起面向全國黨媒的內容共享、技術共享、渠道共享、人才共享、盈利模式緊密協作的公共平臺,努力打造黨媒與全行業融合；中國青年報全力打造了“融媒小廚”，并以培訓的方式作了有效的推廣；浙江日報實現了“傳媒控制資本，資本壯大傳媒”；上海的東方早報成功轉型“澎湃新聞”。

廣電系統則形成了另一類的四種模式：央視——用戶廣泛管理模式——通過新聞移動網建立了媒體入駐模式，通過多渠道分發，依靠多樣化的內容與產品，覆蓋最廣泛的用戶。現有140多家矩陣號入駐，每天發稿首發量達1100條；南方財經全媒體集團——縱向垂直模式打通產業鏈的縱向垂直模式，圍繞產業上下游資源，幫助用戶提供決策路徑。實現媒體數據交易(由“兩報兩臺三刊三網兩微一端”13個媒體集群組成)；芒果TV——特定用戶群模式，通過芒果直播戰略，依靠湖南衛視內容優勢，逐漸建立了特定用戶群的模式。這一模式強調以內容為核心，圍繞內容打造可以利用的渠道，形成針對用戶群的影響力；蘇州廣播電視臺——區域用戶群模式，將用戶限定在一定的區域內，利用自己的內容，整合服務行業的內容，覆蓋、滿足區域市場用戶的不同需求，做區域媒體的主流平臺。

盡管當前的媒體融合已呈現出繽紛多彩的景象，但似乎并沒有感受到融合帶來的踏實感。原因一是沒有找到替代傳統的盈利模式；二是缺乏量化的標準體系。

當前媒體融合的窘境

窘境一：如何實現“互聯網 ”

所謂的“ 互聯網”是指傳統業務通過互聯網來提升業務發展?！?互聯網”強調“順勢而為”。其看重的是存量優勢、行業標準優勢和公信力優勢。按照這個邏輯，傳統媒體在“ 互聯網”方面成效顯著。

“互聯網 ”是指基于互聯網平臺之上的融合。它更多強調“逆襲創新”，是以新技術為先發優勢，帶動體制機制的創新來實現爆發性增長。

媒體融合其核心是“互聯網 ”，但為什么媒體融合在“互聯網 ”這個階段無法邁步？

哈佛大學商學院教授克里斯坦森在其《創新者的窘境》一書中闡述了這一觀點：越是大的公司，越是優秀的公司，越容易在技術革新中失敗。原因就在于思維方式和管理模式的固化。他們很難接受新生的事物。這也就是當前媒體融合過程中，我們只學到了表象而無法更深層面推進的原因。⑧

窘境二：技術是核心還是手段

媒體融合的核心是強化互聯網思維。強化互聯網思維有兩個重要節點，一是在指導思想和思維方式上接受互聯網點面融合的特點，也就是線上與線下鏈接功能；二是要充分運用網絡技術手段去改造傳統媒體。從這一理論出發就必須將互聯網技術作為融合的核心，通過技術來實現信息的傳播與認知、交流以及用戶參與三者的融合。但遺憾的是，到目前為止，傳統媒體的互聯網改造進程并沒有按照這一邏輯去實施，更多還是停留在的方式，這就出現了“兩微一端”我也有，網站我也有，但支撐其運營的技術參數和系統是分割的，數據是孤立的。用戶數是各平臺統計數的疊加，看似數據量很大，但是不相融。

窘境三：“內容為王”還是“渠道為王”

這是近些年在媒體融合進程中爭議最大的問題。傳統媒體力挺“內容為王”這一說法，而互聯網媒體強調渠道優先。其實這兩者之間，是相互支撐、相互作用的。再好的內容，如果沒有平臺支撐，其內容是無法實現傳播效果的；而平臺再好，如果沒有內容供應，亦無法產生影響力。

在媒體的內部，內容與渠道的融合路徑應該是：通過營銷推廣等手段吸引人們訪問自己的網站或數字終端；就用戶感興趣的內容吸引他們駐留；以優質的內容良好的用戶體驗贏取他們再次訪問的機會；在美譽度的基礎上讓他們在朋友圈中分享這些內容。

但在媒體融合過程中，傳統媒體的優勢不僅僅是提供內容那么簡單。它的核心競爭力應該是新聞專業主義精神。所謂新聞專業主義精神，強調傳媒作為一個獨立的社會子系統的收集、整理、傳播信息的功能和責任。在此基礎上，它還包括一套關于新聞媒介社會功能的信念，一系列規范新聞工作的職業倫理，一種服從政治和經濟權力之外的更高權威的精神和一種服務公眾的自覺態度。這種原則著眼于受眾的知情權和接近權，以“公平、公正、公開”為目標取向，強調社會責任意識。而現在很多媒體為了“10萬 ”而丟棄了我們應該固守的傳統。

窘境四：接受“算法”還是排斥“算法”

算法是什么？算法是計算機在擁有海量數據的前提下，根據用戶體驗的習慣，將其偏好記錄下來，再從數據庫中找出與其偏好配對的內容進行推送，達到點對點的傳播效果。

由于算法是以機器代替人工，缺乏內容的審核與把關，帶來了一定的負面效應。傳統媒體在互聯網化的過程中對“算法”過于謹慎，過于放大其負面影響，主動放棄了對用戶需求的了解，無法滿足用戶差異化、個性化的需求。

如何正視這一問題？復旦大學新聞學院教授周葆華認為:“算法已經成為當下傳播生態由于供給和需求變化帶來的必然趨勢，我們已經沒有辦法回到一個逃避算法的時代。我們今天應該重視算法，同時又不應該過分放大算法的作用。”⑨他認為，算法一方面使整個傳播行業在供給和需求兩方面發生重大變化，讓媒體跟用戶發生緊密聯系；另一方面，也跟“移動優先”戰略有關，當下，受眾永遠在線的時間使用生態需要大量的內容匹配。

如何構建媒體融合的價值評估體系

媒體融合是個試錯的過程。當前媒體融合是通過使用任意或所有的傳播工具，按照用戶期望的時間、地點和方式提供新聞，旨在滿足受眾的期望。因此在媒體融合過程中，媒體機構使用哪一種工具最有效，哪一種組合形式最直觀、最容易被用戶所接受也就是媒體融合試錯的過程。盡管現在媒體融合呈現出比較好的發展態勢，但由于缺乏一套行之有效的評價體系來評判和規范融合的效果，融合進展緩慢且成本增加。

媒體融合價值評估體系的建立不是簡單地對轉型過程中的各種嘗試進行對或不對的評判，而是通過各種維度來衡量媒體融合的進程。其核心是圍繞傳播力、影響力、引導力、公信力以及變現能力等作為評價體系。從而實現融合過程中的糾錯功能。

媒體融合的價值評估體系必須在堅持“三個價值”統一的基礎上，量化互聯網運用指數，同時應建立媒體融合的退出機制，實現傳播業態的供給側改革。

政治價值。習總書記關于新聞輿論的重要論述是新時代中國特色社會主義思想的重要組成部分，要圍繞總書記對新聞輿論指導思想的“新定位、新表述、新論斷、新擘畫、新部署、新闡述、新要求”的重要論述來開展新聞宣傳與信息傳播。當前傳播生態已經發生了革命性的變化，融合的要件就是要在真正落實“互聯網 ”的基礎上，打造具有生命力和競爭實力的傳播共享平臺，通過連接聚集數據，通過數據交互，完善用戶體驗。各媒體單位要利用一切先進的技術，通過有效的手段建立各主流媒體間的信息共享機制，在此基礎上建立適應現代傳播規律的政治語境。要通過議程設置，掌握有效的話語權，用議題來引導受眾，用公信力來影響用戶。

社會價值。社會主義核心價值體系是對人類未來社會價值訴求的基本看法和總體要求,是幾千年來人類所追求的社會價值理想的一種延續,是對一種更人道、更平等、更自由的合理社會的理想價值訴求,它是社會主義制度的內在精神和生命之魂,決定社會主義社會發展模式、制度體制和目標任務。

在媒體融合過程當中，主流媒體的社會價值不容忽視。為了10萬，沒有真相、沒有信源的新聞充斥在主流媒體的新媒體傳播渠道。如果這種行為不斷出現，恰恰把主流媒體最核心的公信力丟失了。因此，以社會價值為取向的價值評估體系顯得極為重要。要圍繞社會主義核心價值來構建媒體融合的評價評估體系，重振新聞專業主義精神，建立媒體融合考核的負面清單。

市場價值。媒體融合不能只計投入而不考慮產出。要深刻領會習近平總書記講話精神，推動傳統媒體和新興媒體融合發展，要遵循新聞傳播規律和新興媒體發展規律，強化互聯網思維，堅持傳統媒體和新興媒體優勢互補、一體發展，堅持先進技術為支撐、內容建設為根本，推動傳統媒體和新興媒體在內容、渠道、平臺、經營、管理等方面的深度融合，著力打造一批形態多樣、手段先進、具有競爭力的新型主流媒體，建成幾家擁有強大實力和傳播力、公信力、影響力的新型媒體集團，形成立體多樣、融合發展的現代傳播體系。要一手抓融合，一手抓管理，確保融合發展沿著正確方向推進。

媒體融合要在體制和機制上有所突破、有所創新。要真正理解和運用互聯網思維，通過新技術平臺與新的產業進行有效鏈接，實現媒體融合下的盈利模式創新。

量化互聯網運用指數。媒體融合的核心就是互聯網化。量化互聯網運用指數，不應僅重視數字的堆砌，更應該從以下幾個指標來衡量：跨界融合；創新驅動；品牌重塑；用戶體驗；開放生態；連接一切。

建立退出機制。媒體退出是指媒體機構停止運行或媒體原有形態終結等。有創辦就必有退出。人類傳播史就是在媒體創辦與退出、生與死的交替中不斷演進和發展的。因此，退出和“生”是同等程度的概念。長期以來，我國媒體單位只有準入而沒有退出。近些年，各地均有媒體關閉，但基本上屬于被動退出，并不是依據產能效能來倒逼。建立媒體融合退出機制，有利于媒體在供給側改革的驅動下，完善存量結構的調整。

(作者系溫州商學院傳媒與設計藝術學院院長、教授)

注釋：

①威爾伯·施拉姆：《傳播學概論》，新華出版社1984年版，第23頁。

②③④馬歇爾·麥克盧漢《理解媒介——論人的延伸》，譯林出版社，第19頁、第5頁、第3～4頁。

⑤郭全中：《媒體融合要善用智能傳播平臺》，

http://media.people.com.cn/n1/2016/0422/c40606-28295564.html。

⑥《范以錦、宋建武、沈浩、郭全中談2016媒體融合》，http://www.cssn.cn/bk/bkpd_qkyw/bkpd_rdwz/201612/t20161229_3363130.shtml。

⑦陳國權：《2017中國報業發展報告》，《編輯之友》2018年第2期。

⑧參見克萊頓·克里斯坦森：《創新者的窘境》，中信出版社2010年版。

⑨《編輯后撤、算法當道媒體如何提供內容競爭力？》，

http://media.people.com.cn/n1/2017/0821/c14677-29484390.html

. 背景介紹

1.1. 業務介紹

A平臺與B平臺同屬于同一系統鏈路上，前者主要致力于為用戶提供注冊入駐服務，后者則專注于提供具體業務操作服務。兩者皆為運營人員所依賴的在線管理工具。

1.2. 現狀分析

目前這兩個平臺服務于同一業務方，且B應用的頁面已經100%嵌入到了A應用的平臺上，除此以外目前存在系統上及體驗上的痛點如下：

所以當時我們考慮既然服務于同一業務方是否能在代碼層面上將兩個平臺進行融合，通過系統的融合來達到優化用戶體驗以及降本增效的效果呢？

2.成果展示

平臺融合后，主要的優化點體現在以下四方面：

優化前（跳轉單個頁面白屏時間達2998ms左右）：

優化后（跳轉單個頁面白屏時間800ms左右）：

3. 具體措施

3.1. 方案調研

3.1.1. 部署方式

?部署優化：A應用前后端合部署，現計劃分離前端獨立部署；

?資源節約：經行云部署平臺調研，擬采用混合部署策略，將A應用與B應用前端靜態資源集中部署于一組容器，以優化資源利用；

3.1.2. 代碼倉庫整合

?A應用的三個項目與后端共享一個代碼倉庫，采用統一的編碼標準；而B應用則使用獨立的代碼倉庫，需從中分離出前端代碼，并確保分離過程不影響現有配置；

3.1.3. 項目框架

?4個項目的技術選型框架都為vue2，依賴項略有不同；

3.1.3. 系統權限

?A應用和B應用為erp登錄；

3.2. 架構設計

為了讓用戶融合無體驗差別，兩個平臺的用戶繼續使用各自的域名進行訪問，融合后的項目可以自動識別當前環境，加載對應的內容；保證融合前后用戶查看的內容是一致的；

3.3. 具體方案

3.3.1. 目錄結構設計

針對融合，我們首先考慮的是融合后如何防止文件沖突，減少融合的復雜度，降低出問題的概率。保證兩個系統能正常運行；拆分邏輯分以下三個方面：

1.文件拆分與分類

兩個系統涉及到幾十個文件，經過分析，我們將其拆分成以下幾部分內容：【頁面文件、公共組件文件、mock文件、AxPI接口文件、基礎請求封裝文件、路由組件文件、Store文件、公共樣式文件、公共方法組件、mainjs文件、index.html文件】

2. 結構整合與差異化處理

由于兩個項目的結構相似，我們可以針對各個部分進行整合。整體的思路是，對于差異比較大的文件，建立兩個獨立的文件夾，分別包含系統A和系統B的內容；然后通過一個index文件，識別到當前的運行環境是系統A還是系統B，再分別加載對應的內容；

3. 內容融合與沖突解決

針對差異比較小或者無差異的文件，我們將文件內容進行融合。對于沖突的內容，我們進行了手動修改，并對全局引用部分進行同步修改；

├── root
│   ├── mocks
│   ├── public
│   ├── src
│   │   ├── api
│   │   │   ├── apiA      // 存儲 A 業務請求接口
│   │   │   ├── apiB       // 存儲 B 業務請求接口
│   │   │   ├── apiC         // 存儲 C 業務請求接口
│   │   │   ├── baseHttp.js   // 封裝基礎請求
│   │   │   ├── ARequest.js   // A業務的公共處理，請求header和響應code碼等處理
│   │   │   ├── BRequest.js  //  B業務的公共處理，請求header和響應code碼等處理
│   │   │   ├── CRequest.js   // C業務的公共處理，請求header和響應code碼等處理
│   │   │   ├── DRequest.js  //  D業務的公共處理，請求header和響應code碼等處理
│   │   ├── assets
│   │   │   ├── icons     // icon內容
│   │   ├── common
│   │   │   ├── config
│   │   │   ├── styles      // 一些公共的樣式
│   │   ├── components      // 公共組件
│   │   ├── directive       // 自定義指令
│   │   ├── layout        //公共布局
│   │   ├── router
│   │   │   ├── a.js   // 對應a應用
│   │   │   ├── b.js   // 對應b應用
│   │   │   ├── c.js   // 對應c應用
│   │   │   ├── index.js
│   │   ├── store
│   │   │   ├── modules
│   │   │   ├── getters.js
│   │   │   ├── index.js
│   │   ├── utils   
│   │   ├── views
│   │   │   ├── a    // a 業務文件
│   │   │   ├── b    // b 業務文件
│   │   │   ├── c    // c 業務文件
│   │   ├── main.js
│   │   └── App.vue
│   ├── env
│   ├── package.json

3.3.2. 應用類型判斷

應用類型判斷是我們重要的一環，是我們識別環境的基礎，當用戶通過不同的域名訪問到應用的時候，前端維護一個映射表，不同的域名代表不同的應用；在main.js文件中會在第一時間執行判斷識別；

let APPLICATION_TYPE = 'a'
let host = window.location.host;

// 維護域名列表，包含測試和線上環境
const A_HOST = ['a.com','a_pre.com']
const B_HOST = [] 
const C_HOST = []
const D_HOST = []

if(A_HOST.includes(host)){
    APPLICATION_TYPE = 'a'
}else if(B_HOST.includes(host)){
    APPLICATION_TYPE = 'b'
}else if(C_HOST.includes(host)){
    APPLICATION_TYPE = 'c'
}else if(D_HOST.includes(host)){
    APPLICATION_TYPE = 'd'
}
// 掛載全局
window._APPLICATION_TYPE = APPLICATION_TYPE

3.3.3. 路由設計

根據不同的域名獲取路由配置，根據路由配置生成路由；系統A和系統B各自維護一個路由列表；當從后端請求回來路由結構之后，根據不同的應用映射不同的文件內容；其中路由path保持不變，compoent增加前綴（應用類別）找到對應的應用下的組件；

?第一步：前端獲取當前域名，確認當前應用

根據全局的 APPLICATION_TYPE 字段識別

?第二步：前端維護一個路由列表

let router=[
{
    path: '/home',
    component: Layout,
    meta: {  title: '首頁', icon: 'el-icon-s-grid', alwaysShow: true },
    redirect: '/home',
    children: [
      {
        path: '/home',
        component: () => import('@/views/home/index'),
        name: 'home',
        meta: { title: '首頁', icon: ''}
      }
    ]
  }
]

?第三步：根據當前應用請求后端接口，獲取路由配置信息（component的路徑前拼接各個應用的文件名）

let RouterApi={'a':'/api1','b':'/api2','c':'api3'}
api.get(RouterApi[APPLICATION_TYPE])
component='各個應用文件名'+接口返回路徑

?第四步：針對在路由信息放置在前端的應用，前端維護一個路由的配置信息表

import dRouter from './d.json'
if(APPLICATION_TYPE==='d'){
   router=dRouter
}

?第五步：根據路由配置信息，生成路由結構

?第六步：實例化Vue對象

3.3.4. 環境變量設計

環境主要分為以下幾種：mock環境、本地開發環境、測試環境、線上環境

不同的環境對應不同的變量文件，在變量文件中設置每個端需要用到的參數，結合 APPLICATION_TYPE 和變量文件的配置，獲取到對應的參數

示例：

# .env.pruduction

# a 業務
VUE_APP_A_BASEURL = ''   
# b 業務
VUE_APP_B_BASEURL = ''
# c 業務
VUE_APP_C_BASEURL = ''
# d業務
VUE_APP_D_BASEURL = ''

3.3.5. 請求設計

1.公共請求的封裝

封裝基礎的公共請求createHttp.js，各業務基于公共的請求和各自的code碼，請求參數等信息進行再次封裝，然后可以按照業務需求調用；

?基礎請求：createHttp.js

?業務公共封裝：

a. ARequest.js（A業務公共參數和code碼處理）

b. BRequest.js （B業務公共參數和code碼處理）

c. CRequest.js（C業務公共參數和code碼處理）

d. DRequest.js（D業務公共參數和code碼處理）

?業務層調用：

a. api/apiA A業務接口

b. api/apiB B業務接口

c. api/apiC C業務接口

// 公共請求封裝  baseHttp.js
export const createHttp = (baseUrl, successFun = () => {}, errorFun = () => {}, requestInterceptor = () => {}) => {
  const http = axios.create({
    baseURL: baseUrl,
    timeout: 5 * 60 * 1000,
    withCredentials: true
  })
  // http request 攔截器
  http.interceptors.request.use(
    async config => {
      await requestInterceptor(config)
      return config
    },
    err => {
      return Promise.reject(err)
    }
  )
  // http response 攔截器
  http.interceptors.response.use(successFun, errorFun)
  return http
}

2. 直接調用后端服務請求封裝

//A業務基礎請求 
function requestInterceptor(){
    // A系統公共請求參數處理... 
}
function successFn(){
    // A系統公共響應結果處理 統一新增
}
function errorFn(){
    // A共異常處理 包括code碼等情況
}
export default createHttp(baseUrl,successFn,errorFn,requestinterceptor)

3. 業務接口使用，根據不同的業務劃分不同的目錄分支

// A業務請求調用
ARequest.get(url,{params:data})

//B業務請求調用
BRequest.post(url,{params:data})

3.3.6. 權限和登錄

根據應用類型字段APPLICATION_TYPE，識別不同的環境，請求不同的服務端接口；不同的服務端代表了不同的應用；

針對不同的應用的未登錄情況，前端維護多套登錄處理邏輯，根據應用類型進行不同的處理邏輯；

3.3.7. 公共函數設計

創建一個公共的utils文件夾，針對兩個項目中的公共函數進行合并，針對有沖突的函數，進行命名修改，全局引入的部分進行路徑和函數的同步修改；

3.3.8. 腳手架配置設計

梳理了兩個項目的腳手架配置差異項及各個配置的作用，對配置作了部分的修改和優化，在滿足原有的功能情況下不影響正常的項目運行；

3.3.9. Vuex store設計

store的整體結構保持不變，在項目引用的地址也保持不變，由于項目中使用store的地方較多，保持結構不變能保證改動成本最小，針對兩個項目中模塊名重復的情況，手動把模塊里的內容進行合并；

針對現有的名稱重復內容不一樣的函數，根據應用類型字段 APPLICATION_TYPE 把兩個函數進行融合進行分別處理；

3.3.10. 頁面引用設計

?引用方式變更

由于業務需求，應用A中嵌套了應用B的頁面，之前通過iframe引用。融合后，頁面文件和組件不再隔離，可以直接引入應用B的文件和組件；

?后端數據打通

應用A的后端服務器上有一些功能，如下載列表，應用B項目需要使用時因數據不通難以直接引用。前端融合后，可以在應用B中直接引用應用A的頁面組件，實現業務的順暢使用。效果如下：

4. 總結

在經歷了為期兩個月的緊張工作后，我們成功地將兩個大型項目進行了深度整合，取得了顯著的階段性成果。通過這一融合過程，我們不僅統一了項目的代碼規范和架構，還顯著提升了組件的復用率。盡管在這個過程中我們遇到了諸多挑戰和曲折，但最終的成果——用戶體驗的顯著提升——使一切努力都顯得彌足珍貴。

我們深知，每一個成功的項目背后都有無數次的嘗試和優化。在這個過程中，我們不斷學習、適應和完善，最終實現了項目的無縫融合。我們相信，這段經歷和我們所取得的成果，不僅為我們團隊帶來了寶貴的經驗和教訓，也可能為那些正在經歷類似挑戰的同學提供了一些啟示和幫助。

作者：京東零售高雅薇

來源：京東云開發者社區

tml+css基礎一：html簡介和發展史

HTML全稱（hypertext markup language）譯為超文本標記語言，其譯文代表了HTML的含義，它和其他編程語言不同的是，HTML不是一門真正意義上編程語言，而是一種標記語言，通過帶有尖角號的標簽對文本進行標記，從而實現網頁的結構搭建。

1.2、HTML發展史

HTML創始人（蒂姆·伯納斯-李）蒂姆·伯納斯-李除了是HTML的創始人，還是w3c組織的主席。

1、HTML1.0 （1991年12月）

1991年萬維網（www）在互聯網上首次露面，也隨之引起了巨大的轟動。

1989年，伯納斯-李寫了一份備忘錄，提出建立一個基于互聯網的超文本系統。同年和另外一個工程師一起進行聯合資金申請，但是這個項目并沒有通過。

1991年底的時候，伯納斯-李公開了一份“HTML Tag”的文檔，里面描述了組成HTML初始版本的18個元素

2、HTML2.0（1995年11月）

HTML 2.0是HTML語言的擴展。????

與原始版本的HTML不同，HTML 2.0被創建為Web標準，規定了常見的網頁結構

3、HTML3.2（1996年1月）

慘淡的"第一次瀏覽器大戰時期（Netspace Vs IE）"，兩大巨頭不斷推出重大舉措試圖控制整個領域。???????

網頁開發者是這場戰爭中的焦點。商業戰爭就像軍備競賽，各家公司為了保持領先，招兵買馬。各家都有各家的規則。?????????

那時候，你不得不寫兩份不同的網頁，一個用于網景的瀏覽器，另一個用于微軟的瀏覽器

4、HTML4（1997年12月）

瀏覽器大戰接近尾聲，W3C（世界萬維網聯盟）成立，他們打算通過制定統一的HTML標準，使整個產業能有序的發展。 ? ? ? ? ? ?

他們計劃用兩種語言分離出HTML的表達式（HTML 4.0）和結構（CSS），并且說服瀏覽器廠商接受這些標準

這次發布提供了規范的三種變體：

Strict，嚴格版本；

Transitional，過渡版本；

Frameset，iframe框架集；

HTML4.0 采納了許多瀏覽器特定的元素類型及屬性，但是同時也把 Netscape 的視覺化標記標記為過時的尋求淘汰; 贊成使用樣式表; 同時在1998年4月對HTML4.0進行了微小的修訂，沒有增加版本號HTML5.0

5、HTML4.01（1999年12月）

像 HTML4.0 一樣提供了三種變體，并且他的最終錯誤修訂版在2001年的5月12日發布

6、XHTML 1.0（2000年1月）

各大瀏覽器廠商紛紛接受W3C標準的時候，新技術出現了。?????????????

HTML和另一種語言XML融合，XHTML（可拓展的超文本標記語言）就此誕生。???????????

它繼承了HTML的通用型和瀏覽器的兼容性，繼承了XML的嚴密性和可拓展性

7、HTML5（2014 年 10 月）

HTML5是HTML最新的修訂版本，由W3C制定，目標是取代1999年所制定的HTML 4.01和XHTML 1.0標準

我們現在使用的是html5版本，因為由于新興框架的出現和瀏覽器兼容性的提升，讓我們選擇了html5。

在線咨詢

上一篇：寫個網頁更簡單了！讓AI根據手繪原型生成HTML - 教程+代碼
下一篇：CSS3 - 新單位vw、vh、vmin、vmax使用詳解（附樣例）

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商