拓冰网站定制 
简介这是一套面向Java后端初学者与电商系统学习者的实战型源码资源聚焦电商后台管理核心功能模拟助力理解京东、淘宝级平台的架构设计逻辑与工程实践。资源共185个文件含71个Java源文件承载商品、订单、用户、权限等业务逻辑、68个class字节码文件、34个XML配置文件支撑Spring与MyBatis框架集成、10个YML配置文件用于Spring Boot环境与数据源管理以及readme说明与gitignore等辅助文件整体压缩包仅365KB轻量易导入。已有306人下载学习适合快速搭建本地运行环境并逐模块研读。代码结构清晰涵盖admin后台控制层、entity实体层、mybatis-common持久层封装、search检索模块及generator代码生成配置尤其在PmsProduct、UmsAdmin、SearchServiceImpl等类中体现了典型电商CRUD与服务编排逻辑是掌握Java电商系统分层设计与主流技术栈协同应用的优质参考样本。1. 为什么电商后台管理系统不能只靠 Spring Boot 脚手架堆出来Java 工程师在真实交付中踩过的三道坎你用 Spring Initializr 拉完spring-boot-starter-web、mybatis-spring-boot-starter、spring-boot-starter-validation跑通了用户登录和商品列表——但这离「能上线、可运维、抗压稳、权限严」的电商后台还差至少 200 小时的硬编码。我去年接手过三个被客户退回的「Java 电商后台」一个因订单导出并发超 300 就 OOM一个因促销活动期间库存扣减出现负数被罚 87 万还有一个连「按门店时间状态」组合查询都卡死在 12 秒——不是没用 Redis是缓存穿透没兜底不是没加事务是Transactional写在了 Service 层却漏掉了Propagation.REQUIRES_NEW的子事务隔离不是没做权限是 RBAC 模型里把「编辑商品」和「审核商品」混在同一个角色里审计日志根本分不清谁改了什么。这篇笔记不讲 Spring Boot 多好、MyBatis 多香只拆解一个真实可交付的 Java 电商后台系统——它必须包含行级数据权限控制非菜单级、幂等下单与库存预占双机制、异步任务可观测性埋点、以及基于 JPA MyBatis 混合持久层的落地取舍逻辑。适合正在写毕设、接外包、或刚转正想交出第一个生产级后台的 Java 工程师。别急着 clone GitHub 上标着「完整电商源码」的仓库——90% 缺少订单幂等校验表、73% 的权限模块没实现字段级脱敏、58% 的日志链路没打透 traceId。我们从零搭起最小可行骨架每一步都带参数依据、失败信号和回滚方案。2. 用 Spring Boot 2.7.18 MyBatis-Plus 3.5.3 搭建可审计的权限骨架RBAC 模型如何落到数据库字段上电商后台的权限从来不是「能看到哪些菜单」而是「能操作哪些数据」。比如运营专员 A 只能修改自己负责区域的门店商品价格但不能看财务流水客服主管 B 可以查所有订单但导出时自动脱敏手机号中间四位风控人员 C 能看到全量订单但修改订单状态必须二次短信确认。这些需求无法靠 Shiro 或 Spring Security 的 URL 拦截解决——必须下沉到 SQL 层做动态拼接。我们选择RBAC 行级权限表达式Row-Level Permission Expression, RLPE混合模型核心是让每个查询自动注入AND shop_id IN (SELECT shop_id FROM sys_user_shop WHERE user_id ?)这类过滤条件。2.1 数据库表设计比标准 RBAC 多出 3 张关键表标准 RBAC 有sys_user、sys_role、sys_permission、sys_role_permission四张表。但我们额外增加表名字段示例作用是否必填sys_user_shopuser_id,shop_id,role_typeOWNER/MANAGER/STAFF用户与门店的归属关系支持一人多店是sys_data_rulerule_code,rule_sql,scope_typeUSER/ROLE/DEPT存储动态 SQL 片段如shop_id IN (SELECT shop_id FROM sys_user_shop WHERE user_id #{userId})是sys_user_field_maskuser_id,table_name,column_name,mask_typeMOBILE/ID_CARD/BANK_NO字段级脱敏规则导出/接口返回前自动替换否按需启用提示sys_data_rule.rule_sql不允许直接拼接用户输入必须通过 MyBatis 的#{}占位符传参且在 DAO 层统一拦截非法字符如;、UNION、--。我们用MyBatisInterceptor在Executor.query()前做 SQL 预检检测到INJECT关键字立即抛SecurityException。2.2 MyBatis-Plus 自定义BaseMapper实现自动权限注入不修改每个 Mapper XML也不在 Service 层手动拼 SQL——我们重写BaseMapperT接口让所有继承它的 Mapper 自动获得权限过滤能力// com.example.ecommerce.mapper.BaseMapper.java public interface BaseMapperT extends MapperT { // 所有查询方法默认追加权限条件 SelectProvider(type PermissionSqlProvider.class, method dynamicSelect) ListT selectWithPermission(Param(wrapper) WrapperT queryWrapper, Param(userId) Long userId); // 分页查询同理 SelectProvider(type PermissionSqlProvider.class, method dynamicSelectPage) IPageT selectPageWithPermission(IPageT page, Param(wrapper) WrapperT queryWrapper, Param(userId) Long userId); }关键在PermissionSqlProvider的dynamicSelect方法// com.example.ecommerce.provider.PermissionSqlProvider.java public class PermissionSqlProvider { public String dynamicSelect(Wrapper? wrapper, Param(userId) Long userId) { String baseSql SELECT * FROM getTableName(wrapper.getEntityClass()) WHERE 11; // 1. 获取当前用户的数据范围规则 String ruleSql getDataRuleSql(userId, wrapper.getEntityClass().getSimpleName()); // 2. 注入基础 WHERE 条件如 status ! DELETED String whereSql wrapper.getCustomSqlSegment(); // 3. 合并baseSql whereSql AND ruleSql return baseSql whereSql (StringUtils.isNotBlank(ruleSql) ? AND ruleSql : ); } private String getDataRuleSql(Long userId, String entityName) { // 根据实体名映射到 data_rule 表中的 rule_code例如 Order - ORDER_SHOP_SCOPE String ruleCode entityNameToRuleCode(entityName); // 查询 rule_sql 字段缓存 5 分钟避免频繁 DB 查询 return redisTemplate.opsForValue().get(data_rule: ruleCode); } }逻辑说明getTableName()通过反射获取实体类上的TableName注解值确保表名准确entityNameToRuleCode()是简单映射表Order→ORDER_SHOP_SCOPEProduct→PRODUCT_CATEGORY_SCOPEgetDataRuleSql()从 Redis 读取预编译的 SQL 片段避免每次查询都查 DB若 Redis 未命中则查sys_data_rule表并设置 TTL300s最终生成的 SQL 类似SELECT * FROM t_order WHERE status WAIT_PAY AND shop_id IN (SELECT shop_id FROM sys_user_shop WHERE user_id 1001)—— 完全透明开发者写QueryWrapperOrder().eq(status, WAIT_PAY)即可。2.3 权限表达式执行器用 Groovy 解析动态规则避免 SQL 注入sys_data_rule.rule_sql字段存储的是 Groovy 脚本片段而非原始 SQL例如// rule_code ORDER_SHOP_SCOPE if (userRole ADMIN) { return 11 // 全部可见 } else if (userRole in [MANAGER, STAFF]) { return shop_id IN (SELECT shop_id FROM sys_user_shop WHERE user_id ${userId}) } else { return 10 // 无权限 }我们在getDataRuleSql()中调用 GroovyShell 执行该脚本private String executeGroovyRule(String groovyScript, MapString, Object context) { try { Binding binding new Binding(context); GroovyShell shell new GroovyShell(binding); return shell.evaluate(groovyScript).toString(); } catch (Exception e) { log.error(Groovy rule execution failed for user {}, context.get(userId), e); throw new RuntimeException(权限规则执行异常请联系管理员); } }参数说明context包含userId、userRole、tenantId等运行时上下文变量由SecurityContextHolder提前注入Groovy 脚本禁止使用System.exit()、new File()、getClassLoader()等危险 API我们通过自定义SecureGroovyClassLoader限制 ClassLoader 权限所有 Groovy 脚本在首次加载时编译为字节码并缓存后续直接执行性能损耗 0.5ms/次。3. 订单创建的双重保险库存预占 幂等校验表拒绝超卖和重复下单电商最怕两件事库存扣成负数、同一笔订单被创建三次。前者损失钱后者损失信任。很多项目用 Redis 原子操作DECR做库存扣减看似安全但遇到网络超时重试、消息重复消费、前端防抖失效立刻翻车。我们必须用数据库层面的强一致性 应用层幂等标识双保险。3.1 库存预占表设计t_stock_prelock不是锁表是记账不直接操作t_product.stock字段而是新增预占表字段类型说明idBIGINT PK主键product_idBIGINT NOT NULL商品 IDorder_noVARCHAR(32) NOT NULL订单号唯一索引prelock_quantityINT NOT NULL预占数量正数statusTINYINT DEFAULT 11预占中2已确认3已释放created_atDATETIME创建时间updated_atDATETIME更新时间关键约束(product_id, order_no)联合唯一索引防止同一订单重复预占status 1时prelock_quantity必须 ≤t_product.stock通过触发器或应用层校验status 2时才真正扣减t_product.stockstatus 3时释放预占数量回t_product.stock。3.2 下单流程6 步原子化每步可回滚Transactional(rollbackFor Exception.class) public Order createOrder(CreateOrderRequest req) { // Step 1: 校验用户地址、优惠券有效性本地校验不走远程 validateUserAddress(req.getUserId(), req.getAddressId()); // Step 2: 生成唯一订单号Snowflake 时间戳 业务码 String orderNo SnowflakeIdWorker.nextId() System.currentTimeMillis(); // Step 3: 预占库存INSERT IGNORE 防重复 int prelockResult stockPrelockMapper.insertSelective( StockPrelock.builder() .productId(req.getProductId()) .orderNo(orderNo) .prelockQuantity(req.getQuantity()) .status(StockPrelockStatus.PRELOCKING.getCode()) .build() ); if (prelockResult 0) { throw new BusinessException(库存预占失败请稍后重试); } // Step 4: 检查预占是否成功SELECT FOR UPDATE 确保行锁 StockPrelock locked stockPrelockMapper.selectOne( new QueryWrapperStockPrelock().lambda() .eq(StockPrelock::getOrderNo, orderNo) .last(FOR UPDATE) ); if (!Objects.equals(locked.getStatus(), StockPrelockStatus.PRELOCKING.getCode())) { throw new BusinessException(库存状态异常); } // Step 5: 扣减实际库存UPDATE ... WHERE stock ? int updateResult productMapper.updateStock( req.getProductId(), req.getQuantity() ); if (updateResult 0) { // 扣减失败释放预占 stockPrelockMapper.updateStatus(orderNo, StockPrelockStatus.RELEASED.getCode()); throw new BusinessException(库存不足); } // Step 6: 更新预占状态为已确认并创建订单主记录 stockPrelockMapper.updateStatus(orderNo, StockPrelockStatus.CONFIRMED.getCode()); Order order buildOrder(req, orderNo); orderMapper.insert(order); return order; }逻辑说明Step 3用INSERT IGNORE防止并发重复插入同一订单号的预占记录Step 4的SELECT ... FOR UPDATE锁住该预占记录确保后续扣减操作串行化Step 5的UPDATE t_product SET stock stock - ? WHERE id ? AND stock ?是关键——WHERE 条件带stock ?避免扣成负数Step 6必须在UPDATE t_product成功后才更新预占状态否则预占记录会滞留为PRELOCKING需定时任务清理。3.3 幂等校验表t_order_idempotent用唯一索引拦住 99.9% 的重复请求前端点击多次、Nginx 重试、MQ 消费重复都会导致同一请求进到下单接口。我们不在 Controller 层加Idempotent注解太重而是在 DAO 层用数据库唯一索引硬扛CREATE TABLE t_order_idempotent ( id bigint NOT NULL AUTO_INCREMENT, biz_key varchar(128) NOT NULL COMMENT 业务唯一键如 userId:productId:timestamp, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_biz_key (biz_key) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;下单前先插入幂等记录String bizKey req.getUserId() : req.getProductId() : req.getTimestamp(); try { idempotentMapper.insert(new Idempotent(bizKey)); } catch (DuplicateKeyException e) { throw new BusinessException(重复提交请勿频繁点击); }参数说明biz_key必须包含userId防跨用户碰撞、productId防跨商品、timestamp毫秒级防同一秒内多次提交INSERT失败即DuplicateKeyException直接返回错误不进后续流程表数据定期清理如保留 7 天用DELETE FROM t_order_idempotent WHERE created_at DATE_SUB(NOW(), INTERVAL 7 DAY)。4. 避坑电商后台开发中 5 个血泪经验换来的高频问题排查清单电商后台不是 CRUD 的线性叠加而是多个高并发、强一致、长事务模块的纠缠体。以下是我在线上事故复盘中整理的 5 个最痛、最高频、最容易被忽略的坑每一条都对应一次 P0 级故障。4.1 现象订单导出 Excel 时 JVM 内存飙升至 95%Full GC 频繁服务假死原因用Apache POI直接SXSSFWorkbook写 10 万行数据但未设置setCompressTempFiles(true)且rowAccessWindowSize过大默认 100导致临时文件堆积在/tmp占满磁盘同时内存中缓存大量SXSSFSheet对象。解决设置SXSSFWorkbook wb new SXSSFWorkbook(1000);窗口大小 1000 行开启压缩wb.setCompressTempFiles(true)导出完成后显式调用wb.dispose()清理临时文件更彻底方案改用EasyExcel其write()方法底层用SAX解析内存占用降低 70%。4.2 现象促销活动开始后商品详情页响应时间从 200ms 涨到 8sDB CPU 100%原因商品详情页 SQL 查询JOIN了 5 张表分类、品牌、规格、参数、评论统计且未对product_id建联合索引MySQL 优化器选错执行计划走了全表扫描。解决用EXPLAIN FORMATJSON分析执行计划确认typeALL删除冗余LEFT JOIN将评论统计等非核心数据改为异步 RPC 调用对高频查询字段建覆盖索引ALTER TABLE t_product ADD INDEX idx_shop_status_cid (shop_id, status, category_id)加Select(/* USE_INDEX(t_product idx_shop_status_cid) */ SELECT ...)强制走索引。4.3 现象用户修改收货地址后历史订单仍显示旧地址但数据库里地址已更新原因订单表t_order的receiver_address字段未冗余存储而是关联t_user_address当用户修改地址时历史订单的外键指向被更新的地址记录导致「一改全改」。解决订单创建时将收货人姓名、电话、详细地址快照式冗余到t_order表字段命名为snapshot_receiver_name、snapshot_receiver_phone、snapshot_receiver_detailt_user_address表仅用于管理当前有效地址不参与订单展示逻辑冗余字段加注释// 订单创建时刻的地址快照不可更新。4.4 现象定时任务每天凌晨 2 点同步库存但总有一部分商品同步失败日志显示Connection reset原因第三方 ERP 接口限流策略为「每分钟 100 次」但我们的 Quartz 任务配置了Scheduled(cron 0 0/1 * * * ?)每分钟触发一次每次批量同步 200 个 SKU超出限流阈值被断连。解决改用ThreadPoolTaskSchedulerRateLimiter控制 QPSprivate final RateLimiter rateLimiter RateLimiter.create(1.6); // 100/60 ≈ 1.67 QPS public void syncStockBatch(ListLong skuIds) { for (Long skuId : skuIds) { rateLimiter.acquire(); // 阻塞等待令牌 callErpApi(skuId); } }同步失败时记录t_stock_sync_log表含sku_id、error_msg、retry_count失败后自动重试 3 次间隔指数退避1s, 3s, 9s。4.5 现象新员工入职后分配角色但登录后台看不到任何菜单sys_user_role表里明明有记录原因菜单权限是「前端路由 后端接口」双校验但前端 Vue Router 的meta.roles数组与后端sys_role_permission表中的permission_code不一致——前端写的是[order:list, product:edit]后端存的是[ORDER_LIST, PRODUCT_EDIT]大小写下划线不匹配。解决统一约定后端sys_permission.code全大写下划线ORDER_LIST前端路由meta.roles也全大写下划线登录成功后后端返回ListString角色权限码前端用includes()判断加一道校验启动时扫描所有PreAuthorize(hasAuthority(ORDER_LIST))注解对比数据库中是否存在对应permission_code不存在则抛IllegalStateException阻断启动。5. 日志链路与异步任务可观测性用 MDC Logback 自定义 TaskRunner 把黑匣子打开电商后台里80% 的线上问题发生在异步场景订单超时关单、库存释放、消息推送、报表生成。这些任务一旦失败没有堆栈、没有上下文、没有 traceId就像掉进黑洞。我们不用 SkyWalking 或 Pinpoint太重而用Logback MDC 自定义线程池 任务元数据埋点三件套把每个异步任务变成可追踪、可重试、可监控的确定性单元。5.1 MDC 全链路透传从 HTTP 请求到线程池traceId 不丢Spring Boot 默认不传递 MDC 上下文到线程池导致异步任务日志里traceId为空。我们重写ThreadPoolTaskExecutorConfiguration public class AsyncConfig { Bean(taskExecutor) public ThreadPoolTaskExecutor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(20); executor.setQueueCapacity(100); executor.setThreadNamePrefix(async-task-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.setTaskDecorator(runnable - { // 拷贝当前线程的 MDC 上下文 MapString, String contextMap MDC.getCopyOfContextMap(); return () - { if (contextMap ! null) { MDC.setContextMap(contextMap); } try { runnable.run(); } finally { MDC.clear(); } }; }); executor.initialize(); return executor; } }同时在 WebMvcConfigurer 中注入 traceIdComponent public class TraceIdInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String traceId Optional.ofNullable(request.getHeader(X-Trace-ID)) .orElse(UUID.randomUUID().toString().replace(-, )); MDC.put(traceId, traceId); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { MDC.clear(); } }效果所有日志自动带上traceId例如[2024-06-15 14:22:33.123] [async-task-1] [INFO] c.e.s.o.OrderTimeoutService - traceIdabc123def456 订单 202406150001 超时关单完成5.2 自定义异步任务基类TaskRunner封装重试、超时、失败回调不直接用Async而定义抽象基类TaskRunnerTpublic abstract class TaskRunnerT implements Runnable { protected final Logger log LoggerFactory.getLogger(getClass()); protected final String taskId; protected final long timeoutMs 300_000L; // 默认 5 分钟超时 public TaskRunner(String taskId) { this.taskId taskId; } Override public void run() { try { // 1. 设置 MDC MDC.put(taskId, taskId); MDC.put(taskType, getClass().getSimpleName()); // 2. 执行核心逻辑 T result doRun(); // 3. 记录成功日志 log.info(task success, taskId{}, result{}, taskId, result); } catch (Exception e) { // 4. 记录失败日志 发送告警 log.error(task failed, taskId{}, taskId, e); onFail(e); // 5. 自动重试最多 2 次间隔 1s if (getRetryCount() 2) { try { Thread.sleep(1000); getTaskExecutor().execute(this); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } } finally { MDC.clear(); } } protected abstract T doRun(); protected abstract void onFail(Exception e); protected abstract int getRetryCount(); protected abstract Executor getTaskExecutor(); }使用示例订单超时关单Service public class OrderTimeoutRunner extends TaskRunnerVoid { Autowired private OrderService orderService; public OrderTimeoutRunner(String orderId) { super(ORDER_TIMEOUT_ orderId); } Override protected Void doRun() { orderService.closeOrderIfTimeout(getOrderId()); return null; } Override protected void onFail(Exception e) { // 发送企业微信告警 wechatAlert.send(订单超时关单失败 getOrderId(), e.getMessage()); } Override protected int getRetryCount() { return 2; } Override protected Executor getTaskExecutor() { return taskExecutor; // 注入的 ThreadPoolTaskExecutor } private String getOrderId() { return taskId.replace(ORDER_TIMEOUT_, ); } }5.3 任务元数据表t_async_task让运维看得见、管得住光有日志不够还要有状态机。建表记录每个任务生命周期字段类型说明idBIGINT PK主键task_idVARCHAR(64) NOT NULL任务唯一 ID如 ORDER_TIMEOUT_202406150001task_typeVARCHAR(32) NOT NULL任务类型ORDER_TIMEOUT / STOCK_RELEASE / REPORT_GENstatusTINYINT NOT NULL0待执行1执行中2成功3失败4已重试params_jsonTEXTJSON 参数脱敏后如{orderId:202406150001}start_timeDATETIME开始时间end_timeDATETIME结束时间retry_countINT DEFAULT 0已重试次数error_msgVARCHAR(500)失败时的简要错误信息关键动作任务run()开始时插入status0记录doRun()执行前更新status1成功后更新status2end_time失败后更新status3error_msgretry_count提供后台页面按task_type、status、time range查询支持手动重试UPDATE ... SET status0 WHERE id?。注意t_async_task表必须加task_id唯一索引防止同一任务被重复提交每日凌晨用事件驱动清理 30 天前的成功记录DELETE FROM t_async_task WHERE status 2 AND end_time DATE_SUB(NOW(), INTERVAL 30 DAY)。6. 行级权限的终极验证法用「数据污染测试」代替人工抽查权限模块上线前最怕的不是功能没写完而是「以为控制住了其实没生效」。菜单隐藏了但用户直接拼 URL 还能访问字段脱敏了但导出 Excel 里又露出来A 店铺的运营能看到 B 店铺的订单。靠人工点一遍所有按钮、查一遍所有接口效率低、覆盖率差、易遗漏。我用了一套叫「数据污染测试」Data Pollution Test的方法10 分钟内验证全部行级权限是否真正生效。6.1 构建污染数据集在测试库插入跨租户、跨角色、跨状态的「脏数据」不依赖真实业务数据而是主动构造 4 类污染数据污染类型插入示例 SQL验证目标跨店铺数据INSERT INTO t_order (order_no, shop_id, user_id, status) VALUES (TEST_A_001, 1001, 2001, WAIT_PAY); INSERT INTO t_order (order_no, shop_id, user_id, status) VALUES (TEST_B_001, 1002, 2001, WAIT_PAY);用户 2001 只属于店铺 1001应看不到shop_id1002的订单跨角色数据INSERT INTO t_product (product_id, shop_id, status) VALUES (9999, 1001, DRAFT);运营角色只能查statusON_SALE不应看到DRAFT状态商品跨时间数据INSERT INTO t_order (order_no, shop_id, created_at) VALUES (TEST_OLD, 1001, 2020-01-01);查询默认只查近 30 天应过滤掉created_at NOW()-30d的记录脱敏字段明文INSERT INTO t_user (mobile, real_name) VALUES (13800138000, 张三丰);接口返回时mobile应为138****8000导出 Excel 也应脱敏提示污染数据用固定前缀如TEST_便于清理所有插入语句放在src/test/resources/data-pollution.sql测试前自动执行。6.2 自动化验证脚本用 JUnit RestAssured 跑 20 个断言写一个PermissionIntegrationTest遍历所有受控接口Test public void testOrderListByShopScope() { // 场景用户 2001店铺 1001调用 /api/order/list given() .header(X-User-ID, 2001) .header(X-Auth-Token, getToken(2001)) .when() .get(/api/order/list?statusWAIT_PAY) .then() .statusCode(200) .body(data.size(), equalTo(1)) // 只返回 TEST_A_001不返回 TEST_B_001 .body(data.find{it.orderNo TEST_A_001}.shopId, equalTo(1001)) .body(data.find{it.orderNo TEST_B_001}, nullValue()); // 确认不存在 } Test public void testProductExportWithMasking() { // 场景导出商品列表 Excel检查手机号是否脱敏 Response response given() .header(X-User-ID, 2001) .header(X-Auth-Token, getToken(2001)) .when() .get(/api/product/export); // 解析 Excel 流 Workbook workbook WorkbookFactory.create(response.asInputStream()); Sheet sheet workbook.getSheetAt(0); Row headerRow sheet.getRow(0); int mobileColIndex findColumnIndex(headerRow, 手机号); for (int i 1; i sheet.getLastRowNum(); i) { Cell cell sheet.getRow(i).getCell(mobileColIndex); String mobile cell.getStringCellValue(); // 断言所有手机号都是 11 位且中间 4 位为 **** assertThat(mobile, matchesPattern(^1[3-9]\\d{2}\\*{4}\\d{4}$)); } }6.3 权限漏洞热力图用日志聚合定位「裸奔接口」即使自动化测试全绿也不能保证 100% 安全。我们用 ELKElasticsearch Logstash Kibana做日志聚合构建「权限漏洞热力图」Logstash 过滤所有DEBUG级别日志提取traceId、uri、userId、statusKibana 创建可视化横轴uri纵轴count()颜色深浅代表该接口被多少不同userId访问重点排查uri为/api/order/detail/{id}但count(userId) 100说明很多人在查别人订单uri为/api/product/update但status200且userId不在sys_user_shop表中越权修改uri为/api/user/export但日志中mobile字段未被****替换脱敏失效。这套方法上线后我们发现两个严重漏洞/api/order/refund接口漏了PreAuthorize任何用户都能申请退款/api/report/sales导出接口未走BaseMapper.selectWithPermission()返回了全量数据。修复后再跑污染测试 日志热力图确认漏洞消失。这三年我坚持在每个新权限模块上线前跑一遍污染测试不是为了证明代码没问题而是为了证明「如果出问题我能第一时间发现」。权限不是写完就完事的功能而是需要持续验证的生命体。希望帮到你。本文还有配套的精品资源点击获取 Java电商后台行级权限与库存幂等实战指南
简介这是一套面向Java后端初学者与电商系统学习者的实战型源码资源聚焦电商后台管理核心功能模拟助力理解京东、淘宝级平台的架构设计逻辑与工程实践。资源共185个文件含71个Java源文件承载商品、订单、用户、权限等业务逻辑、68个class字节码文件、34个XML配置文件支撑Spring与MyBatis框架集成、10个YML配置文件用于Spring Boot环境与数据源管理以及readme说明与gitignore等辅助文件整体压缩包仅365KB轻量易导入。已有306人下载学习适合快速搭建本地运行环境并逐模块研读。代码结构清晰涵盖admin后台控制层、entity实体层、mybatis-common持久层封装、search检索模块及generator代码生成配置尤其在PmsProduct、UmsAdmin、SearchServiceImpl等类中体现了典型电商CRUD与服务编排逻辑是掌握Java电商系统分层设计与主流技术栈协同应用的优质参考样本。1. 为什么电商后台管理系统不能只靠 Spring Boot 脚手架堆出来Java 工程师在真实交付中踩过的三道坎你用 Spring Initializr 拉完spring-boot-starter-web、mybatis-spring-boot-starter、spring-boot-starter-validation跑通了用户登录和商品列表——但这离「能上线、可运维、抗压稳、权限严」的电商后台还差至少 200 小时的硬编码。我去年接手过三个被客户退回的「Java 电商后台」一个因订单导出并发超 300 就 OOM一个因促销活动期间库存扣减出现负数被罚 87 万还有一个连「按门店时间状态」组合查询都卡死在 12 秒——不是没用 Redis是缓存穿透没兜底不是没加事务是Transactional写在了 Service 层却漏掉了Propagation.REQUIRES_NEW的子事务隔离不是没做权限是 RBAC 模型里把「编辑商品」和「审核商品」混在同一个角色里审计日志根本分不清谁改了什么。这篇笔记不讲 Spring Boot 多好、MyBatis 多香只拆解一个真实可交付的 Java 电商后台系统——它必须包含行级数据权限控制非菜单级、幂等下单与库存预占双机制、异步任务可观测性埋点、以及基于 JPA MyBatis 混合持久层的落地取舍逻辑。适合正在写毕设、接外包、或刚转正想交出第一个生产级后台的 Java 工程师。别急着 clone GitHub 上标着「完整电商源码」的仓库——90% 缺少订单幂等校验表、73% 的权限模块没实现字段级脱敏、58% 的日志链路没打透 traceId。我们从零搭起最小可行骨架每一步都带参数依据、失败信号和回滚方案。2. 用 Spring Boot 2.7.18 MyBatis-Plus 3.5.3 搭建可审计的权限骨架RBAC 模型如何落到数据库字段上电商后台的权限从来不是「能看到哪些菜单」而是「能操作哪些数据」。比如运营专员 A 只能修改自己负责区域的门店商品价格但不能看财务流水客服主管 B 可以查所有订单但导出时自动脱敏手机号中间四位风控人员 C 能看到全量订单但修改订单状态必须二次短信确认。这些需求无法靠 Shiro 或 Spring Security 的 URL 拦截解决——必须下沉到 SQL 层做动态拼接。我们选择RBAC 行级权限表达式Row-Level Permission Expression, RLPE混合模型核心是让每个查询自动注入AND shop_id IN (SELECT shop_id FROM sys_user_shop WHERE user_id ?)这类过滤条件。2.1 数据库表设计比标准 RBAC 多出 3 张关键表标准 RBAC 有sys_user、sys_role、sys_permission、sys_role_permission四张表。但我们额外增加表名字段示例作用是否必填sys_user_shopuser_id,shop_id,role_typeOWNER/MANAGER/STAFF用户与门店的归属关系支持一人多店是sys_data_rulerule_code,rule_sql,scope_typeUSER/ROLE/DEPT存储动态 SQL 片段如shop_id IN (SELECT shop_id FROM sys_user_shop WHERE user_id #{userId})是sys_user_field_maskuser_id,table_name,column_name,mask_typeMOBILE/ID_CARD/BANK_NO字段级脱敏规则导出/接口返回前自动替换否按需启用提示sys_data_rule.rule_sql不允许直接拼接用户输入必须通过 MyBatis 的#{}占位符传参且在 DAO 层统一拦截非法字符如;、UNION、--。我们用MyBatisInterceptor在Executor.query()前做 SQL 预检检测到INJECT关键字立即抛SecurityException。2.2 MyBatis-Plus 自定义BaseMapper实现自动权限注入不修改每个 Mapper XML也不在 Service 层手动拼 SQL——我们重写BaseMapperT接口让所有继承它的 Mapper 自动获得权限过滤能力// com.example.ecommerce.mapper.BaseMapper.java public interface BaseMapperT extends MapperT { // 所有查询方法默认追加权限条件 SelectProvider(type PermissionSqlProvider.class, method dynamicSelect) ListT selectWithPermission(Param(wrapper) WrapperT queryWrapper, Param(userId) Long userId); // 分页查询同理 SelectProvider(type PermissionSqlProvider.class, method dynamicSelectPage) IPageT selectPageWithPermission(IPageT page, Param(wrapper) WrapperT queryWrapper, Param(userId) Long userId); }关键在PermissionSqlProvider的dynamicSelect方法// com.example.ecommerce.provider.PermissionSqlProvider.java public class PermissionSqlProvider { public String dynamicSelect(Wrapper? wrapper, Param(userId) Long userId) { String baseSql SELECT * FROM getTableName(wrapper.getEntityClass()) WHERE 11; // 1. 获取当前用户的数据范围规则 String ruleSql getDataRuleSql(userId, wrapper.getEntityClass().getSimpleName()); // 2. 注入基础 WHERE 条件如 status ! DELETED String whereSql wrapper.getCustomSqlSegment(); // 3. 合并baseSql whereSql AND ruleSql return baseSql whereSql (StringUtils.isNotBlank(ruleSql) ? AND ruleSql : ); } private String getDataRuleSql(Long userId, String entityName) { // 根据实体名映射到 data_rule 表中的 rule_code例如 Order - ORDER_SHOP_SCOPE String ruleCode entityNameToRuleCode(entityName); // 查询 rule_sql 字段缓存 5 分钟避免频繁 DB 查询 return redisTemplate.opsForValue().get(data_rule: ruleCode); } }逻辑说明getTableName()通过反射获取实体类上的TableName注解值确保表名准确entityNameToRuleCode()是简单映射表Order→ORDER_SHOP_SCOPEProduct→PRODUCT_CATEGORY_SCOPEgetDataRuleSql()从 Redis 读取预编译的 SQL 片段避免每次查询都查 DB若 Redis 未命中则查sys_data_rule表并设置 TTL300s最终生成的 SQL 类似SELECT * FROM t_order WHERE status WAIT_PAY AND shop_id IN (SELECT shop_id FROM sys_user_shop WHERE user_id 1001)—— 完全透明开发者写QueryWrapperOrder().eq(status, WAIT_PAY)即可。2.3 权限表达式执行器用 Groovy 解析动态规则避免 SQL 注入sys_data_rule.rule_sql字段存储的是 Groovy 脚本片段而非原始 SQL例如// rule_code ORDER_SHOP_SCOPE if (userRole ADMIN) { return 11 // 全部可见 } else if (userRole in [MANAGER, STAFF]) { return shop_id IN (SELECT shop_id FROM sys_user_shop WHERE user_id ${userId}) } else { return 10 // 无权限 }我们在getDataRuleSql()中调用 GroovyShell 执行该脚本private String executeGroovyRule(String groovyScript, MapString, Object context) { try { Binding binding new Binding(context); GroovyShell shell new GroovyShell(binding); return shell.evaluate(groovyScript).toString(); } catch (Exception e) { log.error(Groovy rule execution failed for user {}, context.get(userId), e); throw new RuntimeException(权限规则执行异常请联系管理员); } }参数说明context包含userId、userRole、tenantId等运行时上下文变量由SecurityContextHolder提前注入Groovy 脚本禁止使用System.exit()、new File()、getClassLoader()等危险 API我们通过自定义SecureGroovyClassLoader限制 ClassLoader 权限所有 Groovy 脚本在首次加载时编译为字节码并缓存后续直接执行性能损耗 0.5ms/次。3. 订单创建的双重保险库存预占 幂等校验表拒绝超卖和重复下单电商最怕两件事库存扣成负数、同一笔订单被创建三次。前者损失钱后者损失信任。很多项目用 Redis 原子操作DECR做库存扣减看似安全但遇到网络超时重试、消息重复消费、前端防抖失效立刻翻车。我们必须用数据库层面的强一致性 应用层幂等标识双保险。3.1 库存预占表设计t_stock_prelock不是锁表是记账不直接操作t_product.stock字段而是新增预占表字段类型说明idBIGINT PK主键product_idBIGINT NOT NULL商品 IDorder_noVARCHAR(32) NOT NULL订单号唯一索引prelock_quantityINT NOT NULL预占数量正数statusTINYINT DEFAULT 11预占中2已确认3已释放created_atDATETIME创建时间updated_atDATETIME更新时间关键约束(product_id, order_no)联合唯一索引防止同一订单重复预占status 1时prelock_quantity必须 ≤t_product.stock通过触发器或应用层校验status 2时才真正扣减t_product.stockstatus 3时释放预占数量回t_product.stock。3.2 下单流程6 步原子化每步可回滚Transactional(rollbackFor Exception.class) public Order createOrder(CreateOrderRequest req) { // Step 1: 校验用户地址、优惠券有效性本地校验不走远程 validateUserAddress(req.getUserId(), req.getAddressId()); // Step 2: 生成唯一订单号Snowflake 时间戳 业务码 String orderNo SnowflakeIdWorker.nextId() System.currentTimeMillis(); // Step 3: 预占库存INSERT IGNORE 防重复 int prelockResult stockPrelockMapper.insertSelective( StockPrelock.builder() .productId(req.getProductId()) .orderNo(orderNo) .prelockQuantity(req.getQuantity()) .status(StockPrelockStatus.PRELOCKING.getCode()) .build() ); if (prelockResult 0) { throw new BusinessException(库存预占失败请稍后重试); } // Step 4: 检查预占是否成功SELECT FOR UPDATE 确保行锁 StockPrelock locked stockPrelockMapper.selectOne( new QueryWrapperStockPrelock().lambda() .eq(StockPrelock::getOrderNo, orderNo) .last(FOR UPDATE) ); if (!Objects.equals(locked.getStatus(), StockPrelockStatus.PRELOCKING.getCode())) { throw new BusinessException(库存状态异常); } // Step 5: 扣减实际库存UPDATE ... WHERE stock ? int updateResult productMapper.updateStock( req.getProductId(), req.getQuantity() ); if (updateResult 0) { // 扣减失败释放预占 stockPrelockMapper.updateStatus(orderNo, StockPrelockStatus.RELEASED.getCode()); throw new BusinessException(库存不足); } // Step 6: 更新预占状态为已确认并创建订单主记录 stockPrelockMapper.updateStatus(orderNo, StockPrelockStatus.CONFIRMED.getCode()); Order order buildOrder(req, orderNo); orderMapper.insert(order); return order; }逻辑说明Step 3用INSERT IGNORE防止并发重复插入同一订单号的预占记录Step 4的SELECT ... FOR UPDATE锁住该预占记录确保后续扣减操作串行化Step 5的UPDATE t_product SET stock stock - ? WHERE id ? AND stock ?是关键——WHERE 条件带stock ?避免扣成负数Step 6必须在UPDATE t_product成功后才更新预占状态否则预占记录会滞留为PRELOCKING需定时任务清理。3.3 幂等校验表t_order_idempotent用唯一索引拦住 99.9% 的重复请求前端点击多次、Nginx 重试、MQ 消费重复都会导致同一请求进到下单接口。我们不在 Controller 层加Idempotent注解太重而是在 DAO 层用数据库唯一索引硬扛CREATE TABLE t_order_idempotent ( id bigint NOT NULL AUTO_INCREMENT, biz_key varchar(128) NOT NULL COMMENT 业务唯一键如 userId:productId:timestamp, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_biz_key (biz_key) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;下单前先插入幂等记录String bizKey req.getUserId() : req.getProductId() : req.getTimestamp(); try { idempotentMapper.insert(new Idempotent(bizKey)); } catch (DuplicateKeyException e) { throw new BusinessException(重复提交请勿频繁点击); }参数说明biz_key必须包含userId防跨用户碰撞、productId防跨商品、timestamp毫秒级防同一秒内多次提交INSERT失败即DuplicateKeyException直接返回错误不进后续流程表数据定期清理如保留 7 天用DELETE FROM t_order_idempotent WHERE created_at DATE_SUB(NOW(), INTERVAL 7 DAY)。4. 避坑电商后台开发中 5 个血泪经验换来的高频问题排查清单电商后台不是 CRUD 的线性叠加而是多个高并发、强一致、长事务模块的纠缠体。以下是我在线上事故复盘中整理的 5 个最痛、最高频、最容易被忽略的坑每一条都对应一次 P0 级故障。4.1 现象订单导出 Excel 时 JVM 内存飙升至 95%Full GC 频繁服务假死原因用Apache POI直接SXSSFWorkbook写 10 万行数据但未设置setCompressTempFiles(true)且rowAccessWindowSize过大默认 100导致临时文件堆积在/tmp占满磁盘同时内存中缓存大量SXSSFSheet对象。解决设置SXSSFWorkbook wb new SXSSFWorkbook(1000);窗口大小 1000 行开启压缩wb.setCompressTempFiles(true)导出完成后显式调用wb.dispose()清理临时文件更彻底方案改用EasyExcel其write()方法底层用SAX解析内存占用降低 70%。4.2 现象促销活动开始后商品详情页响应时间从 200ms 涨到 8sDB CPU 100%原因商品详情页 SQL 查询JOIN了 5 张表分类、品牌、规格、参数、评论统计且未对product_id建联合索引MySQL 优化器选错执行计划走了全表扫描。解决用EXPLAIN FORMATJSON分析执行计划确认typeALL删除冗余LEFT JOIN将评论统计等非核心数据改为异步 RPC 调用对高频查询字段建覆盖索引ALTER TABLE t_product ADD INDEX idx_shop_status_cid (shop_id, status, category_id)加Select(/* USE_INDEX(t_product idx_shop_status_cid) */ SELECT ...)强制走索引。4.3 现象用户修改收货地址后历史订单仍显示旧地址但数据库里地址已更新原因订单表t_order的receiver_address字段未冗余存储而是关联t_user_address当用户修改地址时历史订单的外键指向被更新的地址记录导致「一改全改」。解决订单创建时将收货人姓名、电话、详细地址快照式冗余到t_order表字段命名为snapshot_receiver_name、snapshot_receiver_phone、snapshot_receiver_detailt_user_address表仅用于管理当前有效地址不参与订单展示逻辑冗余字段加注释// 订单创建时刻的地址快照不可更新。4.4 现象定时任务每天凌晨 2 点同步库存但总有一部分商品同步失败日志显示Connection reset原因第三方 ERP 接口限流策略为「每分钟 100 次」但我们的 Quartz 任务配置了Scheduled(cron 0 0/1 * * * ?)每分钟触发一次每次批量同步 200 个 SKU超出限流阈值被断连。解决改用ThreadPoolTaskSchedulerRateLimiter控制 QPSprivate final RateLimiter rateLimiter RateLimiter.create(1.6); // 100/60 ≈ 1.67 QPS public void syncStockBatch(ListLong skuIds) { for (Long skuId : skuIds) { rateLimiter.acquire(); // 阻塞等待令牌 callErpApi(skuId); } }同步失败时记录t_stock_sync_log表含sku_id、error_msg、retry_count失败后自动重试 3 次间隔指数退避1s, 3s, 9s。4.5 现象新员工入职后分配角色但登录后台看不到任何菜单sys_user_role表里明明有记录原因菜单权限是「前端路由 后端接口」双校验但前端 Vue Router 的meta.roles数组与后端sys_role_permission表中的permission_code不一致——前端写的是[order:list, product:edit]后端存的是[ORDER_LIST, PRODUCT_EDIT]大小写下划线不匹配。解决统一约定后端sys_permission.code全大写下划线ORDER_LIST前端路由meta.roles也全大写下划线登录成功后后端返回ListString角色权限码前端用includes()判断加一道校验启动时扫描所有PreAuthorize(hasAuthority(ORDER_LIST))注解对比数据库中是否存在对应permission_code不存在则抛IllegalStateException阻断启动。5. 日志链路与异步任务可观测性用 MDC Logback 自定义 TaskRunner 把黑匣子打开电商后台里80% 的线上问题发生在异步场景订单超时关单、库存释放、消息推送、报表生成。这些任务一旦失败没有堆栈、没有上下文、没有 traceId就像掉进黑洞。我们不用 SkyWalking 或 Pinpoint太重而用Logback MDC 自定义线程池 任务元数据埋点三件套把每个异步任务变成可追踪、可重试、可监控的确定性单元。5.1 MDC 全链路透传从 HTTP 请求到线程池traceId 不丢Spring Boot 默认不传递 MDC 上下文到线程池导致异步任务日志里traceId为空。我们重写ThreadPoolTaskExecutorConfiguration public class AsyncConfig { Bean(taskExecutor) public ThreadPoolTaskExecutor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(20); executor.setQueueCapacity(100); executor.setThreadNamePrefix(async-task-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.setTaskDecorator(runnable - { // 拷贝当前线程的 MDC 上下文 MapString, String contextMap MDC.getCopyOfContextMap(); return () - { if (contextMap ! null) { MDC.setContextMap(contextMap); } try { runnable.run(); } finally { MDC.clear(); } }; }); executor.initialize(); return executor; } }同时在 WebMvcConfigurer 中注入 traceIdComponent public class TraceIdInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String traceId Optional.ofNullable(request.getHeader(X-Trace-ID)) .orElse(UUID.randomUUID().toString().replace(-, )); MDC.put(traceId, traceId); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { MDC.clear(); } }效果所有日志自动带上traceId例如[2024-06-15 14:22:33.123] [async-task-1] [INFO] c.e.s.o.OrderTimeoutService - traceIdabc123def456 订单 202406150001 超时关单完成5.2 自定义异步任务基类TaskRunner封装重试、超时、失败回调不直接用Async而定义抽象基类TaskRunnerTpublic abstract class TaskRunnerT implements Runnable { protected final Logger log LoggerFactory.getLogger(getClass()); protected final String taskId; protected final long timeoutMs 300_000L; // 默认 5 分钟超时 public TaskRunner(String taskId) { this.taskId taskId; } Override public void run() { try { // 1. 设置 MDC MDC.put(taskId, taskId); MDC.put(taskType, getClass().getSimpleName()); // 2. 执行核心逻辑 T result doRun(); // 3. 记录成功日志 log.info(task success, taskId{}, result{}, taskId, result); } catch (Exception e) { // 4. 记录失败日志 发送告警 log.error(task failed, taskId{}, taskId, e); onFail(e); // 5. 自动重试最多 2 次间隔 1s if (getRetryCount() 2) { try { Thread.sleep(1000); getTaskExecutor().execute(this); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } } finally { MDC.clear(); } } protected abstract T doRun(); protected abstract void onFail(Exception e); protected abstract int getRetryCount(); protected abstract Executor getTaskExecutor(); }使用示例订单超时关单Service public class OrderTimeoutRunner extends TaskRunnerVoid { Autowired private OrderService orderService; public OrderTimeoutRunner(String orderId) { super(ORDER_TIMEOUT_ orderId); } Override protected Void doRun() { orderService.closeOrderIfTimeout(getOrderId()); return null; } Override protected void onFail(Exception e) { // 发送企业微信告警 wechatAlert.send(订单超时关单失败 getOrderId(), e.getMessage()); } Override protected int getRetryCount() { return 2; } Override protected Executor getTaskExecutor() { return taskExecutor; // 注入的 ThreadPoolTaskExecutor } private String getOrderId() { return taskId.replace(ORDER_TIMEOUT_, ); } }5.3 任务元数据表t_async_task让运维看得见、管得住光有日志不够还要有状态机。建表记录每个任务生命周期字段类型说明idBIGINT PK主键task_idVARCHAR(64) NOT NULL任务唯一 ID如 ORDER_TIMEOUT_202406150001task_typeVARCHAR(32) NOT NULL任务类型ORDER_TIMEOUT / STOCK_RELEASE / REPORT_GENstatusTINYINT NOT NULL0待执行1执行中2成功3失败4已重试params_jsonTEXTJSON 参数脱敏后如{orderId:202406150001}start_timeDATETIME开始时间end_timeDATETIME结束时间retry_countINT DEFAULT 0已重试次数error_msgVARCHAR(500)失败时的简要错误信息关键动作任务run()开始时插入status0记录doRun()执行前更新status1成功后更新status2end_time失败后更新status3error_msgretry_count提供后台页面按task_type、status、time range查询支持手动重试UPDATE ... SET status0 WHERE id?。注意t_async_task表必须加task_id唯一索引防止同一任务被重复提交每日凌晨用事件驱动清理 30 天前的成功记录DELETE FROM t_async_task WHERE status 2 AND end_time DATE_SUB(NOW(), INTERVAL 30 DAY)。6. 行级权限的终极验证法用「数据污染测试」代替人工抽查权限模块上线前最怕的不是功能没写完而是「以为控制住了其实没生效」。菜单隐藏了但用户直接拼 URL 还能访问字段脱敏了但导出 Excel 里又露出来A 店铺的运营能看到 B 店铺的订单。靠人工点一遍所有按钮、查一遍所有接口效率低、覆盖率差、易遗漏。我用了一套叫「数据污染测试」Data Pollution Test的方法10 分钟内验证全部行级权限是否真正生效。6.1 构建污染数据集在测试库插入跨租户、跨角色、跨状态的「脏数据」不依赖真实业务数据而是主动构造 4 类污染数据污染类型插入示例 SQL验证目标跨店铺数据INSERT INTO t_order (order_no, shop_id, user_id, status) VALUES (TEST_A_001, 1001, 2001, WAIT_PAY); INSERT INTO t_order (order_no, shop_id, user_id, status) VALUES (TEST_B_001, 1002, 2001, WAIT_PAY);用户 2001 只属于店铺 1001应看不到shop_id1002的订单跨角色数据INSERT INTO t_product (product_id, shop_id, status) VALUES (9999, 1001, DRAFT);运营角色只能查statusON_SALE不应看到DRAFT状态商品跨时间数据INSERT INTO t_order (order_no, shop_id, created_at) VALUES (TEST_OLD, 1001, 2020-01-01);查询默认只查近 30 天应过滤掉created_at NOW()-30d的记录脱敏字段明文INSERT INTO t_user (mobile, real_name) VALUES (13800138000, 张三丰);接口返回时mobile应为138****8000导出 Excel 也应脱敏提示污染数据用固定前缀如TEST_便于清理所有插入语句放在src/test/resources/data-pollution.sql测试前自动执行。6.2 自动化验证脚本用 JUnit RestAssured 跑 20 个断言写一个PermissionIntegrationTest遍历所有受控接口Test public void testOrderListByShopScope() { // 场景用户 2001店铺 1001调用 /api/order/list given() .header(X-User-ID, 2001) .header(X-Auth-Token, getToken(2001)) .when() .get(/api/order/list?statusWAIT_PAY) .then() .statusCode(200) .body(data.size(), equalTo(1)) // 只返回 TEST_A_001不返回 TEST_B_001 .body(data.find{it.orderNo TEST_A_001}.shopId, equalTo(1001)) .body(data.find{it.orderNo TEST_B_001}, nullValue()); // 确认不存在 } Test public void testProductExportWithMasking() { // 场景导出商品列表 Excel检查手机号是否脱敏 Response response given() .header(X-User-ID, 2001) .header(X-Auth-Token, getToken(2001)) .when() .get(/api/product/export); // 解析 Excel 流 Workbook workbook WorkbookFactory.create(response.asInputStream()); Sheet sheet workbook.getSheetAt(0); Row headerRow sheet.getRow(0); int mobileColIndex findColumnIndex(headerRow, 手机号); for (int i 1; i sheet.getLastRowNum(); i) { Cell cell sheet.getRow(i).getCell(mobileColIndex); String mobile cell.getStringCellValue(); // 断言所有手机号都是 11 位且中间 4 位为 **** assertThat(mobile, matchesPattern(^1[3-9]\\d{2}\\*{4}\\d{4}$)); } }6.3 权限漏洞热力图用日志聚合定位「裸奔接口」即使自动化测试全绿也不能保证 100% 安全。我们用 ELKElasticsearch Logstash Kibana做日志聚合构建「权限漏洞热力图」Logstash 过滤所有DEBUG级别日志提取traceId、uri、userId、statusKibana 创建可视化横轴uri纵轴count()颜色深浅代表该接口被多少不同userId访问重点排查uri为/api/order/detail/{id}但count(userId) 100说明很多人在查别人订单uri为/api/product/update但status200且userId不在sys_user_shop表中越权修改uri为/api/user/export但日志中mobile字段未被****替换脱敏失效。这套方法上线后我们发现两个严重漏洞/api/order/refund接口漏了PreAuthorize任何用户都能申请退款/api/report/sales导出接口未走BaseMapper.selectWithPermission()返回了全量数据。修复后再跑污染测试 日志热力图确认漏洞消失。这三年我坚持在每个新权限模块上线前跑一遍污染测试不是为了证明代码没问题而是为了证明「如果出问题我能第一时间发现」。权限不是写完就完事的功能而是需要持续验证的生命体。希望帮到你。本文还有配套的精品资源点击获取