這篇文章不是給初學(xué)Django的人看的蚯斯，只是我在整理一級項目的時候遇見的一些問題和知識點的記錄
1.related_name
在模型寫的時候我們有一個字段就是related_name, 這個不是verbose_name, 他的作用是用于檢索方面窒所，我們在檢索某個作者的作品的時候冶共，會檢索作品表磕潮，然后匹配外鍵是否為該作者刁笙，這樣就能得到期望的作品
但是有個更簡便的寫法剂府，直接從作者那里寫（不過我認為底層還是檢索的作品）:
book = person.book_set.all()
//book = person.類名_set.all()
如果在book類中的外鍵寫了related_name字段佳励，那么我就可以用這個字段來代替查找:
related_name='person_books'
person.person_books.all()//查詢
2.DateField
如果是前后端分離的話跨新，一定要注意DateField給過來的格式是yyyy-mm-dd
不然后端會報錯
3.獲取POST數(shù)據(jù)
在Django中富腊，如果前端傳過來的數(shù)據(jù)是form-data格式，在獲取數(shù)據(jù)的時候我們一般要：
req = request.POST
request.POST就是表單中的數(shù)據(jù)域帐，是一個QueryDict
那么request.body是什么呢赘被？
request.body其實也是獲取請求體里面的數(shù)據(jù)，但是是一個字符串內(nèi)容俯树，如果前端用表單類型傳過來帘腹，你用json.loads()就會出錯，因為這個字符串不是json格式许饿。
那如果前端傳過來application/json格式的話阳欲，就可以用reqeust.body獲取字符串內(nèi)容，然后將其轉(zhuǎn)為字典(json.loads)陋率，那如果用request.POST呢球化？也會報錯的，因為這個字符串的格式不是原來的鍵值對格式瓦糟，而是json格式筒愚，那么Django就轉(zhuǎn)換不了
總結(jié):
- form-data 就只能用 request.POST
- application/json 就只能用 request.body 然后轉(zhuǎn)為字典
4.獲取GET數(shù)據(jù)
一般而言用GET請求很少用請求體炕吸，雖然我還沒研究過HTTP協(xié)議里面各個方法的區(qū)別整胃，但是GET方法最好在請求體里面什么都不放,參考:
https://my.oschina.net/airship/blog/3081424
獲取Query String里面的內(nèi)容，Django里是這樣:
request.GET
得到一個QueryDict對象片仿，里面都是URL里面帶的參數(shù)
然后GET請求體里面的東西在用reqeust.GET是獲取不到的，只能:
request.body
得到字符串內(nèi)容
總結(jié):
1.GET請求體一般不放東西陆淀，要獲取請求體內(nèi)的東西考余，只能用request.body
2.GET請求的參數(shù)獲取是 request.GET
3.POST請求獲取請求體是request.POST,也可以用request.body
可以參考官網(wǎng):https://docs.djangoproject.com/en/3.0/ref/request-response/
整理出的request和response對象常用方法
5.Cookie,Session
Django用來進行會話跟蹤的手段，還有一種token轧苫，這里不講楚堤。
這兩種手段都是用來記錄狀態(tài)的，是對HTTP無狀態(tài)的一種擴展含懊。
Cookie是保存在客戶端的身冬，我們這樣來理解Coookie，它就是一串字符岔乔，是一種憑證酥筝，客戶端登錄服務(wù)器之后，服務(wù)器發(fā)送這個憑證給客戶端雏门，下次客戶端訪問服務(wù)器的時候樱哼，直接把這個憑證show出來，服務(wù)器確認后剿配，就能讓客戶端訪問資源搅幅，而無需重復(fù)登錄。
一般呼胚，我們可以把用戶名或者用戶id保存在Cookie里面茄唐，這樣服務(wù)器就知道這個憑證對應(yīng)的客戶端信息了，但是這樣子的憑證未免也太脆弱了吧蝇更，Cookie是明文的沪编，如果我們僅僅就是放一個uid進去，用戶如果進行偽造怎么辦呢年扩？ 那他不就可以用其他人的賬號了蚁廓？
所以在Django里面我們一般要加鹽，加鹽就是一種簽名手段厨幻，比如說用戶1和用戶2相嵌，我們對Cookie加鹽之后，用戶1的Cookie:uid1 xxxxxxxxx , 用戶2的Cookie:uid2 xxxxxxxxx
后面的xxxxxx就是用戶的簽名(就是對應(yīng)用戶的特定字符串况脆，之所以說簽名饭宾，因為這個就好像是用戶自己簽名一樣)，如果居心不良的用戶想要偽造格了，比如說用戶1看铆，想要訪問用戶2的資源，雖然可以改為uid2,但是用戶1沒有后面xxxxx這么一串用戶2正確的簽名盛末，服務(wù)器是不會通過的
簽名的原理我也不太清楚弹惦，類似一種哈希函數(shù)否淤？
再次強調(diào)，簽名不是加密棠隐，Coookie還是可以在客戶端看到的叹括，所以一般Cookie不要存敏感信息（或者可以自己進行加密然后再發(fā)送）
(參考:https://segmentfault.com/q/1010000015154576?utm_source=tag-newest)
Session和Cookie的最大區(qū)別就是，Session存放在服務(wù)器端宵荒，也是鍵值對，這個key是一串隨機字符串净嘀，value就是要存的用戶信息报咳，客戶端還是要存放sessionid(即key)到本地，然后憑借這個挖藏，服務(wù)器端就搜索是否有這么一串隨機字符串暑刃，如果有就ok了
Cookie的使用:
response = HttpResponse()
response.set_signed_cookie('is_logged',user.id,salt="wobuzhidaoyongshenmejiamisuanfabijiaohaozLPQ",max_age=24*3600*7)
解釋:
set_signed_cookie(key,value,salt,max_age)
max_age單位是秒
