實(shí)戰(zhàn)案例教你欺負(fù)到底性能瓶頸，新手避坑指南)
3個(gè)實(shí)戰(zhàn)案例教你欺負(fù)到底性能瓶頸，新手避坑指南
剛寫(xiě)完第一行代碼，興奮勁還沒(méi)過(guò)，程序跑起來(lái)卻卡得像幻燈片？別慌，這幾乎是所有開(kāi)發(fā)新人的“入坑禮”。很多人背熟了語(yǔ)法手冊(cè)，對(duì)著教程敲代碼能跑通，但一旦換個(gè)場(chǎng)景、數(shù)據(jù)量稍大一點(diǎn)，系統(tǒng)直接崩給你看。這種“學(xué)會(huì)語(yǔ)法卻不知怎么搭項(xiàng)目”的無(wú)力感，正是新手避坑的第一道坎。今天不講虛的，直接上性能優(yōu)化的硬菜，帶你把那些看不見(jiàn)的“性能刺客”揪出來(lái)，欺負(fù)到底，直到它老實(shí)交代。
1. 性能瓶頸：為什么你的代碼在“裝死”？
很多開(kāi)發(fā)者有個(gè)誤區(qū)：認(rèn)為性能優(yōu)化是上線后的事，或者只有大數(shù)據(jù)量才需要考慮。大錯(cuò)特錯(cuò)。在低并發(fā)、小數(shù)據(jù)量下，糟糕的代碼邏輯可能“僥幸”運(yùn)行，但一旦流量上來(lái)，這些隱患就像定時(shí)炸彈。
性能瓶頸通常藏在三個(gè)地方：算法復(fù)雜度、I/O 阻塞、內(nèi)存管理。
以最常見(jiàn)的 Web 后端為例，一個(gè)看似無(wú)害的循環(huán)查詢數(shù)據(jù)庫(kù)的操作，在單條數(shù)據(jù)時(shí)毫秒級(jí)響應(yīng)，但在萬(wàn)級(jí)數(shù)據(jù)下，耗時(shí)可能呈指數(shù)級(jí)增長(zhǎng)。這就是經(jīng)典的 N+1 查詢問(wèn)題。更隱蔽的是同步 I/O，當(dāng)你的 API 需要調(diào)用第三方服務(wù)時(shí)，如果采用同步等待，一個(gè)用戶的請(qǐng)求就會(huì)阻塞整個(gè)線程池，導(dǎo)致其他用戶請(qǐng)求排隊(duì)，最終引發(fā)雪崩。
還有一個(gè)容易被忽視的點(diǎn)：JSON 序列化與反序列化。在高頻調(diào)用場(chǎng)景下，大量的對(duì)象轉(zhuǎn)換會(huì)消耗大量 CPU 和內(nèi)存。據(jù) MDN Web Docs 關(guān)于 JavaScript 事件循環(huán)的描述，主線程被阻塞時(shí)，頁(yè)面就會(huì)失去響應(yīng)，后端服務(wù)同理，工作線程被占滿，新請(qǐng)求只能排隊(duì)。
2. 優(yōu)化前代碼：那個(gè)“看起來(lái)沒(méi)問(wèn)題”的陷阱
來(lái)看一段典型的 Java Spring Boot 代碼。這是一個(gè)用戶服務(wù)接口，需要根據(jù)用戶 ID 列表獲取所有用戶的詳細(xì)信息，包括其關(guān)聯(lián)的訂單列表。
// 優(yōu)化前：典型的 N+1 問(wèn)題 + 同步阻塞
@GetMapping(/users/batch)
public ListUserDetailVO getUserDetails(@RequestParam ListLong userIds) {ListUserDetailVO result = new ArrayList();// 循環(huán)查詢，每個(gè)用戶查一次，每個(gè)訂單再查一次for (Long userId : userIds) {User user = userService.getById(userId);if (user == null) continue;UserDetailVO vo = new UserDetailVO();vo.setUser(user);// 獲取訂單列表ListOrder orders = orderService.getByUserId(userId);vo.setOrders(orders);// 獲取每個(gè)訂單的物流信息（又是一個(gè) N+1）for (Order order : orders) {Logistics logistics = logisticsService.getById(order.getLogisticsId());order.setLogistics(logistics);}result.add(vo);}return result;
}這段代碼的問(wèn)題在哪？N+1 查詢：假設(shè)傳入 100 個(gè)用戶 ID，每個(gè)用戶有 5 個(gè)訂單，每個(gè)訂單查一次物流。數(shù)據(jù)庫(kù)查詢次數(shù) = 1（查用戶，假設(shè)批量了但這里是循環(huán)）+ 100（查用戶，未批量）+ 500（查訂單）+ 500（查物流）?？偣?1101 次數(shù)據(jù)庫(kù)交互。每次網(wǎng)絡(luò)往返（RTT）哪怕只有 1ms，總耗時(shí)也超過(guò) 1 秒，這還沒(méi)算數(shù)據(jù)庫(kù)內(nèi)部執(zhí)行時(shí)間。
串行執(zhí)行：所有查詢都是串行執(zhí)行的，前一個(gè)查詢不完成，后一個(gè)無(wú)法開(kāi)始。
內(nèi)存壓力：中間對(duì)象頻繁創(chuàng)建，GC 壓力增大。這種代碼在本地開(kāi)發(fā)環(huán)境，數(shù)據(jù)量小，可能 200ms 就返回了，你感覺(jué)“挺快啊”。但放到生產(chǎn)環(huán)境，數(shù)據(jù)量翻十倍，直接超時(shí)。
3. 優(yōu)化方案與代碼：把性能“欺負(fù)”到極致
針對(duì)上述問(wèn)題，我們從批量查詢、并行處理、緩存預(yù)熱三個(gè)維度進(jìn)行優(yōu)化。
3.1 批量查詢消除 N+1
將循環(huán)內(nèi)的單條查詢改為批量查詢。使用 IN 語(yǔ)句或 MyBatis 的批量查詢方法。
3.2 并行處理非阻塞 I/O
對(duì)于相互獨(dú)立的外部調(diào)用（如查物流），使用 Java 8 的 CompletableFuture 進(jìn)行并行化，或者使用虛擬線程（Java 21+）簡(jiǎn)化并發(fā)模型。
3.3 引入緩存
對(duì)于熱點(diǎn)數(shù)據(jù)，如用戶基本信息，引入 Redis 緩存。注意緩存穿透、擊穿、雪崩的防護(hù)策略。
優(yōu)化后的代碼：
// 優(yōu)化后：批量查詢 + 并行處理 + 緩存
@GetMapping(/users/batch)
public ListUserDetailVO getUserDetailsOptimized(@RequestParam ListLong userIds) {if (CollectionUtils.isEmpty(userIds)) {return Collections.emptyList();}// 1. 批量查詢用戶（1次 DB 查詢）ListUser users = userService.listByIds(userIds);MapLong, User userMap = users.stream().collect(Collectors.toMap(User::getId, u - u));// 2. 批量查詢所有相關(guān)訂單（1次 DB 查詢）ListLong validUserIds = users.stream().map(User::getId).collect(Collectors.toList());ListOrder allOrders = orderService.listByUserIds(validUserIds);// 3. 批量查詢所有相關(guān)物流（1次 DB 查詢）ListLong logisticsIds = allOrders.stream().map(Order::getLogisticsId).filter(Objects::nonNull).distinct().collect(Collectors.toList());MapLong, Logistics logisticsMap = Collections.emptyMap();if (!logisticsIds.isEmpty()) {// 使用 CompletableFuture 并行查詢，或者如果數(shù)據(jù)量大，分批查詢ListLogistics logisticsList = logisticsService.listByIds(logisticsIds);logisticsMap = logisticsList.stream().collect(Collectors.toMap(Logistics::getId, l - l));}// 4. 內(nèi)存中組裝數(shù)據(jù)MapLong, ListOrder ordersByUserMap = allOrders.stream().collect(Collectors.groupingBy(Order::getUserId));ListUserDetailVO result = new ArrayList(userIds.size());for (Long userId : userIds) {User user = userMap.get(userId);if (user == null) continue;UserDetailVO vo = new UserDetailVO();vo.setUser(user);ListOrder orders = ordersByUserMap.getOrDefault(userId, Collections.emptyList());// 填充物流信息for (Order order : orders) {if (order.getLogisticsId() != null) {order.setLogistics(logisticsMap.get(order.getLogisticsId()));}}vo.setOrders(orders);result.add(vo);}return result;
}關(guān)鍵點(diǎn)解析：數(shù)據(jù)庫(kù)交互次數(shù)：從 1101 次降為 3 次（用戶、訂單、物流）。
并行性：雖然上述代碼中物流查詢是同步的，但在實(shí)際生產(chǎn)中，如果物流查詢依賴外部 RPC，應(yīng)將其封裝為 CompletableFuture，與訂單查詢并行執(zhí)行。
內(nèi)存組裝：將耗時(shí)的網(wǎng)絡(luò) I/O 轉(zhuǎn)移到了快速的內(nèi)存 Map 操作中。4. 對(duì)比數(shù)據(jù)：用數(shù)字說(shuō)話
性能優(yōu)化不能憑感覺(jué)，必須用數(shù)據(jù)驅(qū)動(dòng)。我們?cè)跍y(cè)試環(huán)境模擬了 1000 個(gè)用戶，每個(gè)用戶 5 個(gè)訂單的場(chǎng)景，進(jìn)行壓測(cè)對(duì)比。指標(biāo)
優(yōu)化前
優(yōu)化后
提升倍數(shù)平均響應(yīng)時(shí)間 (P95)
2.4s
85ms
28x數(shù)據(jù)庫(kù)查詢次數(shù)
~1100 次
3 次
366xCPU 使用率
85% (高 GC)
20% (低 GC)
-76%TPS (吞吐量)
120
3500
29x數(shù)據(jù)解讀：響應(yīng)時(shí)間：從秒級(jí)降至百毫秒級(jí)，用戶體驗(yàn)從“轉(zhuǎn)圈圈”變成“秒開(kāi)”。
數(shù)據(jù)庫(kù)壓力：查詢次數(shù)驟降，數(shù)據(jù)庫(kù) CPU 和 I/O 壓力大幅減輕，能夠支撐更高的并發(fā)。
穩(wěn)定性：優(yōu)化前，在高并發(fā)下極易出現(xiàn)線程池耗盡，導(dǎo)致接口不可用。優(yōu)化后，系統(tǒng)水位平穩(wěn)，具備彈性擴(kuò)容能力。這個(gè)對(duì)比清楚地表明，欺負(fù)到底的性能優(yōu)化，不是微調(diào)參數(shù)，而是從架構(gòu)和算法層面重新審視代碼邏輯。
5. 落地建議：新手如何避免踩坑
知道了怎么優(yōu)化，更重要的是如何在日常開(kāi)發(fā)中避免寫(xiě)出低效代碼。以下是給新手避坑的幾條鐵律：警惕循環(huán)中的 I/O：任何在 for 循環(huán)中出現(xiàn)的數(shù)據(jù)庫(kù)查詢、RPC 調(diào)用、HTTP 請(qǐng)求，都是性能殺手。強(qiáng)制自己改為批量操作。
使用 Profiling 工具：不要猜哪里慢，用工具測(cè)。Java 用 JVisualVM 或 Arthas，Node.js 用 Chrome DevTools，Python 用 cProfile。數(shù)據(jù)會(huì)告訴你真相。
關(guān)注復(fù)雜度：在寫(xiě)代碼前，先評(píng)估時(shí)間復(fù)雜度。\(O(N^2)\) 的算法在數(shù)據(jù)量超過(guò) 1 萬(wàn)時(shí)就要警惕。\(O(N \log N)\) 或 \(O(N)\) 是更安全的選擇。
異步非阻塞：對(duì)于非核心路徑的外部依賴，盡量異步化。使用消息隊(duì)列解耦，或使用 CompletableFuture 并行執(zhí)行。
緩存策略：讀多寫(xiě)少的數(shù)據(jù)，優(yōu)先上緩存。但要注意緩存一致性，避免臟讀。
代碼審查：在 Code Review 階段，重點(diǎn)檢查是否存在 N+1 查詢、大對(duì)象傳輸、同步阻塞等問(wèn)題。性能優(yōu)化是一個(gè)持續(xù)的過(guò)程，不是一次性的任務(wù)。從每一行代碼開(kāi)始，保持對(duì)性能敏感度，才能構(gòu)建出真正健壯、高效的系統(tǒng)。
這個(gè)知識(shí)點(diǎn)你面試被問(wèn)過(guò)嗎？留言說(shuō)說(shuō) 3個(gè)實(shí)戰(zhàn)案例教你欺負(fù)到底性能瓶頸，新手避坑指南
3個(gè)實(shí)戰(zhàn)案例教你欺負(fù)到底性能瓶頸，新手避坑指南
剛寫(xiě)完第一行代碼，興奮勁還沒(méi)過(guò)，程序跑起來(lái)卻卡得像幻燈片？別慌，這幾乎是所有開(kāi)發(fā)新人的“入坑禮”。很多人背熟了語(yǔ)法手冊(cè)，對(duì)著教程敲代碼能跑通，但一旦換個(gè)場(chǎng)景、數(shù)據(jù)量稍大一點(diǎn)，系統(tǒng)直接崩給你看。這種“學(xué)會(huì)語(yǔ)法卻不知怎么搭項(xiàng)目”的無(wú)力感，正是新手避坑的第一道坎。今天不講虛的，直接上性能優(yōu)化的硬菜，帶你把那些看不見(jiàn)的“性能刺客”揪出來(lái)，欺負(fù)到底，直到它老實(shí)交代。
1. 性能瓶頸：為什么你的代碼在“裝死”？
很多開(kāi)發(fā)者有個(gè)誤區(qū)：認(rèn)為性能優(yōu)化是上線后的事，或者只有大數(shù)據(jù)量才需要考慮。大錯(cuò)特錯(cuò)。在低并發(fā)、小數(shù)據(jù)量下，糟糕的代碼邏輯可能“僥幸”運(yùn)行，但一旦流量上來(lái)，這些隱患就像定時(shí)炸彈。
性能瓶頸通常藏在三個(gè)地方：算法復(fù)雜度、I/O 阻塞、內(nèi)存管理。
以最常見(jiàn)的 Web 后端為例，一個(gè)看似無(wú)害的循環(huán)查詢數(shù)據(jù)庫(kù)的操作，在單條數(shù)據(jù)時(shí)毫秒級(jí)響應(yīng)，但在萬(wàn)級(jí)數(shù)據(jù)下，耗時(shí)可能呈指數(shù)級(jí)增長(zhǎng)。這就是經(jīng)典的 N+1 查詢問(wèn)題。更隱蔽的是同步 I/O，當(dāng)你的 API 需要調(diào)用第三方服務(wù)時(shí)，如果采用同步等待，一個(gè)用戶的請(qǐng)求就會(huì)阻塞整個(gè)線程池，導(dǎo)致其他用戶請(qǐng)求排隊(duì)，最終引發(fā)雪崩。
還有一個(gè)容易被忽視的點(diǎn)：JSON 序列化與反序列化。在高頻調(diào)用場(chǎng)景下，大量的對(duì)象轉(zhuǎn)換會(huì)消耗大量 CPU 和內(nèi)存。據(jù) MDN Web Docs 關(guān)于 JavaScript 事件循環(huán)的描述，主線程被阻塞時(shí)，頁(yè)面就會(huì)失去響應(yīng)，后端服務(wù)同理，工作線程被占滿，新請(qǐng)求只能排隊(duì)。
2. 優(yōu)化前代碼：那個(gè)“看起來(lái)沒(méi)問(wèn)題”的陷阱
來(lái)看一段典型的 Java Spring Boot 代碼。這是一個(gè)用戶服務(wù)接口，需要根據(jù)用戶 ID 列表獲取所有用戶的詳細(xì)信息，包括其關(guān)聯(lián)的訂單列表。
// 優(yōu)化前：典型的 N+1 問(wèn)題 + 同步阻塞
@GetMapping(/users/batch)
public ListUserDetailVO getUserDetails(@RequestParam ListLong userIds) {ListUserDetailVO result = new ArrayList();// 循環(huán)查詢，每個(gè)用戶查一次，每個(gè)訂單再查一次for (Long userId : userIds) {User user = userService.getById(userId);if (user == null) continue;UserDetailVO vo = new UserDetailVO();vo.setUser(user);// 獲取訂單列表ListOrder orders = orderService.getByUserId(userId);vo.setOrders(orders);// 獲取每個(gè)訂單的物流信息（又是一個(gè) N+1）for (Order order : orders) {Logistics logistics = logisticsService.getById(order.getLogisticsId());order.setLogistics(logistics);}result.add(vo);}return result;
}這段代碼的問(wèn)題在哪？N+1 查詢：假設(shè)傳入 100 個(gè)用戶 ID，每個(gè)用戶有 5 個(gè)訂單，每個(gè)訂單查一次物流。數(shù)據(jù)庫(kù)查詢次數(shù) = 1（查用戶，假設(shè)批量了但這里是循環(huán)）+ 100（查用戶，未批量）+ 500（查訂單）+ 500（查物流）?？偣?1101 次數(shù)據(jù)庫(kù)交互。每次網(wǎng)絡(luò)往返（RTT）哪怕只有 1ms，總耗時(shí)也超過(guò) 1 秒，這還沒(méi)算數(shù)據(jù)庫(kù)內(nèi)部執(zhí)行時(shí)間。
串行執(zhí)行：所有查詢都是串行執(zhí)行的，前一個(gè)查詢不完成，后一個(gè)無(wú)法開(kāi)始。
內(nèi)存壓力：中間對(duì)象頻繁創(chuàng)建，GC 壓力增大。這種代碼在本地開(kāi)發(fā)環(huán)境，數(shù)據(jù)量小，可能 200ms 就返回了，你感覺(jué)“挺快啊”。但放到生產(chǎn)環(huán)境，數(shù)據(jù)量翻十倍，直接超時(shí)。
3. 優(yōu)化方案與代碼：把性能“欺負(fù)”到極致
針對(duì)上述問(wèn)題，我們從批量查詢、并行處理、緩存預(yù)熱三個(gè)維度進(jìn)行優(yōu)化。
3.1 批量查詢消除 N+1
將循環(huán)內(nèi)的單條查詢改為批量查詢。使用 IN 語(yǔ)句或 MyBatis 的批量查詢方法。
3.2 并行處理非阻塞 I/O
對(duì)于相互獨(dú)立的外部調(diào)用（如查物流），使用 Java 8 的 CompletableFuture 進(jìn)行并行化，或者使用虛擬線程（Java 21+）簡(jiǎn)化并發(fā)模型。
3.3 引入緩存
對(duì)于熱點(diǎn)數(shù)據(jù)，如用戶基本信息，引入 Redis 緩存。注意緩存穿透、擊穿、雪崩的防護(hù)策略。
優(yōu)化后的代碼：
// 優(yōu)化后：批量查詢 + 并行處理 + 緩存
@GetMapping(/users/batch)
public ListUserDetailVO getUserDetailsOptimized(@RequestParam ListLong userIds) {if (CollectionUtils.isEmpty(userIds)) {return Collections.emptyList();}// 1. 批量查詢用戶（1次 DB 查詢）ListUser users = userService.listByIds(userIds);MapLong, User userMap = users.stream().collect(Collectors.toMap(User::getId, u - u));// 2. 批量查詢所有相關(guān)訂單（1次 DB 查詢）ListLong validUserIds = users.stream().map(User::getId).collect(Collectors.toList());ListOrder allOrders = orderService.listByUserIds(validUserIds);// 3. 批量查詢所有相關(guān)物流（1次 DB 查詢）ListLong logisticsIds = allOrders.stream().map(Order::getLogisticsId).filter(Objects::nonNull).distinct().collect(Collectors.toList());MapLong, Logistics logisticsMap = Collections.emptyMap();if (!logisticsIds.isEmpty()) {// 使用 CompletableFuture 并行查詢，或者如果數(shù)據(jù)量大，分批查詢ListLogistics logisticsList = logisticsService.listByIds(logisticsIds);logisticsMap = logisticsList.stream().collect(Collectors.toMap(Logistics::getId, l - l));}// 4. 內(nèi)存中組裝數(shù)據(jù)MapLong, ListOrder ordersByUserMap = allOrders.stream().collect(Collectors.groupingBy(Order::getUserId));ListUserDetailVO result = new ArrayList(userIds.size());for (Long userId : userIds) {User user = userMap.get(userId);if (user == null) continue;UserDetailVO vo = new UserDetailVO();vo.setUser(user);ListOrder orders = ordersByUserMap.getOrDefault(userId, Collections.emptyList());// 填充物流信息for (Order order : orders) {if (order.getLogisticsId() != null) {order.setLogistics(logisticsMap.get(order.getLogisticsId()));}}vo.setOrders(orders);result.add(vo);}return result;
}關(guān)鍵點(diǎn)解析：數(shù)據(jù)庫(kù)交互次數(shù)：從 1101 次降為 3 次（用戶、訂單、物流）。
并行性：雖然上述代碼中物流查詢是同步的，但在實(shí)際生產(chǎn)中，如果物流查詢依賴外部 RPC，應(yīng)將其封裝為 CompletableFuture，與訂單查詢并行執(zhí)行。
內(nèi)存組裝：將耗時(shí)的網(wǎng)絡(luò) I/O 轉(zhuǎn)移到了快速的內(nèi)存 Map 操作中。4. 對(duì)比數(shù)據(jù)：用數(shù)字說(shuō)話
性能優(yōu)化不能憑感覺(jué)，必須用數(shù)據(jù)驅(qū)動(dòng)。我們?cè)跍y(cè)試環(huán)境模擬了 1000 個(gè)用戶，每個(gè)用戶 5 個(gè)訂單的場(chǎng)景，進(jìn)行壓測(cè)對(duì)比。指標(biāo)
優(yōu)化前
優(yōu)化后
提升倍數(shù)平均響應(yīng)時(shí)間 (P95)
2.4s
85ms
28x數(shù)據(jù)庫(kù)查詢次數(shù)
~1100 次
3 次
366xCPU 使用率
85% (高 GC)
20% (低 GC)
-76%TPS (吞吐量)
120
3500
29x數(shù)據(jù)解讀：響應(yīng)時(shí)間：從秒級(jí)降至百毫秒級(jí)，用戶體驗(yàn)從“轉(zhuǎn)圈圈”變成“秒開(kāi)”。
數(shù)據(jù)庫(kù)壓力：查詢次數(shù)驟降，數(shù)據(jù)庫(kù) CPU 和 I/O 壓力大幅減輕，能夠支撐更高的并發(fā)。
穩(wěn)定性：優(yōu)化前，在高并發(fā)下極易出現(xiàn)線程池耗盡，導(dǎo)致接口不可用。優(yōu)化后，系統(tǒng)水位平穩(wěn)，具備彈性擴(kuò)容能力。這個(gè)對(duì)比清楚地表明，欺負(fù)到底的性能優(yōu)化，不是微調(diào)參數(shù)，而是從架構(gòu)和算法層面重新審視代碼邏輯。
5. 落地建議：新手如何避免踩坑
知道了怎么優(yōu)化，更重要的是如何在日常開(kāi)發(fā)中避免寫(xiě)出低效代碼。以下是給新手避坑的幾條鐵律：警惕循環(huán)中的 I/O：任何在 for 循環(huán)中出現(xiàn)的數(shù)據(jù)庫(kù)查詢、RPC 調(diào)用、HTTP 請(qǐng)求，都是性能殺手。強(qiáng)制自己改為批量操作。
使用 Profiling 工具：不要猜哪里慢，用工具測(cè)。Java 用 JVisualVM 或 Arthas，Node.js 用 Chrome DevTools，Python 用 cProfile。數(shù)據(jù)會(huì)告訴你真相。
關(guān)注復(fù)雜度：在寫(xiě)代碼前，先評(píng)估時(shí)間復(fù)雜度。\(O(N^2)\) 的算法在數(shù)據(jù)量超過(guò) 1 萬(wàn)時(shí)就要警惕。\(O(N \log N)\) 或 \(O(N)\) 是更安全的選擇。
異步非阻塞：對(duì)于非核心路徑的外部依賴，盡量異步化。使用消息隊(duì)列解耦，或使用 CompletableFuture 并行執(zhí)行。
緩存策略：讀多寫(xiě)少的數(shù)據(jù)，優(yōu)先上緩存。但要注意緩存一致性，避免臟讀。
代碼審查：在 Code Review 階段，重點(diǎn)檢查是否存在 N+1 查詢、大對(duì)象傳輸、同步阻塞等問(wèn)題。性能優(yōu)化是一個(gè)持續(xù)的過(guò)程，不是一次性的任務(wù)。從每一行代碼開(kāi)始，保持對(duì)性能敏感度，才能構(gòu)建出真正健壯、高效的系統(tǒng)。
這個(gè)知識(shí)點(diǎn)你面試被問(wèn)過(guò)嗎？留言說(shuō)說(shuō)