简介这是一份面向Java初学者与课程设计学生的个人信息维护系统完整项目源码可作为Web开发入门与数据库操作的实战练习案例。项目围绕用户登录、个人信息展示与修改、登录历史查询等核心模块展开涉及Java面向对象编程、JDBC数据库连接、SQL增删改查以及MVC分层设计等知识点前端则结合HTML、CSS与JavaScript完成页面布局与动态交互。压缩包共78个文件约1.24MB以42个xml配置文件、8个java源码、5个css与5个js脚本为主另含2个sql建表脚本、properties配置、html页面及docx课程设计报告结构清晰便于按模块查阅。目前已有100人学习下载适合需要参考完整目录组织、理解登录校验与信息更新流程、借鉴表单验证与异常处理思路的读者也可作为课程设计报告撰写的辅助材料。1. 个人信息维护系统到底在维护什么从一张员工表说起很多 Java 初学者拿到「个人信息维护系统」这个题目第一反应是写个增删改查就交差。但真正在企业里做过 HR 系统或后台管理的人知道个人信息维护远不止 CRUD——它涉及字段级权限、数据变更审计、并发更新冲突、敏感字段脱敏这一整套工程问题。一个员工改了自己的手机号HR 看到的是完整信息同部门同事只能看到姓名和工号这条规则怎么在 Java 后端落地离职员工的档案要保留但禁止登录这个状态机怎么设计这些才是「维护」二字的重量。这个系统适合两类人一是正在做课程设计或毕业设计的 Java 学习者想从「能跑」做到「能扛住追问」二是刚转后端不久、需要一套完整练手项目来串联 Spring Boot、MyBatis-Plus、权限控制的开发者。下面我会按实际落地顺序从表结构设计一路讲到审计日志和并发处理把每个环节的参数和踩坑点都摊开说。2. 表结构与实体映射从 Java 实体类反推建表 SQL2.1 为什么先设计实体而不是先建表传统做法是先画 ER 图再建表但在 Spring Boot MyBatis-Plus 的技术栈里我习惯反过来——先写 Java 实体类再用 MyBatis-Plus 的代码生成或手写 DDL 反推建表语句。原因很实际实体类里的字段类型、注解、校验规则直接决定了数据库列的类型和约束先写实体能避免「表建好了发现 Java 类型对不上」的返工。个人信息维护系统的核心实体通常有三个用户账号User、个人档案Profile、变更记录ChangeLog。User 管登录和角色Profile 管姓名、手机、邮箱、部门这些业务字段ChangeLog 管每次修改的审计。三者通过 userId 关联但不要合并成一张大表——账号信息和档案信息的变更频率、权限要求完全不同。2.2 实体类定义与 MyBatis-Plus 注解import com.baomidou.mybatisplus.annotation.*; import lombok.Data; import java.time.LocalDateTime; Data TableName(sys_user_profile) public class UserProfile { TableId(type IdType.AUTO) private Long id; /** 关联账号ID唯一 */ TableField(user_id) private Long userId; /** 真实姓名长度2-20 */ TableField(real_name) private String realName; /** 手机号存储时加密 */ TableField(phone_encrypted) private String phoneEncrypted; /** 部门编码 */ TableField(dept_code) private String deptCode; /** 数据版本号用于乐观锁 */ Version TableField(version) private Integer version; /** 逻辑删除标记 */ TableLogic TableField(deleted) private Integer deleted; TableField(value create_time, fill FieldFill.INSERT) private LocalDateTime createTime; TableField(value update_time, fill FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }这段代码里有几个关键点需要说明。Version注解配合 MyBatis-Plus 的乐观锁插件使用每次更新时自动带上 version 条件防止两个人同时改同一条记录导致覆盖。TableLogic实现逻辑删除deleted0表示有效deleted1表示已删除查询时自动过滤。fill FieldFill.INSERT配合 MetaObjectHandler 自动填充时间字段省去每次手动 set 的麻烦。参数方面phoneEncrypted字段名刻意不叫 phone是为了提醒自己存的是密文。实际存储时用 AES 加密密钥放配置中心而非代码里。deptCode用编码而非部门名称是因为部门会改名编码不变。2.3 对应的建表 SQL 与索引策略CREATE TABLE sys_user_profile ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 关联账号ID, real_name VARCHAR(20) NOT NULL COMMENT 真实姓名, phone_encrypted VARCHAR(128) DEFAULT NULL COMMENT 加密手机号, dept_code VARCHAR(32) DEFAULT NULL COMMENT 部门编码, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_id (user_id), KEY idx_dept_code (dept_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT个人档案表;uk_user_id唯一索引保证一个账号只有一条档案。idx_dept_code支撑按部门筛选的查询。注意phone_encrypted给了 128 长度因为 AES 加密后再 Base64 编码会比原文长不少给 11 位手机号留足空间。字符集用 utf8mb4 而不是 utf8避免姓名里有生僻字或 emoji 时插入失败——这个坑我踩过当时一个同事名字里有生僻字utf8 存进去变成问号排查了半天。提示如果项目要求手机号支持模糊查询加密存储会让 LIKE 查询失效。常见做法是额外存一个手机号哈希列如 SHA256 前 8 位用于精确匹配模糊查询则走单独的脱敏视图不要试图在密文上做 LIKE。3. 接口分层与权限控制谁能看谁的手机号3.1 Controller 层的字段级权限设计个人信息维护系统最容易被面试官追问的点就是权限。不是简单的「登录才能访问」而是「不同角色看到不同字段」。我的做法是在 Controller 返回前做一层字段过滤而不是在 SQL 里查不同字段——后者会导致 SQL 数量爆炸。RestController RequestMapping(/api/profile) public class ProfileController { Autowired private ProfileService profileService; GetMapping(/{userId}) public ResultMapString, Object getProfile(PathVariable Long userId) { // 获取当前登录用户角色 String role SecurityContext.getCurrentRole(); Long currentUserId SecurityContext.getCurrentUserId(); UserProfile profile profileService.getByUserId(userId); if (profile null) { return Result.fail(档案不存在); } MapString, Object result new LinkedHashMap(); result.put(realName, profile.getRealName()); result.put(deptCode, profile.getDeptCode()); // 本人或HR可见手机号 if (currentUserId.equals(userId) || HR.equals(role)) { result.put(phone, decrypt(profile.getPhoneEncrypted())); } // 仅HR可见完整档案 if (HR.equals(role)) { result.put(createTime, profile.getCreateTime()); result.put(version, profile.getVersion()); } return Result.ok(result); } }逻辑说明先查完整实体再根据角色决定往返回 Map 里放哪些字段。这样 SQL 只有一条权限逻辑集中在 Controller便于审计。decrypt方法做 AES 解密只有确实需要展示时才调用避免无谓的解密开销。参数上SecurityContext是我项目里封装的 ThreadLocal 工具类在拦截器里从 JWT 解析后存入。角色判断用字符串比较而非枚举是为了后续加角色时不用改代码——但更好的做法是用枚举加配置表这里为了简洁先用字符串。3.2 Service 层的更新与乐观锁处理更新操作是并发问题的高发区。两个人同时打开编辑页A 先提交B 后提交如果直接 updateB 会覆盖 A 的修改。MyBatis-Plus 的乐观锁插件能解决这个问题但需要正确配置。Service public class ProfileServiceImpl implements ProfileService { Autowired private UserProfileMapper profileMapper; Override Transactional(rollbackFor Exception.class) public boolean updateProfile(Long userId, ProfileUpdateDTO dto) { UserProfile existing profileMapper.selectOne( new LambdaQueryWrapperUserProfile() .eq(UserProfile::getUserId, userId) ); if (existing null) { throw new BizException(档案不存在); } // 记录变更前快照用于审计 String beforeJson JSON.toJSONString(existing); existing.setRealName(dto.getRealName()); existing.setDeptCode(dto.getDeptCode()); if (StringUtils.isNotBlank(dto.getPhone())) { existing.setPhoneEncrypted(encrypt(dto.getPhone())); } // updateById 会自动带上 version 条件 int rows profileMapper.updateById(existing); if (rows 0) { throw new BizException(数据已被他人修改请刷新后重试); } // 写审计日志 saveChangeLog(userId, beforeJson, JSON.toJSONString(existing)); return true; } }关键在updateById返回的影响行数。乐观锁生效时如果 version 不匹配SQL 的 where 条件不满足返回 0 行。此时必须抛异常提示用户刷新而不是静默失败。Transactional保证更新和写日志在同一事务要么都成功要么都回滚。审计日志的beforeJson和afterJson存的是完整快照方便后续做 diff 展示。注意不要存解密后的手机号到日志里存密文即可否则日志本身成了泄露源。3.3 拦截器与 JWT 校验的配置要点Configuration public class WebConfig implements WebMvcConfigurer { Autowired private AuthInterceptor authInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/auth/register); } }拦截器里解析 JWT把 userId 和 role 存入 ThreadLocal。注意excludePathPatterns要精确登录注册接口必须放行否则死循环。JWT 的过期时间建议设 2 小时配合 refresh token 使用。密钥不要硬编码在代码里放环境变量或配置中心。注意ThreadLocal 用完必须在 afterCompletion 里 remove否则线程池复用时会串数据。这个 bug 很隐蔽表现为「A 用户偶尔看到 B 用户的数据」排查起来非常头疼。4. 避坑与排查个人信息维护系统最常见的 5 个翻车现场4.1 手机号加密后模糊查询失效现象HR 想按手机号后四位搜索员工发现搜不到。原因手机号加密存储后密文和原文没有前缀关系LIKE 查询自然失效。解决额外加一列phone_hash存手机号的 SHA256 值精确查询走 hash 列。模糊查询如果业务必须支持只能把手机号明文存到独立的加密表用数据库的透明加密或应用层解密后在内存过滤——后者数据量大时性能差要加缓存。4.2 乐观锁不生效现象并发更新时没有抛「请刷新重试」后提交的直接覆盖了先提交的。原因MyBatis-Plus 的乐观锁插件没有注册或者实体类上的Version注解没加或者更新时用的不是updateById而是自定义 SQL。解决检查配置类里是否注册了OptimisticLockerInnerInterceptor检查实体类 version 字段是否有Version检查更新方法是否走 MyBatis-Plus 的内置方法。自定义 SQL 需要手动在 where 里加 version 条件。4.3 逻辑删除导致唯一索引冲突现象删除一个用户后想用同样的 user_id 重新插入报唯一键冲突。原因逻辑删除只是把 deleted 置为 1记录还在表里唯一索引uk_user_id依然生效。解决把唯一索引改成(user_id, deleted)联合唯一但这样只能删一次。更好的做法是删除时把 user_id 改成一个不冲突的值如加时间戳后缀或者用物理删除配合归档表。我一般选后者逻辑删除只用于业务上需要保留的场景。4.4 时间字段自动填充失效现象create_time 和 update_time 一直是 null。原因MetaObjectHandler 没有实现或者实现类没有被 Spring 扫描到。解决写一个实现MetaObjectHandler的类加上Component注解在insertFill和updateFill方法里分别设置 createTime 和 updateTime。注意字段的 fill 属性要和 handler 里的逻辑对应。4.5 敏感字段在日志里泄露现象排查问题时看日志发现手机号、身份证号明文打印出来了。原因Controller 或 Service 里用了log.info(profile: {}, profile)把整个实体 toString 打出来了。解决实体类的 toString 里排除敏感字段或者用ToString.Exclude注解Lombok。更彻底的做法是配置日志脱敏插件在输出前正则替换手机号、身份证号。日志框架的 Pattern 里也可以做但不如在对象层面控制可靠。5. 审计日志与数据一致性把后悔药做进系统里5.1 变更记录的存储结构审计日志不是简单记一句「用户修改了手机号」而是要能回答「谁、什么时候、把哪个字段从什么改成了什么」。我的做法是存 JSON 快照加字段级 diff。Data TableName(sys_change_log) public class ChangeLog { TableId(type IdType.AUTO) private Long id; private Long userId; private String bizType; // PROFILE_UPDATE private String beforeJson; // 变更前快照 private String afterJson; // 变更后快照 private String diffFields; // 变更字段列表逗号分隔 private Long operatorId; // 操作人 private LocalDateTime createTime; }diffFields存变更的字段名方便快速筛选「谁改过手机号」。beforeJson和afterJson存完整快照前端做 diff 展示时不用再查历史版本。存储量上一条档案一天改几次也就几条日志一年下来量不大不用分表。5.2 用 AOP 统一收集变更日志手动在每个 Service 方法里写日志太累且容易漏。用 AOP 切面统一处理是更工程化的做法。Aspect Component public class ChangeLogAspect { Autowired private ChangeLogMapper changeLogMapper; Around(annotation(recordChange)) public Object around(ProceedingJoinPoint pjp, RecordChange recordChange) throws Throwable { Object[] args pjp.getArgs(); Long userId (Long) args[0]; // 查变更前快照 UserProfile before profileMapper.selectByUserId(userId); String beforeJson before null ? null : JSON.toJSONString(before); Object result pjp.proceed(); UserProfile after profileMapper.selectByUserId(userId); String afterJson after null ? null : JSON.toJSONString(after); ChangeLog log new ChangeLog(); log.setUserId(userId); log.setBizType(recordChange.value()); log.setBeforeJson(beforeJson); log.setAfterJson(afterJson); log.setDiffFields(computeDiff(beforeJson, afterJson)); log.setOperatorId(SecurityContext.getCurrentUserId()); log.setCreateTime(LocalDateTime.now()); changeLogMapper.insert(log); return result; } }computeDiff方法用 JSON 库对比两个 JSON 对象返回变化的字段名列表。注意切面里查两次数据库对性能有影响如果更新频繁可以改成在 Service 里手动传 before 快照。RecordChange是自定义注解标在需要记录的方法上。5.3 数据一致性的兜底检查审计日志和业务数据在同一事务里理论上不会不一致。但如果是异步写日志或用了消息队列就需要兜底。我的习惯是加一个定时任务每天凌晨对比档案表的 update_time 和日志表的最新记录时间如果档案更新了但没有对应日志就告警。Scheduled(cron 0 0 3 * * ?) public void checkConsistency() { ListUserProfile profiles profileMapper.selectList( new LambdaQueryWrapperUserProfile() .ge(UserProfile::getUpdateTime, LocalDateTime.now().minusDays(1)) ); for (UserProfile p : profiles) { Long count changeLogMapper.selectCount( new LambdaQueryWrapperChangeLog() .eq(ChangeLog::getUserId, p.getUserId()) .ge(ChangeLog::getCreateTime, p.getUpdateTime().minusSeconds(5)) ); if (count 0) { log.warn(档案更新但无审计日志, userId{}, p.getUserId()); } } }这个检查不能保证 100% 准确时间窗口有误差但能发现大部分遗漏。告警后人工补日志或排查原因。定时任务用Scheduled需要开启EnableSchedulingcron 表达式按实际业务调整。提示审计日志表只增不改权限上只给 HR 主管和系统管理员查询权限。日志的查询接口也要做分页避免一次拉出几万条把内存打爆。5.4 一个容易被忽略的细节时区LocalDateTime不带时区如果服务器和数据库时区不一致日志时间会对不上。我的做法是统一用LocalDateTime并在数据库连接串里指定serverTimezoneAsia/Shanghai应用层不做时区转换。如果项目要支持多时区就得用ZonedDateTime或存 UTC 时间戳那是另一个复杂度了。这套方案我前后在两个项目里用过最大的体会是个人信息维护系统的难点从来不在增删改查而在「改完之后能不能说清楚谁改的、改前是什么、为什么改」。把审计和并发控制做扎实这个项目才真正拿得出手。希望帮到你。本文还有配套的精品资源点击获取
简介这是一份面向Java初学者与课程设计学生的个人信息维护系统完整项目源码可作为Web开发入门与数据库操作的实战练习案例。项目围绕用户登录、个人信息展示与修改、登录历史查询等核心模块展开涉及Java面向对象编程、JDBC数据库连接、SQL增删改查以及MVC分层设计等知识点前端则结合HTML、CSS与JavaScript完成页面布局与动态交互。压缩包共78个文件约1.24MB以42个xml配置文件、8个java源码、5个css与5个js脚本为主另含2个sql建表脚本、properties配置、html页面及docx课程设计报告结构清晰便于按模块查阅。目前已有100人学习下载适合需要参考完整目录组织、理解登录校验与信息更新流程、借鉴表单验证与异常处理思路的读者也可作为课程设计报告撰写的辅助材料。1. 个人信息维护系统到底在维护什么从一张员工表说起很多 Java 初学者拿到「个人信息维护系统」这个题目第一反应是写个增删改查就交差。但真正在企业里做过 HR 系统或后台管理的人知道个人信息维护远不止 CRUD——它涉及字段级权限、数据变更审计、并发更新冲突、敏感字段脱敏这一整套工程问题。一个员工改了自己的手机号HR 看到的是完整信息同部门同事只能看到姓名和工号这条规则怎么在 Java 后端落地离职员工的档案要保留但禁止登录这个状态机怎么设计这些才是「维护」二字的重量。这个系统适合两类人一是正在做课程设计或毕业设计的 Java 学习者想从「能跑」做到「能扛住追问」二是刚转后端不久、需要一套完整练手项目来串联 Spring Boot、MyBatis-Plus、权限控制的开发者。下面我会按实际落地顺序从表结构设计一路讲到审计日志和并发处理把每个环节的参数和踩坑点都摊开说。2. 表结构与实体映射从 Java 实体类反推建表 SQL2.1 为什么先设计实体而不是先建表传统做法是先画 ER 图再建表但在 Spring Boot MyBatis-Plus 的技术栈里我习惯反过来——先写 Java 实体类再用 MyBatis-Plus 的代码生成或手写 DDL 反推建表语句。原因很实际实体类里的字段类型、注解、校验规则直接决定了数据库列的类型和约束先写实体能避免「表建好了发现 Java 类型对不上」的返工。个人信息维护系统的核心实体通常有三个用户账号User、个人档案Profile、变更记录ChangeLog。User 管登录和角色Profile 管姓名、手机、邮箱、部门这些业务字段ChangeLog 管每次修改的审计。三者通过 userId 关联但不要合并成一张大表——账号信息和档案信息的变更频率、权限要求完全不同。2.2 实体类定义与 MyBatis-Plus 注解import com.baomidou.mybatisplus.annotation.*; import lombok.Data; import java.time.LocalDateTime; Data TableName(sys_user_profile) public class UserProfile { TableId(type IdType.AUTO) private Long id; /** 关联账号ID唯一 */ TableField(user_id) private Long userId; /** 真实姓名长度2-20 */ TableField(real_name) private String realName; /** 手机号存储时加密 */ TableField(phone_encrypted) private String phoneEncrypted; /** 部门编码 */ TableField(dept_code) private String deptCode; /** 数据版本号用于乐观锁 */ Version TableField(version) private Integer version; /** 逻辑删除标记 */ TableLogic TableField(deleted) private Integer deleted; TableField(value create_time, fill FieldFill.INSERT) private LocalDateTime createTime; TableField(value update_time, fill FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }这段代码里有几个关键点需要说明。Version注解配合 MyBatis-Plus 的乐观锁插件使用每次更新时自动带上 version 条件防止两个人同时改同一条记录导致覆盖。TableLogic实现逻辑删除deleted0表示有效deleted1表示已删除查询时自动过滤。fill FieldFill.INSERT配合 MetaObjectHandler 自动填充时间字段省去每次手动 set 的麻烦。参数方面phoneEncrypted字段名刻意不叫 phone是为了提醒自己存的是密文。实际存储时用 AES 加密密钥放配置中心而非代码里。deptCode用编码而非部门名称是因为部门会改名编码不变。2.3 对应的建表 SQL 与索引策略CREATE TABLE sys_user_profile ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 关联账号ID, real_name VARCHAR(20) NOT NULL COMMENT 真实姓名, phone_encrypted VARCHAR(128) DEFAULT NULL COMMENT 加密手机号, dept_code VARCHAR(32) DEFAULT NULL COMMENT 部门编码, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_id (user_id), KEY idx_dept_code (dept_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT个人档案表;uk_user_id唯一索引保证一个账号只有一条档案。idx_dept_code支撑按部门筛选的查询。注意phone_encrypted给了 128 长度因为 AES 加密后再 Base64 编码会比原文长不少给 11 位手机号留足空间。字符集用 utf8mb4 而不是 utf8避免姓名里有生僻字或 emoji 时插入失败——这个坑我踩过当时一个同事名字里有生僻字utf8 存进去变成问号排查了半天。提示如果项目要求手机号支持模糊查询加密存储会让 LIKE 查询失效。常见做法是额外存一个手机号哈希列如 SHA256 前 8 位用于精确匹配模糊查询则走单独的脱敏视图不要试图在密文上做 LIKE。3. 接口分层与权限控制谁能看谁的手机号3.1 Controller 层的字段级权限设计个人信息维护系统最容易被面试官追问的点就是权限。不是简单的「登录才能访问」而是「不同角色看到不同字段」。我的做法是在 Controller 返回前做一层字段过滤而不是在 SQL 里查不同字段——后者会导致 SQL 数量爆炸。RestController RequestMapping(/api/profile) public class ProfileController { Autowired private ProfileService profileService; GetMapping(/{userId}) public ResultMapString, Object getProfile(PathVariable Long userId) { // 获取当前登录用户角色 String role SecurityContext.getCurrentRole(); Long currentUserId SecurityContext.getCurrentUserId(); UserProfile profile profileService.getByUserId(userId); if (profile null) { return Result.fail(档案不存在); } MapString, Object result new LinkedHashMap(); result.put(realName, profile.getRealName()); result.put(deptCode, profile.getDeptCode()); // 本人或HR可见手机号 if (currentUserId.equals(userId) || HR.equals(role)) { result.put(phone, decrypt(profile.getPhoneEncrypted())); } // 仅HR可见完整档案 if (HR.equals(role)) { result.put(createTime, profile.getCreateTime()); result.put(version, profile.getVersion()); } return Result.ok(result); } }逻辑说明先查完整实体再根据角色决定往返回 Map 里放哪些字段。这样 SQL 只有一条权限逻辑集中在 Controller便于审计。decrypt方法做 AES 解密只有确实需要展示时才调用避免无谓的解密开销。参数上SecurityContext是我项目里封装的 ThreadLocal 工具类在拦截器里从 JWT 解析后存入。角色判断用字符串比较而非枚举是为了后续加角色时不用改代码——但更好的做法是用枚举加配置表这里为了简洁先用字符串。3.2 Service 层的更新与乐观锁处理更新操作是并发问题的高发区。两个人同时打开编辑页A 先提交B 后提交如果直接 updateB 会覆盖 A 的修改。MyBatis-Plus 的乐观锁插件能解决这个问题但需要正确配置。Service public class ProfileServiceImpl implements ProfileService { Autowired private UserProfileMapper profileMapper; Override Transactional(rollbackFor Exception.class) public boolean updateProfile(Long userId, ProfileUpdateDTO dto) { UserProfile existing profileMapper.selectOne( new LambdaQueryWrapperUserProfile() .eq(UserProfile::getUserId, userId) ); if (existing null) { throw new BizException(档案不存在); } // 记录变更前快照用于审计 String beforeJson JSON.toJSONString(existing); existing.setRealName(dto.getRealName()); existing.setDeptCode(dto.getDeptCode()); if (StringUtils.isNotBlank(dto.getPhone())) { existing.setPhoneEncrypted(encrypt(dto.getPhone())); } // updateById 会自动带上 version 条件 int rows profileMapper.updateById(existing); if (rows 0) { throw new BizException(数据已被他人修改请刷新后重试); } // 写审计日志 saveChangeLog(userId, beforeJson, JSON.toJSONString(existing)); return true; } }关键在updateById返回的影响行数。乐观锁生效时如果 version 不匹配SQL 的 where 条件不满足返回 0 行。此时必须抛异常提示用户刷新而不是静默失败。Transactional保证更新和写日志在同一事务要么都成功要么都回滚。审计日志的beforeJson和afterJson存的是完整快照方便后续做 diff 展示。注意不要存解密后的手机号到日志里存密文即可否则日志本身成了泄露源。3.3 拦截器与 JWT 校验的配置要点Configuration public class WebConfig implements WebMvcConfigurer { Autowired private AuthInterceptor authInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/auth/register); } }拦截器里解析 JWT把 userId 和 role 存入 ThreadLocal。注意excludePathPatterns要精确登录注册接口必须放行否则死循环。JWT 的过期时间建议设 2 小时配合 refresh token 使用。密钥不要硬编码在代码里放环境变量或配置中心。注意ThreadLocal 用完必须在 afterCompletion 里 remove否则线程池复用时会串数据。这个 bug 很隐蔽表现为「A 用户偶尔看到 B 用户的数据」排查起来非常头疼。4. 避坑与排查个人信息维护系统最常见的 5 个翻车现场4.1 手机号加密后模糊查询失效现象HR 想按手机号后四位搜索员工发现搜不到。原因手机号加密存储后密文和原文没有前缀关系LIKE 查询自然失效。解决额外加一列phone_hash存手机号的 SHA256 值精确查询走 hash 列。模糊查询如果业务必须支持只能把手机号明文存到独立的加密表用数据库的透明加密或应用层解密后在内存过滤——后者数据量大时性能差要加缓存。4.2 乐观锁不生效现象并发更新时没有抛「请刷新重试」后提交的直接覆盖了先提交的。原因MyBatis-Plus 的乐观锁插件没有注册或者实体类上的Version注解没加或者更新时用的不是updateById而是自定义 SQL。解决检查配置类里是否注册了OptimisticLockerInnerInterceptor检查实体类 version 字段是否有Version检查更新方法是否走 MyBatis-Plus 的内置方法。自定义 SQL 需要手动在 where 里加 version 条件。4.3 逻辑删除导致唯一索引冲突现象删除一个用户后想用同样的 user_id 重新插入报唯一键冲突。原因逻辑删除只是把 deleted 置为 1记录还在表里唯一索引uk_user_id依然生效。解决把唯一索引改成(user_id, deleted)联合唯一但这样只能删一次。更好的做法是删除时把 user_id 改成一个不冲突的值如加时间戳后缀或者用物理删除配合归档表。我一般选后者逻辑删除只用于业务上需要保留的场景。4.4 时间字段自动填充失效现象create_time 和 update_time 一直是 null。原因MetaObjectHandler 没有实现或者实现类没有被 Spring 扫描到。解决写一个实现MetaObjectHandler的类加上Component注解在insertFill和updateFill方法里分别设置 createTime 和 updateTime。注意字段的 fill 属性要和 handler 里的逻辑对应。4.5 敏感字段在日志里泄露现象排查问题时看日志发现手机号、身份证号明文打印出来了。原因Controller 或 Service 里用了log.info(profile: {}, profile)把整个实体 toString 打出来了。解决实体类的 toString 里排除敏感字段或者用ToString.Exclude注解Lombok。更彻底的做法是配置日志脱敏插件在输出前正则替换手机号、身份证号。日志框架的 Pattern 里也可以做但不如在对象层面控制可靠。5. 审计日志与数据一致性把后悔药做进系统里5.1 变更记录的存储结构审计日志不是简单记一句「用户修改了手机号」而是要能回答「谁、什么时候、把哪个字段从什么改成了什么」。我的做法是存 JSON 快照加字段级 diff。Data TableName(sys_change_log) public class ChangeLog { TableId(type IdType.AUTO) private Long id; private Long userId; private String bizType; // PROFILE_UPDATE private String beforeJson; // 变更前快照 private String afterJson; // 变更后快照 private String diffFields; // 变更字段列表逗号分隔 private Long operatorId; // 操作人 private LocalDateTime createTime; }diffFields存变更的字段名方便快速筛选「谁改过手机号」。beforeJson和afterJson存完整快照前端做 diff 展示时不用再查历史版本。存储量上一条档案一天改几次也就几条日志一年下来量不大不用分表。5.2 用 AOP 统一收集变更日志手动在每个 Service 方法里写日志太累且容易漏。用 AOP 切面统一处理是更工程化的做法。Aspect Component public class ChangeLogAspect { Autowired private ChangeLogMapper changeLogMapper; Around(annotation(recordChange)) public Object around(ProceedingJoinPoint pjp, RecordChange recordChange) throws Throwable { Object[] args pjp.getArgs(); Long userId (Long) args[0]; // 查变更前快照 UserProfile before profileMapper.selectByUserId(userId); String beforeJson before null ? null : JSON.toJSONString(before); Object result pjp.proceed(); UserProfile after profileMapper.selectByUserId(userId); String afterJson after null ? null : JSON.toJSONString(after); ChangeLog log new ChangeLog(); log.setUserId(userId); log.setBizType(recordChange.value()); log.setBeforeJson(beforeJson); log.setAfterJson(afterJson); log.setDiffFields(computeDiff(beforeJson, afterJson)); log.setOperatorId(SecurityContext.getCurrentUserId()); log.setCreateTime(LocalDateTime.now()); changeLogMapper.insert(log); return result; } }computeDiff方法用 JSON 库对比两个 JSON 对象返回变化的字段名列表。注意切面里查两次数据库对性能有影响如果更新频繁可以改成在 Service 里手动传 before 快照。RecordChange是自定义注解标在需要记录的方法上。5.3 数据一致性的兜底检查审计日志和业务数据在同一事务里理论上不会不一致。但如果是异步写日志或用了消息队列就需要兜底。我的习惯是加一个定时任务每天凌晨对比档案表的 update_time 和日志表的最新记录时间如果档案更新了但没有对应日志就告警。Scheduled(cron 0 0 3 * * ?) public void checkConsistency() { ListUserProfile profiles profileMapper.selectList( new LambdaQueryWrapperUserProfile() .ge(UserProfile::getUpdateTime, LocalDateTime.now().minusDays(1)) ); for (UserProfile p : profiles) { Long count changeLogMapper.selectCount( new LambdaQueryWrapperChangeLog() .eq(ChangeLog::getUserId, p.getUserId()) .ge(ChangeLog::getCreateTime, p.getUpdateTime().minusSeconds(5)) ); if (count 0) { log.warn(档案更新但无审计日志, userId{}, p.getUserId()); } } }这个检查不能保证 100% 准确时间窗口有误差但能发现大部分遗漏。告警后人工补日志或排查原因。定时任务用Scheduled需要开启EnableSchedulingcron 表达式按实际业务调整。提示审计日志表只增不改权限上只给 HR 主管和系统管理员查询权限。日志的查询接口也要做分页避免一次拉出几万条把内存打爆。5.4 一个容易被忽略的细节时区LocalDateTime不带时区如果服务器和数据库时区不一致日志时间会对不上。我的做法是统一用LocalDateTime并在数据库连接串里指定serverTimezoneAsia/Shanghai应用层不做时区转换。如果项目要支持多时区就得用ZonedDateTime或存 UTC 时间戳那是另一个复杂度了。这套方案我前后在两个项目里用过最大的体会是个人信息维护系统的难点从来不在增删改查而在「改完之后能不能说清楚谁改的、改前是什么、为什么改」。把审计和并发控制做扎实这个项目才真正拿得出手。希望帮到你。本文还有配套的精品资源点击获取
![[MoeCTF 2025]mazegame_WP](http://pic.xiahunao.cn/yaotu/[MoeCTF 2025]mazegame_WP)
