前端停止資料庫查詢如下：
使用SQLServer配置管理器啟動或停止SQLServerBrowser服務在「開始」菜單中，右鍵單擊「所有程序」，依次指向「MicrosoftSQLServer2008R2」、「配置工具」，然後單擊「SQLServer配置管理器」。
在SQLServer配置管理器中，單擊「SQLServer服務」。在詳細信息窗格中，右鍵單擊「SQLServerBrowser」，然後單擊「啟動」或「停止」。
『貳』 雲伺服器部署前端服務
yum install -y nginx
進入/etc/ngin文件夾，並且新建自己的配置目錄如：myconfig，並且進入此目錄，衫老燃新建一個配置文件如：ghmall.conf，編輯以下內容並且保存：
上傳前端文件（執行npm run build後，項目下會生成一個dist文件夾）至該配含友置文件中配置或虛的地址如：/usr/portal/ghmall-portal/dist
進入/etc/ngin文件夾，編輯配置文件：vim nginx.conf
修改為自己的server配置：
server {
listen 9527;
server_name localhost;
location / {
root /usr/portal/ghmall-portal/dist;
}
location /ghmall/ {
proxy_pass http://localhost:8118;
}
然後重新啟動nginx：nginx -s reload
輸入systemctl start nginx開啟 nginx 服務
瀏覽器上輸入yourIpAdress:9090/便可以訪問你的頁面了
另外systemctl status nginx可以查看 nginx 的運行狀態
以及systemctl stop nginx可以關閉 nginx 服務
『叄』 前端如何盡量正確地處理ajax的異常
如今前端領域是MVVM框架的天下，組件庫也層出不窮，但是，並沒有一個知名的組件庫提供ajax異常的成熟解決方案，所以今天我們就來研討一下，如何盡量正確地處理異常。
從業務上簡單說，凡是code不是200的，都是異常。這里code可以是HTTP狀態碼，也可以是響應體的code，就不細究了，反正本質沒差別。然後，根據code的不同，又可以細分成401 403 404 500等等。
如果你的後端夥伴以HTTP狀態碼表示404，以響應體code表示其他錯誤，而且你又無法勸說他們，那麼你應在axios的攔截器里把各種情況全考慮進去，比如：
超時很簡單，axios也支持，設定超時閾值即可。超時跟無響應的區別是，超時意味著HTTP三次握手成功，但是得不到響應體，瀏覽器知道介面是存在的，但是響應體又在規定時間內沒有拿到。無響應是根本無法HTTP握手，也就無法獲知介面存在。
處理超時，通常做法是在攔截器里重新請求一遍，還是超時的話就視為伺服器錯誤。
得不到響應又分成2種，可能是網斷了，也可能是伺服器停機了。
苛刻地說，你應分辨這2種情況，並給出不同的提示，畢竟網斷了，用戶可以尋找別的聯網方式，而伺服器停機了就給個重連按鈕，讓用戶有事沒事的嘗試重連一下。
關於解決方案，首先說，XHR對象無法區分到底斷網還是伺服器停機，axios對於2種情況都返回'Network Error'。在得到這個反饋之後，你接下來可以有這2種解決辦法：
你可以將 https://api.map..com/images/blank.gif 改成其他伺服器穩定且位元組小的圖片。或許你可以做一張幾位元組的圖片，傳到一個非常牛逼的CDN上。
MDN手冊： https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/connection
它不支持IE，就算你不在乎這一點，那麼它是不是一定準呢？對於需要登錄的VPN網路，它是否准呢？我也不知道，總體說，它真的不是最佳的方案。我推薦用方案1。
很簡單，分為3種：
通常，一個介面，只需要按照其中一種去處理即可，優先順序就是上面書寫順序。
容器內錯誤提示肯定是內容區的介面出錯才會出現。
處理方式：
局部報錯比較容易理解，比如一個List的介面出錯，那麼，上策是應當給這個容器盡量撐高到有內容時的高度，然後居中給一個錯誤圖標和錯誤描述。中策是不考慮有內容時候的高度，只讓錯誤提示和錯誤描述撐起一定高度即可。都不算錯。如果容器很小，比如就是一個3位數值，那麼用一個 - 表示錯誤也可以。
頁面整體報錯稍微復雜，比如一個左右結構的內容管理系統，前置介面有userInfo介面、全局字典介面、全局路由介面等，這些介面與眾不同的地方在於它們是基礎介面，它們出錯的話，網站乾脆就不能用，頁面骨架也是錯亂的，這種情況下可以有2種解決辦法：一是跳轉到專門的5xx報錯頁面，頁面中央有錯誤圖標、錯誤提示，以及「返回上一頁」的按鈕；二是用白板遮罩覆蓋瀏覽器視口，居中放一個錯誤圖標和錯誤文字以及「刷新頁面」的按鈕，本質是用一個fixed的遮罩壓住瀏覽器全部面積。用哪種方案都可。所以你要做的是決定哪些介面屬於全局報錯，哪些介面屬於局部報錯，並做不同的處理。
報錯內容：
根據ajax異常的分類，可能至少能分出3種：網路錯誤、伺服器宕機、伺服器錯誤。具體用什麼圖標和文字我就不多說了。
組件化：
容器內報錯應盡量組件化。該放返回上一頁或刷新按鈕的，一定要放按鈕。
排他性：
只要做了容器內報錯，就不要做另外報錯了。這也說明了一點，就是在axios攔截器里彈toast或者modal是愚蠢的方案，我在別的文章也提到過這種觀點。不做容器內報錯的情況，才應該考慮其他3種情況。
什麼樣的場景下使用容器隱藏？
比如頁面有一個角落顯示你的粉絲數、關注數、評論量……。如果有獲取到數據，則讓這個容器出現，沒有的話，則容器就保持隱藏。這一類場景往往應用於非主要內容，比如側邊欄的小內容塊。
由於這只適用於非主要內容，那麼主要內容也會有它自己的報錯，所以，你不必擔心用戶看不到「網路出錯」這類錯誤提示。
先簡單對比一下toast和modal。
很簡單，toast就是輕提示，不需要手動關閉，modal就是重提示，需要手動關閉。採用哪個，只要站在用戶角度思考問題就好了。比如有人說，異常應當用重提示。可以這么絕對化么？不可以。比如你在某個頁面點贊，提示你 「您已經點過贊了」 ，這用重提示嗎？肯定toast就夠了。同樣的，成功提示一定用輕提示嗎？比如提示 「感謝參與，工作人員將在3~5個工作日內聯系你」 ，這么長，能toast？能一閃而過？
什麼介面適用彈出提示？簡單說，只要跟UI顯示不相乾的，都最好是使用彈出提示。比如這幾種場景：
先說上傳數據斷網之類的錯誤，通常用modal，因為modal能夠攔截用戶動作，避免重復上傳，而且，還能給用戶足夠的時間讓用戶看清楚出錯原因，避免無謂的重試。
然後說數據內容錯誤，無論是表單提交，還是點個贊，錯誤提示一般用toast，畢竟用戶可能只是不小心填錯的，看一眼然後趕緊改正就好了。
最後說401錯誤，有2種做法，一是用modal，因為一般要強制用戶轉到登錄頁，但是轉之前也得讓用戶看明白為什麼要轉，所以可以先modal提示，點擊確定就跳轉到登錄頁；二是用toast，但是需要先跳轉，然後在登錄頁上提示toast「請先登錄」。
警告條
警告條是可關閉的、永久生命的、又不妨礙用戶繼續操作的彈出組件，一般在頁面頂部，或者在用戶操作區域的附近。什麼場景用警告條？
比如的MD編輯器，你只要輸入，就會自動給伺服器發送數據，頻率很快，有時候因為網路或者伺服器的問題，會出現保存失敗的可能性，這時候就會在頁面頂部出現一個比較長時間的警告條，告訴你保存失敗，但你依然可以繼續寫，什麼時候網路正常了，什麼時候toast才會自動消失，當然你也可以手動關閉它。
總之，toast、modal、警告條究竟什麼場合使用，要根據產品、業務具體而定，要注意優先使用容器內報錯和容器隱藏。