前端工程師做Demo誰(shuí)不會(huì)好看、絲滑、交互驚艷本地一跑效果圖直接發(fā)群里大家都說(shuō)牛。但往往最打臉的一刻就在上線(xiàn)那兩天——白屏、404、接口報(bào)錯(cuò)、字體圖片全裂用戶(hù)在瀏覽器里看到的東西和你在自己電腦上看到的完全不是同一個(gè)東西。這是我在FDE落地實(shí)戰(zhàn)系列里的第三篇。前兩篇我們聊了FDE崗位的工作邊界和需求拆解今天這篇專(zhuān)門(mén)聊聊那個(gè)讓很多前端工程師半夜心梗的經(jīng)典問(wèn)題為什么Demo很好看一上線(xiàn)就出問(wèn)題FDE的日常不只是還原UI、寫(xiě)交互更關(guān)鍵的一段路是從“能跑”到“能上線(xiàn)”。這篇文章就把這條路上的坑一個(gè)個(gè)踩給你看順便給出一套可以直接照抄的落地流程。1. Demo和線(xiàn)上本質(zhì)上是兩個(gè)世界1.1 你以為在跑同一個(gè)項(xiàng)目其實(shí)不是很多前端新人會(huì)有一個(gè)錯(cuò)覺(jué)代碼是我寫(xiě)的本地能跑打包上傳服務(wù)器頂多就是路徑問(wèn)題。但實(shí)際走下去會(huì)發(fā)現(xiàn)本地環(huán)境和線(xiàn)上環(huán)境之間的差異比你想象中大得多。我通常會(huì)把這種差異拆成三個(gè)維度**運(yùn)行環(huán)境差異。**本地開(kāi)發(fā)用的是開(kāi)發(fā)服務(wù)器比如vite的devServer、webpack的devServer或react的npm start它們默認(rèn)做了熱更新、路徑重寫(xiě)、跨域代理。你訪(fǎng)問(wèn)的地址是http://localhost:5173所有資源都是動(dòng)態(tài)編譯的。但線(xiàn)上環(huán)境是一個(gè)靜態(tài)文件服務(wù)器通常是Nginx它不會(huì)幫你做任何編譯只負(fù)責(zé)把文件吐出去路徑匹配、MIME類(lèi)型、緩存策略全得你自己配好。**數(shù)據(jù)環(huán)境差異。**Demo階段大概率是寫(xiě)死數(shù)據(jù)或者用Mock來(lái)模擬接口。而線(xiàn)上要接真實(shí)后端服務(wù)跨域限制、接口鑒權(quán)、網(wǎng)絡(luò)波動(dòng)、數(shù)據(jù)格式變化每一個(gè)都是新的變量。**用戶(hù)環(huán)境差異。**你自己用的是公司配的MacChrome最新版網(wǎng)絡(luò)帶寬充足。真實(shí)用戶(hù)用的是五花八門(mén)的手機(jī)、各種版本的瀏覽器、時(shí)快時(shí)慢的4G/5G。你在本地沒(méi)見(jiàn)過(guò)的兼容性問(wèn)題用戶(hù)能變著花樣幫你復(fù)現(xiàn)。這三個(gè)維度放到一起你就會(huì)明白單獨(dú)把“本地能跑”當(dāng)作上線(xiàn)標(biāo)準(zhǔn)本身就是一件很危險(xiǎn)的事。1.2 Demo模式下哪些東西被“偷偷慣壞了”我得說(shuō)句實(shí)話(huà)Demo本身沒(méi)有錯(cuò)它在前期的需求對(duì)齊和設(shè)計(jì)驗(yàn)證階段非常重要。問(wèn)題在于Demo模式下有些東西被簡(jiǎn)化了而簡(jiǎn)化掉的部分恰好是線(xiàn)上最容易出問(wèn)題的部分。第一是跨域。本地開(kāi)發(fā)時(shí)前端框架的腳手架都會(huì)配置一個(gè)proxy代理把/api這種請(qǐng)求轉(zhuǎn)發(fā)到后端服務(wù)器瀏覽器根本感知不到跨域問(wèn)題。但打包成靜態(tài)文件部署之后就不再走這個(gè)代理了。如果線(xiàn)上沒(méi)有用Nginx做反向代理而是讓前端直接去請(qǐng)求http://api.xxxx.com這種地址那么瀏覽器會(huì)在CORS策略上給你上一課。第二是路由。很多Demo用的是BrowserRouter之類(lèi)的前端路由本地開(kāi)發(fā)怎么刷新都沒(méi)事。但線(xiàn)上部署時(shí)如果Nginx沒(méi)有配置try_files用戶(hù)刷新某個(gè)子頁(yè)面比如/product/123服務(wù)器去找這個(gè)路徑下的文件找不到直接就報(bào)404。第三是環(huán)境變量。Demo里大家習(xí)慣把接口地址寫(xiě)死或者用本地環(huán)境變量頂一下。打包時(shí)如果沒(méi)有區(qū)分development和production很可能會(huì)出現(xiàn)“本地跑得好好的生產(chǎn)環(huán)境也在請(qǐng)求localhost”的尷尬情況。第四是依賴(lài)包版本。不少朋友在Demo階段喜歡用“最新版本”的依賴(lài)今天裝一個(gè)beta版的UI庫(kù)明天更新一個(gè)組件版本。本地跑沒(méi)問(wèn)題但打包到線(xiàn)上時(shí)因?yàn)橐蕾?lài)版本兼容性問(wèn)題編譯失敗或運(yùn)行時(shí)出錯(cuò)排查起來(lái)特別費(fèi)勁。所以與其責(zé)怪“Demo欺騙了我”不如承認(rèn)一個(gè)現(xiàn)實(shí)Demo的目標(biāo)是證明方案可行上線(xiàn)的目標(biāo)是保證交付穩(wěn)定。這兩件事中間還隔著一整套工程化收尾工作。2. 上線(xiàn)翻車(chē)的高頻問(wèn)題清單這一節(jié)我直接把多年踩坑經(jīng)驗(yàn)里最典型的幾類(lèi)問(wèn)題列出來(lái)每類(lèi)都給了現(xiàn)象、原因和排查方向。不管你是第一次部署個(gè)人項(xiàng)目還是在公司里負(fù)責(zé)前端交付都可以對(duì)照著看。2.1 靜態(tài)資源與路由路徑配置錯(cuò)誤這是前端部署翻車(chē)的Top 1問(wèn)題特征非常明顯打開(kāi)首頁(yè)正常但刷新一個(gè)二級(jí)頁(yè)面就404或者頁(yè)面能打開(kāi)但所有的圖片、CSS、JS文件全部加載失敗。原因基本出在打包配置里的base或publicPath上。Vite是basewebpack是publicPathCRA是homepage。如果你的項(xiàng)目部署在域名根路徑問(wèn)題不大但一旦部署在子路徑下比如https://example.com/abc/而構(gòu)建配置里仍然默認(rèn)寫(xiě)成/那么所有資源都會(huì)去請(qǐng)求根目錄自然就全部404了。這里給一個(gè)實(shí)戰(zhàn)中的建議部署前先確認(rèn)部署路徑再寫(xiě)構(gòu)建配置。比如Vite項(xiàng)目部署在子路徑應(yīng)該在vite.config.ts中這樣設(shè)置// vite.config.ts export default defineConfig({ base: /abc/, // 改成實(shí)際部署的二級(jí)路徑 })刷新404背后的路由配置則要在Nginx層面解決location / { try_files $uri $uri/ /index.html; }try_files的作用是當(dāng)URL匹配不到真實(shí)文件時(shí)回退到index.html讓前端路由接管接下來(lái)的處理。這句話(huà)是SPA應(yīng)用部署的命脈不知道這一行配置的話(huà)刷新404就是必然的。2.2 接口Mock和跨域問(wèn)題做Demo的時(shí)候Mock很方便常見(jiàn)方案有mswMock Service Worker、json-server或者直接在代碼里if else一段假數(shù)據(jù)。問(wèn)題是很多人在上線(xiàn)前忘了關(guān)掉這些Mock邏輯或者忘了處理跨域。我見(jiàn)過(guò)一個(gè)項(xiàng)目前端頁(yè)面流轉(zhuǎn)很順暢自以為接的是真實(shí)接口實(shí)際上代碼里有一段被注釋掉一半的Mock邏輯導(dǎo)致線(xiàn)上數(shù)據(jù)死活不對(duì)勁。另外跨域這塊一旦前端和后端不在同一個(gè)域名下就需要處理CORS或者代理。我的建議是能用Nginx反向代理就不要讓瀏覽器直接跨域。在Nginx配置里加一段location /api/ { proxy_pass http://backend-server:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }這樣做的好處是前端代碼里的接口地址統(tǒng)一寫(xiě)成相對(duì)路徑/api/xxxx線(xiàn)上和本地的邏輯一致跨域問(wèn)題從根本上避免了。本地開(kāi)發(fā)再通過(guò)Vite的proxy代理到同一個(gè)后端地址開(kāi)發(fā)體驗(yàn)和線(xiàn)上行為高度趨同。2.3 構(gòu)建體積過(guò)大導(dǎo)致白屏和卡頓Demo階段很少有人關(guān)心包體積反正本地加載快。但到了線(xiàn)上用戶(hù)的網(wǎng)絡(luò)環(huán)境千差萬(wàn)別一個(gè)幾MB甚至十幾MB的JavaScript文件會(huì)讓首屏加載非常煎熬。我遇到過(guò)一個(gè)實(shí)際項(xiàng)目一個(gè)管理后臺(tái)沒(méi)做路由懶加載所有的業(yè)務(wù)代碼打包成一個(gè)chunk壓縮后4.8MB用戶(hù)訪(fǎng)問(wèn)首頁(yè)需要先下載這個(gè)4.8MB的文件加上并發(fā)限制和弱網(wǎng)完全渲染出來(lái)要好幾秒體感極差。解決這個(gè)問(wèn)題的手段有很多優(yōu)先級(jí)從高到低依次是路由懶加載按頁(yè)面拆分代碼塊用const UserPage React.lazy(() import(./pages/User))這種模式訪(fǎng)問(wèn)哪個(gè)頁(yè)面才下載哪個(gè)頁(yè)面的代碼。第三方庫(kù)按需加載UI庫(kù)不要整體引入用ESM按需導(dǎo)入。構(gòu)建產(chǎn)物分析用rollup-plugin-visualizer或webpack-bundle-analyzer看一下哪些模塊體積占比高針對(duì)性地做拆分或替換。靜態(tài)資源處理圖片壓縮、轉(zhuǎn)WebP、合理設(shè)置緩存。對(duì)于Vite項(xiàng)目最簡(jiǎn)單的路由懶加載寫(xiě)法如下// 路由配置 const routes [ { path: /home, component: () import(/pages/Home.vue) } ]這樣打包后每個(gè)路由頁(yè)面會(huì)生成獨(dú)立的chunk文件首屏只加載首屏需要的代碼其他頁(yè)面按需下載首屏性能是肉眼可見(jiàn)的差異。2.4 兼容性和真機(jī)適配Demo基本都在電腦瀏覽器里跑真機(jī)適配很容易被忽略。我復(fù)盤(pán)過(guò)幾次線(xiàn)上事故最典型的是這么幾類(lèi)window或document對(duì)象在服務(wù)端渲染SSR環(huán)境下不存在導(dǎo)致首屏報(bào)錯(cuò)某些老舊瀏覽器不支持ES6新語(yǔ)法比如可選鏈?.和空值合并??白屏沒(méi)商量移動(dòng)端鍵盤(pán)彈起遮擋輸入框iOS Safari對(duì)100vh的處理有歷史遺留問(wèn)題。對(duì)于兼容性問(wèn)題沒(méi)有一勞永逸的方案只能靠?jī)蓷l腿走路一條是構(gòu)建層面加vitejs/plugin-legacy或babel/preset-env進(jìn)行語(yǔ)法降級(jí)另一條是真機(jī)測(cè)試列表了至少要覆蓋iOS Safari、Android Chrome、微信內(nèi)置瀏覽器這三種常見(jiàn)容器。2.5 多端打包與容器差異近期經(jīng)常有朋友問(wèn)到鴻蒙Demo打包成hap、hsp、har的問(wèn)題還有Android上Kotlin Compose寫(xiě)的Demo在上線(xiàn)時(shí)遇到的簽名和權(quán)限問(wèn)題。這里多說(shuō)一句凡是涉及多端打包的場(chǎng)景Demo和線(xiàn)上之間的差異會(huì)進(jìn)一步放大。比如鴻蒙應(yīng)用里的hap包本地調(diào)試可以直接通過(guò)DevEco Studio跑起來(lái)但正式分發(fā)時(shí)需要簽名配置、權(quán)限聲明、版本號(hào)等一堆東西。Android的Compose項(xiàng)目debug構(gòu)建和release構(gòu)建的簽名不同、混淆配置不同如果不提前把本地的debug簽名留在代碼里上線(xiàn)后更新就是個(gè)坑。移動(dòng)端項(xiàng)目和大前端項(xiàng)目的共同思路是一致的Demo階段就要把正式/測(cè)試的環(huán)境區(qū)分做進(jìn)去不要讓debug包的配置和release包耦合在一起。否則等上線(xiàn)前再拆時(shí)間和風(fēng)險(xiǎn)都翻倍。3. 從Demo到上線(xiàn)的完整落地路徑聊完了問(wèn)題清單下面給出一套從Demo到上線(xiàn)可以直接落地的流程。這一節(jié)不寫(xiě)空話(huà)從構(gòu)建配置、Docker部署、Nginx配置到上線(xiàn)驗(yàn)證按步驟走一遍。3.1 第一步整理環(huán)境變量區(qū)分不同環(huán)境的配置很多人上線(xiàn)翻車(chē)的根源就一句話(huà)“環(huán)境變量沒(méi)分清楚”。本地、測(cè)試、生產(chǎn)各需要什么接口地址、是否需要Mock、日志輸出級(jí)別是多少這些都應(yīng)該通過(guò)環(huán)境變量控制而不是每次手動(dòng)改代碼。前端項(xiàng)目通常用.env文件來(lái)管理。Vite項(xiàng)目里可以建立以下文件.env.development # 本地開(kāi)發(fā)環(huán)境 .env.production # 生產(chǎn)環(huán)境 .env.staging # 測(cè)試/預(yù)發(fā)環(huán)境文件里的內(nèi)容類(lèi)似于# .env.production VITE_API_BASE/api VITE_MOCK_ENABLEDfalse然后代碼里統(tǒng)一讀取const apiBase import.meta.env.VITE_API_BASE const mockEnabled import.meta.env.VITE_MOCK_ENABLED true這樣每次打包時(shí)構(gòu)建工具會(huì)自動(dòng)加載對(duì)應(yīng)環(huán)境的變量。不要把接口地址寫(xiě)死在代碼里這是第一條鐵律。3.2 第二步配置構(gòu)建優(yōu)化控制產(chǎn)物體積在構(gòu)建配置里我一般會(huì)固定做三件事代碼分割、壓縮、動(dòng)態(tài)polyfill。以Vite為例一個(gè)基礎(chǔ)優(yōu)化版本是這樣的// vite.config.ts import { defineConfig } from vite import vue from vitejs/plugin-vue import legacy from vitejs/plugin-legacy export default defineConfig({ plugins: [ vue(), legacy({ targets: [defaults, not IE 11], }), ], build: { outDir: dist, sourcemap: false, rollupOptions: { output: { manualChunks: { vueBasic: [vue, vue-router, pinia], uiLibrary: [ant-design-vue], }, }, }, }, })manualChunks的作用是把公共依賴(lài)單獨(dú)拆包利用瀏覽器緩存機(jī)制避免每次業(yè)務(wù)代碼變動(dòng)導(dǎo)致第三方庫(kù)也要重新下載。這在長(zhǎng)期迭代的項(xiàng)目里收益特別明顯。另外記得關(guān)掉sourcemap。線(xiàn)上環(huán)境開(kāi)啟sourcemap不僅增加體積還等于把源代碼暴露給所有人。3.3 第三步用Docker鏡像固化部署環(huán)境問(wèn)“前端怎么使用Docker部署項(xiàng)目上線(xiàn)”的朋友非常多這里統(tǒng)一回答一下前端用Docker部署的核心目的不是花哨而是讓構(gòu)建和運(yùn)行環(huán)境保持一致避免“本機(jī)能跑服務(wù)器跑不了”的玄學(xué)問(wèn)題。前端Docker的一般做法是兩階段構(gòu)建。第一個(gè)階段用Node鏡像來(lái)安裝依賴(lài)并打包第二個(gè)階段用Nginx鏡像來(lái)承載靜態(tài)文件。這樣做的好處是最終鏡像體積很小只有靜態(tài)文件和Nginx配置不包含Node環(huán)境和node_modules。一個(gè)可直接使用的Dockerfile如下# 第一階段構(gòu)建 FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build # 第二階段運(yùn)行 FROM nginx:1.27-alpine COPY --frombuilder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD [nginx, -g, daemon off;]注意一個(gè)細(xì)節(jié)npm install和npm run build分開(kāi)寫(xiě)是為了充分利用Docker的層緩存。如果你的代碼沒(méi)有變化而node_modules緩存還在那鏡像構(gòu)建速度會(huì)快很多。3.4 第四步配置Nginx解決路由、代理和緩存Nginx配置是整個(gè)前端上線(xiàn)的核心很多你以為是代碼問(wèn)題的事故其實(shí)都是Nginx配置問(wèn)題。這里給出一份經(jīng)過(guò)多次實(shí)戰(zhàn)驗(yàn)證的完整配置模板server { listen 80; server_name your-domain.com; gzip on; gzip_min_length 1k; gzip_types text/plain text/css application/javascript application/json image/svgxml; # 靜態(tài)資源緩存文件名帶 hash 的文件可以長(zhǎng)緩存 location /assets/ { expires 30d; add_header Cache-Control public, immutable; } # 前端路由回退 location / { try_files $uri $uri/ /index.html; } # 接口反向代理 location /api/ { proxy_pass http://backend-server:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }這里最值得留意的是緩存策略。帶hash的文件如index.8f2a1c.js內(nèi)容變了文件名就變了可以放心用immutable長(zhǎng)緩存但index.html本身一定不能緩存否則前端每次發(fā)版用戶(hù)拿到的都是舊頁(yè)面。3.5 第五步域名、HTTPS與上線(xiàn)后的驗(yàn)證域名和HTTPS是上線(xiàn)前的最后一公里。現(xiàn)在申請(qǐng)HTTPS證書(shū)已經(jīng)很成熟了使用certbot之類(lèi)的工具可以自動(dòng)申請(qǐng)和續(xù)期。HTTPS不是加分項(xiàng)而是必選項(xiàng)涉及登錄鑒權(quán)的接口如果不是HTTPStoken很容易在傳輸過(guò)程中被截獲。上線(xiàn)后的驗(yàn)證不能只看首頁(yè)能打開(kāi)建議按以下清單走一遍強(qiáng)制刷新頁(yè)面確認(rèn)能拿到最新版本手動(dòng)刷新一個(gè)二級(jí)路由確認(rèn)不404打開(kāi)瀏覽器DevTools的Network面板看靜態(tài)資源是否都是200有沒(méi)有404請(qǐng)求找一個(gè)弱網(wǎng)環(huán)境DevTools里可以模擬確認(rèn)首屏加載可接受按真實(shí)用戶(hù)的操作路徑走一遍包括登錄、跳轉(zhuǎn)、退出檢查控制臺(tái)有沒(méi)有報(bào)錯(cuò)特別是跨域和資源加載相關(guān)的錯(cuò)誤4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這一節(jié)整理一份問(wèn)題排查速查表方便你在上線(xiàn)出問(wèn)題時(shí)按圖索驥。這些都是我當(dāng)時(shí)一個(gè)個(gè)線(xiàn)上事故試出來(lái)的經(jīng)驗(yàn)踩過(guò)的坑我只說(shuō)一遍?，F(xiàn)象可能原因優(yōu)先排查方向首頁(yè)白屏控制臺(tái)無(wú)報(bào)錯(cuò)靜態(tài)資源路徑404打包配置的base/publicPath是否正確刷新子頁(yè)面404服務(wù)端未配置try_filesNginx location塊加try_files $uri $uri/ /index.html圖片CSS加載失敗資源引用用了絕對(duì)路徑檢查構(gòu)建配置里的資源路徑接口請(qǐng)求失敗或跨域反向代理未配置或Mock殘留查看請(qǐng)求URLNginx加proxy_pass頁(yè)面能開(kāi)但圖片全裂CDN/存儲(chǔ)配置錯(cuò)誤檢查上傳文件的域名和存儲(chǔ)權(quán)限區(qū)分本地存儲(chǔ)和對(duì)象存儲(chǔ)構(gòu)建報(bào)錯(cuò)non-resolvable parent pomMaven依賴(lài)解析失敗檢查pom.xml的parent依賴(lài)和倉(cāng)庫(kù)地址是否可達(dá)數(shù)據(jù)異?；蚋虏簧ndex.html被緩存Nginx的index.html設(shè)置no-cache打開(kāi)很慢包體積太大無(wú)代碼分割用構(gòu)建分析工具查體積處理最大的模塊安卓白屏蘋(píng)果正常語(yǔ)法不支持缺少降級(jí)給構(gòu)建加legacy插件或babel降級(jí)接口時(shí)而通時(shí)而不通后端網(wǎng)絡(luò)波動(dòng)或并發(fā)超限查看后端日志確認(rèn)請(qǐng)求是否到達(dá)服務(wù)端為了讓你更直觀地理解排查思路我挑兩個(gè)高頻情況展開(kāi)說(shuō)。**白屏排查通用路徑。**先打開(kāi)瀏覽器DevTools的Console和Network看有沒(méi)有紅色報(bào)錯(cuò)和4xx/5xx請(qǐng)求。如果是資源404那就是路徑問(wèn)題如果是語(yǔ)法錯(cuò)誤一般會(huì)直接提示哪個(gè)js文件哪一行如果是運(yùn)行時(shí)錯(cuò)誤比如Cannot read properties of undefined就需要用sourcemap定位代碼或直接從報(bào)錯(cuò)信息反推業(yè)務(wù)邏輯。白屏的大概率原因80%是“資源沒(méi)加載到”或“JavaScript執(zhí)行出錯(cuò)”只有極少數(shù)是瀏覽器不兼容。**構(gòu)建報(bào)錯(cuò)排查通用思路。**例如有朋友遇到過(guò)project build error: non-resolvable parent pom for com.example:demo:0.0.1-sn這種Maven構(gòu)建報(bào)錯(cuò)這種錯(cuò)誤本質(zhì)上是依賴(lài)找不到。優(yōu)先檢查本地Maven倉(cāng)庫(kù)里有沒(méi)有對(duì)應(yīng)依賴(lài)再看倉(cāng)庫(kù)地址能不能訪(fǎng)問(wèn)接著檢查代理配置是不是攔截了下載。這類(lèi)問(wèn)題在CI環(huán)境里特別常見(jiàn)解決方案一般就是確認(rèn)settings.xml里的鏡像源配置是可用且完整的。5. 從一個(gè)好看的Demo到一個(gè)能交付的線(xiàn)上項(xiàng)目上面講了很多具體操作這一節(jié)我想聊聊比操作更重要的東西FDE視角下的交付思維。因?yàn)楣ぞ吆团渲枚际强梢詫W(xué)的但如果在認(rèn)知層面不轉(zhuǎn)變就算這次上線(xiàn)成功了下次換個(gè)項(xiàng)目還是會(huì)踩類(lèi)似的坑。5.1 FDE的職責(zé)不是“做頁(yè)面”而是“保上線(xiàn)”FDE崗位的工作內(nèi)容絕對(duì)不只是把UI稿做成頁(yè)面。你還需要考慮頁(yè)面在不同環(huán)境下是否可用、交互在弱網(wǎng)下是否合理、數(shù)據(jù)異常時(shí)是否有兜底方案、發(fā)版后如何快速發(fā)現(xiàn)問(wèn)題、出現(xiàn)問(wèn)題后能不能快速回滾。我見(jiàn)過(guò)一些前端同學(xué)自己寫(xiě)的頁(yè)面在開(kāi)發(fā)環(huán)境里反復(fù)點(diǎn)覺(jué)得沒(méi)有問(wèn)題提測(cè)后測(cè)試一上手就發(fā)現(xiàn)一堆邊界情況。其實(shí)這不能全怪測(cè)試很多時(shí)候是因?yàn)殚_(kāi)發(fā)環(huán)境用的數(shù)據(jù)太“完美”了。真實(shí)的接口返回可能是延遲的、可能是500的、可能是字段缺失的你的頁(yè)面設(shè)計(jì)沒(méi)有考慮到這些情況那上線(xiàn)后用戶(hù)看到的就是錯(cuò)誤頁(yè)面。所以在開(kāi)發(fā)過(guò)程中我習(xí)慣性地會(huì)問(wèn)自己幾個(gè)問(wèn)題接口掛了怎么展示用戶(hù)弱網(wǎng)時(shí)有沒(méi)有l(wèi)oading反饋?zhàn)侄螢榭諘?huì)不會(huì)導(dǎo)致頁(yè)面崩潰權(quán)限不足時(shí)按鈕是隱藏還是置灰這些問(wèn)題在你設(shè)計(jì)Demo的時(shí)候可能不重要但在線(xiàn)上體驗(yàn)中就是致命的細(xì)節(jié)。5.2 最少必要工程化清單很多獨(dú)自開(kāi)發(fā)或小團(tuán)隊(duì)協(xié)作的朋友擔(dān)心工程化太重導(dǎo)致開(kāi)發(fā)效率下降。這里我給一個(gè)“最少必要”的清單不做全量標(biāo)準(zhǔn)化的捆綁但至少保證上線(xiàn)可維護(hù)版本管理 每次發(fā)布使用Git tag方便出問(wèn)題時(shí)的版本回溯。環(huán)境配置 三個(gè)基礎(chǔ)環(huán)境dev/test/prod的配置從.env文件中拆分而不是改代碼。構(gòu)建腳本 把構(gòu)建命令和輸出目錄固定下來(lái)本地、CI、Docker統(tǒng)一用同一條命令。日志上報(bào) 前端至少做一次錯(cuò)誤捕獲把js運(yùn)行時(shí)錯(cuò)誤和資源加載錯(cuò)誤上報(bào)到監(jiān)控平臺(tái)哪怕是簡(jiǎn)單地把信息發(fā)到一個(gè)日志接口。這一步主要是為了線(xiàn)上問(wèn)題不再靠用戶(hù)截圖反饋。發(fā)布回滾預(yù)案 Docker鏡像保留上一版tag出問(wèn)題能快速切回舊版本。5.3 拿Demo做過(guò)關(guān)評(píng)審時(shí)多問(wèn)一句“上線(xiàn)了怎么辦”最后分享一個(gè)我在實(shí)際工作中的習(xí)慣每當(dāng)我們做完一個(gè)功能在給產(chǎn)品或設(shè)計(jì)做演示的時(shí)候除了展示效果我都會(huì)追問(wèn)一句“如果這里上線(xiàn)了我們?cè)趺打?yàn)證、怎么監(jiān)控、怎么回退”。這句話(huà)在Demo階段顯得有點(diǎn)掃興但每次都能把很多潛在的線(xiàn)上事故提前消滅在評(píng)審階段。這其實(shí)也是FDE崗位真正的價(jià)值所在你不僅是把設(shè)計(jì)稿變成代碼的執(zhí)行者你是整個(gè)前端交付鏈路的質(zhì)量負(fù)責(zé)人。寫(xiě)到這里我想起自己第一次獨(dú)立部署前端項(xiàng)目的樣子本地運(yùn)行得好好的自信滿(mǎn)滿(mǎn)上了服務(wù)器結(jié)果白屏了一下午。后來(lái)發(fā)現(xiàn)只是忘了配置try_files刷新二級(jí)頁(yè)面就404用戶(hù)訪(fǎng)問(wèn)倒是正常但誰(shuí)知道哪個(gè)用戶(hù)會(huì)手滑刷新一下呢。那一下午的教訓(xùn)換來(lái)的經(jīng)驗(yàn)是從此以后每做一個(gè)前端項(xiàng)目我先把Nginx配置和構(gòu)建路徑想明白再動(dòng)手寫(xiě)頁(yè)面。因?yàn)檫@些底層的部署邏輯決定了你的頁(yè)面最終能不能被用戶(hù)正常訪(fǎng)問(wèn)。希望這篇FDE落地實(shí)戰(zhàn)能幫你在上線(xiàn)環(huán)節(jié)少走幾次彎路。下次Demo演示完別急著慶祝先想想如果這個(gè)頁(yè)面現(xiàn)在就要部署到服務(wù)器上你的base、proxy、try_files、緩存策略都準(zhǔn)備好了嗎