做畢設或練手項目選“在線交易平臺”這套命題幾乎是繞不開的。原因很簡單電商類系統(tǒng)覆蓋面廣從前臺購物車到后臺訂單管理能完整串起 Java Web 開發(fā)的主線知識非常適合作為 Spring Boot 實戰(zhàn)項目的切入點?！盎?Spring Boot 的寵物用品交易平臺”是這個分類里做得比較細、也不容易跟別人完全撞車的題目。這篇文章我把這個項目的完整思路、技術(shù)選型、數(shù)據(jù)庫設計、核心流程實現(xiàn)和踩坑記錄都整理出來希望能幫正在做類似項目或準備自己從零寫一套系統(tǒng)的同學省下不少彎路。這個項目解決的是寵物用品線上購買場景中的完整交易閉環(huán)核心包含用戶端和管理端兩大部分。用戶端有注冊登錄、商品瀏覽、分類篩選、購物車、下單支付模擬、訂單管理和收貨地址管理管理端則是商品管理、分類管理、訂單處理、用戶管理和基礎數(shù)據(jù)統(tǒng)計。整套系統(tǒng)不僅適合畢業(yè)設計展示也特別適合想通過一個完整項目把 Spring Boot 前后端知識串起來的人。簡單說做完這個項目你對 SSM 框架整合、RESTful API 設計、關(guān)系型數(shù)據(jù)庫建模、攔截器鑒權(quán)、文件上傳這些核心技能都會有比較扎實的體感。1. 項目整體設計與功能拆解1.1 需求定位與角色權(quán)限設計寵物用品交易平臺這個題目如果你去看網(wǎng)上現(xiàn)成的成品會發(fā)現(xiàn)很多版本做得非常單薄有的只有一個商品列表加一個“購買”按鈕點了之后什么反饋都沒有有的是把所有管理功能堆到一個頁面里用戶和管理員完全不分權(quán)。這些做法應付中期檢查都勉強更別說真正上線或者進答辯被問到業(yè)務細節(jié)。我做這個項目時第一件事就是把角色權(quán)限作為整個系統(tǒng)的基礎框架來設計。系統(tǒng)分兩種角色普通用戶和管理員。用戶端通過 JWTJSON Web Token做無狀態(tài)鑒權(quán)管理員接口再單獨加一層攔截校驗。這樣做的直接好處是前后端分離時不用每次請求都傳 session ID移動端如果以后要接入小程序這類場景JWT 也能直接復用。管理員權(quán)限校驗我用的是 Spring Boot 攔截器寫一個AdminInterceptor類實現(xiàn)HandlerInterceptor接口在preHandle里判斷請求頭中的 token解析出用戶角色后再決定放行還是攔截。整個系統(tǒng)的功能模塊劃分我建議按照用戶端和管理端兩條線來梳理用戶端注冊、登錄、退出登錄個人信息查看修改首頁輪播圖、商品分類導航、商品推薦列表商品列表支持關(guān)鍵詞搜索、分類篩選、價格排序、分頁展示商品詳情頁展示多張商品圖片、庫存、銷量、詳情描述購物車加入、修改數(shù)量、刪除、批量勾選結(jié)算訂單提交訂單、在線支付模擬、取消、確認收貨收貨地址新增、編輯、刪除、設置默認地址個人中心我的訂單、我的收藏、瀏覽記錄管理端管理員登錄鑒權(quán)獨立于用戶端商品管理新增、上下架、修改庫存和價格、編輯商品圖片分類管理商品分類的增刪改查訂單管理訂單列表、訂單詳情、發(fā)貨操作、訂單統(tǒng)計用戶管理查看用戶列表、禁用/啟用用戶賬號數(shù)據(jù)看板銷售額統(tǒng)計、訂單量統(tǒng)計、熱銷商品 Top N1.2 技術(shù)選型背后的取舍邏輯這個項目我用的是 Spring Boot 2.7.x MyBatis-Plus 3.5.x MySQL 8.0 這套組合。如果你用的是 Java 8 或 11Spring Boot 2.7 仍然是兼容性和穩(wěn)定性最穩(wěn)妥的版本不建議一上來就追 Spring Boot 3因為 Spring Boot 3 強制要求 Java 17且部分第三方中間件的適配還容易踩坑。注意如果你的學?；蚬经h(huán)境強制要求 JDK 8Spring Boot 2.7.x 是最后一代完整兼容 JDK 8 的大版本分支這個信息在選型時很關(guān)鍵。MyBatis-Plus 在這個項目里是真正的效率神器。它內(nèi)置了BaseMapper單表 CRUD 基本不需要手寫 SQL注意是“基本”多表關(guān)聯(lián)查詢和復雜統(tǒng)計還是要自己寫 XML。我用它的分頁插件PaginationInnerInterceptor非常順手配置十幾行代碼就能實現(xiàn)標準的分頁查詢避免了原生 MyBatis 寫 PageHelper 依賴時的版本沖突問題。前端我選的方案是 Thymeleaf Bootstrap 5 jQuery沒上前后端完全分離的 Vue 腳手架。原因很實際團隊只有一個人既要寫后端又要寫頁面如果還要維護 Nginx 靜態(tài)資源分離和前端構(gòu)建流程工作量會翻倍。服務端渲染模式下頁面直接通過 ModelAndView 渲染HTML 里用th:each循環(huán)商品列表對演示和答辯來說已經(jīng)足夠完整。更重要的是Thymeleaf 的語法風格跟原生 HTML 非常接近后續(xù)想遷移到 Vue 時后端接口只要保證返回 JSON 格式就行改動成本也不至于傷筋動骨。2. 核心細節(jié)解析與實操要點2.1 數(shù)據(jù)庫表結(jié)構(gòu)設計不是堆字段是理清關(guān)系數(shù)據(jù)庫設計是這個項目最值得花時間的環(huán)節(jié)。它決定了后面所有業(yè)務邏輯的復雜度上限設計得當代碼寫起來會非常順手。寵物用品交易平臺我設計了 8 張核心表下面這張表給你做個索引對照表名中文含義核心字段關(guān)聯(lián)關(guān)系user用戶表id, username, password, nickname, avatar, phone, role與 cart、orders 一對多category商品分類表id, name, sort_order與 product 一對多product商品表id, category_id, name, subtitle, main_image, detail, price, stock, sales, status與 cart、order_item 一對多cart購物車表id, user_id, product_id, quantity, checked不落訂單表作緩存型數(shù)據(jù)orders訂單表id, order_no, user_id, total_price, payment_type, status, receiver_name, receiver_phone, receiver_address與 order_item 一對多order_item訂單明細表id, order_id, product_id, product_name, product_image, current_price, quantity多對一關(guān)聯(lián) ordersaddress收貨地址表id, user_id, receiver_name, receiver_phone, province, city, district, detail, is_default與 user 多對一banner輪播圖表id, image_url, link_url, sort_order, status獨立配置表有幾個設計細節(jié)我說一下都是我實際開發(fā)中被坑過之后改出來的第一訂單表和訂單明細表必須分開設計。剛開始圖省事把商品快照直接存在訂單表里的 JSON 字段里后來發(fā)現(xiàn)一旦要統(tǒng)計“哪個商品賣得最好”就得去解析 JSON數(shù)據(jù)庫層面完全沒法做聚合查詢。拆成 order_item 表之后熱銷統(tǒng)計一條 SQL 就能解決。另外注意在訂單明細里要冗余一份product_name和product_image因為商品信息是動態(tài)的用戶下單之后商品改名或刪除了訂單里仍要保留購買當時的快照。第二密碼字段存的不是明文是 BCrypt 加密后的密文。Spring Security 里自帶的BCryptPasswordEncoder可以直接用不用為了一個密碼加密功能把整個 Spring Security 引入項目單獨拿它的編碼器工具類即可。第三庫存字段的初始化和扣減邏輯要提前約定清楚。添加商品時默認stock為 0上架前必須手動設置庫存和價格?？蹨p庫存時我用了樂觀鎖機制在 product 表增加version字段更新庫存的 SQL 里帶上WHERE version #{version}避免高并發(fā)場景下兩個訂單同時把同一件商品的庫存扣成負數(shù)。2.2 Spring Boot 項目結(jié)構(gòu)合理的分層是后期維護的救命稻草很多同學做項目時喜歡把所有的 Controller、Service 全部塞到幾個包里表面看文件很少但功能一多根本沒法維護。我自己比較推薦的分層結(jié)構(gòu)是com.pet.mall ├── controller // 接口層只做參數(shù)接收和響應包裝 ├── service // 業(yè)務層處理核心邏輯 │ └── impl ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 數(shù)據(jù)庫實體類 ├── dto // 數(shù)據(jù)傳輸對象請求參數(shù) ├── vo // 視圖對象響應數(shù)據(jù) ├── config // 配置類跨域、攔截器、分頁插件 ├── common // 通用類統(tǒng)一返回結(jié)果、異常處理、常量 ├── util // 工具類JWT、文件上傳 └── interceptor // 登錄鑒權(quán)攔截器注意區(qū)分 DTO 和 VO 的概念這是很少有人在畢設里講清楚但答辯時很可能被問到的點。DTO 是接收前端傳來的參數(shù)比如注冊時只需要username、password、nickname不需要把整個User實體作為入?yún)O 是返回給前端的數(shù)據(jù)比如訂單詳情里需要包含商品明細列表和訂單狀態(tài)描述而這些字段在實體類中可能并不直接存在。統(tǒng)一返回結(jié)果類我也強烈建議寫這是公司里非常基礎的一項規(guī)范。我用的是一個泛型類ResultT包含code、message、data三個字段。成功時 code 為 200失敗時 code 為 500 或自定義業(yè)務碼配合全局異常處理器RestControllerAdvice代碼里就基本不用在每個 Controller 里重復寫 try-catch 了。2.3 關(guān)鍵配置文件與依賴清單pom.xml里核心依賴我整理了一份參考清單dependencies !-- Web 啟動器 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- Thymeleaf 模板引擎 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-thymeleaf/artifactId /dependency !-- MyBatis-Plus Spring Boot 3.x 使用不同的 starter -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- MySQL 驅(qū)動 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency !-- Lombok 簡化實體類 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency !-- JWT 工具 -- dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency !-- Hutool 工具包生成隨機訂單號、日期工具等 -- dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.20/version /dependency /dependenciesapplication.yml的關(guān)鍵配置如下數(shù)據(jù)庫連接池我直接用的 HikariCPSpring Boot 默認server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/pet_mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword hikari: maximum-pool-size: 10 minimum-idle: 5 thymeleaf: cache: false suffix: .html prefix: classpath:/templates/ mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: id-type: auto logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0提示map-underscore-to-camel-case一定要打開否則數(shù)據(jù)庫字段user_id無法自動映射到實體類的userId屬性會讓你在排查問題時懷疑人生。3. 實操過程與核心環(huán)節(jié)實現(xiàn)3.1 商品模塊從數(shù)據(jù)庫到頁面渲染的完整鏈路商品模塊是整個項目最先需要跑通的模塊因為后面購物車、訂單全都要依托商品數(shù)據(jù)。實現(xiàn)一個商品列表接口為例從前端請求到數(shù)據(jù)庫查詢的完整鏈路是瀏覽器訪問/product/list?pageNum1pageSize8categoryId3keyword貓糧請求首先被 Spring MVC 的DispatcherServlet接收根據(jù)RequestMapping(/product/list)映射到ProductController的list方法。Controller 層把參數(shù)封裝成ProductQueryDTO調(diào)用 Service 層的queryProductPage()方法Service 里通過 MyBatis-Plus 的LambdaQueryWrapper構(gòu)造查詢條件分頁插件自動執(zhí)行 count 和 limit 兩條 SQL最終返回一個PageInfo對象給前端 Thymeleaf 渲染。關(guān)鍵代碼如下這段代碼我實測過很多次直接抄就能用Override public PageResultProductVO queryProductPage(ProductQueryDTO dto) { PageProduct page new Page(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); // 關(guān)鍵詞搜索 if (StrUtil.isNotBlank(dto.getKeyword())) { wrapper.and(w - w.like(Product::getName, dto.getKeyword()) .or() .like(Product::getSubtitle, dto.getKeyword())); } // 分類篩選 if (dto.getCategoryId() ! null) { wrapper.eq(Product::getCategoryId, dto.getCategoryId()); } // 只查詢上架商品 wrapper.eq(Product::getStatus, 1); // 排序按銷量、價格、新品 if (sales.equals(dto.getSort())) { wrapper.orderByDesc(Product::getSales); } else if (priceAsc.equals(dto.getSort())) { wrapper.orderByAsc(Product::getPrice); } else if (priceDesc.equals(dto.getSort())) { wrapper.orderByDesc(Product::getPrice); } else { wrapper.orderByDesc(Product::getCreateTime); } productMapper.selectPage(page, wrapper); PageResultProductVO result new PageResult(); result.setPageNum(page.getCurrent()); result.setPageSize(page.getSize()); result.setTotal(page.getTotal()); result.setList(BeanUtil.copyToList(page.getRecords(), ProductVO.class)); return result; }這里有個容易被忽略的細節(jié)搜索條件中的keyword用了StrUtil.isNotBlank()判斷而不是直接判斷! null因為前端如果傳一個空字符串過來like條件仍然會拼進 SQL雖然結(jié)果集一樣但會多一次無效查詢。3.2 購物車與訂單流程事務邊界到底畫在哪里購物車和訂單流程是電商系統(tǒng)的核心鏈路也是答辯時最容易追問細節(jié)的地方。很多初學者的代碼在提交訂單時會出現(xiàn)嚴重問題訂單主表插入成功了但訂單明細和庫存扣減失敗了導致數(shù)據(jù)不一致。這個問題的根本原因是事務邊界沒有控制好。Spring 的Transactional注解默認只對運行時異常RuntimeException回滾對受檢異常如IOException不會回滾。如果代碼里 catch 住了異常但沒有重新拋出即使加了注解也無法觸發(fā)回滾。我實現(xiàn)的提交訂單邏輯是這樣的Transactional(rollbackFor Exception.class) Override public OrderVO submitOrder(OrderCreateDTO dto) { // 1. 參數(shù)校驗地址不能為空購物車商品不能為空 Address address addressMapper.selectById(dto.getAddressId()); Assert.notNull(address, 收貨地址不存在); // 2. 計算訂單總價校驗庫存 ListCartVO cartList cartMapper.selectCartWithProduct(dto.getUserId()); BigDecimal totalPrice BigDecimal.ZERO; for (CartVO cart : cartList) { if (cart.getStock() cart.getQuantity()) { throw new BusinessException(500, 商品【 cart.getProductName() 】庫存不足); } totalPrice totalPrice.add(cart.getCurrentPrice().multiply(new BigDecimal(cart.getQuantity()))); } // 3. 生成訂單號保存訂單主表 String orderNo PM System.currentTimeMillis() RandomUtil.randomNumbers(4); Orders order new Orders(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setTotalPrice(totalPrice); order.setStatus(0); // 0-待支付 1-已支付 2-已發(fā)貨 3-已完成 4-已取消 order.setReceiverName(address.getReceiverName()); order.setReceiverPhone(address.getReceiverPhone()); order.setReceiverAddress(address.getProvince() address.getCity() address.getDistrict() address.getDetail()); ordersMapper.insert(order); // 4. 批量保存訂單明細同時扣減庫存 for (CartVO cart : cartList) { OrderItem item new OrderItem(); item.setOrderId(order.getId()); item.setProductId(cart.getProductId()); item.setProductName(cart.getProductName()); item.setProductImage(cart.getProductImage()); item.setCurrentPrice(cart.getCurrentPrice()); item.setQuantity(cart.getQuantity()); orderItemMapper.insert(item); int rows productMapper.deductStock(cart.getProductId(), cart.getQuantity()); if (rows 0) { throw new BusinessException(500, 商品【 cart.getProductName() 】庫存扣減失敗); } } // 5. 清空用戶購物車中已結(jié)算的商品 cartMapper.deleteByUserIdAndProductIds(dto.getUserId(), cartList.stream().map(CartVO::getProductId).collect(Collectors.toList())); return orderToVO(order); }整套流程我用了Transactional(rollbackFor Exception.class)確保任何一步失敗前面插入的訂單主表、明細表、庫存扣減全部回滾。這里最關(guān)鍵的 SQL 是庫存扣減語句必須使用帶條件的更新而不是先查再更新UPDATE product SET stock stock - #{quantity}, version version 1 WHERE id #{productId} AND stock #{quantity} AND version #{version}這個寫法把“庫存檢查”和“庫存扣減”合并成一條原子 SQL避免了兩步操作之間可能出現(xiàn)的并發(fā)問題。3.3 文件上傳與圖片訪問策略商品圖片上傳是管理端必須的功能。我這里提供兩種方案看你的部署環(huán)境怎么選擇。方案一本地存儲在項目根目錄下的upload/images文件夾通過配置靜態(tài)資源映射來訪問。優(yōu)點是部署簡單方式是自定義一個WebMvcConfigurer來添加資源映射Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) /upload/; registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }PostMapping(/admin/product/upload) public ResultString uploadImage(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(請選擇文件); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); if (!Arrays.asList(.jpg, .jpeg, .png, .gif).contains(ext.toLowerCase())) { return Result.error(圖片格式不支持); } String fileName System.currentTimeMillis() RandomUtil.randomNumbers(6) ext; String datePath DateUtil.format(new Date(), yyyyMMdd); File destDir new File(uploadPath datePath); if (!destDir.exists()) { destDir.mkdirs(); } file.transferTo(new File(destDir, fileName)); String url /upload/ datePath / fileName; return Result.success(url); }方案二把圖片上傳到某云存儲服務商的對象存儲桶里返回公網(wǎng)可訪問的 URL。這是生產(chǎn)環(huán)境的標準做法但需要你在云服務商控制臺創(chuàng)建一個 Bucket 并開通權(quán)限配置更麻煩一些。對于畢設和本地演示方案一足夠用了只要注意在上傳時做格式大小校驗避免把可執(zhí)行文件偽裝成圖片傳上來。3.4 JWT 登錄鑒權(quán)與攔截器配置用戶登錄成功后后端返回一個 JWT 令牌前端在后續(xù)請求時通過Authorization: Bearer token頭發(fā)送。JWT 的核心結(jié)構(gòu)是 Header.Payload.Signature 三段式我用的生成方式如下public String generateToken(User user) { Date now new Date(); Date expireAt new Date(now.getTime() 7 * 24 * 60 * 60 * 1000); // 7天有效期 return Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setIssuedAt(now) .setExpiration(expireAt) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }攔截器里做的事很簡單從請求頭里取 token解析成功且未過期把 userId 和 role 存到ThreadLocal或HttpServletRequest的 attribute 中供后續(xù) Controller 使用。這里我推薦用HandlerInterceptor而不是Filter因為攔截器能拿到 Spring 管理和容器對象比如直接注入 JWT 工具類而 Filter 在 Bean 獲取上會麻煩一些。不過這段攔截期間有個細節(jié)需要注意放行l(wèi)ogin、register、/product/**靜態(tài)資源等需要匿名訪問的路徑其他一律經(jīng)過校驗。Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行跨域預檢請求 if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (StrUtil.isBlank(token) || !token.startsWith(Bearer )) { throw new BusinessException(401, 用戶未登錄); } try { Claims claims JwtUtil.parseToken(token.substring(7)); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { throw new BusinessException(401, 登錄狀態(tài)已過期請重新登錄); } }4. 常見問題與排查技巧實錄4.1 數(shù)據(jù)庫中文亂碼和時區(qū)問題這是新手上路遇到的第一道坎?，F(xiàn)象是插入中文數(shù)據(jù)后查出來變成問號或者控制臺報The server time zone value ?D1ú±ê×?ê±?? is unrecognized的錯。歸根結(jié)底是連接串里沒有顯式指定編碼和時區(qū)。解決方式很直接數(shù)據(jù)庫連接 URL 加上三個參數(shù)就行jdbc:mysql://localhost:3306/pet_mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai這里缺characterEncodingutf8中文會亂碼缺serverTimezone會報時區(qū)異常兩個必須同時配置。另一個容易踩的地方是 MySQL 建庫時的默認字符集如果建庫語句里沒指定 UTF8MB4Windows 上默認會是 latin1這個和連接串無關(guān)要在 CREATE DATABASE 語句里顯式指定CREATE DATABASE IF NOT EXISTS pet_mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;4.2 MyBatis-Plus 實體映射導致的空指針項目里最常見的報錯之一就是查庫能查到數(shù)據(jù)但實體對象某些字段為 null后續(xù)代碼一用到就報空指針。排查思路分三步先看數(shù)據(jù)庫字段名和實體屬性名是否對應再確認map-underscore-to-camel-case是否打開最后看實體類有沒有加TableName和TableId注解。MyBatis-Plus 的實體類默認認為數(shù)據(jù)庫主鍵叫id如果主鍵字段叫user_id必須加TableId(user_id)注解否則插入和更新會把主鍵當作普通字段處理導致 SQL 執(zhí)行失敗。這段經(jīng)驗來自我實際調(diào)試的真實場景當時 Orders 表主鍵是order_id實體類里對應字段寫的orderId怎么查都查不到數(shù)據(jù)日志里打印的 SQL 是這樣的SELECT ... FROM orders WHERE id ?完全不是想要的語義。4.3 跨域請求被攔截如果是服務端渲染的模式跨域問題一般不明顯。一旦你前端頁面單獨啟動在另一個端口比如 Vue 開發(fā)服務器運行在 5173Spring Boot 跑在 8080跨域請求就會被瀏覽器的同源策略攔截。解決方法是寫一個全局跨域配置Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }這串配置允許所有來源、方法和請求頭跨域訪問但當allowCredentials(true)時不能允許具體的 origin 為*必須使用addAllowedOriginPattern才能配合 credentials 正常工作。這是瀏覽器規(guī)范的限制別在這里浪費太多時間。4.4 訂單號并發(fā)重復自己實現(xiàn)電商系統(tǒng)不要用時間戳 隨機數(shù)直接拼訂單號并發(fā)高一點就會重復。我一開始用System.currentTimeMillis()加四位隨機數(shù)測試時連續(xù)快速下兩個訂單就撞號了。推薦幾種增強方案用數(shù)據(jù)庫的自增 ID 作為訂單號的一部分但這個暴露了業(yè)務量數(shù)據(jù)不適合外發(fā)給用戶用 Hutool 的IdUtil.getSnowflakeNextIdStr()生成雪花算法 ID按時間有序、全局唯一這是通用做法更保險的是在數(shù)據(jù)庫訂單表給order_no加唯一索引即使上層并發(fā)導致生成的訂單號重復數(shù)據(jù)庫也能兜底拒絕重復插入4.5 部署與演示常見問題速查問題現(xiàn)象可能原因解決方案啟動直接失敗端口被占用8080 被其他進程占用netstat -ano查出 PID結(jié)束進程或改server.port頁面能打開但樣式丟失Thymeleaf 緩存未關(guān)閉資源路徑引用錯spring.thymeleaf.cachefalse檢查th:href{/css/style.css}商品圖片 404上傳目錄和靜態(tài)資源映射不一致檢查upload目錄是否存在映射路徑是否包含日期子目錄項目打包后啟動報找不到主類打包配置有問題確認spring-boot-maven-plugin的mainClass配置正確頁面顯示模板解析錯誤HTML 文件所在目錄不對Thymeleaf 默認找templates/目錄下的.html子目錄要寫完整相對路徑5. 從這份項目里能拿走的東西做完這個項目最大的體會是“電商系統(tǒng)雖然看似到處都是 CRUD但核心難點其實集中在事務、并發(fā)和狀態(tài)流轉(zhuǎn)三件事上”。我實際開發(fā)時為了演示順暢給訂單狀態(tài)定義了一套完整的狀態(tài)流轉(zhuǎn)待支付、已支付、已發(fā)貨、已完成、已取消。每個狀態(tài)之間的合法跳轉(zhuǎn)我在 Service 層都做了校驗比如已取消的訂單不能發(fā)貨已完成的訂單不能取消。這個設計在答辯時被問到“系統(tǒng)如何處理異常訂單”的時候回答起來非常加分。文檔和視頻資料的整理也是這個項目容易被低估的環(huán)節(jié)。運行視頻錄一遍完整的操作流程代碼講解視頻分段錄制每段控制在 5 分鐘以內(nèi)重點講一個功能點的實現(xiàn)思路。寫文檔時把表結(jié)構(gòu)、接口清單和部署步驟分開寫明尤其是數(shù)據(jù)庫初始化腳本一定要在全新的 MySQL 實例上測試過一遍。這些看起來瑣碎但后期復盤或者給別人展示項目時價值不比代碼本身低。最后再分享一個小技巧項目里放一個README.md把啟動命令、數(shù)據(jù)庫初始化方式、默認管理員賬號密碼都寫清楚。以后無論時隔多久回看這個項目或者直接把項目交給任何人運行都能在五分鐘內(nèi)跑起來。這個習慣會為你省下大量不必要的時間損耗。