Cookie 与 Session 及 Spring MVC 返回值技术详解(完整交互流程)
作者:sugar__salt
一、Cookie 与 Session 核心知识点
1.1 HTTP 无状态特性
HTTP(HyperText Transfer Protocol)是无状态协议。所谓"无状态",指的是协议本身不会记录任何历史请求信息——服务器处理完一次请求后,就"忘记"了这次请求是谁发的。下次同一客户端再发请求,服务器依然"素不相识"。
打个比方:你打客服电话,每次接通都是不同的接线员,你必须把问题从头到尾重新说一遍。
然而实际业务中,"记住用户"是刚需——登录状态要保持、购物车不能刷新就清空、表单要跨页面填写。正是这种业务有状态与协议无状态之间的矛盾,催生了 Cookie + Session 机制。
1.2 通俗类比:医院就诊卡与档案
理解 Cookie 与 Session 最好的方式,是类比就诊流程:
| 概念 | 类比 | 存储位置 | 存放内容 | 安全性 |
|---|---|---|---|---|
| Cookie | 就诊卡 / 学生证 | 客户端(浏览器) | 仅存放唯一标识(SessionID) | 低,本地可伪造 |
| Session | 医院档案 / 学校学籍 | 服务端(服务器内存) | 完整用户隐私数据 | 高,无法伪造 |
完整就诊流程:
- 首次挂号:出示身份证(账号密码),医院给你一张就诊卡,同时在医院内部系统建立你的档案;
- 后续就诊:每次刷卡,医生就能调出你的全部历史病历;
- 退号注销:销毁就诊卡与档案的绑定关系。
对应到 Web 开发:
- 首次登录:校验账号密码,服务端创建 Session,分配唯一
SessionID; - 下发令牌:通过
Set-Cookie响应头将SessionID存入浏览器 Cookie; - 后续请求:浏览器自动携带 Cookie,服务端提取
SessionID,匹配对应用户的 Session; - 注销:清除 Session 并删除客户端 Cookie,解除绑定。

1.3 Cookie 与 Session 完整交互流程
实战代码:在 Spring Boot 中操作 Cookie 和 Session
以下代码完整演示了从 Cookie 读取、Session 存取的三种方式:
package com.spring.demo;
import jakarta.servlet.http.Cookie;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpSession;
import org.springframework.web.bind.annotation.*;
@RestController
@RequestMapping("/request2")
public class RequestController2 {
// ========== 一、读取 Cookie ==========
/**
* 方式一:通过 HttpServletRequest 手动遍历 Cookie 数组
* 适用场景:需要批量处理所有 Cookie 时
*/
@RequestMapping("/getCookie")
public String getCookie(HttpServletRequest request) {
// 通过 request 对象获取所有 Cookie
Cookie[] cookies = request.getCookies();
if (cookies != null) {
for (Cookie cookie : cookies) {
// 打印每个 Cookie 的 key 和 value
System.out.println(cookie.getName() + " : " + cookie.getValue());
}
}
return "cookie读取成功";
}
/**
* 方式二:通过 @CookieValue 注解直接获取指定 Cookie 的值
* 适用场景:只需要某个特定 Cookie 时,代码更简洁
*/
@RequestMapping("/getCookie2")
public String getCookie2(@CookieValue("class") String className) {
return "cookie读取成功, className:" + className;
}
// ========== 二、操作 Session ==========
/**
* 设置 Session 属性
* request.getSession() 无参调用:有则返回,无则新建
*/
@RequestMapping("/setSession")
public String setSession(HttpServletRequest request) {
HttpSession session = request.getSession(); // 获取或创建 Session
session.setAttribute("name", "zmt"); // 向 Session 中存入数据
return "session设置成功";
}
/**
* 读取 Session — 方式一:通过 request.getSession()
*/
@RequestMapping("/getSession")
public String getSession(HttpServletRequest request) {
HttpSession session = request.getSession();
// 从 Session 中取出之前存入的数据
String name = (String) session.getAttribute("name");
return "session读取成功, name:" + name;
}
/**
* 读取 Session — 方式二:直接注入 HttpSession 参数
* Spring 会自动将当前请求对应的 Session 注入进来
*/
@RequestMapping("/getSession2")
public String getSession2(HttpSession session) {
String name = (String) session.getAttribute("name");
return "session读取成功, name:" + name;
}
/**
* 读取 Session — 方式三:通过 @SessionAttribute 注解
* 最简洁的方式,直接获取 Session 中某个属性的值
*/
@RequestMapping("/getSession3")
public String getSession3(@SessionAttribute("name") String name) {
return "session读取成功, name:" + name;
}
// ========== 三、读取请求头 ==========
/**
* 方式一:通过 request.getHeader() 获取
*/
@RequestMapping("/getHeader")
public String getHeader(HttpServletRequest request) {
String userAgent = request.getHeader("User-Agent");
return "header读取成功, userAgent:" + userAgent;
}
/**
* 方式二:通过 @RequestHeader 注解直接获取
*/
@RequestMapping("/getHeader2")
public String getHeader2(@RequestHeader("User-Agent") String userAgent) {
return "header读取成功, userAgent:" + userAgent;
}
}代码思路解析:
- Cookie 的读取有两种姿势:传统
request.getCookies()返回数组需要手动遍历,不够优雅;Spring 提供了@CookieValue注解,一行搞定,推荐日常使用。 - Session 的读取有三种方式:
request.getSession()最基础;直接注入HttpSession参数利用了 Spring 的依赖注入能力;@SessionAttribute最简洁,适合确定属性名存在的场景。 - 请求头的读取同理:
request.getHeader()是原生 API,@RequestHeader是 Spring 封装的注解。
重点理解:Controller 方法参数中的
HttpServletRequest、HttpSession等对象,都是由 Spring 框架在调用方法前自动创建并注入的——开发者只管声明参数,框架负责"送货上门"。
1.4 Cookie 与 Session 核心区别
| 对比维度 | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端浏览器 | 服务端(内存/Redis/数据库) |
| 存储容量 | 单个 ≤ 4KB,单域名总数约 20 个 | 理论上无限制,取决于服务器 |
| 安全性 | 明文存储,可被篡改或伪造 | 数据存于服务端,安全性高 |
| 生命周期 | 可设置过期时间,关闭浏览器不失效 | 默认 30 分钟无操作失效 |
| 性能影响 | 随每次请求发送,占用带宽 | 大量用户时占用服务器内存 |
| 关联方式 | 通过 JSESSIONID 与 Session 关联 | 以 SessionID 为唯一标识 |
关键要点:
- 二者非强制绑定。Cookie 可以独立存储普通业务数据(如主题偏好),不必存放 SessionID;SessionID 也不一定要通过 Cookie 传递,可以在 URL 后拼接
;jsessionid=xxx(但现已不推荐,安全性差)。 - SessionID 是桥梁。它把"客户端的小纸条"和"服务端的档案柜"连接了起来。
- 服务重启数据丢失。默认 Session 存储在服务器内存中,一旦服务重启,所有登录态全部丢失。生产环境通常将 Session 外置到 Redis 等中间件来解决这个问题。
1.5request.getSession()参数规则(容易踩坑)
这是 Spring 开发中最容易被忽略的细节之一:
// 无参 / 参数为 true(默认行为) HttpSession session = request.getSession(); // 等价于: HttpSession session = request.getSession(true); // 行为:根据 Cookie 中的 JSESSIONID 查找 Session // → 找到了 → 返回已有 Session // → 没找到 → 新建一个 Session 并返回 // 参数为 false HttpSession session = request.getSession(false); // 行为:根据 JSESSIONID 查找 Session // → 找到了 → 返回已有 Session // → 没找到 → 返回 null(不创建!)
我们看看源码:

Returns the current session associated with this request, or if the request does not have a session, creates one.
实用场景:用户已登录才需要 Session 的场景,建议用
getSession(false)判断是否已有会话,避免为匿名访问者创建大量无用 Session 浪费内存。
二、Spring MVC 页面跳转与返回值
2.1 路径书写规则(@Controller场景,返回视图页面)
Spring MVC 中,Controller 方法返回字符串时有两种解读方式,取决于是否加了 @ResponseBody。这里先说"不加"的情况——即返回的是视图路径。
假设类上标注了 @RequestMapping("/return"):
@Controller
@RequestMapping("/return")
public class ReturnController {
@RequestMapping("/returnPage")
public String returnPage() {
return "/aaa/index.html"; // 注意:以 "/" 开头
}
}| 返回值写法 | 含义 | 实际访问路径 | 说明 |
|---|---|---|---|
return "index.html" | 相对路径 | /return/index.html | 拼接类上的路径 /return |
return "/index.html" | 绝对根路径 | /index.html | 忽略类上路径,直接从根开始 |
return "/aaa/index.html" | 绝对路径 | /aaa/index.html | 直接定位到 static/aaa/index.html |
Spring Boot 默认首页规则:
访问 http://127.0.0.1:8080 时,Spring Boot 会自动匹配 static/ 目录下的以下文件(按优先级):
index.htmlindex.htmindex.jsp
所以把 index.html 放到 src/main/resources/static/ 下,无需任何 Controller 即可直接访问。
2.2@ResponseBody注解
@ResponseBody 是理解 Spring MVC 的另一个关键注解。它的作用就一句话:把返回值当成"数据"直接写给浏览器,而不是当成"页面路径"去找模板。
@Controller
@RequestMapping("/return")
public class ReturnController {
// 不加 @ResponseBody → 返回值是视图路径
@RequestMapping("/returnPage")
public String returnPage() {
return "/aaa/index.html"; // 去找 /aaa/index.html 页面
}
// 加了 @ResponseBody → 返回值是原始数据
@ResponseBody
@RequestMapping("/returnData")
public String returnData() {
return "/aaa/index.html"; // 浏览器直接显示字符串 "/aaa/index.html"
}
}两段代码返回值一模一样,但加不加 @ResponseBody,行为截然不同:
- 不加:Spring 去
static/下找aaa/index.html模板渲染后返回; - 加了:浏览器收到的是纯粹的字符串
/aaa/index.html。
注解的作用范围:
| 标注位置 | 影响范围 | 示例 |
|---|---|---|
| 类上 | 该类所有方法均返回数据 | @ResponseBody + @Controller = @RestController |
| 方法上 | 仅当前方法返回数据 | 类中可混合使用视图和数据返回 |
对象自动转 JSON:
@ResponseBody
@RequestMapping("/returnJSON")
public Person returnJSON() {
Person person = new Person();
person.setName("zmt");
person.setAge(18);
return person; // 自动序列化为 {"name":"zmt","age":18}
}当返回值是实体类或数组时,Spring 会调用 Jackson 等序列化库自动转为 JSON 字符串,Content-Type 也会自动设为 application/json。这是前后端分离开发中最常用的模式。
返回 HTML 字符串也能被浏览器解析:
@ResponseBody
@RequestMapping("/returnHTML")
public String returnHTML() {
return "<h1>hello world</h1>"; // 浏览器会自动渲染为一级标题
}一句话总结:
@Controller管"走哪条路",@ResponseBody管"输出什么"。而@RestController=@Controller+@ResponseBody,省去在每个方法上加注解的麻烦。
2.3@RequestMapping注解属性详解
@RequestMapping 是 Spring MVC 中最核心的请求映射注解,功能远不止"写个 URL 路径"那么简单。它拥有丰富的属性,可以精确控制请求匹配条件。
| 属性 | 说明 | 使用场景 |
|---|---|---|
value / path | 互为别名,指定映射 URL | 基础路径映射 |
method | 限定请求方式(GET、POST、PUT、DELETE 等) | RESTful 风格接口 |
consumes | 限定请求的 Content-Type | 要求客户端以特定格式传参 |
produces | 指定响应的 Content-Type | 控制返回格式与编码 |
params | 请求必须携带指定参数 | 条件路由、版本控制 |
headers | 请求必须携带指定请求头 | 按客户端类型分发 |
produces 实战示例:
// 传统方式:手动设置 Content-Type 和编码
@ResponseBody
@RequestMapping("/setContentType")
public String setContentType(HttpServletResponse response) {
response.setContentType("text/plain");
response.setCharacterEncoding("UTF-8");
return "<h1>hello world</h1>";
}
// 优雅方式:用 produces 属性一行搞定
@ResponseBody
@RequestMapping(value = "/setContentType2", produces = "text/plain;charset=UTF-8")
public String setContentType2() {
return "<h1>hello world</h1>"; // 浏览器不解析,原样输出 HTML 源码
}
// 返回 JSON 格式数据
@ResponseBody
@RequestMapping(value = "/setContentType3", produces = "application/json")
public String setContentType3() {
return "{\"name\":\"zmt\",\"age\":18}";
}对比说明:
produces = "text/plain"时,<h1>标签会原样输出;而默认的text/html下,浏览器会将其渲染为大标题。控制好Content-Type,才能确保前端正确解析你的返回内容。
三、前后端接口(API)概念
3.1 什么是接口(API)
在 Web 开发领域,接口(API,Application Programming Interface) 指的是:客户端与服务器之间约定的通信规则——包括可以发起哪些 HTTP 请求、每个请求需要什么参数、返回什么格式的数据。
需要明确区分的是:这里的"接口"与 Java 中的 interface 关键字完全是两个概念。Java interface 是代码层面的抽象契约;Web API 是应用层通信协议,是前后端协作的"合同"。
3.2 前后端分离与接口约定
在前后端分离架构下,前端和后端是两个独立的项目,可能由不同团队、甚至使用完全不同的技术栈开发。它们唯一的交集就是 HTTP 接口:

接口约定的典型内容:
- 请求路径:
POST /api/user/login - 请求参数:
{"username":"zmt", "password":"123456"} - 响应格式:
{"code":200, "msg":"success", "data":{"token":"xxx"}}
前端按这个约定发请求,后端按这个约定返回数据,双方各自独立开发、独立测试,最后联调时只要"合同"没问题,就能无缝对接。
3.3 接口文档
接口文档就是这份"合同"的书面记录。它描述了每个接口的:
- URL 路径和请求方式
- 请求参数(名称、类型、是否必填、示例值)
- 响应数据结构(字段含义、类型、示例)
- 错误码说明
常见的接口文档工具:Swagger / Knife4j、Apifox、YApi。对团队而言,接口文档是比口头沟通可靠一百倍的协作方式——先定接口,再写代码,是现代软件开发的标准流程。
补充:Request 与 Response 对象
在整个 Cookie/Session 机制和 Spring MVC 的返回值处理中,有两个贯穿始终的对象:
| 对象 | 职责 | 常用方法 |
|---|---|---|
| HttpServletRequest | 封装请求的所有信息 | getCookies()、getSession()、getParameter()、getHeader() |
| HttpServletResponse | 控制响应的所有行为 | addCookie()、setStatus()、setHeader()、setContentType() |
代码示例:
// 设置响应状态码
@ResponseBody
@RequestMapping("/setStatus")
public String setStatus(HttpServletResponse response) {
response.setStatus(404); // 返回 404 状态码
return "设置状态码成功";
}
// 设置响应头
@ResponseBody
@RequestMapping("/setHeader")
public String setHeader(HttpServletResponse response) {
response.setHeader("name", "zmt"); // 自定义响应头
return "设置响应头成功";
}
一句话记忆:HttpServletRequest 是"别人发来了什么"(只读),HttpServletResponse 是"我要回复什么"(只写)。二者分工明确,共同完成一次完整的 HTTP 交互。
全文总结
本文从 HTTP 无状态协议的根本矛盾出发,系统梳理了 Cookie 与 Session 的设计动机、交互流程、代码实战和核心区别,同时深入讲解了 Spring MVC 中页面跳转路径规则、@ResponseBody 注解机制、@RequestMapping 属性运用,以及前后端接口(API)的概念和协作方式。
整条知识线的关联可以这样串起来:HTTP 无状态 → 需要识别用户 → Cookie 存令牌、Session 存数据 → request.getSession() 获取会话 → Controller 处理业务 → @ResponseBody 决定返回数据还是页面 → produces 控制响应格式 → 最终通过 HttpServletResponse 把结果送回客户端。
核心知识点复盘
- HTTP 是无状态协议,Cookie + Session 是弥补无状态缺陷的两大机制。
- Cookie 存客户端,Session 存服务端,SessionID 是二者之间的唯一桥梁。
- Cookie 可伪造,Session 不可伪造——凡是涉及权限判断的场景,只能信任服务端 Session 中的数据。
request.getSession()无参默认创建新 Session,getSession(false)查不到返回null,要根据业务场景选择。@Controller返回字符串 = 视图路径,@Controller+@ResponseBody返回字符串 = 原始数据。@RestController=@Controller+@ResponseBody,是 RESTful 接口开发的标准注解。@RequestMapping的produces属性可以优雅地设置响应Content-Type和编码,替代传统的response.setContentType()。- Spring 自动注入机制:方法参数中的
HttpServletRequest、HttpSession等对象由框架自动创建并注入。 - Session 默认存内存,服务重启全部丢失,生产环境应外置到 Redis。
- 接口就是前后端之间的"合同",先定接口再写代码是现代开发的标准实践。
常见问题 / 避坑指南
Q1:@RestController 和 @Controller 到底怎么选?
- 前后端分离项目:接口只返回 JSON 数据 → 用
@RestController; - 传统 MVC 项目:需要跳转页面、使用模板引擎(Thymeleaf、JSP)→ 用
@Controller; - 混合场景:同一类中既有页面跳转又需要返回数据 → 类上
@Controller,数据返回方法上加@ResponseBody。
Q2:produces 和 response.setContentType() 同时使用会怎样?
produces 本质上是声明式的 setContentType(),但后者的优先级更高。如果代码中调用了 response.setContentType("text/plain"),即便 produces 设了 application/json,最终的 Content-Type 也是 text/plain。建议二选一,优先使用 produces(更 Spring 化、更简洁)。
Q3:Session 和 Cookie 的关系是强制的吗?
不是。Cookie 可以独立存储普通数据(如"7 天内免登录"的 Token),不必放 SessionID;SessionID 也可以不走 Cookie 而走 URL 拼接(虽然不推荐)。二者常搭配使用,但不是强制绑定。
本文所有代码基于 Spring Boot 3.x + JDK 17 编写,完整可运行。如果你跟着敲一遍所有示例,Cookie/Session 机制和 Spring MVC 的返回值处理就基本吃透了。
到此这篇关于Cookie 与 Session 及 Spring MVC 返回值技术详解(完整交互流程)的文章就介绍到这了,更多相关Cookie 与 Session 及 Spring MVC 返回值内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
您可能感兴趣的文章:
- java开发web前端cookie session及token会话机制详解
- 浅谈Servlet的Cookie和Session机制
- 利用php实现一周之内自动登录存储机制(cookie、session、localStorage)
- SpringMVC修改返回值类型后的消息转换器处理方式
- Spring MVC处理方法返回值过程解析
- Spring MVC Controller返回值及异常的统一处理方法
- SpringMVC 方法四种类型返回值总结(你用过几种)
- SpringMVC Controller 返回值的可选类型详解
- 详解springmvc之json数据交互controller方法返回值为简单类型
- 详解利用SpringMVC拦截器控制Controller返回值
