1. 用一個(gè)周末把博客站做出來(lái)原生 Web 三件套的取舍與邊界做個(gè)人博客系統(tǒng)頁(yè)面搭建這件事最容易被帶偏的地方不是寫(xiě)不出來(lái)而是還沒(méi)開(kāi)始就先把腳手架裝上。我見(jiàn)過(guò)太多人在第一步就卡住為了一個(gè)只有十幾篇文章的個(gè)人站裝 Node、配構(gòu)建、調(diào)依賴(lài)、處理版本沖突兩天過(guò)去首頁(yè)還是白屏。等你終于跑起來(lái)寫(xiě)文章的熱情已經(jīng)消耗掉一半。所以這次分享的方案很直接HTML 負(fù)責(zé)結(jié)構(gòu)、CSS 負(fù)責(zé)視覺(jué)、JavaScript 負(fù)責(zé)交互也就是常說(shuō)的 Web 三件套不引入任何框架和構(gòu)建工具雙擊index.html就能看效果扔進(jìn)任意靜態(tài)托管空間就能上線(xiàn)。這不是什么情懷而是對(duì)個(gè)人博客這個(gè)具體場(chǎng)景最合理的技術(shù)選擇。這篇文章要講的是一個(gè)完整的、能跑起來(lái)的個(gè)人博客系統(tǒng)頁(yè)面包含首頁(yè)文章列表、文章詳情頁(yè)、標(biāo)簽篩選、關(guān)鍵詞搜索、深淺色主題切換、文章目錄自動(dòng)高亮、代碼塊一鍵復(fù)制、移動(dòng)端響應(yīng)式適配這幾個(gè)模塊。文中的源碼可以直接拿走改也可以當(dāng)模板往上疊功能。適合的人群有三類(lèi)正在做課設(shè)或畢業(yè)設(shè)計(jì)、需要一個(gè)能看懂全流程的博客前端的同學(xué)想給自己的筆記找一個(gè)輕量展示出口、又不想維護(hù)復(fù)雜工程的開(kāi)發(fā)者以及已經(jīng)用過(guò)框架但想搞清楚那些框架幫你做的事具體是怎么實(shí)現(xiàn)的同行。如果你屬于第三類(lèi)后面的原生 DOM 渲染、狀態(tài)持久化、滾動(dòng)監(jiān)聽(tīng)那幾段會(huì)更有味道。1.1 這套方案能撐住什么撐不住什么先把邊界說(shuō)清楚免得你照著做完發(fā)現(xiàn)期望錯(cuò)位。原生三件套的個(gè)人博客系統(tǒng)舒適區(qū)是靜態(tài)內(nèi)容 少量交互文章數(shù)量在幾十到一兩百篇之間更新頻率不高不需要登錄和后臺(tái)不需要實(shí)時(shí)評(píng)論和協(xié)同編輯。在這個(gè)范圍內(nèi)它的優(yōu)勢(shì)非常明顯——首屏只有三個(gè)請(qǐng)求HTML、CSS、JS沒(méi)有任何運(yùn)行時(shí)開(kāi)銷(xiāo)加載速度比大部分框架站點(diǎn)都快而且十年后你回來(lái)改它依然能一眼看懂。不舒適的地方也要提前承認(rèn)。文章正文如果多到幾百篇把所有內(nèi)容塞進(jìn)一個(gè) JS 文件會(huì)導(dǎo)致首屏加載的文件體積過(guò)大這時(shí)候就需要按需加載或者干脆改成分頁(yè)。另外原生方案沒(méi)有組件復(fù)用機(jī)制如果你希望頁(yè)頭、頁(yè)腳、側(cè)邊欄在多頁(yè)面間保持一致要么復(fù)制粘貼要么用一小段 JS 在頁(yè)面加載時(shí)注入公共片段——文中的做法是后者。最后一個(gè)限制是 SEO純前端渲染的內(nèi)容對(duì)搜索引擎的友好度不如服務(wù)端直出不過(guò)對(duì)個(gè)人博客來(lái)說(shuō)真正重要的那幾十篇文章完全可以用靜態(tài) HTML 單獨(dú)生成一份這個(gè)后面會(huì)講。提示判斷要不要上框架我自己的標(biāo)準(zhǔn)是交互狀態(tài)是否復(fù)雜到需要統(tǒng)一狀態(tài)管理。博客站的交互狀態(tài)只有當(dāng)前主題、當(dāng)前篩選標(biāo)簽、當(dāng)前搜索詞這三個(gè)塞進(jìn)閉包變量就夠了沒(méi)必要為此引入一整套響應(yīng)式系統(tǒng)。1.2 目錄結(jié)構(gòu)三件套也要有工程感雖然不用構(gòu)建工具但文件劃分不能亂。亂放的后果是三個(gè)月后你想加個(gè)功能得先花半小時(shí)回憶哪個(gè)文件負(fù)責(zé)什么。我采用的是下面這種扁平結(jié)構(gòu)沒(méi)有任何深層嵌套看一眼就知道東西在哪blog/ ├── index.html # 首頁(yè)文章列表 ├── post.html # 文章詳情頁(yè) ├── about.html # 關(guān)于頁(yè) ├── css/ │ ├── reset.css # 歸零樣式 │ └── style.css # 主題變量與全站樣式 ├── js/ │ ├── theme.js # 主題切換放 head 里同步執(zhí)行 │ ├── data.js # 文章數(shù)據(jù) │ ├── list.js # 列表頁(yè)渲染與篩選 │ ├── post.js # 詳情頁(yè)渲染與目錄高亮 │ └── common.js # 公共片段注入、回到頂部 └── assets/ └── avatar.jpg這里有一個(gè)關(guān)鍵決定theme.js必須放在head里并且同步執(zhí)行不能加defer也不能挪到/body前面。原因是瀏覽器解析到style后就會(huì)開(kāi)始渲染如果這時(shí)候>// js/data.js const POSTS [ { id: build-blog-with-vanilla-js, title: 用原生三件套搭一個(gè)博客站, date: 2024-05-18, tags: [前端, 實(shí)戰(zhàn)], summary: 不裝框架從零搭出可用的博客頁(yè)面包含列表、詳情、篩選與主題切換。, content: p這里是正文可以用 HTML 片段直接書(shū)寫(xiě)。/p h2第一個(gè)小標(biāo)題/h2 p正文內(nèi)容……/p }, { id: css-variables-notes, title: CSS 變量的幾個(gè)實(shí)用姿勢(shì), date: 2024-06-02, tags: [CSS, 筆記](méi), summary: 用一套變量撐起整站配色與間距改一處全站生效。, content: p正文內(nèi)容……/p } ];注意content字段里我存的是 HTML 字符串而不是 Markdown。這個(gè)選擇有取舍存 HTML 意味著寫(xiě)作時(shí)得手寫(xiě)標(biāo)簽但省掉了在瀏覽器里跑 Markdown 解析器這一整套東西頁(yè)面加載更快也不會(huì)有解析失敗的風(fēng)險(xiǎn)。如果你更習(xí)慣 Markdown可以在構(gòu)建階段比如用一段 Node 腳本把.md轉(zhuǎn)成 HTML 再寫(xiě)進(jìn)data.js開(kāi)發(fā)體驗(yàn)和運(yùn)行性能都不犧牲。2. 頁(yè)面骨架從內(nèi)容模型倒推 HTML 標(biāo)簽怎么寫(xiě)寫(xiě) HTML 最常見(jiàn)的錯(cuò)誤是想到哪寫(xiě)到哪先把 div 堆起來(lái)再想每個(gè) div 裝什么。這樣寫(xiě)出來(lái)的結(jié)構(gòu)后面加功能時(shí)會(huì)特別難受因?yàn)槟悴恢雷约涸撏膫€(gè)層級(jí)的哪個(gè)節(jié)點(diǎn)掛事件。我的做法是先畫(huà)數(shù)據(jù)流一篇文章在列表頁(yè)要展示標(biāo)題、日期、標(biāo)簽、摘要四項(xiàng)在詳情頁(yè)要展示標(biāo)題、日期、標(biāo)簽、正文、目錄五項(xiàng)。把這十個(gè)信息點(diǎn)列出來(lái)HTML 結(jié)構(gòu)基本上就定型了剩下的只是給它們找個(gè)合適的容器。2.1 首頁(yè)列表的骨架首頁(yè)的職責(zé)很單一把文章按時(shí)間倒序排出來(lái)并提供篩選和搜索入口。所以結(jié)構(gòu)上分成三段——頂部導(dǎo)航、篩選區(qū)、文章列表。篩選區(qū)里的標(biāo)簽按鈕不是寫(xiě)死的而是由 JS 從數(shù)據(jù)里把所有tags去重后自動(dòng)生成這樣你新增一篇文章、打了個(gè)新標(biāo)簽篩選欄里就會(huì)自動(dòng)多出來(lái)一個(gè)按鈕不用回來(lái)改 HTML。!DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1 / title我的博客/title link relstylesheet href./css/reset.css / link relstylesheet href./css/style.css / script src./js/theme.js/script /head body header classsite-header a classlogo href./index.html我的博客/a nav classsite-nav a href./index.html首頁(yè)/a a href./about.html關(guān)于/a button idthemeToggle classicon-btn typebutton aria-label切換主題主題/button /nav /header main classcontainer section classtoolbar input idsearchInput classsearch typesearch placeholder搜索標(biāo)題或摘要 / div idtagBar classtag-bar/div /section section idpostList classpost-list aria-livepolite/section p idemptyTip classempty-tip hidden沒(méi)有匹配的文章/p /main footer classsite-footer p? span idyear/span 我的博客/p /footer script src./js/data.js/script script src./js/common.js/script script src./js/list.js/script /body /htmlaria-livepolite這個(gè)屬性值得單獨(dú)說(shuō)一句。它告訴屏幕閱讀器這塊區(qū)域的內(nèi)容會(huì)動(dòng)態(tài)變化變化后請(qǐng)朗讀出來(lái)。搜索時(shí)列表被替換加了這個(gè)屬性視障用戶(hù)就能聽(tīng)到結(jié)果條數(shù)的變化。加它只花兩秒鐘但這就是能用和好用之間的差別。span idyear/span也是同樣的思路頁(yè)腳年份交給 JS 填省得每年一月回來(lái)手動(dòng)改一次。2.2 詳情頁(yè)的骨架與目錄容器詳情頁(yè)比列表頁(yè)多一個(gè)東西右側(cè)的目錄Table of Contents。目錄的每個(gè)條目對(duì)應(yīng)正文里的一個(gè)標(biāo)題點(diǎn)擊可以跳轉(zhuǎn)滾動(dòng)時(shí)會(huì)自動(dòng)高亮當(dāng)前所在章節(jié)。要讓它工作正文里的每個(gè)標(biāo)題必須有穩(wěn)定的id而且這個(gè)id不能手寫(xiě)——手寫(xiě)遲早會(huì)漏、會(huì)重復(fù)。所以我在渲染正文之后用 JS 掃描一遍所有h2和h3給沒(méi)id的自動(dòng)補(bǔ)一個(gè)同時(shí)生成目錄數(shù)據(jù)。main classcontainer post-layout article classpost h1 idpostTitle/h1 div classpost-meta time idpostDate/time span idpostTags classtag-bar/span /div div idpostContent classpost-content/div /article aside classpost-toc p classtoc-title目錄/p nav idtocList/nav /aside /main頁(yè)面怎么知道該顯示哪篇文章用的是 URL 查詢(xún)參數(shù)形如post.html?idbuild-blog-with-vanilla-js。相比 hash 路由查詢(xún)參數(shù)的好處是分享鏈接更直觀而且在部分靜態(tài)托管平臺(tái)上同一路徑帶不同參數(shù)不會(huì)被當(dāng)成不同頁(yè)面重復(fù)收錄。讀取只需要一行const id new URLSearchParams(location.search).get(id); const post POSTS.find(p p.id id);如果post是undefined比如用戶(hù)手動(dòng)改了參數(shù)頁(yè)面會(huì)顯示一個(gè)文章不存在的提示并給個(gè)返回首頁(yè)的按鈕。這個(gè)兜底邏輯很多人不寫(xiě)結(jié)果訪(fǎng)問(wèn)一個(gè)失效鏈接就是滿(mǎn)屏空白體驗(yàn)很差。2.3 語(yǔ)義化標(biāo)簽帶來(lái)的實(shí)際好處有人覺(jué)得用div加 class 和用section、article、nav沒(méi)什么區(qū)別反正樣式都靠自己寫(xiě)。短期看確實(shí)沒(méi)區(qū)別但有兩個(gè)場(chǎng)景會(huì)立刻體現(xiàn)出差異。第一是屏幕閱讀器用戶(hù)可以按快捷鍵在各個(gè) landmark 之間跳轉(zhuǎn)直接跳到正文或者導(dǎo)航第二是你在瀏覽器里打開(kāi)閱讀模式語(yǔ)義良好的頁(yè)面能被正確識(shí)別出正文和標(biāo)題層級(jí)語(yǔ)義混亂的頁(yè)面提取出來(lái)的內(nèi)容會(huì)夾雜導(dǎo)航和頁(yè)腳。我在這個(gè)項(xiàng)目里的語(yǔ)義約定是站點(diǎn)級(jí)的頭部用header主導(dǎo)航用nav主要內(nèi)容用main每篇文章用article相關(guān)的一組內(nèi)容用section頁(yè)腳用footer。標(biāo)題層級(jí)嚴(yán)格不跳級(jí)——詳情頁(yè)的h1是文章標(biāo)題正文里的章節(jié)從h2開(kāi)始子節(jié)用h3。順帶一提正文的h2不要從h3起步否則目錄生成出來(lái)會(huì)缺一層視覺(jué)上也奇怪。3. 樣式層一套 CSS 自定義屬性撐起整站視覺(jué)CSS 部分我踩過(guò)的最大彎路是邊寫(xiě)邊定顏色。寫(xiě)到一半發(fā)現(xiàn)某個(gè)灰不好看回去全局替換換了七八處之后發(fā)現(xiàn)漏了兩處頁(yè)面上的灰色變得深淺不一。后來(lái)統(tǒng)一改成先在:root里定變量所有地方只引用變量這個(gè)問(wèn)題就徹底消失了。這不只是省事的問(wèn)題它還讓暗色模式這種需要整體換色的需求變得極其簡(jiǎn)單——只要重新定義一組變量值所有引用變量的地方自動(dòng)跟著變。3.1 變量命名與配色約定變量命名我采用用途 變體的方式而不是顏色 深淺。--brand比--blue-500好因?yàn)閷?lái)你把品牌色改成綠色的時(shí)候不需要把變量名和它的含義一起改。下面這套是我用得比較順手的配置可以直接抄:root { --bg: #ffffff; --bg-soft: #f6f7f9; --text: #1f2328; --text-soft: #5b6472; --border: #e3e6ea; --brand: #2f6fed; --code-bg: #f3f4f6; --radius: 10px; --maxw: 860px; --space-1: 4px; --space-2: 8px; --space-3: 16px; --space-4: 24px; --space-5: 40px; --font-sans: -apple-system, BlinkMacSystemFont, Segoe UI, PingFang SC, Microsoft YaHei, sans-serif; --font-mono: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; } html[data-themedark] { --bg: #14171a; --bg-soft: #1b1f23; --text: #e6e8eb; --text-soft: #9aa4b2; --border: #2a2f36; --brand: #6ea8fe; --code-bg: #1e2227; }間距變量按 4 的倍數(shù)遞增不是強(qiáng)迫癥而是因?yàn)?8px 的倍數(shù)在雙眼屏和高分屏上都不會(huì)出現(xiàn)半像素模糊。字號(hào)我沒(méi)有做成變量因?yàn)椴┛驼镜淖痔?hào)層級(jí)非常固定把它變量化反而增加閱讀成本正文 17px、行高 1.75、小標(biāo)題 1.4 倍、文章大標(biāo)題 2 倍這幾個(gè)數(shù)字寫(xiě)死在樣式里就夠了。--font-sans里把系統(tǒng)字體放在最前面是為了讓中文和英文都優(yōu)先使用系統(tǒng)自帶字體。這樣做的好處是頁(yè)面不依賴(lài)任何外部字體文件沒(méi)有字體加載導(dǎo)致的文字閃爍首屏渲染速度也更快。macOS 上會(huì)命中蘋(píng)方Windows 上會(huì)命中微軟雅黑視覺(jué)上略有差異但對(duì)個(gè)人博客來(lái)說(shuō)完全可接受。3.2 Grid 和 Flex 各自負(fù)責(zé)什么布局這件事Flex 和 Grid 的分工要明確混著用會(huì)讓代碼越來(lái)越亂。我的原則很簡(jiǎn)單一維排列用 Flex二維布局用 Grid。導(dǎo)航欄的 logo 和菜單是橫向一維排列用 Flex首頁(yè)的文章列表是一維垂直堆疊也可以用 Flex 或者直接塊級(jí)元素詳情頁(yè)的正文 側(cè)邊目錄是兩列布局這是二維用 Grid。.container { width: 100%; max-width: var(--maxw); margin: 0 auto; padding: 0 var(--space-3); } /* 詳情頁(yè)兩列布局正文自適應(yīng)目錄固定寬 */ .post-layout { display: grid; grid-template-columns: minmax(0, 1fr) 200px; gap: var(--space-5); align-items: start; } /* 小屏收成一列目錄挪到正文下方 */ media (max-width: 900px) { .post-layout { grid-template-columns: 1fr; gap: var(--space-3); } .post-toc { order: 2; } }這里有兩個(gè)容易忽略的點(diǎn)。第一grid-template-columns里用的是minmax(0, 1fr)而不是1fr。區(qū)別在于1fr的最小值是auto如果正文里有一個(gè)超長(zhǎng)的代碼塊或者一張大圖它會(huì)把整個(gè)網(wǎng)格撐寬導(dǎo)致橫向滾動(dòng)條出現(xiàn)寫(xiě)成minmax(0, 1fr)就把最小值壓到 0超出部分交給代碼塊自己的滾動(dòng)條處理。第二align-items: start讓兩側(cè)內(nèi)容都頂對(duì)齊否則目錄會(huì)被拉伸到和正文一樣高看起來(lái)很奇怪。文章列表項(xiàng)的布局則用 Flex因?yàn)樗亲筮厓?nèi)容自適應(yīng)、右邊日期固定寬的一維結(jié)構(gòu).post-item { display: flex; justify-content: space-between; align-items: baseline; gap: var(--space-3); padding: var(--space-3) 0; border-bottom: 1px solid var(--border); } .post-item .title { flex: 1; min-width: 0; } .post-item time { flex: none; color: var(--text-soft); font-size: 14px; }min-width: 0又是同一個(gè)坑的另一面Flex 子項(xiàng)默認(rèn)最小寬度是內(nèi)容寬度長(zhǎng)標(biāo)題會(huì)把日期擠出容器加了這個(gè)屬性之后標(biāo)題才能被正常截?cái)嗷驌Q行。這個(gè)屬性我?guī)缀踉诿總€(gè) Flex 文本容器上都會(huì)加。3.3 主題切換的樣式實(shí)現(xiàn)上一節(jié)把暗色的變量值定好了但還差一步讓html上的>body { background: var(--bg); color: var(--text); font-family: var(--font-sans); font-size: 17px; line-height: 1.75; transition: background-color .2s ease, color .2s ease; }關(guān)于transition有一個(gè)爭(zhēng)議點(diǎn)給body加顏色過(guò)渡會(huì)讓主題切換很順滑但也會(huì)讓頁(yè)面首次加載時(shí)出現(xiàn)從白色漸變到暗色的效果如果theme.js執(zhí)行得夠早這個(gè)漸變其實(shí)看不到。我的做法是保留transition因?yàn)榇蟛糠钟脩?hù)感知不到首次加載的那一瞬間而切換主題時(shí)的順滑感是能明顯感知到的。如果你追求極致可以在html上加一個(gè)preload類(lèi)加載完成后再移除用來(lái)臨時(shí)禁用過(guò)渡這里不展開(kāi)。3.4 中文排版的幾個(gè)細(xì)節(jié)中文網(wǎng)頁(yè)的排版有很多默認(rèn)值其實(shí)是錯(cuò)的需要手動(dòng)覆蓋。第一是行高瀏覽器默認(rèn)的normal大概在 1.2 左右中文方塊字在這個(gè)行高下會(huì)顯得擁擠正文用 1.75、注釋類(lèi)文本用 1.6 比較舒服。第二是段落間距中文習(xí)慣用段間距而不是首行縮進(jìn)來(lái)區(qū)分段落所以p上要加margin-bottom同時(shí)把text-indent保持為 0。.post-content p { margin: 0 0 1.2em; } .post-content h2 { font-size: 1.4em; margin: 2em 0 .8em; padding-bottom: .3em; border-bottom: 1px solid var(--border); scroll-margin-top: 80px; /* 錨點(diǎn)跳轉(zhuǎn)時(shí)給吸頂導(dǎo)航留位置 */ } .post-content h3 { font-size: 1.15em; margin: 1.6em 0 .6em; } .post-content img { max-width: 100%; height: auto; border-radius: var(--radius); } .post-content pre { background: var(--code-bg); padding: var(--space-3); border-radius: var(--radius); overflow-x: auto; /* 關(guān)鍵代碼塊自己橫向滾動(dòng) */ font-family: var(--font-mono); font-size: 14px; line-height: 1.6; } .post-content code { font-family: var(--font-mono); font-size: .92em; }scroll-margin-top是個(gè)特別實(shí)用但知道的人不多的屬性。頁(yè)面頂部有吸頂導(dǎo)航時(shí)點(diǎn)擊目錄跳轉(zhuǎn)到某個(gè)標(biāo)題標(biāo)題會(huì)被導(dǎo)航擋住一半。以前的做法是給標(biāo)題加padding-top再用負(fù)margin-top抵消現(xiàn)在一行scroll-margin-top就解決了而且只影響錨點(diǎn)定位不影響視覺(jué)間距。overflow-x: auto加在pre上而不是body上是為了讓長(zhǎng)代碼行只讓代碼塊自己滾動(dòng)整個(gè)頁(yè)面不會(huì)橫向漂移。這是移動(dòng)端閱讀體驗(yàn)的關(guān)鍵——如果給body加了overflow-x: hidden來(lái)掩蓋問(wèn)題代碼塊里的內(nèi)容就被裁掉了用戶(hù)根本看不到。正確的做法是讓代碼塊內(nèi)部滾動(dòng)。4. 交互層原生 JS 把靜態(tài)頁(yè)變成可用的博客系統(tǒng)到這一步頁(yè)面已經(jīng)能看了但它還是死的——沒(méi)有文章列表點(diǎn)了標(biāo)簽沒(méi)反應(yīng)主題切換按鈕也不工作。這一章是整篇的核心講清楚每一段 JS 到底在做什么、為什么這么寫(xiě)。我把它拆成四塊數(shù)據(jù)渲染、篩選搜索、主題持久化、目錄高亮。每塊都控制在幾十行加起來(lái)也不過(guò)兩三百行比引入一整套框架省事得多。4.1 渲染列表模板字符串加文檔片段最簡(jiǎn)單直接的渲染方式是用模板字符串拼 HTML然后一次性塞進(jìn)容器的innerHTML。這種寫(xiě)法性能很好因?yàn)橹挥|發(fā)一次 DOM 重排比循環(huán)appendChild快得多。但它有一個(gè)必須警惕的問(wèn)題XSS。如果文章標(biāo)題或摘要里含有script或者img onerror...直接插進(jìn)innerHTML就會(huì)被瀏覽器當(dāng)成標(biāo)簽執(zhí)行。我這里的做法是在拼接之前對(duì)所有來(lái)自數(shù)據(jù)的文本做一次轉(zhuǎn)義。// js/list.js const escapeHtml str String(str).replace(/[]/g, ch ({ : amp;, : lt;, : gt;, : quot;, : #39; }[ch])); const formatDate iso { const d new Date(iso); return ${d.getFullYear()}-${String(d.getMonth() 1).padStart(2, 0)}-${String(d.getDate()).padStart(2, 0)}; }; function renderList(list) { const box document.getElementById(postList); if (!list.length) { box.innerHTML ; document.getElementById(emptyTip).hidden false; return; } document.getElementById(emptyTip).hidden true; const sorted [...list].sort((a, b) b.date.localeCompare(a.date)); box.innerHTML sorted.map(post article classpost-item div classtitle h2a href./post.html?id${encodeURIComponent(post.id)}${escapeHtml(post.title)}/a/h2 p classsummary${escapeHtml(post.summary)}/p div classtag-bar ${post.tags.map(t span classtag${escapeHtml(t)}/span).join()} /div /div time datetime${post.date}${formatDate(post.date)}/time /article ).join(); }這里有兩個(gè)細(xì)節(jié)值得掰開(kāi)說(shuō)。第一post.id用encodeURIComponent處理因?yàn)?id 我習(xí)慣用英文短橫線(xiàn)拼寫(xiě)如果將來(lái)出現(xiàn)中文 id不編碼會(huì)拼出非法 URL。第二排序用的是b.date.localeCompare(a.date)而不是new Date(b.date) - new Date(a.date)。因?yàn)槿掌诟袷浇y(tǒng)一是YYYY-MM-DD字符串比較的結(jié)果和日期比較完全一致而字符串比較不需要?jiǎng)?chuàng)建 Date 對(duì)象幾十篇文章的差異可以忽略但寫(xiě)法更干凈。如果日期格式不統(tǒng)一就必須老老實(shí)實(shí)轉(zhuǎn)成時(shí)間戳。關(guān)于innerHTML和DocumentFragment的選擇我補(bǔ)充一句實(shí)測(cè)結(jié)論在幾十到幾百條數(shù)據(jù)的量級(jí)下兩者的性能差異肉眼不可感知選哪個(gè)主要看代碼可讀性。innerHTML的寫(xiě)法更短但每次更新都會(huì)銷(xiāo)毀并重建整棵子樹(shù)如果有節(jié)點(diǎn)上掛了事件監(jiān)聽(tīng)或者有輸入框焦點(diǎn)會(huì)丟失。所以我的原則是純展示內(nèi)容用innerHTML包含表單或者需要保持狀態(tài)的區(qū)域用DocumentFragment逐個(gè)構(gòu)建。4.2 標(biāo)簽篩選與關(guān)鍵詞搜索的組合邏輯篩選和搜索這兩個(gè)功能單獨(dú)實(shí)現(xiàn)都很簡(jiǎn)單難的是它們要能疊加——選中前端標(biāo)簽之后再輸入關(guān)鍵詞結(jié)果應(yīng)該是兩個(gè)條件的交集。我的做法是把全部文章當(dāng)作數(shù)據(jù)源每次交互時(shí)都從原始數(shù)據(jù)重新算一遍結(jié)果而不是在上一次的結(jié)果上繼續(xù)過(guò)濾。后者看起來(lái)省事實(shí)際是坑搜完再點(diǎn)標(biāo)簽結(jié)果會(huì)越篩越少而且取消條件時(shí)無(wú)法恢復(fù)。let state { tag: , keyword: }; function applyFilter() { const kw state.keyword.trim().toLowerCase(); const result POSTS.filter(post { const tagOk !state.tag || post.tags.includes(state.tag); const kwOk !kw || post.title.toLowerCase().includes(kw) || post.summary.toLowerCase().includes(kw); return tagOk kwOk; }); renderList(result); } function renderTags() { const all [全部, ...new Set(POSTS.flatMap(p p.tags))]; document.getElementById(tagBar).innerHTML all.map(t { const value t 全部 ? : t; const active state.tag value ? active : ; return button classtag-btn${active} typebutton>// js/theme.js —— 必須放在 head 中同步執(zhí)行 (function () { var saved null; try { saved localStorage.getItem(theme); } catch (e) { /* 隱私模式可能拋錯(cuò) */ } var prefersDark window.matchMedia window.matchMedia((prefers-color-scheme: dark)).matches; document.documentElement.dataset.theme saved || (prefersDark ? dark : light); })();// js/common.js 中的切換邏輯 document.addEventListener(click, e { if (!e.target.closest(#themeToggle)) return; const root document.documentElement; const next root.dataset.theme dark ? light : dark; root.dataset.theme next; try { localStorage.setItem(theme, next); } catch (err) {} });try...catch包住localStorage的讀寫(xiě)是因?yàn)樵?Safari 的隱私瀏覽模式下某些版本訪(fǎng)問(wèn)localStorage會(huì)直接拋異常。不包的話(huà)theme.js一拋錯(cuò)后面的代碼全都不執(zhí)行頁(yè)面直接白屏。這種在某些瀏覽器里才復(fù)現(xiàn)的問(wèn)題本地開(kāi)發(fā)時(shí)根本發(fā)現(xiàn)不了只有用戶(hù)反饋上來(lái)才追得到所以防御性寫(xiě)法很有必要。順便說(shuō)一個(gè)進(jìn)階細(xì)節(jié)如果用戶(hù)沒(méi)有手動(dòng)選過(guò)主題那么系統(tǒng)在用戶(hù)瀏覽過(guò)程中切換到暗色比如到了日落時(shí)間自動(dòng)切換頁(yè)面應(yīng)該跟著變。這需要監(jiān)聽(tīng)matchMedia的change事件并且在用戶(hù)手動(dòng)選過(guò)之后停止跟隨。實(shí)現(xiàn)方式是判斷l(xiāng)ocalStorage里有沒(méi)有值window.matchMedia((prefers-color-scheme: dark)) .addEventListener(change, e { if (localStorage.getItem(theme)) return; // 用戶(hù)已手動(dòng)選擇不跟隨 document.documentElement.dataset.theme e.matches ? dark : light; });4.4 目錄高亮用 IntersectionObserver 而不是 scroll 事件文章目錄的高亮是詳情頁(yè)里最有技術(shù)含量的部分。早期我用的是監(jiān)聽(tīng)scroll事件每次滾動(dòng)都遍歷所有標(biāo)題計(jì)算它們的getBoundingClientRect().top找出第一個(gè)進(jìn)入視口的標(biāo)題。這個(gè)方法能跑但有兩個(gè)問(wèn)題滾動(dòng)事件觸發(fā)極其頻繁每一幀都在做幾十次布局計(jì)算長(zhǎng)文章滾動(dòng)時(shí)會(huì)有明顯掉幀而且滾動(dòng)位置和標(biāo)題位置的計(jì)算依賴(lài)頁(yè)面布局一旦有圖片未加載完成計(jì)算結(jié)果會(huì)跳變?，F(xiàn)在的做法是用IntersectionObserver它由瀏覽器在合成線(xiàn)程里統(tǒng)一調(diào)度不阻塞主線(xiàn)程性能好得多。思路是觀察所有正文標(biāo)題當(dāng)某個(gè)標(biāo)題進(jìn)入頂部以下、底部以上這個(gè)判定區(qū)域時(shí)就把它標(biāo)記為當(dāng)前激活項(xiàng)。為了讓判定更符合閱讀直覺(jué)我把根邊界的底部設(shè)成負(fù) 70%讓標(biāo)題只有在靠近頁(yè)面頂部時(shí)才被算作當(dāng)前章節(jié)。// js/post.js 中的目錄生成與高亮 function buildToc(container) { const headings [...container.querySelectorAll(h2, h3)]; const tocList document.getElementById(tocList); const items headings.map((h, i) { if (!h.id) h.id h- i; // 自動(dòng)補(bǔ) id避免手寫(xiě)遺漏 const a document.createElement(a); a.href # h.id; a.textContent h.textContent; a.className toc-link (h.tagName H3 ? level-3 : ); a.dataset.target h.id; tocList.appendChild(a); return a; }); const map new Map(items.map(a [a.dataset.target, a])); const observer new IntersectionObserver(entries { entries.forEach(entry { if (!entry.isIntersecting) return; items.forEach(a a.classList.remove(active)); const active map.get(entry.target.id); if (active) active.classList.add(active); }); }, { rootMargin: -72px 0px -70% 0px, threshold: 0 }); headings.forEach(h observer.observe(h)); }rootMargin的-72px對(duì)應(yīng)吸頂導(dǎo)航的高度讓判定區(qū)域從導(dǎo)航下方開(kāi)始。最后一個(gè)參數(shù)threshold: 0表示只要有 1 像素進(jìn)入?yún)^(qū)域就算這樣連續(xù)滾動(dòng)時(shí)高亮切換很及時(shí)。這個(gè)方案有個(gè)已知的小缺陷當(dāng)用戶(hù)滾到文章最底部時(shí)判定區(qū)域內(nèi)可能一個(gè)標(biāo)題都沒(méi)有高亮?xí)Ｔ谏弦粋€(gè)標(biāo)題上。如果希望最后一段始終高亮最后一個(gè)標(biāo)題需要在滾動(dòng)到底部時(shí)手動(dòng)處理或者在正文末尾補(bǔ)一個(gè)空的錨點(diǎn)元素參與觀察。實(shí)踐中這個(gè)缺陷影響很小我一般不處理。4.5 代碼復(fù)制、回到頂部和公共片段注入剩下幾個(gè)小功能都很短但少一個(gè)體驗(yàn)就缺一塊。代碼復(fù)制給每個(gè)pre動(dòng)態(tài)插入一個(gè)復(fù)制按鈕點(diǎn)擊后用navigator.clipboard.writeText寫(xiě)入剪貼板。這里要注意剪切板 API 在非 HTTPS 環(huán)境下不可用本地用file://打開(kāi)會(huì)失敗所以必須有降級(jí)提示。function bindCopyButtons(container) { container.querySelectorAll(pre).forEach(pre { const btn document.createElement(button); btn.className copy-btn; btn.type button; btn.textContent 復(fù)制; btn.addEventListener(click, async () { const code pre.querySelector(code); const text (code || pre).innerText; try { await navigator.clipboard.writeText(text); btn.textContent 已復(fù)制; } catch (err) { btn.textContent 復(fù)制失敗; } setTimeout(() { btn.textContent 復(fù)制; }, 1500); }); pre.appendChild(btn); }); }回到頂部按鈕越簡(jiǎn)單越好用一個(gè)position: fixed的按鈕滾動(dòng)超過(guò)一屏?xí)r顯示點(diǎn)擊后window.scrollTo({ top: 0, behavior: smooth })。注意滾動(dòng)監(jiān)聽(tīng)也要節(jié)流或者干脆用IntersectionObserver觀察頁(yè)面頂部的一個(gè)哨兵元素在它不可見(jiàn)時(shí)顯示按鈕這樣連滾動(dòng)事件都不用監(jiān)聽(tīng)。公共片段注入多頁(yè)面共享的頁(yè)頭和頁(yè)腳我用一小段 JS 在DOMContentLoaded時(shí)注入數(shù)據(jù)放在獨(dú)立的對(duì)象里。它的代價(jià)是首屏?xí)幸凰查g沒(méi)有頁(yè)頭但因?yàn)樽⑷氚l(fā)生在 DOM 解析完但渲染之前實(shí)際感知不到。如果將來(lái)你要求嚴(yán)格的無(wú)閃爍可以把頁(yè)頭頁(yè)腳寫(xiě)成獨(dú)立的 HTML 文件用構(gòu)建腳本在打包時(shí)拼進(jìn)去那就是另一條路了。5. 踩坑記錄原生方案里最容易翻車(chē)的幾處前面講的都是怎么做這一章講為什么會(huì)做錯(cuò)。下面這些問(wèn)題我在這個(gè)項(xiàng)目上基本都踩過(guò)一遍有的是自己寫(xiě)的 bug有的是瀏覽器行為跟直覺(jué)不一致。把它們整理出來(lái)是因?yàn)檫@些坑的共同特點(diǎn)是出問(wèn)題時(shí)現(xiàn)象和原因看起來(lái)毫無(wú)關(guān)系只能靠經(jīng)驗(yàn)或者一步步排查才能定位。5.1 主題閃爍的完整排查過(guò)程現(xiàn)象是這樣的頁(yè)面用暗色主題刷新時(shí)會(huì)先閃一下白色大約幾十毫秒然后才變成暗色。第一次遇到我以為是自己 CSS 寫(xiě)錯(cuò)了檢查了>let composing false; const input document.getElementById(searchInput); input.addEventListener(compositionstart, () { composing true; }); input.addEventListener(compositionend, () { composing false; state.keyword input.value; applyFilter(); }); input.addEventListener(input, e { if (composing) return; // 輸入法組合中先不篩 clearTimeout(timer); timer setTimeout(() { state.keyword e.target.value; applyFilter(); }, 200); });同類(lèi)的問(wèn)題還有搜索大小寫(xiě)。我用toLowerCase()統(tǒng)一處理但要注意土耳其語(yǔ)環(huán)境下的i轉(zhuǎn)換規(guī)則不同個(gè)人博客可以忽略知道了就行。5.4 移動(dòng)端的兩個(gè)經(jīng)典問(wèn)題移動(dòng)端第一個(gè)問(wèn)題是100vh。我原本給首屏歡迎區(qū)設(shè)了min-height: 100vh在桌面瀏覽器上沒(méi)問(wèn)題在手機(jī)瀏覽器上底部會(huì)被地址欄遮住一截。原因在移動(dòng)瀏覽器里100vh指的是地址欄隱藏時(shí)的視口高度而地址欄顯示時(shí)可視區(qū)域更小?，F(xiàn)代的解法是用100dvh代替100vhd表示動(dòng)態(tài)視口會(huì)隨地址欄狀態(tài)變化。兼容性不夠時(shí)退回到100vh.hero { min-height: 100vh; min-height: 100dvh; /* 后者生效時(shí)覆蓋前者 */ }第二個(gè)問(wèn)題是可點(diǎn)擊元素的尺寸。小屏上按鈕如果只有 20 像素高手指根本點(diǎn)不準(zhǔn)。經(jīng)驗(yàn)值是交互元素的可點(diǎn)區(qū)域不小于 44×44 像素。標(biāo)簽按鈕在我的設(shè)計(jì)里視覺(jué)高度是 28 像素通過(guò)padding和::before擴(kuò)展出一個(gè)更大的命中區(qū)域視覺(jué)不變、手感變好。這是個(gè)花五分鐘就能做完、但用戶(hù)粘性提升很明顯的改動(dòng)。第 5.5 節(jié)我把響應(yīng)式斷點(diǎn)的選擇也放在這里說(shuō)因?yàn)樗举|(zhì)上也是移動(dòng)端適配的一部分。我用的斷點(diǎn)只有兩個(gè)900px 和 640px。900px 以上是正文 目錄兩列以下收成一列640px 以下是手機(jī)導(dǎo)航折疊、字號(hào)從 17px 調(diào)到 16px、間距變量整體縮小一檔。斷點(diǎn)不是越多越好每多一個(gè)斷點(diǎn)就多一套需要維護(hù)的樣式兩三個(gè)足夠覆蓋個(gè)人博客的全部場(chǎng)景。6. 源碼之外性能、數(shù)據(jù)維護(hù)和什么時(shí)候該換方案頁(yè)面能跑起來(lái)之后還有幾個(gè)決定它能不能長(zhǎng)期用下去的問(wèn)題。這一章講三件事資源加載順序怎么排、文章數(shù)據(jù)怎么維護(hù)、以及什么信號(hào)出現(xiàn)時(shí)說(shuō)明你該考慮換技術(shù)方案了。這部分不是必須做但它決定了這個(gè)博客是你花兩天做完就扔的練手作品還是能持續(xù)用兩三年的個(gè)人站點(diǎn)。6.1 資源加載順序與體積控制三個(gè) JS 文件的加載順序不是隨便排的有依賴(lài)關(guān)系data.js定義POSTS必須最先加載common.js用到主題切換和公共片段不依賴(lài)數(shù)據(jù)排第二list.js和post.js依賴(lài)前兩者最后加載。因?yàn)槎际瞧胀╯cript標(biāo)簽瀏覽器會(huì)按順序同步執(zhí)行不會(huì)出現(xiàn)POSTS is not defined的錯(cuò)誤。如果你給它們加上defer執(zhí)行順序同樣是按標(biāo)簽順序保持的但會(huì)推遲到 DOM 解析完之后反而更好——前提是渲染邏輯都包在DOMContentLoaded或者defer之后執(zhí)行。體積方面可以做幾個(gè)簡(jiǎn)單的控制。第一所有小圖標(biāo)用內(nèi)聯(lián) SVG 而不是圖片文件一個(gè) SVG 圖標(biāo)大約兩三百字節(jié)比發(fā)一次 HTTP 請(qǐng)求劃算得多。第二圖片統(tǒng)一用img loadinglazy延遲加載首屏只加載視口內(nèi)的圖。第三如果你用了第三方代碼高亮庫(kù)注意它的體積往往比自己寫(xiě)的所有代碼加起來(lái)都大個(gè)人博客上完全可以不做語(yǔ)法高亮或者只在詳情頁(yè)按需加載。一個(gè)常被忽略的點(diǎn)是 CSS 的渲染阻塞。link relstylesheet會(huì)阻塞首屏渲染這是必要的否則會(huì)出現(xiàn)無(wú)樣式內(nèi)容閃爍但如果有多個(gè) CSS 文件它們會(huì)串行加載。我把歸零樣式和主題樣式合并成一個(gè)文件就是這個(gè)原因。如果將來(lái)樣式變得很復(fù)雜可以用一個(gè)內(nèi)聯(lián)的style放首屏關(guān)鍵樣式剩下的異步加載不過(guò)對(duì)個(gè)人博客來(lái)說(shuō)這是過(guò)度優(yōu)化。6.2 文章數(shù)據(jù)怎么維護(hù)才不痛苦把文章放在js/data.js里最直接但寫(xiě)文章時(shí)要在 JS 字符串里嵌 HTML編輯器不會(huì)給你語(yǔ)法高亮和補(bǔ)全寫(xiě)起來(lái)很難受。我的實(shí)際做法是用 Markdown 寫(xiě)正文用一個(gè)幾十行的腳本轉(zhuǎn)換成 HTML 后追加到data.js里。這個(gè)腳本只需要做幾件事讀取posts/目錄下的.md文件解析出開(kāi)頭的元信息標(biāo)題、日期、標(biāo)簽把正文轉(zhuǎn)成 HTML輸出成data.js。用到的元信息格式就是最簡(jiǎn)單的鍵值對(duì)放在文件開(kāi)頭用三個(gè)短橫線(xiàn)包起來(lái)--- title: 用原生三件套搭一個(gè)博客站 date: 2024-05-18 tags: 前端, 實(shí)戰(zhàn) summary: 不裝框架從零搭出可用的博客頁(yè)面。 --- 正文從這里開(kāi)始……這樣做的好處是寫(xiě)作和展示徹底分離寫(xiě)作時(shí)享受 Markdown 編輯器的便利展示時(shí)享受純靜態(tài)頁(yè)面的性能。代價(jià)是每次寫(xiě)完文章要跑一次腳本但個(gè)人博客的更新頻率這個(gè)成本完全可接受。如果你想更省事可以把這個(gè)腳本掛在文件系統(tǒng)的變化事件上保存 Markdown 就自動(dòng)重新生成。另一個(gè)維護(hù)上的建議是給data.js加上版本號(hào)或者時(shí)間戳注釋并且把文章的id定得足夠永久。id 一旦發(fā)布就不要改否則所有外部鏈接都會(huì)失效而且localStorage里可能還存著基于舊 id 的閱讀記錄。我習(xí)慣用英文短橫線(xiàn)拼寫(xiě)的標(biāo)題作為 id比如build-blog-with-vanilla-js語(yǔ)義清晰、不易沖突、也不需要額外的編號(hào)系統(tǒng)。6.3 出現(xiàn)這幾個(gè)信號(hào)就該考慮換方案了原生方案不是終點(diǎn)它有自己的天花板。我總結(jié)了幾條判斷標(biāo)準(zhǔn)如果你同時(shí)命中兩條以上說(shuō)明繼續(xù)在這套代碼上疊功能已經(jīng)不劃算了。文章超過(guò)兩三百篇data.js會(huì)變成幾百 KB 的文件每次打開(kāi)首頁(yè)都要完整下載。這時(shí)候要么改成按需加載每篇文章一個(gè)獨(dú)立的 JSON 文件要么引入服務(wù)端渲染。前者的改動(dòng)量不小但比全面重寫(xiě)便宜。需要多人協(xié)作或者在線(xiàn)編輯一旦涉及登錄、草稿、權(quán)限前端的復(fù)雜度會(huì)陡增這時(shí)候后端和框架的價(jià)值才開(kāi)始體現(xiàn)。純靜態(tài)方案在這個(gè)方向上沒(méi)有任何優(yōu)勢(shì)。交互狀態(tài)超過(guò)十個(gè)目前只有主題、標(biāo)簽、搜索詞三個(gè)狀態(tài)用閉包變量管理很輕松。如果將來(lái)加了閱讀進(jìn)度、收藏、筆記、排序方式等等狀態(tài)之間的聯(lián)動(dòng)會(huì)變得難以追蹤這時(shí)候引入一個(gè)狀態(tài)管理層才是合理的。需要頻繁的局部更新比如實(shí)時(shí)預(yù)覽、拖拽排序這類(lèi)高度動(dòng)態(tài)的交互手寫(xiě) DOM 操作會(huì)變得又長(zhǎng)又容易出錯(cuò)框架的聲明式渲染能省下大量代碼。場(chǎng)景原生三件套引入框架文章幾十篇、無(wú)登錄推薦首屏最快收益不明顯文章幾百篇需要自己做按需加載有現(xiàn)成的路由與分包多人協(xié)作、在線(xiàn)編輯不適合推薦交互狀態(tài)少于十個(gè)閉包變量足夠略重需要 SEO 且不做預(yù)渲染依賴(lài)靜態(tài) HTML 兜底可服務(wù)端渲染我個(gè)人的判斷是個(gè)人博客這個(gè)場(chǎng)景絕大多數(shù)人永遠(yuǎn)用不到第四列。真正需要做的是把內(nèi)容寫(xiě)好而不是把技術(shù)棧堆高。我在這個(gè)博客上跑了兩年一共改過(guò)三次代碼一次加了目錄高亮一次換了暗色配色一次調(diào)整了移動(dòng)端字號(hào)。每次改動(dòng)花的時(shí)間都在半小時(shí)以?xún)?nèi)因?yàn)橛凶兞亢颓逦奈募澐治抑涝摳哪睦铩Ｗ詈蠓窒硪粋€(gè)我自己用了很久的小習(xí)慣每次改完樣式或者加完功能都把頁(yè)面縮到 375 像素寬看一眼再用鍵盤(pán) Tab 鍵從頭到尾走一遍。縮到手機(jī)寬度能發(fā)現(xiàn) 90% 的布局問(wèn)題Tab 鍵走一遍能發(fā)現(xiàn)所有焦點(diǎn)不可見(jiàn)的問(wèn)題。這兩個(gè)動(dòng)作加起來(lái)不到兩分鐘但能擋掉絕大多數(shù)用戶(hù)會(huì)遇到的糟糕體驗(yàn)。