用Spring Boot+JPA快速搭建问卷提交接口的核心是定义结构化DTO与实体模型，避免Map接收和时间类型误用，多选题推荐关联表存储。
如何用 Spring Boot + JPA 快速搭建问卷提交接口
核心是避免从零写 HTTP 解析和数据库映射。Spring Boot 的 @RequestBody 能直接绑定 JSON 表单数据，JPA 的 @Entity 可对应问卷、题目、回答三张表。
常见错误是把所有字段塞进一个大 JSON 对象里，导致后续统计困难。正确做法是拆成结构化模型：
-
Survey：含 id、title、created_at -
Question：含 id、survey_id、text、type（”single”, “multiple”, “text”） -
Answer：含 id、question_id、respondent_id、value（String）、choices（JSON 数组，仅 multiple 用）
提交时前端发类似这样的 JSON：
{
"survey_id": 1,
"answers": [
{"question_id": 1, "value": "Java"},
{"question_id": 2, "choices": [1, 3]},
{"question_id": 3, "value": "喜欢模块化设计"}
]
}
为什么不能直接用 Map 接收表单数据
看似灵活，实则埋雷。JPA 不会自动识别 Map 中的嵌套结构，保存时要么报 IllegalArgumentException，要么存成 BLOB 失去查询能力。
立即学习“Java免费学习笔记（深入）”；
更严重的是类型丢失：前端传 "age": "25"，后端 Map 里拿到的是 String，但业务上它该是 Integer——校验、排序、聚合全会出错。
正确做法是定义 DTO 类，用 @JsonProperty 显式声明字段，并配合 @Valid 做基础校验：
public class SubmitRequest {
private Long survey_id;
@Valid
private List answers;
// getter/setter
}
public class AnswerItem {
private Long question_id;
private String value;
private List choices;
}
MySQL 存储多选题答案的两种方式及取舍
多选题选项（如“你常用哪些框架？[ ]Spring [ ]MyBatis [ ]Netty”）的答案存储，容易踩坑。
