“中國剪紙微信小程序 SSM”這個組合光看名字就知道是典型的校園項目配置前端用小程序的輕量入口后端老老實實上 Spring SpringMVC MyBatis 三件套題材又自帶文化氣息。但真上手做的時候你會發(fā)現(xiàn)它遠(yuǎn)不止“增刪改查”那么輕松——圖片內(nèi)容在小程序里的加載體驗、微信登錄的會話保持、后臺管理權(quán)限、訂單狀態(tài)流轉(zhuǎn)每一環(huán)都有隱藏坑。這篇文章我就按實際開發(fā)順序把從需求拆解、表結(jié)構(gòu)設(shè)計到后端接口編碼、小程序端聯(lián)調(diào)的關(guān)鍵節(jié)點全捋一遍重點寫那些代碼以外、但真能決定你項目能不能順利跑起來的東西。1. 項目定位與技術(shù)方案的取舍1.1 為什么總是“微信小程序 SSM”先說結(jié)論這個組合能成為畢業(yè)生項目里的?？筒煌耆且驗榧夹g(shù)老舊而是因為它踩在了一個很合適的平衡點上。小程序端解決了“用戶怎么訪問”的問題。不用下載 App掃碼即用分享也方便特別適合剪紙這種偏向文化展示和內(nèi)容瀏覽的場景。你做一個剪紙作品展示和購買的小程序用戶看完一幅剪紙作品覺得有意思可以直接分享給朋友這個傳播鏈路是原生 App 很難比的。后端選 SSM 而不是 Spring Boot更多是課程和教學(xué)體系的原因。很多學(xué)校課程還停留在 SpringMVC MyBatis 的講授階段要求學(xué)生用這套框架完成項目。不過從實際開發(fā)角度講SSM 并沒有過時到不能用的程度配置雖然繁瑣一點但正是因為配置是顯式的你對請求處理鏈路、事務(wù)管理、MyBatis 的 mapper 映射反而理解得更清楚。用這類框架做完一個完整項目再回頭看 Spring Boot基本是降維打擊。1.2 用戶端和管理端的邊界劃分這樣的系統(tǒng)一般拆成兩個端小程序端做用戶操作后臺管理端做內(nèi)容運維。小程序端核心功能圍繞“看”和“買”展開首頁輪播圖 推薦剪紙作品列表分類頁按剪紙流派、地區(qū)、用途篩選作品作品詳情多圖展示、創(chuàng)作說明、作者信息、價格收藏與購物車用戶先收藏或加購再統(tǒng)一結(jié)算個人中心個人信息、我的訂單、收貨地址管理端通常是 Web 界面負(fù)責(zé)作品管理上傳剪紙圖片、填寫標(biāo)題、簡介、價格、庫存分類管理維護(hù)剪紙分類的樹形結(jié)構(gòu)訂單管理查看訂單、更新發(fā)貨狀態(tài)輪播圖管理配置首頁 Banner用戶管理查看注冊用戶列表我見過不少項目把管理端做得很敷衍只留幾個后端接口沒有實際頁面。這種項目演示的時候很吃虧答辯老師隨便打開一個頁面看到空白印象分直接拉低。所以管理端哪怕用簡單的 JSP Bootstrap 也要把能點的入口都做出來。1.3 剪紙內(nèi)容的數(shù)據(jù)特征決定了系統(tǒng)側(cè)重點剪紙作品有一個很突出的數(shù)據(jù)特征圖片是絕對主角文字只是輔助。一幅剪紙作品的美感、精細(xì)程度、刀工細(xì)節(jié)全部依賴高清圖片來傳遞。所以這個項目不能像普通商品系統(tǒng)那樣把圖片當(dāng)成附帶字段處理。你需要考慮圖片的存儲位置、訪問路徑、多圖展示順序、縮略圖尺寸這些都是影響用戶體驗的關(guān)鍵點。另外剪紙本身有很強(qiáng)的文化和分類屬性。按地域分有蔚縣剪紙、高密剪紙、佛山剪紙按用途分有窗花、禮花、鞋花按風(fēng)格分有傳統(tǒng)寫實和現(xiàn)代創(chuàng)新。如果分類字段設(shè)計得不合理后期用戶搜索和篩選會很吃力。2. 數(shù)據(jù)庫設(shè)計先定表再寫代碼2.1 用戶表與微信登錄態(tài)的設(shè)計用戶表是整個系統(tǒng)的地基。和普通注冊登錄不同微信小程序一般用微信授權(quán)登錄不需要用戶輸入用戶名密碼。關(guān)鍵字段大概是CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL UNIQUE, nickname VARCHAR(64), avatar_url VARCHAR(255), phone VARCHAR(20), gender TINYINT, create_time DATETIME, update_time DATETIME );這里的核心是 openid它是微信用戶在當(dāng)前小程序下的唯一標(biāo)識。用戶首次進(jìn)入小程序前端調(diào)用 wx.login 拿到 code后端拿 code 換 openid如果 openid 不存在就自動注冊。千萬不要讓用戶先填一遍注冊表單再登錄那和原生 App 時代的體驗沒有區(qū)別在小程序場景里會勸退大量用戶。至于登錄后的會話保持推薦的做法是后端生成一個自定義 token 返回給前端前端存到 storage 里后續(xù)請求在 header 里帶上 token。不要每次請求都拿 code 換 session微信接口有頻率限制而且 code 是一次性的。2.2 作品表與分類表的設(shè)計作品表是內(nèi)容系統(tǒng)的重頭戲。常見的表結(jié)構(gòu)CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, parent_id INT DEFAULT 0, sort_order INT DEFAULT 0 ); CREATE TABLE artwork ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, title VARCHAR(100) NOT NULL, cover_image VARCHAR(255) NOT NULL, images TEXT, description TEXT, price DECIMAL(10,2), stock INT DEFAULT 0, view_count INT DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME, update_time DATETIME, KEY idx_category (category_id), KEY idx_status (status) );有幾個細(xì)節(jié)值得注意images字段用 TEXT 存 JSON 字符串如[/upload/1.jpg, /upload/2.jpg, /upload/3.jpg]避免專門為多圖建一張子表。這在圖片數(shù)量不多、不需要復(fù)雜查詢的前提下效率和簡單性都是最優(yōu)解。單獨存一個cover_image封面字段列表頁只加載封面不加載詳情大圖響應(yīng)速度會快很多。view_count瀏覽量字段一定要留。雖然現(xiàn)在看著沒用但后期做“熱門剪紙推薦”時它就是最直接的排序依據(jù)。status字段做上下架控制管理員下架的作品不要直接刪保留在庫里才是正常業(yè)務(wù)邏輯。2.3 收藏、購物車與訂單表收藏表最簡單兩個外鍵搞定CREATE TABLE favorite ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, artwork_id INT NOT NULL, create_time DATETIME, UNIQUE KEY uk_user_artwork (user_id, artwork_id) );購物車表也類似區(qū)別是增加數(shù)量字段。訂單表稍微復(fù)雜一點至少要拆成訂單主表和訂單明細(xì)表CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id INT NOT NULL, total_amount DECIMAL(10,2), status TINYINT DEFAULT 0, receiver_name VARCHAR(50), receiver_phone VARCHAR(20), receiver_address VARCHAR(255), create_time DATETIME, update_time DATETIME ); CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, artwork_id INT NOT NULL, title VARCHAR(100), cover_image VARCHAR(255), price DECIMAL(10,2), quantity INT DEFAULT 1 );訂單表里的receiver_name、receiver_phone、receiver_address這幾個字段是普通商品流程必須的從哪里來從小程序端的收貨地址表單采集后寫入。如果你的需求里沒有做真實物流地址可以填在訂單備注里但字段最好還是保留方便后續(xù)擴(kuò)展。說到這里必須吐槽一個常見設(shè)計錯誤很多同學(xué)把訂單狀態(tài)設(shè)計成一長串?dāng)?shù)字0、1、2、3、4 分別代表待付款、待發(fā)貨、待收貨、已完成、已取消。這種設(shè)計本身沒問題但要寫清楚狀態(tài)枚舉和流轉(zhuǎn)條件。我在下面的章節(jié)專門展開講。2.4 索引和外鍵的取舍在 SSM 項目里很多人因為建表的時候貪圖省事不建索引等數(shù)據(jù)量跑到一定規(guī)模查詢就卡。雖然畢設(shè)數(shù)據(jù)量一般不大但建立正確的索引是好習(xí)慣user 表的 openid 必須唯一索引否則微信登錄會有隱患o(jì)rders 表的 order_no 唯一索引favorite 表的 user_id artwork_id 聯(lián)合唯一索引防止用戶重復(fù)收藏artwork 表的 category_id、status 建普通索引分類篩選和上下架過濾會用到外鍵方面我個人的做法是不在數(shù)據(jù)庫層面強(qiáng)制外鍵約束而是通過代碼邏輯保證一致性。理由很簡單外鍵會影響插入和刪除性能而且在 SSM 項目里一旦操作順序不小心外鍵約束報錯會讓整個事務(wù)管理變得復(fù)雜。項目里靠 service 層控制邏輯就夠了。3. SSM 后端實現(xiàn)代碼結(jié)構(gòu)和關(guān)鍵接口3.1 Maven 工程結(jié)構(gòu)一個清晰的工程結(jié)構(gòu)比多寫一百行業(yè)務(wù)代碼更重要。我習(xí)慣的分包方式src/main/java ├── com.example.cutpaper │ ├── controller │ ├── service │ │ ├── impl │ ├── mapper │ ├── entity │ ├── common │ │ ├── Result.java │ │ ├── PageResult.java │ │ └── TokenInterceptor.javacontroller 只做參數(shù)接收和響應(yīng)封裝service 里寫業(yè)務(wù)邏輯mapper 放 MyBatis 接口。很多剛?cè)腴T的同學(xué)喜歡把 SQL 直接寫在 controller 里圖省事但后期維護(hù)會特別痛苦。換一個查詢條件就要動 controller而且沒法做單元測試。pom.xml 核心依賴大致是dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.2.15.RELEASE/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version3.5.9/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.0.7/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.27/version /dependency雖然 SSM 配置繁瑣但別用那些能自動生成配置的工具手動寫一遍 spring-mvc.xml、spring-mybatis.xml、web.xml你才能真正理解請求是怎么從 tomcat 走到 controller 再到 service 再落到數(shù)據(jù)庫的。這個過程雖然枯燥卻是很多 Spring Boot 工程師補(bǔ)不上的課。3.2 統(tǒng)一返回結(jié)構(gòu)讓前端少踩一半坑如果你打算把后端接口提供給小程序端聯(lián)調(diào)第一件事就是約定一個統(tǒng)一返回結(jié)構(gòu)。我常用的格式{ code: 200, message: success, data: {} }對應(yīng)的 Java 類public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }前端拿到響應(yīng)后只判斷code是不是 200 就夠了不需要針對不同接口寫不同的錯誤解析邏輯。自定義錯誤碼還可以約定401 表示未登錄、403 表示無權(quán)限、500 表示服務(wù)器異常。這樣排查問題的時候掃一眼 code 就知道是哪一層出了問題。3.3 作品分頁查詢接口作品列表頁一般是小程序的主要頁面接口設(shè)計成GET /api/artwork/list?page1size10categoryId2keyword窗花Service 層調(diào)用 MyBatis 的 PageHelper 或者其他分頁方式返回一個包含總條數(shù)和當(dāng)前頁數(shù)據(jù)的結(jié)構(gòu)。這里需要注意如果用了 PageHelper分頁必須緊跟在執(zhí)行查詢前調(diào)用中間不能有其它 SQL 操作。因為 PageHelper 是基于 ThreadLocal 實現(xiàn)的一旦線程被線程池復(fù)用而上下文沒有清理分頁參數(shù)可能會串到下一次查詢上這是一個非常隱蔽的坑。當(dāng)年我在聯(lián)調(diào)的時候遇到列表頁和數(shù)據(jù)對不上查了半天才發(fā)現(xiàn)是 PageHelper 使用位置不對導(dǎo)致分頁失效。Mapper XML 里寫動態(tài) SQL按傳入條件拼接 where 子句select idselectArtworkPage resultTypecom.example.cutpaper.entity.Artwork SELECT * FROM artwork where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND title LIKE CONCAT(%, #{keyword}, %) /if AND status 1 /where ORDER BY create_time DESC /select動態(tài) SQL 是 MyBatis 的靈魂where標(biāo)簽會自動處理第一條件前面的 AND省掉很多糾結(jié)。判斷條件時categoryId用! null而不是! 數(shù)字類型直接判空keyword字符串判空要兩個條件都寫。3.4 微信登錄接口與攔截器微信小程序登錄的邏輯不復(fù)雜但很多同學(xué)在“誰來換取 openid”這個問題上想不清楚。正確流程是小程序端wx.login()獲取臨時 code前端把 code 發(fā)給后端后端拿 code appid secret 請求微信接口獲取 openid后端根據(jù) openid 查用戶表不存在就自動創(chuàng)建后端生成 token 返回給前端服務(wù)端代碼大致是PostMapping(/api/login) public Result login(RequestBody LoginRequest req) { String url https://api.weixin.qq.com/sns/jscode2session? appid appid secret secret js_code req.getCode() grant_typeauthorization_code; String result HttpUtil.get(url); JSONObject json JSON.parseObject(result); String openid json.getString(openid); User user userMapper.findByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); userMapper.insert(user); } String token UUID.randomUUID().toString().replace(-, ); // 存 token 到 Redis 或內(nèi)存 Map return Result.ok(token); }注意幾個點appid 和 secret 不能寫在小程序前端代碼里secret 一旦暴露就是安全事故。必須放后端由后端去調(diào)微信接口。換 openid 的接口是jscode2session注意不要和獲取 access_token 的接口搞混。返回的 openid 對于每個用戶是固定的但對每個小程序是隔離的。也就是說同一個用戶在不同小程序下 openid 不同。有了 token 之后寫一個 HandlerInterceptor 做登錄校驗把白名單接口放行其他接口都檢查 header 里的 token。這里容易踩的坑是放行路徑寫錯比如/api/login和/api/artwork/list必須放行但/api/user/**、/api/order/**必須攔截。如果正則寫得不仔細(xì)很可能出現(xiàn)所有接口都被攔截然后小程序端瘋狂報 401 的尷尬局面。3.5 圖片上傳與靜態(tài)資源映射剪紙系統(tǒng)的圖片上傳是核心功能。管理端上傳剪紙圖片時后端接收 MultipartFile保存到服務(wù)器的指定目錄然后把圖片的相對路徑存到數(shù)據(jù)庫里。Upload 接口關(guān)鍵邏輯PostMapping(/api/admin/upload) public Result upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(400, 文件為空); } String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); String fileName UUID.randomUUID().toString() suffix; String filePath uploadDir / fileName; file.transferTo(new File(filePath)); return Result.ok(/upload/ fileName); }文件名一定要用 UUID 重新生成不要用原名。原因有兩個一是中文文件名在 URL 拼接時容易亂碼二是重名文件會互相覆蓋。另外還要給 SpringMVC 配置靜態(tài)資源映射讓/upload/**可以訪問服務(wù)器磁盤上的文件mvc:resources mapping/upload/** locationfile:/your/absolute/path/upload//這里有一個非常經(jīng)典的坑Linux 服務(wù)器上路徑寫的是/usr/local/uploadWindows 本地調(diào)試時路徑就得換成D:/upload。很多同學(xué)在本地跑得好好的部署到服務(wù)器上圖片全部顯示不出來十有八九就是這個靜態(tài)資源映射路徑的問題。建議把路徑配置放在 properties 文件里部署時單獨維護(hù)一份配置不要寫死。4. 小程序端實現(xiàn)從頁面到聯(lián)調(diào)4.1 請求封裝和前端環(huán)境小程序端開發(fā)第一步絕對不是寫頁面而是把請求工具封裝好。在 utils/request.js 里統(tǒng)一處理 baseURL、token、響應(yīng)狀態(tài)碼和錯誤提示const BASE_URL http://localhost:8080; function request(url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, token: wx.getStorageSync(token) || }, success(res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { wx.navigateTo({ url: /pages/login/login }); reject(res.data); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 網(wǎng)絡(luò)異常, icon: none }); reject(err); } }); }); }這里有個容易被忽略的點微信開發(fā)者工具的“不校驗合法域名”選項默認(rèn)是關(guān)閉的但開發(fā)的時候你訪問的是http://localhost:8080屬于不合法域名必須在開發(fā)者工具里勾選“不校驗合法域名、web-view業(yè)務(wù)域名、TLS 版本以及 HTTPS 證書”。如果你提交上線就必須把后端域名改成備案過的 HTTPS 域名并在小程序后臺配置合法域名白名單。4.2 首頁輪播圖與推薦列表首頁是我前面說的“看”的核心通常布局是頂部輪播圖 下方推薦剪紙作品列表。輪播圖從后端接口拉取配置的 Banner 列表每張圖包含 image 路徑和跳轉(zhuǎn)鏈接。這里踩過坑的是Banner 里的 image 路徑存的是相對路徑如/upload/banner1.jpg前端請求圖片時必須拼上 BASE_URL 才能顯示。很多同學(xué)圖片加載不出來原因就是請求頁面時數(shù)據(jù)用的是相對路徑而wx.previewImage預(yù)覽大圖時又必須用絕對路徑兩者對不上。推薦列表我用的是作品分頁查詢接口側(cè)重數(shù)據(jù)加載體驗。列表用onReachBottom觸發(fā)下一頁加載每頁 10 條。每次加載前判斷isLoading狀態(tài)防止重復(fù)請求加載完判斷hasMore決定是否繼續(xù)顯示“加載更多”。這里還有一個容易被忽視的性能優(yōu)化點小程序頁面渲染大量圖片時如果圖片尺寸過大會非?？ā＝鉀Q方案是圖床或后端按需生成縮略圖也可以在前端用modewidthFix固定寬度等比縮放。對于單張圖大小超過 1MB 的建議用 CDN 或者在上傳時壓縮。剪紙作品的細(xì)節(jié)圖本來就大如果不做壓縮用戶滑兩頁就會感到明顯卡頓。4.3 分類頁與搜索交互分類頁一般用左側(cè)一級分類列表、右側(cè)二級分類內(nèi)容布局。點擊左側(cè)分類右側(cè)展示對應(yīng)分類下的作品。分類接口設(shè)計成兩級結(jié)構(gòu)返回[ { id: 1, name: 按地區(qū), children: [ { id: 11, name: 蔚縣剪紙 }, { id: 12, name: 高密剪紙 } ] } ]這里比較容易出的 bug 是分類數(shù)據(jù)量大的時候左側(cè)滾動和右側(cè)滾動互相影響。建議左右各用獨立 scroll-view并設(shè)置好高度和 scroll-y避免整頁滾動導(dǎo)致體驗混亂。搜索框放在分類頁頂部輸入關(guān)鍵詞調(diào)作品接口的 keyword 參數(shù)。需要注意防抖用戶輸入太快你不希望每個字符都觸發(fā)一次請求。簡單做法是 setTimeout 500ms 后再請求期間清掉上一個定時器。4.4 收藏、購物車與訂單流程收藏功能在小程序端很簡單點擊心形圖標(biāo)就調(diào)收藏/取消收藏接口。但這里要處理一個狀態(tài)問題用戶未登錄時點收藏會被攔截器攔截返回 401前端就應(yīng)該跳轉(zhuǎn)登錄頁。購物車與訂單的流程是加購 → 選擇商品結(jié)算 → 填寫收貨信息 → 提交訂單 → 支付。對于 SSM 項目很多畢設(shè)沒有接入真實微信支付因為微信支付需要企業(yè)主體、商戶號、證書等一系列材料個人開發(fā)者和測試號很難跑通。因此常見的做法是“模擬支付”用戶點擊提交訂單后進(jìn)入支付頁面點擊“模擬支付”按鈕直接把訂單狀態(tài)從待付款改成待發(fā)貨。這種做法的好處是業(yè)務(wù)邏輯完整演示時也能順暢走完整個鏈路。但要注意以后接真實微信支付時只需要在生產(chǎn)環(huán)境的提交訂單接口后面加一步“調(diào)用微信統(tǒng)一下單 API 獲取支付參數(shù)”前端拿到參數(shù)后再調(diào)wx.requestPayment喚起支付面板。支付成功回調(diào)里更新訂單狀態(tài)即可整個訂單模塊不用大改。我之前幫別人改過一個項目結(jié)果發(fā)現(xiàn)它的訂單提交接口里寫死了status為已支付而且沒有保留回調(diào)接口的位置。后來接真實支付時不得不重寫創(chuàng)建訂單、支付回調(diào)、狀態(tài)更新三個接口工作量翻了一倍。所以就算你現(xiàn)在不接真實支付也要把接口設(shè)計成“創(chuàng)建訂單 → 獲取支付參數(shù) → 支付回調(diào)”的三段式結(jié)構(gòu)狀態(tài)流轉(zhuǎn)留給后續(xù)擴(kuò)展。5. 聯(lián)調(diào)階段的高頻問題與排查思路5.1 小程序請求連不上后端這個問題出現(xiàn)頻率最高現(xiàn)象是接口狀態(tài)碼 404 或 500或者直接顯示“網(wǎng)絡(luò)異常”。排查步驟建議按順序來先用 Postman 或瀏覽器訪問后端接口確認(rèn)接口本身是否正常確認(rèn)小程序開發(fā)工具里的 “不校驗合法域名” 已勾選確認(rèn)后端的 IP 和端口可以被外部訪問localhost只在本機(jī)生效真機(jī)調(diào)試時要改成電腦的局域網(wǎng) IP后端如果是 Linux 服務(wù)器檢查防火墻和云服務(wù)商的安全組規(guī)則8080 端口是否放行有一點要提醒如果你在開發(fā)者工具里用的是http://localhost:8080那么手機(jī)預(yù)覽時這個地址指向的是手機(jī)本身而不是你的電腦。很多同學(xué)在電腦上測試沒問題手機(jī)掃碼預(yù)覽發(fā)現(xiàn)接口全部失敗就是因為這個原因。正確做法是電腦跑起來后查一下本機(jī)局域網(wǎng) IP把 baseURL 改成http://192.168.x.x:8080手機(jī)和電腦連同一個 WiFi 再試。5.2 登錄態(tài)丟失與 token 失效這個問題的復(fù)現(xiàn)場景很典型用戶在小程序里登錄后切到后臺再回來看頁面顯示要重新登錄。首先要檢查前端請求封裝里token 是否從 storage 取出并放進(jìn) header。其次看后端攔截器的規(guī)則——有些接口在 token 過期后返回 401前端收到 401 后跳轉(zhuǎn)登錄頁這是正常邏輯。但如果 token 明明沒過期接口全部 401那就是攔截器放行路徑配置的問題。另外要注意 token 存儲位置的坑小程序wx.setStorageSync存的是本地的切換環(huán)境比如開發(fā)版切到體驗版時 storage 不一定共享會出現(xiàn)“明明登錄過但還是未登錄”的錯覺。這種時候清一下緩存一般能解決屬于環(huán)境切換的常見假象。5.3 圖片顯示不出來圖片不顯示的原因基本就三類數(shù)據(jù)庫存的路徑和實際文件位置不一致靜態(tài)資源映射配置錯誤前端圖片 src 拼錯 BASE_URL排查時先打開瀏覽器直接訪問圖片 URL看能不能請求到。如果 404檢查后端上傳目錄里有沒有這個文件如果有文件檢查 SpringMVC 靜態(tài)資源映射是否指向正確目錄。因為是兩個系統(tǒng)小程序端和后端之間的路徑拼接建議在后端返回數(shù)據(jù)時存入的鏈接字段直接返回完整路徑前端不用再拼從根上杜絕少拼漏拼的問題。5.4 數(shù)據(jù)庫中文亂碼中文亂碼通常是字符集不統(tǒng)一導(dǎo)致的。一共有四層字符集數(shù)據(jù)庫連接 URL、MySQL 表結(jié)構(gòu)、Tomcat 請求編碼、響應(yīng)編碼。數(shù)據(jù)庫連接 URL 強(qiáng)制指定編碼jdbc.urljdbc:mysql://localhost:3306/cutpaper?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai建表時統(tǒng)一DEFAULT CHARSETutf8mb4。MySQL 5.7 以上建議用 utf8mb4它兼容表情符號免得用戶昵稱帶 emoji 輸入時報錯。另外要在 web.xml 里配置 SpringMVC 的字符編碼過濾器filter filter-nameencodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter這一步配置如果漏了前端提交中文數(shù)據(jù)到后端大概率亂碼。而且這個是屬于“不報錯但讓人抓狂”的坑排查起來特別費時間。5.5 攔截器誤傷和接口白名單SSM 項目里攔截器配錯了比控制器報錯更難受。有個朋友的項目所有接口請求都正常返回數(shù)據(jù)唯獨wx.login也返回 401我在幫他排查的時候發(fā)現(xiàn)攔截器配置里放行路徑只寫了/login而前端實際請求的是/api/login路徑對不上登錄請求被攔截器攔下來了。放行路徑不是越多越好也不是越少越好。我的建議是用/api/login和/api/artwork/**、/api/category/**、/upload/**作為白名單其他接口一律做登錄校驗。這個規(guī)則既保證數(shù)據(jù)安全也給了前端足夠的瀏覽空間未登錄用戶可以看作品和分類但下單、收藏、個人中心必須登錄。5.6 數(shù)據(jù)庫連接和事務(wù)管理很多 SSM 項目跑一段時間后會報Connection is not available, request timed out這是因為沒有配置連接池大小和超時時間。在 spring-mybatis.xml 里配置 DBCP 或 HikariCP 時把maxTotal設(shè)置成 20 或 30maxWaitMillis設(shè)置成 10000基本能滿足一般場景。事務(wù)管理也值得留意。創(chuàng)建訂單時要在 service 方法上加Transactional注解保證訂單主表和訂單明細(xì)表同時寫入、同時回滾。如果漏掉事務(wù)創(chuàng)建訂單主表成功后明細(xì)表寫入失敗會出現(xiàn)個“空訂單”用戶端看到訂單點進(jìn)去空無一物后臺訂單統(tǒng)計也會對不上賬。這種問題在演示時被老師問起來非常尷尬。6. 部署、源碼利用與后期擴(kuò)展方向6.1 拿到源碼之后怎么快速跑起來不管從哪拿到一套 SSM 小程序源碼第一件事不是打開代碼而是先檢查環(huán)境。我建議按下面順序操作裝 JDK 1.8 和 Maven 3.6不要用 JDK 11 以上跑 SSM 老項目很多老依賴不兼容裝 MySQL 5.7導(dǎo)入項目提供的 SQL 腳本修改jdbc.properties里的數(shù)據(jù)庫賬號密碼在 IDEA 里 import 為 Maven 項目等待依賴下載完配置 Tomcat 8.5部署后啟動用 Postman 先測一個簡單接口確認(rèn)后端通用微信開發(fā)者工具導(dǎo)入小程序前端項目修改 request.js 里的 baseURL這里最坑的是 Maven 依賴下載慢。國內(nèi)環(huán)境建議在settings.xml中配置阿里云鏡像源否則等十分鐘下載進(jìn)度還是 0%。另外老的 SSM 項目經(jīng)常會有依賴沖突比如 servlet-api 和 tomcat 自帶版本沖突控制臺報java.lang.NoSuchMethodError。解決方法是把 pom.xml 里scope提供范圍的依賴排掉或者統(tǒng)一依賴版本。6.2 剪紙類小程序的差異化優(yōu)化方向如果做完基礎(chǔ)功能還想加點亮點我建議從三個方向考慮。第一個是搜索體驗?；A(chǔ)系統(tǒng)一般只支持按標(biāo)題模糊搜索你可以擴(kuò)展成按作者、流派、地區(qū)標(biāo)簽搜索甚至支持拼音首字母檢索。數(shù)據(jù)量小的話用 SQLLIKE就行數(shù)據(jù)量大再考慮全文索引或引入 Elasticsearch但這個對畢設(shè)沒有必要。第二個是展示層優(yōu)化。剪紙這類藝術(shù)品展示質(zhì)感決定用戶停留時間。可以給詳情頁加多圖查看、雙指縮放、全屏預(yù)覽列表頁用瀑布流布局讓圖片高度錯落有致視覺上更有文藝感。小程序原生的grid布局做不出來那種氛圍需要手動計算每張圖的高度百分比。第三個是社區(qū)化功能。比如用戶給剪紙作品留言、點贊、分享做成一個輕量的“文化社區(qū)”。這個方向聽著高級代碼層面其實還是在做書評系統(tǒng)的那套邏輯容易實現(xiàn)也容易在答辯時講出亮點。6.3 代碼安全和內(nèi)容合規(guī)提醒開發(fā)歸開發(fā)有兩點還是要相當(dāng)注意。第一不要在小程序前端暴露任何后端敏感配置尤其是數(shù)據(jù)庫密碼、API 密鑰、secret 等。前端代碼是可能被反編譯查看的這類信息泄露出去不只是項目安全問題更涉及合規(guī)責(zé)任。第二項目涉及圖片素材時要注意版權(quán)問題。剪紙圖片盡量用自己拍攝的、從版權(quán)圖庫購買授權(quán)的或者明確授權(quán)免費使用的素材。特別是如果系統(tǒng)有用戶上傳功能要在前端加圖片上傳的審核機(jī)制后端也要對上傳圖片做格式和內(nèi)容校驗避免不合適的圖片流入正式環(huán)境。7. 這個項目后續(xù)還能怎么擴(kuò)展最后聊點我實際做這類文化展示項目時的體會。剪紙這種題材做小程序有個天然優(yōu)勢內(nèi)容輸出的門檻低、分享意愿高。一般商品小程序用戶看了就走但文化活動內(nèi)容用戶會愿意轉(zhuǎn)發(fā)甚至主動收藏。做產(chǎn)品的人常說內(nèi)容產(chǎn)品要靠“鉤子”剪紙作品背后的故事、創(chuàng)作過程、地方民俗這些都能成為讓用戶反復(fù)打開小程序的理由。如果以后想把這個項目做成真正能上線的產(chǎn)品我建議在兩個方向上下工夫。一是數(shù)字藏品類的玩法每幅經(jīng)典剪紙不僅有商品介紹還有編號、創(chuàng)作者、背后的故事用戶收藏的不只是一張圖片而是一種文化記憶。二是和線下場景打通剪紙展、非遺手作課程、材料包購買小程序完全可以承擔(dān)從內(nèi)容種草到消費轉(zhuǎn)化再回到內(nèi)容沉淀的閉環(huán)。從技術(shù)角度看這些擴(kuò)展無非是再增加幾個模塊和幾張表但產(chǎn)品價值就完全不一樣了。我也是踩了不少坑才把這類項目理順的。最深的體會是不要小看“文化展示 電商 小程序”這種組合它的難點不在技術(shù)本身而在內(nèi)容、數(shù)據(jù)、業(yè)務(wù)狀態(tài)這三者的關(guān)系是否能梳理清楚。把表結(jié)構(gòu)設(shè)計好、接口規(guī)范約定好、前后端聯(lián)調(diào)環(huán)境統(tǒng)一好項目基本就成功了八成。剩下的兩成就是反復(fù)跑流程、查日志、補(bǔ)邊界情況的時間。希望這篇分享能幫你少走點彎路。