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

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