体融合价值评估体系的建立不是简单地对转型过程中的各种尝试进行对或不对的评判，而是通过各种维度来衡量媒体融合的进程。其核心是围绕传播力、影响力、引导力、公信力以及变现能力等建立评价体系，从而实现融合过程中的纠错功能。媒体融合的价值评估体系必须在坚持“三个价值”统一的基础上，量化互联网运用指数，并建立退出机制，实现传播业态的供给侧改革。

媒体融合 评估体系 主流价值观

从“你中有我，我中有你”,到“你就是我，我就是你”，从“ 互联网”到“互联网 ”。以2014年8月18日习近平总书记在中央全面深化改革领导小组第四次会议上的重要讲话为起点，媒体融合在国内已有四年的探索与实践。这4年，媒体融合基本完成了从理论认知到全面实证的过程，中央厨房和移动优先战略成为一种共识，不管是报业领域还是广电传媒，在融合的探索与实践中均有不菲的业绩出现。各具特色的融合模式令人耳目一新，呈现出色彩斑斓的缤纷世界。但繁华的背后亦不乏深深的忧虑。评判媒体融合的实际效果需要建构一套“价值评估体系”，从顶层设计入手，以量化指标来分析和甄别媒体融合的实证效应。

媒介与传播形态的演变

什么是媒体？这问题有点老套，但必须得重新探究。

媒体(Media)一词来源于拉丁语“Medius”，音译为媒介，意为两者之间。媒体是指传播信息的媒介。它是指人借助用来传递信息与获取信息的工具、渠道、载体、中介物或技术手段。美国传播学者威尔伯·施拉姆在《传播学概论》一书中说：“媒介就是传播过程中，用以扩大并延伸信息传送的工具”。①

其实从理论上来说，媒体和媒介还是有区别的：媒介是信息传播所需要的载体、介质或通道。媒体是媒介 内容体系的组合，拥有后端内容架构、生产流程、编读互动等系统支撑。也就是说媒体应该是借助媒介对内容进行传播的一种组织架构。

加拿大传播学者马歇尔·麦克卢汉在《理解媒介》一书中认为，“媒介即讯息”。他说：“任何媒介对个人和社会的任何影响，都是由于新的尺度产生的。”②麦克卢汉把媒介的研究方向做了新的解构，他提出了研究媒介应该从研究内容的传播效果反转到对媒介的传播工具的研究。《特伦斯·戈登序》中说：“麦克卢汉对传播媒介的理解是，媒介是人体和心灵的技术延伸，任何技术、一切技术都是媒介。”③

1440年，古腾堡的印刷机带来了报纸的诞生。之后广播来了，电视出现了。再之后互联网问世了，智能手机(移动终端)诞生了。直至今天，微信、微博被广泛地使用。当人们很娴熟地按照各自的喜好选择不同的媒介来获取和传播信息，也印证了麦克卢汉所说的：“技术创造新环境，新环境引起痛苦，人体的神经系统就‘关闭’和‘截除’。”④但人们“关闭”和“截除”的是某些不需要的传播渠道，并不是“关闭”和“截除”媒介存在的形态。

从这一理论出发，我们应该很好理解当今各种媒介形态存在和人们选择媒介形态的合理性。技术推进媒体形态的发展，而这发展和变化是永恒的，或许未来会有更多新的媒介形态出现。而使用哪种媒介形态仍然取决于科技进步给传播带来的便利性。

这就是媒介与传播生态。从媒介诞生之日起，媒介就在不断地分化，从单一到多元，从供应到共建。

媒体为什么要“融合”

“媒体融合”(media convergence)，最早由尼古拉斯·尼葛洛庞蒂提出。美国马萨诸塞州理工大学教授浦尔认为媒介融合是指各种媒介呈现多功能一体化的趋势。

媒体融合是传统媒体自我“救赎”的手段，是由下往上行的被动的过程。媒体融合是传统媒体面对因技术演变带来的媒介生态变化，通过与技术的嫁接，打通传统媒体和以互联网技术为核心的新媒体之间的壁垒，借助技术手段改变传统媒体单一的点对面的传播形态，从而去拉动那些已“关闭”和“截除”传统媒体的人，让他们在传统媒体设置的新的传输平台上，获取需要的内容，最终在新的媒介形态上让用户回归“传统”的方式。这里所说的“传统”是传统的品牌，而不是传统的表现方式。当好酒遇到了“巷子深”的问题，唯一的出路就是走出去，融入到大的集市中。

中宣部媒体融合专家组成员、中国人民大学教授、媒体融合实验室总干事宋建武认为，新闻媒体的融合发展之路其实是传统媒体的互联网 改造之路。国家行政学院高级经济师、媒体融合专家郭全中说：“媒体融合的核心问题就在于重建用户连接，必须以用户为中心，破解观念、技术、机制、资金等方面的难题，在创新中赢得未来。”⑤原南方报业掌门人，现暨南大学新闻学院院长范以锦先生说：“随着内容创业热潮的兴起，媒体人更加重视内容的打造。此外，如何将媒体内容打造的品牌价值延伸到新的领域？如何通过新媒体连接产业，找到新的商业模式？已成为各大媒体机构关注并积极探索的问题。”⑥

梳理三位专家的观点，我们可以给媒体融合整理出这样一个逻辑思路：媒体融合必须要有互联网思维，通过互联网 改造传统；媒体融合要破解观念、技术、机制、资金等方面的难题；媒体融合最终的目的是通过内容建设形成的品牌价值来连接平台和用户，拓展新的产业，在其基础上找到新的商业模式。

媒体融合的实证效果

4年的探索与实践，不管是理论的认知还是融合的实践都取得了不菲的成绩。从认知上来看，以下三个方面应该是共识：理清了一个思路——媒体融合是传统媒体互联网化的过程；认清了一个方向——媒体融合的路径必须是技术迭代、用户体验和大数据营销；完成了 互联网的过程——“93%的报纸创办了自有APP，99%的报纸内容入驻各类聚合类客户端。”⑦

从实践上来看，不管是报业还是广电，都形成了具有鲜明特色的融合模式：

报纸系统大致形成了四种融合模式：人民日报完成了从中央厨房到全国党媒信息公共平台的搭建。全国党媒信息公共平台,旨在构建起面向全国党媒的内容共享、技术共享、渠道共享、人才共享、盈利模式紧密协作的公共平台,努力打造党媒与全行业融合；中国青年报全力打造了“融媒小厨”，并以培训的方式作了有效的推广；浙江日报实现了“传媒控制资本，资本壮大传媒”；上海的东方早报成功转型“澎湃新闻”。

广电系统则形成了另一类的四种模式：央视——用户广泛管理模式——通过新闻移动网建立了媒体入驻模式，通过多渠道分发，依靠多样化的内容与产品，覆盖最广泛的用户。现有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。