接口測試經驗筆記：
1.掌握什麼是接口測試；
2.接口測試的類型；
3.如何做接口測試；
4.接口測試的工具；（jmeter、postman）
測試學習交流羣，歡迎加入軟件測試組織
首先，什麼是接口呢？
接口一般來說有兩種，一種是程序內部的接口，一種是系統對外的接口。
系統對外的接口：比如你要從別的網站或服務器上獲取資源或信息，別人肯定不會把數據庫共享給你，他只能給你提供一個他們寫好的方法來獲取數據，你引用他提供的接口就能使用他寫好的方法，從而達到數據共享的目的，比如說咱們用的app、網址這些它在進行數據處理的時候都是通過接口來進行調用的。
程序內部的接口：方法與方法之間，模塊與模塊之間的交互，程序內部拋出的接口，比如bbs系統，有登錄模塊、發帖模塊等等，那你要發帖就必須先登錄，要發帖就得登錄，那麼這兩個模塊就得有交互，它就會拋出一個接口，供內部系統進行調用。
一、常見接口：
1、webService接口：是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。可以使用的工具有SoapUI、jmeter、loadrunner等；
2、http api接口：是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；
二、前端和後端：
在說接口測試之前，我們先來搞清楚這兩個概念，前端和後端。
前端是什麼呢，對於web端來說，咱們使用的網頁，打開的網站，這都是前端，這些都是html、css寫的；對於app端來說呢，它就是咱們用的app，android或者object-C（開發ios上的app）開發的，它的作用就是顯示頁面，讓我們看到漂亮的頁面，以及做一些簡單的校驗，比如說非空校驗，咱們在頁面上操作的時候，這些業務邏輯、功能，比如說你購物，發微博這些功能是由後端來實現的，後端去控制你購物的時候扣你的餘額，發微博發到哪個賬號下面，那前端和後端是怎麼交互的呢，就是通過接口。
前面說的你可能不好理解，你只需記住：前端負責貌美如花，後端負責掙錢養家。
三、什麼是接口測試：
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
OK，上面是百度百科上說的，下面纔是我說的
其實我覺得接口測試很簡單，比一般的功能測試還簡單（這話我先這樣說，以後可能會刪O(∩_∩)O哈！），現在找工作好多公司都要求有接口測試經驗，也有好多人問我（也就兩三個人）什麼是接口測試，本着不懂也要裝懂的態度，我會說：所謂接口測試就是通過測試不同情況下的入參與之相應的出參信息來判斷接口是否符合或滿足相應的功能性、安全性要求。
我爲啥說接口測試比功能測試簡單呢，因爲功能測試是從頁面輸入值，然後通過點擊按鈕或鏈接等傳值給後端，而且功能測試還要測UI、前端交互等功能，但接口測試沒有頁面，它是通過接口規範文檔上的調用地址、請求參數，拼接報文，然後發送請求，檢查返回結果，所以它只需測入參和出參就行了，相對來說簡單了不少。
四、接口組成
接口都有那些部分組成呢？
首先，接口文檔應該包含以下內容：
1、接口說明
2、調用url
3、請求方法（get\post）
4、請求參數、參數類型、請求參數說明
5、返回參數說明
由接口文檔可知，接口至少應有請求地址、請求方法、請求參數（入參和出參）組成，部分接口有請求頭header。
標頭 (header)：是服務器以HTTP協議傳HTML資料到瀏覽器前所送出的字串，在標頭與 HTML 文件之間尚需空一行分隔，一般存放cookie、token等信息
有同學問我header和入參有什麼關係？它們不都是發送到服務器的參數嗎？
OK，首先，它們確實都是發送到服務器裏的參數，但它們是有區別的，header裏存放的參數一般存放的是一些校驗信息，比如cookie，它是爲了校驗這個請求是否有權限請求服務器，如果有，它才能請求服務器，然後把請求地址連同入參一起發送到服務器，然後服務器會根據地址和入參來返回出參。也就是說，服務器是先接受header信息進行判斷該請求是否有權限請求，判斷有權限後，纔會接受請求地址和入參的。
五、爲什麼要做接口測試：
大家都知道，接口其實就是前端頁面或APP等調用與後端做交互用的，所以好多人都會問，我功能測試都測好了，爲什麼還要測接口呢？OK，在回答這個問題之前，先舉個栗子：
比如測試用戶註冊功能，規定用戶名爲6~18個字符，包含字母（區分大小寫）、數字、下劃線。首先功能測試時肯定會對用戶名規則進行測試時，比如輸入20個字符、輸入特殊字符等，但這些可能只是在前端做了校驗，後端可能沒做校驗，如果有人通過抓包繞過前端校驗直接發送到後端怎麼辦呢？試想一下，如果用戶名和密碼未在後端做校驗，而有人又繞過前端校驗的話，那用戶名和密碼不就可以隨便輸了嗎？如果是登錄可能會通過SQL注入等手段來隨意登錄，甚至可以獲取管理員權限，那這樣不是很恐怖？
所以，接口測試的必要性就體現出來了：
①、可以發現很多在頁面上操作發現不了的bug
②、檢查系統的異常處理能力
③、檢查系統的安全性、穩定性
④、前端隨便變，接口測好了，後端不用變
六、接口測試怎麼測：
在進行接口測試前，還需要了解：
1）、GET和POST請求：
如果是get請求的話，直接在瀏覽器裏輸入就行了，只要在瀏覽器裏面直接能請求到的，都是get請求，如果是post的請求的話，就不行了，就得藉助工具來發送。
GET請求和POST請求的區別：
1、GET使用URL或Cookie傳參。而POST將數據放在BODY中。
2、GET的URL會有長度上的限制，則POST的數據則可以非常大。
3、POST比GET安全，因爲數據在地址欄上不可見。
4、一般get請求用來獲取數據，post請求用來發送數據。
其實上面這幾點，只有最後一點說的是比較靠譜的，第一點post請求也可以把數據放到url裏面，get請求其實也沒長度限制，post請求看起來參數是隱式的，稍微安全那麼一些些，但是那只是對於小白用戶來說的，就算post請求，你通過抓包也是可以抓到參數的。所以上面這些面試的時候你說出來就行了。
2）、http狀態碼
每發出一個http請求之後，都會有一個響應，http本身會有一個狀態碼，來標示這個請求是否成功，常見的狀態碼有以下幾種：
1、200 2開頭的都表示這個請求發送成功，最常見的就是200，就代表這個請求是ok的，服務器也返回了。
2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了，
3、400 400代表客戶端發送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有權限訪問這個頁面，404代表沒有這個頁面
4、500 5開頭的代表服務器有異常，500代表服務器內部異常，504代表服務器端超時，沒返回結果
接下來再說接口測試怎麼測：
1）、通用接口用例設計
①、通過性驗證：首先肯定要保證這個接口功能是好使的，也就是正常的通過性測試，按照接口文檔上的參數，正常傳入，是否可以返回正確的結果。
②、參數組合：現在有一個操作商品的接口，有個字段type，傳1的時候代表修改商品，商品id、商品名稱、價格有一個是必傳的，type傳2的時候是刪除商品，商品id 是必傳的，這樣的，就要測參數組合了，type傳1的時候，只傳商品名稱能不能修改成功，id、名稱、價格都傳的時候能不能修改成功。
③、接口安全：
1、繞過驗證，比如說購買了一個商品，它的價格是300元，那我在提交訂單時候，我把這個商品的價格改成3元，後端有沒有做驗證，更狠點，我把錢改成-3，是不是我的餘額還要增加？
2、繞過身份授權，比如說修改商品信息接口，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改成功，我傳一個其他的賣家能不能修改成功
3、參數是否加密，比如說我登陸的接口，用戶名和密碼是不是加密，如果不加密的話，別人攔截到你的請求，就能獲取到你的信息了，加密規則是否容易破解。
4、密碼安全規則，密碼的複雜程度校驗
④、異常驗證：
所謂異常驗證，也就是我不按照你接口文檔上的要求輸入參數，來驗證接口對異常情況的校驗。比如說必填的參數不填，輸入整數類型的，傳入字符串類型，長度是10的，傳11，總之就是你說怎麼來，我就不怎麼來，其實也就這三種，必傳非必傳、參數類型、入參長度。
2）、根據業務邏輯來設計用例
根據業務邏輯來設計的話，就是根據自己系統的業務來設計用例，這個每個公司的業務不一樣，就得具體的看自己公司的業務了，其實這也和功能測試設計用例是一樣的。
舉個例子，拿bbs來說，bbs的需求是這樣的：
1、登錄失敗5次，就需要等待15分鐘之後再登錄
2、新註冊的用戶需要過了實習期才能發帖
3、刪除帖子扣除積分
4、......
像這樣的你就要把這些測試點列出來，然後再去造數據測試對應的測試點。
七、用什麼工具測
接口測試的工具很多，比如 postman、RESTClient、jmeter、loadrunner、SoapUI等，本人首推的測試工具是postman和jmeter，接下來就簡單介紹下如何使用這兩款工具進行接口測試，其他工具本次暫不介紹。
1）、Postman是谷歌的一款接口測試插件，它使用簡單，支持用例管理，支持get、post、文件上傳、響應驗證、變量管理、環境參數管理等功能，可以批量運行，並支持用例導出、導入。
jmeter是一款100%純Java編寫的免費開源的工具，它主要用來做性能測試，相比loadrunner來說，它內存佔用小，免費開源，輕巧方便、無需安裝，越來越被大衆所喜愛。
注：以下用例中所用地址皆爲本人在本地所搭的環境，外網無法訪問，見諒。
①、獲取用戶信息：該接口用於通過userid獲取用戶信息
請求地址：http://192.168.1.102:8081/getuser
請求方式：POST/GET
入參：
|
參數 |
數據類型(長度) |
是否必傳 |
備註 |
|
userid |
String |
Y |
用戶id |
出參：
|
參數 |
數據類型(長度) |
備註 |
|
code |
int |
狀態碼200爲成功，500爲異常 |
|
age |
int |
年齡 |
|
id |
string |
用戶id |
|
name |
String |
用戶姓名 |
postman中請求如下
jmeter中請求如下：
②、獲取用戶信息：需要添加header，Content-Type application/json
1.1 請求地址
http://192.168.1.102:8081/getuser2
1.2 請求方式
get/post
1.3 入參
|
參數 |
數據類型(長度) |
是否必傳 |
備註 |
|
userid |
String |
Y |
用戶id |
1.4 出參
|
參數 |
數據類型(長度) |
備註 |
|
code |
int |
狀態碼200爲成功，500爲異常 |
|
userid |
int |
用戶id |
|
name |
string |
用戶名稱 |
|
age |
int |
用戶年齡 |
postman測試如下，本次入參爲json類型，當然文檔中沒說非要用json，用其他方式也是可以的
jmeter測試如下
③、修改用戶餘額2
1.1 功能描述
功能描述：需要添加cookie，token token是寫死的token12345
1.2 請求地址
http://192.168.1.102:8081/setmoney2
1.3 請求方式
Post
1.4 入參
|
參數 |
數據類型(長度) |
是否必傳 |
備註 |
|
userid |
String |
Y |
用戶id |
|
money |
String |
Y |
修改的餘額數值 |
1.5 出參
|
參數 |
數據類型(長度) |
備註 |
|
code |
int |
狀態碼200爲成功，500爲異常 |
|
success |
String |
狀態 |
postman測試如下：
jmeter測試如下：
④文件上傳
postman：
jmeter:
⑤、請求webService接口
請求webService接口需要用到的工具是SoapUI，如下圖
在jmeter裏請求如下： 
1.什麼是接口？
接口測試主要用於外部系統與系統之間以及內部各個子系統之間的交互點，定義特定的交互點，然後通過這些交互點來，通過一些特殊的規則也就是協議，來進行數據之間的交互。
2.接口都有哪些類型？
接口一般分爲兩種：1.程序內部的接口 2.系統對外的接口
系統對外的接口：比如你要從別的網站或服務器上獲取資源或信息，別人肯定不會把數據庫共享給你，他只能給你提供一個他們寫好的方法來獲取數據，你引用他提供的接口就能使用他寫好的方法，從而達到數據共享的目的。
程序內部的接口：方法與方法之間，模塊與模塊之間的交互，程序內部拋出的接口，比如bbs系統，有登錄模塊、發帖模塊等等，那你要發帖就必須先登錄，那麼這兩個模塊就得有交互，它就會拋出一個接口，供內部系統進行調用。
接口的分類：1.webservice接口 2.http api接口
webService接口是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。
http api接口是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。
json是一種通用的數據類型，所有的語言都認識它。（json的本質是字符串，他與其他語言無關，只是可以經過稍稍加工可以轉換成其他語言的數據類型，比如可以轉換成Python中的字典，key-value的形式，可以轉換成JavaScript中的原生對象，可以轉換成java中的類對象等。）
3.接口的本質及其工作原理是什麼？
接口你可以簡單的理解他就是URL，工作原理就會說URL通過get或者post請求像服務器發送一些東西，然後得到一些相應的返回值，本質就是數據的傳輸與接收。
4.什麼是接口測試？
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
–百度百科
簡答的說就是通過URL像服務器或者其他模塊等，傳輸我們想傳輸的數據，然後看看他們返回的是不是我們預期想要的。
5.問什麼要做接口測試？
1.越底層發現bug，它的修復成本是越低的。
2.前端隨便變，接口測好了，後端不用變，前後端是兩撥人開發的。
3.檢查系統的安全性、穩定性，前端傳參不可信，比如京東購物，前端價格不可能傳入-1元，但是通過接口可以傳入-1元。
4.如今的系統複雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，接口測試可以提供這種情況下的解決方案。
5. 接口測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，可以減少人工迴歸測試人力成本與時間，縮短測試周期，支持後端快速發版需求。接口持續集成是爲什麼能低成本高收益的根源。
6. 現在很多系統前後端架構是分離的，從安全層面來說：
(1)、只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易）， 需要後端同樣進行控制，在這種情況下就需要從接口層面進行驗證。
(2)、前後端傳輸、日誌打印等信息是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。
6.怎樣做接口測試？
–由於我們項目前後端調用主要是基於http協議的接口，所以測試接口時主要是通過工具或代碼模擬http請求的發送與接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
–也可以用 接口自動化來實現，就是用代碼實現，框架和UI自動化差不多，發送請求用斷言來判斷。
7.接口測測試點是什麼？
目的：測試接口的正確性和穩定性；
原理：模擬客戶端向服務器發送請求報文，服務器接收請求報文後對相應的報文做處理並向客戶端返回應答，客戶端接收應答的過程；
重點：檢查數據的交換，傳遞和控制管理過程，還包括處理的次數；
核心：持續集成是接口測試的核心；
優點：爲高複雜性的平臺帶來高效的缺陷監測和質量監督能力，平臺越複雜，系統越龐大，接口測試的效果越明顯（提高測試效率，提升用戶體驗，降低研發成本）；
用例設計重點：通常情況下主要測試最外層的兩類接口:數據進入系統接口（調用外部系統的參數爲本系統使用）和數據流出系統接口（驗證系統處理後的數據是否正常）；
PS：設計用例時還需要注意外部接口提供給使用這些接口的外部用戶什麼功能，外部用戶真正需要什麼功能；
問題1.1、後端接口都測試什麼？
–回答這個問題，我們可以從接口測試活動內容的角度下手，看一下面這張圖，基本反應了當前我們項目後端接口測試的主要內容：
問題2、後端接口測試一遍 ，前端也測試一遍，是不是重複測試了？
–回答這個問題，我們可以直接對比接口測試和app端測試活動的內容，如下圖爲app測試時需要覆蓋或考慮內容：
從上面這兩張圖對比可以看出，兩個測試活動中相同的部分有功能測試、邊界分析測試和性能測試，其它部分由於各自特性或關注點不同需要進行特殊的測試，在此不做討論。接下來我們針對以上三部分相同的內容再進行分析：
1、基本功能測試：
由於是針對基本業務功能進行測試，所以這部分是兩種測試重合度最高的一塊，開發同學通常所指的也主要是這部分的內容。
2、邊界分析測試：
在基本功能測試的基礎上考慮輸入輸出的邊界條件，這部分內容也會有重複的部分（比如業務規則的邊界）。但是，前端的輸入輸出很多時候都是提供固守的值讓用戶選擇（如下拉框），在這種情況下測試的邊界範圍就非常有限，但接口測試就不存在這方面的限制，相對來說接口可以覆蓋的範圍更廣，同樣的，接口出現問題的概率也更高。
3、性能測試：
這個比較容易區分，雖然都需要做性能測試，但關注點確大不相同。App端性能主要關注與手機相關的特性，如手機cpu、內存、流量、fps等。而接口性能主要關注接口響應時間、併發、服務端資源的使用情況等。兩種測試時的策略和方法都有很大區別，所以這部分內容是需要分開單獨進行測試的，理論上來說這也是不同的部分。
綜論：
1、接口測試和app測試的活動有部分重複的內容，主要集中在業務功能測試方面。除此之外，針對各自特性的測試都不一樣，需要分別進行有針對性的測試，才能確保整個產品的質量。
2、接口測試可以關注於服務器邏輯驗證，而UI測試可以關注於頁面展示邏輯及界面前端與服務器集成驗證
3、接口測試持續集成：
對接口測試而言，持續集成自動化是核心內容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經實現了接口自動化，主要應用於迴歸階段，後續還需要加強自動化的程度，包括但不限於下面的內容：
a) 流程方面：在迴歸階段加強接口異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。
b) 結果展示：更加豐富的結果展示、趨勢分析，質量統計和分析等
c) 問題定位：報錯信息、日誌更精準，方便問題復現與定位。
d) 結果校驗：加強自動化校驗能力，如數據庫信息校驗。
e) 代碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提高代碼覆蓋率。
f) 性能需求：完善性能測試體系，通過自動化的手段監控接口性能指標是否正常。
4、接口測試質量評估標準：
a) 業務功能覆蓋是否完整
b) 業務規則覆蓋是否完整
c) 參數驗證是否達到要求（邊界、業務規則）
d) 接口異常場景覆蓋是否完整
e) 接口覆蓋率是否達到要求
f) 代碼覆蓋率是否達到要求
g) 性能指標是否滿足要求
h) 安全指標是否滿足要求
8.接口測試都要掌握哪些知識？
①瞭解系統及內部各個組件之間的業務邏輯交互；
②瞭解接口的I/O（input/output：輸入輸出）；
③瞭解協議的基本內容，包括：通信原理、三次握手、常用的協議類型、報文構成、數據傳輸方式、常見的狀態碼、URL構成等；
④常用的接口測試工具，比如：jmeter、loadrunner、postman、soapUI等；
⑤數據庫基礎操作命令（檢查數據入庫、提取測試數據等）；
⑥常見的字符類型，比如：char、varchar、text、int、float、datatime、string等；
如何學這些技能？
①系統間業務交互邏輯：通過需求文檔、流程圖、思維導圖、溝通等很多渠道和方式；
②協議：推薦《圖解http》這本書，內容生動，相對算是入門級的書籍，其他的還有《圖解tcp、IP》等；
③接口測試工具：百度這些工具，然後你會發現，好多的教學博客、相關問題解決方案、以及一些基於工具的書籍，當然，選擇合適的書很重要；
④數據庫操作命令：學習網站（W3C、菜鳥教程）、教學博客，以及一些數據庫相關書籍，入門級推薦：《mysql必知必會》、《oracle PL/SQL必知必會》等
⑤字符類型：還是百度，有句話這麼說：內事不決問百度，外事不決問Google。。。
如何獲取接口相關信息？
一般的企業，都會由開發或者對應的技術負責人員編寫接口文檔，裏面會註明接口相關的地址、參數類型、方法、輸入、輸出等信息，如果沒有，想辦法獲取。。。
接口文檔八要素：
封面：封面最好是本公司規定的封面，有logo，內容標題，版本號，公司名稱，文檔產生日期；
修訂歷史：表格形式較好些，包括：版本、修訂說明、修訂日期、修訂人、審覈時間審覈人等；
接口信息：接口調用方式，常用的GET/POST方式，接口地址；
功能描述：簡潔清晰的描述接口功能，比如：接口獲取的信息不包括哪些；
接口參數說明：每個參數都要和實際中調用的一樣，包括大小寫；參數的含義言簡意賅的說明，格式，是string 還是int 還是long等格式；
說明部分，說明參數值是需要哪裏提供，並詳細說明參數怎麼生成的，例如時間戳，是哪個時間段的，參數是否必填，一些參數是必須要有的，有些是可選參數等；
返回值說明：
①最好有一個模板返回值，並說明每個返回參數的意義；
②提供一個真實的調用接口，真實的返回值；
調用限制，安全方面：
加密方式，或者自己公司一個特殊的加密過程，只要雙方採用一致的加密算法就可以調用接口，保證了接口調用的安全性，比如常見的md5；
文檔維護：文檔在維護的時候，如有修改一定要寫上修改日期，修改人，對大的修改要有版本號變更；
9.其他相關知識？
get請求，post請求的區別：
1、GET使用URL或Cookie傳參。而POST將數據放在BODY中。
2、GET的URL會有長度上的限制，則POST的數據則可以非常大。
3、POST比GET安全，因爲數據在地址欄上不可見。
4、一般get請求用來獲取數據，post請求用來發送數據。
其實上面這幾點，只有最後一點說的是比較靠譜的，第一點post請求也可以把數據放到url裏面，get請求其實也沒長度限制，post請求看起來參數是隱式的，稍微安全那麼一些些，但是那只是對於小白用戶來說的，就算post請求，你通過抓包也是可以抓到參數的。（唯一區別就是這一點，上面3點區別都是不準確的）
http狀態碼：
1、200 2開頭的都表示這個請求發送成功，最常見的就是200，就代表這個請求是ok的，服務器也返回了。
2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了。
3、400 400代表客戶端發送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有權限訪問這個頁面，404代表沒有這個頁面。
4、500 5開頭的代表服務器有異常，500代表服務器內部異常，504代表服務器端超時，沒返回結果。
webservice接口怎麼測試：
它不需要你在拼報文了，會給一個webservice的地址，或者wsdl文件，直接在soapui導入，就可以看到這個webservice裏面的所有接口，也有報文，直接填入參數調用，看返回結果就可以了。
天氣預報wsdl地址：http://www.webservicex.net/globalweather.asmx?wsdl
cookie與session的區別：
1、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
2、cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙
考慮到安全應當使用session。
3、session會在一定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
考慮到減輕服務器性能方面，應當使用cookie。
4、單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、所以個人建議：
將登陸信息等重要信息存放爲session
其他信息如果需要保留，可以放在cookie中
如果您覺得本篇文章還不錯，歡迎點贊，轉發分享，感謝~~