1) mysite/wsgi.py：用於你的項目的與WSGI兼容的Web服務器入口。
2) migrate查看INSTALLED_APPS設置並根據mysite/settings.py文件中的數據庫設置創建任何必要的數據庫表，數據庫的遷移還會跟蹤應用的變化。你會看到對每次遷移有一條信息。如果你有興趣，可以運行你的數據庫的命令行客戶端並輸入dt (PostgreSQL), SHOW TABLES; (MySQL)或.schema (SQLite)來顯示Django創建的表。
3) 應用是一個Web應用程序，它完成具體的事項 —— 比如一個博客系統、一個存儲公共檔案的數據庫或者一個簡單的投票應用。 項目是一個特定網站中相關配置和應用的集合。一個項目可以包含多個應用。一個應用可以運用到多個項目中。
4) 當編寫一個數據庫驅動的Web應用時，第一步就是定義該應用的模型 —— 本質上，就是定義該模型所對應的數據庫設計及其附帶的元數據。
遷移完全依照於你的模型文件且本質上只是一個歷史記錄，Django通過這個歷史記錄更新你的數據庫模式使它與你現在的模型文件保持一致。
python manage.py migrate
python manage.py makemigrations polls(通過運行makemigrations告訴Django，已經對模型做了一些更改（在這個例子中，你創建了一個新的模型）並且會將這些更改存儲爲遷移文件。)
Django使用遷移文件來保存對模型的更改（即數據庫模式的更改）—— 所謂遷移文件其實就是磁盤上的普通文件。
python manage.py sqlmigrate polls 0001(sqlmigrate命令接收遷移文件的名字並返回它們的SQL語句)
python manage.py check；會檢查你的項目中的模型是否存在問題，而不用執行遷移或者接觸數據庫。
python manage.py migrate(migrate命令會找出所有還沒有被應用的遷移文件（Django使用數據庫中一個叫做django_migrations的特殊表來追蹤哪些遷移文件已經被應用過），並且在你的數據庫上運行它們 —— 本質上來講，就是使你的數據庫模式和你改動後的模型進行同步。)
實現模型變更的三個步驟：
修改你的模型（在models.py文件中）。
運行python manage.py makemigrations ，爲這些修改創建遷移文件
運行python manage.py migrate ，將這些改變更新到數據庫中。
python manage.py shell
export DJANGO_SETTINGS_MODULE="mysite.settings"
python >> import django >> django.setup()
5) python manage.py createsuperuser
admin.site.register(Question)
class QuestionAdmin(admin.ModelAdmin):
fields = ['pub_date', 'question_text']
admin.site.register(Question, QuestionAdmin)
當你需要爲一個對象修改管理選項的話，就按照這樣的步驟來做：創建一個模型管理對象，然後把該對象作爲第二個參數傳入admin.site.register()。
#class ChoiceInline(admin.StackedInline):
class ChoiceInline(admin.TabularInline):
model = Choice
extra = 3
class QuestionAdmin(admin.ModelAdmin):
fieldsets = [
(None, {'fields': ['question_text']}),
('Date information', {'fields': ['pub_date'], 'classes': ['collapse']}),
]
inlines = [ChoiceInline]
list_display = ('question_text', 'pub_date', 'was_published_recently')
list_filter = ['pub_date']
search_fields = ['question_text']
Django不支持按照隨便一個方法的輸出進行排序。
模板可以放在你的文件系統中Django所能訪問到的任何地方。 （運行Web服務器的用戶即是運行Django的用戶）。然而，把模板放在項目目錄下會是一個值得提倡的、應該遵循的約定。
DIRS 是加載Django模板時檢查的一個文件系統目錄列表；它是一個搜索路徑。
Django源文件在系統上的位置: python -c "import django; print(django.__path__)"
由於APP_DIRS設置爲True，Django會自動地在每個應用包下面查找一個templates/子目錄，留作備用。
視圖
Django使用叫做‘URLconfs’的配置來爲URL匹配視圖。 一個URLconf負責將URL模式匹配（使用正則表達式）到視圖。
url()參數: regex 正則表達式不會檢索URL中GET和POST的參數以及域名。性能方面的一個注意點：這些正則表達式會在URLconf模塊第一次載入的時候被編譯。
當Django找到一個匹配的正則表達式時，它就會調用view參數指定的視圖函數，並將HttpRequest對象作爲第一個參數，從正則表達式中“捕獲”的其他值作爲其他參數，傳入到該視圖函數中。如果正則表達式使用簡單的捕獲方式，值將作爲位置參數傳遞； 如果使用命名的捕獲方式，值將作爲關鍵字參數傳遞。
url()參數: name
命名你的URL。 這樣就可以在Django的其它地方尤其是模板中，通過名稱來明確地引用這個URL。 這個強大的特性可以使你僅僅修改一個文件就可以改變全局的URL模式。
當有人請求你的網站的一個頁面時，Django將加載mysite.urls Python 模塊，因爲ROOT_URLCONF設置指定了它。
模板命名空間
現在，我們可以直接將我們的模板放在polls/templates中（而不用創建另外一個polls子目錄），但實際上這是個壞主意。Django將選擇它找到的名字匹配的第一個模板文件，如果你在不同 的應用有相同名字的模板文件，Django將不能區分它們。我們需要將Django指向正確的模板，最簡單的方式是使用命名空間。具體實現方式是，將這些模板文件放在以應用的名字來命名的另一個目錄下。
Context是一個字典，將模板變量的名字映射到Python 對象。
常見的習慣是載入一個模板、填充一個context 然後返回一個含有模板渲染結果的HttpResponse對象。
forloop.counter指示for標籤已經循環多少次。
所有針對內部URL的POST表單都應該使用{% csrf_token %}模板標籤。
你應該在成功處理POST數據後總是返回一個HttpResponseRedirect。 這不是Django的特定技巧；這是那些優秀網站
python manage.py test polls查找polls 應用下的測試用例
它找到 django.test.TestCase 類的一個子類
它爲測試創建了一個特定的數據庫
它查找用於測試的方法 —— 名字以test開始
它運行test_was_published_recently_with_future_question創建一個pub_date爲未來30天的 Question實例
... 然後利用assertEqual()方法，它發現was_published_recently() 返回True，儘管我們希望它返回False
每個模型或視圖具有一個單獨的TestClass
爲你想測試的每一種情況建立一個單獨的測試方法
測試方法的名字可以描述它們的功能
{% load staticfiles %} 從staticfiles模板庫加載{% static %} 模板標籤。{% static %}模板標籤會生成靜態文件的絕對URL。
模型中的每個字段都是 Field 子類的某個實例。Django 根據字段類的類型確定以下信息：
數據庫當中的列類型 (比如: INTEGER, VARCHAR)。
渲染表單時使用的默認HTML 部件（例如，<input type="text">, <select>）。
最低限度的驗證需求，它被用在 Django 管理站點和自動生成的表單中。
主鍵字段是隻讀的。如果你在一個已存在的對象上面更改主鍵的值並且保存，一個新的對象將會在原有對象之外創建出來。