簡介這是一套基于Java后端與微信小程序前端的二手物品交易系統完整源碼面向畢業(yè)設計場景適合計算機相關專業(yè)學生用于課程設計、論文實現或項目二次開發(fā)。壓縮文件共包含1154個文件整包約17MB其中既有js、wxml、wxss等小程序前端頁面與邏輯文件也有java、class構成的后端工程代碼同時收納了xml配置、sql數據庫腳本以及png、jpg等UI素材項目結構完整便于按模塊查閱。源碼已在本地編譯通過下載后配置好JDK、小程序開發(fā)工具等環(huán)境即可運行功能模塊經過指導老師確認完成度較高。數據庫腳本可直接導入配合前端代碼可快速跑通二手交易的前后端交互與核心流程適合作為理解微信小程序與Java后端聯動機制的學習樣本。當前已有408人學習下載對有畢業(yè)設計或新手練手需求的使用者具有不錯的參考價值。1. 這個二手物品交易小程序源碼包到底適合什么場景“微信小程序二手物品交易小程序源碼數據庫.zip”這個壓縮包聽名字就知道里面裝的是什么一個二手物品交易的微信小程序完整工程外加它的后端接口和數據庫腳本。我處理過的這類包不在少數標配一般是三部分——小程序前端、后端服務、SQL 文件合在一起就是一個典型的 C2C 二手交易閉環(huán)用戶登錄、發(fā)布閑置、分類檢索、收藏、議價、下單成交。這類資源對兩類人最有用。一類是畢設或課設學生需要短時間交付一個業(yè)務完整、能現場演示的系統另一類是剛開始學小程序開發(fā)的新手想在一個能跑通的項目里看懂前后端怎么配合。它最大的價值不是代碼寫得有多炫而是業(yè)務閉環(huán)和表結構完整可落地你可以直接在它上面改出自己的東西。但別指望解壓就能跑下面就從拆包開始把每一步怎么走、坑在哪說清楚。2. 源碼包拆解與技術選型目錄、技術棧、數據庫表設計2.1 技術棧組成為什么“小程序原生 Java 后端 MySQL”最常見拿到壓縮包后第一步不是急著解壓運行而是確認它是什么技術棧。這類二手交易小程序的源碼前端部分幾乎都是微信小程序原生開發(fā)目錄里會有 pages、utils、images、app.js、app.json 這些標準文件后端則常見兩派一派是 Java 的 Spring Boot 或 SSM 框架另一派是 Node.js 的 Express 或 PHP 的 ThinkPHP。判斷方法很簡單看根目錄里有沒有 pom.xml 或者 package.json有前者就是 Maven 管理的 Java 工程有后者就是 Node 工程。為什么“小程序原生 Java MySQL”會成為這類源碼包的主流組合答案很現實教學和畢設生態(tài)里 Java 的資料最全MyBatis 操作 MySQL 的寫法網上有大量現成代碼答辯時講“訂單狀態(tài)機”“用戶鑒權”這些也能講出深度。小程序原生開發(fā)則不需要引入 uni-app 或 Taro 這類跨端框架微信開發(fā)者工具打開就能編譯對新手最友好。MySQL 更不用多說免費、裝機量大幾乎任何 SQL 文件都能直接導入。我拿到一個包后的習慣動作是先把目錄結構過一遍再對照根目錄的配置文件確認后端語言。這類包解壓后最常見的結構長這樣# 項目根目錄解壓后 ├── miniprogram/ # 小程序前端源碼 │ ├── pages/ # 頁面 │ │ ├── index/ # 首頁商品列表 │ │ ├── publish/ # 發(fā)布商品 │ │ ├── detail/ # 商品詳情 │ │ ├── order/ # 訂單列表 │ │ └── mine/ # 個人中心 │ ├── utils/ │ │ └── request.js # 封裝 wx.request │ ├── app.js │ ├── app.json │ └── app.wxss ├── server/ # 后端接口源碼 │ ├── pom.xml # Java Maven 工程 │ └── src/main/resources/ │ ├── application.yml │ └── mapper/ # MyBatis XML ├── sql/ │ └── secondhand.sql # 數據庫腳本 └── README.md這是二手交易源碼包的典型目錄形態(tài)實際項目會有細節(jié)差異但主干基本一致?？慈c前端有沒有獨立的 pages 目錄、后端有沒有配置文件、sql 目錄里有沒有可執(zhí)行腳本。三個都有說明包是完整的缺了哪個后面跑通就要自己補。我一般先看 sql 目錄是否為空為空的話這包的價值直接打對折因為數據庫腳本是整個項目的地基沒有它光看代碼很難還原表結構。核對完目錄再看技術棧細節(jié)。Java 后端看 pom.xml 引了哪些依賴重點看有沒有 mybatis-spring-boot-starter 和 spring-boot-starter-web有這兩樣說明是標準的 Spring Boot MyBatis 組合。Node 后端看 package.json 里的 express 或 koa。數據庫基本鎖定 MySQL少數包會用 SQLite但 SQLite 在小程序畢設里很少見。2.2 數據庫核心表設計從二手交易需求反推表結構看懂目錄后最重要的一件事是把數據庫表結構讀明白。我自己的經驗是一個二手交易系統表設計能對上業(yè)務閉環(huán)項目就值得往下改對不上后面改代碼全是坑。這類源碼包的表設計大同小異核心是用戶、商品、分類、收藏、訂單、留言這六張表。先看用戶表和商品表它們是整個業(yè)務的兩大主體-- 用戶表 CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT COMMENT 用戶ID, openid VARCHAR(64) NOT NULL COMMENT 微信openid唯一標識, nickname VARCHAR(50) DEFAULT COMMENT 昵稱, avatar VARCHAR(255) DEFAULT COMMENT 頭像URL, phone VARCHAR(20) DEFAULT COMMENT 聯系電話線下交易用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注冊時間, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用戶表; -- 商品表 CREATE TABLE goods ( id INT NOT NULL AUTO_INCREMENT COMMENT 商品ID, user_id INT NOT NULL COMMENT 發(fā)布者ID關聯user.id, title VARCHAR(100) NOT NULL COMMENT 商品標題, description TEXT COMMENT 商品描述, price DECIMAL(10,2) NOT NULL COMMENT 售價, original_price DECIMAL(10,2) DEFAULT NULL COMMENT 原價用于顯示折扣, category_id INT DEFAULT NULL COMMENT 分類ID, images VARCHAR(1024) DEFAULT NULL COMMENT 圖片URL多張用逗號分隔, status TINYINT DEFAULT 0 COMMENT 0在售 1已售 2下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 發(fā)布時間, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_category (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT二手商品表;這里兩個字段最容易理解錯。第一個是 user 表里的 openid它來自微信登錄接口是用戶在小程序里的唯一標識不允許重復所以建了唯一索引。第二個是 goods 表的 images 字段類型是 VARCHAR(1024)說明它存的是圖片 URL 列表多張圖用逗號拼接而不是一張圖一行記錄這是畢設項目里最常見也最省事的做法。理解這一點對后面排查“圖片裂圖”很關鍵。訂單表和收藏表是交易閉環(huán)的核心。訂單表用來記錄一次交易從下單到成交的狀態(tài)變化收藏表記錄用戶和商品之間的“意向”關系-- 訂單表 CREATE TABLE orders ( id INT NOT NULL AUTO_INCREMENT COMMENT 訂單ID, order_no VARCHAR(32) NOT NULL COMMENT 訂單編號, goods_id INT NOT NULL COMMENT 商品ID, buyer_id INT NOT NULL COMMENT 買家ID, seller_id INT NOT NULL COMMENT 賣家ID, price DECIMAL(10,2) NOT NULL COMMENT 成交價, status TINYINT DEFAULT 0 COMMENT 0待付款 1待發(fā)貨 2待收貨 3已完成 4已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, deal_time DATETIME DEFAULT NULL COMMENT 成交時間, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單表; -- 收藏表 CREATE TABLE favorite ( id INT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL COMMENT 收藏用戶, goods_id INT NOT NULL COMMENT 商品, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_goods (user_id, goods_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT收藏表;訂單表里有個值得注意的細節(jié)它同時存了 buyer_id 和 seller_id 兩份用戶 ID。原因是二手交易的買賣雙方都可能是平臺上的任意用戶如果不冗余存下賣家 ID查詢“我賣出的訂單”就需要先查商品再關聯用戶多一次 JOIN畢設里直接用冗余字段能省很多事。收藏表的聯合唯一索引 uk_user_goods 保證同一用戶對同一個商品只能收藏一次這是防止重復收藏的關鍵約束。分類表和留言表相對簡單。分類表就是一組靜態(tài)數據手機數碼、家用電器、服飾鞋包、圖書教材、運動戶外、其他。留言表是買家對商品提問或議價的地方一個商品可以有多條留言所以外鍵指向 goods_id。留言表在演示環(huán)節(jié)很有用答辯時可以現場演示“提問-回復”的互動流程讓系統看起來不是一個靜態(tài)展示頁。2.3 導入源碼包前先做的三件事在動手導庫和啟動后端之前我會先花五分鐘做三件事能避免后面一半以上的報錯。第一件事是完整解壓用文本編輯器打開 SQL 文件先看一眼里面有沒有 CREATE DATABASE 語句。有的話說明腳本會自動建庫你只需要在 MySQL 里執(zhí)行它沒有的話就要手動先建一個空的數據庫再導入表結構。第二件事是確認本機環(huán)境。這類包一般要求 MySQL 5.7 或 8.0、JDK 1.8 或 11、微信開發(fā)者工具穩(wěn)定版。我一般在命令行里快速確認版本# 檢查本機 MySQL 版本 mysql --version # 檢查 Java 版本 java -version # 檢查 Node 版本如果是 Node 后端 node --version命令行輸出的版本和你后面要用的框架版本越接近跑通的概率越高。第三件事是找到后端配置文件提前把數據庫賬號密碼改成本機的。Java 項目在 application.yml 或 application.properties 里配置Node 項目通常在 config 目錄或 .env 文件里。這一步不提前做后面啟動后端一定報連接失敗而且報錯信息里只會說“Access denied”不會告訴你“密碼錯了”排查起來更費時間。3. 本地跑通全流程從建庫到小程序里看到商品3.1 導入數據庫執(zhí)行 SQL 的兩種方式與字符集注意點環(huán)境確認沒問題就開始導庫。這一步是整個流程里翻車率最高的一步絕大多數新手都在“執(zhí)行 SQL”這個動作上出了問題。先明確一點SQL 文件只是個文本需要 MySQL 服務真正運行起來它才能被執(zhí)行。如果你用集成的環(huán)境包先啟動 MySQL 服務如果單獨裝的 MySQL確認 Windows 服務或 Linux 下的 mysqld 進程在跑。導入方式有兩種我推薦新手用圖形化數據庫工具操作新建連接后右鍵數據庫選擇“運行 SQL 文件”選中 sql 目錄下的腳本等待執(zhí)行完成。如果腳本里沒有 CREATE DATABASE就提前新建一個名為 secondhand名字以包內腳本為準的數據庫再用。命令行方式其實也不難適合熟手快速操作# 登錄 MySQL 并導入整個腳本 mysql -u root -p secondhand sql/secondhand.sql這條命令的意思是用 root 用戶連接本機 MySQL把 secondhand.sql 文件里的 SQL 語句導入到名為 secondhand 的數據庫里。-p 參數會提示你輸入密碼就是本機 MySQL 的 root 密碼。執(zhí)行完沒有報錯說明表和索引都建好了。注意這里有個隱性要求數據庫 secondhand 必須已經存在否則命令會直接報錯這就是前面說“先看腳本里有沒有 CREATE DATABASE”的原因。導庫完成后建議順手驗證一下別急著啟動后端。在圖形工具里展開數據庫應該能看到 user、goods、orders、favorite、category、message 這些表另外可能還有幾張輔助表。打開 goods 表看數據如果里面已經插入了示例商品小程序首頁打開時就能立即看到商品列表這對后面排查問題非常有幫助。驗證完表結構再看一眼字符集。表結構和數據都導入成功不代表沒有隱患。檢查每個表的排序規(guī)則是不是 utf8mb4_general_ci 或 utf8mb4_unicode_ci如果有個別表是 latin1后面中文查詢可能出現亂碼或查不出來。最簡單粗暴的處理辦法是在導入前把 SQL 文件里所有 DEFAULT CHARSET 統一替換成 utf8mb4再執(zhí)行導入。3.2 啟動后端接口Java 項目的啟動方式與端口修改數據庫就緒后后端接口是第二個要跑起來的模塊。以最常見的 Spring Boot 工程為例前端小程序本身沒有能力直接讀數據庫所有商品列表、登錄、下單請求都要先發(fā)給后端后端再去查 MySQL最后把 JSON 返回給小程序。所以后端不啟動小程序打開必然是空白或報“請求失敗”。先改配置文件。打開 server 模塊下的 application.yml找到 spring.datasource 這一段把 url、username、password 改成本機 MySQL 的實際連接信息spring: datasource: url: jdbc:mysql://localhost:3306/secondhand?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密碼這段配置有三個關鍵參數。jdbc:mysql://localhost:3306/secondhand 指數據庫地址是本機的 3306 端口庫名是 secondhandcharacterEncodingutf8 保證中文不亂碼serverTimezoneAsia/Shanghai 解決 MySQL 8.0 和 Java 時區(qū)不一致導致的“時間相差 8 小時”問題。改完密碼保存用 IDEA 打開 server 目錄等待 Maven 依賴下載完成找到帶 main 方法的啟動類直接運行。后端啟動成功的標志是控制臺出現“Started Application in x.xxx seconds”的日志并且端口監(jiān)聽在 8080以實際配置為準?？吹饺罩竞笙炔灰蜷_小程序用瀏覽器或命令行直接訪問接口地址測試# 在命令行里測試商品列表接口 curl http://localhost:8080/api/goods/list如果返回的是 JSON 數組說明后端、數據庫、網絡三層都通了。如果返回 404先檢查接口路徑是不是 /api/goods/list如果返回 500去 IDE 控制臺看異常堆棧最常見的是數據庫連接失敗和 SQL 語句語法錯誤。這一步用 curl 驗證的意義在于把問題定位在后端而不是讓小程序來背鍋。后端還有個端口沖突的坑要提前說。如果你的本機已經跑過其他 Spring Boot 或 Tomcat 服務8080 端口可能被占用啟動日志里會報“Port already in use”。解決辦法是改端口在 application.yml 里加一行 server.port: 8081然后把小程序端請求地址里的端口也一起改成 8081。端口一致性是前后端聯調最容易忽略的細節(jié)我接手過的項目里有一半的“接口不通”是端口沒對上。3.3 小程序端配置測試號、請求地址、編譯預覽后端接口通了最后一步是把小程序前端在微信開發(fā)者工具里跑起來。打開微信開發(fā)者工具選擇“導入項目”目錄選解壓后的 miniprogram 文件夾AppID 可以直接用工具自帶的測試號不需要注冊真實的小程序賬號。這里要注意導入的是小程序前端目錄不是整個項目根目錄如果選錯了工具會提示找不到 app.json。導入完成后第一件事是修改請求地址。小程序端所有網絡請求都集中在 utils/request.js 里這類項目通常會在文件頂部定義 baseUrl// utils/request.js —— 統一請求封裝 const baseUrl http://localhost:8080 // 后端接口地址 function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: baseUrl path, method: method, data: data, header: { Content-Type: application/json // 登錄后可以在這里追加 token }, success(res) { // 后端約定返回 { code: 0, data: ... } 表示成功 if (res.data.code 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg || 請求失敗, icon: none }) reject(res.data) } }, fail(err) { wx.showToast({ title: 網絡異常, icon: none }) reject(err) } }) }) } module.exports { request, baseUrl }這段封裝的邏輯是所有接口統一走 request 函數避免每個頁面都寫一遍 wx.request 的完整配置。參數說明里最重要的是 header 對象登錄后后端會返回一個 token后續(xù)請求需要帶上它來識別身份一般在登錄成功的回調里把 token 寫入本地緩存然后在 request 里用 wx.getStorageSync(token) 動態(tài)塞進 header。如果你發(fā)現某個接口返回“未登錄”或 401先檢查這里是否真的帶了 token。改完 baseUrl直接點工具欄的“編譯”。如果一切正常模擬器里會看到首頁的商品列表點擊商品能進詳情底部導航能在首頁、分類、發(fā)布、消息、我的之間切換。到這里“從數據庫到小程序頁面”的完整鏈路就打通了。注意真機預覽有兩個前置要求——后端地址不能是 localhost手機訪問不到你的電腦且后端必須是 HTTPS或者你在開發(fā)者工具的本地設置里勾選了“不校驗合法域名”。開發(fā)階段用模擬器即可真機調試放到避坑章節(jié)細說。4. 核心業(yè)務邏輯走讀商品發(fā)布、搜索、訂單狀態(tài)流轉4.1 商品發(fā)布與圖片上傳從選擇圖片到 multipart 表單跑通之后讀業(yè)務代碼的順序我建議從“商品發(fā)布”看起因為它是整個系統里唯一涉及文件上傳的功能也是前后端配合最復雜的一條鏈路。發(fā)布頁的流程是填標題、選分類、填價格、寫描述、選圖片然后點發(fā)布按鈕。前端核心代碼長這樣// pages/publish/publish.js —— 發(fā)布商品 const { request, baseUrl } require(../../utils/request.js) Page({ data: { title: , price: , categoryId: 0, description: , images: [] }, chooseImage() { wx.chooseMedia({ count: 6, // 最多選6張 mediaType: [image], sourceType: [album, camera], success: (res) { const images res.tempFiles.map(item item.tempFilePath) this.setData({ images: this.data.images.concat(images) }) } }) }, uploadImages() { // 逐個上傳圖片全部成功后再提交表單 const tasks this.data.images.map(filePath { return new Promise((resolve, reject) { wx.uploadFile({ url: baseUrl /api/upload, filePath: filePath, name: file, success: (res) { const data JSON.parse(res.data) if (data.code 0) { resolve(data.url) // 收集后端返回的圖片URL } else { reject(new Error(data.msg)) } }, fail: reject }) }) }) return Promise.all(tasks) }, submit() { if (!this.data.title || !this.data.price) { wx.showToast({ title: 標題和價格必填, icon: none }) return } this.uploadImages().then(urls { request(/api/goods/add, POST, { title: this.data.title, price: this.data.price, categoryId: this.data.categoryId, description: this.data.description, images: urls.join(,) // 后端存逗號分隔的URL }).then(() { wx.showToast({ title: 發(fā)布成功, icon: success }) }) }) } })上面代碼里有幾個容易被新手忽略的設計點。chooseMedia 返回的 tempFilePath 只是微信臨時文件路徑只在當前小程序會話有效所以必須立刻上傳到后端不能直接拿來當商品圖片存庫。圖片是逐個上傳的Promise.all 等所有圖片上傳完成后再把 URL 拼接成逗號分隔字符串配合數據庫里 images 字段的 VARCHAR 類型。count 參數控制最多選 6 張這是二手交易場景里比較合理的上限太多張會讓詳情頁加載變慢。后端接收圖片的接口用 Spring Boot 實現的話核心是一個接收 MultipartFile 的接口。常見做法是把上傳的文件保存到服務器本地的一個 upload 目錄然后返回一個可訪問的 URL// UploadController.java —— 圖片上傳接口 RestController RequestMapping(/api) public class UploadController { // 配置文件里定義的上傳路徑例如 /usr/local/upload/ Value(${file.upload-path}) private String uploadPath; PostMapping(/upload) public MapString, Object upload(RequestParam(file) MultipartFile file) { // 用時間戳隨機數生成文件名避免重名覆蓋 String fileName System.currentTimeMillis() _ file.getOriginalFilename(); File dest new File(uploadPath, fileName); file.transferTo(dest); // 返回給前端的URL需要和靜態(tài)資源映射配合 return Map.of(code, 0, url, /files/ fileName); } }這個接口的關鍵參數是 RequestParam(file)它的 name 必須和小程序端 wx.uploadFile 里的 name 字段一致都是 file對不上后端會直接報“Required request part file is not present”。文件名用時間戳拼接是為了防止多個用戶上傳同名文件互相覆蓋這是開發(fā)階段最容易踩的坑。返回的 /files/xxx 只是相對路徑前端拿到后要拼上后端地址才能完整顯示所以還要在 Spring Boot 里配置靜態(tài)資源映射把 /files/** 指向本地的 upload 目錄否則圖片 404。4.2 搜索與分類篩選接口參數設計與分頁邊界商品列表頁是用戶進小程序后看到的第一個頁面也是搜索和分類的入口。這類項目最典型的設計是首頁頂部一個搜索框下面一排分類 tab再往下是商品瀑布流。對應的后端接口通常是一個支持多條件組合查詢的列表接口參數設計基本固定為 keyword、categoryId、page、size 四個。keyword 來自搜索框categoryId 來自分類 tabpage 和 size 控制分頁。后端 Service 層最常見的實現是用 MyBatis 動態(tài) SQL 拼接查詢條件!-- GoodsMapper.xml —— 搜索列表查詢 -- select idsearchGoods resultTypemap SELECT g.id, g.title, g.price, g.original_price, g.images, g.status, g.create_time, u.nickname, u.avatar FROM goods g LEFT JOIN user u ON g.user_id u.id where g.status 0 if testkeyword ! null and keyword ! AND g.title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null and categoryId ! 0 AND g.category_id #{categoryId} /if /where ORDER BY g.create_time DESC LIMIT #{offset}, #{size} /select這段 SQL 的核心在 標簽它能讓 MyBatis 根據是否傳入了 keyword 和 categoryId 自動拼條件不傳就只查 status0 的在售商品。注意 status0 是硬條件必須寫在動態(tài) if 之外否則下架和已售商品也會出現在搜索結果里。LIMIT 的兩個參數offset 是偏移量size 是每頁條數小程序端下拉加載時通過修改 page 來計算 offset。前端分頁的寫法我一般用一個統一的模式data 里維護 page、size、list、loading 四個字段onLoad 請求第一頁觸底事件請求下一頁// pages/index/index.js —— 列表加載與分頁 Page({ data: { list: [], page: 1, size: 10, total: 0, loading: false }, onLoad() { this.loadList(true) // 首次加載清空列表 }, loadList(isRefresh) { if (this.data.loading) return // 防止重復請求 this.setData({ loading: true }) request(/api/goods/list, GET, { page: this.data.page, size: this.data.size, keyword: this.data.keyword || , categoryId: this.data.categoryId || 0 }).then(res { const newList isRefresh ? res.list : this.data.list.concat(res.list) this.setData({ list: newList, total: res.total, loading: false }) }) }, onReachBottom() { if (this.data.list.length this.data.total) { wx.showToast({ title: 沒有更多了, icon: none }) return } this.setData({ page: this.data.page 1 }) this.loadList(false) } })分頁最大的坑在“沒有更多了”的判斷。total 是后端返回的總條數只有當已加載的 list.length 小于 total 時才允許加載下一頁。很多新手忽略這個判斷導致觸底一直請求最后一頁數據重復展示。還有一個細節(jié)loadList 開頭用 loading 標志位攔截重復請求是因為 onReachBottom 觸底事件觸發(fā)頻率很高不加這個標志位同一頁會被請求兩次。4.3 訂單狀態(tài)流轉買家、賣家兩個視角的狀態(tài)機訂單模塊是二手交易系統里最值得講清楚的部分。難點在于同一個訂單買家和賣家看到的狀態(tài)是不同的。比如買家點“確認收貨”后訂單狀態(tài)變成已完成賣家那邊要看到的是“交易完成”雙方視角必須對得上。下表是這類項目最常用的狀態(tài)設計狀態(tài)值買家視角賣家視角觸發(fā)動作0待付款等待買家付款買家提交訂單1待發(fā)貨待發(fā)貨買家完成支付演示環(huán)境常用模擬支付2待收貨已發(fā)貨賣家點擊發(fā)貨3已完成已完成買家點擊確認收貨4已取消已取消任意一方取消僅限狀態(tài) 0 和 1 時這張表的價值在于它明確了狀態(tài)的唯一來源訂單表里的 status 字段兩個視角只是對這個字段的不同文字解釋。寫代碼時不能給買家和賣家各維護一份狀態(tài)那必然導致數據不一致。前端的訂單列表頁通過判斷當前用戶是買家還是賣家把 status 映射成不同的文字和操作按鈕。狀態(tài)流轉的校驗邏輯后端通常用一組 if 判斷或者枚舉配合轉移表實現。判斷的關鍵是每個狀態(tài)只允許固定的幾個動作不合法的一律拒絕// OrderService.java —— 狀態(tài)流轉核心邏輯簡化 public void updateStatus(int orderId, int fromStatus, int toStatus, int userId) { // 1. 查訂單判斷用戶是否為買家或賣家 Order order orderMapper.findById(orderId); boolean isBuyer order.getBuyerId() userId; boolean isSeller order.getSellerId() userId; // 2. 校驗狀態(tài)是否合法 if (isBuyer fromStatus 2 toStatus 3) { // 買家確認收貨待收貨 - 已完成 orderMapper.updateStatus(orderId, 3); } else if (isSeller fromStatus 1 toStatus 2) { // 賣家發(fā)貨待發(fā)貨 - 已發(fā)貨 orderMapper.updateStatus(orderId, 2); } else { throw new RuntimeException(非法狀態(tài)流轉); } }這段代碼的核心思想是“狀態(tài)轉移必須顯式聲明”。fromStatus 和 toStatus 都明確寫出從哪到哪不允許出現待發(fā)貨直接跳到已完成這種跳變。實際項目里還會加上時間記錄比如發(fā)貨時間、成交時間這些字段在訂單表里都有對應的 DATETIME 列。如果你拿到手的源碼把狀態(tài)流轉邏輯散落在各個頁面里那是個危險信號說明改起來容易出并發(fā)問題。訂單模塊還有個繞不開的現實真實支付需要商戶號和支付資質畢設和大多數演示項目都不會接真實支付。常見做法是用一個“模擬支付”按鈕代替點擊后直接調用后端把訂單從 0 改成 1并彈出提示“演示環(huán)境未接入真實支付”。這個設計在答辯時一定要主動說明不然老師問“支付成功回調怎么處理的”會很尷尬。5. 二手交易小程序開發(fā)避坑指南5 個必踩的坑與排查路徑5.1 數據庫導入報錯 1064MySQL 版本語法不匹配現象用圖形工具或命令行導入 SQL 文件時報 ERROR 1064 (42000) You have an error in your SQL syntax報錯位置在某個建表語句的結尾。原因大多數源碼包的 SQL 文件是在 MySQL 8.0 環(huán)境下導出的里面可能帶上了 8.0 特有的排序規(guī)則如 utf8mb4_0900_ai_ci在 MySQL 5.7 上執(zhí)行就會語法報錯。解決先確認本機 MySQL 版本如果本機是 5.7用文本編輯器打開 SQL 文件把所有 utf8mb4_0900_ai_ci 全局替換成 utf8mb4_general_ci再重新導入。如果替換后還報錯定位到報錯行號把那一行單獨粘貼到查詢窗口逐句執(zhí)行通常能立刻看出是多了逗號還是少了分號。5.2 真機預覽請求不到接口合法域名與本地回環(huán)問題現象在開發(fā)者工具模擬器里一切正常商品列表、登錄都通一換成真機預覽就全部請求失敗控制臺報 request:fail。原因兩個問題疊加。第一開發(fā)階段后端跑在你自己電腦上地址是 localhost手機訪問 localhost 訪問的是手機自己根本到不了電腦第二真機上微信要求所有請求域名必須在后臺配置合法域名且必須是 HTTPSHTTP 的局域網地址必然被攔。解決如果是聯調階段最簡單的辦法是讓手機和電腦連同一個局域網把后端請求地址從 localhost 改成電腦的局域網 IP比如 http://192.168.1.5:8080同時在微信開發(fā)者工具的“詳情 → 本地設置”里勾選“不校驗合法域名”。注意這個選項只在開發(fā)版和體驗版里生效上線必須換成備案域名加 HTTPS。想省掉域名成本的話把后端遷到云開發(fā)是更干凈的方案后面進階章會講。5.3 圖片列表裂圖本地路徑與服務器路徑的邊界現象商品發(fā)布時圖片上傳成功數據庫里也能看到圖片 URL但首頁和詳情頁的圖片顯示不出來全部裂圖。原因最常見的是后端把圖片存到了服務器本地數據庫里存的是相對路徑如 /files/xxx.jpg前端拿到后直接拼在請求域名后面。如果后端沒有做靜態(tài)資源映射或者前端拼的域名端口不對圖片就訪問不到。另一種情況是開發(fā)階段數據庫里殘留了原作者機器上的絕對路徑比如 C:/Users/某個用戶/upload/xxx.jpg換到你機器上自然打不開。解決第一步確認后端是否配置了靜態(tài)資源映射Spring Boot 里實現 WebMvcConfigurer 把 /files/** 指向本機 upload 目錄第二步用瀏覽器直接訪問數據庫中存的完整 URL能打開說明后端沒問題問題在前端拼地址打不開就檢查映射路徑。第三步把數據庫里歷史圖片 URL 統一替換成你本機的訪問地址或者干脆清掉舊數據重新發(fā)布。5.4 接口一直返回 401登錄態(tài)過期與 token 丟失現象用戶剛登錄時一切正常過一會兒再點接口全部返回未登錄或 401。重新登錄又好了過一陣又失效。原因這類項目幾乎都用微信登錄獲取 openid再用 openid 查詢用戶生成一個自定義 token 存在后端。token 通常設置了過期時間比如 2 小時。前端這邊如果每次請求都從本地緩存里讀 token 并放到 header那問題多半出在 token 過期后沒有重新登錄的機制。解決在 request.js 封裝的響應處理里加一個 401 分支收到 401 后清空本地登錄態(tài)跳回登錄頁或者靜默調用 wx.login 重新登錄換取新 token。后端的 token 過期時間也可以適當拉長比如改成 7 天但畢設項目夠用就行。重點在“統一處理”不能在幾十個頁面里各寫一遍判斷不然漏掉一個就很難查。5.5 已售商品還在首頁展示列表接口漏了狀態(tài)過濾現象把某個商品標記為已售或下架后首頁和搜索列表里還能看到它點進去卻提示已被購買。原因列表接口的 SQL 里沒有把 status0 作為強制條件或者前端列表頁沒有傳任何狀態(tài)參數。這類源碼包的商品表里 status 字段是有設計的但接口層寫漏了把下架和已售狀態(tài)的商品也查出來了。解決找到后端商品列表查詢的 Mapper 或 SQL在查詢條件里加上 AND g.status 0并把商品詳情接口也做同樣處理——已售商品只能看詳情不能觸發(fā)購買。這個坑雖然小但它直接影響系統可信度答辯演示時被老師看到“已售商品還在首頁”是很掉分的事。6. 進階把跑通的 Demo 改造成能上線跑的版本6.1 三條低成本改造路徑云開發(fā)、HTTPS、云存儲項目跑通只是第一步如果目標是上線或者放到簡歷里展示三個改造點優(yōu)先級最高。第一是把后端和數據庫遷到微信云開發(fā)用云函數替代自建服務器用云數據庫替代 MySQL這樣免掉了域名備案和 HTTPS 證書配置是最省事的路徑。改造工作量不小因為要把所有 wx.request 換成云函數調用方式但換完后不再有本地回環(huán)和合法域名的困擾真機隨時能測。第二是圖片存儲遷到云存儲。本地磁盤存圖的方案在后端重啟或換機器后經常丟圖而云存儲返回的 URL 是公網可訪問的天然支持 HTTPS。改動范圍很小只動上傳接口那一塊。第三是如果堅持用自建服務器那就在服務器上配 Nginx給后端接口掛上 HTTPS 證書再把小程序后臺的合法域名填上正式域名。這三種路徑按開發(fā)成本和長期收益排序云開發(fā) 云存儲加自建后端 純自建加 HTTPS。6.2 上線前必須自查的清單改造成能跑只是上線前的及格線。我把這類二手交易項目上線前要過一遍的清單列在這里照著查就行。功能層注冊登錄流程是否支持靜默登錄失敗后的手動處理、商品發(fā)布是否校驗了必填項和圖片數量、訂單取消和超時未支付是否有兜底、買家和賣家雙方看到的狀態(tài)文案是否一致。安全層后端接口有沒有做登錄鑒權所有需要登錄才能調的接口是否都校驗了 token不能只攔了前端頁面。內容層是否做了敏感詞過濾用戶發(fā)布違規(guī)商品時有沒有舉報和下架通道。做完這些自查再回答兩個問題我的代碼里有沒有把數據庫密碼寫死在配置里并提交到公開倉庫有沒有在控制臺打印用戶手機號和 openid。這兩個問題任何一個沒處理好都比功能 bug 更致命。說一句我自己的習慣拿到任何源碼包第一件事不是讀業(yè)務代碼而是先把數據庫表結構畫出來再對著表去看接口。表結構能和業(yè)務閉環(huán)對上這個項目就值得花時間往下讀對不上后面改起來全是無底洞。這套二手交易項目的表設計六張表對應一個完整交易閉環(huán)已經算很規(guī)整的了。順著這個思路去改造你會比那些直接解壓跑通就交付的人走得遠得多。希望這篇能幫到你。本文還有配套的精品資源點擊獲取