优先用 LocalDate 作 key；它不可变、可比较、时区中立，避免字符串格式不一致导致的重复或漏统计，解析时需用 DateTimeFormatter 严格校验。
用 Map 存日期和签到状态，选 String 还是 LocalDate 作 key？
直接说结论：优先用 LocalDate。它天然不可变、可比较、时区中立，不会因为格式字符串拼错（比如把 "2024-05-1" 和 "2024-05-01" 当成两个日期）导致重复打卡或漏统计。
常见错误现象：Map.get("2024-5-1") 返回 null，但你确信存过——其实是 key 字符串格式不统一；或者用 SimpleDateFormat 解析时没设 setLenient(false)，把 "2024-02-30" 也糊弄过去了。
- 学生端提交的日期字符串，进 Map 前必须解析成
LocalDate.parse(input, DateTimeFormatter.ofPattern("yyyy-MM-dd")) - 避免用
new Date()或Calendar，它们带时间戳、易受系统时区影响 - 如果后端要 JSON 输出，
LocalDate默认序列化为"2024-05-01"，前端好处理
Map 选 HashMap 还是 ConcurrentHashMap？
单机、无并发写入（比如只由一个定时任务或一个管理员批量导入），用 HashMap 就够了；但只要涉及多个学生同时打卡（哪怕只是模拟请求），就必须换 ConcurrentHashMap。
容易踩的坑：HashMap 在多线程 put 时可能触发扩容，引发死循环（JDK 7）或数据丢失（JDK 8+），现象是某天的签到状态突然没了，或者 size() 返回值和实际 entry 数对不上。
-
ConcurrentHashMap的putIfAbsent()很适合“只记录第一次打卡”逻辑，比如attendanceMap.putIfAbsent(date, "present") - 别在遍历
ConcurrentHashMap时调用remove()或put()——虽然不抛ConcurrentModificationException，但行为不确定 - 如果后续要按日期范围查（比如查本周），
TreeMap更合适，但得接受O(log n)插入开销
怎么存“未打卡”“迟到”“请假”这些状态？用字符串还是枚举？
用枚举。硬编码字符串如 "absent" 或 "late" 看似简单，但一改就漏改、一拼错就难调试，比如把 "leate" 当成 "late"，前端永远收不到迟到样式。
使用场景：状态要参与判断（比如导出报表时统计“迟到次数 > 3 的学生”），枚举能靠编译器兜底。
- 定义
enum AttendanceStatus { PRESENT, LATE, ABSENT, LEAVE } - Map 的 value 类型写成
Map<localdate attendancestatus></localdate>，不是Map<localdate string></localdate> - JSON 序列化时，用 Jackson 的
@JsonValue让枚举输出小写字符串，兼容前端习惯
为什么不能直接把整个学生打卡记录塞进一个 Map<string map attendancestatus>></string>？
可以，但很快会失控。当学生数过百、日期跨度超半年，这个嵌套 Map 会变得难以遍历、无法索引、内存占用陡增——比如想查“所有迟到的学生”，就得遍历每个学生的内层 Map，O(n×m) 时间复杂度。
性能影响明显：1000 个学生 × 180 天 ≈ 18 万个 entry，HashMap 桶数组要撑到 262144 才不严重冲突，GC 压力大；更麻烦的是，没法按“状态=迟到”反向查。
- 更稳的做法：用
Map<studentid map attendancestatus>></studentid>存主数据，再额外建一个Map<localdate set>></localdate>缓存当天迟到者 - 如果数据量持续增长，Map 就该让位给轻量级嵌入式数据库（如 H2 或 SQLite），哪怕只是文件存储
- 别为了“看起来简洁”牺牲可维护性——嵌套两层 Map 已经是临界点
真正卡住人的往往不是语法，而是没想清楚“查什么”比“存什么”更重要。状态字段加一个，查询路径可能就得重写一遍。
