天天干夜夜操91视频网站,天天干夜夜操91视频网站,一本一道精品欧美中文,老熟妇性老熟妇性色,国产午夜亚洲精品羞羞答答八戒网,亚洲乱熟女一区二区三区色,2021国产精品自慰,大鸡吧草我流水视频,波多野结衣中文字幕在线

日常工作開(kāi)發(fā)中，遇到哪些坑是讓你印象深刻且具有挑戰(zhàn)的，它們是怎么產(chǎn)生的，我們?cè)撊绾伪苊?？本期我們帶?lái)與前端開(kāi)發(fā)相關(guān)的三個(gè)問(wèn)題：一次網(wǎng)頁(yè)資源加載問(wèn)題的定位過(guò)程；CSS中的z-index層疊覆蓋問(wèn)題；CSS3 transform 屬性對(duì) position 的影響，希望能為你的技術(shù)提升助力。

01

一次網(wǎng)頁(yè)資源加載問(wèn)題的定位過(guò)程

今天討論的話題比較聚焦，就是有用戶報(bào)Web頁(yè)面資源或局部區(qū)域加載不出來(lái)的問(wèn)題，該如何查？又該如何避免？

1.1 問(wèn)題描述

用戶反饋?lái)?yè)面內(nèi)的推薦列表加載不出來(lái)，而且能穩(wěn)定復(fù)現(xiàn)。

1.2 分析

第一反應(yīng)就是自己復(fù)現(xiàn)，但是不行啊，團(tuán)隊(duì)沒(méi)有同學(xué)能復(fù)現(xiàn)，也無(wú)法接觸到用戶。那么先理清楚此區(qū)域的實(shí)現(xiàn)邏輯，該區(qū)域的HMTL雖然已經(jīng)下載，但默認(rèn)不可見(jiàn)，而是依賴c.js（文件名簡(jiǎn)化了）展現(xiàn)。基于此，我們懷疑：

• c.js 以及其依賴的a.js, b.js等 加載非常慢或直接失敗；

• c.js 以及其依賴邏輯發(fā)生JS異常。

1.3 監(jiān)控實(shí)現(xiàn)

那么該如何佐證，我們需要做下監(jiān)控。

做監(jiān)控需要考慮到實(shí)際場(chǎng)景，由于Head和Body都有外鏈請(qǐng)求，因此監(jiān)控代碼要置于頂部且內(nèi)聯(lián)，且代碼要精簡(jiǎn)，從而可以最大程度拿到信息和減少首屏影響。

window.addEventListener('error', event => {    if (event.srcElement !== window) {        console.log('資源加載失敗，加載資源的元素是：', event.srcElement);        send();  }    else {        console.log('JS報(bào)錯(cuò)：', event.message);        send();    }}, true);window.addEventListener('unhandledrejection', event => {    const error = event.reason || {};    console.log('JS報(bào)錯(cuò)：', error);    send();});

上述可以監(jiān)控到全局的 資源加載失敗 和 JS異常，包括未捕獲的Promise Rejection。此外，還需定位資源，通過(guò)向上遍歷獲取元素的XPath，XPath上帶上id或class屬性，避免全都是`div>div>div>div`，而摸不著頭腦。

上線后發(fā)現(xiàn)，有不少錯(cuò)誤都是script error，這是因?yàn)橥怄淛S都是CDN域名。瀏覽器對(duì)于腳本執(zhí)行遵守 same-origin policy ，為避免域名信息泄漏給宿主域名，特意隱藏錯(cuò)誤信息。

解決方案是給所有外鏈JS加上響應(yīng)頭。

access-control-allow-origin: *

JS資源若托管在云上CDN服務(wù)，那么其CDN控制臺(tái)都會(huì)提供增加Header功能。

若是自有服務(wù)，就需要主動(dòng)設(shè)置Header。這里假設(shè)使用Koa2 框架，設(shè)置如下：

ctx.set('Access-Control-Allow-Origin', '*');

然后給所有該CDN域名的script元素增加crossorigin屬性，如：

但發(fā)現(xiàn)其在Chrome瀏覽器是生效的，可以拿到真實(shí)錯(cuò)誤堆棧?？上?，Safari瀏覽器不支持此機(jī)制，依然只能拿到script error。為了Safari拿到真實(shí)錯(cuò)誤，外鏈需要是同域。因此有個(gè)辦法是在www.a.com的Nginx做一層代理轉(zhuǎn)發(fā)，即 https://www.a.com/static/a.js 轉(zhuǎn)發(fā)到 https://cdn.a.com/static/a.js  。不過(guò)如此一來(lái)，就喪失CDN就近訪問(wèn)的優(yōu)勢(shì)，不適合常態(tài)化。但可以在定位用戶問(wèn)題時(shí)，將用戶訪問(wèn)臨時(shí)切換成 https://www.a.com/static/a.js。

那如何監(jiān)控加載慢，可以在onload事件后獲取慢資源。

const list = performance.getEntriesByType('resource');const len = list.length;const slowList = [];for (let i = 0; i < len; i++) {     const timing = list[i];     // 大于1s     if (timing.duration > 1000) {         slowList.push(timing);     }}send(slowList);

上報(bào)信息也包含了每個(gè)請(qǐng)求的TCP、下載等耗時(shí)，詳細(xì)可見(jiàn)Resource_Timing_API規(guī)范（https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API）。

要注意的是，該API信息受到CORS （https://developer.mozilla.org/en-US/docs/Glossary/CORS）影響，必須給資源設(shè)置如下響應(yīng)頭才能拿到數(shù)據(jù)，否則很多字段取值都是0。

Timing-Allow-Origin: *

通過(guò)分析這些數(shù)據(jù)，我們可以知道資源耗時(shí)過(guò)程，這里可以充分參照Chrome開(kāi)發(fā)者工具提供的Timing子面板，了解關(guān)鍵時(shí)段耗時(shí)。比如同域名6個(gè)并發(fā)請(qǐng)求限制，若資源請(qǐng)求較多，則可能處于stalled（掛起等待）狀態(tài)。這些階段可能原因分析參考Chrome說(shuō)明。

?

由于有些圖片在頁(yè)面內(nèi)不好確定位置，因此需要獲取其XPath，如何獲取呢？對(duì)于img標(biāo)簽加載圖片，可以快速獲取：

// timing.name就是資源地址，適合const img = document.body.querySelector('img[src="' + timing.name + '"]');const xpath = getxpath(img);

額外信息獲取，其實(shí)除了問(wèn)題信息本身外，用戶當(dāng)時(shí)環(huán)境信息非常重要，如

1. performance.memory：獲取內(nèi)存使用信息；

2. navigator.connection：用戶連接情況，可惜，此API不怎么準(zhǔn)；

如果是APP內(nèi)頁(yè)面，可以調(diào)用端能力獲取到用戶網(wǎng)絡(luò)類型、網(wǎng)速。

1.4 數(shù)據(jù)分析

上線后，用戶依然訪問(wèn)慢。根據(jù)日志發(fā)現(xiàn)，用戶未有JS報(bào)錯(cuò)，但根據(jù)慢資源日志，發(fā)現(xiàn)有大量資源加載超過(guò)1s，有些資源甚至達(dá)到10s，其花費(fèi)在建連階段耗時(shí)較大。看來(lái)問(wèn)題還不是這么簡(jiǎn)單，那如何解釋用戶資源加載如此慢？用戶所在局域網(wǎng)環(huán)境差？接入運(yùn)營(yíng)商質(zhì)量差？插件影響？CDN問(wèn)題？

這些問(wèn)題只有CDN可以去排查，我們首先拿到用戶訪問(wèn) https://www.a.com 的服務(wù)器端日志，獲取到用戶IP。聯(lián)合云CDN服務(wù)，根據(jù)用戶IP，竟然未查到任何CDN訪問(wèn)日志。但從日志看，用戶確實(shí)請(qǐng)求了大量JS，并不是全部本地緩存。所以用戶IP可能不是訪問(wèn)CDN的IP，有一種情況是使用代理。

所以想通過(guò)其他信息撈取用戶的CDN日志，來(lái)確定訪問(wèn)CDN的IP。思路是按照用戶UA、請(qǐng)求地址等非精確信息撈取CDN日志，但由于撈取日志量非常大，無(wú)法確定哪些日志是該用戶的；而：

1.CDN域名一般是無(wú)cookie域名，沒(méi)有TRACEID；

2.Web頁(yè)面無(wú)法給script/link資源請(qǐng)求頭設(shè)置Traceid；

3.前端目前無(wú)法拿到CDN TCP建連IP；

綜上，除了用戶IP，種種精確定位信息都無(wú)效。因此這一步舉步維艱。

好在能聯(lián)系上用戶，咨詢是否使用代理，結(jié)果：確實(shí)使用了代理，且根據(jù)用戶代理，實(shí)測(cè)代理非常慢，甚至加載超時(shí)，其代理請(qǐng)求走了香港服務(wù)器。通過(guò)代理出口IP，最終從海外CDN撈取到了用戶訪問(wèn)日志。同時(shí)也確認(rèn)，用戶將所有 *.a.com 請(qǐng)求配置不使用代理，所以服務(wù)端能拿到的IP是用戶IP，而CDN拿到的是代理出口IP。

1.5 總結(jié)

Web能力終是有限，但通過(guò)足夠的輔助信息，以及全鏈路協(xié)作，在定位Case過(guò)程中也會(huì)事半功倍。該Case雖然歸因于用戶不合理代理配置，但也可基于此場(chǎng)景做技術(shù)優(yōu)化。如任何首屏內(nèi)容不依賴外鏈展現(xiàn)，減少核心邏輯JS體積，增加資源緩存率等。

02

CSS中的z-index層疊覆蓋問(wèn)題

2.1 含義

• 當(dāng)前元素的堆疊順序
• 當(dāng)前元素是否建立新的堆疊上下文

2.2 屬性值

• 默認(rèn)值：z-index:auto;
• 整數(shù)值：z-index:;
• 繼承：z-index:inherit;

2.3 基本特性

• 在CSS2.1時(shí)代，需要和定位元素配合使用；
• 如果定位元素z-index沒(méi)有發(fā)生嵌套(并列的)：
• 后來(lái)者居上的準(zhǔn)則；
• 哪個(gè)大哪個(gè)上（z-index大小比較）；
• 如果定位元素z-index發(fā)生嵌套：
• 祖先優(yōu)先原則（前提：z-index是數(shù)值，不是auto）

• 老業(yè)務(wù)寫了個(gè)z-index：5000；
• B同學(xué)調(diào)用一個(gè)全局彈層，原本設(shè)置為100，想要覆蓋全局，z-index改為10000；
• C同學(xué)調(diào)用一個(gè)toast，原本設(shè)置為2000，想要覆蓋彈層，z-index改為100000；
• ...
• 層層覆蓋的情況下，不能無(wú)限改下去，為了避免這樣的情況發(fā)生，減少不斷覆蓋的情況，那么應(yīng)該如何規(guī)定z-index的值呢；

const KEY = '_tbv_z_index_';function initZIndex$() {    return (window[KEY] = 10000);}// 初始化，只能被調(diào)用一次function once(fn) {    const flag = true;    return function () {        if (flag) {            flag = false;            const args = Array.prototype.slice.call(arguments, 0);            fn.apply(args);        }    };}const initZIndex = once(initZIndex$);// 外部調(diào)用&支持重置function zIndex$(zIndex) {    if (zIndex) {        return (window[KEY] = zIndex);    }    return (window[KEY] += 1);}// 組件mount時(shí)觸發(fā)+1const zIndex = zIndex$();

03

CSS3 transform 屬性對(duì) position 的影響

CSS3中引入了transform，定義了在二維或三維空間中元素的旋轉(zhuǎn)、縮放、平移等行為，還能利用合成層原理開(kāi)啟GPU加速，提升頁(yè)面動(dòng)畫(huà)的流暢度。然而transform也不是「省油的燈」（并沒(méi)有說(shuō)它不好的意思，我就很喜歡它），增強(qiáng)了頁(yè)面交互效果的同時(shí)它也有一些「副作用」容易讓人踩坑。

position: fixed 實(shí)現(xiàn)了固定定位的效果，元素不追隨滾動(dòng)條進(jìn)行滾動(dòng)，普通元素的overflow屬性也無(wú)法對(duì)其進(jìn)行裁剪，因此在一些需要固定頭部、固定懸浮按鈕的場(chǎng)景中十分好用。

但fixed遇上transform時(shí)表現(xiàn)的就不再那么「強(qiáng)硬」，反而退化成了position: absolute的效果。在外層沒(méi)有transform影響時(shí)，固定定位元素的包含塊是根元素，可以近似認(rèn)為是元素，因此fixed元素可以實(shí)現(xiàn)相對(duì)視口定位的效果。而當(dāng)元素設(shè)置了transform時(shí)，便會(huì)創(chuàng)建一個(gè)新的包含塊(containing block)，如果該元素的內(nèi)部有元素設(shè)置了fixed定位，那么該fixed元素的包含塊便不再是根元素，而變成了被設(shè)置了transform的元素。如果在開(kāi)發(fā)過(guò)程中發(fā)現(xiàn)設(shè)置了position:fixed的元素隨著頁(yè)面滾動(dòng)了，就可以看下fixed的元素外層是否有元素設(shè)置了transfrom。

除了包含塊之外，transform還會(huì)生成新的層疊上下文（stack context）,使得元素內(nèi)部和外部的z-index相互獨(dú)立，出現(xiàn)低z-index元素層級(jí)比高z-index元素還高的情況：