1.在模板標記中，extend和include沖突。用extend，include不能生效。原因是底層渲染的獨立機制設計造成的。
2.語句#coding:utf-8只有放在代碼文件的第壹行才能生效，如果放在註釋字符串之後可能會失效。
3.Rest請求前端開發帶來的躁動，Django的原生技術設施層簡化和事務封裝前移，導致業務層可以完全放在視圖中。同事再虛擬化的好處是跨業務模塊調用可以放在前端，保證了後端模塊之間的相切。
4.最好不要將帶有XSRF的POST表單放在帶有用戶生成的富文本內容的頁面上。前者可能竊取後者的令牌信息。
5.模板中比較邏輯運算符號= =兩邊必須有空格，否則會影響模板解析。
6.form.is_valid內部邏輯的Clean_data處理中拋出的異常不會被傳遞出去，只會變成form.is_valid()並返回false。
7.Django的業務層和視圖層怎麽劃分？壹個簡單的方法是將什麽級別的參數傳遞給業務層。個人覺得還是通過驗證的形式比較合適。
8.多級雅思兩個簡化技巧:1直接用except處理；2是中途返回的直接返回，不符合過程編程函數設計的原則，但是代碼比較簡潔。
9、Ubuntu制作環境不能打印Unicode中文，否則會導致錯誤。
10.由於Django的500機制和事務機制，DJango的視圖層對異常處理代碼的依賴性很弱。
11，模型表單定義:首頁沒有出現的字段必須排除或者為Null，但是Null會影響默認值，所以最好的辦法就是排除，否則即使是空的也會導致存儲表單時出錯。因為表單中缺少字段會用Null覆蓋默認值。定義字段比排除更方便的方法是定義字段元信息，這樣在添加未使用的字段時，模型就不必運行來更新表單定義。
12.數據清單中時區數據的格式化顯示必須放在模板中，並由日期等過濾器操作。如果直接用datetime的strifttime格式化，時區數據會丟失，出來的時間會變成格林威治標準時間。如果它由代碼中的Strifttime處理，那麽它可以由django處理。utils.timezone.local time方法，這樣出來的時間就正常了。
13，Django調試中的壹個問題:眾所周知，runserver啟動時，如果代碼發生變化，服務會重新啟動，但如果自定義標記代碼發生變化，服務不會重新啟動。
14和表單驗證的錯誤在舊版本中沒有文本信息。前段時間看文檔，發現新版本加強了錯誤，比如as_json()和as_text()。在舊版本中，我編寫了壹個函數來解析errors對象並生成反饋文本信息。
通過in 15，許多字段無法添加或刪除。出於擴展性的考慮，建議默認添加through，中間關系表可以添加壹個date_added字段，順便也可以給它們添加unique_together約束。但是使用through是有缺陷的:寫操作有點麻煩。所以，如果不加通過，就要改成加通過。最小的變化妳該怎麽辦？妳要先刪除這個ManyToMany字段，migrate才會生效，然後用through添加壹個ManyToMany字段，當然後臺數據的備份也會再次生效。這應該算是目前姜戈遷徙的壹個缺陷。