1. 第13屆藍(lán)橋杯Web賽道賽題全貌與出題邏輯拆解2023年的第13屆藍(lán)橋杯Web應(yīng)用開(kāi)發(fā)賽道作為前端方向含金量比較高的高校競(jìng)賽關(guān)注度持續(xù)走高。這屆題目的整體風(fēng)格和往年相比有了比較明顯的變化不再單純考“會(huì)不會(huì)寫(xiě)代碼”而是更側(cè)重“能不能在有限時(shí)間內(nèi)完成一個(gè)接近真實(shí)工作的網(wǎng)頁(yè)還原和邏輯交互”。很多人賽后都說(shuō)“題目不算難但時(shí)間真的不夠用”這句話(huà)基本概括了整場(chǎng)考試的核心矛盾。先說(shuō)結(jié)論第13屆Web賽道一共6道題滿(mǎn)分150分考試時(shí)間4小時(shí)。題型分布大致是2道HTML/CSS界面還原題、2道JavaScript交互邏輯題、1道綜合性應(yīng)用題涉及DOM操作與數(shù)據(jù)渲染、1道動(dòng)態(tài)數(shù)據(jù)可視化/圖表類(lèi)題目。從分?jǐn)?shù)權(quán)重來(lái)看界面還原類(lèi)題目占了比較大的比重差不多有60分以上剩下的是JS邏輯題和數(shù)據(jù)交互題。這屆出題的一個(gè)明顯特征是“題目描述很長(zhǎng)但代碼框架已經(jīng)給你搭好”。本質(zhì)上考驗(yàn)的是三件事讀懂題目的能力、在已有代碼基礎(chǔ)上修改的能力、以及瀏覽器調(diào)試的熟練度。這跟很多同學(xué)平時(shí)刷題的習(xí)慣不太一樣——刷LeetCode式的前端題目通常是白板寫(xiě)函數(shù)但藍(lán)橋杯Web賽道更像是在“接手一個(gè)半成品項(xiàng)目”你得先看懂別人寫(xiě)的代碼再在這個(gè)基礎(chǔ)上小步快改。我記得考場(chǎng)上拿到第一道頁(yè)面還原題的時(shí)候設(shè)計(jì)稿是一張比較復(fù)雜的電商活動(dòng)頁(yè)包含輪播圖、商品卡片、價(jià)格標(biāo)簽、促銷(xiāo)倒計(jì)時(shí)等模塊。這種題目放到平時(shí)練習(xí)做一版精修可能需要兩個(gè)小時(shí)但賽場(chǎng)上你最多只能給它50分鐘。這就逼著你形成一套“先搭骨架、再摳細(xì)節(jié)、最后查邊界”的流水線(xiàn)打法而不是像平時(shí)寫(xiě)作業(yè)那樣從左上角開(kāi)始一點(diǎn)一點(diǎn)精雕細(xì)琢。第13屆藍(lán)橋杯Web賽道的難度系數(shù)我個(gè)人的評(píng)價(jià)是如果滿(mǎn)分五星它大概在三星半到四星之間。難不在知識(shí)點(diǎn)本身難在陌生環(huán)境下的快速適應(yīng)。很多同學(xué)平時(shí)練習(xí)都是在自己的編輯器里、自己的環(huán)境下到了比賽那種精簡(jiǎn)版瀏覽器環(huán)境沒(méi)有代碼提示、沒(méi)有自動(dòng)補(bǔ)全、沒(méi)有插件加持差距一下就拉開(kāi)了。這篇文章我打算從題型拆解、核心考點(diǎn)、實(shí)戰(zhàn)流程、踩坑回顧四個(gè)維度把第13屆藍(lán)橋杯Web應(yīng)用開(kāi)發(fā)賽道的題解思路完整復(fù)盤(pán)一遍。適合兩類(lèi)人看一是準(zhǔn)備參加下一屆比賽的同學(xué)可以提前感受出題風(fēng)格二是已經(jīng)比完但想查漏補(bǔ)缺的同學(xué)可以對(duì)照看看自己哪些環(huán)節(jié)還能優(yōu)化。2. 題型深度解析6道題的分類(lèi)與得分策略2.1 界面還原題的三個(gè)層次布局、樣式、細(xì)節(jié)精度第13屆的界面還原題給的是靜態(tài)設(shè)計(jì)稿通常是PNG/JPG圖片要求你用HTMLCSS實(shí)現(xiàn)出一個(gè)視覺(jué)上盡量一致的頁(yè)面。聽(tīng)起來(lái)樸實(shí)無(wú)華但這里面的分層很清楚第一層是布局結(jié)構(gòu)。拿到設(shè)計(jì)稿第一步不是看顏色、看字體而是先劃分大的區(qū)塊。設(shè)計(jì)稿里哪些部分是通欄、哪些是兩列、哪些是卡片列表先梳理出大盒子的嵌套關(guān)系。這一步的核心工具是Flexbox和Grid如果這兩樣不夠熟練本質(zhì)上是靠“感覺(jué)”在做題很難穩(wěn)定拿到高分。第13屆里有一道題的設(shè)計(jì)稿是典型的三段式布局頂部導(dǎo)航、中部商品瀑布流、底部信息欄中間商品區(qū)域用到了兩列自適應(yīng)布局容器寬度是百分比卡片間距用gap控制。這類(lèi)題能攤開(kāi)考的就是“盒模型計(jì)算是否準(zhǔn)確”和“Flex/Gride屬性是否配置正確”。第二層是樣式還原。布局對(duì)了接下來(lái)就是對(duì)細(xì)節(jié)圓角大小、陰影偏差、邊框粗細(xì)、字體行高、圖標(biāo)尺寸。這里比較坑的是設(shè)計(jì)稿里很多元素并沒(méi)有明確的標(biāo)注數(shù)值你得靠肉眼判斷和經(jīng)驗(yàn)估算。比如卡片圓角設(shè)計(jì)稿上看著像是12px但你寫(xiě)8px似乎也差不多——這種時(shí)候千萬(wàn)別猶豫太久按接近值先寫(xiě)上整頁(yè)做完再統(tǒng)一回頭精修。賽場(chǎng)上的時(shí)間單位是以分鐘計(jì)的不是以小時(shí)計(jì)的一個(gè)圓角糾結(jié)3分鐘就是很大的浪費(fèi)。第三層是響應(yīng)式與邊界情況。第13屆的頁(yè)面還原題沒(méi)有強(qiáng)制要求做完整的響應(yīng)式適配但題目描述里往往埋著一條“當(dāng)窗口寬度小于某個(gè)值時(shí)兩列布局切換為單列”。這道題我記得很清楚好多人最后沒(méi)發(fā)現(xiàn)這個(gè)隱藏條件在標(biāo)準(zhǔn)寬度下看著幾乎一模一樣但稍一縮窗口就露餡了。所以讀題目描述的時(shí)候不要只盯著視覺(jué)設(shè)計(jì)稿文字里出現(xiàn)的“小于”“大于”“當(dāng)...時(shí)”這類(lèi)條件描述基本就是加分項(xiàng)或者扣分點(diǎn)的所在。2.2 JavaScript交互題的命題套路不是算法是業(yè)務(wù)邏輯藍(lán)橋杯Web賽道的JS題和算法競(jìng)賽那種“手寫(xiě)快速排序、手寫(xiě)二叉樹(shù)遍歷”完全不是一個(gè)路數(shù)。它更接近日常工作里的場(chǎng)景給你一段已經(jīng)有部分功能的代碼讓你補(bǔ)全其中的關(guān)鍵函數(shù)或者修復(fù)某個(gè)具體的Bug。第13屆的JS交互題大致可以分成這么幾類(lèi)一類(lèi)是事件處理與數(shù)據(jù)聯(lián)動(dòng)。比如頁(yè)面上有個(gè)下拉選擇框選擇不同城市后下面的天氣信息卡片要跟著變化或者有一組單選按鈕切換到不同選項(xiàng)時(shí)表格的數(shù)據(jù)源要重新渲染。這類(lèi)題目考驗(yàn)的是對(duì)事件監(jiān)聽(tīng)、數(shù)據(jù)映射和DOM更新的熟練度不需要寫(xiě)很復(fù)雜的算法但對(duì)代碼的組織能力有要求。官方給的框架里通常已經(jīng)定義好了數(shù)據(jù)結(jié)構(gòu)你需要做的是把數(shù)據(jù)和視圖用事件連接起來(lái)這中間最?？嫉募?xì)節(jié)就是“初始化時(shí)要不要執(zhí)行一次渲染函數(shù)”。另一類(lèi)是數(shù)據(jù)處理與格式化。比如后端返回了一個(gè)訂單列表字段都是英文要求你在頁(yè)面上以中文形式展示或者時(shí)間戳需要格式化成“YYYY-MM-DD HH:mm:ss”再或者數(shù)組里的數(shù)字需要按從小到大排序并去重。這些題目的核心就是JavaScript的內(nèi)置方法和數(shù)組的常用操作——map、filter、sort、reduce考的都是這些“基本功”。第13屆有一道題就是給了一組商品銷(xiāo)售數(shù)據(jù)要求實(shí)現(xiàn)“按銷(xiāo)量降序排列并過(guò)濾掉庫(kù)存為0的商品”說(shuō)白了就是排序加過(guò)濾一道非常典型的數(shù)據(jù)加工題。還有一類(lèi)是動(dòng)態(tài)DOM創(chuàng)建。題目會(huì)給出一個(gè)數(shù)據(jù)源讓你根據(jù)數(shù)據(jù)生成一組相同結(jié)構(gòu)的DOM節(jié)點(diǎn)。這就要用到模板字符串、createElement、appendChild這類(lèi)操作稍微進(jìn)階一點(diǎn)的會(huì)要求你用事件委托去處理動(dòng)態(tài)生成節(jié)點(diǎn)上的點(diǎn)擊事件——這道題幾乎每年都出現(xiàn)識(shí)別出來(lái)基本就等于送分題。交互題的另一個(gè)共性是“代碼已經(jīng)寫(xiě)了一半”你要在理解現(xiàn)有代碼的基礎(chǔ)上找到缺的那一塊。這就意味著你一開(kāi)始不能急著改代碼要先花兩分鐘把已有的函數(shù)都讀一遍理清數(shù)據(jù)流動(dòng)的方向。很多同學(xué)上來(lái)就開(kāi)始寫(xiě)寫(xiě)到一半發(fā)現(xiàn)變量名對(duì)不上、函數(shù)被重復(fù)定義、之前的代碼風(fēng)格和自己的習(xí)慣沖突反而浪費(fèi)了更多的時(shí)間。2.3 數(shù)據(jù)可視化與應(yīng)用類(lèi)題目的特殊之處第13屆的場(chǎng)景化大題把數(shù)據(jù)可視化和真實(shí)應(yīng)用場(chǎng)景結(jié)合在了一起。這類(lèi)題目通常要求你在一個(gè)給定的HTML頁(yè)面中通過(guò)JavaScript將數(shù)據(jù)處理后渲染成圖表、卡片列表或者某種信息面板。這里的核心考點(diǎn)是“能否把原始數(shù)據(jù)處理成視圖需要的結(jié)構(gòu)”。舉個(gè)例子題目可能給你一份銷(xiāo)售記錄數(shù)組每條記錄包含日期、門(mén)店、銷(xiāo)售額等字段然后要求你在頁(yè)面上展示“各門(mén)店銷(xiāo)售趨勢(shì)圖”或者“總銷(xiāo)售額統(tǒng)計(jì)卡片”。如果你直接用原始數(shù)據(jù)去渲染圖表圖表組件可能不認(rèn)你必須先把數(shù)據(jù)按門(mén)店分組、按日期匯總甚至還要計(jì)算環(huán)比增長(zhǎng)這些預(yù)處理邏輯本身就要占用不少時(shí)間。圖表部分在第13屆里是可以選型自由的——可以用原生Canvas繪制也可以用引入的輕量圖表庫(kù)。但明確一點(diǎn)比賽環(huán)境里不會(huì)給你CDN讓你在線(xiàn)引包所以要么用題目自帶的庫(kù)要么就得從零自己畫(huà)。如果題目框架里已經(jīng)引入了某個(gè)圖表庫(kù)那你就得快速熟悉它的API每個(gè)圖表庫(kù)的配置項(xiàng)都不一樣這時(shí)候讀官方文檔的速度就很重要了。我的建議是不要把時(shí)間花在追求圖表的酷炫動(dòng)畫(huà)上先保證數(shù)據(jù)正確顯示再加裝飾。這類(lèi)題目的時(shí)間跨度比較大做完大概需要50分鐘到70分鐘。所以我把它排在整體做題順序的中后段——先拿保分題再啃這塊硬骨頭。3. 實(shí)戰(zhàn)拆解界面還原題怎么做到又快又準(zhǔn)界面還原題在整張?jiān)嚲砝锏男詢(xún)r(jià)比其實(shí)很高因?yàn)樗目键c(diǎn)非常明確基本不涉及算法只要CSS功底扎實(shí)分?jǐn)?shù)是比較穩(wěn)定的。第13屆的界面還原題在細(xì)節(jié)上比以往增加了幾個(gè)小小的“陷阱”但套路還是可以歸納的。我把自己做題時(shí)的常規(guī)步驟分享一下基本可以覆蓋大多數(shù)還原場(chǎng)景。3.1 打開(kāi)設(shè)計(jì)稿先干三件事量、拆、排第一件事是“量”——測(cè)量設(shè)計(jì)稿中的關(guān)鍵尺寸。如果題目給的是帶標(biāo)注的尺寸圖那信息就明確很多照著標(biāo)注寫(xiě)就行。但很多時(shí)候藍(lán)橋杯給的是一個(gè)純草圖沒(méi)有標(biāo)數(shù)字。這時(shí)候我的做法是以設(shè)計(jì)稿的整體寬度為基準(zhǔn)通常是750px或者1440px然后用比例推算組件尺寸。舉個(gè)例子設(shè)計(jì)稿寬度是750px某個(gè)卡片區(qū)域視覺(jué)上占了半屏那它的寬度大概就是375px。這種比例法不用特別精確能保證大板塊不錯(cuò)位就夠了。第二件事是“拆”——把設(shè)計(jì)稿按視覺(jué)區(qū)域拆分出獨(dú)立的模塊并畫(huà)出DOM結(jié)構(gòu)的草圖。這一步的關(guān)鍵是“先有結(jié)構(gòu)再寫(xiě)樣式”。很多時(shí)候我們寫(xiě)頁(yè)面會(huì)陷入“邊寫(xiě)邊想”的局面寫(xiě)著寫(xiě)著發(fā)現(xiàn)某個(gè)內(nèi)容不知道放哪個(gè)容器里。先花五分鐘畫(huà)個(gè)結(jié)構(gòu)草稿你后面寫(xiě)代碼的每一分鐘都會(huì)是高效的。第13屆的電商活動(dòng)頁(yè)我當(dāng)時(shí)拆了六個(gè)部分導(dǎo)航欄、搜索框、輪播區(qū)、分類(lèi)導(dǎo)航、商品列表、底部版權(quán)區(qū)。拆完之后一路寫(xiě)下來(lái)幾乎沒(méi)有停頓。第三件事是“排”——確定哪些模塊是復(fù)用型的需要用循環(huán)遍歷來(lái)渲染哪些是固定的直接寫(xiě)在HTML里。像商品列表這種數(shù)據(jù)可能是題目用JS模擬接口返回的那就不能手動(dòng)寫(xiě)5個(gè)一模一樣的div得用數(shù)組map出來(lái)。如果你一開(kāi)始就手動(dòng)復(fù)制了HTML節(jié)點(diǎn)后續(xù)題目要求你用接口數(shù)據(jù)渲染的時(shí)候你就得回頭刪代碼效率很低。3.2 CSS樣式的細(xì)節(jié)處理掌控盒模型的每一個(gè)像素界面還原題丟分最可惜的往往不是整體布局錯(cuò)了而是一些小地方差了那么幾個(gè)像素。第13屆里常見(jiàn)的細(xì)節(jié)考點(diǎn)包括邊框和圓角卡片列表里每張卡片有一個(gè)圓角邊框設(shè)計(jì)稿里視覺(jué)上是“比較圓潤(rùn)”的我一開(kāi)始設(shè)了8px后來(lái)跟原圖對(duì)比感覺(jué)不太夠調(diào)到了12px。這種誤差在自動(dòng)判分系統(tǒng)里可能就有差別。我的經(jīng)驗(yàn)是單價(jià)不為零的小型組件比如按鈕、輸入框、標(biāo)簽圓角基本是2-8px之間中等尺寸的卡片是12-16px大容器彈窗之類(lèi)的可以定20px以上。拿不準(zhǔn)就取中間值至少視覺(jué)上不會(huì)怪。陰影和層級(jí)第13屆的設(shè)計(jì)稿里有個(gè)浮層卡片底部有比較明顯的投影。這里要區(qū)分box-shadow和filter: drop-shadow()——前者是基于盒子形狀的陰影后者是基于內(nèi)容形狀的視覺(jué)效果不一樣。一般情況下用box-shadow就夠了注意陰影的方向和模糊半徑。我當(dāng)時(shí)寫(xiě)的是0 4px 12px rgba(0,0,0,0.08)效果和設(shè)計(jì)稿比較接近。文本溢出處理商品卡片里的標(biāo)題通常一行放不下設(shè)計(jì)稿里的表現(xiàn)是超出用省略號(hào)。這里三件套要記熟white-space: nowrap; overflow: hidden; text-overflow: ellipsis;。第13屆的商品卡片標(biāo)題我瞄了一眼就不長(zhǎng)但我也習(xí)慣性地加了這三行因?yàn)橛行┥唐访容^長(zhǎng)的時(shí)候沒(méi)有這三行設(shè)計(jì)稿就會(huì)變形。還有一個(gè)容易被忽略的點(diǎn)是圖片資源的處理。比賽環(huán)境一般不能訪(fǎng)問(wèn)外網(wǎng)圖片設(shè)計(jì)稿里的圖片可能會(huì)用占位色塊代替。你寫(xiě)CSS的時(shí)候要給img標(biāo)簽設(shè)置width和height否則圖片加載不出來(lái)時(shí)頁(yè)面結(jié)構(gòu)就崩塌了。很多同學(xué)在這里栽過(guò)跟頭代碼邏輯沒(méi)問(wèn)題但頁(yè)面顯示出來(lái)是一堆碎裂的圖標(biāo)分?jǐn)?shù)直接打折扣。3.3 動(dòng)態(tài)數(shù)據(jù)渲染的正確打開(kāi)方式界面還原題里有一個(gè)常見(jiàn)的環(huán)節(jié)商品數(shù)據(jù)通過(guò)JS動(dòng)態(tài)渲染。題目通常會(huì)提前用const goodsList [...]定義好數(shù)組你的工作就是用JavaScript把這組數(shù)據(jù)渲染到頁(yè)面上。這塊內(nèi)容我單獨(dú)拿出來(lái)講因?yàn)樗膶?xiě)法有好有壞直接影響后續(xù)調(diào)試效率。建議的做法是在script標(biāo)簽里寫(xiě)一個(gè)renderGoods(list)函數(shù)函數(shù)內(nèi)部用list.map(...)生成HTML字符串然后用innerHTML一次性插入容器。寫(xiě)的時(shí)候注意模板字符串里要區(qū)分?jǐn)?shù)據(jù)字段比如div classprice${item.price}/div。還有一種做法是創(chuàng)建document.createElement(div)逐個(gè)appendChild到容器里這個(gè)方式的性能略差而且代碼量更大但如果后續(xù)要綁定事件會(huì)更合適一些。數(shù)據(jù)渲染完成后要檢查一個(gè)關(guān)鍵細(xì)節(jié)如果某個(gè)數(shù)據(jù)字段不存在頁(yè)面會(huì)不會(huì)報(bào)錯(cuò)。第13屆里有一個(gè)商品的discount字段是可能為空的設(shè)計(jì)稿在這個(gè)位置上要求“沒(méi)折扣時(shí)不顯示折扣標(biāo)簽”。如果你不管三七二十一直接渲染${item.discount}那頁(yè)面上就會(huì)露出一個(gè)undefined字樣。很多人回頭復(fù)查時(shí)才發(fā)現(xiàn)這個(gè)問(wèn)題。其實(shí)處理方案很簡(jiǎn)單先用Array.isArray()或者typeof判斷一下字段是否存在再?zèng)Q定渲染什么。3.4 輪播圖與倒計(jì)時(shí)高頻組件的固定套路第13屆界面還原題的整個(gè)頁(yè)面里輪播圖和倒計(jì)時(shí)占了差不多十分之一的分?jǐn)?shù)。這幾個(gè)組件是前端頁(yè)面里出場(chǎng)率最高的也是藍(lán)橋杯Web賽道歷年愛(ài)考的值得我們單拎出來(lái)說(shuō)。輪播圖的核心是“圖片索引的切換”。組件的結(jié)構(gòu)是一個(gè)可視區(qū)域容器overflow: hidden內(nèi)部有一個(gè)橫向排列的圖片列表display: flex切換時(shí)通過(guò)修改列表的transform: translateX()來(lái)實(shí)現(xiàn)。自動(dòng)播放的核心就是一個(gè)setInterval每隔幾秒讓索引加一并更新translateX的值。如果要加手動(dòng)左右按鈕就在按鈕點(diǎn)擊事件里加減索引并重新定位即可。當(dāng)時(shí)那題還要求“輪播圖下方的小圓點(diǎn)跟隨切換同步高亮”這也不算難關(guān)鍵是把索引和數(shù)據(jù)狀態(tài)對(duì)應(yīng)起來(lái)每次切換索引時(shí)遍歷所有小圓點(diǎn)節(jié)點(diǎn)把它們的active類(lèi)全部移除再給當(dāng)前索引的圓點(diǎn)加上即可。有個(gè)細(xì)節(jié)值得留意——當(dāng)索引走到最后一張時(shí)點(diǎn)擊下一張要回到第一張而不是卡住不動(dòng)。很多人就是這個(gè)邊界條件沒(méi)寫(xiě)對(duì)運(yùn)行到末尾就報(bào)錯(cuò)了。倒計(jì)時(shí)的實(shí)現(xiàn)則是典型的“時(shí)間計(jì)算”題目。思路很固定先拿到目標(biāo)時(shí)間的時(shí)間戳然后每次定時(shí)器觸發(fā)時(shí)用目標(biāo)時(shí)間戳減去當(dāng)前時(shí)間戳所得差值再拆分成天、小時(shí)、分鐘、秒分別填充到頁(yè)面上對(duì)應(yīng)的位置。需要注意的是如果差值出現(xiàn)負(fù)數(shù)要清除定時(shí)器并把倒計(jì)時(shí)文本置為“活動(dòng)已結(jié)束”這是題目里很喜歡埋的一個(gè)考點(diǎn)。4. JavaScript邏輯題的現(xiàn)場(chǎng)解法與易錯(cuò)點(diǎn)4.1 事件監(jiān)聽(tīng)和數(shù)據(jù)聯(lián)動(dòng)先畫(huà)數(shù)據(jù)流再動(dòng)鍵盤(pán)JavaScript邏輯題里事件聯(lián)動(dòng)是最常見(jiàn)的。我拿到題第一反應(yīng)不是看按鈕而是先把數(shù)據(jù)流向捋清楚。所謂數(shù)據(jù)流就是“什么數(shù)據(jù)從哪里來(lái) → 經(jīng)過(guò)什么處理 → 渲染到頁(yè)面的哪個(gè)位置”。有一道題是這樣的某個(gè)頁(yè)面上有三段可選的城市信息點(diǎn)擊不同城市右側(cè)要顯示對(duì)應(yīng)城市的天氣數(shù)據(jù)。核心邏輯就是一個(gè)函數(shù)function renderWeather(cityId) { // 從數(shù)據(jù)源中取出對(duì)應(yīng)城市的數(shù)據(jù)更新DOM }。然后給每個(gè)城市選項(xiàng)綁定click事件事件回調(diào)里調(diào)用renderWeather(當(dāng)前點(diǎn)擊的城市ID)。這里面有兩個(gè)常見(jiàn)坑第一個(gè)是事件綁定時(shí)機(jī)。如果頁(yè)面節(jié)點(diǎn)是JavaScript動(dòng)態(tài)生成的那么你在初始狀態(tài)下直接去綁定事件很可能綁不上因?yàn)樵剡€不存在。正確的做法是在生成DOM之前就把事件綁定寫(xiě)好或者用事件委托的方式監(jiān)聽(tīng)父容器。第13屆的一道題就考了這個(gè)點(diǎn)——有一個(gè)列表是通過(guò)接口數(shù)據(jù)渲染的列表每一項(xiàng)都有一個(gè)刪除按鈕刪除按鈕的點(diǎn)擊事件必須通過(guò)事件委托才能正確綁定。其實(shí)思路不難給列表的父容器加一個(gè)addEventListener(click, fn)然后通過(guò)event.target去判斷點(diǎn)的是不是刪除按鈕。第二個(gè)是重復(fù)渲染導(dǎo)致的事件疊加。如果你用一個(gè)renderList()函數(shù)反復(fù)渲染列表而渲染時(shí)每個(gè)節(jié)點(diǎn)都通過(guò)addEventListener綁定了同樣的事件那多次渲染之后同一個(gè)動(dòng)作可能會(huì)觸發(fā)多次回調(diào)。解決這個(gè)問(wèn)題的方式有兩個(gè)要么在渲染前清空容器內(nèi)容innerHTML 要么在綁定事件前先移除舊事件。第一種方式更常用也更穩(wěn)。有些數(shù)據(jù)聯(lián)動(dòng)題還有一種形式點(diǎn)擊按鈕A之后按鈕B的禁用態(tài)要切換。比如表單里未勾選協(xié)議時(shí)提交按鈕是置灰狀態(tài)勾選后才變亮。這種邏輯非常簡(jiǎn)單核心是按鈕的disabled屬性配合一個(gè)狀態(tài)變量每次狀態(tài)變化時(shí)執(zhí)行一次“更新按鈕狀態(tài)”的函數(shù)即可。這種題是純粹的送分題見(jiàn)到別慌直接按布爾變量控制就行。4.2 防抖與節(jié)流賽場(chǎng)上最容易被問(wèn)到的隱藏考點(diǎn)第13屆JavaScript題有一道讓我印象比較深要求實(shí)現(xiàn)一個(gè)“搜索框輸入防抖”的功能。題目很直白——用戶(hù)在輸入框中輸入關(guān)鍵詞不需要每次都觸發(fā)搜索請(qǐng)求而是等用戶(hù)停止輸入300毫秒后再觸發(fā)。這就是標(biāo)準(zhǔn)的前端防抖場(chǎng)景。防抖的核心思想是“延遲執(zhí)行若在延遲期間再次觸發(fā)則重新計(jì)時(shí)”。現(xiàn)場(chǎng)代碼我可以給個(gè)示意let timer null; searchInput.addEventListener(input, function () { clearTimeout(timer); timer setTimeout(() { // 這里執(zhí)行真正的搜索邏輯 doSearch(searchInput.value); }, 300); });有些同學(xué)會(huì)在函數(shù)外面定義定時(shí)器變量時(shí)忘了加let導(dǎo)致變量污染到全局作用域比賽環(huán)境中有可能和其他腳本沖突。寫(xiě)的時(shí)候注意作用域問(wèn)題最好把整個(gè)防抖邏輯包在一個(gè)函數(shù)里。還有一道題是“滾動(dòng)加載更多”的場(chǎng)景這就要用到節(jié)流。節(jié)流的核心思想是“在一段時(shí)間內(nèi)只觸發(fā)一次”。舉例來(lái)說(shuō)監(jiān)聽(tīng)滾動(dòng)事件時(shí)如果每滾動(dòng)一像素就執(zhí)行一次數(shù)據(jù)處理性能會(huì)非常差所以要限定在200毫秒內(nèi)只執(zhí)行一次。經(jīng)典寫(xiě)法是用一個(gè)標(biāo)志位let isLoading false; window.addEventListener(scroll, function () { if (isLoading) return; if (window.innerHeight window.scrollY document.body.offsetHeight - 100) { isLoading true; // 觸發(fā)加載更多... setTimeout(() { isLoading false; }, 500); } });判斷是否滾動(dòng)到底部這個(gè)條件很多同學(xué)記不牢。拆開(kāi)來(lái)看就三層當(dāng)前視口高度window.innerHeight、已經(jīng)滾出視口的高度window.scrollY、整個(gè)文檔的高度document.body.offsetHeight。當(dāng)“視口底部”距離“文檔底部”小于某個(gè)閾值時(shí)就觸發(fā)加載。這里要提醒一句如果用document.documentElement.scrollHeight而不是document.body.offsetHeight在某些瀏覽器下數(shù)值會(huì)不一樣最好兩種都試一次以能觸發(fā)為準(zhǔn)。4.3 數(shù)據(jù)格式化時(shí)間戳、金額、數(shù)字的常見(jiàn)處理細(xì)節(jié)第13屆的數(shù)據(jù)處理題里時(shí)間和金額的處理是高頻考點(diǎn)。時(shí)間戳格式化是前端業(yè)務(wù)里最常見(jiàn)的操作但很多同學(xué)在比賽時(shí)手寫(xiě)格式化函數(shù)容易磨蹭。我這邊有個(gè)模板可以直接背下來(lái)function formatTime(timestamp) { const date new Date(timestamp); const y date.getFullYear(); const m String(date.getMonth() 1).padStart(2, 0); const d String(date.getDate()).padStart(2, 0); const hh String(date.getHours()).padStart(2, 0); const mm String(date.getMinutes()).padStart(2, 0); const ss String(date.getSeconds()).padStart(2, 0); return ${y}-${m}-$7jrgojewd9zx ${hh}:${mm}:${ss}; }注意getMonth()返回的月份是從0開(kāi)始的所以一定要加1padStart(2, 0)是補(bǔ)齊兩位數(shù)的好幫手比三目運(yùn)算符清爽多了。金額格式化這道題里常常要求“千分位分隔”比如把1234567顯示成1,234,567?，F(xiàn)場(chǎng)手寫(xiě)這個(gè)正則表達(dá)式如果你不熟的話(huà)我建議直接用toLocaleString(en-US)一秒鐘搞定。有些同學(xué)擔(dān)心這個(gè)方法在小數(shù)位上表現(xiàn)不同其實(shí)題目給的數(shù)據(jù)基本都是整數(shù)金額toLocaleString的表現(xiàn)足夠。萬(wàn)一遇到比較大的小數(shù)精度要求也可以用Number.prototype.toFixed(2)搭配正則——但這屬于進(jìn)階操作平時(shí)練習(xí)可以準(zhǔn)備一下比賽時(shí)優(yōu)先用什么簡(jiǎn)單用什么。還有一類(lèi)是排序。第13屆有一道題讓按價(jià)格從低到高排序商品如果價(jià)格相同再按銷(xiāo)量從高到低排。這就是典型的多條件排序代碼只需要一行l(wèi)ist.sort((a, b) a.price - b.price || b.sales - a.sales);注意sort的排序規(guī)則返回值小于0表示a排在b前面大于0表示a排在b后面。如果沒(méi)有掌握這一點(diǎn)很容易把升序降序?qū)懛础６襰ort是原地排序如果你不想改變?cè)瓟?shù)組要先[...list].sort(...)再返回。4.4 接口數(shù)據(jù)的獲取模擬請(qǐng)求與異步處理的現(xiàn)場(chǎng)寫(xiě)法藍(lán)橋杯Web賽道里通常不會(huì)真的讓你發(fā)HTTP請(qǐng)求數(shù)據(jù)一般會(huì)以“模擬接口”的形式出現(xiàn)比如getData()返回一個(gè)Promise對(duì)象。你要做的就是調(diào)用這個(gè)函數(shù)處理返回的數(shù)據(jù)渲染到頁(yè)面上。這里考的其實(shí)就是Promise和async/await的用法。我的建議是能寫(xiě)async/await就別寫(xiě).then()鏈因?yàn)榍罢唛喿x起來(lái)更直觀(guān)代碼也更短。現(xiàn)場(chǎng)模板可以這么寫(xiě)async function loadData() { const res await getData(); const list res.data || []; renderList(list); }需要注意的一點(diǎn)異步數(shù)據(jù)返回之后要判斷數(shù)據(jù)結(jié)構(gòu)是否符合預(yù)期。有時(shí)候接口返回的是{code: 0, data: [...]}這樣的包裝格式你得先解構(gòu)出真正的數(shù)據(jù)數(shù)組。如果你不知道返回結(jié)構(gòu)最穩(wěn)妥的辦法是先在控制臺(tái)里console.log(res)看一眼再寫(xiě)后續(xù)代碼——不要憑感覺(jué)去猜字段名因?yàn)槠村e(cuò)一個(gè)字母你可能花十分鐘也查不出來(lái)。渲染的時(shí)候還涉及一個(gè)“加載中/加載失敗”的反饋。藍(lán)橋杯的題目框架里有時(shí)已經(jīng)寫(xiě)好了加載狀態(tài)容器你需要根據(jù)異步執(zhí)行的結(jié)果動(dòng)態(tài)切換文案。比如加載中顯示“加載中...”成功渲染數(shù)據(jù)失敗顯示“加載失敗請(qǐng)重試”。這種細(xì)節(jié)雖然不至于扣大分但判斷系統(tǒng)是按點(diǎn)給分少一個(gè)環(huán)節(jié)就少一分能寫(xiě)就寫(xiě)上。5. 綜合實(shí)戰(zhàn)一道貼近真實(shí)的“數(shù)據(jù)看板”題全程復(fù)盤(pán)第13屆藍(lán)橋杯Web賽道里有一道綜合應(yīng)用題讓我印象很深題目叫“銷(xiāo)售數(shù)據(jù)看板”本質(zhì)上就是一個(gè)帶數(shù)據(jù)的可視化頁(yè)面。這里我把當(dāng)時(shí)的解題全程復(fù)盤(pán)一遍你就能知道一道綜合題從讀題到寫(xiě)完代碼應(yīng)該怎么分配精力。題目描述大概是這樣的頁(yè)面上方是兩個(gè)統(tǒng)計(jì)卡片總銷(xiāo)售額、訂單總數(shù)中間是一個(gè)圖表下方是一個(gè)七天的銷(xiāo)售明細(xì)表格。題目給了salesData數(shù)組里面是7天數(shù)據(jù)每天有日期、銷(xiāo)售額、訂單量這三個(gè)字段。要求你自動(dòng)計(jì)算出總銷(xiāo)售額和訂單總數(shù)顯示在統(tǒng)計(jì)卡片上把七天的數(shù)據(jù)渲染到表格里用圖表展示七天銷(xiāo)售額的變化趨勢(shì)。第一步是讀題和數(shù)據(jù)預(yù)判。我拿到題先看了salesData的字段結(jié)構(gòu)確認(rèn)日期是字符串2023-04-01、銷(xiāo)售額是數(shù)值、訂單量是整數(shù)。接著看HTML部分發(fā)現(xiàn)統(tǒng)計(jì)卡片的數(shù)值區(qū)域是一個(gè)空span表格的tbody是空的圖表容器也是一個(gè)空div。整道題的框架非常清晰就是三個(gè)“填空”填數(shù)據(jù)、填表格、填圖表。第二步是計(jì)算匯總數(shù)據(jù)。這是一個(gè)非常典型的reduce操作我對(duì)salesData做了遍歷累加同時(shí)保留原始數(shù)組用于表格渲染const totalSales salesData.reduce((sum, item) sum item.salesAmount, 0); const totalOrders salesData.reduce((sum, item) sum item.orderCount, 0);把這兩個(gè)值通過(guò)textContent賦值到對(duì)應(yīng)的DOM節(jié)點(diǎn)上。這里有個(gè)小細(xì)節(jié)銷(xiāo)售額的數(shù)值設(shè)定很大幾千幾萬(wàn)顯示的時(shí)候要加個(gè)單位或者千分位我在數(shù)值后面拼了一個(gè)“元”字看起來(lái)更自然。有些同學(xué)直接把數(shù)字塞進(jìn)去頁(yè)面上光禿禿的數(shù)字不夠美觀(guān)在自動(dòng)判定里不算錯(cuò)但如果你面對(duì)的是人工復(fù)核環(huán)節(jié)觀(guān)感就會(huì)差一些。第三步是表格渲染。還是老思路用map生成表格行再一次性插入tbody。這里要把日期格式化一下原始數(shù)據(jù)是2023-04-01可以直接用也可以轉(zhuǎn)成04月01日這種更直觀(guān)的格式。題目沒(méi)有強(qiáng)制要求我就按原樣輸出了省時(shí)間。第四步是圖表繪制。題目框架里已經(jīng)引入了一個(gè)柱狀圖的庫(kù)我看了一眼文檔知道它的配置項(xiàng)大概長(zhǎng)什么樣就直接用庫(kù)的接口傳數(shù)據(jù)了。這類(lèi)庫(kù)通常需要一個(gè)series數(shù)組里面每項(xiàng)是{ name: 銷(xiāo)售額, data: [100, 200, ...] }。我的處理方式很簡(jiǎn)單先map出七天的salesAmount數(shù)組作為data再把日期數(shù)組作為xAxis的labels傳入。這里想提醒大家遇到圖表庫(kù)不要慌先在控制臺(tái)打印一下庫(kù)對(duì)象看看全局變量的名字是什么再?lài)L試調(diào)用。很多圖表庫(kù)需要你先初始化一個(gè)實(shí)例傳入的第二個(gè)參數(shù)是配置對(duì)象最小配置也要有xAxis、yAxis和series三項(xiàng)。如果圖表沒(méi)顯示出來(lái)優(yōu)先檢查三項(xiàng)是否齊全、數(shù)據(jù)格式是否匹配。這道題整個(gè)寫(xiě)下來(lái)大概是40分鐘我對(duì)自己的要求是——先用25分鐘把數(shù)據(jù)和表格渲染全部搞定再用10分鐘去摸索圖表庫(kù)的配置剩下5分鐘復(fù)查邊界。如果圖表庫(kù)確實(shí)用不明白也不至于把前面已經(jīng)拿到的分丟了。6. 時(shí)間分配與考場(chǎng)做題順序的實(shí)戰(zhàn)建議第13屆藍(lán)橋杯Web賽道的4個(gè)小時(shí)從我的實(shí)際體驗(yàn)來(lái)看前半小時(shí)基本屬于“讀題-選題-熱身”最后半小時(shí)屬于“復(fù)查-修復(fù)-提交”真正高效寫(xiě)代碼的時(shí)間大約3小時(shí)。所以做題順序非常關(guān)鍵直接影響到你能拿到多少分。我的做題順序策略是按“保分優(yōu)先”的原則排的。先做界面還原題因?yàn)檫@類(lèi)題目只要花時(shí)間寫(xiě)了基本就有分再去做JavaScript交互題把邏輯分拿到然后才輪到綜合應(yīng)用和數(shù)據(jù)可視化這類(lèi)題上限高但不確定性強(qiáng)最后留半小時(shí)統(tǒng)一復(fù)查。具體時(shí)間分配可以參考這個(gè)方案讀題選題期15分鐘把6道題全部快速瀏覽一遍按“難度預(yù)估分值預(yù)估”給每道題打一個(gè)性?xún)r(jià)比標(biāo)簽。第1道界面還原題50分鐘分值最高值得投入。第2道界面還原題40分鐘如果兩道還原題難度差異不大第二道可以適當(dāng)壓縮時(shí)間。JavaScript交互題2道60分鐘每道30分鐘重點(diǎn)保證數(shù)據(jù)邏輯正確。綜合應(yīng)用題60分鐘數(shù)據(jù)可視化能做完數(shù)據(jù)渲染就已經(jīng)贏(yíng)了一半。復(fù)查期15分鐘優(yōu)先檢查所有控制臺(tái)的報(bào)錯(cuò)其次檢查頁(yè)面布局有沒(méi)有明顯錯(cuò)位最后再摳樣式細(xì)節(jié)。這個(gè)方案不是死的你可以根據(jù)自己的強(qiáng)項(xiàng)調(diào)整。但有一個(gè)原則值得守住不要把一道題卡超過(guò)20分鐘。藍(lán)橋杯Web賽道每道題的分值是遞增的前面簡(jiǎn)單的題可能10分、15分后面大題可能30分。如果你在一道15分的題上卡了半小時(shí)哪怕最后做出來(lái)了也相當(dāng)于賠掉了后面一道30分題的思考時(shí)間。還有一個(gè)考場(chǎng)心態(tài)的問(wèn)題。比賽時(shí)看到別人敲鍵盤(pán)飛快你心里可能會(huì)焦慮。但實(shí)際上速度快不等于分?jǐn)?shù)高前期的花時(shí)間讀題和理解數(shù)據(jù)邏輯后期的調(diào)試效率才會(huì)高。我見(jiàn)過(guò)好幾個(gè)同學(xué)一上來(lái)就吭哧吭哧寫(xiě)代碼結(jié)果寫(xiě)到一半發(fā)現(xiàn)自己理解錯(cuò)了題目需求刪掉重來(lái)不僅浪費(fèi)時(shí)間還特別影響心態(tài)。讀題慢一點(diǎn)寫(xiě)題快一點(diǎn)復(fù)查細(xì)一點(diǎn)——這個(gè)節(jié)奏是拿分最穩(wěn)的。7. 藍(lán)橋杯Web賽道的高頻踩坑與查錯(cuò)方法論7.1 語(yǔ)法層面最容易忽略的報(bào)錯(cuò)陷阱第13屆的考試環(huán)境沒(méi)有VSCode那么聰明的代碼提示很多報(bào)錯(cuò)要靠刷新頁(yè)面看控制臺(tái)才知道。這里把高頻的語(yǔ)法陷阱整理一下全部中過(guò)招的同學(xué)可以對(duì)照自查第一是大小寫(xiě)。JavaScript對(duì)大小寫(xiě)敏感g(shù)etElementById和getElementByID完全是兩個(gè)函數(shù)。有的同學(xué)平時(shí)編輯器里打了一半靠自動(dòng)補(bǔ)全環(huán)境一變就很容易寫(xiě)錯(cuò)。我的建議是所有內(nèi)置API名稱(chēng)在敲的時(shí)候養(yǎng)成“全名輸入”的習(xí)慣不要只記個(gè)大概。第二是括號(hào)匹配。嵌套多層函數(shù)調(diào)用時(shí)一個(gè)括號(hào)漏了整個(gè)頁(yè)面可能白屏。平時(shí)練習(xí)建議用有括號(hào)高亮的編輯器比賽時(shí)如果環(huán)境沒(méi)有就養(yǎng)成寫(xiě)完一段函數(shù)后數(shù)一遍括號(hào)的習(xí)慣。其實(shí)這個(gè)方法特別笨但真的很有效。第三是變量作用域。藍(lán)橋杯Web賽道的代碼框架里有些變量是全局的有些限制在函數(shù)內(nèi)。如果你在一個(gè)函數(shù)里定義了變量卻在另一個(gè)函數(shù)里直接訪(fǎng)問(wèn)瀏覽器控制臺(tái)會(huì)報(bào)ReferenceError: xxx is not defined。比賽的判分系統(tǒng)往往會(huì)根據(jù)控制臺(tái)是否報(bào)錯(cuò)來(lái)扣分所以看到這類(lèi)報(bào)錯(cuò)一定要修復(fù)不要心存僥幸。7.2 邏輯層面代碼寫(xiě)出了頁(yè)面卻沒(méi)反應(yīng)有時(shí)候控制臺(tái)不報(bào)錯(cuò)但頁(yè)面沒(méi)有任何變化。這種情況下問(wèn)題大概率出在“執(zhí)行時(shí)機(jī)”和“元素是否存在”上。最常見(jiàn)的場(chǎng)景是script放在head里但代碼里直接document.getElementById(...)去操作body里的元素。此時(shí)body還沒(méi)解析到元素自然找不到返回null代碼就會(huì)報(bào)錯(cuò)或靜默失敗。解決辦法是如果代碼框架已經(jīng)是這個(gè)結(jié)構(gòu)就把執(zhí)行代碼包在window.addEventListener(DOMContentLoaded, () { ... })里確保DOM就緒后再執(zhí)行。還有一種場(chǎng)景是樣式寫(xiě)了但沒(méi)生效。比如設(shè)置display:none的元素你通過(guò)getComputedStyle去取它的寬高得到的是0再比如你給一個(gè)元素設(shè)置了position:absolute但它的父容器沒(méi)有設(shè)置position:relative元素就會(huì)相對(duì)整個(gè)頁(yè)面定位位置看起來(lái)很奇怪。遇到樣式問(wèn)題優(yōu)先在瀏覽器開(kāi)發(fā)者工具里看Computed面板哪些規(guī)則被覆蓋、哪些屬性沒(méi)生效一目了然。7.3 調(diào)試方法論控制臺(tái)是你最好的提分工具比賽時(shí)瀏覽器開(kāi)發(fā)者工具就是你最核心的調(diào)試助手。第13屆考試我?guī)缀跻恢遍_(kāi)著控制臺(tái)。這里分享幾個(gè)實(shí)用的調(diào)試技巧用console.log分階段確認(rèn)數(shù)據(jù)。每處理完一個(gè)環(huán)節(jié)打印一下當(dāng)前的數(shù)據(jù)確認(rèn)沒(méi)問(wèn)題再往下走。比如reduce完的總銷(xiāo)售額先打印看一眼是不是預(yù)期的數(shù)字再塞進(jìn)頁(yè)面。這樣可以直接定位到出錯(cuò)環(huán)節(jié)不用反復(fù)重啟頁(yè)面。善用“選中元素”功能。在Elements面板里點(diǎn)擊放大鏡圖標(biāo)然后在頁(yè)面上點(diǎn)你想檢查的元素控制臺(tái)就會(huì)自動(dòng)定位到它的代碼位置。右側(cè)的Styles面板會(huì)展示該元素所有命中的樣式和計(jì)算后的最終樣式排查邊框、尺寸、字體問(wèn)題時(shí)非常好用。Network面板雖然不那么常用但如果你的綜合應(yīng)用題里有異步數(shù)據(jù)請(qǐng)求打開(kāi)Network面板可以看到請(qǐng)求是否成功、返回了什么內(nèi)容。如果請(qǐng)求失敗往往是接口地址寫(xiě)錯(cuò)了或者模擬函數(shù)沒(méi)調(diào)用。第13屆里有個(gè)別題目的“接口”是延遲返回的需要在Network里確認(rèn)是否拿到了真正的數(shù)據(jù)。7.4 復(fù)盤(pán)一份“看似全對(duì)卻丟分”的答卷有一個(gè)同學(xué)的答卷讓我印象非常深頁(yè)面效果看起來(lái)和設(shè)計(jì)稿幾乎一模一樣數(shù)據(jù)渲染也在圖表也出來(lái)了最后得分卻比預(yù)期低了不少?；厝?fù)查代碼時(shí)發(fā)現(xiàn)了問(wèn)題所在。第一處丟分點(diǎn)圖片資源引的是外鏈比賽環(huán)境網(wǎng)絡(luò)受限圖片全都加載失敗只留下一個(gè)個(gè)空白的占位框。當(dāng)時(shí)他寫(xiě)CSS時(shí)沒(méi)有給圖片設(shè)置width、height屬性圖片加載失敗后容器塌縮導(dǎo)致頁(yè)面整體排版亂掉了。這是典型的“依賴(lài)外部資源”導(dǎo)致的丟分。第二處丟分點(diǎn)有一道JS題要求點(diǎn)擊某個(gè)按鈕后“防重復(fù)提交”他實(shí)現(xiàn)的時(shí)候只做了按鈕置灰但沒(méi)有在合適的時(shí)機(jī)恢復(fù)按鈕狀態(tài)。雖然頁(yè)面上沒(méi)報(bào)錯(cuò)但因?yàn)檫壿嫴煌暾麃G失了部分分值。這道題如果仔細(xì)看題目的需求描述會(huì)發(fā)現(xiàn)“防重復(fù)提價(jià)提交成功后可再次提價(jià)”是一個(gè)完整的閉環(huán)邏輯少一環(huán)都不夠嚴(yán)謹(jǐn)。第三處丟分點(diǎn)表格數(shù)據(jù)渲染時(shí)他把數(shù)字直接塞進(jìn)去了沒(méi)有做任何格式化。視覺(jué)上是對(duì)的但題目明確要求“金額保留兩位小數(shù)”他的實(shí)現(xiàn)不滿(mǎn)足這個(gè)約束又被扣了分。所以讀完題之后把所有“要求”圈出來(lái)逐條對(duì)照代碼一邊寫(xiě)一邊劃勾這樣是最不容易遺漏需求的。從這三個(gè)丟分點(diǎn)能看出來(lái)藍(lán)橋杯Web賽道很多時(shí)候不是難在技術(shù)深度而是難在需求完整度。代碼能跑通只是及格線(xiàn)按需求逐條驗(yàn)證才是拿高分的關(guān)鍵。8. 備考路徑從第13屆題目倒推下一屆的備戰(zhàn)重點(diǎn)如果你準(zhǔn)備參加下一屆藍(lán)橋杯Web賽道與其漫無(wú)目的地刷題不如從第13屆的題目風(fēng)格倒推備戰(zhàn)方向。這屆題目透露出的趨勢(shì)是界面還原依然是主線(xiàn)JS邏輯依然是基礎(chǔ)數(shù)據(jù)與交互的結(jié)合越來(lái)越緊密?；谶@些我建議備戰(zhàn)重點(diǎn)鎖定在以下幾個(gè)方面。第一是過(guò)一遍CSS布局全家桶。Flex和Grid必須非常熟練能夠看到設(shè)計(jì)稿快速搭建出布局。盒模型相關(guān)概念——border-box和content-box的區(qū)別、margin合并、子元素寬度溢出問(wèn)題這些都要在練習(xí)中反復(fù)遇到并解決。推薦的方式是找?guī)讉€(gè)中等復(fù)雜度的活動(dòng)頁(yè)設(shè)計(jì)稿設(shè)定一個(gè)半小時(shí)的還原時(shí)間然后反復(fù)對(duì)比和原稿的差異。第二是背熟JavaScript的數(shù)組方法。map、filter、reduce、sort、find、includes這些方法要能“不用查文檔就寫(xiě)出來(lái)”。藍(lán)橋杯Web賽道的數(shù)據(jù)處理題本質(zhì)上就是在考這些方法組合使用的能力。我當(dāng)時(shí)整理了一個(gè)小本子每個(gè)方法一頁(yè)紙左邊是定義右邊是使用場(chǎng)景和一個(gè)最小示例考前翻一翻非常有效。第三是練熟事件處理和數(shù)據(jù)渲染的搭配使用。尤其是“數(shù)據(jù)源渲染函數(shù)事件綁定”這種三段式結(jié)構(gòu)幾乎每場(chǎng)比賽都會(huì)出現(xiàn)。你只需要掌握一個(gè)模板然后在不同場(chǎng)景里不斷套用——初始數(shù)據(jù)渲染一次事件觸發(fā)后重新渲染渲染前清空舊內(nèi)容。把這個(gè)流程做成肌肉記憶能省下不少思考時(shí)間。第四是提升“讀別人代碼”的能力。多去分析一些開(kāi)源項(xiàng)目的結(jié)構(gòu)哪怕是簡(jiǎn)單的頁(yè)面去理解別人為什么那么寫(xiě)變量名、為什么把函數(shù)拆成小函數(shù)、為什么要寫(xiě)那么多判斷條件。比賽時(shí)讀題和讀代碼的速度很大程度上能決定你能不能提前做完。這不是天賦是刻意練習(xí)出來(lái)的。第五是模擬考試環(huán)境做套題。平時(shí)練習(xí)別總依賴(lài)代碼提示和自動(dòng)格式化試著干寫(xiě)代碼?？梢越o自己限時(shí)4小時(shí)在規(guī)定時(shí)間內(nèi)完成一套模擬題然后對(duì)照解析復(fù)盤(pán)。第一套做不完很正常第二套開(kāi)始有感覺(jué)到第三套基本就能找到自己的節(jié)奏了。藍(lán)橋杯Web賽道是一個(gè)熟能生巧的賽道知識(shí)點(diǎn)不會(huì)超綱太多熟練度決定成績(jī)上限。9. 寫(xiě)在最后的實(shí)操體會(huì)復(fù)盤(pán)第13屆藍(lán)橋杯Web賽道我最深的感受是這不是一場(chǎng)拼智力的比賽而是一場(chǎng)拼熟練度和體力的比賽?？碱}里沒(méi)有那種“想到了就會(huì)做想不到就卡死”的偏題怪題所有知識(shí)點(diǎn)都是日常前端開(kāi)發(fā)里真正在用的東西。所以備考策略其實(shí)很簡(jiǎn)單——多寫(xiě)代碼、多寫(xiě)帶場(chǎng)景的代碼、多寫(xiě)限時(shí)的代碼。我在比賽過(guò)程中也犯過(guò)一些小錯(cuò)誤比如有一道JS題我一開(kāi)始用錯(cuò)了事件名把input事件寫(xiě)成了change事件導(dǎo)致輸入框內(nèi)容變化時(shí)沒(méi)有觸發(fā)聯(lián)動(dòng)浪費(fèi)了五六分鐘才排查出來(lái)。還有一次是圖表的data數(shù)組長(zhǎng)度和xAxis長(zhǎng)度對(duì)不上圖表渲染出來(lái)少了一個(gè)點(diǎn)我盯著圖表數(shù)據(jù)看了半天才發(fā)現(xiàn)問(wèn)題。這些小失誤其實(shí)只要在寫(xiě)代碼前多看一眼需求、寫(xiě)完數(shù)據(jù)后多打印一次就完全能避免。如果你問(wèn)我下一屆的備考建議我會(huì)說(shuō)找一個(gè)下午設(shè)定4小時(shí)找一套往年的真題或者模擬題開(kāi)一個(gè)無(wú)插件、無(wú)提示的瀏覽器用記事本加瀏覽器控制臺(tái)去完成整套題。這個(gè)過(guò)程會(huì)很痛苦但它能非常真實(shí)地還原你在考場(chǎng)上的感受。藍(lán)橋杯Web賽道分?jǐn)?shù)高低的分水嶺從來(lái)不是誰(shuí)懂得多而是誰(shuí)在有限時(shí)間內(nèi)動(dòng)作更利索、思路更清晰。希望這份題解和復(fù)盤(pán)能幫你少走一些彎路。如果你打算參加下一屆比賽建議從今天開(kāi)始就照著上面列的方向做針對(duì)性練習(xí)。賽場(chǎng)上真正拉開(kāi)差距的不是天賦而是你在賽前已經(jīng)踩過(guò)多少坑、填過(guò)多少洞。這個(gè)賽道值得投入它能讓你在短時(shí)間內(nèi)把前端基本功壓得很扎實(shí)。