幾乎所有建置系統都選擇使用watch機制來解決開發過程中需要反覆產生建置後檔案的問題，但在watch機制下，長期以來我們必須忍受修改完程式碼，保存完程式碼必須喝口茶才能刷新看看效果的問題。在這裡我們試著探討為什麼watch不是銀彈，並試著尋找更好的方案來解決這個問題。
watch基於的事實
當一個文件修改，我們能知道其修改可能導致的文件修改，那麼重新建構這些文件即可。
通常對於檔案A，建構成檔案B這種場景，這種對應關係是極好確定的。但現實場景下，建置過程往往不是那麼簡單。例如：
文件A ＋ 文件B（被文件A引用） －> 文件C
在這種場景下，檔案B的修改，可能難以定位哪些檔案需要重新跑建置任務，因為可能有許多檔案引用了檔案B。
除非我們建立一個依賴樹，並在每次檔案更新的情況下更新依賴樹，並根據新的依賴樹觸發檔案建置。但這對每一個插件都需要自行實現這個機制，而且極易出錯。故實際上watch機制只是重跑了整個task。所以當專案越來越大的時候，watch機制將越來越慢（因為越來越多檔案需要重新跑整個過程，即使透過快取減少了整個過程所需的耗時）。
解決方案
src直接可用
AlloyTeam & @ldjking，簡單來說直接讓src直接可跑，把構建任務放置在瀏覽器端，甚至根本不構建，既可做到及時修改及時刷新，在開發過程中減少了時間消耗。線下建置僅負責效能優化上的問題，不負責開發效率。
典型代表有LESS、React等。但也有一些問題：
難以在瀏覽器端實現優雅的建構方式，難以提供強大的功能進一步減少開發成本，大部分只能採用類似的方式引入腳本。
開發模式下的執行順序不一定和實際場景相同，可能導致隱形bug出現，例如實作一個HTML inline由於開發模式下inline是異步的，而發布模式下inline時同步的，產生莫名其妙的bug。
瀏覽器編譯效能堪憂，例如js版的sass，編譯速度幾乎無法忍受。
需要維護線上、線下兩套建置系統，增加了工具開發成本。
本機伺服器動態建置
一個事實是：在合理的規範支援下，我們可以從瀏覽器請求的文件，回溯到該文件建置過程中的入口文件。這樣我們就可以動態觸發一次建置過程。
透過在本地建立一個伺服器，讓伺服器捕獲請求後，在伺服器中動態建置。只要回溯到入口文件，我們便能將入口文件丟進gulp插件組成的管道中，則輸出便是瀏覽器所需的文件。
這樣我們就能解決上面的所有問題。
