一般有哪些做法？如果保存在localstorage 具体保存什么信息呢？
存token，事实上不是存登录状态，而是存调用接口的token，只要token存在并且没有过期，就认为仍旧在登录状态。
保存在服务器的session上面
token用于用户登录检查，他只是个ID，具体内容在服务端。
登录状态其实没有所谓的“状态”。因为http本身就是没有状态的。所以客户端每次向服务器端发起请求，服务器端都要认证。
第一次：用户提供用户名和密码认证，服务器端通过"用户名+密码"对用户进行认证。通过后会服务器会生成一个认证标识。服务器端会保存这个认证标识，并且把认证标识响应给客户端，客户端也要保存这个认证标识。
第二次到第n次：客户端代理用户用保存的认证标识向服务器发起请求，服务器端通过"认证标识"对用户进行认证。
至于认证标识保存在客户端的cookie里还是localstorage，使用session机制还是自定义的token机制。都只是一个具体的实现方案。
如果是使用浏览器，通常cookie+session。如果是接口，比如app，通常自定义一个token机制。
为什么要这么做呢？因为每个请求都让用户输用户名和密码的话，用户会疯。
所以客户代理(浏览器)，代替用户。认证标识代替用户名和密码。
各种技术实现方案无非就是出于安全和效率考虑的
本质上，和用户每次输用户名和密码没什么区别
存token，事实上不是存登录状态，而是存调用接口的token，只要token存在并且没有过期，就认为仍旧在登录状态。
保存在服务器的session上面
token用于用户登录检查，他只是个ID，具体内容在服务端。
登录状态其实没有所谓的“状态”。因为http本身就是没有状态的。所以客户端每次向服务器端发起请求，服务器端都要认证。
第一次：用户提供用户名和密码认证，服务器端通过"用户名+密码"对用户进行认证。通过后会服务器会生成一个认证标识。服务器端会保存这个认证标识，并且把认证标识响应给客户端，客户端也要保存这个认证标识。
第二次到第n次：客户端代理用户用保存的认证标识向服务器发起请求，服务器端通过"认证标识"对用户进行认证。
至于认证标识保存在客户端的cookie里还是localstorage，使用session机制还是自定义的token机制。都只是一个具体的实现方案。
如果是使用浏览器，通常cookie+session。如果是接口，比如app，通常自定义一个token机制。
为什么要这么做呢？因为每个请求都让用户输用户名和密码的话，用户会疯。
所以客户代理(浏览器)，代替用户。认证标识代替用户名和密码。
各种技术实现方案无非就是出于安全和效率考虑的
本质上，和用户每次输用户名和密码没什么区别