在前端项目里一个字段的增删改改往往只需要修改表单、接口调用或页面展示。说起来，但在后端，副标题的“加一个字段”却是一个完整链路的演练：从数据库结构、实体映射、请求校验。到业务编排、缓存失效和权限控制。下面把这个过程拆解成易懂的几个层级，并在每一步标注前端同学常遇到的痛点。

1️⃣ 你先不需要写代码。先确认数据来源

痛点：前端只想把副标题放进 JSON，却忽略了它到底存在哪个表。

• 确认数据库里确实有 mall_product.subtitle
• 若没有。需在 SQL 脚本里添加并同步到测试环境（sql/01_schema.sql,sql/02_seed.sql)
• 记住的观点是，如果你只在本地 MySQL 修改了字段，其他环境就会报错。

2️⃣ Entity & Response 同步

痛点：实体类多了字段但页面仍旧显示旧值——忘记更新 Response。

@Data
public class ProductEntity {
private Long id;private String title;private String subtitle;// 新增
// ...
}

@Data
public class ProductDetailResponse {
private Long id;private String title;private String subtitle;// 同步
// ...
}

A. Entity 与 MyBatis 的映射规则

• Maven 项目开启了 mapUnderscoreToCamelCase
• 数据库字段 subtitle 自动映射到 Java 字段名同名。

B. Response 的组装逻辑

public ProductDetailResponse toDetailResponse {
return new ProductDetailResponse。entity.getTitle,entity.getSubtitle);}

3️⃣ Request DTO 与 Bean Validation 必不可少

痛点：前端做了校验，但后端依旧接受无效数据；或忘记 @Valid 导致校验不生效。

@Data @Builder @NoArgsConstructor @AllArgsConstructor
public class ProductSubtitleUpdateRequest {
@NotBlank
@Size
private String subtitle;}

A. 前端示意代码

async function submitSubtitle {
if ) throw new Error;if throw new Error;await request.patch;}

B. 后端 Controller 接收 & 校验入口

@PatchMapping
@Operation
public ApiResponse updateSubtitle(
@PathVariable Long id。@Valid @RequestBody ProductSubtitleUpdateRequest request,HttpServletRequest servletRequest) {
ProductDetailResponse resp = productFacade.updateSubtitle;return ApiResponse.success);
}

**注意**这方面。如果缺少 `@Valid`，Bean Validation 将不被触发。

4️⃣ 权限控制完全交给方法匹配规则。而非方法内部判断

至于**痛点**，把权限判断写在业务层容易遗漏，也让代码更难维护。

.securityMatcher.hasRole
.requestMatchers.hasRole;java
// SecurityConfig.java 示例片段
http.authorizeHttpRequests
.requestMatchers.hasRole
.anyRequest.aunticated;

管理员接口被放置在 `/api/admin/**/products/{id}/subtitle` 方法下只有拥有 ADMIN 权限的使用者才能访问；普通使用者会得到 `403 Forbidden`。说起来，

5️⃣ 缓存失效是业务关键环节 

痛点：`updateSubtitle` 成功后缓存没被清除导致匿名使用者看到旧值；或缓存删除失败导致回滚错误信息混乱。


`ProductFacade.updateSubtitle` 调用 `productDetailCacheService.evict` 删除公开详情缓存。


`evict` 方法内部捕获异常并记录日志，而不影响事务成功。

`evict` 使用 Redis key 格式 `mall:product:detail:v1:{id}`。

`evict` 在删除失败时仅写日志 `DEGRADED operation=EVICT`，TTL 会自动失效旧缓存。

`evict` 调用顺序：DB 更新 → 缓存删除 → 返回 Response。

`ProductDbService.updateSubtitle` 使用 `@Transactional` 确保 DB 写入成功才继续后续步骤。


If Redis deletion fails we don't rollback DB because Redis is just a performance layer.










A. Service 层实现 

@Transactional
public void updateSubtitle {
int rows = productDbMapper.updateById(
new LambdaUpdateWrapper<>
.eq
.set)
.set));if throw new BusinessException;其实，
 productDetailCacheService.evict;// 缓存失效


}


B. 缓存服务实现简化版 


// ProductDetailCacheService.java
public void evict {
try { redisTemplate.delete);}
catch { log.warn;}
}
private String buildKey{ return "mall:product:detail:v1:" + id;}




6️⃣ 常见错误与排查顺序 


Pain Point & Fix Summary*

#1 错误场景
- 前端只改 Controller。不改 DB 表
- 或者忘记同步 test schema
- 本地启动报错 “unknown column 'subtitle'” 或 “entity not found”
- 单元测试直接 fail


#2 错误场景
- 把管理员接口写进公开 Controller
- 或者忘记 /api/admin/** 方法匹配规则
- 普通使用者能直接访问导致安全漏洞或返回 403/
- 测试时出现 Unauthorized 错误


#3 错误场景
- 没有加 @Valid 或者 DTO 校验未生效
- POST / PATCH 接口返回 HTTP 200 成功却未更新数据库


#4 错误场景
- 缓存失效逻辑写错或者调用位置错误
- 匿名访问仍然看到旧副标题，即使 MySQL 已经更新；检查 Redis key 是否存在且已被删掉


#5 错误场景
- Redis 删除失败却回滚事务
 - 因为业务已成功，却因缓存问题导致异常状态；推荐记录日志并允许 TTL 自动清理 


*下面给出逐层排查流程图：







① HTTP 状态码 →② Token 是否有效 →③ 使用者角色是否 ADMIN →④ 参数合法性 →⑤ 数据库影响行数 →⑥ Redis 缓存是否失效 →⑦ Response 是否包含新值 ->⑧ 页面展示是否一致。





按上述顺序定位错误来源，可以快速定位是权限、校验还是缓存问题。


7️⃣ 小练习 



Create a diagram that shows how subtitle flows from client JSON body through Request DTO ➜ Controller ➜ Facade ➜ DbService ➜ MySQL ➜ Cache Eviction ➜ Response JSON.




@NotBlank

 and @Size are used on ProductSubtitleUpdateRequest. *


403 Forbidden


. *










invalidateQueries with our backend's productDetailCacheService.evict – what is common?what differs?











8️⃣ 下一章预告：调试方法与常见坑 | Front‑End 转 Back‑End 的常用方法 🚀 

This article covered everything from schema changes to cache eviction for a single field change – an exact replica of what you’ll face when moving from front‑end to back‑end development. In next part we’ll dive into debugging patterns,unit test design for service layers and how to avoid “ one wrong line” that breaks your whole flow.