中國(guó)有句古話叫做好馬配鞍，在太極的哲學(xué)里講究的就是平衡二字，我們?cè)诨ヂ?lián)網(wǎng)當(dāng)中亦是如此。在互聯(lián)網(wǎng)當(dāng)中要想成功必須具備很多種條件，比如資金、人脈、技術(shù)、運(yùn)營(yíng)策略等等，而任何一種條件都不能太差，哪怕你其他的條件是非常好的。

在細(xì)分到我們建網(wǎng)站的這個(gè)小方面上面來(lái)，也是一樣的。大家都知道建一個(gè)網(wǎng)站必不可少的三個(gè)要件就是域名、服務(wù)器、程序。而域名的質(zhì)量基本不會(huì)有太大的差別，特別是現(xiàn)在；而空間和服務(wù)器那就有所差異了，可以說(shuō)是一分錢一分貨了，而程序或者講源代碼的差異就更大了。實(shí)際上影響我們一個(gè)網(wǎng)站執(zhí)行效率和穩(wěn)定性以及響應(yīng)速度的主要原因還是我們的源代碼和服務(wù)器。

因?yàn)槲易约菏侵鳈C(jī)服務(wù)，經(jīng)常受到一些售后的工單，都是說(shuō)我提供給客戶的服務(wù)器或者空間卡死或者速度慢之類的，其實(shí)在一般的企業(yè)網(wǎng)站來(lái)說(shuō)因?yàn)榱髁勘緛?lái)就不大，一般不會(huì)造成服務(wù)器卡死匯總速度非常慢之類的問(wèn)題，更不要說(shuō)一天就出現(xiàn)好幾次的情況了。

很多次我都幫用戶解決這樣的問(wèn)題，最開(kāi)始的時(shí)候我都是把問(wèn)題放在自己身上，認(rèn)為這是我空間的問(wèn)題，比較再好的空間都有出問(wèn)題的的時(shí)候，只是這些問(wèn)題出現(xiàn)頻率太大了，而有的用戶卻基本不會(huì)出問(wèn)題。查看他們的程序發(fā)現(xiàn)，里面寫的不知道是一些什么東西，我一步步教用戶在本地用自己的電腦測(cè)試，結(jié)果發(fā)現(xiàn)依然看，讓他們終于相信不是服務(wù)器的問(wèn)題。

也是這樣的情況所以我今天想來(lái)談?wù)勥@個(gè)問(wèn)題，那就是我們很多人在做網(wǎng)站過(guò)程中根本沒(méi)有注意什么性能，他們做網(wǎng)站只會(huì)為了實(shí)現(xiàn)一個(gè)功能去做，尤其是那些專業(yè)的建站公司。常見(jiàn)的這類現(xiàn)象有。

前端方面結(jié)構(gòu)混亂。大家都知道一般來(lái)講前端不會(huì)太影響一個(gè)網(wǎng)站的性能和穩(wěn)定性，但是一旦完全不按照開(kāi)發(fā)的規(guī)范來(lái)做，那就不一定了。我發(fā)現(xiàn)了很多出自一些建站公司的作品，結(jié)果看了他們的前端寫作風(fēng)格讓我驚呆了。比如說(shuō)我們現(xiàn)在都是應(yīng)用DIV+CSS來(lái)做布局，結(jié)果他可能是一會(huì)兒CSS，一會(huì)兒用HTML風(fēng)格的樣式控制了，或者就是本來(lái)能公共使用的CSS樣式，結(jié)果卻偏偏要用style來(lái)做，又或者是本來(lái)可以應(yīng)用分組選擇器的，結(jié)果卻沒(méi)有搞得很多代碼多少冗余的，網(wǎng)頁(yè)的體積自然增大了。還有在JS腳本等問(wèn)題，很多人在寫頁(yè)面交互效果的時(shí)候，本來(lái)可以多個(gè)效果用同一段代碼就可以實(shí)現(xiàn)，結(jié)果卻要重復(fù)寫幾次，當(dāng)然能自己寫的代碼的還算好的，還有的朋友直接在網(wǎng)上下載源碼，本來(lái)我們只需要里面簡(jiǎn)單的某段代碼，卻把整個(gè)代碼都放進(jìn)了網(wǎng)站，結(jié)果輕則造成體積龐大，重則還會(huì)造成意想不到的錯(cuò)誤。

后端方面僅僅為實(shí)現(xiàn)功能。我看過(guò)很多用戶的程序，而且出問(wèn)題的網(wǎng)站基本上都是被所謂的二次開(kāi)發(fā)過(guò)，我發(fā)現(xiàn)原來(lái)的程序本來(lái)開(kāi)發(fā)很規(guī)范，比如PHP的源碼用了面向?qū)ο?，甚至現(xiàn)在主流的MCV模式。但看到二次開(kāi)發(fā)的就完全沒(méi)有這些東西，SQL語(yǔ)句直接寫在前端的模板上面，而且根本沒(méi)有什么封裝的概念出現(xiàn)。于是新寫成的代碼非?；靵y，而且冗余也特別多，而出問(wèn)題往往就是以后二次修改的時(shí)候因?yàn)楦静恢酪郧案牧耸裁炊斐傻腻e(cuò)誤。最大的問(wèn)題是，有的人做網(wǎng)站的時(shí)候可能自己寫了某一個(gè)模塊，比如說(shuō)報(bào)名系統(tǒng)或者投票系統(tǒng)之類的，在編寫代碼的過(guò)程中只是考慮能不能實(shí)現(xiàn)自己想要的功能，結(jié)果在用戶使用該系統(tǒng)的時(shí)候弄了一大推后臺(tái)連接數(shù)據(jù)庫(kù)的操作，造成網(wǎng)站響應(yīng)非常遲緩。

當(dāng)然實(shí)際上我們很多人做一些簡(jiǎn)單網(wǎng)站的時(shí)候更多的也是為了實(shí)現(xiàn)效果，而不會(huì)太多考慮其他的東西，特別是很多建站公司都是這么做的，因?yàn)閷?duì)于實(shí)際應(yīng)用來(lái)說(shuō)沒(méi)有特別大的影響。比如就算他們代碼寫得冗余，只要不出現(xiàn)致命錯(cuò)誤，雖然服務(wù)器資源占用大，但因?yàn)榫W(wǎng)站流量不高也不會(huì)出現(xiàn)嚴(yán)重后果。但如果當(dāng)流量成千上萬(wàn)的時(shí)候，他們做出來(lái)的網(wǎng)站顯然就不能正常使用了。

我之所以寫這樣一篇文章就是要告訴大家，在以后建網(wǎng)站的開(kāi)發(fā)過(guò)程中應(yīng)該規(guī)范點(diǎn)，而不要為了當(dāng)時(shí)方便完全只是考慮當(dāng)時(shí)的效果。其實(shí)我們很多朋友不是說(shuō)技術(shù)不行，而是就是太懶，因?yàn)樽龊酶鞣N規(guī)范在當(dāng)時(shí)來(lái)講確實(shí)相對(duì)費(fèi)時(shí)，但對(duì)于以后來(lái)講是非常好的習(xí)慣，實(shí)際上如果我們?cè)陂_(kāi)發(fā)過(guò)程中嚴(yán)格按照規(guī)范操作，考慮各種情況下可能遇到的問(wèn)題，其實(shí)反而以后會(huì)節(jié)省很多時(shí)間，而且可以保證我們的網(wǎng)站穩(wěn)定完全地運(yùn)行。