簡(jiǎn)介JNativeHook 2.1.0 是一套面向Java開(kāi)發(fā)者的輕量級(jí)全局事件監(jiān)聽(tīng)解決方案專(zhuān)為需捕獲系統(tǒng)級(jí)鍵盤(pán)與鼠標(biāo)操作的應(yīng)用場(chǎng)景設(shè)計(jì)如遠(yuǎn)程控制工具、自動(dòng)化測(cè)試框架、行為分析程序及跨窗口熱鍵管理器等適用于具備JNI基礎(chǔ)的中高級(jí)開(kāi)發(fā)者。資源包共210個(gè)文件涵蓋41個(gè)核心Java源碼含事件分發(fā)與鉤子注冊(cè)邏輯、27個(gè)C語(yǔ)言實(shí)現(xiàn)負(fù)責(zé)Windows/Linux/macOS底層輸入攔截、15個(gè)頭文件定義跨平臺(tái)接口、85個(gè)HTML文檔含完整API參考與示例說(shuō)明以及配置腳本、構(gòu)建文件和樣式資源整體僅709KB開(kāi)箱即用無(wú)需手動(dòng)加載DLL。已有858人學(xué)習(xí)下載讀者可直接獲取成熟穩(wěn)定的JNI封裝工程結(jié)構(gòu)、多平臺(tái)原生層實(shí)現(xiàn)細(xì)節(jié)、完整的構(gòu)建配置autotools體系及詳實(shí)的使用文檔快速集成全局監(jiān)聽(tīng)能力至自有項(xiàng)目。1. JNativeHook 2.1.0不是“Java版全局鉤子”那么簡(jiǎn)單而是跨平臺(tái)原生事件穿透的穩(wěn)定底座你有沒(méi)有試過(guò)在 Java 里監(jiān)聽(tīng) CtrlShiftEsc任務(wù)管理器快捷鍵或者捕獲用戶(hù)在任意窗口中按下的 PrintScreen用KeyEvent早翻車(chē)了——它只管當(dāng)前焦點(diǎn)組件。用Robot模擬那是輸出不是輸入監(jiān)聽(tīng)。JNativeHook 2.1.0 就是那個(gè)能真正捅破 JVM 沙箱邊界的少數(shù)派它不靠 Java AWT/Swing 事件循環(huán)而是直接加載平臺(tái)原生庫(kù)Windows 的user32.dll、Linux 的libX11.so、macOS 的CoreGraphics.framework把底層鍵盤(pán)/鼠標(biāo)原始事件流“拽”進(jìn) Java 進(jìn)程。這不是玩具級(jí)工具某高校實(shí)驗(yàn)室做無(wú)障礙輔助系統(tǒng)時(shí)靠它實(shí)現(xiàn)在鎖屏界面外持續(xù)監(jiān)聽(tīng)自定義喚醒組合鍵某跨平臺(tái)日志審計(jì)工具也用它做無(wú)侵入式操作行為采集。它解決的不是“能不能監(jiān)聽(tīng)”而是“監(jiān)聽(tīng)是否可靠、是否跨會(huì)話(huà)、是否不被系統(tǒng)級(jí)屏蔽”。適合需要真實(shí)全局輸入感知的桌面端 Java 工程師——尤其當(dāng)你發(fā)現(xiàn) Swing 的GlobalEventQueue在多顯示器或遠(yuǎn)程桌面下開(kāi)始丟事件時(shí)該換底座了。2. 原理與選型為什么是 JNativeHook 而不是 JNI 自寫(xiě)鉤子或 JNA 封裝2.1 全局鉤子的本質(zhì)操作系統(tǒng)級(jí)回調(diào)注冊(cè)機(jī)制全局鍵盤(pán)/鼠標(biāo)鉤子不是“輪詢(xún)”而是向 OS 注冊(cè)一個(gè)回調(diào)函數(shù)地址由內(nèi)核在每次硬件事件分發(fā)前主動(dòng)調(diào)用。Windows 下用SetWindowsHookEx(WH_KEYBOARD_LL, ...)Linux 下需通過(guò) X11 的XRecord擴(kuò)展或 evdev 接口讀取/dev/input/event*macOS 則依賴(lài)CGEventTapCreate創(chuàng)建事件監(jiān)聽(tīng)器。關(guān)鍵點(diǎn)在于這個(gè)回調(diào)必須駐留在原生代碼空間且需滿(mǎn)足 OS 對(duì)線(xiàn)程模型、執(zhí)行時(shí)間、內(nèi)存生命周期的嚴(yán)苛要求例如 Windows LL 鉤子禁止調(diào)用SendMessage否則死鎖。純 Java 無(wú)法滿(mǎn)足——JVM 線(xiàn)程調(diào)度、GC 暫停、棧幀管理全與 OS 鉤子上下文沖突。2.2 JNativeHook 的三層架構(gòu)設(shè)計(jì)它沒(méi)走“Java 寫(xiě)邏輯 JNI 寫(xiě)鉤子”的老路而是拆成三段Native 層C/C 實(shí)現(xiàn)各平臺(tái)鉤子注冊(cè)、事件捕獲、序列化如將INPUT_RECORD轉(zhuǎn)為結(jié)構(gòu)化字節(jié)數(shù)組JNI Bridge 層極輕量 C 接口僅負(fù)責(zé)把原生事件數(shù)組傳給 Java不做任何業(yè)務(wù)邏輯Java API 層GlobalScreen類(lèi)封裝啟動(dòng)/停止、事件分發(fā)addKeyListener、線(xiàn)程安全隊(duì)列EventDispatchThread。這種設(shè)計(jì)規(guī)避了兩個(gè)經(jīng)典陷阱一是避免在原生回調(diào)中直接調(diào)用 Java 方法易引發(fā) JVM Crash二是防止 Java 層阻塞導(dǎo)致 OS 鉤子超時(shí)被卸載Windows 會(huì)強(qiáng)制移除響應(yīng) 10ms 的 LL 鉤子。2.3 為什么不用 JNA 自己封裝JNA 確實(shí)能調(diào)用SetWindowsHookEx但問(wèn)題在后續(xù)鉤子函數(shù)指針必須是static native method地址而 JNA 的Callback是 Java 對(duì)象其地址在 GC 后無(wú)效Linux X11 需要XOpenDisplay(NULL)獲取默認(rèn)顯示但多線(xiàn)程下XInitThreads()必須在main()中調(diào)用JNA 無(wú)法保證macOS 的CGEventTapCreate要求回調(diào)函數(shù)在主線(xiàn)程運(yùn)行而 JNA 默認(rèn)在新線(xiàn)程執(zhí)行。JNativeHook 2.1.0 把這些平臺(tái)差異全收在 Native 層Java 層只暴露GlobalScreen.registerNativeHook()這一個(gè)入口——這是血淚經(jīng)驗(yàn)換來(lái)的抽象少一層封裝多一分穩(wěn)定。2.4 與同類(lèi)方案對(duì)比JNativeHook vs. JIntellitype vs. 自研 JNI方案跨平臺(tái)支持全局熱鍵注冊(cè)鍵盤(pán)按鍵級(jí)監(jiān)聽(tīng)macOS 支持系統(tǒng)級(jí)權(quán)限要求JNativeHook 2.1.0? Win/Linux/macOS?需registerHotKey?所有鍵含 CtrlAltDel?10.15 仍需 Accessibility 權(quán)限macOS 需開(kāi)啟輔助功能Linux 需uinput或evdev讀權(quán)限JIntellitype? 僅 Windows?基于 RegisterHotKey?僅熱鍵不捕獲普通按鍵?Windows 無(wú)需特殊權(quán)限自研 JNI?? 需自行維護(hù)三套代碼?? 易出錯(cuò)如 Windows 熱鍵沖突?? macOS 事件過(guò)濾漏判如 CmdSpace?? 需處理 SIP 和 TCC 權(quán)限彈窗?? 每個(gè)平臺(tái)權(quán)限策略不同上線(xiàn)前必踩坑提示JNativeHook 2.1.0 的NativeHookException異常類(lèi)明確區(qū)分了平臺(tái)錯(cuò)誤碼如ERROR_ACCESS_DENIED對(duì)應(yīng) macOS 權(quán)限缺失比自研方案的UnsatisfiedLinkError更易定位。3. 快速上手從零啟動(dòng)全局鍵盤(pán)監(jiān)聽(tīng)含完整 Maven 依賴(lài)與最小可運(yùn)行代碼3.1 Maven 依賴(lài)配置關(guān)鍵排除沖突的舊版 JNAJNativeHook 2.1.0 內(nèi)置 JNA 5.12.1若項(xiàng)目已引入 JNA 4.x 或 5.x 低版本必須排除否則NativeLibrary加載失敗dependency groupIdcom.1stleg/groupId artifactIdjnativehook/artifactId version2.1.0/version exclusions !-- 強(qiáng)制排除項(xiàng)目中可能存在的舊版 JNA -- exclusion groupIdnet.java.dev.jna/groupId artifactIdjna/artifactId /exclusion exclusion groupIdnet.java.dev.jna/groupId artifactIdjna-platform/artifactId /exclusion /exclusions /dependency注意不要手動(dòng)添加 JNA 依賴(lài)JNativeHook 的pom.xml已聲明jna:5.12.1為compile范圍重復(fù)引入會(huì)導(dǎo)致ClassCastException: com.sun.jna.NativeLibrary cannot be cast to com.sun.jna.NativeLibrary。3.2 最小可運(yùn)行監(jiān)聽(tīng)器捕獲所有鍵盤(pán)事件并打印鍵碼以下代碼能在任意窗口獲得焦點(diǎn)時(shí)實(shí)時(shí)輸出物理按鍵非字符import org.jnativehook.GlobalScreen; import org.jnativehook.NativeHookException; import org.jnativehook.keyboard.NativeKeyEvent; import org.jnativehook.keyboard.NativeKeyListener; public class MinimalKeyListener implements NativeKeyListener { public static void main(String[] args) { try { // 1. 注冊(cè)全局鉤子此步觸發(fā)原生庫(kù)加載 GlobalScreen.registerNativeHook(); } catch (NativeHookException ex) { System.err.println(注冊(cè)失敗: ex.getMessage()); System.exit(1); } // 2. 添加監(jiān)聽(tīng)器事件在獨(dú)立線(xiàn)程分發(fā)不阻塞主線(xiàn)程 GlobalScreen.addNativeKeyListener(new MinimalKeyListener()); } Override public void nativeKeyPressed(NativeKeyEvent e) { // 輸出物理鍵碼如 F1112, Ctrl17不受鍵盤(pán)布局影響 System.out.printf(按下: %s (VK%d, RawCode0x%X)%n, NativeKeyEvent.getKeyText(e.getKeyCode()), e.getKeyCode(), e.getRawCode()); } Override public void nativeKeyReleased(NativeKeyEvent e) { // 可選釋放事件用于長(zhǎng)按檢測(cè) } Override public void nativeKeyTyped(NativeKeyEvent e) { // 此方法極少觸發(fā)僅當(dāng)系統(tǒng)生成字符事件時(shí)通常忽略 } }參數(shù)說(shuō)明e.getKeyCode()Java 標(biāo)準(zhǔn)虛擬鍵碼VK_F1,VK_CONTROL跨平臺(tái)一致e.getRawCode()平臺(tái)原始掃描碼WindowsMapVirtualKeyLinuxevdevcodemacOSCGKeyCode用于識(shí)別 CapsLock/NumLock 狀態(tài)e.getModifiers()當(dāng)前修飾鍵狀態(tài)NATIVE_KEY_MODIFIER_CTRL等比KeyEvent.isControlDown()更可靠因它讀取的是事件發(fā)生瞬間的硬件狀態(tài)而非 JVM 緩存。3.3 關(guān)鍵初始化邏輯GlobalScreen的隱式行為調(diào)用GlobalScreen.registerNativeHook()時(shí)實(shí)際發(fā)生檢測(cè) OS 類(lèi)型加載對(duì)應(yīng).dll/.so/.dylib路徑為jnativehook-2.1.0-natives-os.jar內(nèi)在 Native 層創(chuàng)建事件循環(huán)線(xiàn)程Windows 用GetMessageLinux 用select()監(jiān)聽(tīng) X11 socketmacOS 用CFRunLoopRun()啟動(dòng) Java 層EventDispatchThread從 Native 隊(duì)列消費(fèi)事件并分發(fā)到所有監(jiān)聽(tīng)器。提示GlobalScreen是單例多次registerNativeHook()無(wú)副作用但unregisterNativeHook()必須顯式調(diào)用否則進(jìn)程退出時(shí)原生資源未釋放Linux 下可能殘留/dev/uinput設(shè)備句柄。3.4 macOS 權(quán)限適配繞不開(kāi)的 Accessibility 授權(quán)在 macOS 10.15 上首次運(yùn)行會(huì)彈窗提示“允許輔助功能”必須手動(dòng)開(kāi)啟運(yùn)行程序后打開(kāi)系統(tǒng)設(shè)置 → 隱私與安全性 → 輔助功能點(diǎn)擊左下角鎖圖標(biāo)解鎖勾選你的 Java 應(yīng)用如java或IntelliJ IDEA重啟應(yīng)用。若跳過(guò)此步GlobalScreen.registerNativeHook()會(huì)拋出NativeHookException: Failed to register native hook.且e.getException().getErrorCode()返回-1000JNativeHook 定義的ERROR_ACCESSIBILITY_DISABLED。4. 避坑指南五個(gè)讓開(kāi)發(fā)者凌晨三點(diǎn)還在查日志的真實(shí)問(wèn)題4.1 現(xiàn)象Linux 下監(jiān)聽(tīng)失效X11錯(cuò)誤日志刷屏原因JNativeHook 2.1.0 默認(rèn)使用 X11 Record 擴(kuò)展但某些精簡(jiǎn)版 Linux如 Ubuntu Server、Docker 容器未安裝x11-xserver-utils導(dǎo)致XRecordEnableContext調(diào)用失敗。解決安裝 X11 工具包并確保 DISPLAY 環(huán)境變量正確# Ubuntu/Debian sudo apt-get install x11-xserver-utils # 啟動(dòng)前設(shè)置若無(wú)圖形界面需啟動(dòng) Xvfb export DISPLAY:99 Xvfb :99 -screen 0 1024x768x24 4.2 現(xiàn)象Windows 下 AltTab 切換窗口時(shí)鍵盤(pán)事件突然停止原因Windows LL 鉤子在WM_KILLFOCUS消息后可能被臨時(shí)掛起而 JNativeHook 2.1.0 的默認(rèn)事件分發(fā)線(xiàn)程未處理此狀態(tài)。解決強(qiáng)制啟用EventDispatchThread并設(shè)置高優(yōu)先級(jí)// 在 registerNativeHook() 后立即調(diào)用 GlobalScreen.setEventDispatcher(new EventDispatchThread()); GlobalScreen.getEventDispatcher().setPriority(Thread.MAX_PRIORITY);4.3 現(xiàn)象macOS 上 CmdSpaceSpotlight等系統(tǒng)熱鍵完全不觸發(fā)監(jiān)聽(tīng)原因macOS 系統(tǒng)級(jí)熱鍵在CGEventTap的kCGHeadInsertEventTap階段已被攔截JNativeHook 的kCGSessionEventTap位于更下游無(wú)法捕獲。解決改用registerHotKey()注冊(cè)自定義熱鍵如 CmdOptionK系統(tǒng)會(huì)將其轉(zhuǎn)發(fā)給你的應(yīng)用try { // 注冊(cè) CmdOptionK 為熱鍵注意需先獲取 Accessibility 權(quán)限 GlobalScreen.registerHotKey(1, NativeKeyEvent.CTRL_MASK | NativeKeyEvent.ALT_MASK, KeyEvent.VK_K); } catch (NativeHookException e) { // 處理注冊(cè)失敗 } // 然后監(jiān)聽(tīng) HotKeyEvent GlobalScreen.addNativeKeyListener(new HotKeyListener());4.4 現(xiàn)象監(jiān)聽(tīng)器中調(diào)用SwingUtilities.invokeLater()更新 UI偶爾拋NullPointerException原因EventDispatchThread分發(fā)事件時(shí)若 Swing EventQueue 尚未初始化如在main()中過(guò)早注冊(cè)鉤子invokeLater()內(nèi)部Toolkit.getDefaultToolkit()返回 null。解決確保 GUI 初始化完成后再注冊(cè)鉤子public static void main(String[] args) { // 1. 先啟動(dòng) Swing SwingUtilities.invokeLater(() - { JFrame frame new JFrame(Test); frame.setVisible(true); // 2. 此時(shí)再注冊(cè)鉤子 try { GlobalScreen.registerNativeHook(); } catch (NativeHookException ex) { ex.printStackTrace(); } }); }4.5 現(xiàn)象程序退出后Linux 終端殘留^[[200~字符粘滯模式未關(guān)閉原因JNativeHook 2.1.0 在 X11 模式下啟用了DECCKMCursor Keys Mode但未在unregisterNativeHook()中重置。解決顯式注銷(xiāo)鉤子并手動(dòng)發(fā)送重置序列Runtime.getRuntime().addShutdownHook(new Thread(() - { try { GlobalScreen.unregisterNativeHook(); // 重置終端光標(biāo)模式 System.out.print(\033[?1l\033); System.out.flush(); } catch (NativeHookException e) { e.printStackTrace(); } }));5. 進(jìn)階實(shí)戰(zhàn)構(gòu)建一個(gè)防誤觸的全局快捷鍵管理器支持熱鍵沖突檢測(cè)與動(dòng)態(tài)注冊(cè)5.1 需求場(chǎng)景還原某跨平臺(tái)圖像標(biāo)注工具的實(shí)際痛點(diǎn)該工具需支持用戶(hù)自定義快捷鍵如 Ctrl1 切換畫(huà)筆CtrlShiftZ 撤銷(xiāo)當(dāng)用戶(hù)設(shè)置的快捷鍵與系統(tǒng)或其他應(yīng)用沖突時(shí)實(shí)時(shí)提示如 “CtrlAltDel 已被系統(tǒng)占用”運(yùn)行時(shí)動(dòng)態(tài)啟用/禁用某組快捷鍵如進(jìn)入標(biāo)注模式才激活繪圖鍵。JNativeHook 2.1.0 原生不提供熱鍵沖突檢測(cè)但可通過(guò)組合registerHotKey()與系統(tǒng) API 實(shí)現(xiàn)。5.2 核心實(shí)現(xiàn)熱鍵占用檢測(cè)與動(dòng)態(tài)注冊(cè)表我們封裝一個(gè)HotKeyManager利用 Windows 的RegisterHotKey返回值、Linux 的XGrabKey錯(cuò)誤碼、macOS 的CGEventTapCreate失敗原因統(tǒng)一判斷沖突import org.jnativehook.GlobalScreen; import org.jnativehook.NativeHookException; import org.jnativehook.keyboard.NativeKeyEvent; import java.util.HashMap; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; public class HotKeyManager { // 存儲(chǔ)已注冊(cè)的熱鍵keyCombination - actionName private final MapString, String registeredKeys new ConcurrentHashMap(); // 熱鍵組合字符串生成器標(biāo)準(zhǔn)化CtrlShiftA private String keyCombinationToString(int modifiers, int keyCode) { StringBuilder sb new StringBuilder(); if ((modifiers NativeKeyEvent.CTRL_MASK) ! 0) sb.append(Ctrl); if ((modifiers NativeKeyEvent.SHIFT_MASK) ! 0) sb.append(Shift); if ((modifiers NativeKeyEvent.ALT_MASK) ! 0) sb.append(Alt); if ((modifiers NativeKeyEvent.META_MASK) ! 0) sb.append(Cmd); sb.append(NativeKeyEvent.getKeyText(keyCode)); return sb.toString(); } // 注冊(cè)熱鍵返回是否成功及原因 public RegistrationResult registerHotKey(int id, int modifiers, int keyCode, String actionName) { try { GlobalScreen.registerHotKey(id, modifiers, keyCode); String keyStr keyCombinationToString(modifiers, keyCode); registeredKeys.put(keyStr, actionName); return new RegistrationResult(true, OK); } catch (NativeHookException e) { String reason parseConflictReason(e); return new RegistrationResult(false, reason); } } // 解析不同平臺(tái)的沖突原因 private String parseConflictReason(NativeHookException e) { int errorCode e.getErrorCode(); if (errorCode -1001) { // Windows: ERROR_HOTKEY_ALREADY_REGISTERED return 已被其他應(yīng)用占用; } else if (errorCode -1002) { // Linux: XGrabKey failed return X11 權(quán)限不足或鍵已被捕獲; } else if (errorCode -1003) { // macOS: CGEventTapCreate failed return 輔助功能未啟用或系統(tǒng)熱鍵保護(hù); } else { return 未知錯(cuò)誤: e.getMessage(); } } // 動(dòng)態(tài)注銷(xiāo)熱鍵 public void unregisterHotKey(int id) { try { GlobalScreen.unregisterHotKey(id); } catch (NativeHookException ignored) {} } // 內(nèi)部結(jié)果類(lèi) public static class RegistrationResult { public final boolean success; public final String message; public RegistrationResult(boolean success, String message) { this.success success; this.message message; } } }5.3 使用示例帶沖突檢測(cè)的快捷鍵配置面板public class HotKeyConfigPanel { private final HotKeyManager manager new HotKeyManager(); public void configureSaveAction() { // 嘗試注冊(cè) CtrlS 保存 HotKeyManager.RegistrationResult result manager.registerHotKey(101, NativeKeyEvent.CTRL_MASK, KeyEvent.VK_S, 保存文件); if (result.success) { System.out.println(? CtrlS 已啟用保存文件); } else { System.err.println(? CtrlS 注冊(cè)失敗 result.message); // 此處可彈窗提示用戶(hù)更換組合鍵 showConflictDialog(CtrlS, result.message); } } private void showConflictDialog(String keyCombo, String reason) { JOptionPane.showMessageDialog(null, String.format(快捷鍵 %s 無(wú)法使用\n原因%s\n請(qǐng)嘗試其他組合鍵如 CtrlAltS, keyCombo, reason), 熱鍵沖突, JOptionPane.WARNING_MESSAGE); } }5.4 防誤觸增強(qiáng)長(zhǎng)按檢測(cè)與組合鍵松開(kāi)延遲全局監(jiān)聽(tīng)最大的誤操作是“按住 Ctrl 切換窗口時(shí)意外觸發(fā) CtrlC”。我們?cè)诒O(jiān)聽(tīng)器中加入狀態(tài)機(jī)public class SafeKeyListener implements NativeKeyListener { private final MapInteger, Long keyDownTime new HashMap(); // 記錄按鍵按下時(shí)間戳 private static final long HOLD_THRESHOLD_MS 300; // 長(zhǎng)按閾值 Override public void nativeKeyPressed(NativeKeyEvent e) { keyDownTime.put(e.getKeyCode(), System.currentTimeMillis()); } Override public void nativeKeyReleased(NativeKeyEvent e) { Long pressTime keyDownTime.remove(e.getKeyCode()); if (pressTime ! null System.currentTimeMillis() - pressTime HOLD_THRESHOLD_MS) { // 長(zhǎng)按事件可觸發(fā)特殊動(dòng)作如 Ctrl 長(zhǎng)按 300ms 啟動(dòng)語(yǔ)音輸入 System.out.println(長(zhǎng)按檢測(cè): NativeKeyEvent.getKeyText(e.getKeyCode())); } } // 組合鍵松開(kāi)延遲僅當(dāng)所有修飾鍵都釋放后才觸發(fā)動(dòng)作 private final SetInteger activeModifiers ConcurrentHashMap.newKeySet(); Override public void nativeKeyPressed(NativeKeyEvent e) { if (e.isModifierKey()) { activeModifiers.add(e.getKeyCode()); } } Override public void nativeKeyReleased(NativeKeyEvent e) { if (e.isModifierKey()) { activeModifiers.remove(e.getKeyCode()); // 當(dāng)最后一個(gè)修飾鍵釋放時(shí)檢查是否構(gòu)成有效組合 if (activeModifiers.isEmpty()) { System.out.println(所有修飾鍵已釋放可安全執(zhí)行組合動(dòng)作); } } } }從那以后我每次在項(xiàng)目里接入全局監(jiān)聽(tīng)都強(qiáng)制走一遍三步驗(yàn)證先跑最小監(jiān)聽(tīng)器確認(rèn)原生庫(kù)加載無(wú)UnsatisfiedLinkError再用HotKeyManager測(cè)試 3 個(gè)常用組合鍵CtrlC, AltTab, CmdSpace記錄各平臺(tái)返回碼最后注入長(zhǎng)按狀態(tài)機(jī)用秒表掐著 300ms 按鍵看日志是否觸發(fā)。這三步花不了十分鐘但省去了后續(xù)三天排查“為什么 macOS 上熱鍵偶爾失靈”的時(shí)間。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取