你有沒有算過，搭一個全棧項目環(huán)境要踩多少坑？

最近參與了一場為期兩天的MERN Stack動手實訓(xùn)，主題很實在——從命令行敲第一行代碼，到最終把項目掛到托管平臺。沒有PPT轟炸，全程對著屏幕敲。結(jié)果發(fā)現(xiàn)，那些教程里一筆帶過的"環(huán)境配置"環(huán)節(jié)，才是真實耗時的黑洞。

先說說項目骨架。前端用React+Vite，后端是Node.js裸寫HTTP服務(wù)。目錄拆成前后端兩個文件夾，看起來清爽，但第一次跑通卻卡了半小時——端口沖突。前端默認5173，后端設(shè)了3000，本以為是井水不犯河水，結(jié)果瀏覽器緩存和CORS策略聯(lián)手搞事情。

具體結(jié)構(gòu)長這樣：my-react-app下面分frontend和backend兩兄弟。frontend里頭是標準的Vite生成物，src目錄塞了App.jsx、main.jsx、calculator.js和index.css；backend更簡陋，就一個server.js頂著，外加calculator.js做業(yè)務(wù)邏輯。README.md放在根目錄，算是給兩周后的自己留條活路。

后端那段代碼很直白：createServer監(jiān)聽127.0.0.1:3000，返回一段帶學(xué)號的"Hello World"。但魔鬼在細節(jié)——hostname寫成'127.0.0.1'而不是'localhost'，在部分Windows機器上會觸發(fā)防火墻彈窗。講師的原話是："先讓它跑起來，再研究為什么跑起來。"

啟動命令分兩條線。前端三件套：cd frontend、npm install、npm run dev。后端更省事，node server.js直接起。但這里埋了個雷：如果先跑后端再裝前端依賴，terminal窗口開多了容易分不清哪個是哪個。我的解決辦法是給后端terminal標簽標紅，前端標綠——土，但有效。

.gitignore的配置是當天第二個頓悟時刻。node_modules、.env、dist/這三兄弟必須拉黑，否則GitHub會拒絕推送——單個文件超100MB直接報錯，而node_modules輕輕松松破這個數(shù)。更隱蔽的問題是嵌套倉庫：如果frontend文件夾里不小心git init過，整個項目就會變成"倉庫里的倉庫"，push時Git會懵掉。

解決路徑是先把嵌套的.git目錄刪掉，再用git rm --cached清掉已經(jīng)track的文件，最后重新add、commit、push。講師演示時特意放慢了速度："看，這里出現(xiàn)fatal: refusing to merge unrelated histories的時候，別慌，加--allow-unrelated-histories只是止痛片，根治得把結(jié)構(gòu)理順。"

實訓(xùn)后半段切到MongoDB，用mongosh練CRUD。insert、find、update、delete四個操作，語法不算復(fù)雜，但case sensitivity坑了不少人——db.collection.findOne()和findone()在JavaScript里是兩個函數(shù)，在mongosh里后者直接報錯。更隱蔽的是引號：JSON格式要求雙引號，但手滑打成單引號時，錯誤提示指向的是"Unexpected token"，而不是"引號錯了"。

有個細節(jié)值得記一筆。練習(xí)update操作時，有人用了$set有人忘了，結(jié)果后者直接把整條document替換成新值，舊字段全丟。講師沒阻止這個錯誤，而是讓當事人自己查db.collection.find()的輸出，對比前后差異。"比我說十遍印象深刻"，這是他的原話。

兩天結(jié)束時的檢查清單包括：React+Vite前端、Node.js后端、Calculator UI、HTTP服務(wù)對接、GitHub倉庫、.gitignore生效、雙端口并行。聽起來基礎(chǔ)，但逐項打勾的過程里，每個勾背后都有至少一次報錯和搜索。

最后的狀態(tài)是項目環(huán)境配齊了Node.js、Express.js、MongoDB，雖然Express在原文里只露了個名字，實際代碼還是原生http模塊。這種"知道有更方便的工具但先不用"的教學(xué)設(shè)計，倒是讓人理解為什么要學(xué)底層——等Express的app.get()出問題時，你知道它最終調(diào)的是createServer。

托管部署環(huán)節(jié)用的是"multiple platforms"，具體名字沒展開。從上下文推測是多平臺對比演示，但實訓(xùn)重點放在"能跑通"而非"選哪個"。畢竟對于兩天速成來說，先建立端到端的信心，比糾結(jié)Vercel和Netlify的帶寬差異更實際。

如果非要總結(jié)點什么：全棧開發(fā)的門檻不在代碼復(fù)雜度，而在故障定位。報錯信息、日志輸出、網(wǎng)絡(luò)面板的來回切換，這些軟技能沒有快捷鍵。實訓(xùn)的價值或許就在這里——它模擬了真實工作流里"預(yù)期之外"的那部分，而不是教程里精心修剪過的happy path。