前端工程師做Demo誰(shuí)不會(huì)好看、絲滑、交互驚艷本地一跑效果圖直接發(fā)群里大家都說(shuō)牛。但往往最打臉的一刻就在上線那兩天——白屏、404、接口報(bào)錯(cuò)、字體圖片全裂用戶在瀏覽器里看到的東西和你在自己電腦上看到的完全不是同一個(gè)東西。這是我在FDE落地實(shí)戰(zhàn)系列里的第三篇。前兩篇我們聊了FDE崗位的工作邊界和需求拆解今天這篇專門聊聊那個(gè)讓很多前端工程師半夜心梗的經(jīng)典問(wèn)題為什么Demo很好看一上線就出問(wèn)題FDE的日常不只是還原UI、寫(xiě)交互更關(guān)鍵的一段路是從“能跑”到“能上線”。這篇文章就把這條路上的坑一個(gè)個(gè)踩給你看順便給出一套可以直接照抄的落地流程。1. Demo和線上本質(zhì)上是兩個(gè)世界1.1 你以為在跑同一個(gè)項(xiàng)目其實(shí)不是很多前端新人會(huì)有一個(gè)錯(cuò)覺(jué)代碼是我寫(xiě)的本地能跑打包上傳服務(wù)器頂多就是路徑問(wèn)題。但實(shí)際走下去會(huì)發(fā)現(xiàn)本地環(huá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ě)、跨域代理。你訪問(wèn)的地址是http://localhost:5173所有資源都是動(dòng)態(tài)編譯的。但線上環(huán)境是一個(gè)靜態(tài)文件服務(wù)器通常是Nginx它不會(huì)幫你做任何編譯只負(fù)責(zé)把文件吐出去路徑匹配、MIME類型、緩存策略全得你自己配好。**數(shù)據(jù)環(huán)境差異。**Demo階段大概率是寫(xiě)死數(shù)據(jù)或者用Mock來(lái)模擬接口。而線上要接真實(shí)后端服務(wù)跨域限制、接口鑒權(quán)、網(wǎng)絡(luò)波動(dòng)、數(shù)據(jù)格式變化每一個(gè)都是新的變量。**用戶環(huán)境差異。**你自己用的是公司配的MacChrome最新版網(wǎng)絡(luò)帶寬充足。真實(shí)用戶用的是五花八門的手機(jī)、各種版本的瀏覽器、時(shí)快時(shí)慢的4G/5G。你在本地沒(méi)見(jiàn)過(guò)的兼容性問(wèn)題用戶能變著花樣幫你復(fù)現(xiàn)。這三個(gè)維度放到一起你就會(huì)明白單獨(dú)把“本地能跑”當(dāng)作上線標(biāo)準(zhǔn)本身就是一件很危險(xiǎn)的事。1.2 Demo模式下哪些東西被“偷偷慣壞了”我得說(shuō)句實(shí)話Demo本身沒(méi)有錯(cuò)它在前期的需求對(duì)齊和設(shè)計(jì)驗(yàn)證階段非常重要。問(wèn)題在于Demo模式下有些東西被簡(jiǎn)化了而簡(jiǎn)化掉的部分恰好是線上最容易出問(wèn)題的部分。第一是跨域。本地開(kāi)發(fā)時(shí)前端框架的腳手架都會(huì)配置一個(gè)proxy代理把/api這種請(qǐng)求轉(zhuǎn)發(fā)到后端服務(wù)器瀏覽器根本感知不到跨域問(wèn)題。但打包成靜態(tài)文件部署之后就不再走這個(gè)代理了。如果線上沒(méi)有用Nginx做反向代理而是讓前端直接去請(qǐng)求http://api.xxxx.com這種地址那么瀏覽器會(huì)在CORS策略上給你上一課。第二是路由。很多Demo用的是BrowserRouter之類的前端路由本地開(kāi)發(fā)怎么刷新都沒(méi)事。但線上部署時(shí)如果Nginx沒(méi)有配置try_files用戶刷新某個(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”的尷尬情況。第四是依賴包版本。不少朋友在Demo階段喜歡用“最新版本”的依賴今天裝一個(gè)beta版的UI庫(kù)明天更新一個(gè)組件版本。本地跑沒(méi)問(wèn)題但打包到線上時(shí)因?yàn)橐蕾嚢姹炯嫒菪詥?wèn)題編譯失敗或運(yùn)行時(shí)出錯(cuò)排查起來(lái)特別費(fèi)勁。所以與其責(zé)怪“Demo欺騙了我”不如承認(rèn)一個(gè)現(xiàn)實(shí)Demo的目標(biāo)是證明方案可行上線的目標(biāo)是保證交付穩(wěn)定。這兩件事中間還隔著一整套工程化收尾工作。2. 上線翻車的高頻問(wèn)題清單這一節(jié)我直接把多年踩坑經(jīng)驗(yàn)里最典型的幾類問(wèn)題列出來(lái)每類都給了現(xiàn)象、原因和排查方向。不管你是第一次部署個(gè)人項(xiàng)目還是在公司里負(fù)責(zé)前端交付都可以對(duì)照著看。2.1 靜態(tài)資源與路由路徑配置錯(cuò)誤這是前端部署翻車的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)的處理。這句話是SPA應(yīng)用部署的命脈不知道這一行配置的話刷新404就是必然的。2.2 接口Mock和跨域問(wèn)題做Demo的時(shí)候Mock很方便常見(jiàn)方案有mswMock Service Worker、json-server或者直接在代碼里if else一段假數(shù)據(jù)。問(wèn)題是很多人在上線前忘了關(guān)掉這些Mock邏輯或者忘了處理跨域。我見(jiàn)過(guò)一個(gè)項(xiàng)目前端頁(yè)面流轉(zhuǎn)很順暢自以為接的是真實(shí)接口實(shí)際上代碼里有一段被注釋掉一半的Mock邏輯導(dǎo)致線上數(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線上和本地的邏輯一致跨域問(wèn)題從根本上避免了。本地開(kāi)發(fā)再通過(guò)Vite的proxy代理到同一個(gè)后端地址開(kāi)發(fā)體驗(yàn)和線上行為高度趨同。2.3 構(gòu)建體積過(guò)大導(dǎo)致白屏和卡頓Demo階段很少有人關(guān)心包體積反正本地加載快。但到了線上用戶的網(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用戶訪問(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))這種模式訪問(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ò)幾次線上事故最典型的是這么幾類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在上線時(shí)遇到的簽名和權(quán)限問(wèn)題。這里多說(shuō)一句凡是涉及多端打包的場(chǎng)景Demo和線上之間的差異會(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簽名留在代碼里上線后更新就是個(gè)坑。移動(dòng)端項(xiàng)目和大前端項(xiàng)目的共同思路是一致的Demo階段就要把正式/測(cè)試的環(huán)境區(qū)分做進(jìn)去不要讓debug包的配置和release包耦合在一起。否則等上線前再拆時(shí)間和風(fēng)險(xiǎn)都翻倍。3. 從Demo到上線的完整落地路徑聊完了問(wèn)題清單下面給出一套從Demo到上線可以直接落地的流程。這一節(jié)不寫(xiě)空話從構(gòu)建配置、Docker部署、Nginx配置到上線驗(yàn)證按步驟走一遍。3.1 第一步整理環(huán)境變量區(qū)分不同環(huán)境的配置很多人上線翻車的根源就一句話“環(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)容類似于# .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的作用是把公共依賴單獨(dú)拆包利用瀏覽器緩存機(jī)制避免每次業(yè)務(wù)代碼變動(dòng)導(dǎo)致第三方庫(kù)也要重新下載。這在長(zhǎng)期迭代的項(xiàng)目里收益特別明顯。另外記得關(guān)掉sourcemap。線上環(huán)境開(kāi)啟sourcemap不僅增加體積還等于把源代碼暴露給所有人。3.3 第三步用Docker鏡像固化部署環(huán)境問(wèn)“前端怎么使用Docker部署項(xiàng)目上線”的朋友非常多這里統(tǒng)一回答一下前端用Docker部署的核心目的不是花哨而是讓構(gòu)建和運(yùn)行環(huán)境保持一致避免“本機(jī)能跑服務(wù)器跑不了”的玄學(xué)問(wèn)題。前端Docker的一般做法是兩階段構(gòu)建。第一個(gè)階段用Node鏡像來(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è)前端上線的核心很多你以為是代碼問(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ā)版用戶拿到的都是舊頁(yè)面。3.5 第五步域名、HTTPS與上線后的驗(yàn)證域名和HTTPS是上線前的最后一公里?，F(xiàn)在申請(qǐng)HTTPS證書(shū)已經(jīng)很成熟了使用certbot之類的工具可以自動(dòng)申請(qǐng)和續(xù)期。HTTPS不是加分項(xiàng)而是必選項(xiàng)涉及登錄鑒權(quán)的接口如果不是HTTPStoken很容易在傳輸過(guò)程中被截獲。上線后的驗(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í)用戶的操作路徑走一遍包括登錄、跳轉(zhuǎn)、退出檢查控制臺(tái)有沒(méi)有報(bào)錯(cuò)特別是跨域和資源加載相關(guān)的錯(cuò)誤4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這一節(jié)整理一份問(wèn)題排查速查表方便你在上線出問(wèn)題時(shí)按圖索驥。這些都是我當(dāng)時(shí)一個(gè)個(gè)線上事故試出來(lái)的經(jīng)驗(yàn)踩過(guò)的坑我只說(shuō)一遍。現(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依賴解析失敗檢查pom.xml的parent依賴和倉(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ì)上是依賴找不到。優(yōu)先檢查本地Maven倉(cāng)庫(kù)里有沒(méi)有對(duì)應(yīng)依賴再看倉(cāng)庫(kù)地址能不能訪問(wèn)接著檢查代理配置是不是攔截了下載。這類問(wèn)題在CI環(huán)境里特別常見(jiàn)解決方案一般就是確認(rèn)settings.xml里的鏡像源配置是可用且完整的。5. 從一個(gè)好看的Demo到一個(gè)能交付的線上項(xiàng)目上面講了很多具體操作這一節(jié)我想聊聊比操作更重要的東西FDE視角下的交付思維。因?yàn)楣ぞ吆团渲枚际强梢詫W(xué)的但如果在認(rèn)知層面不轉(zhuǎn)變就算這次上線成功了下次換個(gè)項(xiàng)目還是會(huì)踩類似的坑。5.1 FDE的職責(zé)不是“做頁(yè)面”而是“保上線”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)有考慮到這些情況那上線后用戶看到的就是錯(cuò)誤頁(yè)面。所以在開(kāi)發(fā)過(guò)程中我習(xí)慣性地會(huì)問(wèn)自己幾個(gè)問(wèn)題接口掛了怎么展示用戶弱網(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í)候可能不重要但在線上體驗(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)化的捆綁但至少保證上線可維護(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è)日志接口。這一步主要是為了線上問(wèn)題不再靠用戶截圖反饋。發(fā)布回滾預(yù)案 Docker鏡像保留上一版tag出問(wèn)題能快速切回舊版本。5.3 拿Demo做過(guò)關(guān)評(píng)審時(shí)多問(wèn)一句“上線了怎么辦”最后分享一個(gè)我在實(shí)際工作中的習(xí)慣每當(dāng)我們做完一個(gè)功能在給產(chǎn)品或設(shè)計(jì)做演示的時(shí)候除了展示效果我都會(huì)追問(wèn)一句“如果這里上線了我們?cè)趺打?yàn)證、怎么監(jiān)控、怎么回退”。這句話在Demo階段顯得有點(diǎn)掃興但每次都能把很多潛在的線上事故提前消滅在評(píng)審階段。這其實(shí)也是FDE崗位真正的價(jià)值所在你不僅是把設(shè)計(jì)稿變成代碼的執(zhí)行者你是整個(gè)前端交付鏈路的質(zhì)量負(fù)責(zé)人。寫(xiě)到這里我想起自己第一次獨(dú)立部署前端項(xiàng)目的樣子本地運(yùn)行得好好的自信滿滿上了服務(wù)器結(jié)果白屏了一下午。后來(lái)發(fā)現(xiàn)只是忘了配置try_files刷新二級(jí)頁(yè)面就404用戶訪問(wèn)倒是正常但誰(shuí)知道哪個(gè)用戶會(huì)手滑刷新一下呢。那一下午的教訓(xùn)換來(lái)的經(jīng)驗(yàn)是從此以后每做一個(gè)前端項(xiàng)目我先把Nginx配置和構(gòu)建路徑想明白再動(dòng)手寫(xiě)頁(yè)面。因?yàn)檫@些底層的部署邏輯決定了你的頁(yè)面最終能不能被用戶正常訪問(wèn)。希望這篇FDE落地實(shí)戰(zhàn)能幫你在上線環(huán)節(jié)少走幾次彎路。下次Demo演示完別急著慶祝先想想如果這個(gè)頁(yè)面現(xiàn)在就要部署到服務(wù)器上你的base、proxy、try_files、緩存策略都準(zhǔn)備好了嗎