基于微信的智能拍賣小程序計算機畢業(yè)設計源碼LW文檔——這個項目標題最近在畢業(yè)設計交流群里出現(xiàn)的頻率非常高。很多同學一看“拍賣”兩個字就打怵覺得又像電商又像金融其實把它拆開來看就是一個以拍賣流程為核心的微信小程序全棧項目前端負責展示和交互后端負責業(yè)務規(guī)則和數(shù)據(jù)沉淀再用一份LW文檔把整個設計和實現(xiàn)過程說清楚。這篇文章不打算復述那些官方項目介紹而是把我實際做過、也帶學生做過這類畢設項目的思路和踩坑記錄拿出來從需求拆解、數(shù)據(jù)庫設計到關鍵代碼實現(xiàn)再到答辯前需要注意的問題一步步過一遍希望對正在選題或者已經開工的你有點用。1. 項目概述與需求分析先搞清楚畢業(yè)設計到底在做什么1.1 核心需求拆解隨便搜一下“智能拍賣小程序”你能看到各種風格的版本有的主打一元起拍有的做奢侈品拍賣也有的做成二手閑置競拍。但不管外觀怎么變剝掉包裝之后核心需求永遠是同一套賣家和平臺發(fā)布拍品買家看中后繳納保證金參與出價最高出價者在截拍時間點勝出然后完成支付和訂單流轉。把這條主線拆成功能點落在一張需求清單上大概是這樣用戶端微信登錄、個人資料、拍品瀏覽與搜索、拍品詳情、保證金繳納、出價競拍、自動出價、訂單支付、出價記錄查看。管理端拍品上架與審核、拍賣場次安排、用戶管理、訂單管理、成交結算、公告發(fā)布。公共模塊圖片上傳、消息提醒、支付回調處理、異常狀態(tài)恢復。很多畢設論文里喜歡把功能寫成“用戶模塊、拍賣模塊、訂單模塊、后臺管理模塊”這種說法我不反對但答辯時老師更愿意看到你對“拍賣模塊”的規(guī)則細節(jié)有完整描述。比如起拍價怎么定、最小加價幅度怎么設計、最后幾秒有人出價要不要延時、流拍后怎么處理這些問題才是整篇論文的核心看點也是拉開檔次的地方。1.2 目標用戶與使用場景這個項目的主要目標用戶有兩類一類是參與競拍的普通微信用戶另一類是運營平臺的管理員。普通用戶的使用場景很典型在微信里打開小程序瀏覽當天正在進行的拍賣場次看到喜歡的拍品后先支付一筆保證金然后進入競拍大廳實時出價如果最終成交就去支付尾款。管理員的使用場景則更偏后臺配置拍品、設置起拍時間、監(jiān)控競拍過程、處理流拍和違規(guī)出價、導出訂單數(shù)據(jù)。畢設選題的時候我建議你可以把“場景故事”也寫進需求分析。例如“某用戶周末在閑逛時看到一件拍品起拍價很低但保證金要200元他猶豫了平臺應該怎么消除他的顧慮”這個問題的答案就是一副好設計拍品詳情頁展示完整的出價歷史、賣家信譽等級、保證金退還規(guī)則并且讓“繳納保證金”這個動作可以一鍵完成。把這些場景寫清楚論文的“需求分析”章節(jié)就不會顯得空洞。1.3 為什么選微信小程序而不是App現(xiàn)在做一個面向普通用戶的拍賣系統(tǒng)選微信小程序的理由非常充分。首先是獲客成本拍賣是低頻但高客單的交易用戶不可能為了偶爾拍一件東西專門去應用商店下一個App但小程序只要在微信里搜一下或者點一下分享鏈接就能打開。其次是支付閉環(huán)微信支付在小程序里的接入流程成熟用戶不需要跳出去綁卡登錄整體的轉化路徑短很多。第三是開發(fā)成本小程序前端用類似前端的語法就能做做畢設不需要準備iOS和Android兩套代碼一個人也能跑通全流程。當然小程序也有短板最明顯的就是包體積限制和部分原生能力的缺失但這些對拍賣場景來說不算致命后面我在實操部分會專門說怎么繞開。2. 系統(tǒng)架構與技術棧選型前端、后端、數(shù)據(jù)庫怎么分工2.1 技術棧全景我見過很多版本的小程序拍賣畢設技術棧五花八門有微信原生小程序配Java Spring Boot的有uniapp配Node.js的還有直接把后端寫成Python Flask的。從通用性出發(fā)我這里給你一套比較穩(wěn)妥的組合前端微信小程序原生框架WXML WXSS JavaScript。后端Spring Boot 2.x 或 3.x主要用 RESTful API 提供服務。數(shù)據(jù)庫MySQL 8.x數(shù)據(jù)以結構化表格為主。緩存與實時推送Redis緩存拍品狀態(tài)、處理并發(fā)加價鎖、WebSocket實時推送最高出價。對象存儲本地文件存儲配合 Nginx 靜態(tài)映射或者接入云存儲。部署單人畢設推薦采用前后端分離部署后端跑在云服務器上小程序通過 HTTPS 請求調用。為什么推薦原生小程序而不是uniapp對畢設來說原生框架的調試體驗更直接微信開發(fā)者工具里的報錯定位更準確而且教你的老師大概率也用過原生文檔。如果你之前已經熟悉Vue想用uniapp一稿多端也完全可以但注意 uni-app 打包小程序時經常遇到“source size 2612kb exceed max limit 2mb”的問題也就是主包超過2MB限制這時候需要做分包加載處理起來又多了一層工作。我的建議是時間緊就原生時間充裕且想跨端再上uniapp。2.2 前端模塊劃分小程序端的代碼結構建議按業(yè)務模塊來分目錄而不是按頁面類型堆在一起。一個比較清晰的做法是miniprogram/ ├── pages/ │ ├── index/ // 首頁拍品列表 │ ├── detail/ // 拍品詳情與競拍大廳 │ ├── login/ // 登錄授權 │ ├── user/ // 個人中心 │ ├── order/ // 訂單列表與詳情 │ ├── address/ // 收貨地址 │ └── feedback/ // 意見反饋 ├── components/ │ ├── countdown/ // 倒計時組件 │ ├── item-card/ // 拍品卡片 │ ├── bid-panel/ // 出價面板 │ └── empty-state/ // 空狀態(tài)占位 ├── utils/ │ ├── request.js // 封裝wx.request │ ├── auth.js // 登錄態(tài)管理 │ ├── config.js // 環(huán)境配置 │ └── format.js // 價格/時間格式化 └── app.js這里有個小細節(jié)值得注意倒計時組件不要每個頁面各自寫一遍單獨抽成組件之后首頁列表、詳情頁、競拍大廳都能共用后面如果要在出價按鈕上做“最后10秒禁止出價”這種規(guī)則也只需要改組件內部邏輯。2.3 后端模塊劃分與接口設計后端建議按領域拆分模塊而不是按傳統(tǒng)的Controller、Service、Mapper三層一刀切。拍賣場景下我比較習慣下面幾個模塊auth處理微信登錄、token簽發(fā)、用戶信息維護。item拍品管理、拍品上下架、圖片處理。auction拍賣場次控制、出價記錄、自動延時規(guī)則。order訂單生成、支付回調、退款處理。admin后臺管理接口包括拍品審核、數(shù)據(jù)統(tǒng)計。接口設計上正例是“POST /api/auction/{itemId}/bid”專門處理出價返回當前最高價和出價人昵稱“GET /api/auction/{itemId}/bids”拉取出價歷史“POST /api/auction/{itemId}/extend”處理延時規(guī)則。反例是把所有操作都塞進“POST /api/auction/doAction”這種萬能接口雖然前端寫著方便但后端邏輯會越來越難維護論文里也寫不出層次感。2.4 數(shù)據(jù)交互設計小程序和服務器之間的對話核心是 HTTPS JSON。前端所有請求都走一個統(tǒng)一封裝請求頭里帶上 token響應里做好統(tǒng)一錯誤處理。舉個例子封裝出價請求的時候不能只把 data 里的 price 傳過去還要帶上 itemId、時間戳、以及一個前端生成的請求序號用來防重復提交。這里我習慣在后端持久層給每個用戶每件拍品加一個唯一出價約束或者用 Redis 的 set 記錄本場已出價用戶這樣就算用戶瘋狂連點出價按鈕后端也能擋掉重復請求。3. 數(shù)據(jù)庫設計拍賣核心模型與建表思路3.1 核心表結構拍賣系統(tǒng)的數(shù)據(jù)模型比起普通電商要稍微復雜一點因為多了一個“競拍過程”的概念。普通商品下單是用戶直接付錢拍賣則是用戶先出價再根據(jù)結果生成訂單所以數(shù)據(jù)庫里除了用戶表、商品表、訂單表還一定要有出價記錄表和拍賣場次表。我建議至少設計六張核心表表名作用關鍵字段user用戶信息openid、昵稱、頭像、手機號、狀態(tài)auction_item拍品標題、描述、起拍價、最小加價、保留價、當前最高價、開始時間、結束時間、狀態(tài)auction_session拍賣場次場次名稱、開始時間、結束時間、狀態(tài)bid_record出價記錄拍品ID、用戶ID、出價金額、出價時間、出價類型order訂單訂單號、拍品ID、買家ID、成交價、支付狀態(tài)payment_log支付流水訂單號、支付方式、支付金額、回調狀態(tài)、交易號幾張關鍵表的建表 SQL可以直接照著改。用戶表的核心是 openid這個字段必須加唯一索引否則同一個微信號在你系統(tǒng)里注冊兩次就會出 bugCREATE TABLE user ( id bigint unsigned NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL, nickname varchar(64) DEFAULT , avatar_url varchar(255) DEFAULT , phone varchar(20) DEFAULT , status tinyint NOT NULL DEFAULT 1, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;拍品表的開始時間和結束時間我強烈建議存 datetime 類型別存 int 時間戳。原因有兩個第一你在小程序后端和數(shù)據(jù)庫之間調試時datetime 可以直接可讀不用每次轉換第二MySQL 對 datetime 的范圍和索引支持都足夠穩(wěn)查詢某天正在進行的拍賣場次一句WHERE auction_start_time NOW() AND auction_end_time NOW()就能搞定。3.2 出價記錄為什么要追加而不是修改這個點是我?guī)W生時反復強調的出價記錄表只能追加不能更新更不能覆蓋。拍賣和普通購物不一樣它要求整個過程可追溯。如果某個用戶出了1000元后來又出了一個1200元你直接把原來那條記錄改成1200元那么出價歷史就丟了買家沒辦法看到“誰在什么時間出了什么價”。如果出現(xiàn)糾紛比如最高價出價人聲稱自己沒出過這個價沒有歷史記錄系統(tǒng)根本說不清楚。正確做法是每次出價都 insert 一條新記錄然后注意處理并發(fā)時的金額校驗CREATE TABLE bid_record ( id bigint unsigned NOT NULL AUTO_INCREMENT, item_id bigint NOT NULL, user_id bigint NOT NULL, session_id bigint DEFAULT 0, bid_price decimal(10,2) NOT NULL, bid_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, bid_type tinyint NOT NULL DEFAULT 1 COMMENT 1手動 2自動, PRIMARY KEY (id), KEY idx_item_time (item_id, bid_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;3.3 狀態(tài)機設計從預告到流拍拍賣品的狀態(tài)變化是整個項目里最容易寫混亂的地方。我建議把拍品狀態(tài)定義成一個枚舉并且在數(shù)據(jù)庫里用 tinyint 存狀態(tài)流轉只在后端控制。一個比較完整的流轉關系是這樣的0草稿管理員上傳后還沒發(fā)布。1預告中已經發(fā)布但沒到開始時間用戶只能看不能出價。2競拍中可以出價。3已結束出價被鎖定等待結算。4已成交買家支付完成。5流拍沒有人出價或出價未達保留價。這里最容易犯的錯是有些人喜歡直接用“1表示上架0表示下架”一旦遇到拍賣這種多階段狀態(tài)后面對接訂單模塊時就得不斷補判斷條件代碼里到處都是 if status 1 或者 if status 2。提前把狀態(tài)機設計好不僅寫代碼舒服畫論文里的狀態(tài)圖也順手。4. 關鍵功能實現(xiàn)細節(jié)拍賣規(guī)則和實時交互4.1 倒計時與服務器時間同步拍賣系統(tǒng)最核心的視覺元素就是倒計時。很多項目做出來的效果看起來沒問題實際一到整點截拍就出事故原因很簡單小程序的倒計時用的是本地時間。用戶手機如果開了自動校時問題不大但一旦時區(qū)不對、或者用戶手動往后調了時間倒計時就亂了。正確的做法是倒計時展示依賴本地計算但用戶點擊出價按鈕時后端必須用服務器時間校驗拍賣是否已經結束。也就是說前端倒計時到達0的時候先別立刻展示“已截拍”而是先調一次后端查詢拍品狀態(tài)。具體實現(xiàn)上可以在后端提供一個獲取服務器時間的接口或者更簡單一點后端在每次返回拍品詳情時把serverTime一起帶過去前端根據(jù)服務端時間和結束時間計算剩余秒數(shù)。4.2 實時出價輪詢還是WebSocket實時出價是拍賣系統(tǒng)的技術難點也是答辯時老師最喜歡追問的地方。建議先明確一個觀點剛出價后的“實時”并不需要達到毫秒級用戶能接受的體驗是別人出價后1到2秒內當前最高價能刷新出來。對于畢設項目兩種方案都可行短輪詢前端每2秒請求一次“當前最高價和最新出價記錄”接口。實現(xiàn)簡單兼容性好服務器壓力在小項目下完全可接受。WebSocket后端推送出價消息前端實時更新。實現(xiàn)難度稍高但項目檔次明顯提升答辯時更有亮點。我的建議是如果后端用 Spring Boot可以直接上 WebSocket因為生態(tài)太成熟了加一個配置類就行。小程序的客戶端側要注意消息推送頻率不能太高后端可以做一下合并推送比如1秒內收到同一拍品的多次出價只推送最后一次結果。這樣能避免用戶手機在激烈競拍時瘋狂振動。4.3 “智能”拍賣的規(guī)則怎么設計標題里的“智能”兩個字是項目的加分項也是論文里可以重點包裝的部分。一套不錯的智能拍賣規(guī)則包含三個層面第一最小加價幅度。每次出價必須在當前最高價之上至少加一個最小加價幅度比如100元。這個規(guī)則不能只在前端校驗后端出價接口也必須校驗否則有人繞過前端直接調接口就能用1元優(yōu)勢搶到拍品。第二延時規(guī)則。常見做法是結束前最后30秒內如果有人出價則自動延長30秒。這是為了避免“最后一秒搶拍”的不公平行為。實現(xiàn)上很簡單每次成功出價后后端判斷當前時間距離結束時間是否小于30秒如果是就把結束時間更新為當前時間加30秒。第三代理出價。用戶可以設置一個心理最高價系統(tǒng)自動在當前最高價基礎上增加一手直到超過用戶的代理價為止。這個功能很能體現(xiàn)“智能”二字答辯時可以配合一個表格講清楚比如當前最高價1000元最小加價100元用戶代理價2000元這時別人出1100元系統(tǒng)自動幫用戶出1200元但只展示一次出價記錄。4.4 微信登錄與支付集成微信登錄的邏輯其實不復雜核心是 wx.login() 獲取 code然后后端用 code 換 openid。我這里特別提醒一個坑小程序端拿到的 code 是一次性的過期時間很短務必在拿到 code 后立刻傳給后端。有的同學把 code 存在全局變量里反復使用結果第二次請求就報錯。支付部分建議直接接微信支付但要區(qū)分兩種情況如果只是畢設展示可以用微信支付沙箱環(huán)境不產生真實資金如果希望真實可用則要走完整的商戶號申請流程。答辯時的加分點在于訂單生成和回調處理的冪等設計也就是同一筆訂單支付回調可能收到多次后端不能重復改狀態(tài)。5. 從零搭建到落地實操過程記錄5.1 開發(fā)環(huán)境準備開發(fā)這個項目需要安裝的工具和準備的東西不算多但每一步都要確認到位。我按順序列一下注冊一個微信小程序測試號耐心等待審核通過拿到 AppID。下載安裝微信開發(fā)者工具創(chuàng)建一個原生小程序項目填入 AppID。后端開發(fā)工具直接用 IntelliJ IDEA 或 Eclipse安裝 Maven 和 JDK。安裝 MySQL 8.x 和 RedisRedis 在 Windows 下可以用 WSL 跑或者用 Docker 起一個容器。第一次在微信開發(fā)者工具里打開項目時很多人會卡在“不在以下合法域名列表”這個報錯。小程序上線前所有請求域名都必須是 HTTPS 并且在后臺配置好。本地開發(fā)階段可以在開發(fā)者工具的本地設置里勾選“不校驗合法域名”但上線前一定要記得關掉。5.2 小程序端核心頁面開發(fā)頁面開發(fā)的重點是首頁拍品列表和拍品詳情競拍大廳。首頁列表推薦用兩個組件的組合scroll-view實現(xiàn)下拉刷新和觸底加載配合onReachBottom事件做分頁。這里有一個經驗列表數(shù)據(jù)不要在 onLoad 里一次性加載完定義一個pageNum和pageSize每次觸底時 pageNum 加1請求下一頁數(shù)據(jù)接口返回的數(shù)據(jù)為空時展示“沒有更多了”并標記一個hasMorefalse。拍品詳情頁則要處理好競拍狀態(tài)的展示邏輯。拍賣開始前顯示“距開始還有xx秒”拍賣進行中顯示倒計時和出價按鈕拍賣結束后顯示“已結束”或者成交價格。這里要注意用戶停留在詳情頁時倒計時要走定時器但是頁面切到后臺時比如用戶看了會兒微信消息定時器會被小程序掛起。處理方式是頁面onShow時重新拉取拍品狀態(tài)不要依賴一個一直在跑的定時器。5.3 后端接口與聯(lián)調后端接口建議按功能分批開發(fā)第一批先做登錄和拍品查詢第二批做出價和倒計時邏輯第三批再處理訂單支付。每完成一個接口就先用 Postman 測一遍確認返回格式正確后再接小程序。這個習慣能讓你少掉很多頭發(fā)。出價接口的關鍵實現(xiàn)要點我寫一段偽代碼你可以看懂思路后用自己的語言改造PostMapping(/api/auction/{itemId}/bid) public Result bid(PathVariable Long itemId, RequestBody BidRequest request) { // 1. 校驗拍品是否存在、狀態(tài)是否為競拍中 AuctionItem item itemService.getById(itemId); if (item.getStatus() ! AuctionStatus.RUNNING) { return Result.error(拍賣尚未開始或已結束); } // 2. 服務端校驗時間不能信任客戶端的倒計時 if (LocalDateTime.now().isAfter(item.getEndTime())) { return Result.error(拍賣已結束); } // 3. 加鎖防止并發(fā)出價覆蓋 boolean locked redisLock.tryLock(bid:item: itemId, 5, TimeUnit.SECONDS); if (!locked) { return Result.error(系統(tǒng)繁忙請重試); } // 4. 校驗出價金額 當前最高價 最小加價 BigDecimal currentPrice item.getCurrentPrice(); if (request.getPrice().compareTo(currentPrice.add(item.getMinIncrement())) 0) { return Result.error(出價低于最低加價幅度); } // 5. 插入出價記錄并更新當前最高價 bidService.insert(itemId, userId, request.getPrice()); itemService.updateCurrentPrice(itemId, request.getPrice()); // 6. 處理延時規(guī)則 if (item.getEndTime().isBefore(LocalDateTime.now().plusSeconds(30))) { itemService.extendEndTime(itemId, LocalDateTime.now().plusSeconds(30)); } redisLock.release(bid:item: itemId); return Result.ok(); }這里的具體細節(jié)如果你用的是 MyBatis-Plusupdate 時最好用樂觀鎖也就是給拍品表的version字段加上Version這樣并發(fā)請求進來時后一個請求會因為版本號對不上而更新失敗再走重試就不會出現(xiàn)兩個人同時認為自己是最高價的情況。5.4 LW文檔撰寫建議LW文檔是畢業(yè)設計里另一大塊工作量很多同學都低估了它的難度。寫的時候要注意幾點選題背景不要假大空直接說明拍賣行業(yè)線下流程效率低、信息不透明因此需要線上化需求分析和數(shù)據(jù)庫設計部分要能和你寫的代碼對應上別只畫概念圖最后在系統(tǒng)測試部分至少寫出三個完整的測試用例包括正常出價、超出最大加價幅度非法出價、最后幾秒出價觸發(fā)延時這三種場景老師看到這種具體的測試描述印象分會好很多。文檔里涉及的功能模塊圖和流程圖我建議用 Visio 或在線繪圖工具畫導出成高清 PNG不要用截圖糊弄。所有圖表和代碼示例要保持編號一致這個檢查在打印之前一定要做一遍。6. 常見問題與排查技巧實錄6.1 列表頁“加載更多”偶爾不生效首頁拍品列表用觸底加載時最典型的癥狀是第一次翻頁正常翻到第三頁后就沒反應了。排查思路是先看控制臺請求如果觸底事件根本沒觸發(fā)檢查onReachBottom頁面配置是不是頁面滾動的根元素不是 page如果請求發(fā)出了但接口返回的數(shù)據(jù)是重復的第一頁那說明pageNum在頁面翻頁時被重置了大概率是你在頁面 onLoad 里重新置了 pageNum1而 onReachBottom 里也改了同一個變量兩者發(fā)生了競態(tài)。6.2 自定義導航欄高度適配問題如果項目用了自定義導航欄頂部按鈕在不同機型上會出現(xiàn)錯位。問題根源是不同手機的膠囊按鈕位置和狀態(tài)欄高度不一樣。獲取高度建議用官方提供的方式在 app.js 的 onLaunch 里讀取wx.getMenuButtonBoundingClientRect()和wx.getSystemInfoSync()把狀態(tài)欄高度和膠囊按鈕位置存到全局變量自定義導航欄的樣式都基于這兩個值動態(tài)計算。注意 iPhone 靈動島機型的狀態(tài)欄高度比普通機型高不能寫死。6.3 WebSocket 斷線重連接入 WebSocket 后另一個高頻問題是用戶鎖屏、切后臺、或者網(wǎng)絡切換時連接會斷開。處理辦法是頁面 onShow 時主動檢查連接狀態(tài)斷了就重連重連成功后拉取一次當前拍品狀態(tài)用服務端數(shù)據(jù)覆蓋本地可能已經過期的狀態(tài)。另外小程序對 WebSocket 同時存在的連接數(shù)有限制跳轉頁面時記得在 onHide 里關閉當前連接不然可能報連接數(shù)超出上限。6.4 支付回調掉單和并發(fā)超賣掉單是支付環(huán)節(jié)最常見的問題。用戶付了錢小程序端顯示支付成功但后臺訂單還是“待付款”。原因一般是回調地址沒有設置為外網(wǎng)可訪問或者回調處理邏輯里有異常沒有捕獲。我的經驗是回調處理接口一定要做日志記錄回調失敗時要能通過日志反查。后端處理邏輯要做成冪等的收到回調后先查本地訂單如果已經是“已支付”就直接返回成功不重復處理。并發(fā)超賣問題則是出價環(huán)節(jié)特有的處理辦法就是我在出價接口里寫的 Redis 鎖加數(shù)據(jù)庫樂觀鎖兩層保險。鎖的鍵名規(guī)則建議按拍品粒度是 itemId不是用戶ID這樣才能保證同一件商品的出價請求串行執(zhí)行。6.5 真機預覽與體驗版分發(fā)開發(fā)完小程序后不要只在開發(fā)者工具里點一遍就完事。建議在項目成員里添加幾個微信號然后通過“體驗版”二維碼分發(fā)出去讓周圍人用真機試用幾天收集反饋。真機預覽經常暴露出兩類問題一類是之前提到的自定義導航欄錯位另一類是部分安卓機型上圖片加載不出需要檢查圖片鏈接是否是 HTTPS 且在小程序后臺配置了 downloadFile 合法域名。7. 個人實操心得與避坑清單項目做到最后代碼能跑、文檔能交只是及格線。我比較看重的加分項是拍賣規(guī)則是否有細節(jié)數(shù)據(jù)是否可追溯異常情況是否考慮完整。這三個點都在前面每一節(jié)里反復出現(xiàn)過因為它們才是決定一個系統(tǒng)能不能真正上線運轉的關鍵。最后分享一個我自己帶項目時常用的開發(fā)節(jié)奏第一階段不要碰支付和自動出價只做用戶登錄、拍品列表、詳情頁、手動出價先把主流程跑通第二階段再加入倒計時、保證金和自動出價第三階段才處理支付和后臺管理。三個階段每完成一個就提交一次代碼并且寫一段版本說明。這樣就算最后時間不夠你至少有一個能演示的核心版本不至于交一個半成品上去。