設(shè)計(jì)與實(shí)現(xiàn)：訂單狀態(tài)與權(quán)限實(shí)戰(zhàn))
簡(jiǎn)介完整的洗衣店管理系統(tǒng)畢業(yè)設(shè)計(jì)論文面向Java Web開(kāi)發(fā)學(xué)習(xí)者、高校計(jì)算機(jī)相關(guān)專業(yè)學(xué)生以及需要快速上手B/S結(jié)構(gòu)項(xiàng)目的開(kāi)發(fā)者。文檔基于B/S架構(gòu)采用JSP、Java與MySQL數(shù)據(jù)庫(kù)進(jìn)行設(shè)計(jì)詳細(xì)闡述了用戶消費(fèi)記錄查詢、衣服清洗/修補(bǔ)/賠償管理、會(huì)員卡管理及營(yíng)業(yè)額統(tǒng)計(jì)等核心功能模塊并對(duì)系統(tǒng)安全、可擴(kuò)展性與可維護(hù)性進(jìn)行了分析。資源包僅含1個(gè)docx文檔文件大小3.11MB內(nèi)容涵蓋緒論、系統(tǒng)開(kāi)發(fā)環(huán)境、功能設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)、操作界面等完整章節(jié)并附有中英文摘要與目錄結(jié)構(gòu)。文檔中不僅給出了系統(tǒng)總體架構(gòu)和數(shù)據(jù)庫(kù)表結(jié)構(gòu)還對(duì)各模塊的JSP頁(yè)面與后臺(tái)Java邏輯交互流程進(jìn)行了說(shuō)明可以幫助讀者快速建立開(kāi)發(fā)思路直接適配課程設(shè)計(jì)或畢業(yè)設(shè)計(jì)需求。目前已有154人學(xué)習(xí)下載適合需要參考完整論文撰寫(xiě)規(guī)范與項(xiàng)目設(shè)計(jì)流程的讀者。1. 基于java洗衣店管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)先解決“衣服到哪了”一個(gè)普通洗衣店一天收一百來(lái)單每單三五件衣服。真正讓店員頭疼的不是洗不干凈而是顧客問(wèn)“我那件羽絨服好了沒(méi)”時(shí)前臺(tái)只能說(shuō)“我去看看”。干洗、水洗、熨燙、質(zhì)檢、返洗、暫存每換一個(gè)環(huán)節(jié)就經(jīng)手一個(gè)人漏記一次后面全是翻找和扯皮?；趈ava洗衣店管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)要解決的就是把“一件衣服現(xiàn)在在哪個(gè)狀態(tài)”變成可查詢的記錄再用權(quán)限、事務(wù)和報(bào)表把每個(gè)環(huán)節(jié)鎖住。這套系統(tǒng)適合兩類人一是做畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)的Java后端學(xué)習(xí)者能在訂單、鑒權(quán)、統(tǒng)計(jì)模塊里完整走一遍二是想給本地小店做輕量化改造的開(kāi)發(fā)者。洗衣單不是普通買賣單它有多件衣物明細(xì)、動(dòng)態(tài)狀態(tài)、按件計(jì)費(fèi)和會(huì)員儲(chǔ)值數(shù)據(jù)模型必須圍繞狀態(tài)流轉(zhuǎn)來(lái)設(shè)計(jì)。2. 用Spring Boot先落數(shù)據(jù)模型訂單、衣物、計(jì)費(fèi)規(guī)則怎么建表2.1 下單要同時(shí)寫(xiě)多張表實(shí)體邊界先分清洗衣店業(yè)務(wù)中最核心的實(shí)體不是“衣服”而是“洗衣訂單”。一個(gè)訂單包含多件衣物每件衣物有獨(dú)立的洗護(hù)方式、價(jià)格和狀態(tài)因此需要拆成訂單主表、訂單明細(xì)表和狀態(tài)流轉(zhuǎn)記錄表。常見(jiàn)的做法是客戶表算一方訂單表算一方明細(xì)表記錄多方衣物。狀態(tài)流轉(zhuǎn)單獨(dú)建表是因?yàn)橄匆鹿べ|(zhì)檢不過(guò)、顧客要求返洗這類事件后續(xù)要用來(lái)算返洗率和績(jī)效。以下是我常用的建表結(jié)構(gòu)數(shù)據(jù)庫(kù)用MySQL 8字符集統(tǒng)一utf8mb4。CREATE TABLE laundry_order ( order_id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 訂單ID, order_no VARCHAR(24) NOT NULL COMMENT 訂單號(hào)前臺(tái)展示用, customer_id BIGINT NOT NULL COMMENT 客戶ID, store_id BIGINT NOT NULL COMMENT 門店ID, order_status VARCHAR(20) NOT NULL DEFAULT CREATED COMMENT 訂單狀態(tài), total_amount DECIMAL(10,2) NOT NULL COMMENT 原價(jià)總額, discount_amount DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 折扣金額, payable_amount DECIMAL(10,2) NOT NULL COMMENT 應(yīng)付金額, created_at DATETIME NOT NULL COMMENT 創(chuàng)建時(shí)間, updated_at DATETIME NOT NULL COMMENT 最后更新時(shí)間, UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT洗衣訂單主表; CREATE TABLE order_item ( item_id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL COMMENT 所屬訂單ID, item_name VARCHAR(64) NOT NULL COMMENT 衣物名稱, wash_method VARCHAR(20) NOT NULL COMMENT 洗護(hù)方式, item_count INT NOT NULL DEFAULT 1 COMMENT 件數(shù), price_snapshot DECIMAL(10,2) NOT NULL COMMENT 下單時(shí)單價(jià), item_status VARCHAR(20) NOT NULL DEFAULT CREATED COMMENT 衣物狀態(tài), KEY idx_order_item (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT衣物明細(xì)表;訂單主表把整單金額、訂單狀態(tài)鎖在一起明細(xì)表負(fù)責(zé)單件衣物的洗護(hù)方式和狀態(tài)。注意price_snapshot記錄的是下單那一刻的單價(jià)不是每次查詢時(shí)去讀價(jià)目表。洗衣店的價(jià)目表會(huì)隨著換季、活動(dòng)調(diào)整如果明細(xì)里不保留下單價(jià)改價(jià)之后歷史賬單會(huì)全部亂掉。創(chuàng)建時(shí)間字段用 DATETIME不要用 TIMESTAMP 存儲(chǔ)避免 2038 年問(wèn)題和夏令時(shí)換算干擾Java 側(cè)用 LocalDateTime 接收。2.2 金額用DECIMAL狀態(tài)用字符串還是枚舉金額和折扣類字段必須用 DECIMAL(10,2)Java 實(shí)體里對(duì)應(yīng) BigDecimal不要用 double 或 float。洗衣店的會(huì)員折扣、返洗賠付、儲(chǔ)值抵扣經(jīng)常出現(xiàn) 0.05 這種精度要求浮點(diǎn)運(yùn)算在小數(shù)位多時(shí)會(huì)出現(xiàn)金額對(duì)不平的情況排查成本遠(yuǎn)高于建表時(shí)多寫(xiě)幾個(gè)字符。字段類型可以按下面這張表定減少后期返工。字段用途推薦類型原因金額、折扣DECIMAL(10,2)精度可控避免浮點(diǎn)誤差訂單號(hào)VARCHAR(24)需要自定義規(guī)則比如日期加流水狀態(tài)VARCHAR(20)可讀性好排查數(shù)據(jù)方便創(chuàng)建時(shí)間DATETIME避開(kāi) TIMESTAMP 的 2038 年問(wèn)題訂單狀態(tài)字段我習(xí)慣在數(shù)據(jù)庫(kù)里存字符串在 Java 代碼里用枚舉定義常量。不要用數(shù)字代表狀態(tài)否則三個(gè)月后你會(huì)面對(duì)一個(gè)“3 到底表示已取衣還是已結(jié)算”的問(wèn)題。枚舉上可以掛上中文標(biāo)簽public enum OrderStatus { CREATED(待取衣), WASHING(洗護(hù)中), QUALITY_CHECK(質(zhì)檢中), READY(可取衣), PICKED_UP(已取衣), REWASH(返洗), VOID(已作廢); private final String label; OrderStatus(String label) { this.label label; } }狀態(tài)流轉(zhuǎn)時(shí)只允許從當(dāng)前狀態(tài)遷移到指定下一狀態(tài)。這個(gè)校驗(yàn)如果散落在前端頁(yè)面遲早會(huì)被繞過(guò)。后面第 4 章會(huì)給出一個(gè)集中的狀態(tài)機(jī)服務(wù)來(lái)管這件事。2.3 持久層選MyBatis-Plus還是Spring Data JPA單體項(xiàng)目里我一般選 MyBatis-Plus原因有三個(gè)。第一多表關(guān)聯(lián)查詢可以直接寫(xiě) SQL洗衣店的營(yíng)運(yùn)報(bào)表經(jīng)常要 join 訂單、明細(xì)、支付三張表MyBatis-Plus 的 xml 或注解 SQL 肉眼可讀。第二分頁(yè)插件對(duì)“下單記錄要分頁(yè)列表”這種需求開(kāi)箱即用不需要自己拼 LIMIT。第三updateById默認(rèn)只更新非空字段做部分狀態(tài)更新比較友好不容易把其他字段覆蓋掉。如果指導(dǎo)老師要求用 Spring Data JPA也可以。但要注意關(guān)聯(lián)查詢時(shí)的 N1 問(wèn)題取衣列表經(jīng)常要查訂單明細(xì)不要在循環(huán)里逐條查數(shù)據(jù)庫(kù)。用EntityGraph或者寫(xiě)一個(gè)顯式 join 查詢一次取出明細(xì)列表回到內(nèi)存后按 orderId 分組再用視圖對(duì)象組裝數(shù)據(jù)庫(kù)只查兩次。2.4 初始化腳本用Flyway管理數(shù)據(jù)表不是一次建完就結(jié)束后面加字段、加索引是常態(tài)。用 Flyway 把這些變更納入版本管理比每個(gè)人都手動(dòng)執(zhí)行 SQL 腳本靠譜。項(xiàng)目啟動(dòng)時(shí)配置spring.flyway.enabledtrue在src/main/resources/db/migration下放 V1、V2 等腳本第一版就放上面的建表語(yǔ)句。升級(jí)的時(shí)候V2 里只寫(xiě) ALTER 語(yǔ)句比如給 order_item 加一個(gè)tag_no標(biāo)簽號(hào)字段用于店內(nèi)掃碼找衣。新環(huán)境從零初始化、老環(huán)境增量升級(jí)都走同一條路徑不會(huì)出現(xiàn)“我這能跑你那就報(bào)錯(cuò)”的情況。提示啟動(dòng)報(bào) “Flyway validate failed” 時(shí)先檢查腳本 checksum 是否被手動(dòng)改過(guò)。如果數(shù)據(jù)已經(jīng)變更用 repair 命令修復(fù)記錄不要直接刪 flyway_schema_history 表。新環(huán)境跑不起來(lái)的頭號(hào)原因不是代碼而是本機(jī) Java 環(huán)境變量配置、MySQL 版本和連接串里的時(shí)區(qū)參數(shù)。JDK 17 下連接 MySQL 8url 里加上serverTimezoneAsia/Shanghai能省掉大量時(shí)間字段錯(cuò)亂的問(wèn)題。3. 洗衣店管理系統(tǒng)的登錄鑒權(quán)三種角色怎么控制權(quán)限3.1 前臺(tái)、洗衣工、店長(zhǎng)的操作邊界先按業(yè)務(wù)把角色理清。前臺(tái)負(fù)責(zé)下單、錄入衣物、收款、取衣核銷洗衣工負(fù)責(zé)接單、上報(bào)送洗、上報(bào)完成店長(zhǎng)負(fù)責(zé)改價(jià)、返洗、退款、關(guān)賬。如果還有“加盟店老板”不要因此把權(quán)限模型復(fù)雜化在角色表里加一行即可。角色能做的操作不能做的操作前臺(tái)下單、改衣、結(jié)算、取衣退款、批量改價(jià)、關(guān)賬洗衣工接單、上報(bào)洗護(hù)完成結(jié)算、退款、作廢訂單店長(zhǎng)全部操作無(wú)權(quán)限維度不多我傾向在代碼里用 Spring Security 注解硬編碼而不是引入動(dòng)態(tài)權(quán)限表。需要重點(diǎn)保護(hù)的接口是退款只允許ROLE_MANAGER返洗需要店長(zhǎng)二次確認(rèn)已作廢訂單不能被再次修改。硬編碼的好處是代碼即文檔后端維護(hù)人員一眼能看到某個(gè)接口誰(shuí)能調(diào)。3.2 Spring Security JWT的登錄流程前端和后端分開(kāi)部署時(shí)用 JWT 比 Session 更適合省掉跨域 Session 同步。登錄接口接收手機(jī)號(hào)和密碼校驗(yàn)通過(guò)后生成 token把 userId、storeId、role 放進(jìn)去。后續(xù)請(qǐng)求經(jīng)過(guò)過(guò)濾器時(shí)從 token 里取用戶信息設(shè)置到 SecurityContext。Component public class JwtAuthFilter extends OncePerRequestFilter { private final JwtTokenUtil jwtTokenUtil; private final UserService userService; public JwtAuthFilter(JwtTokenUtil jwtTokenUtil, UserService userService) { this.jwtTokenUtil jwtTokenUtil; this.userService userService; } Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String header request.getHeader(Authorization); if (header ! null header.startsWith(Bearer )) { String token header.substring(7); String userId jwtTokenUtil.getUserId(token); if (userId ! null) { User user userService.getById(userId); UsernamePasswordAuthenticationToken auth new UsernamePasswordAuthenticationToken(user, null, user.getAuthorities()); SecurityContextHolder.getContext().setAuthentication(auth); } } chain.doFilter(request, response); } }這段過(guò)濾器的核心邏輯是從請(qǐng)求頭拿到 Authorization判斷是否以Bearer開(kāi)頭解析 token 取 userId再查庫(kù)得到用戶和角色。UsernamePasswordAuthenticationToken的第一個(gè)參數(shù)放當(dāng)前用戶對(duì)象第三個(gè)參數(shù)放角色集合中間參數(shù)是憑證JWT 模式下不需要再放密碼。有個(gè)容易踩的坑header.substring(7)的前提是字符串長(zhǎng)度一定大于 7。如果前端傳了個(gè)空 token 或格式不標(biāo)準(zhǔn)的字符串這里會(huì)直接拋異常。建議先判斷header.length() 7再截取或者把解析邏輯包在 try-catch 里解析失敗時(shí)直接放行讓后續(xù) Spring Security 的匿名用戶邏輯接手。3.3 登錄接口和權(quán)限注解登錄接口做兩件事校驗(yàn)密碼和簽發(fā) token。密碼在數(shù)據(jù)庫(kù)里存 BCrypt 哈希不要存明文。登錄成功后返回 token 和用戶角色前端把 token 存到 localStorage每次請(qǐng)求帶上即可。這里不推薦做“七天免登錄”之類的長(zhǎng)有效期 token洗衣店前臺(tái)共用瀏覽器token 有效期控制在 12 小時(shí)以內(nèi)比較穩(wěn)妥。RestController RequestMapping(/api/auth) public class AuthController { private final AuthService authService; public AuthController(AuthService authService) { this.authService authService; } PostMapping(/login) public ResultLoginVO login(RequestBody LoginDTO dto) { LoginVO vo authService.login(dto.getPhone(), dto.getPassword()); return Result.ok(vo); } }Service 層校驗(yàn)手機(jī)號(hào)是否存在、密碼是否匹配并且限制錯(cuò)誤次數(shù)。洗衣店前臺(tái)可能連續(xù)輸錯(cuò)幾次一鎖就 5 分鐘會(huì)打擾營(yíng)業(yè)。更好的做法是同一個(gè)手機(jī)號(hào)一分鐘內(nèi)最多 5 次失敗連續(xù)失敗 10 次鎖 15 分鐘。密碼校驗(yàn)失敗統(tǒng)一返回“手機(jī)號(hào)或密碼錯(cuò)誤”不要把“用戶不存在”和“密碼錯(cuò)誤”區(qū)分開(kāi)否則容易被拿來(lái)撞庫(kù)。接口保護(hù)用注解比如退款接口PostMapping(/refund) PreAuthorize(hasRole(MANAGER)) public ResultVoid refund(RequestBody RefundDTO dto) { return refundService.refund(dto); }Spring Security 的角色前綴默認(rèn)是ROLE_所以 User 實(shí)體里給 authority 時(shí)要寫(xiě)成ROLE_MANAGERhasRole(MANAGER)才能匹配。如果數(shù)據(jù)庫(kù)里存的是MANAGER注解要改成hasAuthority(MANAGER)或者統(tǒng)一加前綴。這個(gè)細(xì)節(jié)經(jīng)常導(dǎo)致接口 403排查時(shí)先看角色字符串。3.4 敏感操作二次校驗(yàn)退款、改價(jià)這類操作要強(qiáng)制操作人再次輸入登錄密碼。后端在 RefundDTO 里帶一個(gè)confirmPassword字段校驗(yàn)時(shí)從當(dāng)前登錄用戶取出密碼哈希再做 BCrypt 匹配。前端彈窗只是交互形式后端必須獨(dú)立校驗(yàn)否則接口被腳本直接調(diào)用就繞過(guò)了。洗衣店場(chǎng)景里店長(zhǎng)不在時(shí)前臺(tái)代操作的情況很多這個(gè)二次校驗(yàn)?zāi)軗踝〈蟛糠终`操作。4. 下單、洗護(hù)、取衣、結(jié)算核心業(yè)務(wù)鏈路的Java實(shí)現(xiàn)4.1 下單事務(wù)明細(xì)與訂單同時(shí)寫(xiě)入java 面試題里經(jīng)常問(wèn)的事務(wù)傳播與回滾邊界在這個(gè)下單接口就是一道必答題。下單涉及訂單主表、明細(xì)表、可能還有會(huì)員儲(chǔ)值賬戶流水整單必須在一個(gè)事務(wù)里完成任何一步失敗都回滾。用Transactional時(shí)注意默認(rèn)只回滾 RuntimeException建議顯式寫(xiě)rollbackFor Exception.class。后端不能信任前端傳過(guò)來(lái)的金額。正確順序是讀出當(dāng)前價(jià)目表重新計(jì)算每件衣物金額再累加整單金額。洗衣店的計(jì)價(jià)規(guī)則里常有“三件以上每件八折、會(huì)員再打九折”這種組合把計(jì)價(jià)邏輯抽成獨(dú)立的PriceCalculator以后改規(guī)則只動(dòng)一個(gè)類。Transactional(rollbackFor Exception.class) public Long createOrder(CreateOrderDTO dto, User operator) { Member member memberService.getById(dto.getMemberId()); ListOrderItem items buildOrderItems(dto.getItems(), member); BigDecimal total items.stream() .map(OrderItem::getPriceSnapshot) .reduce(BigDecimal.ZERO, BigDecimal::add); LaundryOrder order new LaundryOrder(); order.setOrderNo(generateOrderNo()); order.setCustomerId(member.getId()); order.setStoreId(operator.getStoreId()); order.setTotalAmount(total); order.setPayableAmount(total); order.setOrderStatus(OrderStatus.CREATED); orderMapper.insert(order); items.forEach(item - item.setOrderId(order.getOrderId())); itemService.saveBatch(items); return order.getOrderId(); }rollbackFor Exception.class的目的如果下單成功后生成取衣碼的步驟拋了受檢異常事務(wù)也能回滾。generateOrderNo()建議用日期 門店號(hào) 4 位流水比如2025010210010001方便前臺(tái)按訂單號(hào)口頭報(bào)單也方便按日期查流水。4.2 洗護(hù)狀態(tài)機(jī)怎么防住“直接改成已取衣”狀態(tài)機(jī)是 java 后端完整成長(zhǎng)路線里繞不開(kāi)的點(diǎn)落到洗衣店就是一張遷移白名單。訂單狀態(tài)包括創(chuàng)建、洗護(hù)中、質(zhì)檢中、可取衣、已取衣、返洗、作廢衣物明細(xì)狀態(tài)可能比訂單更細(xì)需要區(qū)分“正在洗”“已洗完”“已質(zhì)檢”。訂單和明細(xì)的狀態(tài)同步更新但明細(xì)狀態(tài)是訂單狀態(tài)的前置條件。狀態(tài)變更記錄單獨(dú)建表CREATE TABLE state_history ( history_id BIGINT AUTO_INCREMENT PRIMARY KEY, entity_type VARCHAR(20) NOT NULL COMMENT ORDER 或 ITEM, entity_id BIGINT NOT NULL COMMENT 訂單ID或明細(xì)ID, from_status VARCHAR(20) COMMENT 遷移前狀態(tài), to_status VARCHAR(20) NOT NULL COMMENT 遷移后狀態(tài), operator_id BIGINT NOT NULL COMMENT 操作人ID, remark VARCHAR(255) COMMENT 備注返洗原因等, created_at DATETIME NOT NULL COMMENT 操作時(shí)間 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT業(yè)務(wù)狀態(tài)流轉(zhuǎn)記錄;狀態(tài)遷移規(guī)則如下當(dāng)前狀態(tài)下一狀態(tài)白名單允許角色前置條件CREATEDWASHING / VOID前臺(tái)、洗衣工衣物已清點(diǎn)WASHINGQUALITY_CHECK / REWASH洗衣工、店長(zhǎng)質(zhì)檢不合格時(shí)返洗QUALITY_CHECKREADY / REWASH店長(zhǎng)、質(zhì)檢員返洗需記錄原因READYPICKED_UP前臺(tái)必須校驗(yàn)取衣碼PICKED_UPREWASH店長(zhǎng)顧客取衣后發(fā)現(xiàn)問(wèn)題驅(qū)動(dòng)狀態(tài)遷移的服務(wù)里第一步查當(dāng)前狀態(tài)第二步查允許的下一狀態(tài)第三步校驗(yàn)操作人角色第四步寫(xiě)入 state_historypublic void transition(LaundryOrder order, OrderStatus target, User operator, String remark) { OrderStatus current order.getOrderStatus(); ListOrderStatus allowed TRANSITIONS.get(current); if (allowed null || !allowed.contains(target)) { throw new BusinessException(SSE-4001, 不允許的狀態(tài)遷移); } if (target OrderStatus.PICKED_UP) { checkPickupCode(order); } order.setOrderStatus(target); orderMapper.updateById(order); StateHistory history new StateHistory(); history.setEntityType(ORDER); history.setEntityId(order.getOrderId()); history.setFromStatus(current.name()); history.setToStatus(target.name()); history.setOperatorId(operator.getId()); history.setRemark(remark); stateHistoryMapper.insert(history); }transition方法的四個(gè)參數(shù)中order 是當(dāng)前訂單實(shí)體target 是目標(biāo)狀態(tài)operator 是當(dāng)前登錄用戶remark 記錄返洗原因。這里有個(gè)關(guān)鍵約束前端頁(yè)面只能調(diào)用服務(wù)層暴露的transition接口不能自己拼 UPDATE 語(yǔ)句。如果發(fā)現(xiàn)某個(gè)訂單的狀態(tài)不是通過(guò)白名單遷移過(guò)來(lái)的說(shuō)明代碼路徑繞過(guò)狀態(tài)機(jī)要優(yōu)先排查。4.3 取衣碼和取衣校驗(yàn)取衣是洗衣店最頻繁的操作。很多前臺(tái)圖快只報(bào)手機(jī)號(hào)就讓顧客拿走但手機(jī)號(hào)容易被他人猜到或報(bào)錯(cuò)。更好的方式是在訂單確認(rèn)時(shí)生成 4 位取衣碼取衣時(shí)顧客出示前臺(tái)輸入后校驗(yàn)。取衣碼存冗余在 order 表里隨機(jī)數(shù)生成后落庫(kù)并設(shè)置當(dāng)日有效。顧客在收銀報(bào)手機(jī)號(hào)和取衣碼前臺(tái)輸入后校驗(yàn)命中才允許點(diǎn)擊“取衣”按鈕。如果訂單金額超過(guò) 500 元可以要求雙重校驗(yàn)取衣碼加下單時(shí)登記的顧客手機(jī)尾號(hào)。取衣碼連續(xù)輸入錯(cuò)誤 5 次后鎖定需店長(zhǎng)解鎖防止惡意試碼。這個(gè)機(jī)制簡(jiǎn)單但能顯著降低“衣服被錯(cuò)取”的糾紛。4.4 結(jié)算時(shí)的折扣與會(huì)員儲(chǔ)值結(jié)算和下單可以分離。下單時(shí)只記錄應(yīng)收金額取衣時(shí)再結(jié)算。結(jié)算接口要做四件事重新核對(duì)金額、優(yōu)先扣會(huì)員儲(chǔ)值、剩余走現(xiàn)金或收款碼、寫(xiě)支付流水。public BigDecimal calcDiscount(LaundryOrder order, Member member) { BigDecimal total order.getTotalAmount(); BigDecimal ratio BigDecimal.ONE; if (member ! null member.getLevel() 2) { ratio ratio.multiply(new BigDecimal(0.9)); } if (order.getItemCount() 3) { ratio ratio.multiply(new BigDecimal(0.8)); } BigDecimal payable total.multiply(ratio).setScale(2, RoundingMode.HALF_UP); order.setDiscountAmount(total.subtract(payable)); order.setPayableAmount(payable); return payable; }折扣比例用字符串構(gòu)造 BigDecimal不要用0.9這種 double 常量否則會(huì)出現(xiàn)0.899999這類精度問(wèn)題。計(jì)算后必須setScale(2, RoundingMode.HALF_UP)指定舍入模式不然后續(xù)相加會(huì)出現(xiàn)“一分錢”差異。會(huì)員等級(jí)和滿減活動(dòng)屬于促銷規(guī)則建議抽成ListDiscountRule按順序應(yīng)用。洗衣店常見(jiàn)的活動(dòng)規(guī)則是“不同時(shí)疊加取最優(yōu)”不要把多個(gè)折扣乘在一起要先在業(yè)務(wù)側(cè)明確規(guī)則再寫(xiě)代碼。儲(chǔ)值扣款時(shí)要先查余額再扣款再寫(xiě)流水三步都在一個(gè)事務(wù)里并且對(duì)賬戶行加悲觀鎖防止兩個(gè)前臺(tái)同時(shí)操作同一張會(huì)員卡導(dǎo)致余額扣成負(fù)數(shù)。這個(gè)場(chǎng)景在并發(fā)量不高的洗衣店里不容易觸發(fā)但一旦發(fā)生顧客會(huì)直接投訴。5. 報(bào)表核對(duì)和狀態(tài)機(jī)遷移記錄是系統(tǒng)上線后最值錢的部分5.1 營(yíng)業(yè)日?qǐng)?bào)SQL別用sum(amount)糊弄賬洗衣店的營(yíng)業(yè)報(bào)表要能回答兩個(gè)問(wèn)題今天實(shí)收多少錢今天該收多少錢。前者來(lái)自訂單結(jié)算時(shí)間后者只看下單時(shí)間和明細(xì)金額。如果兩個(gè)口徑對(duì)不上說(shuō)明有單子結(jié)算時(shí)間缺失或者訂單狀態(tài)沒(méi)更新。用一條 SQL 把當(dāng)天的取衣結(jié)算金額按支付方式統(tǒng)計(jì)SELECT DATE_FORMAT(settle_time, %Y-%m-%d) AS stat_date, payment_method, COUNT(*) AS order_count, SUM(payable_amount) AS settle_amount, SUM(discount_amount) AS discount_total FROM laundry_order WHERE settle_time IS NOT NULL AND settle_time 2025-01-01 00:00:00 AND settle_time 2025-01-02 00:00:00 GROUP BY DATE_FORMAT(settle_time, %Y-%m-%d), payment_method ORDER BY payment_method;payable_amount 是實(shí)收金額discount_total 是打折總金額。時(shí)間范圍用和圈住一整天避免用 BETWEEN 造成零點(diǎn)邊界誤差。每天對(duì)賬時(shí)把這條 SQL 的實(shí)收金額和微信、支付寶后臺(tái)的賬單比一下差幾分錢大概率是舍入。5.2 用定時(shí)任務(wù)生成日終匯總每天人工跑 SQL 容易漏。用 Spring Boot 自帶的定時(shí)任務(wù)在每天凌晨生成前一天的營(yíng)業(yè)匯總Component public class DailyReportJob { private final ReportService reportService; Scheduled(cron 0 5 0 * * ?) public void generateYesterdayReport() { reportService.generateDailyReport(LocalDate.now().minusDays(1)); } }cron 表達(dá)式0 5 0 * * ?表示每天 00:05 執(zhí)行跑的是前一天的數(shù)據(jù)。生成報(bào)表時(shí)要檢查 state_history 里是否有“已取衣”但 laundry_order 狀態(tài)不是 PICKED_UP 的不一致記錄。發(fā)現(xiàn)這種數(shù)據(jù)要在報(bào)表里單獨(dú)列一個(gè)“異常單數(shù)”先找操作人記錄再?zèng)Q定是補(bǔ)操作記錄還是改狀態(tài)不要強(qiáng)行修數(shù)據(jù)掩蓋問(wèn)題。5.3 驗(yàn)證狀態(tài)機(jī)遷移是否被繞過(guò)上線前寫(xiě)一段數(shù)據(jù)校驗(yàn)?zāi)_本把訂單當(dāng)前狀態(tài)和 state_history 的末端狀態(tài)做一致性比對(duì)SELECT o.order_no, o.order_status, h.to_status FROM laundry_order o LEFT JOIN state_history h ON h.entity_type ORDER AND h.entity_id o.order_id WHERE h.created_at (SELECT MAX(h2.created_at) FROM state_history h2 WHERE h2.entity_type ORDER AND h2.entity_id o.order_id) AND o.order_status h.to_status;這條 SQL 找出每個(gè)訂單最后一條歷史記錄與當(dāng)前狀態(tài)不一致的單子。如果查詢結(jié)果有數(shù)據(jù)說(shuō)明有代碼路徑繞過(guò)狀態(tài)機(jī)直接改了狀態(tài)或者歷史記錄沒(méi)寫(xiě)全。洗衣店系統(tǒng)長(zhǎng)期維護(hù)的難點(diǎn)就在這里光有狀態(tài)字段不夠還要有狀態(tài)的歷史證據(jù)所有返洗、退款、改價(jià)都要能在 state_history 里對(duì)出來(lái)。本文還有配套的精品資源點(diǎn)擊獲取 基于Java的洗衣店管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)：訂單狀態(tài)與權(quán)限實(shí)戰(zhàn)
簡(jiǎn)介完整的洗衣店管理系統(tǒng)畢業(yè)設(shè)計(jì)論文面向Java Web開(kāi)發(fā)學(xué)習(xí)者、高校計(jì)算機(jī)相關(guān)專業(yè)學(xué)生以及需要快速上手B/S結(jié)構(gòu)項(xiàng)目的開(kāi)發(fā)者。文檔基于B/S架構(gòu)采用JSP、Java與MySQL數(shù)據(jù)庫(kù)進(jìn)行設(shè)計(jì)詳細(xì)闡述了用戶消費(fèi)記錄查詢、衣服清洗/修補(bǔ)/賠償管理、會(huì)員卡管理及營(yíng)業(yè)額統(tǒng)計(jì)等核心功能模塊并對(duì)系統(tǒng)安全、可擴(kuò)展性與可維護(hù)性進(jìn)行了分析。資源包僅含1個(gè)docx文檔文件大小3.11MB內(nèi)容涵蓋緒論、系統(tǒng)開(kāi)發(fā)環(huán)境、功能設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)、操作界面等完整章節(jié)并附有中英文摘要與目錄結(jié)構(gòu)。文檔中不僅給出了系統(tǒng)總體架構(gòu)和數(shù)據(jù)庫(kù)表結(jié)構(gòu)還對(duì)各模塊的JSP頁(yè)面與后臺(tái)Java邏輯交互流程進(jìn)行了說(shuō)明可以幫助讀者快速建立開(kāi)發(fā)思路直接適配課程設(shè)計(jì)或畢業(yè)設(shè)計(jì)需求。目前已有154人學(xué)習(xí)下載適合需要參考完整論文撰寫(xiě)規(guī)范與項(xiàng)目設(shè)計(jì)流程的讀者。1. 基于java洗衣店管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)先解決“衣服到哪了”一個(gè)普通洗衣店一天收一百來(lái)單每單三五件衣服。真正讓店員頭疼的不是洗不干凈而是顧客問(wèn)“我那件羽絨服好了沒(méi)”時(shí)前臺(tái)只能說(shuō)“我去看看”。干洗、水洗、熨燙、質(zhì)檢、返洗、暫存每換一個(gè)環(huán)節(jié)就經(jīng)手一個(gè)人漏記一次后面全是翻找和扯皮?；趈ava洗衣店管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)要解決的就是把“一件衣服現(xiàn)在在哪個(gè)狀態(tài)”變成可查詢的記錄再用權(quán)限、事務(wù)和報(bào)表把每個(gè)環(huán)節(jié)鎖住。這套系統(tǒng)適合兩類人一是做畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)的Java后端學(xué)習(xí)者能在訂單、鑒權(quán)、統(tǒng)計(jì)模塊里完整走一遍二是想給本地小店做輕量化改造的開(kāi)發(fā)者。洗衣單不是普通買賣單它有多件衣物明細(xì)、動(dòng)態(tài)狀態(tài)、按件計(jì)費(fèi)和會(huì)員儲(chǔ)值數(shù)據(jù)模型必須圍繞狀態(tài)流轉(zhuǎn)來(lái)設(shè)計(jì)。2. 用Spring Boot先落數(shù)據(jù)模型訂單、衣物、計(jì)費(fèi)規(guī)則怎么建表2.1 下單要同時(shí)寫(xiě)多張表實(shí)體邊界先分清洗衣店業(yè)務(wù)中最核心的實(shí)體不是“衣服”而是“洗衣訂單”。一個(gè)訂單包含多件衣物每件衣物有獨(dú)立的洗護(hù)方式、價(jià)格和狀態(tài)因此需要拆成訂單主表、訂單明細(xì)表和狀態(tài)流轉(zhuǎn)記錄表。常見(jiàn)的做法是客戶表算一方訂單表算一方明細(xì)表記錄多方衣物。狀態(tài)流轉(zhuǎn)單獨(dú)建表是因?yàn)橄匆鹿べ|(zhì)檢不過(guò)、顧客要求返洗這類事件后續(xù)要用來(lái)算返洗率和績(jī)效。以下是我常用的建表結(jié)構(gòu)數(shù)據(jù)庫(kù)用MySQL 8字符集統(tǒng)一utf8mb4。CREATE TABLE laundry_order ( order_id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 訂單ID, order_no VARCHAR(24) NOT NULL COMMENT 訂單號(hào)前臺(tái)展示用, customer_id BIGINT NOT NULL COMMENT 客戶ID, store_id BIGINT NOT NULL COMMENT 門店ID, order_status VARCHAR(20) NOT NULL DEFAULT CREATED COMMENT 訂單狀態(tài), total_amount DECIMAL(10,2) NOT NULL COMMENT 原價(jià)總額, discount_amount DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 折扣金額, payable_amount DECIMAL(10,2) NOT NULL COMMENT 應(yīng)付金額, created_at DATETIME NOT NULL COMMENT 創(chuàng)建時(shí)間, updated_at DATETIME NOT NULL COMMENT 最后更新時(shí)間, UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT洗衣訂單主表; CREATE TABLE order_item ( item_id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL COMMENT 所屬訂單ID, item_name VARCHAR(64) NOT NULL COMMENT 衣物名稱, wash_method VARCHAR(20) NOT NULL COMMENT 洗護(hù)方式, item_count INT NOT NULL DEFAULT 1 COMMENT 件數(shù), price_snapshot DECIMAL(10,2) NOT NULL COMMENT 下單時(shí)單價(jià), item_status VARCHAR(20) NOT NULL DEFAULT CREATED COMMENT 衣物狀態(tài), KEY idx_order_item (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT衣物明細(xì)表;訂單主表把整單金額、訂單狀態(tài)鎖在一起明細(xì)表負(fù)責(zé)單件衣物的洗護(hù)方式和狀態(tài)。注意price_snapshot記錄的是下單那一刻的單價(jià)不是每次查詢時(shí)去讀價(jià)目表。洗衣店的價(jià)目表會(huì)隨著換季、活動(dòng)調(diào)整如果明細(xì)里不保留下單價(jià)改價(jià)之后歷史賬單會(huì)全部亂掉。創(chuàng)建時(shí)間字段用 DATETIME不要用 TIMESTAMP 存儲(chǔ)避免 2038 年問(wèn)題和夏令時(shí)換算干擾Java 側(cè)用 LocalDateTime 接收。2.2 金額用DECIMAL狀態(tài)用字符串還是枚舉金額和折扣類字段必須用 DECIMAL(10,2)Java 實(shí)體里對(duì)應(yīng) BigDecimal不要用 double 或 float。洗衣店的會(huì)員折扣、返洗賠付、儲(chǔ)值抵扣經(jīng)常出現(xiàn) 0.05 這種精度要求浮點(diǎn)運(yùn)算在小數(shù)位多時(shí)會(huì)出現(xiàn)金額對(duì)不平的情況排查成本遠(yuǎn)高于建表時(shí)多寫(xiě)幾個(gè)字符。字段類型可以按下面這張表定減少后期返工。字段用途推薦類型原因金額、折扣DECIMAL(10,2)精度可控避免浮點(diǎn)誤差訂單號(hào)VARCHAR(24)需要自定義規(guī)則比如日期加流水狀態(tài)VARCHAR(20)可讀性好排查數(shù)據(jù)方便創(chuàng)建時(shí)間DATETIME避開(kāi) TIMESTAMP 的 2038 年問(wèn)題訂單狀態(tài)字段我習(xí)慣在數(shù)據(jù)庫(kù)里存字符串在 Java 代碼里用枚舉定義常量。不要用數(shù)字代表狀態(tài)否則三個(gè)月后你會(huì)面對(duì)一個(gè)“3 到底表示已取衣還是已結(jié)算”的問(wèn)題。枚舉上可以掛上中文標(biāo)簽public enum OrderStatus { CREATED(待取衣), WASHING(洗護(hù)中), QUALITY_CHECK(質(zhì)檢中), READY(可取衣), PICKED_UP(已取衣), REWASH(返洗), VOID(已作廢); private final String label; OrderStatus(String label) { this.label label; } }狀態(tài)流轉(zhuǎn)時(shí)只允許從當(dāng)前狀態(tài)遷移到指定下一狀態(tài)。這個(gè)校驗(yàn)如果散落在前端頁(yè)面遲早會(huì)被繞過(guò)。后面第 4 章會(huì)給出一個(gè)集中的狀態(tài)機(jī)服務(wù)來(lái)管這件事。2.3 持久層選MyBatis-Plus還是Spring Data JPA單體項(xiàng)目里我一般選 MyBatis-Plus原因有三個(gè)。第一多表關(guān)聯(lián)查詢可以直接寫(xiě) SQL洗衣店的營(yíng)運(yùn)報(bào)表經(jīng)常要 join 訂單、明細(xì)、支付三張表MyBatis-Plus 的 xml 或注解 SQL 肉眼可讀。第二分頁(yè)插件對(duì)“下單記錄要分頁(yè)列表”這種需求開(kāi)箱即用不需要自己拼 LIMIT。第三updateById默認(rèn)只更新非空字段做部分狀態(tài)更新比較友好不容易把其他字段覆蓋掉。如果指導(dǎo)老師要求用 Spring Data JPA也可以。但要注意關(guān)聯(lián)查詢時(shí)的 N1 問(wèn)題取衣列表經(jīng)常要查訂單明細(xì)不要在循環(huán)里逐條查數(shù)據(jù)庫(kù)。用EntityGraph或者寫(xiě)一個(gè)顯式 join 查詢一次取出明細(xì)列表回到內(nèi)存后按 orderId 分組再用視圖對(duì)象組裝數(shù)據(jù)庫(kù)只查兩次。2.4 初始化腳本用Flyway管理數(shù)據(jù)表不是一次建完就結(jié)束后面加字段、加索引是常態(tài)。用 Flyway 把這些變更納入版本管理比每個(gè)人都手動(dòng)執(zhí)行 SQL 腳本靠譜。項(xiàng)目啟動(dòng)時(shí)配置spring.flyway.enabledtrue在src/main/resources/db/migration下放 V1、V2 等腳本第一版就放上面的建表語(yǔ)句。升級(jí)的時(shí)候V2 里只寫(xiě) ALTER 語(yǔ)句比如給 order_item 加一個(gè)tag_no標(biāo)簽號(hào)字段用于店內(nèi)掃碼找衣。新環(huán)境從零初始化、老環(huán)境增量升級(jí)都走同一條路徑不會(huì)出現(xiàn)“我這能跑你那就報(bào)錯(cuò)”的情況。提示啟動(dòng)報(bào) “Flyway validate failed” 時(shí)先檢查腳本 checksum 是否被手動(dòng)改過(guò)。如果數(shù)據(jù)已經(jīng)變更用 repair 命令修復(fù)記錄不要直接刪 flyway_schema_history 表。新環(huán)境跑不起來(lái)的頭號(hào)原因不是代碼而是本機(jī) Java 環(huán)境變量配置、MySQL 版本和連接串里的時(shí)區(qū)參數(shù)。JDK 17 下連接 MySQL 8url 里加上serverTimezoneAsia/Shanghai能省掉大量時(shí)間字段錯(cuò)亂的問(wèn)題。3. 洗衣店管理系統(tǒng)的登錄鑒權(quán)三種角色怎么控制權(quán)限3.1 前臺(tái)、洗衣工、店長(zhǎng)的操作邊界先按業(yè)務(wù)把角色理清。前臺(tái)負(fù)責(zé)下單、錄入衣物、收款、取衣核銷洗衣工負(fù)責(zé)接單、上報(bào)送洗、上報(bào)完成店長(zhǎng)負(fù)責(zé)改價(jià)、返洗、退款、關(guān)賬。如果還有“加盟店老板”不要因此把權(quán)限模型復(fù)雜化在角色表里加一行即可。角色能做的操作不能做的操作前臺(tái)下單、改衣、結(jié)算、取衣退款、批量改價(jià)、關(guān)賬洗衣工接單、上報(bào)洗護(hù)完成結(jié)算、退款、作廢訂單店長(zhǎng)全部操作無(wú)權(quán)限維度不多我傾向在代碼里用 Spring Security 注解硬編碼而不是引入動(dòng)態(tài)權(quán)限表。需要重點(diǎn)保護(hù)的接口是退款只允許ROLE_MANAGER返洗需要店長(zhǎng)二次確認(rèn)已作廢訂單不能被再次修改。硬編碼的好處是代碼即文檔后端維護(hù)人員一眼能看到某個(gè)接口誰(shuí)能調(diào)。3.2 Spring Security JWT的登錄流程前端和后端分開(kāi)部署時(shí)用 JWT 比 Session 更適合省掉跨域 Session 同步。登錄接口接收手機(jī)號(hào)和密碼校驗(yàn)通過(guò)后生成 token把 userId、storeId、role 放進(jìn)去。后續(xù)請(qǐng)求經(jīng)過(guò)過(guò)濾器時(shí)從 token 里取用戶信息設(shè)置到 SecurityContext。Component public class JwtAuthFilter extends OncePerRequestFilter { private final JwtTokenUtil jwtTokenUtil; private final UserService userService; public JwtAuthFilter(JwtTokenUtil jwtTokenUtil, UserService userService) { this.jwtTokenUtil jwtTokenUtil; this.userService userService; } Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String header request.getHeader(Authorization); if (header ! null header.startsWith(Bearer )) { String token header.substring(7); String userId jwtTokenUtil.getUserId(token); if (userId ! null) { User user userService.getById(userId); UsernamePasswordAuthenticationToken auth new UsernamePasswordAuthenticationToken(user, null, user.getAuthorities()); SecurityContextHolder.getContext().setAuthentication(auth); } } chain.doFilter(request, response); } }這段過(guò)濾器的核心邏輯是從請(qǐng)求頭拿到 Authorization判斷是否以Bearer開(kāi)頭解析 token 取 userId再查庫(kù)得到用戶和角色。UsernamePasswordAuthenticationToken的第一個(gè)參數(shù)放當(dāng)前用戶對(duì)象第三個(gè)參數(shù)放角色集合中間參數(shù)是憑證JWT 模式下不需要再放密碼。有個(gè)容易踩的坑header.substring(7)的前提是字符串長(zhǎng)度一定大于 7。如果前端傳了個(gè)空 token 或格式不標(biāo)準(zhǔn)的字符串這里會(huì)直接拋異常。建議先判斷header.length() 7再截取或者把解析邏輯包在 try-catch 里解析失敗時(shí)直接放行讓后續(xù) Spring Security 的匿名用戶邏輯接手。3.3 登錄接口和權(quán)限注解登錄接口做兩件事校驗(yàn)密碼和簽發(fā) token。密碼在數(shù)據(jù)庫(kù)里存 BCrypt 哈希不要存明文。登錄成功后返回 token 和用戶角色前端把 token 存到 localStorage每次請(qǐng)求帶上即可。這里不推薦做“七天免登錄”之類的長(zhǎng)有效期 token洗衣店前臺(tái)共用瀏覽器token 有效期控制在 12 小時(shí)以內(nèi)比較穩(wěn)妥。RestController RequestMapping(/api/auth) public class AuthController { private final AuthService authService; public AuthController(AuthService authService) { this.authService authService; } PostMapping(/login) public ResultLoginVO login(RequestBody LoginDTO dto) { LoginVO vo authService.login(dto.getPhone(), dto.getPassword()); return Result.ok(vo); } }Service 層校驗(yàn)手機(jī)號(hào)是否存在、密碼是否匹配并且限制錯(cuò)誤次數(shù)。洗衣店前臺(tái)可能連續(xù)輸錯(cuò)幾次一鎖就 5 分鐘會(huì)打擾營(yíng)業(yè)。更好的做法是同一個(gè)手機(jī)號(hào)一分鐘內(nèi)最多 5 次失敗連續(xù)失敗 10 次鎖 15 分鐘。密碼校驗(yàn)失敗統(tǒng)一返回“手機(jī)號(hào)或密碼錯(cuò)誤”不要把“用戶不存在”和“密碼錯(cuò)誤”區(qū)分開(kāi)否則容易被拿來(lái)撞庫(kù)。接口保護(hù)用注解比如退款接口PostMapping(/refund) PreAuthorize(hasRole(MANAGER)) public ResultVoid refund(RequestBody RefundDTO dto) { return refundService.refund(dto); }Spring Security 的角色前綴默認(rèn)是ROLE_所以 User 實(shí)體里給 authority 時(shí)要寫(xiě)成ROLE_MANAGERhasRole(MANAGER)才能匹配。如果數(shù)據(jù)庫(kù)里存的是MANAGER注解要改成hasAuthority(MANAGER)或者統(tǒng)一加前綴。這個(gè)細(xì)節(jié)經(jīng)常導(dǎo)致接口 403排查時(shí)先看角色字符串。3.4 敏感操作二次校驗(yàn)退款、改價(jià)這類操作要強(qiáng)制操作人再次輸入登錄密碼。后端在 RefundDTO 里帶一個(gè)confirmPassword字段校驗(yàn)時(shí)從當(dāng)前登錄用戶取出密碼哈希再做 BCrypt 匹配。前端彈窗只是交互形式后端必須獨(dú)立校驗(yàn)否則接口被腳本直接調(diào)用就繞過(guò)了。洗衣店場(chǎng)景里店長(zhǎng)不在時(shí)前臺(tái)代操作的情況很多這個(gè)二次校驗(yàn)?zāi)軗踝〈蟛糠终`操作。4. 下單、洗護(hù)、取衣、結(jié)算核心業(yè)務(wù)鏈路的Java實(shí)現(xiàn)4.1 下單事務(wù)明細(xì)與訂單同時(shí)寫(xiě)入java 面試題里經(jīng)常問(wèn)的事務(wù)傳播與回滾邊界在這個(gè)下單接口就是一道必答題。下單涉及訂單主表、明細(xì)表、可能還有會(huì)員儲(chǔ)值賬戶流水整單必須在一個(gè)事務(wù)里完成任何一步失敗都回滾。用Transactional時(shí)注意默認(rèn)只回滾 RuntimeException建議顯式寫(xiě)rollbackFor Exception.class。后端不能信任前端傳過(guò)來(lái)的金額。正確順序是讀出當(dāng)前價(jià)目表重新計(jì)算每件衣物金額再累加整單金額。洗衣店的計(jì)價(jià)規(guī)則里常有“三件以上每件八折、會(huì)員再打九折”這種組合把計(jì)價(jià)邏輯抽成獨(dú)立的PriceCalculator以后改規(guī)則只動(dòng)一個(gè)類。Transactional(rollbackFor Exception.class) public Long createOrder(CreateOrderDTO dto, User operator) { Member member memberService.getById(dto.getMemberId()); ListOrderItem items buildOrderItems(dto.getItems(), member); BigDecimal total items.stream() .map(OrderItem::getPriceSnapshot) .reduce(BigDecimal.ZERO, BigDecimal::add); LaundryOrder order new LaundryOrder(); order.setOrderNo(generateOrderNo()); order.setCustomerId(member.getId()); order.setStoreId(operator.getStoreId()); order.setTotalAmount(total); order.setPayableAmount(total); order.setOrderStatus(OrderStatus.CREATED); orderMapper.insert(order); items.forEach(item - item.setOrderId(order.getOrderId())); itemService.saveBatch(items); return order.getOrderId(); }rollbackFor Exception.class的目的如果下單成功后生成取衣碼的步驟拋了受檢異常事務(wù)也能回滾。generateOrderNo()建議用日期 門店號(hào) 4 位流水比如2025010210010001方便前臺(tái)按訂單號(hào)口頭報(bào)單也方便按日期查流水。4.2 洗護(hù)狀態(tài)機(jī)怎么防住“直接改成已取衣”狀態(tài)機(jī)是 java 后端完整成長(zhǎng)路線里繞不開(kāi)的點(diǎn)落到洗衣店就是一張遷移白名單。訂單狀態(tài)包括創(chuàng)建、洗護(hù)中、質(zhì)檢中、可取衣、已取衣、返洗、作廢衣物明細(xì)狀態(tài)可能比訂單更細(xì)需要區(qū)分“正在洗”“已洗完”“已質(zhì)檢”。訂單和明細(xì)的狀態(tài)同步更新但明細(xì)狀態(tài)是訂單狀態(tài)的前置條件。狀態(tài)變更記錄單獨(dú)建表CREATE TABLE state_history ( history_id BIGINT AUTO_INCREMENT PRIMARY KEY, entity_type VARCHAR(20) NOT NULL COMMENT ORDER 或 ITEM, entity_id BIGINT NOT NULL COMMENT 訂單ID或明細(xì)ID, from_status VARCHAR(20) COMMENT 遷移前狀態(tài), to_status VARCHAR(20) NOT NULL COMMENT 遷移后狀態(tài), operator_id BIGINT NOT NULL COMMENT 操作人ID, remark VARCHAR(255) COMMENT 備注返洗原因等, created_at DATETIME NOT NULL COMMENT 操作時(shí)間 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT業(yè)務(wù)狀態(tài)流轉(zhuǎn)記錄;狀態(tài)遷移規(guī)則如下當(dāng)前狀態(tài)下一狀態(tài)白名單允許角色前置條件CREATEDWASHING / VOID前臺(tái)、洗衣工衣物已清點(diǎn)WASHINGQUALITY_CHECK / REWASH洗衣工、店長(zhǎng)質(zhì)檢不合格時(shí)返洗QUALITY_CHECKREADY / REWASH店長(zhǎng)、質(zhì)檢員返洗需記錄原因READYPICKED_UP前臺(tái)必須校驗(yàn)取衣碼PICKED_UPREWASH店長(zhǎng)顧客取衣后發(fā)現(xiàn)問(wèn)題驅(qū)動(dòng)狀態(tài)遷移的服務(wù)里第一步查當(dāng)前狀態(tài)第二步查允許的下一狀態(tài)第三步校驗(yàn)操作人角色第四步寫(xiě)入 state_historypublic void transition(LaundryOrder order, OrderStatus target, User operator, String remark) { OrderStatus current order.getOrderStatus(); ListOrderStatus allowed TRANSITIONS.get(current); if (allowed null || !allowed.contains(target)) { throw new BusinessException(SSE-4001, 不允許的狀態(tài)遷移); } if (target OrderStatus.PICKED_UP) { checkPickupCode(order); } order.setOrderStatus(target); orderMapper.updateById(order); StateHistory history new StateHistory(); history.setEntityType(ORDER); history.setEntityId(order.getOrderId()); history.setFromStatus(current.name()); history.setToStatus(target.name()); history.setOperatorId(operator.getId()); history.setRemark(remark); stateHistoryMapper.insert(history); }transition方法的四個(gè)參數(shù)中order 是當(dāng)前訂單實(shí)體target 是目標(biāo)狀態(tài)operator 是當(dāng)前登錄用戶remark 記錄返洗原因。這里有個(gè)關(guān)鍵約束前端頁(yè)面只能調(diào)用服務(wù)層暴露的transition接口不能自己拼 UPDATE 語(yǔ)句。如果發(fā)現(xiàn)某個(gè)訂單的狀態(tài)不是通過(guò)白名單遷移過(guò)來(lái)的說(shuō)明代碼路徑繞過(guò)狀態(tài)機(jī)要優(yōu)先排查。4.3 取衣碼和取衣校驗(yàn)取衣是洗衣店最頻繁的操作。很多前臺(tái)圖快只報(bào)手機(jī)號(hào)就讓顧客拿走但手機(jī)號(hào)容易被他人猜到或報(bào)錯(cuò)。更好的方式是在訂單確認(rèn)時(shí)生成 4 位取衣碼取衣時(shí)顧客出示前臺(tái)輸入后校驗(yàn)。取衣碼存冗余在 order 表里隨機(jī)數(shù)生成后落庫(kù)并設(shè)置當(dāng)日有效。顧客在收銀報(bào)手機(jī)號(hào)和取衣碼前臺(tái)輸入后校驗(yàn)命中才允許點(diǎn)擊“取衣”按鈕。如果訂單金額超過(guò) 500 元可以要求雙重校驗(yàn)取衣碼加下單時(shí)登記的顧客手機(jī)尾號(hào)。取衣碼連續(xù)輸入錯(cuò)誤 5 次后鎖定需店長(zhǎng)解鎖防止惡意試碼。這個(gè)機(jī)制簡(jiǎn)單但能顯著降低“衣服被錯(cuò)取”的糾紛。4.4 結(jié)算時(shí)的折扣與會(huì)員儲(chǔ)值結(jié)算和下單可以分離。下單時(shí)只記錄應(yīng)收金額取衣時(shí)再結(jié)算。結(jié)算接口要做四件事重新核對(duì)金額、優(yōu)先扣會(huì)員儲(chǔ)值、剩余走現(xiàn)金或收款碼、寫(xiě)支付流水。public BigDecimal calcDiscount(LaundryOrder order, Member member) { BigDecimal total order.getTotalAmount(); BigDecimal ratio BigDecimal.ONE; if (member ! null member.getLevel() 2) { ratio ratio.multiply(new BigDecimal(0.9)); } if (order.getItemCount() 3) { ratio ratio.multiply(new BigDecimal(0.8)); } BigDecimal payable total.multiply(ratio).setScale(2, RoundingMode.HALF_UP); order.setDiscountAmount(total.subtract(payable)); order.setPayableAmount(payable); return payable; }折扣比例用字符串構(gòu)造 BigDecimal不要用0.9這種 double 常量否則會(huì)出現(xiàn)0.899999這類精度問(wèn)題。計(jì)算后必須setScale(2, RoundingMode.HALF_UP)指定舍入模式不然后續(xù)相加會(huì)出現(xiàn)“一分錢”差異。會(huì)員等級(jí)和滿減活動(dòng)屬于促銷規(guī)則建議抽成ListDiscountRule按順序應(yīng)用。洗衣店常見(jiàn)的活動(dòng)規(guī)則是“不同時(shí)疊加取最優(yōu)”不要把多個(gè)折扣乘在一起要先在業(yè)務(wù)側(cè)明確規(guī)則再寫(xiě)代碼。儲(chǔ)值扣款時(shí)要先查余額再扣款再寫(xiě)流水三步都在一個(gè)事務(wù)里并且對(duì)賬戶行加悲觀鎖防止兩個(gè)前臺(tái)同時(shí)操作同一張會(huì)員卡導(dǎo)致余額扣成負(fù)數(shù)。這個(gè)場(chǎng)景在并發(fā)量不高的洗衣店里不容易觸發(fā)但一旦發(fā)生顧客會(huì)直接投訴。5. 報(bào)表核對(duì)和狀態(tài)機(jī)遷移記錄是系統(tǒng)上線后最值錢的部分5.1 營(yíng)業(yè)日?qǐng)?bào)SQL別用sum(amount)糊弄賬洗衣店的營(yíng)業(yè)報(bào)表要能回答兩個(gè)問(wèn)題今天實(shí)收多少錢今天該收多少錢。前者來(lái)自訂單結(jié)算時(shí)間后者只看下單時(shí)間和明細(xì)金額。如果兩個(gè)口徑對(duì)不上說(shuō)明有單子結(jié)算時(shí)間缺失或者訂單狀態(tài)沒(méi)更新。用一條 SQL 把當(dāng)天的取衣結(jié)算金額按支付方式統(tǒng)計(jì)SELECT DATE_FORMAT(settle_time, %Y-%m-%d) AS stat_date, payment_method, COUNT(*) AS order_count, SUM(payable_amount) AS settle_amount, SUM(discount_amount) AS discount_total FROM laundry_order WHERE settle_time IS NOT NULL AND settle_time 2025-01-01 00:00:00 AND settle_time 2025-01-02 00:00:00 GROUP BY DATE_FORMAT(settle_time, %Y-%m-%d), payment_method ORDER BY payment_method;payable_amount 是實(shí)收金額discount_total 是打折總金額。時(shí)間范圍用和圈住一整天避免用 BETWEEN 造成零點(diǎn)邊界誤差。每天對(duì)賬時(shí)把這條 SQL 的實(shí)收金額和微信、支付寶后臺(tái)的賬單比一下差幾分錢大概率是舍入。5.2 用定時(shí)任務(wù)生成日終匯總每天人工跑 SQL 容易漏。用 Spring Boot 自帶的定時(shí)任務(wù)在每天凌晨生成前一天的營(yíng)業(yè)匯總Component public class DailyReportJob { private final ReportService reportService; Scheduled(cron 0 5 0 * * ?) public void generateYesterdayReport() { reportService.generateDailyReport(LocalDate.now().minusDays(1)); } }cron 表達(dá)式0 5 0 * * ?表示每天 00:05 執(zhí)行跑的是前一天的數(shù)據(jù)。生成報(bào)表時(shí)要檢查 state_history 里是否有“已取衣”但 laundry_order 狀態(tài)不是 PICKED_UP 的不一致記錄。發(fā)現(xiàn)這種數(shù)據(jù)要在報(bào)表里單獨(dú)列一個(gè)“異常單數(shù)”先找操作人記錄再?zèng)Q定是補(bǔ)操作記錄還是改狀態(tài)不要強(qiáng)行修數(shù)據(jù)掩蓋問(wèn)題。5.3 驗(yàn)證狀態(tài)機(jī)遷移是否被繞過(guò)上線前寫(xiě)一段數(shù)據(jù)校驗(yàn)?zāi)_本把訂單當(dāng)前狀態(tài)和 state_history 的末端狀態(tài)做一致性比對(duì)SELECT o.order_no, o.order_status, h.to_status FROM laundry_order o LEFT JOIN state_history h ON h.entity_type ORDER AND h.entity_id o.order_id WHERE h.created_at (SELECT MAX(h2.created_at) FROM state_history h2 WHERE h2.entity_type ORDER AND h2.entity_id o.order_id) AND o.order_status h.to_status;這條 SQL 找出每個(gè)訂單最后一條歷史記錄與當(dāng)前狀態(tài)不一致的單子。如果查詢結(jié)果有數(shù)據(jù)說(shuō)明有代碼路徑繞過(guò)狀態(tài)機(jī)直接改了狀態(tài)或者歷史記錄沒(méi)寫(xiě)全。洗衣店系統(tǒng)長(zhǎng)期維護(hù)的難點(diǎn)就在這里光有狀態(tài)字段不夠還要有狀態(tài)的歷史證據(jù)所有返洗、退款、改價(jià)都要能在 state_history 里對(duì)出來(lái)。本文還有配套的精品資源點(diǎn)擊獲取