题库管理Quiz Bank
各课程页随堂测验（<Quiz items>）的题集中在此：可增 / 改 / 删并实时校验，按章节统计题量，导出 JSON 供整理回填。 编辑仅作用于当前会话（客户端内存），导出的 JSON 需教师确认后回填到对应 MDX。
题库管理器（QuizBankManager）
各课程页 <Quiz items={…} /> 里的题集中在这里： 可增 / 改 / 删（实时校验），导出 JSON 供整理回填。当前共 90 题，全部通过校验。
判定一个网页是「动态网页」的核心依据是（ ）
解析：动态网页的内容是服务器端现算的（.jsp/.asp/.php 等），可因人而异因时而变；静态网页（.html）内容写死、人人相同。后缀只是表象，本质看「是不是服务端生成」。
URL `http://localhost:8080/guestbook/index.jsp` 中，`8080` 表示（ ）
解析：URL 形如 http://host:port/path——localhost 是主机、8080 是端口、/guestbook/index.jsp 是路径。Tomcat 默认监听 8080，所以端口号决定连到哪个服务。
浏览器向服务器提交表单数据（如登录）时，最常用的 HTTP 方法是（ ）
解析：POST 用于把数据提交到服务器（请求体里带参数），适合登录、留言这类「写」操作；GET 主要用于取资源，参数拼在 URL 上、不宜传敏感/大量数据。
Tomcat 在这套技术栈里的角色是（ ）
解析：Tomcat 实现了 Servlet API：读 WEB-INF/web.xml、实例化并管理 Servlet 生命周期、把 JSP 编译成 Servlet。Apache/Nginx 主要管静态资源与代理，分工不同。
HTTP 是「无状态」协议，网站要记住「当前用户」应依赖（ ）
解析：HTTP 每次请求独立、服务器不记「上次是谁」。靠 Cookie 在客户端存会话标识、Session 在服务端存用户数据，两者配合实现跨请求的「有状态」体验（登录、购物车）。
浏览器（客户端）在一次网页访问里不负责（ ）
解析：浏览器只负责「问 + 显示」：解析 URL、发请求、渲染 HTML、存 Cookie。动态内容的计算在服务器端（Servlet/JSP），浏览器拿到的永远是算好的 HTML。
浏览器地址栏里 `http://localhost:8080/guestbook/index.jsp`，浏览器首先做的是（ ）
解析：浏览器先解析 URL（协议 http、主机 localhost、端口 8080、路径 /guestbook/index.jsp），据此向该服务器发 HTTP 请求；JSP 的编译在服务器端 Tomcat 里进行，与浏览器无关。
关于 Servlet 生命周期，下列说法正确的是（ ）
解析：Servlet 是单例多线程对象：容器加载类、new 出唯一实例后只调用一次 init()；每次客户端请求都调用 service()（分发到 doGet/doPost）；destroy() 只在卸载前调用一次。
Servlet 被容器实例化之后，第一个被调用的生命周期方法是（ ）
解析：顺序是：加载类 → 实例化（new，不触发任何生命周期方法）→ init() → service()。实例化之后容器先调 init() 做一次性资源准备。
下列哪个方法属于 HttpServletRequest？
解析：getParameter/getSession 是请求侧（取参数、取会话）；setContentType/getWriter/sendRedirect 都是 HttpServletResponse 的方法（写响应）。
在 web.xml 中，把 Servlet 映射到 URL 的元素是（ ）
解析：<servlet> 声明 servlet-name 与类名；<servlet-mapping> 把该名字映射到 /hello.svc 这样的 url-pattern。两者配合才完成「URL → Servlet」的路由。
Filter 链中，AuthFilter 判定用户未登录时应该（ ）
解析：这就是「短路」：不放行就直接写响应（如 302 跳登录页），后续 Filter 与目标 Servlet 都不会执行。
关于链上多个 Filter 的执行顺序，正确的是（ ）
解析：请求「下顺」：依次经过每个 Filter 的前置处理；响应「上逆」：按相反顺序经过每个 Filter 的后置处理。任一 Filter 短路后，其后的 Filter 不再执行。
Servlet 为什么不应该用实例变量保存每次请求的数据？
解析：所有请求共享同一个 Servlet 实例，service() 可能被多个线程并发调用——请求相关状态一律用局部变量；确需共享时加同步或用 ThreadLocal。
关于 Listener，下列说法正确的是（ ）
解析：Listener 注册在 web.xml 中，HttpSession 创建/销毁、属性变更等事件发生时由容器自动通知；它只「旁听」事件，不拦截请求。
JSP 页面里 `<% if(x>0){...} %>` 属于哪种元素？
解析：<% %> 是脚本（scriptlet），编译进 Servlet 的 service() 方法体，是 Java 语句。指令是 <%@ %>、声明是 <%! %>、表达式是 <%= %>。
`<%! int i = 0; %>` 与 `<% int i = 0; %>` 的区别是（ ）
解析：<%! %> 声明的是 Servlet 的成员变量/方法，整个页面（跨请求、多线程）共享——有线程安全风险；<% %> 是 service() 内的局部语句，每次请求独立执行。
要「真正隐藏」一段代码不让用户查看源码看到，应使用（ ）
解析：JSP 注释 <%-- --%> 在编译期就被去掉，不会进入生成的 Servlet/HTML；HTML 注释会原样发到浏览器，查看源码可见。
要保存「同一用户多次访问都要保留」的数据（如登录状态），应使用哪个内置对象？
解析：request 只活一次请求；session 活一个会话（跨请求、同一用户）；application 是全局共享。登录状态是「同一用户跨请求」，用 session。
实现「退出登录」（清空登录态），标准做法是调用（ ）
解析：invalidate() 销毁整个会话、清空全部属性——是「退出登录」的标准动作；removeAttribute 只删单个属性（会话里其他数据还在）；登录态本来就不该存在 application 里。
调用 session.invalidate() 之后，该用户下一次请求会发生什么？
解析：会话销毁后属性清空；下次请求时容器会创建新会话（新的 JSESSIONID），原登录态丢失——所以退出登录后需要重新登录。
下列数据最适合存放在 application（ServletContext）里的是（ ）
解析：application 整个应用、所有用户共享，适合 PV / 在线人数这类全站统计和全局配置；购物车属于某个具体用户，应放 session；单次请求内的数据放 request。
`<%= name %>` 在编译后会变成什么？
解析：表达式 <%= %> 编译成 out.print(...)，把表达式的值写进响应输出流。它是「往页面里塞一个值」。
JSP 与 Servlet 的关系最准确的描述是（ ）
解析：首次请求 .jsp 时，Tomcat 把它编译成一个 Servlet（.class），之后执行该 Servlet 生成 HTML。所以 JSP 本质是「披着 HTML 外衣的 Servlet」，能复用 request/response 等容器能力。
JSP 里要把「整个应用共享」的数据（如在线人数）存起来，应使用哪个内置对象？
解析：application（ServletContext）作用域是整个 Web 应用、全局共享；request 只活一次请求，session 只活一个会话。在线人数是「全站共享」，用 application。
按 JavaBean 规范，一个标准 Bean 必须提供（ ）
解析：JavaBean 规范：public 类 + 无参构造器（框架靠它 new）+ 私有属性经 getter/setter 访问。字段不 public、不用带参构造器实例化。
IoC（控制反转）的含义是（ ）
解析：IoC=Inversion of Control（控制反转）：对象的创建、持有、装配交给容器，业务代码不再 new 依赖——依赖关系被「反转」了。
Spring XML 里 <property name="title" value="第一条留言"/> 的作用是（ ）
解析：<property> 对应 setter 注入：容器调 setTitle 把 title 填成「第一条留言」。这是 DI 的「属性注入」方式。
注解配置中 @Autowired 的作用是（ ）
解析：@Autowired 按类型自动装配（同类型多个时加 @Qualifier 指定名字），对应 XML 里的 <ref bean>。
关于 @Component 四兄弟，正确的是（ ）
解析：四者本质都是 @Component（都注册为 bean），区别是分层语义：@Service 业务层、@Repository 持久层、@Controller Web 层、@Component 通用兜底。
BeanFactory 与 ApplicationContext 的区别，正确的是（ ）
解析：ApplicationContext 是 BeanFactory 的超集：启动即饿加载全部单例（如 ClassPathXmlApplicationContext），并提供事件发布、国际化、资源加载等。
Spring bean 生命周期的正确顺序是（ ）
解析：先无参构造实例化，再填属性/依赖（DI），然后执行初始化回调（@PostConstruct），之后可用，容器关闭时销毁。
XML 里 <property name="gb"><ref bean="gb1"/></property> 表示（ ）
解析：<ref bean> 是依赖注入：把容器里已创建的 gb1 实例引用注入进来，而不是字符串。
注解配置中 @Value("zhang") 的作用是（ ）
解析：@Value 注入字面量（基本类型/字符串），对应 XML 的 <property value>。
DispatcherServlet 的作用是（ ）
解析：DispatcherServlet 是 SpringMVC 的前端控制器（总入口）：web.xml 把所有 *.do 请求交给它，再由它调度到对应 Controller。
SpringMVC 请求处理五步的正确顺序是（ ）
解析：请求先到 DispatcherServlet，HandlerMapping 找到命中的 @RequestMapping 方法，Controller 返回 ModelAndView，最后 ViewResolver 渲染视图。
@RequestMapping 的作用是（ ）
解析：@RequestMapping 标注在方法（或类）上，把 URL 与处理方法绑定；HandlerMapping 据此找到命中的 handler。
HandlerMapping 的职责是（ ）
解析：HandlerMapping（如 RequestMappingHandlerMapping）按 URL 匹配到对应的 Controller 方法，是「URL→handler」的映射器。
ViewResolver（视图解析器）的作用是（ ）
解析：ViewResolver 把 Controller 返回的逻辑视图名（hello）结合 prefix/suffix 解析成真实 JSP 路径，交给 JSP 渲染。
Model / ModelMap 的作用是（ ）
解析：Model 是请求作用域的数据容器：Controller 放、JSP 用 ${...} 取，请求结束即失效；跨请求要存就得用 HttpSession。
JSP 里 ${message} 的取值来源是（ ）
解析：EL ${message} 从当前请求的 Model 中读名为 message 的属性——即 Controller 放进来的那个值。
new ModelAndView("hello", "message", msg) 的含义是（ ）
解析：第一个参数是逻辑视图名（hello），后两个是「模型属性名 → 值」（message → msg）：视图去渲染，数据进 Model。
在 MVC 三层架构里，「业务规则、事务边界」应放在哪一层？
解析：Service 层封装业务规则并划定事务边界，协调各 DAO；Controller 只接请求渲染视图，DAO 只管存取，都不该写业务判断。
数据访问层（DAO）的职责是（ ）
解析：DAO 层只负责存取数据（MyBatis Mapper / XML），不含业务判断、不碰视图；业务在 Service，展示在 Controller/View。
关于 MySQL 里 emp_name 用 varchar(22)、gender 用 char(2) 的选型，正确的是（ ）
解析：char 定长、varchar 变长。姓名长度可变（用 varchar），性别基本定长（M/F/男/女，用 char 省空间）。类型选型看数据是否定长与取值范围。
emp_id int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY(emp_id) 的含义是（ ）
解析：AUTO_INCREMENT 让数据库自动为每行发递增编号；作为主键它唯一且非空。因此 INSERT 不能手工指定它、UPDATE 不能改它。
下面哪条 SQL 是「查」语句（DML-SELECT）？
解析：SELECT 是查询语句（DML）。INSERT 是增、CREATE/DROP 是 DDL（定义结构），都不是查。
关于 UPDATE / DELETE，正确的是（ ）
解析：不带 WHERE 的 UPDATE/DELETE 会作用于整张表（全改/全删），极危险。教学与生产都要求必须带 WHERE 条件。
tbl_emp.department_id 指向 tbl_dept.dept_id，本课程不建物理外键，称之为（ ）
解析：逻辑外键只在语义/应用层表示关联，数据库不加 FOREIGN KEY 强约束。好处是灵活（删部门不必先删员工）、校验放业务层更好测。
为什么课程表一律加 DEFAULT CHARSET=utf8？
解析：建库建表指定 DEFAULT CHARSET=utf8，是为了正确存储/显示中文，避免默认字符集导致乱码。这是课程所有表的统一约定。
CREATE USER 'hrm'@'localhost' ...; GRANT SELECT,INSERT,UPDATE,DELETE ON shrmssm.* TO 'hrm'@'localhost'; 体现了（ ）
解析：GRANT 属于 DCL（控制权限）。只授予 SELECT/INSERT/UPDATE/DELETE（DML），把建表删库（DDL）留给 DBA，是「最小权限原则」。
JDBC 五步的正确顺序是（ ）
解析：标准五步：加载驱动 → 建立 Connection → 造 Statement/PreparedStatement → 执行（executeQuery/Update）→ 用 rs.next() 读 ResultSet → 由内向外逐级关闭。
关于 JDBC 四大接口，正确的是（ ）
解析：Driver/Connection/Statement/ResultSet 都是接口，Java 面向接口编程，实现类由 MySQL 等厂商驱动提供。换库只需换驱动，业务代码基本不动——多态的价值。
INSERT / UPDATE / DELETE 应使用哪个方法？返回值是（ ）
解析：增删改用 executeUpdate()，返回受影响的行数；SELECT 用 executeQuery()，返回 ResultSet。
下面哪种写法能防 SQL 注入？
解析：? 占位符 + setString 把用户输入只当「值」绑定，数据库不会把它当 SQL 代码执行，天然防注入。字符串拼接则可能被 ' OR '1'='1 之类破坏。
JDBC 资源正确的关闭顺序是（ ）
解析：ResultSet 依赖 Statement、Statement 依赖 Connection，须由内向外逐级关。try-with-resources 会按声明的逆序自动关闭，最省心。
try (Connection conn = ...; PreparedStatement ps = ...) { try (ResultSet rs = ...) {...} } 的好处是（ ）
解析：try-with-resources（Java 7+）让实现了 AutoCloseable 的资源在块结束时自动按声明逆序 close()，省去手写 finally 与判空，避免资源泄漏。
手写 JDBC 的三大痛点中，MyBatis 用「XML/注解声明 SQL + 自动映射对象」主要解决的是（ ）
解析：JDBC 痛点是：五步模板重复、rs.getXxx() 手映射、无动态 SQL。MyBatis 用声明式 SQL + 自动结果映射 + 资源管理把这些封装掉，底层仍是 JDBC。
MyBatis 中 DAO 接口方法能直接执行 SQL，靠的是（ ）
解析：MyBatis 用动态代理给每个 @Mapper 接口生成代理对象；调用接口方法时，代理按 namespace+方法名定位到 XML 里的 SQL 去执行。
#{} 占位符的特点是（ ）
解析：#{} 是安全的预编译占位符：MyBatis 把它转成 ? 并把参数绑定进 PreparedStatement，避免 SQL 注入；${} 才是字符串直接拼接。
"${}" 占位符适合用于（ ）
解析："${}" 是字符串直接拼接，适合动态表名/列名/ORDER BY 字段这类不能当参数绑定的场景，但要注意 SQL 注入风险。
<where> 标签的作用是（ ）
解析：<where> 只在其中的 <if> 条件有内容时才输出 where，并自动去掉第一个条件前的多余 and/or。
<foreach> 标签常用于（ ）
解析：<foreach> 遍历传入的集合/数组，拼出 IN (a,b,c) 或 insert ... values (...),(...) 这类需要重复片段的 SQL。
resultType 与 resultMap 的区别是（ ）
解析：列名与属性名一致时用 resultType 自动映射即可；需要处理列名≠属性名或关联对象（association/collection）时用 resultMap 显式声明。
resultMap 里的 <association> 用来（ ）
解析：<association> 处理一对一关联：把若干列映射进某个属性指向的对象，如 Word.user。多对一则用 <collection>。
一次 Mapper 方法调用的正确顺序是（ ）
解析：先调用接口方法（call），动态代理拦截（proxy），定位 XML 里的 SQL（locate），绑定参数（bind），执行得到结果集（execute），最后映射成对象（map）。
SpringBoot 引入 spring-boot-starter-web 后，会自动带入什么？
解析：starter 把「某类能力所需的一组依赖」打包：spring-boot-starter-web 一次性带入 Web MVC、内嵌 Tomcat、Jackson 等，版本由 BOM 统一托管。
SSM 里 spring.xml 负责的「组件扫描 + 数据源 + 声明式事务」，在 Boot 中对应（ ）
解析：spring.xml 的三项职责分别由组件扫描（@SpringBootApplication 内含）、数据源自动配置、事务自动配置接管，不再手写 <context:component-scan> 等。
SSM 里 spring-mvc.xml 装配 DispatcherServlet 与注解驱动，Boot 中由谁完成？
解析：WebMvcAutoConfiguration（spring-boot-starter-web）自动注册 DispatcherServlet、映射处理器与消息转换器，省去 spring-mvc.xml。
SSM 里 mybatis-config.xml 配置 SqlSessionFactory，Boot 中由谁完成？
解析：MybatisAutoConfiguration 按 DataSource 自动建 SqlSessionFactory、扫 @Mapper，省去 mybatis-config.xml 的手工装配。
SSM 需要 web.xml 声明 DispatcherServlet/Filter 并依赖外部 Tomcat；Boot 里 web.xml 被省掉的原因是（ ）
解析：Boot 内嵌 Tomcat（ServletWebServerFactoryAutoConfiguration），容器随应用启动，容器级组件靠注解/自动配置注册，整个 web.xml 省掉。
相比 SSM「打 war 丢进外部 Tomcat」，Boot 的典型部署方式是（ ）
解析：Boot 把 Tomcat 内嵌进 fat-jar，部署退化为 java -jar app.jar，环境一致性由 jar 自身保证。
对 SpringBoot 最准确的定位是（ ）
解析：Boot 不是新框架，而是把 Spring + SpringMVC + MyBatis 的手写配置交给自动配置类——M4/M5/M8 学的都还在，只是装配被自动化了。
SSM 中负责「业务层」（IoC + 事务）的框架是（ ）
解析：Spring 负责业务层：用 IoC 容器装配 Bean、@Service 封装业务、@Transactional 管理事务。SpringMVC 管 Web 层，MyBatis 管持久层。
@Transactional 的作用是（ ）
解析：@Transactional 由 Spring 的事务拦截器处理：进入方法开事务，正常结束提交，抛出运行时异常则回滚。通常加在 Service 层。
applicationContext.xml 与 springmvc-servlet.xml 的关系是（ ）
解析：applicationContext.xml（ContextLoaderListener 加载）是根容器，springmvc-servlet.xml（DispatcherServlet 加载）是 Web 子容器；子容器能访问根容器的 Bean，所以 Controller 能注入 Service/DAO。
一次「保存留言」请求的正确调用链是（ ）
解析：请求先到 DispatcherServlet，分发到 Controller；Controller 调 Service（业务+事务），Service 调 Mapper（持久层），Mapper 执行 SQL 写库。
sqlSessionFactory 的作用是（ ）
解析：sqlSessionFactory 由 applicationContext.xml 配置（指向 mybatis-config.xml），负责创建 SqlSession，是 MyBatis 持久层的入口。
SSM 分层架构的主要好处是（ ）
解析：分层让各层职责清晰、可独立替换（如 MyBatis↔JPA）；事务集中在 Service 层声明，Controller 与持久层都不必关心事务细节。
开发一个完整的 SSM 人事系统，第一步应该做什么？
解析：开发流程从需求分析开始——先明确三大功能模块与两张数据表，再依次做表设计、四层开发、部署测试；跳过需求直接写代码是初学者最常见的弯路。
SHrmSSM01B 中定义 tbl_dept / tbl_emp 两张表的文件是
解析：shrmssm.sql 是数据库脚本（CREATE DATABASE + CREATE TABLE + 示例数据），部署前先导入 MySQL；Mapper XML 只写 SQL 语句，不负责建表。
DepartmentMapper.xml 里 resultMap 的作用是
解析：dept_id→deptId 等：列名与属性名不一致（下划线 vs 驼峰）时靠 resultMap 显式映射；若完全一致，用 resultType 即可。
SHrmSSM01B 中 MapperScannerConfigurer 扫描的 Mapper 接口包是
解析：MyBatis.xml 里 basePackage="com.hrms.mapper"——Mapper 接口统一放 mapper 包；controller 包由 springmvc.xml 扫描，两者互不干扰。
MyBatis.xml 中 SqlSessionTemplate 配置了 executorType=BATCH，它是
解析：BATCH 把同类 SQL 命令攒成一批再执行，提升批量增删改性能；单条操作场景 SIMPLE 足够。
人事系统部署到 Tomcat 时，WEB 应用应放在哪个目录？
解析：Tomcat 对 webapps/ 下每个目录自动部署并解析其中的 web.xml；放 conf/bin/logs 都不会被当作 Web 应用。
Spring Data JPA 中，定义一个继承 JpaRepository 的接口后，常用 CRUD 方法
解析：Spring Data 通过 Repository 抽象 + 方法名约定（如 findByEmail）自动生成常用 CRUD 与查询，省去 MyBatis 的 Mapper+XML；复杂查询仍可下沉到 JPQL / 原生 SQL。
Thymeleaf 相比 JSP 的一个显著优点是
解析：Thymeleaf 的 th:* 属性写在合法 HTML 里，未渲染时也是标准页面，便于预览与维护；JSP 混入 Java 代码无法直接当 HTML 打开。
JSP 中 EL 表达式 ${param.name} 的作用是
解析：EL（${...}）从 request / session / application 等作用域取值，param.name 即请求参数 name；它替代 <%= %>，把取值从 Java 程序片里抽出来。
Spring IoC 能扫描 @Component 并按 @Autowired 注入，底层依赖
解析：容器用反射在运行时读取类 / 方法上的注解（@Component、@Autowired），据此决定创建与装配哪些 Bean；没有反射，注解只是编译期标记，无法被动态读取。
Java 泛型 List<String> 在运行时是
解析：Java 泛型采用类型擦除：运行期 List<String> 就是 List，取出元素时编译器插入强转；因此不能 new T()、也不能 instanceof List<String>。