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