簡介這份資源是面向Android初學(xué)者與移動(dòng)應(yīng)用開發(fā)練習(xí)者的同城物流派送系統(tǒng)項(xiàng)目源碼圍繞城市內(nèi)快速配送場景完整呈現(xiàn)從訂單發(fā)起到司機(jī)搶單、再到貨物送達(dá)的業(yè)務(wù)閉環(huán)可用于學(xué)習(xí)SQLite數(shù)據(jù)存儲(chǔ)、賬號(hào)注冊(cè)登錄、自定義適配器列表展示、搶單與派送狀態(tài)流轉(zhuǎn)以及GPS定位與路線規(guī)劃等典型模塊的實(shí)現(xiàn)思路。壓縮包共275個(gè)文件約53.42MB以94個(gè)png界面素材、86個(gè)class編譯文件、39個(gè)xml布局與配置、31個(gè)java源碼為主另含9個(gè)jar依賴、5個(gè)so庫及apk安裝包等兼顧源碼閱讀與直接運(yùn)行體驗(yàn)。目前已有323人學(xué)習(xí)下載。讀者可從中獲得一套結(jié)構(gòu)完整的項(xiàng)目參考對(duì)照數(shù)據(jù)庫增刪改查、用戶認(rèn)證與適配器數(shù)據(jù)綁定等環(huán)節(jié)理解Android應(yīng)用的組織方式適合作為課程設(shè)計(jì)或畢業(yè)設(shè)計(jì)的實(shí)踐藍(lán)本。1. 同城物流派送系統(tǒng)拆解一個(gè) SQLite 單文件撐起整套調(diào)度邏輯同城物流派送這類項(xiàng)目最容易被做復(fù)雜訂單表、騎手表、路線表、狀態(tài)機(jī)、結(jié)算流水一上來就上 MySQL 加 Redis本地跑個(gè) Demo 還得先裝服務(wù)、配賬號(hào)、開端口。我這次拆的這份資源走的是另一條路——整套派送調(diào)度邏輯壓在一個(gè) SQLite 單文件里訂單落庫、騎手狀態(tài)流轉(zhuǎn)、派單匹配、軌跡點(diǎn)記錄全在一個(gè).db文件內(nèi)完成拷走就能跑換臺(tái)機(jī)器不用改一行連接配置。它解決的是中小規(guī)模同城配送場景下「數(shù)據(jù)量不大但事務(wù)一致性要求不低」的問題適合想快速驗(yàn)證派單算法、做課程設(shè)計(jì)、或者給門店做輕量調(diào)度工具的從業(yè)者。SQLite 在這里不是妥協(xié)是選型。2. 數(shù)據(jù)模型與派單狀態(tài)機(jī)先把表設(shè)計(jì)對(duì)后面少改三次代碼拿到這類資源我一般不看界面先看表結(jié)構(gòu)。同城派送的復(fù)雜度八成壓在數(shù)據(jù)模型上訂單從創(chuàng)建到簽收要經(jīng)過哪些狀態(tài)、騎手接單后訂單和騎手怎么綁定、派單失敗怎么回滾這些想不清楚后面每加一個(gè)功能都要?jiǎng)颖?。這份資源的表設(shè)計(jì)不算多但把關(guān)鍵關(guān)系收住了值得先講透再動(dòng)手。2.1 四張核心表與它們的外鍵關(guān)系資源里的核心表大致是四張訂單表orders、騎手表couriers、派單記錄表assignments、軌跡點(diǎn)表track_points。訂單表存收貨地址經(jīng)緯度、期望時(shí)段、當(dāng)前狀態(tài)騎手表存當(dāng)前位置、載單上限、在線狀態(tài)派單記錄表是訂單和騎手的多對(duì)多橋接帶派單時(shí)間和結(jié)果軌跡點(diǎn)表按時(shí)間戳追加騎手位置。關(guān)鍵設(shè)計(jì)點(diǎn)在assignments這張橋接表它沒有把courier_id直接塞進(jìn)orders而是單獨(dú)記錄每一次派單嘗試包括失敗的那次。這個(gè)選擇很關(guān)鍵——同城派送里「派了但騎手拒單」是高頻事件如果只在訂單表上掛一個(gè)騎手字段拒單后歷史就丟了事后排查「這單為什么繞了三圈才派出去」沒有依據(jù)。橋接表讓每次嘗試都留痕代價(jià)是多一次 join。-- 訂單表狀態(tài)用整數(shù)枚舉避免字符串比較 CREATE TABLE orders ( id INTEGER PRIMARY KEY AUTOINCREMENT, pickup_lat REAL NOT NULL, pickup_lng REAL NOT NULL, drop_lat REAL NOT NULL, drop_lng REAL NOT NULL, status INTEGER NOT NULL DEFAULT 0, -- 0待派 1已派 2取貨中 3配送中 4已簽收 5已取消 created_at INTEGER NOT NULL, -- Unix 秒統(tǒng)一時(shí)區(qū) expect_start INTEGER, -- 期望送達(dá)時(shí)段起點(diǎn) expect_end INTEGER ); -- 派單記錄每次嘗試一行失敗也留痕 CREATE TABLE assignments ( id INTEGER PRIMARY KEY AUTOINCREMENT, order_id INTEGER NOT NULL REFERENCES orders(id), courier_id INTEGER NOT NULL REFERENCES couriers(id), result INTEGER NOT NULL, -- 0待響應(yīng) 1接受 2拒單 3超時(shí) assigned_at INTEGER NOT NULL, responded_at INTEGER ); CREATE INDEX idx_assign_order ON assignments(order_id); CREATE INDEX idx_assign_courier ON assignments(courier_id, result);上面這段建表語句里有兩個(gè)參數(shù)值得說。status用整數(shù)而不是文本是因?yàn)?SQLite 沒有原生枚舉文本狀態(tài)在批量更新時(shí)容易拼錯(cuò)且索引效率低整數(shù)配合應(yīng)用層常量最穩(wěn)。created_at和expect_start統(tǒng)一存 Unix 秒而不是文本時(shí)間是為了后面算「距離期望時(shí)段還有多久」時(shí)能直接做減法不用在 SQL 里調(diào)日期函數(shù)——SQLite 的日期函數(shù)跨時(shí)區(qū)處理是玄學(xué)能避開就避開。兩個(gè)索引分別服務(wù)「查某訂單的派單歷史」和「查某騎手當(dāng)前有效單」這兩個(gè)查詢?cè)谂蓡窝h(huán)里會(huì)被高頻調(diào)用。2.2 狀態(tài)流轉(zhuǎn)與事務(wù)邊界狀態(tài)機(jī)是這類系統(tǒng)最容易翻車的地方。訂單狀態(tài)從 0 到 4 是一條單向鏈但取消5可以從任意前置狀態(tài)進(jìn)入騎手拒單則要把訂單從 1 退回 0。這份資源把狀態(tài)變更全部收在一個(gè)函數(shù)里不允許業(yè)務(wù)代碼直接UPDATE orders SET status這個(gè)約束我認(rèn)可。import sqlite3 # 合法狀態(tài)遷移當(dāng)前狀態(tài) - 允許的下一狀態(tài)集合 TRANSITIONS { 0: {1, 5}, # 待派 - 已派 / 取消 1: {2, 0, 5}, # 已派 - 取貨中 / 退回待派(拒單) / 取消 2: {3, 5}, # 取貨中 - 配送中 / 取消 3: {4, 5}, # 配送中 - 已簽收 / 取消 4: set(), # 終態(tài) 5: set(), } def change_status(conn, order_id, new_status): cur conn.cursor() cur.execute(SELECT status FROM orders WHERE id?, (order_id,)) row cur.fetchone() if row is None: raise ValueError(forder {order_id} not found) old row[0] if new_status not in TRANSITIONS.get(old, set()): raise ValueError(fillegal transition {old} - {new_status}) cur.execute( UPDATE orders SET status? WHERE id? AND status?, (new_status, order_id, old), # 帶舊狀態(tài)做樂觀鎖 ) if cur.rowcount ! 1: raise RuntimeError(concurrent status change detected) conn.commit()這段代碼的邏輯說明先查當(dāng)前狀態(tài)用TRANSITIONS字典校驗(yàn)遷移合法性非法遷移直接拋錯(cuò)而不是靜默忽略——靜默忽略是血淚經(jīng)驗(yàn)線上出問題時(shí)你根本不知道哪一步被吞了。UPDATE語句里帶AND status?是樂觀鎖防止兩個(gè)并發(fā)請(qǐng)求同時(shí)把訂單從 1 改到 2 和 0rowcount不等于 1 就說明有人搶先改了拋錯(cuò)讓上層重試。參數(shù)上conn由調(diào)用方傳入而不是函數(shù)內(nèi)新建是為了讓多個(gè)狀態(tài)變更能包在同一個(gè)事務(wù)里如果你要一次改多張表把commit提到外層。提示SQLite 默認(rèn)的isolation_level是隱式事務(wù)Python 的sqlite3模塊在 DML 前會(huì)自動(dòng)開事務(wù)。上面代碼里顯式commit是必要的但如果你在外層已經(jīng)開了事務(wù)這里的commit會(huì)提前提交需要改成由外層統(tǒng)一控制。2.3 派單匹配的 SQL 寫法派單的核心查詢是「找一批在線、未滿載、距離取貨點(diǎn)最近的騎手」。這份資源沒有上空間索引用的是經(jīng)緯度平方差近似排序在同城幾公里范圍內(nèi)誤差可以接受。-- 候選騎手在線、載單未滿、按到取貨點(diǎn)距離平方升序 SELECT c.id, (c.lat - :pickup_lat) * (c.lat - :pickup_lat) (c.lng - :pickup_lng) * (c.lng - :pickup_lng) AS dist2 FROM couriers c WHERE c.online 1 AND c.load_count c.max_load AND c.id NOT IN ( SELECT courier_id FROM assignments WHERE order_id :order_id AND result IN (1, 0) -- 已接受或待響應(yīng) ) ORDER BY dist2 ASC LIMIT 5;邏輯說明dist2是距離平方省掉開方排序結(jié)果和真實(shí)距離一致但快一點(diǎn)。NOT IN子查詢排除掉已經(jīng)對(duì)這筆訂單接受或待響應(yīng)的騎手避免重復(fù)派給同一個(gè)人。LIMIT 5是候選池大小實(shí)際派單時(shí)按順序逐個(gè)發(fā)請(qǐng)求前一個(gè)拒單再試下一個(gè)。參數(shù):pickup_lat這類命名占位符比?可讀性好Python 里用字典傳參即可。注意load_count是冗余字段每次接單要同步加一這個(gè)一致性靠應(yīng)用層保證SQLite 沒有觸發(fā)器約束的話容易漏——這是后面避坑章要展開的點(diǎn)。3. 從零跑通派單閉環(huán)建庫、灌數(shù)據(jù)、模擬一輪調(diào)度表設(shè)計(jì)講完接下來是讓它動(dòng)起來。這一章按「建庫 → 灌測(cè)試數(shù)據(jù) → 跑一輪派單 → 看結(jié)果」的順序走每一步都能直接抄。我一般會(huì)先造一批假數(shù)據(jù)把閉環(huán)跑通再談優(yōu)化不然連狀態(tài)流轉(zhuǎn)對(duì)不對(duì)都驗(yàn)證不了。3.1 初始化數(shù)據(jù)庫與 PRAGMA 調(diào)優(yōu)SQLite 默認(rèn)配置偏保守同城派送這種寫多讀也多的小系統(tǒng)開庫時(shí)設(shè)幾個(gè) PRAGMA 能明顯減少鎖等待。import sqlite3 def open_db(pathdispatch.db): conn sqlite3.connect(path, timeout5.0) cur conn.cursor() cur.execute(PRAGMA journal_modeWAL;) # 讀寫不互斥 cur.execute(PRAGMA synchronousNORMAL;) # 兼顧安全與速度 cur.execute(PRAGMA foreign_keysON;) # 外鍵約束默認(rèn)是關(guān)的 cur.execute(PRAGMA busy_timeout5000;) # 鎖等待 5 秒 conn.commit() return conn參數(shù)說明journal_modeWAL讓讀操作不被寫操作阻塞派單循環(huán)里一邊寫派單記錄一邊查騎手列表不開 WAL 會(huì)頻繁database is locked。synchronousNORMAL在 WAL 模式下已經(jīng)足夠安全比默認(rèn)FULL快不少代價(jià)是極端斷電可能丟最后一個(gè)事務(wù)——同城派送場景可以接受。foreign_keysON必須顯式開SQLite 默認(rèn)不校驗(yàn)外鍵不開的話assignments里能插進(jìn)不存在的order_id臟數(shù)據(jù)就是這么來的。busy_timeout是等鎖的超時(shí)設(shè) 5 秒比默認(rèn)立即報(bào)錯(cuò)友好。3.2 灌入模擬訂單與騎手測(cè)試數(shù)據(jù)要覆蓋邊界有騎手滿載、有騎手離線、有訂單在期望時(shí)段邊緣。下面這段造 20 個(gè)騎手、50 個(gè)訂單坐標(biāo)在一個(gè)虛構(gòu)城區(qū)的矩形范圍內(nèi)隨機(jī)。import random, time def seed(conn, n_couriers20, n_orders50): cur conn.cursor() now int(time.time()) for i in range(n_couriers): cur.execute( INSERT INTO couriers(lat,lng,online,load_count,max_load) VALUES(?,?,?,?,?), (30.0 random.random(), 120.0 random.random(), 1 if random.random() 0.2 else 0, # 兩成離線 0, random.choice([2, 3, 4])), ) for i in range(n_orders): cur.execute( INSERT INTO orders(pickup_lat,pickup_lng,drop_lat,drop_lng,status,created_at,expect_start,expect_end) VALUES(?,?,?,?,0,?,?,?), (30.0 random.random(), 120.0 random.random(), 30.0 random.random(), 120.0 random.random(), now, now 1800, now 3600), ) conn.commit()邏輯說明online用random.random() 0.2讓約兩成騎手離線是為了驗(yàn)證派單查詢的WHERE online1真的生效。max_load在 2 到 4 之間隨機(jī)制造滿載邊界。訂單的expect_start設(shè)在 30 分鐘后、expect_end在 1 小時(shí)后方便后面測(cè)「臨近超時(shí)優(yōu)先派」的邏輯。坐標(biāo)范圍是虛構(gòu)的實(shí)際用時(shí)換成你所在城區(qū)的經(jīng)緯度矩形即可。3.3 跑一輪派單并核對(duì)結(jié)果派單主循環(huán)的邏輯是取待派訂單按期望時(shí)段緊迫度排序?qū)γ繂尾楹蜻x騎手逐個(gè)嘗試成功則更新訂單和騎手。def dispatch_round(conn): cur conn.cursor() cur.execute(SELECT id,pickup_lat,pickup_lng FROM orders WHERE status0 ORDER BY expect_end ASC) orders cur.fetchall() for oid, plat, plng in orders: cur.execute( SELECT c.id FROM couriers c WHERE c.online1 AND c.load_count c.max_load AND c.id NOT IN (SELECT courier_id FROM assignments WHERE order_id? AND result IN (0,1)) ORDER BY (c.lat-?)*(c.lat-?)(c.lng-?)*(c.lng-?) ASC LIMIT 5 , (oid, plat, plat, plng, plng)) candidates [r[0] for r in cur.fetchall()] for cid in candidates: try: cur.execute(BEGIN) cur.execute(INSERT INTO assignments(order_id,courier_id,result,assigned_at) VALUES(?,?,0,?), (oid, cid, int(time.time()))) cur.execute(UPDATE orders SET status1 WHERE id? AND status0, (oid,)) if cur.rowcount ! 1: raise RuntimeError(order taken) cur.execute(UPDATE couriers SET load_countload_count1 WHERE id? AND load_countmax_load, (cid,)) if cur.rowcount ! 1: raise RuntimeError(courier full) conn.commit() break except Exception: conn.rollback() continue邏輯說明外層按expect_end升序越臨近超時(shí)的訂單越先派。內(nèi)層對(duì)每個(gè)候選騎手開一個(gè)事務(wù)插入派單記錄、改訂單狀態(tài)、加騎手載單數(shù)三步要么全成要么全回滾。UPDATE orders ... AND status0和UPDATE couriers ... AND load_countmax_load都帶條件rowcount校驗(yàn)是并發(fā)下的后悔藥——兩個(gè)派單線程同時(shí)處理同一單或同一騎手時(shí)第二個(gè)會(huì)失敗并回滾。參數(shù)上LIMIT 5控制候選池太大浪費(fèi)查詢太小可能派不出去5 是個(gè)經(jīng)驗(yàn)值。跑完一輪后查SELECT status, COUNT(*) FROM orders GROUP BY status就能看到派出去多少、還剩多少待派。4. 避坑與排查SQLite 派送系統(tǒng)最容易翻車的五個(gè)點(diǎn)這套東西跑通不難難的是跑穩(wěn)。下面五條是我在類似項(xiàng)目里真實(shí)踩過或見別人踩過的按「現(xiàn)象 → 原因 → 解決」寫遇到對(duì)應(yīng)癥狀直接對(duì)號(hào)入座。4.1 現(xiàn)象派單循環(huán)跑幾百單后報(bào)database is locked原因沒開 WAL或者開了 WAL 但多個(gè)連接同時(shí)寫。SQLite 同一時(shí)刻只允許一個(gè)寫者派單循環(huán)里如果每個(gè)訂單都新開連接寫鎖競爭會(huì)非常激烈。另一個(gè)常見原因是事務(wù)沒及時(shí)提交長事務(wù)占著寫鎖。解決開庫時(shí)統(tǒng)一走open_db()設(shè)journal_modeWAL和busy_timeout整個(gè)派單循環(huán)復(fù)用同一個(gè)連接不要每單新建事務(wù)粒度控制在「一單一次」別把整輪派單包成一個(gè)大事務(wù)。如果確實(shí)要多線程寫操作串行化讀可以并發(fā)。4.2 現(xiàn)象騎手load_count和實(shí)際有效單數(shù)對(duì)不上原因load_count是冗余字段接單時(shí)加一、簽收或取消時(shí)減一漏了任何一處就會(huì)漂移。最常見的是訂單取消時(shí)忘了減或者拒單回滾時(shí)減了兩次。解決不要靠人工記增減點(diǎn)寫一個(gè)對(duì)賬函數(shù)定期重算UPDATE couriers SET load_count(SELECT COUNT(*) FROM assignments a JOIN orders o ON a.order_ido.id WHERE a.courier_idcouriers.id AND a.result1 AND o.status IN (1,2,3))。更穩(wěn)的做法是干脆不存load_count每次派單時(shí)用子查詢實(shí)時(shí)算數(shù)據(jù)量小的時(shí)候性能完全夠省掉一致性維護(hù)。4.3 現(xiàn)象同一訂單被派給兩個(gè)騎手兩人都來取貨原因派單時(shí)先查候選再插入查和插之間沒有鎖兩個(gè)調(diào)度線程同時(shí)處理同一單都查到空候選然后各自插入。這是典型的檢查后使用競態(tài)。解決插入派單記錄前先UPDATE orders SET status1 WHERE id? AND status0用rowcount判斷是否搶到搶到再插記錄或者給assignments加唯一約束UNIQUE(order_id, courier_id, result)配合事務(wù)。核心是讓「占單」這個(gè)動(dòng)作原子化別把判斷和寫入分開。4.4 現(xiàn)象按距離排序結(jié)果和地圖上看到的順序不一致原因用經(jīng)緯度平方差排序在緯度跨度大或者靠近極地時(shí)誤差明顯另外如果經(jīng)緯度存的是文本或者混了不同坐標(biāo)系比如有的點(diǎn)存了偏移后的坐標(biāo)排序直接失效。解決同城幾公里范圍內(nèi)平方差夠用但前提是所有坐標(biāo)同一坐標(biāo)系、同一單位。入庫前統(tǒng)一轉(zhuǎn)成 WGS84 的十進(jìn)制度別混?？缍瘸^十幾公里時(shí)改用 Haversine 公式或者上 R-Tree 索引SQLite 自帶rtree模塊建虛擬表按矩形范圍先篩再精排。4.5 現(xiàn)象程序重啟后部分訂單狀態(tài)卡在「已派」但騎手說沒收到原因派單記錄插了、訂單狀態(tài)改了但通知騎手的動(dòng)作在事務(wù)外通知失敗后事務(wù)已提交狀態(tài)和實(shí)際不一致?；蛘叻催^來通知發(fā)了但事務(wù)回滾了。解決把「通知」做成可重試的獨(dú)立步驟訂單狀態(tài)里加一個(gè)「已派待確認(rèn)」騎手確認(rèn)后才轉(zhuǎn)「取貨中」。通知失敗時(shí)靠定時(shí)任務(wù)掃「已派待確認(rèn)」超時(shí)的單重新派。別指望一次通知必達(dá)同城派送的常態(tài)就是重試。5. 進(jìn)階用觸發(fā)器和對(duì)賬任務(wù)把一致性焊死前面幾章把閉環(huán)跑通了但冗余字段和狀態(tài)一致性還是靠應(yīng)用層自覺。真要在生產(chǎn)邊緣用我一般會(huì)加兩層保險(xiǎn)一層是 SQLite 觸發(fā)器兜底一層是定時(shí)對(duì)賬任務(wù)。觸發(fā)器負(fù)責(zé)「該減的必須減」對(duì)賬負(fù)責(zé)「已經(jīng)漂的拉回來」兩層配合基本不用再擔(dān)心數(shù)據(jù)對(duì)不上。先看觸發(fā)器。訂單狀態(tài)從「已派/取貨中/配送中」進(jìn)入終態(tài)簽收或取消時(shí)對(duì)應(yīng)騎手的load_count必須減一。用AFTER UPDATE觸發(fā)器實(shí)現(xiàn)CREATE TRIGGER trg_order_release_load AFTER UPDATE OF status ON orders WHEN OLD.status IN (1,2,3) AND NEW.status IN (4,5) BEGIN UPDATE couriers SET load_count MAX(load_count - 1, 0) WHERE id ( SELECT courier_id FROM assignments WHERE order_id NEW.id AND result 1 ORDER BY assigned_at DESC LIMIT 1 ); END;邏輯說明AFTER UPDATE OF status只在狀態(tài)列被改時(shí)觸發(fā)避免無關(guān)更新誤觸。WHEN子句限定「從進(jìn)行中進(jìn)入終態(tài)」重復(fù)觸發(fā)不會(huì)重復(fù)減。MAX(load_count - 1, 0)防止減成負(fù)數(shù)這是兜底中的兜底。子查詢?nèi)∽罱淮谓邮艿呐蓡斡涗浺驗(yàn)橐粏慰赡鼙慌蛇^多次只有最后接受的那個(gè)騎手該減。參數(shù)上沒有可調(diào)的但要注意觸發(fā)器在事務(wù)內(nèi)執(zhí)行如果外層事務(wù)回滾觸發(fā)器效果也回滾這點(diǎn)和普通語句一致。再看對(duì)賬任務(wù)。觸發(fā)器能覆蓋大部分路徑但歷史臟數(shù)據(jù)、手工改庫、觸發(fā)器創(chuàng)建前的數(shù)據(jù)都管不到所以需要一個(gè)定時(shí)跑的校正腳本def reconcile(conn): cur conn.cursor() cur.execute( UPDATE couriers SET load_count ( SELECT COUNT(*) FROM assignments a JOIN orders o ON a.order_id o.id WHERE a.courier_id couriers.id AND a.result 1 AND o.status IN (1,2,3) ) ) conn.commit() return cur.rowcount這個(gè)腳本把每個(gè)騎手的load_count重算成「當(dāng)前有效單數(shù)」rowcount返回被修正的行數(shù)可以打到日志里監(jiān)控漂移頻率。我一般設(shè)成每 10 分鐘跑一次或者每次派單批次結(jié)束后跑一次。如果rowcount長期大于 0說明觸發(fā)器有漏網(wǎng)路徑得回去查。驗(yàn)證方法也簡單造一批訂單隨機(jī)走完簽收和取消然后跑一次reconcile看rowcount是否為 0。不為 0 就說明有路徑?jīng)]被觸發(fā)器覆蓋。我習(xí)慣在每次改狀態(tài)機(jī)代碼后都跑一遍這個(gè)驗(yàn)證比肉眼看代碼靠譜。注意觸發(fā)器會(huì)增加寫操作開銷派單高峰期如果發(fā)現(xiàn)寫入變慢先查是不是觸發(fā)器里的子查詢沒走索引。assignments(order_id)和assignments(courier_id, result)這兩個(gè)索引就是為它準(zhǔn)備的別刪。從那以后我每次給這類單文件數(shù)據(jù)庫加冗余字段都強(qiáng)制先寫觸發(fā)器再寫業(yè)務(wù)代碼最后補(bǔ)一個(gè)對(duì)賬腳本兜底——順序反了后面補(bǔ)一致性就是無底洞。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取