Java如何设计简单问卷系统_表单数据存储解析

用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 失去查询能力。

更严重的是类型丢失：前端传 "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”）的答案存储，容易踩坑。

方案一：用 JSON 字段（如 JSON 类型或 TEXT 存字符串）

• 优点：写入快，结构灵活
• 缺点：MySQL 5.7+ 才支持 JSON_CONTAINS，旧版本只能用 LIKE 模糊查，无法走索引；导出做 BI 分析时解析成本高

方案二：建关联表 answer_choice(answer_id, option_id)

• 优点：可高效统计“选了 Spring 又选了 Netty 的人数”，支持外键约束和联合索引
• 缺点：插入需两步（先插 Answer，再批量插 answer_choice），代码稍多

推荐方案二，尤其当问卷要支持后台筛选导出时。

前端传时间戳，后端怎么避免时区错乱

用户在东八区填完问卷点提交，前端 JS 用 new Date().toISOString() 发 "2024-06-15T08:30:00.000Z"，后端若用 LocalDateTime 接收，会丢掉 Z（UTC 标识），变成系统默认时区时间，入库后可能偏差 8 小时。

必须统一用 Instant 或 ZonedDateTime：

• DTO 字段声明为 private Instant submit_time;
• JPA 实体对应字段用 @Column(columnDefinition = "TIMESTAMP WITH TIME ZONE")（PostgreSQL）或 datetime（MySQL，靠应用层保证 UTC）
• 配置 Jackson：spring.jackson.time-zone=UTC，确保反序列化不偏移

别依赖 java.util.Date，它已被 Instant 更清晰地替代。

复杂点在于历史问卷数据迁移和前端兼容——如果已有老系统用毫秒数传时间，后端得加 @JsonDeserialize 适配器，这点常被忽略。