在debug之前, 我們可能已經(jīng)花費(fèi)了大量精力去模擬正式服務(wù)器上出現(xiàn)的錯(cuò)誤, 但最終發(fā)現(xiàn)這是由于正式服務(wù)器的settings文件設(shè)置和本地不同而 出現(xiàn)的問(wèn)題. 這時(shí)你的心情會(huì)是怎樣?
當(dāng)你在開(kāi)發(fā)django項(xiàng)目時(shí), 發(fā)現(xiàn)并修復(fù)了一個(gè)bug. 當(dāng)將這一commit push到服務(wù)器后, 你突然發(fā)現(xiàn)這一bug的出現(xiàn)完全是因?yàn)槟阈薷牧吮镜氐?settings文件而產(chǎn)生的, 而由于你的push, 又導(dǎo)致了服務(wù)器的宕機(jī). 這時(shí)你又會(huì)是怎樣的感受?
每個(gè)人都會(huì)從另一個(gè)程序員那里拷貝/黏貼settings文件內(nèi)容, 這難道不是違反了"不要重復(fù)自己"的原則嗎?

方案一
總是使用Django自帶的數(shù)據(jù)庫(kù)API。它會(huì)根據(jù)你所使用的數(shù)據(jù)庫(kù)服務(wù)器（例如PostSQL或者M(jìn)ySQL）的轉(zhuǎn)換規(guī)則，自動(dòng)轉(zhuǎn)義特殊的SQL參數(shù)。這被運(yùn)用到了整個(gè)Django的數(shù)據(jù)庫(kù)API中，只有一些例外：
傳給 extra() 方法的 where 參數(shù)。 (參考 附錄 C。) 這個(gè)參數(shù)故意設(shè)計(jì)成可以接受原始的SQL。
使用底層數(shù)據(jù)庫(kù)API的查詢。