应采用类型驱动设计：questionType区分题型，答案统一存String/JsonNode；Question用surveyId外键；JPA用LEFT JOIN FETCH避免N+1；DTO接收答案并用@JsonAnySetter；选项与答案分表存储。
问卷实体怎么设计才不容易改崩
Java里问卷系统最常踩的坑，是把Question和Answer硬编码成固定字段（比如String optionA、String optionB），结果加个新题型就得改类、改数据库、改前端接口。真正能撑住迭代的模型，得让题型可扩展、答案可动态解析。
建议用「类型驱动」：用questionType字段区分"single_choice"、"multiple_choice"、"text"等，答案统一存为String或JsonNode（用Jackson），而不是拆成一堆列。
-
Question类保留id、content、questionType、options（List，只对选择题有意义） -
Response类不存具体答案值，只存questionId和rawValue（String），后端按questionType决定怎么解析rawValue - 避免在
Question里放Survey引用，用外键surveyId代替，否则JPA懒加载容易出N+1
JPA映射一对多时为什么总查出null
新手常把Survey → Question → Answer全设成@OneToMany，结果survey.getQuestions()返回空集合，不是数据没查到，而是没配对FetchType或没触发初始化。
根本原因在于JPA默认LAZY，而你又没在service层调用getQuestions().size()之类触发加载，或者用了findAll()这种不带JOIN的查询。
- 开发阶段快速验证：在
@OneToMany上加fetch = FetchType.EAGER，但上线前必须改回LAZY - 真正该做的是写自定义JPQL：
@Query("SELECT s FROM Survey s LEFT JOIN FETCH s.questions q LEFT JOIN FETCH q.answers WHERE s.id = :id") - 别在
Question实体里再写@ManyToOne(fetch = FetchType.LAZY)指向Survey——循环引用+JSON序列化会直接报StackOverflowError
答案提交时怎么避免JSON格式错乱
前端传来的答案通常是{"q1": "A", "q2": ["X", "Y"], "q3": "其他说明"}这类结构，后端如果用@RequestBody Map接，Object可能是LinkedHashMap也可能是String，转成具体类型时容易ClassCastException。
更稳的方式是定义一个轻量DTO，用Jackson注解控制反序列化行为，而不是靠运行时类型判断。
- 用
@JsonAnySetter捕获所有问题ID，存在Map里 - 对单选题字段，声明为
String；多选题声明为List；文本题也声明为String——Jackson会自动转换，失败则抛HttpMessageNotReadableException - 别在Controller里手动
new ObjectMapper().readValue()，Spring Boot已配置好，直接依赖注入ObjectMapper即可
MySQL里怎么存选项和答案才不锁表
有人把所有选项拼成"A|B|C|D"存VARCHAR，答案存"A,C"，看着省事，但查“选了C的所有用户”就得LIKE '%C%'，索引失效，数据一过万就卡。
真正兼顾查询和扩展的做法是分表，但不用过度设计：一个question_option表存选项（含排序字段sortOrder），答案单独存response_answer，用(response_id, question_id)联合主键。
-
question_option表必须有question_id索引，否则后台管理加载选项时慢 -
response_answer表别加唯一约束在question_id上——同一份问卷可以有多个同题ID的答案（比如矩阵题） - 如果真要全文搜答案内容，给
response_answer.value加GENERATED COLUMN + FULLTEXT，别直接FULLTEXT原字段
题型逻辑和存储分离这事，一开始想太细会拖进度，但等到要加评分规则、导出Excel、做交叉分析时，模型没留余地就只能推倒重来。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
