★ FEATURED ARTICLE 简介本资源是面向高校计算机专业学生与JavaEE初学者的期末复习题库聚焦MyBatis框架核心知识点系统覆盖ORM原理、SQL映射配置、事务管理、模糊查询安全、动态SQL及工作流程等高频考点助力高效备考与概念巩固。压缩包为单个41KB的Word文档.docx内容结构清晰含填空、判断、选择、简答四类题型每章配套标准答案与解析如第1章深入考查 与 元素用法、namespace作用、concat()函数局限性及MyBatis八步工作原理第2章延伸至 映射、 代码复用、数据源类型等进阶配置。题目设计紧扣教学重点强调易错点辨析与原理理解避免死记硬背。目前已有2646人学习下载适合作为期末冲刺自测、课堂随堂练习或MyBatis模块化复习的权威辅助材料。1. JavaEE期末复习一张贯穿 MyBatis → Spring → Spring MVC → AOP 的知识地图如果你正在翻着《JavaEE期末复习题库》发愁——填空题空了三行、判断题反复纠结“对/错”、选择题四个选项看着都像对的、简答题写到一半突然卡壳……别急这不是你学得差而是这套题库背后藏着一条被拆解得过于细碎、却从未被系统串联的知识主干。它不是零散考点的堆砌而是一张从数据持久层MyBatis出发经由控制反转容器Spring Core再向上延伸至 Web 层Spring MVC与横切关注点AOP的完整技术栈地图。这张图里mapper不是孤立标签它是 ORM 映射逻辑的起点Autowired不是魔法注解它是 IoC 容器生命周期管理的具象化DispatcherServlet更不是黑匣子它是整个 MVC 流程的调度中枢。真正让你在考前夜反复出错的往往不是某个单词拼写而是没看清这个模块在整个 JavaEE 架构中“站在哪一级、连着哪一根线、承接着谁的输入、输出给谁用”。本篇笔记就按这张地图来梳理不罗列定义不复述答案而是把每道题背后隐含的设计意图、执行路径、易混淆边界和真实运行时行为全部摊开。适合两类人一是刚学完各模块、但感觉知识点像散落珠子的同学二是刷过几轮题、却总在相似位置翻车、急需一次结构化归因的备考者。我们不讲“应该背什么”只说“为什么必须这样理解”。MyBatis不是 SQL 拼接器而是对象-关系映射的编排引擎MyBatis 的本质是让 Java 对象能“自然地”活在关系型数据库之上。它的核心不是帮你写 SQL而是精准控制 SQL 如何生成、参数如何绑定、结果如何映射、事务如何收口。所以delete元素之所以重要不是因为它叫 delete而是因为它强制你意识到删除操作必须显式提交事务否则数据白删且其 SQL 执行路径与select截然不同——前者走Executor.update()后者走Executor.query()底层调用 JDBC 的executeUpdate()与executeQuery()。同样namespace也不是为了“起个名字”而是为SqlSession.getMapper(XxxMapper.class)提供类型安全的代理入口——没有它MyBatis 就无法将接口方法名准确路由到对应 XML 中的delete idxxx。这就是为什么填空题第一问直指delete第二问紧跟着namespace它们共同构成 MyBatis 最小可运行单元的骨架。Spring Core不是配置文件搬运工而是对象生命周期的中央控制器当你看到ApplicationContext context new ClassPathXmlApplicationContext(applicationContext.xml)别只把它当一行初始化代码。这行代码背后是 Spring 容器启动的完整生命周期解析 XML → 实例化 BeanDefinition → 推断构造函数 → 调用InstantiationAwareBeanPostProcessor→ 注入属性Autowired触发AutowiredAnnotationBeanPostProcessor→ 调用InitializingBean.afterPropertiesSet()→ 执行init-method→ 放入单例池。而prototype作用域的 Bean恰恰在“放入单例池”这一步被截断——容器只负责创建不负责后续管理。所以判断题里“Spring 只负责创建 prototype Bean”是对的但“每次请求 singleton 都新建实例”就是典型误解。这种认知偏差直接导致你在做“Bean 作用域”类选择题时在request和prototype之间反复横跳。Spring MVC不是 Servlet 封装器而是 HTTP 请求的标准化流水线DispatcherServlet是整个流程的“总调度台”但它本身不处理业务逻辑。它严格遵循“接收 → 映射 → 适配 → 执行 → 解析 → 渲染 → 响应”的十步流水线。其中HandlerMapping决定“谁来处理这个 URL”HandlerAdapter解决“怎么调用这个 HandlerController 方法”ViewResolver负责“把逻辑视图名变成真实页面路径”。所以填空题问“前端控制器拦截后调用什么”答案是HandlerMapping而不是Controller或ViewResolver——因为这是流水线的第一道分拣口。而RequestMapping的 method 属性之所以“可选”正是因为DispatcherServlet默认支持所有 HTTP 方法但一旦你写了GetMapping它就自动绑定了method RequestMethod.GET这是注解的语义糖不是功能增强。AOP不是日志打印工具而是横切逻辑的织入协议Aspect类里的Before方法执行时机永远在目标方法之前但“之前”不等于“立刻之前”——如果目标方法抛异常AfterReturning就不会执行而After最终通知一定执行。这种差异源于 Spring AOP 的底层实现它通过ProxyFactoryBean创建 JDK 动态代理或 CGLIB 代理在目标方法调用前后插入MethodInterceptor链。而Pointcut定义的切入点表达式如execution(* com.xxx.service.*.*(..))本质是告诉代理“当执行这些方法时请把我的通知加进去”。所以选择题里问“AOP 是 OOP 的升级替代品”答案必错——AOP 是 OOP 的补充它解决的是分散在各处的重复逻辑日志、事务、权限而非替代封装、继承、多态。复习策略拒绝题海转向“路径验证式学习”与其反复刷同一道“resultMap子元素有哪些”的填空题不如打开一个真实项目做三件事在mybatis-config.xml中找到mappers确认它加载了哪个Mapper.xml在该Mapper.xml中找到一个select看它的resultMap属性指向哪个resultMap在resultMap中逐行检查id和result的column与property是否匹配 Java 类字段。这三步走完你记住的不是“id是主键”而是“当数据库主键列名和 Java 字段名不一致时id columnuser_id propertyid是唯一能打通映射的桥梁”。这才是题库该有的打开方式——它不是考卷而是你调试 JavaEE 架构的探针。2. MyBatis 核心机制从 XML 配置到动态 SQL 的执行链路MyBatis 的学习常陷入两个误区一是把 XML 当成静态配置文档忽略其与 Java 对象、SQL 执行、事务管理的实时联动二是把动态 SQL 当成模板语法糖没意识到if、set等标签背后是 OGNL 表达式引擎与 SQL 构建器的深度协作。本章不罗列标签用法而是沿着一条真实请求的执行路径拆解 MyBatis 如何把一个userMapper.deleteByStatus(inactive)调用一步步翻译成可执行的 JDBC 操作。这条路径覆盖了从全局配置加载、映射文件解析、SQL 动态组装、参数绑定到最终执行的全链路也是期末题库中填空、判断、选择题最密集的出题区。2.1 全局配置与映射加载mybatis-config.xml不是摆设而是运行时环境的契约mybatis-config.xml是 MyBatis 的“宪法”它定义了框架运行的底线规则。其中最关键的配置项远不止“获取数据库连接”这么简单提示environments中的default属性值必须与environment idxxx的id完全一致否则SqlSessionFactoryBuilder.build()会抛IllegalArgumentException。这是填空题第 4 题“主要内容是获取【 】”的答案陷阱——表面答“数据库连接”实则要意识到连接只是DataSource配置的结果而environments还决定了事务管理器类型JDBC 或 MANAGED、是否开启延迟加载等全局行为。!-- mybatis-config.xml 片段 -- configuration properties resourcedb.properties/ !-- 外部属性文件支持占位符 ${driver} -- settings setting namelazyLoadingEnabled valuetrue/ setting nameaggressiveLazyLoading valuefalse/ /settings typeAliases typeAlias aliasUser typecom.example.entity.User/ /typeAliases environments defaultdevelopment environment iddevelopment transactionManager typeJDBC/ dataSource typePOOLED property namedriver value${driver}/ property nameurl value${url}/ property nameusername value${username}/ property namepassword value${password}/ /dataSource /environment /environments mappers mapper resourcemapper/UserMapper.xml/ /mappers /configuration这段配置的执行顺序是加载db.properties注入${}占位符初始化Settings影响后续所有 SQL 执行行为如lazyLoadingEnabledtrue时关联查询会触发懒加载注册别名User使UserMapper.xml中可直接写resultTypeUser而非全限定名构建Environment创建PooledDataSource连接池和JdbcTransactionFactory最后扫描并加载UserMapper.xml—— 注意mappers必须放在/environments之后否则解析失败。这就是为什么题库中“mappers是配置文件根元素”是错的判断题第 1 题configuration才是根mappers只是其子元素。而namespace属性填空题第 2 题之所以必须存在是因为SqlSession.getMapper(UserMapper.class)依赖它来定位UserMapper.xml中的 SQL 片段。没有namespaceMyBatis 就无法将接口方法deleteByStatus(String status)映射到delete iddeleteByStatus。2.2 SQL 映射与参数绑定#{}与${}的生死线MyBatis 最易错的点集中在参数传递的安全性上。题库中多次出现concat()函数与 SQL 注入的辨析填空题第 3 题、选择题第 3 题其核心在于理解 MyBatis 的两种参数处理机制参数写法底层实现安全性典型场景风险示例#{status}预编译参数?占位符JDBCPreparedStatement.setString(1, inactive)✅ 防 SQL 注入所有常规条件查询、更新、删除WHERE status ?→ 安全${status}字符串拼接OGNL 表达式求值后直接插入 SQL❌ 高危可注入动态表名、列名、ORDER BY 子句WHERE status inactive; DROP TABLE user;→ 爆库因此填空题第 3 题“使用 MySQL 中的【 】函数进行字符串拼接可以有效防止模糊查询时可能出现的 SQL 注入问题”是一个误导性陷阱。concat()函数本身不能防止注入它只是 MySQL 的字符串函数。真正防注入的是#{}绑定。例如模糊查询应写为!-- 安全写法参数绑定 数据库函数 -- select idfindByName resultTypeUser SELECT * FROM user WHERE name LIKE CONCAT(%, #{name}, %) /select而非!-- 危险写法字符串拼接 -- select idfindByName resultTypeUser SELECT * FROM user WHERE name LIKE %${name}% /select后者若传入namea% OR 11SQL 变成WHERE name LIKE %a% OR 11%直接绕过条件。2.3 动态 SQL 的执行逻辑where、set不是语法糖而是 SQL 构建器动态 SQL 的本质是 MyBatis 在运行时根据 Java 对象状态动态生成合法 SQL 字符串。where和set标签的核心价值在于解决手工拼接 SQL 时的“多余 AND”、“多余逗号”问题。但它们的实现原理常被忽略where标签当其内部所有if判断均为 false 时整个where标签内容被忽略不会生成WHERE关键字若至少一个if为 true则自动添加WHERE并智能去除第一个AND或OR。set标签同理当内部无if为 true 时不生成SET否则添加SET并自动去除最后一个逗号。看一个典型更新场景update idupdateUser parameterTypeUser UPDATE user set if testname ! null and name ! name #{name}, /if if testemail ! null and email ! email #{email}, /if if teststatus ! null status #{status} /if /set WHERE id #{id} /update若传入User{namenull, emailab.com, statusactive}MyBatis 生成的 SQL 是UPDATE user SET email ?, status ? WHERE id ?注意set自动去掉了email ?后面的逗号并未生成SET , email ?, status ?这种语法错误。这就是填空题第 3 题“如果set元素内包含的内容都为空则会出现【 】”的答案——SQL 语法错误因为UPDATE user SET WHERE id ?是非法的。而填空题第 5 题“set元素就会动态前置【 】关键字同时也会消除 SQL 语句中最后一个多余的【 】”答案是SET和逗号。2.4 结果映射resultMap是对象与数据库的“翻译官”不是可有可无的备胎当数据库列名user_name与 Java 字段名userName不一致或存在一对一、一对多关联时resultMap是唯一解。题库填空题第 1 题“当数据表中的列和需要返回的对象的属性不完全一致MyBatis 是不会自动赋值的。此时就可以使用【 】元素进行处理”答案是resultMap但关键在于理解它的工作机制resultMap idUserResultMap typeUser id propertyid columnuser_id/ !-- 主键映射必须用于缓存和延迟加载 -- result propertyuserName columnuser_name/ !-- 普通字段映射 -- association propertydept javaTypeDepartment resultMapDeptResultMap/ collection propertyroles ofTypeRole resultMapRoleResultMap/ /resultMapid标签标记主键列必须配置。MyBatis 用它做一级缓存 Key 和延迟加载标识。若省略关联查询可能失效。result标签映射普通字段column是数据库列名property是 Java 字段名。association/collection处理关联对象resultMap属性指向另一个resultMap实现嵌套结果映射。这就是为什么判断题第 4 题“映射文件中可以包含多个 id 值相同的resultMap元素”是错的——id是resultMap的唯一标识重复会导致XMLParser解析异常。2.5 事务管理MyBatis 的 CRUD 操作从来不是“自动提交”一个致命误区认为 MyBatis 的insert()、update()、delete()执行后数据就落地了。事实是所有修改操作都必须显式提交事务否则回滚。题库判断题第 4 题“MyBatis 的更新操作也需要进行事务提交”为正确选择题第 1 题 D 选项“删除操作和添加操作一样也需要封装整个实体类”为错误原因在此// 错误示范忘记 commit SqlSession session sqlSessionFactory.openSession(); UserMapper mapper session.getMapper(UserMapper.class); mapper.deleteByStatus(inactive); // SQL 已执行但未提交 // session.commit(); // 忘记这一行 → 事务回滚数据未删除 // 正确示范try-with-resources 显式 commit try (SqlSession session sqlSessionFactory.openSession()) { UserMapper mapper session.getMapper(UserMapper.class); mapper.deleteByStatus(inactive); session.commit(); // 必须 } catch (Exception e) { session.rollback(); // 异常时回滚 }MyBatis 默认使用 JDBC 事务openSession()返回的SqlSession默认autoCommitfalse。这也是为什么题库反复强调“事务提交”——它不是加分项是及格线。3. Spring CoreIoC 容器的生命周期与 Bean 的装配哲学Spring Core 的灵魂是 IoCInversion of Control控制反转与 DIDependency Injection依赖注入。但很多同学把Autowired当成“自动赋值开关”把ApplicationContext当成“对象工厂”却忽略了 Spring 容器本身是一个有严格生命周期、状态管理和装配契约的运行时环境。本章聚焦三个核心容器启动的完整流程、Bean 的作用域本质、以及装配方式的选择逻辑。这些正是题库中填空、判断、选择题高频踩坑区——比如“Component标注在方法上”判断题第 1 题、“singleton每次请求都新建”判断题第 3 题、“autowire属性取值”选择题第 1 题等根源都在对容器机制理解不深。3.1 容器启动从 XML 解析到 Bean 实例化的七步法ClassPathXmlApplicationContext(applicationContext.xml)的执行绝非简单加载配置。它是一套精密的七步初始化流程资源定位ClassPathResource从 classpath 加载applicationContext.xmlXML 解析XmlBeanDefinitionReader解析bean标签生成BeanDefinition对象存储 class、scope、properties 等元数据注册 BeanDefinition存入DefaultListableBeanFactory的beanDefinitionMap实例化 BeanFactoryPostProcessor如PropertyPlaceholderConfigurer允许修改BeanDefinition实例化 Bean按 scope 创建实例singleton立即创建存入singletonObjects缓存prototype仅注册定义调用getBean()时才创建属性填充DIAutowiredAnnotationBeanPostProcessor扫描Autowired通过BeanFactory.getBean()注入依赖初始化回调调用InitializingBean.afterPropertiesSet()和init-method。这个流程解释了题库中所有“容器行为”类题目判断题第 2 题“通常在 Java 项目中会采用FileSystemXmlApplicationContext”是错的——FileSystemXmlApplicationContext从文件系统加载而ClassPathXmlApplicationContext从 classpath 加载后者才是标准实践填空题第 2 题“对象的实例不再由调用者来创建而是由【 】来创建”答案是Spring 容器但更精确地说是DefaultListableBeanFactory选择题第 4 题“Spring 的核心容器是其他模块建立的基础以下哪个不是该容器的组成模块”答案是AOP 模块——因为 AOP 是独立模块通过AopNamespaceHandler集成到容器而非容器原生组件。3.2 Bean 作用域singleton与prototype的本质区别不在“数量”而在“管理权”scope属性决定 Spring 容器对 Bean 实例的管理粒度。题库填空题第 4 题“对于【 】作用域的 BeanSpring 只负责创建当容器创建了 Bean 实例后Bean 的实例就交给客户端代码来管理”答案是prototype。但关键要理解“管理权移交”的含义作用域创建时机存储位置容器管理典型用途题库陷阱singleton容器启动时或首次getBean()singletonObjects缓存✅ 全生命周期管理创建、注入、初始化、销毁无状态服务类Service、DAO判断题第 3 题“每次请求都新建” → 错prototype每次getBean()调用时无缓存由 GC 回收❌ 仅创建不管理后续不调用destroy-method有状态对象如用户会话上下文判断题第 4 题“prototypeBean 在容器中只有一个实例” → 错因此“singleton是单例”不等于“JVM 中只有一个对象”——它特指Spring 容器内唯一。而prototypeBean 的销毁需由开发者手动处理如调用close()容器不会介入。这也是填空题第 4 题强调“交给客户端代码来管理”的深意。3.3 装配方式Autowired的默认策略是byType不是byNameSpring 提供三种装配方式基于 XML 的设值注入/构造注入、基于注解的Autowired/Resource、以及自动装配autowire属性。题库选择题第 1 题“bean元素中的autowire属性取值不包括以下”选项 DbyId是干扰项——autowire合法值只有no、byName、byType、constructor、autodetect没有byId。而Autowired的工作原理是默认按byType匹配即查找相同类型的 Bean若找到多个再按byName匹配字段名与 Bean 的id或name一致可用Qualifier(xxx)强制指定 Bean 名。Service public class UserServiceImpl implements UserService { ... } Service(userServiceImpl2) public class UserServiceImpl2 implements UserService { ... } Component public class UserController { Autowired // 按 byType 找 UserService但找到两个 private UserService userService; // 报错NoUniqueBeanDefinitionException Autowired Qualifier(userServiceImpl2) // 指定名称解决歧义 private UserService userService2; }这就是为什么题库判断题第 1 题“Component注解...只需将该注解标注在相应方法上即可”是错的——Component是类级别注解标注在方法上无效而选择题第 4 题 A 选项“Autowired默认按照 Bean 的名称进行装配”也是错的——默认是byType。3.4 注解体系Repository、Service、Controller是语义化标签非功能增强Spring 的分层注解Repository、Service、Controller本质是Component的派生功能完全等价唯一区别是语义和 AOP 切面的默认切入点。题库填空题第 2、3 题分别考察Controller作用于Controller层、Repository作用于 DAO 层这不仅是记忆点更是设计规范Repository被PersistenceExceptionTranslationPostProcessor增强自动将 JDBC 异常转为 Spring 的DataAccessException层次结构Service约定俗成的业务逻辑层便于 AOP 切入事务TransactionalController被ResponseBody、RequestBody等 Web 注解支持专用于 MVC 控制器。因此选择题第 4 题 A 选项“Autowired默认按照 Bean 的名称进行装配”错误而 D 选项“Controller用于将控制层的类标识为 Spring 中的 Bean”正确——它强调的是“标识为 Bean”而非“提供 Web 功能”。3.5 工厂模式实例工厂与静态工厂谁持有创建权Spring 支持三种 Bean 实例化方式构造器、静态工厂、实例工厂。题库填空题第 5 题“实例工厂方式...需要实例化的 Bean 是通过【 】属性指向配置的实例工厂”答案是factory-bean。关键区别在于静态工厂工厂类有静态方法bean用class指向工厂类factory-method指向静态方法名实例工厂工厂类需先被容器管理bean用factory-bean指向工厂 Bean 的idfactory-method指向其实例方法名。!-- 静态工厂 -- bean iduserDao classcom.example.factory.DaoFactory factory-methodcreateUserDao/ !-- 实例工厂 -- bean iddaoFactory classcom.example.factory.DaoFactory/ bean iduserDao2 factory-beandaoFactory factory-methodcreateUserDao/选择题第 5 题“不属于 Spring 中实例化 Bean 的方式的是”答案是抽象方法实例化——Spring 不支持抽象类直接实例化必须有具体实现。4. Spring MVC从前端控制器到视图解析的十步执行流Spring MVC 不是简单的“Controller 接收请求、返回视图”而是一套高度解耦、职责分明的 HTTP 请求处理流水线。DispatcherServlet是这条流水线的总控中心但它自身不写业务逻辑所有工作都委托给一系列策略接口HandlerMapping、HandlerAdapter、ViewResolver等。题库中大量题目如填空题第 1、3、4 题判断题第 1、2 题选择题第 2、3 题都在考察你是否看清了每个环节的输入、输出和职责边界。本章以一次GET /user/list请求为例完整拆解这十步执行流让你彻底告别“DispatcherServlet 之后就模糊了”的复习困境。4.1 执行流程全景十步不可逆的请求流转Spring MVC 的标准执行流程依据题库简答题第 1 题答案如下每一步都是强依赖前一步的输出用户请求到达浏览器发送GET http://localhost:8080/user/list前端控制器拦截DispatcherServlet在web.xml中配置为url-pattern/捕获请求处理器映射DispatcherServlet调用HandlerMapping如RequestMappingHandlerMapping根据 URL/user/list查找匹配的Controller方法返回HandlerExecutionChain含HandlerMethod和拦截器处理器适配DispatcherServlet调用HandlerAdapter如RequestMappingHandlerAdapter将HandlerMethod适配为可执行对象执行处理器HandlerAdapter调用UserController.list()方法执行业务逻辑返回 ModelAndViewlist()方法返回ModelAndView(user/list, model)其中user/list是逻辑视图名视图解析DispatcherServlet调用ViewResolver如InternalResourceViewResolver将逻辑视图名user/list解析为真实路径/WEB-INF/jsp/user/list.jsp视图渲染ViewResolver返回View对象DispatcherServlet调用view.render(model, request, response)将模型数据填充到 JSP响应输出JSP 渲染 HTML写入HttpServletResponse输出流流程结束DispatcherServlet返回容器关闭请求。这个流程解释了所有高频考点填空题第 1 题“前端控制器拦截请求后会调用【 】”答案是HandlerMapping第 3 步填空题第 4 题“Spring MVC 提供了一个前端控制器【 】”答案是DispatcherServlet第 2 步判断题第 1 题“HandlerAdapter 将 ModelAndView 对象返回给 ViewReslover”是错的——是DispatcherServlet调用ViewResolver第 6→7 步HandlerAdapter只负责执行 Controller 并返回ModelAndView第 5→6 步选择题第 2 题“Spring MVC 中的后端控制器是指”答案是Handler即UserController而非DispatcherServlet前端控制器。4.2 核心组件职责HandlerMapping、HandlerAdapter、ViewResolver的分工铁律这三个组件是 Spring MVC 的“三驾马车”职责绝不交叉组件职责输入输出题库关联HandlerMappingURL 到处理器的路由HTTP 请求URL、HTTP 方法HandlerExecutionChain含HandlerMethod填空题第 1 题、选择题第 3 题“负责拦截用户请求的是” → 答案是前端控制器但HandlerMapping是它调用的第一个组件HandlerAdapter处理器的统一调用适配HandlerExecutionChainModelAndView判断题第 1 题错误点它不返回给ViewResolver只返回给DispatcherServletViewResolver逻辑视图名到物理视图的转换ModelAndView中的视图名View对象如InternalResourceView填空题第 3 题“可以配置...和【 】”答案是视图解析器特别注意HandlerAdapter的存在是为了兼容不同风格的处理器如Controller、HttpRequestHandler、Servlet它把千差万别的处理器调用方式统一成ModelAndView输出。没有它DispatcherServlet就要为每种处理器写一套调用逻辑。4.3 注解驱动开发RequestMapping的属性体系与语义缩写RequestMapping是 Spring MVC 的基石注解但题库中对其属性的考察非常细致。填空题第 1 题“RequestMapping注解类型用于映射【 】”答案是URL但实际它可映射多种维度属性说明示例题库考点value/path指定 URL 路径RequestMapping(/user)填空题第 1 题method指定 HTTP 方法RequestMapping(value/user, methodRequestMethod.POST)判断题第 2 题“method属性必须使用” → 错可选默认支持所有方法params指定请求参数约束RequestMapping(paramsactionsave)未在题库出现但属重点headers指定请求头约束RequestMapping(headersContent-Typeapplication/json)未在题库出现而GetMapping、PostMapping等是RequestMapping的语义化缩写GetMapping(/user) // 等价于 RequestMapping(value /user, method RequestMethod.GET)判断题第 3 题“RequestMapping(method RequestMethod.GET)可以缩写为GetMapping”为正确。这不仅是语法糖更是 RESTful 风格的强制约定。4.4 视图解析器InternalResourceViewResolver的前缀/后缀魔法ViewResolver的核心任务是把逻辑视图名如success变成物理路径如/WEB-INF/jsp/success.jsp。最常用的是InternalResourceViewResolver它通过prefix和suffix属性完成拼接bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/jsp// property namesuffix value.jsp/ /bean p a hrefhttps://download.csdn.net/download/m0_52861684/88680769 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
阅读完成 · 觉得有帮助？
