❶ nginx前端常用配置
nginx现在几乎是众多大型网站的必用技术，大多数情况下，我们不需要亲自去配置它，但是了解它在应用程序中所担任的角色，以及如何解决这些问题是非常必要的。
下面我将从nginx在企业中的真实应用来解释nginx在应用程序中起到的作用。
为了便于理解，首先先来了解一下一些基础知识， nginx是一个高性能的反向代理服务器 那么什么是反向代理呢？
代理 是在服务器和客户端之间假设的一层服务器， 代理 将接收客户端的请求并将它转发给服务器，然后将服务端的响应转发给客户端。
不管是正向代理还是反向代理，实现的都是上面的功能。
正向代理 是为我们服务的，即为客户端服务的，客户端可以根据正向代理访问到它本身无法访问到的服务器资源。
正向代理 对我们是透明的，对服务端是非透明的，即服务端并不知道自己收到的是来自代理的访问还是来自真实客户端的访问。
反向代理 是为服务端服务的，反向代理可以帮助服务器接收来自客户端的请求，帮助服务器做请求转发，负载均衡等。
反向代理 对服务端是透明的，对我们是非透明的，即我们并不知道自己访问的是代理服务器，而服务器知道反向代理在为他服务。
下面是一个nginx配置文件的基本结构：
下面是 nginx 一些配置中常用的内置全局变量，你可以在配置的任何位置使用它们。
| 变量名 | 功能 | | ------ | ------ | | $host | 请求信息中的 Host ，如果请求中没有 Host 行，则等于设置的服务器名 | | $request_method | 客户端请求类型，如 GET 、 POST | $remote_addr | 客户端的 IP 地址 | | $args | 请求中的参数 | | $content_length | 请求头中的 Content-length 字段 | | $http_user_agent | 客户端agent信息 | | $http_cookie | 客户端cookie信息 | | $remote_addr | 客户端的IP地址 | | $remote_port | 客户端的端口 | | $server_protocol | 请求使用的协议，如 HTTP/1.0 、·HTTP/1.1 | | server_name | 服务器名称| | $server_port`|服务器的端口号|
先追本溯源以下，跨域究竟是怎么回事。
同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。通常不允许不同源间的读操作。
如果两个页面的协议，端口（如果有指定）和域名都相同，则两个页面具有相同的源。
例如：
现在我在 fe.server.com 对 dev.server.com 发起请求一定会出现跨域。
现在我们只需要启动一个nginx服务器，将 server_name 设置为 fe.server.com ,然后设置相应的location以拦截前端需要跨域的请求，最后将请求代理回 dev.server.com 。如下面的配置：
这样可以完美绕过浏览器的同源策略： fe.server.com 访问 nginx 的 fe.server.com 属于同源访问，而 nginx 对服务端转发的请求不会触发浏览器的同源策略。
根据状态码过滤
根据URL名称过滤，精准匹配URL，不匹配的URL全部重定向到主页。
根据请求类型过滤。
GZIP 是规定的三种标准HTTP压缩格式之一。目前绝大多数的网站都在使用 GZIP 传输 HTML 、 CSS 、 JavaScript 等资源文件。
对于文本文件， GZip 的效果非常明显，开启后传输所需流量大约会降至 1/4 ~ 1/3 。
并不是每个浏览器都支持 gzip 的，如何知道客户端是否支持 gzip 呢，请求头中的 Accept-Encoding 来标识对压缩的支持。
启用 gzip 同时需要客户端和服务端的支持，如果客户端支持 gzip 的解析，那么只要服务端能够返回 gzip 的文件就可以启用 gzip 了,我们可以通过 nginx 的配置来让服务端支持 gzip 。下面的 respone 中 content-encoding:gzip ，指服务端开启了 gzip 的压缩方式。
这里为什么默认版本不是 1.0 呢？
HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性。
启用持久连接情况下，服务器发出响应后让 TCP 连接继续打开着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。
为了尽可能的提高 HTTP 性能，使用持久连接就显得尤为重要了。
HTTP/1.1 默认支持 TCP 持久连接， HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。对于 TCP 持久连接上的 HTTP 报文，客户端需要一种机制来准确判断结束位置，而在 HTTP/1.0 中，这种机制只有 Content-Length 。而在 HTTP/1.1 中新增的 Transfer-Encoding: chunked 所对应的分块传输机制可以完美解决这类问题。
nginx 同样有着配置 chunked的 属性 chunked_transfer_encoding ，这个属性是默认开启的。
Nginx 在启用了 GZip 的情况下，不会等文件 GZip 完成再返回响应，而是边压缩边响应，这样可以显着提高 TTFB ( Time To First Byte ，首字节时间，WEB 性能优化重要指标)。这样唯一的问题是， Nginx 开始返回响应时，它无法知道将要传输的文件最终有多大，也就是无法给出 Content-Length 这个响应头部。
所以，在 HTTP1.0 中如果利用 Nginx 启用了 GZip ，是无法获得 Content-Length 的，这导致HTTP1.0中开启持久链接和使用 GZip 只能二选一，所以在这里 gzip_http_version 默认设置为 1.1 。
如上面的图，前面是众多的服务窗口，下面有很多用户需要服务，我们需要一个工具或策略来帮助我们将如此多的用户分配到每个窗口，来达到资源的充分利用以及更少的排队时间。
把前面的服务窗口想象成我们的后端服务器，而后面终端的人则是无数个客户端正在发起请求。负载均衡就是用来帮助我们将众多的客户端请求合理的分配到各个服务器，以达到服务端资源的充分利用和更少的请求时间。
Upstream指定后端服务器地址列表
在server中拦截响应请求，并将请求转发到Upstream中配置的服务器列表。
上面的配置只是指定了nginx需要转发的服务端列表，并没有指定分配策略。
轮询策略
默认情况下采用的策略，将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的，但是如果其中某一台服务器压力太大，出现延迟，会影响所有分配在这台服务器下的用户。
最小连接数策略
将请求优先分配给压力较小的服务器，它可以平衡每个队列的长度，并避免向压力大的服务器添加更多的请求。
最快响应时间策略
依赖于NGINX Plus，优先分配给响应时间最短的服务器。
客户端ip绑定
来自同一个ip的请求永远只分配一台服务器，有效解决了动态网页存在的session共享问题。
匹配以 png|gif|jpg|jpeg 为结尾的请求，并将请求转发到本地路径， root 中指定的路径即nginx本地路径。同时也可以进行一些缓存的设置。
nginx的功能非常强大，还有很多需要探索，上面的一些配置都是公司配置的真实应用（精简过了），如果您有什么意见或者建议，欢迎在下方留言...
❷ 前端开发怎么做
Web前端开发是从网页制作演变而来的，名称上有很明显的时代特征。在互联网的演化进程中，网页制作是Web1.0时代的产物，那时网站的主要内容都是静态的，用户使用网站的行为也以浏览为主。2005年以后，互联网进入Web2.0时代，各种类似桌面软件的Web应用大量涌现，网站的前端由此发生了翻天覆地的变化。网页不再只是承载单一的文字和图片，各种富媒体让网页的内容更加生动，网页上软件化的交互形式为用户提供了更好的使用体验，这些都是基于前端技术实现的。 以前会Photoshop和Dreamweaver就可以制作网页，现在只掌握这些已经远远不够了。无论是开发难度上，还是开发方式上，现在的网页制作都更接近传统的网站后台开发，所以现在不再叫网页制作，而是叫Web前端开发。Web前端开发在产品开发环节中的作用变得越来越重要，而且需要专业的前端工程师才能做好，这方面的专业人才近几年来备受青睐。Web前端开发是一项很特殊的工作，涵盖的知识面非常广，既有具体的技术，又有抽象的理念。简单地说，它的主要职能就是把网站的界面更好地呈现给用户。
❸ 如何搭建web前端框架
搭建web前端框架步骤如下：
1、确定项目使用的技术
根据项目的需求等来选择使用的技术（这里以angular4 + typsescript + nodejs+mongodb举例）
2、新建一个项目的工作文件夹
使用npm init初始化项目，根据问题配置，一般是直接回车使用默认配置,生成package.json文件
3、新建一个index.html页面
4、新建配置文件system.config.js
5、新建ts的配置文件tsconfig.json
npm install typescript
6、新建webApp目录，这里面放的是所有html页面和js代码，首先得有个入口文件，与system.config.js配置文件中的入口文件名一样，app.mole.ts，里面引入了所有js文件，不被引入的在加载时都不会被加载
7、打包(将代码压缩，使程序运行速度更快）
❹ 关于B端系统的产品设计
过去的一年，负责的业务主要聚焦于平台运营，随着业务模式的成熟，也负责建设了许多营销系统。
本文将以此前实际设计的案例与大家分享 关于B端 系统的产品设计。
关于系统，个人认为是将 无序、散乱的业务抽象成中心化、标准化的有序服务。 而中台则在系统之上再上升一层，将 系统的共性抽象成通用服务。
而中心化和标准化的动机又是什么呢？较高频的动机有三条：
1） 业务模式足够成熟
2） 高频需求重复占用资源，且不具备复用性。
3） 旧有系统耦合性强，延展性弱。
在企业的早期阶段，一些非高频的共性需求并没有可依赖的中台系统。为了迅速上线及满足业务的需求，大多会将其耦合于该系统之中。
但当其他系统有相同需求时无法复用，需要额外开发相同的逻辑。不仅重复消耗资源，后续的迭代难度也会不断提升。
通过需求分析所确定的产品定位，能够明确系统要解决的 核心问题 是什么。而梳理业务流程，则作用在 问题解决的深度。
理解业务流程目的是梳理系统架构，从而划分系统的边界。边界清晰能够让系统各司其职，专注于自身的功能，并尽量提供可复用的能力。
以抽奖系统为例，输出其系统架构：
对于抽奖系统而言，它应该专注于抽奖的规则，如：抽奖次数来源、中奖概率、限中次数等等。
对于抽出的奖品是什么，奖品怎么发放，应该由奖品管理、奖品发放系统去消化；而奖品发放所触发的触达则应该交由触达系统。
什么时候应该将非核心需求抽象成中台系统，什么时候又应该耦合呢？个人认为应从其需求频次、强度以及投入产出比考虑。
在梳理了新系统与现有系统的耦合关系后，下一步则是确认中心化的对象，中心化的方式不同，其核心逻辑、功能框架也会不同。
以奖品管理系统为例，其中心化的方案可以有两种，如下图所示：
方案1以奖品作为中心，一个奖品将能够被多个业务方所使用。因其层级较少，产品、技术设计会更为简单，后续业务方的操作也更为轻便；
而方案2以奖品池作为中心，每个奖池的奖品相互独立，虽然方案更为复杂，但优势是其数据相互独立，更有利于成本核算以及风控。
当中心化的方案确定，系统的的核心逻辑及数据模型也就初见雏形了。
梳理功能框架相信大家都非常熟悉，本小节主要描述最小单元。 最小单元，指无法继续拆解的功能，其通用性的强弱也决定着系统的延展性 。
以下将以前端配置化系统为例和朋友们分享，以下的示例分别是最基础设计方式，以及有赞和笔者的设计方式：
1）固定组件、固定配置
第一种做法，是最基础的做法。它的思路是对固定的组件进行固定的配置。
以抽奖活动为例：
上图的两种抽奖玩法对应着两种前端样式，左侧是九宫格，右侧是老虎机。这两种样式对应着头图、抽奖模块、我的奖品及活动规则四个组件。
根据它们组件的共性，我们能抽象的最小单元是页面头图、页面底色、活动规则、抽奖按钮的颜色、文字等内容。
由于共性不足，它们的最小单元已经无法延伸。当后续增加新的模板“大转盘”时，我们就需要再次抽象并迭代，这种设计方案是非常不灵活的，而且最小单元很可能会再次减少。
最小单元共性越少，延展性越差，后续开发的工作量越多。
从九宫格的“我的奖品”、老虎机的“活动规则”来看，它们属于各自的私有属性，原则上而言我们也能够设计成配置项，但从投入产出比、延展性来看显得不太划算。
2）有赞：多种组件、独立配置
有赞的设计思路也是比较常见的设计思路，它的每个组件拥有独立的配置项。
上图分别是有赞中拼团、砍价组件对应的配置项，在图片的红框部分是商品模块的配置，同样是自动获取商品类型，拼团组件的配置项比砍价多了一个排序规则。
这种设计方式的优点是该组件能够很轻易的适配业务方的需求，灵活性能够达到最高。缺点则是组件的特性没有办法复用，某个商品模块或按钮的特性是无法复用到其他组件的商品模块或组件之中。
结合了上述的两种设计思路，根据实际业务方的诉求，笔者设计的思路为：多种组件、共用配置。
3）多种组件、共用配置
这种方式的设计思路是： 组件由模板与元素组成，模板决定元素的位置，元素负责视觉及交互的配置。
元素指的是： 文字、图片、线条 ，它们是本系统的最小单元。
其拆解示例如下图：
商品组件由图片、文字符素及按钮组件组成，而按钮组件由线条元素及文字符素组成。
关于元素的拆解思路如下图：
通过这样的解构，元素的交叉组合能够形成不同样式的组件。
当业务方有新的特性需求，只需要迭代元素的属性， 一次迭代所有的组件都能够使用这个特性， 即避免重复开发也保证了其复用性。产品、研发及测试的工作量的也大大减少。
除了视觉配置，另一部分则是交互的配置，其拆解如下：
最小单元在实际的设计过程中，还应权衡投入产出比， 不应为了解构而解构。
数据统计，有两点建议：定义清晰、数据独立。后者与系统架构有关，由于系统之间的相互依赖，会有关联的数据需要查询。
个人的经验是让系统尽量只消化系统本身的数据，对于关联的数据可以查询数据源让核心系统做整合，最粗糙的设计方式则是直接跳转至关联的系统查询。
1）角色与权限设计
根据组织架构以及权责范围，系统的使用角色所对应的权限也不同，常见的权限有增、删、改、查以及审批流。
2）版本计划
版本的计划。可以是对完整系统的分版本上线，也可以是对业务的预估推测系统后续需要延展的功能，这会非常影响系统的技术设计方案。
3）交互设计及文档撰写
随着业务认知的提升、技能的熟练，产品设计的能力可能会达到瓶颈 。 近期的想法是，面向价值设置需求优先级，不仅是企业、业务，还有支撑部门和自己。
以前喜欢做有难度的需求，但难度却不代表价值，我想好的产品设计一定能 帮助业务方带来可视、可观的数据成果。
给多方创造价值，才能够自上而下的推动跨部门协作，持续获得资源以及成长。
❺ 前端环境的安装与配置
前端环境的安装与配置？一、工具安装
1.编辑器
2.Git(分布式的代码管理工具)
3.Photoshop
4.Nodejs链接
二、 环境配置
1.配置git：
1.1 设置Git的user name和email：
$ git config --global user.name "name"
$ git config --global user.email "[email protected]"
1.2 生成SSH密钥过程：(看需求配置)
$ ssh-keygen -t rsa -C "[email protected]"
3个回车，密码为空。
Your identification has been saved in /home/tekkub/.ssh/id_rsa.
Your public key has been saved in /home/tekkub/.ssh/id_rsa.pub.
The key fingerprint is:
………………
最后得到了两个文件：id_rsa和id_rsa.pub
添加密钥到ssh：
登陆gitlab, Profile Settings -> SSH Keys -> ADD SSH KEYS ,找到本地的id_rsa.pub文件，复制出里面的内容，添加到 key 内，此时 Title 会自动填上你的邮箱，没有的话手动填写, ADD KEY
1.3 拉取代码到本地(权限)
创建一个存放项目的文件夹，在该文件夹下，单击右键，选择git bash,打开git命令框，编写命令：git clone [email protected]:xx/xx.git（可以在gitlab项目中找到存放地址，gitlab地址：http://gitlab.vchangyi.com ），按回车，就可以从gitlab上clone代码到本地文件夹
1.4 手动安装nodejs，如果是pc端安装的话，nodejs版本不能过低。
安装最新版的话npm安装项目依赖会有问题，手机端gulp无法启动，所以建议安装nodejs V6。
1.5 测试node是否安装成功
在git 命令窗或者node 命令窗中输入命令 ：node -v
1.6 同理，测试npm是否安装成功npm -v
1.7安装gulp
在项目下打开git 命令窗，从淘宝源上自行安装，这个时间需要等待和耐心，也会有网络原因导致安装失败，如果安装失败可以多来几次，直到成功为止。
如果是pc端：npm install --registry=http://registry.npm.taobao.org --phantomjs_cdnurl=http://cnpmjs.org/downloads
npm 安装时候 持久使用淘宝源 设置:
npm config set registry https://registry.npm.taobao.org
配置后可通过下面方式来验证是否成功
npm config get registry
或
npm info express
❻ 前端分辨率适配
现在手机屏大小不一，而且屏幕硬件性能也各不相同，一般的UI设计都是基于特定机型画设计搞件的，常见的是基于iPhone6的分辨率设计2倍图，以iPhone6为例，屏幕物理像素宽度是750，网页宽度为375PX。开发中还要根据不同手机留出设计余量，因为不同分辨率的手机显示时会有拉伸位移。
网上也有一些方案，处理高清屏适配方案，但一般也只把DPR适配到2，彩用所有长度单位放大2位，网页整体缩放50%的的做法，比如ant-mobile就支持这种方式，它可以定义一个less常量“@hd”来定义CSS中使用的基础单位大小，但是这种方式在遇到网页实际宽度大于375的设备时，还是不能1：1的还源UI设计稿。
我个人在项目中采用的是更复杂的实现方式，可以实现适配DPR大于2的手机屏，并接近100%的还源UI设计稿。具体的适配技术各家大同小异，这里不再细说，我只给出我自己的适配方案。
同大多数适配方法一样，通过 rem 设计一个基础的大小单位 ，做为整个页面的基础单位，再根据屏幕物理DPR结合屏宽计算这个单位的大小，
基础单位 = 屏幕DPR * 网页宽度 / 375（设计稿基准为375）
网页缩放值 = 1 / 屏幕DPR
比如我的方案是把rem设为10px 再乘以“基础单位”，这样在设置一个设计稿上14号字的时候，就写 1.4rem就可以了。另外编写页面布局时，也用这个计算出来的相对单位，这样可以做到不管什么样的屏幕，UI设计搞都不会因宽度变化而变形。另外，如果使用ant-mobile这样的支持高清方案的UI中间件，直接在配置中把它的LESS常量 “@hd”设置 为 “0.1rem”就可以了。
另外还有一个小的福利，就是在这个方案下，当你想画出“1物理像素”的细边框时，直接用 “1px”，就可以了，因为在这个方案下，1px对应的是一个物理像素。
下面给出我实践中使用的适配代码：(这是直接放在HTML文件中的版本）
//计算屏幕比例并设置html的font-size
/**
将html字号设置为10个设计像素（一个基准系数，即rem为10 设计稿像素）
设计一个缩放系数，以应对可能出现的适配高清屏要求
*/
( function () {
/**初始化方法
* _standard 设计稿对应的分辨率
* base_DPR 设定最小DPR值
*/
function setInitialRem( _standard, base_DPR) {
//取得当前设备DPR
var dpr = window. devicePixelRatio || 1;
//如果设定了默认最小DPR值
if ( base_DPR) {
dpr = dpr >= base_DPR ? dpr : base_DPR;
}
//设定缩放视图比例
var scale = 1 / dpr;
//设直视图缩放比例
document. head. querySelector( 'meta[name="viewport"]'). content = "width=device-width,initial-scale=" + scale + ",minimum-scale=" + scale + ",maximum-scale=" + scale + ",user-scalable=no, shrink-to-fit=no";
//取得当前设备宽度
var device_width = document. documentElement. clientWidth; //window.innerWidth;
//标定原稿设计基准值 当前稿件设计宽度为 iPhone6/6s 375像素
var standard_width = _standard * dpr;
//设定基准单位
var base_value = 10;
//基准系数=设备宽度➗稿件基准宽度✖️设备DPR✖️10
var rem = device_width / standard_width * dpr * base_value;
//设置 REM
document. documentElement. style. fontSize = rem + "px";
}
window. addEventListener( "resize", function () { setInitialRem( 375, 1); });
setInitialRem( 375, 1);
})();
❼ 前端基础设施怎么搞看腾讯TDesign跨技术栈组件库的最佳实践
在 6 月 28 日的首届 Techo Day 腾讯技术开放日上，腾讯发布了一系列“轻量级”产品，将腾讯多年自研产品的底层能力释放给了开发者。
正如腾讯云高级副总裁 & CTO 王慧星，在前不久的腾讯 TDesign 技术生态日提到的那样：“自腾讯确立了开源协同，自研上云的技术战略，成立了十大技术领域委员会，推出了众多 PaaS 能力，并将这样的能力放在云上，实现对内部和外部用户的统一服务。”
而腾讯设计云旗下的企业级产品设计体系腾讯 TDesign 正是这样一款产品，其也在首届 Techo Day 腾讯技术开放日活动中，发布了新的产品动态。据了解，目前腾讯 TDesign 的大部分组件已经完成了内测版本的发布， Vue 2、Vue 3、React 和移动端 Vue 3 也已经发布了公测版本和候选版本。与此同时，Augular、Flutter 、taro 等热门技术栈也在开发的行列当中。
如果要回溯腾讯自研 UI 组件库的缘由，这或许要先了解下前端领域的发展史。
纵览底层的前端框架领域，先是经历了 JQuery 一统江湖的时代，而后过渡到了 MVVM 框架成为主流的时期。目前，Vue、React 以及 Angular 则成为了前端开发人员使用最多、最广的底层框架。可以看出，业界并没有完全占据主导地位的前端开发框架，这也就导致前端技术团队在迭代技术栈时，往往存在较大的切换成本，跨团队共享前端资产时也会遇到技术栈差异的壁垒。
此外，由于组件库和团队技术栈存在一定耦合性的关系，对于很多企业中后台系统这样的弱设计风格场景，我们可以根据整个栈的风格，大致推测出这个项目使用了哪种组件库。例如，前端团队选择了 React 开发框架，大概率会用 AntD 组件库；使用 Vue 开发框架，则大概率会直接用 iview-admin 页面模板。这样一来，技术栈的差异不仅会导致整个组件库的选型受到一定限制，还会让对外曝露的产品体验存在较大的偏差。
因此，在产品体验、开发效率与设计效率等因素的驱动下，腾讯通过开源协同的方式，与多个业务团队共建了企业级设计体系腾讯 TDesign ，通过提供复用性的设计体系，为设计研发各个流程环节提供需要的设计和研发等解决方案。
在代码组件库中，腾讯 TDesign 基于业界实际的使用需求，已经覆盖了 Vue、Vue Next、React 等主流的前端开发框架，目的在于让公司内外部使用的同学都可以根据自身实际需求，选择对应的组件库产品，不再受技术选型的限制。当项目同时有桌面端和移动端使用需求的时候，腾讯 TDesign 还可以统一产品在两端上的业务体验。
从另一个角度来看，如果没有统一的 UI 组件体系，UI 设计师的工作效率同样是大打折扣的。在“腾讯前端通用 UI 组件库技术生态日”活动中， 腾讯用户研究与体验设计部总经理陈妍说道：“如果没有腾讯 TDesign 这样的 UI 组件库，设计师是最大的受害者，因为我桥核孝们的工作需要不断的重复，没有办法把时间节省下来做更加有价值的事情。”
基于设计敏稿师的痛点，腾讯 TDesign 目前也提供了 Figma、Sketch、Axure 等设计资源以及 Sketch 设计插件，让设计和代码能够无缝衔接，使设计资源分配到必要的环节。
既然腾讯 TDesign 选择了支持各种技术栈的原生开发，就不可避免地会遇到几类问题。例如，UI 组件库怎么保证与技术栈产物一致性？交互和 UI 实现怎么保持一致？组件 API 怎么保持一致？官网体验与用户氏并的实际使用如何保持一致？
据腾讯 TDesign 团队透露，虽然业界基于上述挑战已经有几种不同实现的方式，但其各有优劣：
一种方案是基于 Web Components 做一个组件，将其使用在各个框架当中，但 Web Components 方案的优势与具体实现框架没有太大关系，因为是由浏览器原生支持，其最大的问题还是浏览器的兼容性，部分浏览器可以通过 polyfill 解决，但是有些政企浏览器的兼容性依然是不可小觑的问题。
另一种方案是直接将一份 React 代码转成 Vue，这带来的好处是可以真正做到维护一份代码，同时支持多技术栈，但统一整个前端技术栈其实是比较大的课题，目前业界还没有统一的方案。另外，代码转换支持多技术栈的方案，其实在应用开发层会更常见，对于腾讯 TDesign 这种底层依赖而言，转化后代码的稳定性还是难以得到保障。
不仅于此，这种转化方案的中间层代码相当于是新的框架，既不是 Vue，也不是 React，对于贡献者来说门槛比较高，会进一步导致开源社区不够活跃，这同样是腾讯 TDesign 团队需要考虑的问题。
最终，腾讯 TDesign 团队决定选择用 Vue 开发 Vue 技术栈，React 开发 React 技术栈，除了 Angular、小程序等受技术栈限制，其他技术栈均统一用 Jsx 来维护组件实现，并主要解决了以下几个问题：
组件 API 保持一致
腾讯 TDesign 团队梳理出了开源项目前端组件上线的流程，在组件进入开发的前置阶段，设置了 API / 交互稿统一评审环节，邀请各技术栈的实现者、UI/ 交互设计师以及 PMC 成员同学一起针对组件 API 的易用性、灵活性以及必要性进行评审，充分的讨论过后，会将大家的意见形成整个组件的 API 描述，并录入腾讯 TDesign 的组件 API 管理平台。
最终，API 管理平台会生成各个技术栈的 API 文档、某个组件的 props.ts、typeb.ts 等文件。当组件开发者进行开发时，不需要对照文档做开发，直接根据已经生成的定义文件开发即可，做 API 开发同学提了 PR 做 review 时，有任何更改会同步到各个技术栈实现的仓库。
用户实际使用与官网体验保持一致
为了让用户的实际使用感受与官网体验保持一致，腾讯 TDesign 做了一层官网共同的架构，目前所有的组件文档包括文字部分，以及我们要展示的组件 Demo。各个端实现时，会各自引入一个 Web Components 实现官网的公共部分，通过统一的 Markdown 解析工具，最终解析出来的栈点就会完全一样。
各个技术栈产物的 UI 和交互保持一致
除了要保证组件 API 一致，还要保证各个技术栈的产物里 UI 和交互都要完全一样，这里 TDesign 做了两件事情：第一，以 TDesign Token 贯穿设计开发流程，从最初设计师提供的设计稿，到组件库里代码的实现变量，一直到最终组件库里面 NPM 包产物，每个变量都有一一对应的关系；第二，抽取一个独立的仓库，将每个组件都独立维护在 TDesign-common 仓库，通过 Submole 的方式引入到实现仓库里。当 UI 需要调整的时候，直接在独立的库里修改，再同步到各个技术栈实现的仓库，最终保证整个 UI 和交互在各个技术栈上面实现完全一样。
部分组件代码复用
除了 UI 相关实现代码做到了各技术栈复用，腾讯 TDesign 也参考了业界类似组件库产品的实践， 探索 了一些代码逻辑复用的方案：一些与技术栈无关的组件抽象类，也抽取到了 TDesign-common 仓库中；合理分层组件实现，通过 Hooks 和 Composition API 来跨技术栈复用部分代码实现。
据了解，当前腾讯 TDesign 在内外部已经有了比较广泛的应用基础，腾讯内部在积极推动各个业务统一到 TDesign，也支持了多个领域和行业外部项目落地，并从中孵化出了多个行业组件库。这些组件库也将在未来逐步开源，持续支持各行业领域的系统建设。
而当我们开始回溯腾讯 TDesign 自开源以来的历程，可以发现其取得的成绩已经可圈可点：在开源社区的建设方面，腾讯 TDesign 仍然秉持着为社区贡献价值的初心，不断向有活力、高质量的开源社区进阶。据统计，上半年 TDesign 共有 280+ 贡献者，其中外部 17 ，核 贡献者 47 ，GitHub star 4k+。
展望未来，腾讯 TDesign 还将继续围绕着两个既定目标迈进：
第一，让更多人使用腾讯 TDesign。后续组件库各技术栈将发布 Stable 版本，并针对移动端开展专项优化，以确保提升组件质量和用户使用体验。为了最大化提升设计师的工作效率，还将提供 模板、移动端 Figma UIKit Variant（设计可配置能 ）等设计资源，并建设物料市场，承载更多的 业组件和模板资源。除此之外，TDesign 还计划支持国际化以及无障碍适老化的适配；
第二，建设更有活 、更 质量的开源社区。为了帮助更多从业者了解企业级设计体系 腾讯 TDesign，社区后续计划沉淀、总结设计体系和组件库专业 章 / 课程。另外，为了吸引更多外部开发者加 贡献，透明化内外部协作进度，开源社区将优化开发者的招募和激励机制。
谈及未来的发展规划，腾讯 TDesign 团队在接受 InfoQ 采访时表示，未来除了会支持现有的前端技术栈，还将协同社区的力量推出 Web components、Flutter 等更多技术栈产品，服务于公司内外使用者。同时，也期待更进一步复用跨框架实现的代码，在降低维护成本的同时，不显着额外提升参与贡献的门槛。
作为腾讯设计云的关键产品，腾讯 TDesign 的诞生便是为了让 UI 组件库摆脱技术选型的影响，让其回归到前端基础设施的地位上来。事实证明，在一步步的迭代与优化之下，腾讯 TDesign 已经逐步地将开源协同能力渗透给了更多企业。
与此同时， 腾讯用户研究与体验设计部总经理陈妍还在接受 InfoQ 采访时透露：未来，腾讯设计云将继续在设计资产、设计协作效率发力，针对图标库、设计资产开源平台以及智能设计工具进行迭代升级。目前，腾讯设计云已经初步完成平台建设阶段，后续腾讯设计云将逐步向内容建设方面进阶。
我们也坚信，今后腾讯设计云在实现高效设计、轻松协同目标的过程中，也将迈出更加坚实的一步。
❽ 银行前端开发怎么样
银行前端开发非常好。
通过前端系统整合，建立银行的统- -柜面平台，逐步将现有系统的前端采用嵌入或者翻写的方式进行整合，对于新建系统，其前端均在柜面平台上统一开发；
通过前端系统整合，同时实现柜员的统-管理和柜员的单点登录以及操作界面的图形化。前端系统整合应考虑能够满足未来业务处理中心的要求。
综合前端系统平 台功能齐全：提供应用服务平台、柜员管理平台、运维管理平台、二次开发平台等。综合前端系统平 台使用便捷:集成开发环境的可视化、配置化、组件化。综合前端系统平台有完善的质量管理体系：良好的版本管理体系，清晰有效的二次开发规范。综合前端系统平 台提供部署和管理工具，提供可视化的维护工具。影像处理:新系统支持影像扫描、上传、存储、检索及下载等功能。