❶ 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 采訪時透露：未來，騰訊設計雲將繼續在設計資產、設計協作效率發力，針對圖標庫、設計資產開源平台以及智能設計工具進行迭代升級。目前，騰訊設計雲已經初步完成平台建設階段，後續騰訊設計雲將逐步向內容建設方面進階。
我們也堅信，今後騰訊設計雲在實現高效設計、輕松協同目標的過程中，也將邁出更加堅實的一步。
❽ 銀行前端開發怎麼樣
銀行前端開發非常好。
通過前端系統整合，建立銀行的統- -櫃面平台，逐步將現有系統的前端採用嵌入或者翻寫的方式進行整合，對於新建系統，其前端均在櫃面平台上統一開發；
通過前端系統整合，同時實現櫃員的統-管理和櫃員的單點登錄以及操作界面的圖形化。前端系統整合應考慮能夠滿足未來業務處理中心的要求。
綜合前端系統平 台功能齊全：提供應用服務平台、櫃員管理平台、運維管理平台、二次開發平台等。綜合前端系統平 台使用便捷:集成開發環境的可視化、配置化、組件化。綜合前端系統平台有完善的質量管理體系：良好的版本管理體系，清晰有效的二次開發規范。綜合前端系統平 台提供部署和管理工具，提供可視化的維護工具。影像處理:新系統支持影像掃描、上傳、存儲、檢索及下載等功能。