前端筆記（201902-201904）

一、響應式佈局

參考：https://www.ui.cn/detail/351448.html

　　簡而言之，就是一個網站可以兼容多個設備終端，它能夠自動識別設備尺寸並相應調整佈局，而不是爲每一個終端作一個特定的版本。隨着愈來愈多智能移動設備的誕生，小到智能手錶，大到4k顯示屏，「主流設備」的概念正在慢慢消失，就算是PC和MAC咱們也不能肯定用戶的瀏覽窗口有多大（有調研只有一半的用戶會全屏顯示瀏覽器），爲了給不一樣終端的用戶提供更加溫馨的界面和用戶體驗，響應式設計應時而生。

　　對頁面進行響應式設計，須要對相同的內容進行不一樣寬度的佈局設計。首先要根據目標用戶和使用環境等定位考慮側重的是桌面端仍是移動端：桌面優先（從桌面端開始向下設計）；移動優先（從移動端開始向上設計）。由於須要適應不一樣的尺寸，對樣式上有較大的侷限性，在各類因素的影響下讓頁面達不到最佳的效果，因此須要根據用戶羣和使用環境來考慮側重哪一種設備，儘可能爲最中心的用戶提供最優的體驗。不管基於哪一種方向開始設計，要適配全部的設備，頁面模塊不可避免的須要隨着設備尺寸作相應的改變。當頁面寬度發生變化，超過了制定範圍的臨界點，頁面樣式就會發生變化，這個範圍咱們叫作斷點區間。Bootstrap是全球最受歡迎的前端組件庫，用於開發響應式佈局、移動設備優先的 WEB 項目。

　　響應式佈局樣式常見的有5種：1.擠壓-拉伸、2.上下-左右、3.刪減-增長、4.變換位置、5.隱藏-展開

• 擠壓-拉伸：頁面中的內容隨着屏幕的變化拉伸擠壓，適用於文本內容、純色背景、按鈕、填選框等伸縮不會發生變形的元素。
• 上下-左右：模塊內容從左右排版變爲上下排版，兩欄、三欄變爲一欄，適用於表單表格、圖文列表、圖片列表、主內容+右側推薦等全部左右排版的組合。
• 刪減-增長：移動端不一樣於桌面端網頁，移動端可視區域小，並且使用環境可能在公交、地鐵等沒法專心操做的環境裏，因此應當刪減掉不重要的內容，保留主線任務內容，及足夠用戶分析判斷的內容便可。
• 變換位置：響應式不是簡單的等比縮放，要根據內容重要性在保證易用性基礎上靈活佈局。
• 隱藏-展開：移動端當內容過多時能夠選擇收起，以彈框或者單獨一個頁面顯示。適用於分類、導航等內容。

總結：

　　不少時候單一的佈局方式沒法達到最好的效果，須要根據實際的狀況，搭配靈活使用；適配移動端時，根據頁面的功能主次作減法，不要爲了保留全部內容讓頁面冗長，可讀性差，認知難度增大；移動端是沒有hover效果的，要考慮移動端的操做習慣（好比：桌面端hover內容就能出現的說明，移動端可能須要提醒+彈出，或者直接顯示出來）；設計稿上的字體與用戶實際看到的字體是有差異的，特別是適配移動端（使用電腦、電視與手機之間的距離不同、分辨率也不同，字體大小需求也會不同。好比雖然電視屏幕大，可是距離較遠，桌面端的字體大小在電視上可讀性會不好；電腦上最小的字體是12px，可是在移動端時12px很是小）。

　　不管從手機端開始設計，仍是電腦端，在作的過程當中，要考慮發生變化之後頁面總體的樣式。相同設備的交互邏輯保持統一，好比平板與手機（手勢操做），寬屏顯示器與lapto（鼠標操做、觸屏操做）。並且要考慮這兩種不一樣的使用環境以及移動端和pc端用戶的使用習慣。

 

二、圖片上傳（兼容ie8和ie9）

參考：https://www.jianshu.com/p/b2ab1eb2452e

https://developer.mozilla.org/zh-CN/docs/Web/API/FormData

1）若是不考慮ie9兼容性，能夠經過ajax和FormData上傳圖片。FormData 是 XMLHttpRequest Level 2 新增的接口，低於IE10 的IE瀏覽器不支持該接口，也不支持html5表單上傳控件Files API（e.target.files爲undefined）。

 2）爲了兼容低於IE10 的IE瀏覽器，可經過form表單形式實現圖片上傳。

<form id="file-form" method="post" action="xxx" enctype="multipart/form-data">
<label class="upload-select">
    <i class="add-icon"></i>
    <p class="upload-text">點擊添加圖片</p>
    <input type="file" accept=".jpg, .gif, .png" class="input-file" name="Filedata">
</label>
</form>

表單中enctype="multipart/form-data"的意思，是設置表單的MIME編碼。默認狀況，這個編碼格式是application/x-www-form-urlencoded，不能用於文件上傳；只有使用了multipart/form- data，才能完整的傳遞文件數據。

enctype 屬性規定在發送到服務器以前應該如何對錶單數據進行編碼。

$('.input-file').change(function() {
    $('#file-form').submit(); // 觸發提交表單 submit 事件
});
$('#file-form').submit(function() { // 將函數綁定到 submit 事件
    $('#file-form').ajaxSubmit(function(data) { 
    });
    return false; // 阻止頁面跳轉
});

ajaxSubmit方法是jQuery的一個插件jquery.form.js裏面的方法，因此使用此方法須要先引入這個插件，它是一個form插件，支持ajax表單提交和ajax文件上傳。一般狀況下，咱們直接經過form提交的話， 提交後當前頁面跳轉到form的action所指向的頁面。然而，不少時候咱們比不但願提交表單後頁面跳轉，那麼，咱們就可使用ajaxSubmit來提交數據。

此時，若是服務器返回的是json對象，在ie8和ie9下並不能拿到服務器返回的數據，而是直接提示下載或打開（圖片上傳成功），以下圖所示

 

解決方案：服務端返回json字符串，前臺轉成json對象，而後進行接下來的處理，展現上傳的圖片等。

$('#file-form').submit(function() {
    $(this).ajaxSubmit({
        success: function(data) {
            data = JSON.parse(data);
            console.log(data);
        },
        error: function() {
            globalFn.showToast({title: '圖片上傳失敗'});
        }
    });
    return false;
});

 

三、flex:1;

參考：https://developer.mozilla.org/zh-CN/docs/Web/CSS/flex

CSS屬性flex規定了彈性元素如何伸長或縮短以適應flex容器中的可用空間。這是一個簡寫屬性，用來設置flex-grow, flex-shrink與flex-basis。

   

   

 

設置min-width，可避免flex 元素在默認寬度之和大於容器的時候發生收縮（CSS flex-shrink 屬性）。

 

四、前端複製到剪切板 

$('body').on('click', '.copy-btn', function () {
    $(this).siblings('.code-input')[0].select(); // 選中文本
    document.execCommand("copy"); // 拷貝當前選中內容到剪貼板
    weui.toast('複製成功');
});

此方式兼容ie8，移動端安卓也支持，可是iOS不支持。

 解決方案：使用插件clipboard.js

參考：https://blog.csdn.net/sinat_34351851/article/details/82627198

https://clipboardjs.com/

1）頁面引入clipboard.min.js（我使用的版本是v2.0.4）

2）html

 

能夠從input、textarea、div等元素中獲取目標內容，data-clipboard-target指向目標節點（被複制/剪切，匹配選擇器）。data-clipboard-action可使用copy和cut，使用cut則點擊按鈕後，內容裏的值被剪切。若是沒有指定，則默認值是copy。cut只對input和textarea起做用。

<!-- Target -->
<textarea id="bar">Mussum ipsum cacilds...</textarea>
<!-- Trigger -->
<button class="btn" data-clipboard-action="cut" data-clipboard-target="#bar">Cut to clipboard</button>

3）js

var clipboard = new ClipboardJS('.copy-btn');
clipboard.on('success', function(e) { // 成功回調
    weui.toast('複製成功');
});
clipboard.on('error', function(e) { // 失敗回調
　  console.log(e); 
});

 

五、weui

調出對話框：

weui.confirm('請使用購買商品時填寫的手機號進行登陸而後查看卡密詳情，從新登陸？', {
    title: '提示',
    buttons: [{
        label: '取消',
        type: 'default',
        onClick: function(){}
    }, {
        label: '肯定',
        type: 'primary',
        onClick: function(){ 
            location.href = '/h5/login.html';
        }
    }]
});

調整對話框樣式：

.weui-dialog {
    width: 85%;
    max-width: 500px;
}
.weui-dialog__title, .weui-dialog__btn {
    font-size: 24px !important;
}
.weui-dialog__bd {
    font-size: 22px !important;
}

瀏覽器渲染：

ios：

  

安卓：

  

 

六、document.referrer

返回跳轉或打開到當前頁面的那個頁面的URI。若是用戶直接打開了這個頁面（不是經過頁面跳轉，而是經過地址欄或者書籤等打開的），則該屬性爲空字符串。

返回上一頁，可使用history.go(-1)或者history.back()【使用這兩種方式返回上一個頁面在移動端不會刷新頁面？】

解決方案：location.href = document.referrer（返回並刷新上一個頁面）

 

七、Safari瀏覽器

• cookie問題

參考：https://blog.csdn.net/u011627980/article/details/79643428

對於先後端分離的項目或者單點登陸的系統後臺須要作session會話校驗或者cookie跨域存儲，Safari瀏覽器可能會遇到沒法存儲cookie，須要關閉瀏覽器的「阻止跨（網）站跟蹤」開關。

  

• 判斷瀏覽器是safari

參考：https://blog.csdn.net/JamieCheung/article/details/80175591

Navigator 對象包含有關瀏覽器的信息。

能夠利用navigator.vendor字段來判斷是不是Safari瀏覽器，navigator.vendor字段是描述瀏覽器提供商的字段，在Safari下爲「Apple Computer, Inc.」

pc端判斷方法：/Apple/.test(navigator.vendor)。

可是這個字段僅僅適合判斷是不是Safari，並且僅適合在PC上判斷。在ios手機上，我經過alert(navigator.vendor);測試，不管是不是safari瀏覽器，都彈框「Apple Computer, Inc.」

 手機端判斷方法：/Safari/.test(navigator.userAgent) && !/Chrome/.test(navigator.userAgent);【測試了ios上的safari瀏覽器和非safari瀏覽器和安卓上的瀏覽器，結果safari瀏覽器的navigator.userAgent字段包含Safari不包含Chrome，ios上的非safari瀏覽器不包含Safari和Chrome，安卓上的瀏覽器包含Safari和Chrome】

 

八、單點登陸

單點登陸（Single Sign On），簡稱爲 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

很早期的公司，一家公司可能只有一個Server，慢慢的Server開始變多了。每一個Server都要進行註冊登陸，退出的時候又要一個個退出。用戶體驗很很差！你能夠想象一下，上豆瓣 要登陸豆瓣FM、豆瓣讀書、豆瓣電影、豆瓣日記......真的會讓人崩潰的。咱們想要另外一種登陸體驗：一家企業下的服務只要一次註冊，登陸的時候只要一次登陸，退出的時候只要一次退出。

參考：https://yq.aliyun.com/articles/636281

 

如圖所示，圖中有4個系統，分別是Application一、Application二、Application三、和SSO。Application一、Application二、Application3沒有登陸模塊，而SSO只有登陸模塊，沒有其餘的業務模塊，當Application一、Application二、Application3須要登陸時，將跳到SSO系統，SSO系統完成登陸，其餘的應用系統也就隨之登陸了。

• 普通的登陸認證機制：

如上圖所示，咱們在瀏覽器（Browser）中訪問一個應用，這個應用須要登陸，咱們填寫完用戶名和密碼後，完成登陸認證。這時，咱們在這個用戶的session中標記登陸狀態爲yes（已登陸），同時在瀏覽器（Browser）中寫入Cookie，這個Cookie是這個用戶的惟一標識。下次咱們再訪問這個應用的時候，請求中會帶上這個Cookie，服務端會根據這個Cookie找到對應的session，經過session來判斷這個用戶是否登陸。若是不作特殊配置，這個Cookie的名字叫作jsessionid，值在服務端（server）是惟一的。

• 不一樣域下的單點登陸：

同域下的單點登陸是巧用了Cookie頂域的特性。若是是不一樣域呢？不一樣域之間Cookie是不共享的。

具體流程以下：

1. 用戶訪問app系統，app系統是須要登陸的，但用戶如今沒有登陸。
2. 跳轉到CAS server，即SSO登陸系統。 SSO系統也沒有登陸，彈出用戶登陸頁。
3. 用戶填寫用戶名、密碼，SSO系統進行認證後，將登陸狀態寫入SSO的session，瀏覽器（Browser）中寫入SSO域下的Cookie。
4. SSO系統登陸完成後會生成一個ST（Service Ticket），而後跳轉到app系統，同時將ST做爲參數傳遞給app系統。
5. app系統拿到ST後，從後臺向SSO發送請求，驗證ST是否有效。
6. 驗證經過後，app系統將登陸狀態寫入session並設置app域下的Cookie。

至此，跨域單點登陸就完成了。之後咱們再訪問app系統時，app就是登陸的。接下來，咱們再看看訪問app2系統時的流程。

1. 用戶訪問app2系統，app2系統沒有登陸，跳轉到SSO。
2. 因爲SSO已經登陸了，不須要從新登陸認證。
3. SSO生成ST，瀏覽器跳轉到app2系統，並將ST做爲參數傳遞給app2。
4. app2拿到ST，後臺訪問SSO，驗證ST是否有效。
5. 驗證成功後，app2將登陸狀態寫入session，並在app2域下寫入Cookie。

這樣，app2系統不須要走登陸流程，就已是登陸了。SSO，app和app2在不一樣的域，它們之間的session不共享也是沒問題的。

補充： https://www.cnblogs.com/EzrealLiu/p/5559255.html

 

九、微信登陸

參考：https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1419316505&token=&lang=zh_CN

網站內嵌二維碼微信登陸JS代碼中href字段做用？
答：若是第三方以爲微信團隊提供的默認樣式與本身的頁面樣式不匹配，能夠本身提供樣式文件來覆蓋默認樣式，並把連接地址填入href字段

擴展：

iframe跨域：瀏覽器有一個同源策略，第一種限制就是不能經過ajax的方法去請求不一樣源的文檔。第二種限制是瀏覽器中不一樣域的框架之間是不能進行js的交互操做的。

 

十、h5頁面在手機上返回如何刷新頁面

var isPageHide =false;
window.addEventListener('pageshow', function () {
    if (isPageHide) {
        window.location.reload();
    }
});
window.addEventListener('pagehide', function () {
    isPageHide =true;
});

onpageshow 事件在用戶瀏覽網頁時觸發。onpageshow 事件相似於 onload 事件，onload 事件在頁面第一次加載時觸發， onpageshow 事件在每次加載頁面時觸發，即 onload 事件在頁面從瀏覽器緩存中讀取時不觸發。

onpagehide 事件在用戶離開網頁時觸發。離開網頁有多種方式。如點擊一個連接，刷新頁面，提交表單，關閉瀏覽器等。.onpagehide 事件有時能夠替代 onunload 事件，但 onunload 事件觸發後沒法緩存頁面。

 

十一、電商超賣及解決方案（事務鎖、樂觀鎖）

1）電商超賣

參考：https://blog.csdn.net/mydistance/article/details/85236410

超賣即「超賣缺貨」，當寶貝庫存接近0時，若是多個買家同時付款購買此寶貝，將會出現「超賣缺貨」現象。電商大促期間，隨着各類優惠促銷活動的刺激，訂單量會急速增加。隨着銷量的節節攀升，商品超賣問題也愈來愈嚴重，嚴重影響了商家的正常運營。

庫存會帶來「超賣」的問題：售出數量多於庫存數量。因爲庫存併發更新的問題，致使在實際庫存已經不足的狀況下，庫存依然在減，致使賣家的商品賣得件數超過秒殺的預期。

優化：

• 在秒殺的時候，因爲瞬時訪問量致使應用的壓力暴漲，數據庫的load上升，IC(商品中心)的壓力很大，從而致使了其餘非秒殺的交易也受到了影響。將秒殺應用與普通交易相隔離，對IC作分組隔離，從而保證秒殺不會影響主站的其餘交易。
• 因爲商品詳情頁面(detail)用戶的刷新頻率很高，因此儘可能將該頁面靜態化。淘寶的秒殺商品詳情頁面，去除了不少沒必要要的後臺查詢邏輯，好比賣家的信譽，星級等信息。
• detail頁面的響應時間在3-5秒，主要緣由是須要到數據庫查詢庫存信息，該操做所花時間比較長，對數據庫的壓力也很大。因此採用了從緩存取庫存信息。淘寶有一個tair緩存，在應用起來的時候，會將商品的庫存信息加載到tair中。
• 聚划算的一次秒殺活動中，出現超賣的狀況，緣由是：庫存信息是從tair中取的，拍下時在tair中減小了庫存，可是在真正購買時，會去更新數據庫中的庫存，這樣就致使數據庫的當前庫存信息又去更新了tair中的庫存信息。這件事情帶來的思考是：儘可能將信息保持一致，可以作到同一處修改最好。好比保持總庫存以及sku的庫存修改保持一致。後來的方案是：數據庫中只記錄默認的庫存信息，對庫存的更新都放在tair中去作。不過這個就要保證tair的足夠穩定，否則tair掛掉，購買信息就全丟了。因此能夠採用一些機制保證信息的可恢復。好比記日誌，不過這種涉及到IO的也會影響性能了。

2）悲觀鎖和樂觀鎖

參考：https://www.imooc.com/article/details/id/44217

悲觀鎖：老是假設最壞的狀況，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完後再把資源轉讓給其它線程）。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖。Java中synchronized和ReentrantLock等獨佔鎖就是悲觀鎖思想的實現。

樂觀鎖：老是假設最好的狀況，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號機制和CAS算法實現。樂觀鎖適用於多讀的應用類型，這樣能夠提升吞吐量，像數據庫提供的相似於write_condition機制，其實都是提供的樂觀鎖。在Java中java.util.concurrent.atomic包下面的原子變量類就是使用了樂觀鎖的一種實現方式CAS實現的。

樂觀鎖相對悲觀鎖而言，樂觀鎖機制採起了更加寬鬆的加鎖機制。悲觀鎖大多數狀況下依靠數據庫的鎖機制實現，以保證操做最大程度的獨佔性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷每每沒法承受。而樂觀鎖機制在必定程度上解決了這個問題。樂觀鎖，大可能是基於數據版本（ Version ）記錄機制實現。何謂數據版本？即爲數據增長一個版本標識，在基於數據庫表的版本解決方案中，通常是經過爲數據庫表增長一個 「version」 字段來實現。讀取出數據時，將此版本號一同讀出，以後更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，若是提交的數據版本號大於數據庫表當前版本號，則予以更新，不然認爲是過時數據。

兩種鎖的使用場景：兩種鎖各有優缺點，不可認爲一種好於另外一種，像樂觀鎖適用於寫比較少的狀況下（多讀場景），即衝突真的不多發生的時候，這樣能夠省去了鎖的開銷，加大了系統的整個吞吐量。但若是是多寫的狀況，通常會常常產生衝突，這就會致使上層應用會不斷的進行retry，這樣反卻是下降了性能，因此通常多寫的場景下用悲觀鎖就比較合適。

樂觀鎖常見的兩種實現方式：樂觀鎖通常會使用版本號機制或CAS算法實現。

CAS算法：即compare and swap（比較與交換），是一種有名的無鎖算法。

CAS算法的缺點：

• ABA 問題：若是一個變量V初次讀取的時候是A值，而且在準備賦值的時候檢查到它仍然是A值，那咱們就能說明它的值沒有被其餘線程修改過了嗎？很明顯是不能的，由於在這段時間它的值可能被改成其餘值，而後又改回A，那CAS操做就會誤認爲它歷來沒有被修改過。這個問題被稱爲CAS操做的 "ABA"問題......

 

用戶體驗（User Experience，簡稱UE/UX）

　1）步驟型導引：將複雜的任務分解成有序的任務操做流，每一個簡化後的任務均可以快速完成，以幫助用戶順利完成總體任務。

　　綜合考慮用戶的易用性和情感化因素，過多的信息難以讓用戶聚焦，同時產生抵觸情緒，同時在校驗上也承載了極大的分險，由於數據越多，修改校驗後的錯誤信息的難度就越大。面對這種交互信息繁多的狀況，分步分解任務後，用戶只須要按着機器預置好的一系列步驟，每完成一步對於用戶情緒上會有成就感加成，同時聚焦每一頁關鍵任務，分步校驗，避免用戶挫敗感，高效完成表單的填寫。

在上圖中，金蝶雲蒼穹產品裏的出差類應用，原來的長單據填寫被拆解成三步填寫，下降決策成本與用戶風險，用戶只須要關注當前步驟的結果。該方法同時適用於PC端、移動端等各終端。對於移動端而言，須要時刻注意在錄入表單的場景中，鍵盤彈起後剩餘的界面空間，此時保證信息出如今界面上方，也是易用性的細節保證。

注：http://www.javashuo.com/article/p-hzdtfgni-bz.html