前言
话说那时候还是学生，有一年春运，冒着风雪在北京北站买回家的票。悲催的是，特快车的票没买着，只买到了绿皮火车，L 打头的临时车。更悲催的是，原本33个小时的车程（特快不到20个小时），结果……走走停停超过了40多个小时，那煎熬，感觉永无尽头！
换个别的方式吧！于是我提前下车了，下车到了出站口，车站检票人员瞄了一眼我的车牌，眼神有点奇怪，估计是在想这小伙子是不是傻。还好我的票到站点是更远的站，不需要补票。其他没票的，就被嚷嚷着补票了——那个时候为了能回家，多少人是偷偷混上车的啊！ 以前是一把心酸一把泪，现在回忆起来那都是年少时难得的经历啊！
火车票与会话
火车票就好像我们后台的会话 Session一样，坐火车的这个过程就是我们的会话过程。我们需要先买票才能上车，下车出站票就失效了。本篇我们就来介绍Dio如何使用会话Session保持登录状态。首先请更新后台代码：https://gitee.com/island-coder/express-api，涉及到的接口如下：
- 注册新用户接口：http://localhost:3900/api/users，自行注册一个用户验证。
- 登录接口：http://localhost:3900/api/auth/login，登录成功后会将Session写入 Cookie。
- 退出登录接口：http://localhost:3900/api/auth/logout，退出成功后会清除后端 Session。
- 验证会话接口：http://localhost:3900/api/auth/check，检查登录会话是否有效。
先拿 Postman 走一遍流程做一下接口自测（我们的口号是真正的全栈：产品->设计->后端->前端->测试->运维一条龙服务）。过程见下图：
可以看到整个会话过程如下：
- 登录成功后，后端会返回 Cookie，对应的是一个
sessionId字段（字段名由后端定），这里就是登录人的会话信息。 - 每次请求相同域名的接口时候，Postman就会携带这个 Cookie 到后端，从而实现了会话过程的免登录验证。
- 如果退出登录，后端会清除会话信息，此时携带原有的会话信息请求会被后端认为是无效的。
这个过程对于我们使用 Postman 是无感知的，就好比我们用浏览器访问网页一样。但是对于 App 来说就不一样了。App本身是不会自动把登录会话信息携带到其他接口的，也就是说如果我们登录成功后不做会话处理，那么其他涉及到需要会话信息的接口全部会失败！这就好比我们买了张火车票，但是弄丢了，傻乎乎地跑到检票口才发现进不了站！！！
携带会话信息
怎么办？首先是在买票环节我们要把票保存好，在我们的 HttpUtil 中找一个严实的口袋保存车票，这个口袋就是 Dio 的 options.headers。当我们往 options 里存放信息时，每次请求都会携带这些信息到后端（除非请求本身将其参数覆盖）。
static void setCookie(String cookie) {
_dioInstance.options.headers['Cookie'] = cookie;
}
options 是 Dio 的默认请求配置，是一个BaseOptions对象，包括了很多属性，例如请求方法、响应类型、请求内容类型，连接超时时间、默认查询参数、请求头等等，通过设置 options 我们可以设置很多默认的参数，从而避免到处设置。常见的设置有：
- 连接超时：
connectTimeout，可以根据需要设置超时时长。 - 请求内容类型：
contentType，是一个字符串，默认是：application/json; charset=utf-8。可以在headers里设置也可以指定。 - 响应类型：
responseType，是一个枚举，默认是json。 - 默认查询参数：
queryParameters，一个Map对象，假设接口有默认的请求参数（如终端类型，版本号这类）可以加入到这里。 - 请求头：
headers，也就是我们今天的主角，可以设置请求的 cookie 信息或者其他参数（比如 JWT 的 token，后端要求传递的其他通用参数）。其中 cookie 固定使用 Cookie 字段存储，当然如果后端要自定义别的字段也是可以的。
找着了口袋，我们买完票后就需要把票存放起来，也就是登录成功后要获取到后端设置的 cookie，这个是在响应头里，调试的时候可以打印出来整个 headers 查看，如下所示：
实际 cookie 存在response.headers.map['set-cookie']中，注意这是一个数组，我们这里因为只有一个 cookie，因此取第一个元素再调用 HttpUtil的 setCookie即可。登录处理业务逻辑如下：
_handleSubmit(String username, String password) async {
EasyLoading.showInfo('请稍候...');
var response = await AuthService.login(username, password);
if (response != null && response.statusCode == 200) {
EasyLoading.showSuccess('登录成功');
if (response.headers.map['set-cookie'] != null) {
HttpUtil.setCookie(response.headers.map['set-cookie'][0]);
}
Navigator.of(context).pop();
} else {
EasyLoading.showInfo(response.statusMessage);
}
EasyLoading.dismiss();
}
这样，主要我们不退出登录，我们就可以携带会话信息与后端友好地交互了——碰到查票的你也不用心慌了！
清除会话信息
下车了，以前票默认是要回收的，可千万别只是返回到登录页面哦！退出登录时 调用后端的退出登录接口，成功后需要清除掉本地的存储的session。clearCookie方法很简单，只是将 headers 的 Cookie 设置为 null 即可。
void _logout() async {
var response = await AuthService.logout();
if (response != null && response.statusCode == 200) {
HttpUtil.clearCookie();
EasyLoading.showSuccess('已退出登录');
} else {
print('logout Failed');
}
}
static void clearCookie() {
_dioInstance.options.headers['Cookie'] = null;
}
验票
有了这个，我们就可以像乘务员那样验票了。验票这里只是调用了后端的一个需要会话信息的接口来验证。
void _checkSession() async {
var response = await AuthService.checkSession();
if (response != null && response.statusCode == 200) {
print(response.data);
EasyLoading.showSuccess('验票通过，持票人：' + response.data['loginUser']);
} else {
print('Request Failed');
}
}
运行效果如下图：
总结
本篇介绍了 Dio如何在登录后携带会话信息，以避免其他需要登录鉴权的接口请求失败。需要注意的是，会话信息在退出登录后需要及时清除，同时，会话信息可能还携带失效时间信息，可以根据失效时间来判断是否需要重新登录。另外，Dio官方推荐的 Cookie 管理插件是dio_cookie_manager。dio_cookie_manager使用拦截器来管理 Cookie，支持使用 CookieJar 来在内存存放 Cookie，或使用 PersistCookieJar持久化Cookie。
