前端工程化
一篇知乎上的問答，原文出處：http://www.zhihu.com/question/20790576
大公司裏怎樣開發和部署前端代碼？
主要有以下問題：
- 開發時的和部署時類庫的引用和存放是一致還是不同？
- 模塊放在項目中還是放在 CDN 之類服務器？
- 渲染網頁用 Nginx 還是其他動態語言的 Web 服務器？
- 製作網頁的流程，是先有設計師的稿，還是先看模塊？
- 會選擇用自己寫的模塊還是從社區尋找模塊？
以下爲ＵＣ 張雲龍，前端工程師 的一篇回答：
前百度工程師，曾負責百度 前端集成解決方案 的核心設計與開發工作。我現在稱這個領域爲【前端工程】。沒錯，這是我最愛嘮叨的問題域。
這是一個非常有趣的 非主流前端領域，這個領域要探索的是如何用工程手段解決前端開發和部署優化的綜合問題，入行到現在一直在學習和實踐中。
在我的印象中，facebook是這個領域的鼻祖，有興趣、有梯子的同學可以去看看facebook的頁面源代碼，體會一下什麼叫工程化。
接下來，我想從原理展開講述，多圖，較長，希望能有耐心看完。
---------------------------- 我是一條分割線 ----------------------------
讓我們返璞歸真，從原始的前端開發講起。上圖是一個“可愛”的index.html頁面和它的樣式文件a.css，用文本編輯器寫代碼，無需編譯，本地預覽，確認OK，丟到服務器，等待用戶訪問。前端就是這麼簡單，好好玩啊，門檻好低啊，分分鐘學會有木有！
然後我們訪問頁面，看到效果，再查看一下網絡請求，200！不錯，太™完美了！那麼，研發完成。。。。了麼？
等等，這還沒完呢！對於大公司來說，那些變態的訪問量和性能指標，將會讓前端一點也不“好玩”。
看看那個a.css的請求吧，如果每次用戶訪問頁面都要加載，是不是很影響性能，很浪費帶寬啊，我們希望最好這樣：
利用304，讓瀏覽器使用本地緩存。但，這樣也就夠了嗎？不成！304叫協商緩存，這玩意還是要和服務器通信一次，我們的優化級別是變態級，所以必須徹底滅掉這個請求，變成這樣：
強制瀏覽器使用本地緩存（cache-control/expires），不要和服務器通信。好了，請求方面的優化已經達到變態級別，那問題來了：你都不讓瀏覽器發資源請求了，這緩存咋更新？
很好，相信有人想到了辦法：通過更新頁面中引用的資源路徑，讓瀏覽器主動放棄緩存，加載新資源。好像這樣：
下次上線，把鏈接地址改成新的版本，就更新資源了不是。OK，問題解決了麼？！當然沒有！大公司的變態又來了，思考這種情況：
頁面引用了3個css，而某次上線只改了其中的a.css，如果所有鏈接都更新版本，就會導致b.css，c.css的緩存也失效，那豈不是又有浪費了？！
重新開啓變態模式，我們不難發現，要解決這種問題，必須讓url的修改與文件內容關聯，也就是說，只有文件內容變化，纔會導致相應url的變更，從而實現文件級別的精確緩存控制。
什麼東西與文件內容相關呢？我們會很自然的聯想到利用 數據摘要要算法 對文件求摘要信息，摘要信息與文件內容一一對應，就有了一種可以精確到單個文件粒度的緩存控制依據了。好了，我們把url改成帶摘要信息的：
這回再有文件修改，就只更新那個文件對應的url了，想到這裏貌似很完美了。你覺得這就夠了麼？大公司告訴你：圖樣圖森破！
唉~~~~，讓我喘口氣
現代互聯網企業，爲了進一步提升網站性能，會把靜態資源和動態網頁分集羣部署，靜態資源會被部署到CDN節點上，網頁中引用的資源也會變成對應的部署路徑：
好了，當我要更新靜態資源的時候，同時也會更新html中的引用吧，就好像這樣：
這次發佈，同時改了頁面結構和樣式，也更新了靜態資源對應的url地址，現在要發佈代碼上線，親愛的前端研發同學，你來告訴我，咱們是先上線頁面，還是先上線靜態資源？
- 先部署頁面，再部署資源：在二者部署的時間間隔內，如果有用戶訪問頁面，就會在新的頁面結構中加載舊的資源，並且把這個舊版本的資源當做新版本緩存起來，其結果就是：用戶訪問到了一個樣式錯亂的頁面，除非手動刷新，否則在資源緩存過期之前，頁面會一直執行錯誤。
- 先部署資源，再部署頁面：在部署時間間隔之內，有舊版本資源本地緩存的用戶訪問網站，由於請求的頁面是舊版本的，資源引用沒有改變，瀏覽器將直接使用本地緩存，這種情況下頁面展現正常；但沒有本地緩存或者緩存過期的用戶訪問網站，就會出現舊版本頁面加載新版本資源的情況，導致頁面執行錯誤，但當頁面完成部署，這部分用戶再次訪問頁面又會恢復正常了。
好的，上面一坨分析想說的就是：先部署誰都不成！都會導致部署過程中發生頁面錯亂的問題。所以，訪問量不大的項目，可以讓研發同學苦逼一把，等到半夜偷偷上線，先上靜態資源，再部署頁面，看起來問題少一些。
但是，大公司超變態，沒有這樣的“絕對低峯期”，只有“相對低峯期”。So，爲了穩定的服務，還得繼續追求極致啊！
這個奇葩問題，起源於資源的 覆蓋式發佈，用 待發布資源 覆蓋 已發佈資源，就有這種問題。解決它也好辦，就是實現 非覆蓋式發佈。
看上圖，用文件的摘要信息來對資源文件進行重命名，把摘要信息放到資源文件發佈路徑中，這樣，內容有修改的資源就變成了一個新的文件發佈到線上，不會覆蓋已有的資源文件。上線過程中，先全量部署靜態資源，再灰度部署頁面，整個問題就比較完美的解決了。
所以，大公司的靜態資源優化方案，基本上要實現這麼幾個東西：
- 配置超長時間的本地緩存 —— 節省帶寬，提高性能
- 採用內容摘要作爲緩存更新依據 —— 精確的緩存控制
- 靜態資源CDN部署 —— 優化網絡請求
- 更資源發佈路徑實現非覆蓋式發佈 —— 平滑升級
全套做下來，就是相對比較完整的靜態資源緩存控制方案了，而且，還要注意的是，靜態資源的緩存控制要求在前端所有靜態資源加載的位置都要做這樣的處理。是的，所有！什麼js、css自不必說，還要包括js、css文件中引用的資源路徑，由於涉及到摘要信息，引用資源的摘要信息也會引起引用文件本身的內容改變，從而形成級聯的摘要變化，大概示意圖就是：
好了，目前我們快速的學習了一下前端工程中關於靜態資源緩存要面臨的優化和部署問題，新的問題又來了：這™讓工程師怎麼寫碼啊！！！
要解釋優化與工程的結合處理思路，又會扯出一堆有關模塊化開發、資源加載、請求合併、前端框架等等的工程問題，以上只是開了個頭，解決方案纔是精髓，但要說的太多太多，有空再慢慢展開吧。或者大家可以去我的blog看其中的一些拆解：fouber/blog · GitHub
總之，前端性能優化絕逼是一個工程問題！
以上不是我YY的，可以觀察 百度 或者 facebook 的頁面以及靜態資源源代碼，查看它們的資源引用路徑處理，以及網絡請中靜態資源的緩存控制部分。再次讚歎facebook的前端工程建設水平，跪舔了。
建議前端工程師多多關注前端工程領域，也許有人會覺得自己的產品很小，不用這麼變態，但很有可能說不定某天你就需要做出這樣的改變了。而且，如果我們能把事情做得更極致，爲什麼不去做呢？
另外，也不要覺得這些是運維或者後端工程師要解決的問題。如果由其他角色來解決，大家總是把自己不關心的問題丟給別人，那麼前端工程師的開發過程將受到極大的限制，這種情況甚至在某些大公司都不少見！
媽媽，我再也不玩前端了。。。。5555
========================[ 10.29更新 ]========================
這裏更新一下：
在評論中， @陳鋼@fleuria @林翔 提到了rails，剛剛去看了一下，確實是完成了以上所說的優化細節，對整個靜態資源的管理上的思考於本答案描述的一致。很遺憾我直到今天（2014-10-29）才瞭解到rails中的assets pipeline。這裏向以上3位同學道歉，原諒我的無知。
不過整篇回答沒有講解到具體的解決方案實現思路，只是介紹了前端在工程化方向的思考，答案本身是可用的，瞭解rails的人也可以把此答案當做是對rails中assets pipeline設計原理的分析。
rails通過把靜態資源變成erb模板文件，然後加入<%= asset_path 'image.png' %>，上線前預編譯完成處理，不得不承認，fis的實現思路跟這個幾乎完全一樣，但我們當初確實不知道有rails的這套方案存在。
相關資料：英文版：The Asset Pipeline，中文版：Asset Pipeline
========================[ 10.31更新 ]========================
用 F.I.S 包裝了一個小工具，完整實現整個回答所說的最佳部署方案，並提供了源碼對照，可以感受一下項目源碼和部署代碼的對照。
源碼項目：fouber/static-resource-digest-project · GitHub
部署項目：fouber/static-resource-digest-project-release · GitHub
部署項目可以理解爲線上發佈後的結果，可以在部署項目裏查看所有資源引用的md5化處理。
這個示例也可以用於和assets pipeline做比較。fis沒有assets的目錄規範約束，而且可以以獨立工具的方式組合各種前端開發語言（coffee、less、sass/scss、stylus、markdown、jade、ejs、handlebars等等你能想到的），並與其他後端開發語言結合。
assets pipeline的設計思想值得獨立成工具用於前端工程，fis就當做這樣的一個選擇吧。
贊同92反對，不會顯示你的姓名
![]()
潘魏增，喜歡前端開發
雖然美團不是大公司，但在這裏寫一下我們的情況，僅供參考。
開發時的和部署時類庫的引用和存放是一致還是不同?
開發環境和部署環境的類庫代碼都是相同的，但物理位置不同。部署環境的類庫在CDN上，開發環境的類庫在開發服務器上。
模塊放在項目中還是放在 CDN 之類服務器?
模塊放在項目中，部署時都在CDN上。
渲染網頁用 Nginx 還是其他動態語言的 Web 服務器?
前面用ngnix做負載均衡，後面用apache做web服務器。
製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
先有設計師的稿再寫模塊，但很多時候並不需要設計師，因爲架子已經搭好了，界面規範和基礎元素都有，一般的界面前端工程師都能搞得定。
會選擇用自己寫的模塊還是從社區尋找模塊?
基礎框架用的YUI3，大部分二次開發的底層模塊，還有和業務緊密結合的UI模塊都是自己寫的。當然也會用社區寫的模塊，比如上傳組件、highcharts、Ace等。如果說怎麼選擇模塊的話，那就是具體情況具體分析了，總體原則有兩個：
- 能不自己寫，就不自己寫；
- 選擇最符合需求的，一般來說，要麼選最好的，要麼選最快出結果的
贊同30反對，不會顯示你的姓名
![]()
知乎用戶，上知乎，求歡樂
每一家大公司都不一樣，你只能尋找適合自己的流程。
一般來說，大公司面臨的問題就是複雜度。這就如同說，簡單的問題，你用匯編寫也肯定寫得出來，但更復雜的問題就需要用高級語言來抽象，否則其複雜度無法管理。此外，編譯不僅僅是能執行就可以，還要考慮目標平臺的執行效率。
對於大公司來說，用 CDN 是必然的，只是如何儘可能多地把靜態資源放到 CDN 上去。對於圖片這種數量有限的資源，一般新增多少都會放到 CDN 而不在乎成本。至於 JavaScript 這類打包方案有無窮組合的資源，則需要特別的優化了。最笨的辦法，當然是人手劃定幾個基本的打包方案，然後在 CDN 上部署。如果組合數有限，把所有打包方案都緩存到 CDN 也是可以的（沒有人請求的打包方案就不生成了）。更先進的辦法是，統計實際請求的打包方案，然後自動生成優化的打包方案，並且緩存在 CDN 上。
考慮到各家大公司採用的語言不一樣，用什麼服務器也是不確定的。甚至在一家公司內不同語言的系統用的服務器就不一樣。同理，不同團隊的合作方式不一樣，導致了設計到實現的流程也不一樣。就算在同一家公司內，也有可能同時存在最保守的團隊和最敏捷的團隊，一邊必須設計定稿了纔開始寫第一行代碼，另一邊想到什麼寫什麼覺得不好看再找設計師調整。
大公司一般都不會非常多的依賴於開源項目，而是自己做自己的項目然後開源。一方面這是 Not Invented Here 的問題；另一方面，確實通用的開源項目無法滿足某一家公司非常特定的某些需求，所以就算 idea 是很好的，大公司也會把 idea 搬過來再結合自己的需求做一個自己的版本。
贊同73反對，不會顯示你的姓名
![]()
小芋頭君，顏文字輸入法開發者，前端亂燉創始人，大…
最後有招聘，有意者留意一下，謝謝~~
雖然我們不是大公司，但是我也來佔個位，東西太多慢慢寫。
1.開發環境的被動式資源服務。
我們的開發環境是一個叫做ads的服務，在github上找得到，沒說開源，但是都是public的項目。
這個環境跑在每個人的機器和測試環境的機器和線上的機器上。
支撐了大搜車所有環境的靜態服務。
其實它做的工作比較簡單，無非是一個靜態文件服務器+一些實時處理。
原理也比較簡單，被動式處理，當你訪問一個文件的時候，就會去尋找這個文件的需要經過的處理中間件，讓文件以管道的形式通過這些中間件，最後返回一個處理過的文件內容。
例如jade和less，我們項目裏沒有編譯和打包的概念，你就寫就行了，然後任何環境裏訪問index.css其實都返回的是index.less的編譯結果，打包的過程和配置，都不需要關心。包括jade，less，js壓縮，requrejs打包合併都是用這樣的方式開發，你寫的是這樣，你看到的是另一樣，簡單粗暴，每個人只需要關心自己需要關心的事情，而不是項目的配置和打包之類的事情。
這個環境也無需配置，直接github clone下來，node app.js跑一下就再也不用管了。
2.如何開發和測試？
測試環境。通過切換host，我們有一個測試的域名，叫做http://f2e.souche.com。默認這個域名是指向一臺前端單獨的測試服務器的，通過nginx，轉發到一個ads的服務上。然後這個服務的背後是我們的前端資源文件，這個項目裏還跑了一個定時腳本，一分鐘pull一次從github更新代碼。
所以http://f2e.souche.com直接訪問，訪問的就是測試環境，這個環境的代碼永遠是最新的，它會定時從github拉取最新的代碼。
這個環境主要用來支撐測試和開發訪問網站的測試環境時候訪問到的前端資源的服務支撐。
本地開發。通過切換host，把http://f2e.souche.com切換到127.0.0.1，然後就把服務指向了本地的ads服務，本地的ads訪問的是本地的資源項目，所以任何修改直接會生效。
3.動態路徑和時間戳自動更新
在java程序中，我們實現了兩個跟前端資源有關的機制。
動態路徑。我們的java程序會根據環境的不同判斷來引用不同環境的資源文件，例如測試和線上，自動引用不同路徑的資源。
時間戳自動更新。我們前端維護了一個resource.properties，這個文件是一個時間戳的kv。每次發佈一個文件，就讓他對應的時間戳+1。然後java裏會定時去遠程讀取這個文件，如果讀取成功，就把這個kv解析到內存覆蓋之前的時間戳map，然後每次渲染模板的時候，會把對應的時間戳通過方法注入到模板中，模板中所有的資源引用都會根據這個時間戳配置動態改變資源的時間戳。
4.線上CDN和發佈
線上我們也有一臺前端自己的服務器，專門用來跑ads支撐線上服務。
每個請求進來（http://assets.souche.com是指向cdn的），會先通過阿里的cdn服務，然後如果cdn上有緩存副本，就會直接返回，如果沒有，則會去請求一臺（http://f2e-assets.souche.com不經過cdn)這臺是前端的線上服務，這臺服務器上的ads跟開發和測試環境的ads一模一樣，會動態處理，jade,less,js壓縮合並，requirejs打包，圖片自動優化。
發佈，就簡單了，就是簡單的文件拷貝，我們有個專門的發佈服務，也是nodejs寫的，會記錄每次發佈的時間內容，然後copy文件過去，並且更新上面提到的resource.properties。這樣就能自動更新時間戳了。
5.combo等個性化服務。
因爲採用上述的架構，所以我們可以靈活定製我們的靜態服務，因爲我們中間有一層cdn，後面架設了一個動態服務，這個動態服務是無所不能的。
例如combo，這樣的url：http://assets.souche.com/assets/js/$$lib/jquery-1.7.1.min.js,lib/require.js,lib/jquery.flexslider-min.js
實現起來很簡單，後臺收到請求的時候解析下路徑，把文件動態壓縮一下，然後合併返回給前端即可，沒啥好說的，但是就是夠方便。
6.被動式服務的性能。
因爲ads是被動式服務，它的好處是傻瓜化，壞處是有時候可能會有性能問題，還好我們可以適當規避。
例如常用的服務：jade,less,js壓縮合並，requirejs打包，圖片自動優化
其中jade,less的實時編譯是非常快的，基本感覺不出來，所以這兩個可以忽略。
js合併壓縮，requirejs打包，圖片優化是比較慢的。
所以在本地開發和測試環境的時候，這幾個服務是關閉掉的。也就是我們的js只有在線上纔是壓縮的，本地都是不壓縮的，當然訪問路徑都是一樣一樣的。
requirejs也不打包，本地和測試都採用異步加載，到了線上纔會使用打包出來的文件。
所有的所有，都沒有中間文件，所以在我們的前端項目裏，看不到css文件，看不到壓縮後的js文件，看不到jade編譯出來的html，看不到requirejs打包的文件，也看不到優化後的圖片文件。因爲所有的一切都是被動式。
而在線上，所有的性能問題都不是問題了，因爲有cdn，所以服務不會一直被請求，請求一次之後就被cdn緩存，再慢的服務，也是沒有問題的。
7.後言
大概先說這些，一直以來從來沒跟別人講過公司的前端工程環境，今天廢話了一通。
最近正在搞一個比較特立獨行的前後端分離，思路跟其他公司稍微不同，前後端分離最重要的不是技術實現，而是因爲涉及到了整個公司的開發架構，需要爲前端，開發，測試，都定製一套傻瓜化的開發環境和解決方案，重新制定開發流程，又涉及到產品運營等等，這些的推動纔是最複雜的，中間要解決很多問題，不能說爲了技術而技術，要爲每個職責解決問題才能夠推動整個項目。
另外，公司招聘前端開發，杭州大搜車，線上二手車O2O服務平臺，技術什麼的就不說了（java,ruby,nodejs,golang我們都玩），氛圍也懶得誇了（燒烤喝酒party妹子應有盡有），有興趣的直接聯繫我吧，郵箱：[email protected]
贊同1反對，不會顯示你的姓名
![]()
施宏，Javascript Coder
隔壁老王 贊同
原來做的大多是集成在發佈產品中的WEB前端，不是發佈到互聯網上的。是用戶安裝到自己的服務器上配合其他軟件使用的。類似於oracle的web管理界面之類。
部分問題如下：
開發時的和部署時類庫的引用和存放是一致還是不同?
:: 這個安裝性的自然不一致，開發js，css是未混淆和未合併的。部署（或者稱爲安裝，或者生成版本時）使用的是合併後的js和css
製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
:: 先有交互設計師設計幾乎所界面，操作模式，
再有視覺設計師設計出來常用場景和常用控件。要求覆蓋交互設計師的所有界面。
然後開發人員根據邏輯需求分到各個模塊中開發。
會選擇用自己寫的模塊還是從社區尋找模塊?
::多數是自己寫的模塊。使用的前端框架是自的框架（很重的框架，自完備型的）
贊同3反對，不會顯示你的姓名
![]()
CrazyCoder，Java開發工程師
我們公司是這樣做的
1，前後端完全分離
2，前段html javascript放在nginx裏
3，通過配置nginx的反向代理等，講前端的ajax請求轉發到後端服務器（前端全部是ajax請求）
4，後端採用分佈式部署在16臺wildfly上，前身就是jboss
贊同2反對，不會顯示你的姓名
![]()
知乎用戶，(☆_☆)
公司也算不小，但是我不是前端，只能大概說一下前端的情況。
開發時的和部署時類庫的引用和存放是一致還是不同?
開發時，前端會在自己機器上用nginx搭建一個簡單的前端環境來模擬CDN。
部署時，前端會用腳本壓縮合並JS，並上傳到CDN，路徑中存在版本號。
模塊放在項目中還是放在 CDN 之類服務器?
前端有單獨的SVN存放相關內容，但是部署上線時都會經過壓縮合並、加上版本號同步CDN。
渲染網頁用 Nginx 還是其他動態語言的 Web 服務器?
前端nginx，後端resin或tomcat。
所有靜態內容包括圖片、flash、js、css等全部由CDN完成（CDN那邊應該是nginx）。
製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
首先由設計師出設計稿，之後交由前端童鞋來切圖、做頁面。
通常，設計師會根據整個網站的風格來設計，這樣前端就可以複用已有的UI庫了，但這種情況不多。。。
會選擇用自己寫的模塊還是從社區尋找模塊?
我們有一套自己的前端庫，很大很全，各項功能都有。。很少從社區尋找。。
另外，贊成@Cat Chen的答案~
贊同1反對，不會顯示你的姓名
![]()
施磊，職業程序猿。愛科學。
黃凌翔 贊同
此問題沒有標準答案。我個人傾向於把前端開發者定義爲全棧程序員。這種個體全能是被工作分工困難倒逼出來的，是不利於工程的。
對於不同的技術棧的團隊，“前端”的工作內容出入較大，大公司的流水線上的工位也不是完全一致的，所以幾乎每家前端乾的事情都不一樣。如果僅僅討論部署和開發流程，上面幾位已經闡述了大方向和思路。這些的思路和方案完全就是傳統軟件工程過去積累出的經驗和方案的前端版本，只不過由於過去的“前端技術”的客觀條件和需求還不足以暴露出這些工程問題，所以基本沒人討論這些問題。
對比前端工程和傳統軟件工程的各個環節的解決方案數量，會發現前端的可選方案出奇的多。由此可見當下前端生態的混亂的程度。我認爲造成這種局面的原因在於，現在前端技術中的中心對象HTML文檔的模塊化方案還沒有事實標準， 所以目前生產環境中的所有的前端工程方案都只能借用其他的技術來實現HTML的模塊化，這一點其實是很彆扭的。這樣做也大大增加前端工程的複雜度。只有待這一問題有了大家認可的解決方案(有可能是Web Components)，前端技術纔能有較爲統一的最佳實踐。
贊同0反對，不會顯示你的姓名
![]()
桂林，遊的越來越遠，才明白水越來越深
開發時的和部署時類庫的引用和存放是一致還是不同?
開發時候用的源碼開發，部署的時候用的壓縮後的，性能優化！
模塊放在項目中還是放在 CDN 之類服務器?
你說的模塊是JS類庫嗎？對於前端的js和css文件放在獨立的服務器就行，主要設置緩存，減少客戶端的重複請求壓力；
渲染網頁用 Nginx 還是其他動態語言的 Web 服務器?
前端頁面的渲染都是瀏覽器來處理的，至於動態語言的運行，看你用的什麼開發語言來配置環境，Nginx和apache是用來運行php語言的，iis運行asp和c#,tomcate運行java語言
製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
當然先看模塊，有交互設計師做出原型，然後是設計人員根據原型做設計搞，最後是前端做頁面，最後是開發人員嵌入程序；
會選擇用自己寫的模塊還是從社區尋找模塊?
根據需求來，複雜的模塊可以採用第三方的，簡單的可以自己直接寫；
贊同0反對，不會顯示你的姓名
![]()
dong yan，初學者
我這公司還行。
開發時的和部署時類庫的引用和存放是一致還是不同?
還算一致
模塊放在項目中還是放在 CDN 之類服務器?
CDN
渲染網頁用 Nginx 還是其他動態語言的 Web 服務器?
渲染網頁是瀏覽器
製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
模塊
會選擇用自己寫的模塊還是從社區尋找模塊？
取最好的
贊同0反對，不會顯示你的姓名
![]()
李先生，在線教育
- 開發時的和部署時類庫的引用和存放是一致還是不同？
開發時，把應用代碼分支拉到本地，這些分支可以只包含你要修改的應用，也可包含你要引用的類庫。在本地搭建webserver，修改host映射到本地。開發過程中要引用類庫地址時直接引用線上地址，會被webserver中轉到本地代碼上。 發佈時直接發佈到對應機器上就行，代碼裏不用再修改線上路徑。
相關視頻課程推薦《站長必修課：網站是怎樣做出來的？》https://edu.51cto.com/sd/3be5b
