多數人以為做網站就是找一個工程師，把版面、功能、後台通通交給同一個人一手包辦；實際上，一張報價單裡看似整合在一起的「網站建置」項目，背後常常同時牽動兩種完全不同的專業——一種負責使用者在螢幕上看到什麼、點下去有沒有反應，另一種負責資料存在哪裡、金流有沒有算對、誰能看到什麼內容。前者是前端工程師的工作範圍，後者是後端工程師的工作範圍。
這個分工聽起來像是技術細節，跟發案的人沒什麼關係，但實務上常常不是這樣。不少人收到報價單，看到「前端」「後端」兩個項目，卻不太確定這兩行各自對應哪些工作，也不知道為什麼同樣叫「一個網站」，有的案子後端費用特別高，有的案子幾乎沒有後端項目。等到網站上線後系統出狀況，也常常搞不清楚該找誰排查，結果變成前端工程師和後端工程師互相指向對方。
搞懂前端與後端各自的邊界，不需要學會寫程式，只要抓住幾個判斷維度就夠了。先從這兩個角色各自的定義開始拆。
前端工程師是什麼？
前端工程師負責的，是使用者在瀏覽器裡實際看得到、摸得到的一切：版面怎麼排，字型多大，顏色怎麼配，按下按鈕之後有沒有動畫回饋，手機和電腦打開同一個網頁時排版會不會跑掉。這些工作用到的技術主要是三種語言，HTML 負責搭建頁面的結構（標題在哪、段落在哪、圖片放哪），CSS 負責外觀（顏色、字型、間距、版面配置），JavaScript 負責互動（點擊選單會展開、輪播圖會自動切換、表單填錯欄位會即時提示）。
這三種語言寫出來的程式碼，執行的地方跟一般想像的不太一樣，不是在某台遠方的伺服器上運算完再把結果傳過來，而是直接下載到使用者的瀏覽器裡，在使用者自己的電腦或手機上執行。這個執行位置的差異，決定了前端能做到什麼、做不到什麼：前端程式碼碰得到的資源有限，沒有辦法直接存取遠端的資料庫，也沒有辦法完成金流驗證這類需要伺服器端把關的工作。MDN（Mozilla 官方開發文件）在說明用戶端程式碼時就指出，client-side code 在瀏覽器裡執行，對底層作業系統幾乎沒有存取權限，連檔案系統的存取都受到限制；它的工作重點是選擇與設計使用者介面元件、建立版面配置、處理導覽與表單驗證這類讓頁面呈現正確、行為正確的任務。
也因為前端程式碼是下載到使用者端才執行，RWD（響應式網頁設計）也歸在前端的工作範圍，同一份 HTML 與 CSS，要能依螢幕寬度自動調整版面配置，讓手機、平板、電腦打開同一個網址都看得清楚、用得順手。這是很多人對「網站做得好不好」最直接的感受來源，卻也是最容易誤會分工的地方：使用者看到的版面順不順眼、動畫跑不跑得動，幾乎都是前端在負責，但這不代表前端可以獨立完成一整個網站，真正涉及資料存放與商業邏輯的部分，要交給後端。
後端工程師負責的資料庫、邏輯與伺服器
後端工程師負責的，是使用者看不到的那一層：資料庫裡存了什麼資料、商業邏輯怎麼跑、伺服器環境怎麼設定。前端決定畫面長什麼樣，後端則決定這個網站實際能做到什麼事，會員資料存在哪裡、訂單怎麼被記錄、誰能看到什麼內容、金流有沒有驗證正確，通通是後端的工作。
跟前端不同的是，後端程式碼跑在伺服器上，而不是使用者的瀏覽器裡。MDN 說明，伺服器端程式碼可以用多種語言撰寫，常見的選項包括 PHP、Python、Ruby、C# 與 JavaScript（在伺服器端執行時稱為 Node.js）；伺服器端程式碼對伺服器的作業系統有完整的存取權限，開發者也能自由選擇要用哪一種程式語言與版本。換句話說，PHP、Python、Node.js 這些名詞本身不是重點，它們只是完成後端工作的工具選項，真正重要的是後端負責決定回傳什麼內容給瀏覽器、能不能做這件事。
資料庫是後端工作裡最核心的一塊，負責儲存與查詢會員、訂單、商品這類會不斷變動的資料，今天有新會員註冊、有新訂單成立，資料庫裡的內容就要跟著更新，而不是像前端頁面那樣寫死不變。除了存資料，後端還要做驗證與權限控管：使用者填的表單有沒有符合格式、密碼對不對、誰能看到哪些內容、誰能修改什麼。這也是判斷一個網站是靜態還是動態的關鍵，靜態網站沒有資料庫，每一頁的內容都是寫死的；動態網站則是靠後端程式把資料庫裡的內容即時套進頁面樣板產生出來，關鍵差別就在有沒有資料庫在背後運作。
前端與後端的三個分工邊界
前端與後端各自的工作範圍拆開來看之後，真正能直接拿去對照報價單、合約或後續維護溝通的，是三個判斷維度：使用者看不看得到、程式碼實際在哪裡執行、系統出狀況時該往哪個方向找。
使用者看得到與看不到的範圍
最直覺的第一個判準，是使用者看不看得到。按鈕長什麼樣、動畫順不順、手機版排版跑不跑版，這些使用者一眼就能感受到的東西，幾乎都屬於前端；帳號密碼存在哪裡、訂單資料怎麼被記錄、金流驗證有沒有做對，這些使用者平常完全感受不到，卻是後端在背後撐著。
MDN 的說明把這個界線講得更精確：伺服器端程式碼決定哪些內容被回傳，負責驗證送出的資料、存取資料庫、把正確的資料送給使用者；瀏覽器端程式碼則主要負責讓頁面呈現、行為正確，也就是排版與互動效果這一層。使用者平常感受不到後端在做什麼，正因為它做得好、根本不會被注意到，一旦後端出錯，往往就是資料遺失、金流算錯這類大事，而不是版面跑掉這種小問題。
程式碼執行在瀏覽器或伺服器
第二個判準，是從技術執行位置去解釋為什麼前端和後端的能力天差地遠。前端程式碼下載到使用者的電腦或手機裡，在瀏覽器裡執行，先天上就碰不到伺服器端才有的資源；後端程式碼則是在遠端的伺服器上執行，才有權限去接觸資料庫、寄送通知信、對接金流系統。
MDN 對這兩者的說明幾乎是逐字對照：用戶端程式碼在瀏覽器裡執行，對底層作業系統幾乎沒有存取權限；伺服器端程式碼則對伺服器的作業系統有完整存取權限，開發者可以自由選擇程式語言。這個執行位置的差異，正是判斷這個新功能該找前端還是後端做的依據，單純調整畫面上的顯示方式，通常是前端就能處理；只要牽涉到存取資料、驗證身分、對接外部系統，幾乎都得交給後端。
系統出狀況時對接的角色不一樣
第三個判準，延伸到發包後的維護溝通情境。同一個症狀，頁面轉圈圈轉不停、表單按下送出沒反應、訂單卡在處理中不動，背後的原因可能出在前端邏輯寫錯，也可能出在後端伺服器或資料庫出問題。
多數人不需要自己判斷是哪一種，但知道這兩種角色負責的排查方向不一樣很有用：前端工程師會去檢查按鈕綁定的事件、頁面渲染的邏輯有沒有寫對；後端工程師則會去檢查伺服器的資源夠不夠、資料庫查詢是否異常緩慢、串接的服務有沒有逾時。遇到廠商彼此推說不是自己這邊的問題時，至少能聽懂雙方在講的是哪一個層面，而不是被兩邊的技術用語繞得更暈。
前端與後端之間靠 API 傳遞資料
前面把前端與後端當成兩個獨立的角色來拆，但實際運作時，兩者不是各做各的，而是靠一套請求與回應的機制持續交換資料，這套機制就是 API（應用程式介面）。
MDN 的說明把這個過程講得很具體：使用者點連結、送出表單、執行搜尋的時候，瀏覽器會發出一個 HTTP 請求（request），內容包含目標網址與方法（method）。最常見的兩種方法，GET 用來讀取現有的資料（例如打開一份商品清單頁面），POST 則用來送出或新增資料（例如新增一筆聯絡表單紀錄）。伺服器收到請求、處理完之後，會回傳一個 HTTP 回應（response），裡面帶著狀態碼，200 代表成功、404 代表找不到指定的資源、403 則代表沒有權限查看。
這也是報價單上「API 串接」這個項目在做的事，瀏覽器發出請求、伺服器處理後回傳結果。看到「串金流」、「串物流」、「串第三方簡訊服務」這類字眼，背後幾乎都是後端工作，因為要接資料庫、做身分驗證、跟外部系統的伺服器來回交換資料，這不是前端能單獨完成的事，前端頂多是負責把送出按鈕做出來、把回傳的結果顯示在畫面上。
多數網站案子前端與後端缺一不可
不少人發案時心裡想的是找一個人把網站做好就好，但只要網站有會員、金流、表單，或是後台可以自己編輯內容，前端與後端的工作量幾乎都同時存在，差別只在於是不是由同一個人分時段完成，不代表這個案子不需要後端。
MDN 舉的通則例子很能說明這件事：電商類型的網站，會用伺服器端程式建構搜尋結果，依照購買紀錄做出商品推薦；需要登入才能使用的服務，會用伺服器端程式儲存帳戶資訊，只讓通過驗證的使用者查看與操作自己的資料；社群類型的網站，則用伺服器端程式控制內容要分享給誰、誰能存取。這些看得到的功能，背後都代表著有一整套後端邏輯在運作。純靜態、沒有表單、沒有會員、沒有金流的網站，後端工作量確實可以很少，但只要多了登入、金流，或是後台可以自己編輯內容（現在常見的 CMS 幾乎都是這樣），就一定有後端在跑，不會因為看起來簡單就省略掉。
發案的時候，真正該問的問題不是這個案子要不要找後端工程師，而是這個功能屬於前端還是後端。絕大多數用得到會員、金流或可編輯後台的網站，答案本來就是兩者都要。
全端工程師身兼兩種角色的情況
不少報價單或人力配置裡會出現「全端工程師」這個角色，它不是第三種獨立的技術分工，而是同一個人同時具備前端與後端兩種能力，把原本該由兩個人分別負責的工作，全部攬在自己身上完成。
這種組合方式常見於案子規模較小、或改版頻率不高的情況，一個人要同時兼顧畫面呈現與資料邏輯兩塊，時間分配自然要抓得比較緊。看到「全端工程師」這個字眼時，值得留意的是對方要一人兼顧兩種完全不同性質的工作，評估時間規劃時可以多問一句，確認這樣的人力配置是不是真的吃得下這個案子的規模。
報價單上前端與後端項目的計算邏輯
前面確立的技術分工，套進報價單來看，會直接反映在計價邏輯上：前端費用通常跟著頁面數量與版型複雜度估算，工作量相對容易預期；後端費用的落差則可以很大，因為要看功能複雜度，一個單純的聯絡表單，和一整套會員加金流加權限系統，工作量天差地遠。搞懂這個邏輯，不是要學怎麼殺價，而是要看懂為什麼兩份報價單前端費用差不多，後端費用卻可能落差懸殊。
前端費用通常跟著頁面與版型計價
前端的工作單位相對明確，要切幾頁版型、需不需要 RWD（響應式設計）、有幾個斷點、有沒有客製化的動畫特效，這些項目在動工前大致都能先數出來。因為工作內容可以提前拆解、範圍清楚，前端報價的可預期性通常比較高。
也因為這樣，同一種類型的網站，不同廠商報出來的前端費用，落差通常不會太懸殊。版型數量與複雜度是看得見的，估價的依據相對客觀，不太容易出現同樣叫做前端、價差卻大到離譜的情況。
後端費用隨著功能複雜度大幅拉開
後端的工作量沒辦法只憑這是一個網站就估出來，而是要看有沒有會員系統、有沒有金流、權限規則複不複雜、要不要跟第三方系統串接。功能越貼近處理資料與商業邏輯，後端要投入的工作量就越吃重。
這也是為什麼兩份報價單，前端費用可能差不多，後端費用卻可能差出一大截。同樣叫做一個網站，一邊只是收集表單資料存進資料庫，另一邊要處理會員登入、金流交易、串接物流與簡訊通知，背後的工作量根本不是同一個級別。看報價單的時候，與其糾結某一行的數字，不如直接問清楚這個項目算前端還是後端、實際包含哪些功能，這比單看金額高低更能判斷這份報價合不合理。
網站發包時常見的分工誤會
發案過程中，有幾個誤會特別容易踩到，多半來自看不到後端在做什麼，才會先入為主覺得某個功能應該很簡單。
畫面顯示異常，原因常出在後端
使用者看到的症狀，永遠顯示在前端這一層，頁面轉圈圈轉不停、資料一直跑不出來、訂單狀態停滯不動，這些畫面看起來像是前端出了問題。但根源常常出在後端，資料庫查詢太慢、伺服器資源不夠用、串接的 API 逾時沒有回應。
MDN 對動態網站的說明能解釋這個現象：動態網站的頁面，是應用程式伺服器即時從資料庫抓資料、套進樣板才產生出來的，這整個過程如果出了狀況，使用者在瀏覽器端看到的就是頁面轉圈圈或空白畫面，但問題發生在伺服器與資料庫那一端，不是瀏覽器裡的程式碼壞掉。畫面壞了就一定是前端的問題，這個直覺聯想很多時候其實是誤會。
會員登入和金流，其實都是後端工作
另一個常見誤會，是覺得不就是加個登入按鈕、加個付款按鈕，應該很簡單。按鈕本身確實只是前端的幾行程式碼，但按下去之後要驗證帳號密碼對不對、要記住使用者已經登入、要跟金流商的伺服器對接交易資料、要確認交易結果之後寫回資料庫，這一長串都是後端在做。
MDN 的文件指出，HTTP 本身是一種無狀態（stateless）協定，伺服器與客戶端都不會記得先前的溝通內容，要完成像記住密碼、記住交易進行到一半這類任務，需要應用程式伺服器來處理。換句話說，記住使用者已經登入這件事，本身就需要後端的機制才做得到，前端沒有辦法單獨完成。也因為這樣，只要案子裡多了會員或金流功能，後端報價通常會比純表單的網站多跳一截，這不是廠商亂喊價，而是工作量真的多了一截。
採用 WordPress 之類系統，後端工作並未消失
不少人用現成的 CMS（內容管理系統）架站，會覺得後端工作已經不存在，用了現成系統，自然不用再找後端工程師。但實際上，後端（資料庫結構、核心邏輯、伺服器環境）只是已經有人事先寫好，不需要從零開發，並不代表客製化功能也一起消失了。
MDN 的說明可以拿來對照這個運作原理，像 MDN 或維基百科這類大型網站，是靠少數幾套 HTML 樣板加上龐大的資料庫產生出成千上萬個頁面，而不是每一頁手寫出來，這正是 WordPress 這類系統的運作邏輯，佈景主題樣板加上資料庫裡的文章內容，套出每一個頁面。只要牽涉到特殊的表單邏輯、跟外部系統串接、或是非典型的資料呈現方式，還是需要有人碰後端（PHP、資料庫查詢），並不是裝了現成系統這一步，就完全不需要後端知識，只是門檻降低、需要投入的工作量變少而已。
回頭看最開頭的問題，答案是一份報價單裡的「網站建置」，幾乎從來不是單一角色能獨自完成的工作。前端工程師負責的是使用者看得到、摸得到的畫面與互動，後端工程師負責的是使用者看不到、卻決定整個網站能不能正常運作的資料與邏輯，兩者用的技術不同，程式碼執行的位置不同，出狀況時該往哪個方向排查也不同。下次看到報價單上分別列出前端與後端兩個項目，或是聽到這個功能歸前端還是後端這樣的問題時，至少能判斷這兩塊各自在解決什麼問題，也比較容易看懂為什麼同樣是做一個網站，不同案子的工作量與費用會差這麼多。