简介：面向网络工程与计网课程设计的Java项目，这份资源给出的是一套基于Java实现的跨平台网络流量实时监控与分析方案：后台用Java完成数据采集与解析，前端以Web客户端展示流量图表，特别适合无图形界面或需要远程查看目标机状态的场景；为应对复杂网络环境，方案还考虑了传输加密与运行稳定性，整体示范意义较强。压缩包共76个文件，大小约11.32MB，主要包含27个Java源码、15个JS与9个JSX前端文件，并附带Gradle构建脚本、证书密钥、TASK说明、课程设计报告PDF等，Java源码负责核心逻辑，JS/JSX支撑可视化界面，证书与配置则用于安全通信和项目构建。该资源已有462人学习下载，对正在做同类课程设计或想了解网络流量分析实现思路的人有直接参考价值。通过完整阅读源码与报告，可以掌握数据抓包/解析、多线程处理、前后端联调、安全通信机制及从源码到可运行JAR的构建流程；随包的报告书和配置记录还能帮助梳理设计脉络，用于答辩展示或在此基础上二次开发。
1. 用Java写网络流量分析软件：从pcap抓包到协议还原的落地路径
网络流量分析这个方向，听起来像运维或安全团队才碰的东西，但它恰恰是Java课程设计案例源码里最常出现的高分题目之一。原因很直接：流量分析天然具备「采集端用C、分析端用Java」的分工，libpcap负责抓包，JNI层把原始报文交给JVM，剩下的协议解析、统计聚合、可视化报表全部可以用纯Java实现。这个项目需求里带编号【100010394】，说明是要交付一个完整软件系统，不是写几个抓包函数就交差的Demo，那就要顺着「采集、解析、存储、展示」四条线去设计。
我接触这类项目比较多，也给不少做毕设或课设的同学看过代码。最常见的翻车点不是写不出抓包代码，而是把整个系统做成一个Java类从头写到尾——抓包在主线程跑，UI卡死，数据库连接按次开，回调里做重活，最后演示的时候一开抓包界面就假死。这篇文章就把我自己验证过的方案拆开讲：先说明流量分析在Java里应该怎么分层，再给出能跑通的最小源码结构，最后把那些坑提前标出来。适合正在做Java课程设计、期末项目，或者想在自己后端服务里加一层流量观测能力的工程师。
2. 流量分析软件的技术选型：为什么是pcap4j而不是jpcap
2.1 抓包引擎的现状对比：jpcap与pcap4j的取舍
Java做网络流量分析，第一步要解决的是底层抓包依赖。libpcap是几乎所有抓包工具的基石，但它是C语言写的，Java要调用就必须经过JNI。早期最常用的库是jpcap，它封装了libpcap的抓包和发包接口，很多老教程都拿它做例子。但jpcap的问题在于维护几乎停滞，官方很久没有更新，对Windows 10及更新系统的兼容性靠社区补丁撑着，而且它在macOS上的适配一直不太稳定。如果你把这个项目当课程设计源码交，评审老师很可能在自己电脑上跑不起来，这就是扣分项。
我这边一般会推荐pcap4j。它同样基于libpcap/WinPcap/Npcap，但是JNI层使用JNA（Java Native Access）来加载本地库，不需要预先为不同平台编译不同的.so/.dll文件。换句话说，只要目标机器装了Npcap（Windows）或libpcap（Linux/macOS），pcap4j就能跑。这一条就解决了课设项目跨机器演示的大半问题。从包结构来看，pcap4j把数据包解析也做了：EthernetPacket、IpV4Packet、TcpPacket这些类直接对应协议层次，拿到Packet对象之后基本不用自己写位运算拆报文头，省下大量时间。
2.2 协议解析的层次模型：从链路层到应用层
流量分析的核心不是抓包本身，而是把抓到的报文还原成可理解的信息。你可能经常听到「五元组」这个词，它指源IP、目的IP、源端口、目的端口、协议号。这个数据在以太网帧里是分层次存放的：链路层头里有MAC地址和上层协议类型，网络层头里有IP地址和IP协议字段，传输层头里有端口号和TCP标志位。解析顺序必须严格自下而上，每一层的payload交给下一层去解读。
pcap4j里的Packet类已经把这个结构建模好了。一个实际的TCP报文，从网卡抓到之后，pcap4j会解析出EthernetPacket，再往上get出IpV4Packet，再往上get出TcpPacket。代码里只需要通过类型判断逐层下探即可。比较特殊的是IP分片报文：一个完整的应用层数据被拆成多个IP包传输，如果直接按包去统计应用层流量就会失真。解析时要在IP层做分片重组，pcap4j的IpV4Packet里有offset和moreFragment标志，重组逻辑要处理乱序到达的情况。刚开始做这个项目时可以先把分片重组标注为「待完善」，但答辩时如果有老师问起，你要能说出这个点。
3. 用pcap4j搭建抓包模块：最小可运行命令与参数设计
3.1 获取网络接口列表：抓包前的第一个动作
抓包的前提是选定一个网卡设备。真实机器上通常有多个网络接口：有线以太网卡、无线网卡、虚拟机的虚拟网卡、蓝牙网络适配器等。手动指定网卡名很容易因为环境差异出错，所以写代码时先列出所有可用接口让用户选择，或者支持命令行参数传入接口名。下面这段代码是获取网卡列表的最简实现：
import org.pcap4j.core.PcapNetworkInterface; import org.pcap4j.core.Pcaps; import org.pcap4j.core.PcapNetworkInterface.PromiscuousMode; import java.util.List; public class NetworkInterfaceLister { public static void main(String[] args) throws Exception { List<PcapNetworkInterface> allDevices = Pcaps.findAllDevs(); if (allDevices == null || allDevices.isEmpty()) { System.out.println("未找到任何网络接口，请确认Npcap/libpcap已安装"); return; } for (int i = 0; i < allDevices.size(); i++) { PcapNetworkInterface device = allDevices.get(i); System.out.println(i + ": " + device.getName()); System.out.println(" 描述: " + device.getDescription()); } } }这段代码的逻辑很直白：调用Pcaps.findAllDevs()让pcap4j扫描本机所有可用的网卡设备，返回一个列表，然后逐条打印名字和描述。注意代码里对allDevices做了空值判断，这很重要——如果Npcap没装好或者当前用户权限不够，findAllDevs会返回null而不是空列表，不判断直接遍历就会抛NullPointerException。运行这段代码之前，Windows机器必须先安装Npcap并勾选「WinPcap API兼容模式」，Linux机器则要安装libpcap-dev，macOS通常系统自带libpcap但需要给终端授权网络权限。
参数说明方面，device.getName()返回的是pcap库内部的设备标识，Windows上形如\Device\NPF_{GUID}，Linux上是eth0这类名称；description字段则是一段人可读的说明文本，多为主板型号或USB适配器名称。如果description为null，说明pcap在解析设备信息时没拿到描述字符串，不影响抓包使用，但在界面上最好显示“未命名设备”而不是直接拼接null。
3.2 实时抓包：打开设备、设置过滤规则、注册回调
拿到网卡之后，下一步是打开设备、设置抓包过滤器、循环抓包。pcap4j里打开设备返回PcapHandle对象，它封装了底层pcap_t指针。需要重点说明的是snaplen（抓包快照长度）参数：设置65536意味着无论包多大都完整抓取；如果只关心包头而不关心payload，可以设成96字节（14字节以太网头+20字节IP头+20字节TCP头+若干），能显著降低内存和磁盘压力。timeoutMillis（超时时间）不是「抓包超时」，而是缓冲区回收间隔，设置100到1000之间都可以，不宜设成0，否则在某些驱动上会一直读不到数据。
import org.pcap4j.core.*; import org.pcap4j.packet.Packet; public class PacketCapture { public static void main(String[] args) throws Exception { PcapNetworkInterface device = findDevice("192.168.1.100"); // 按IP匹配网卡 PcapHandle handle = device.openLive(65536, PromiscuousMode.PROMISCUOUS, 500); // BPF语法过滤器：只抓TCP协议、源或目的端口为8080的包 handle.setFilter("tcp and port 8080", BpfProgram.BpfCompileMode.OPTIMIZE); PacketListener listener = new PacketListener() { @Override public void gotPacket(Packet packet) { System.out.println("抓到报文: " + packet.length() + " 字节"); System.out.println(packet); } }; // 持续抓包100秒，max=0表示不限制抓包数量 handle.loop(0, listener); handle.close(); } private static PcapNetworkInterface findDevice(String ip) throws Exception { for (PcapNetworkInterface dev : Pcaps.findAllDevs()) { if (dev.getAddresses().stream() .anyMatch(a -> a.getAddress().getHostAddress().equals(ip))) { return dev; } } throw new IllegalStateException("未找到IP对应的网卡"); } }这段代码展示的是完整的抓包流程：定位设备、打开句柄、设置BPF过滤器、循环抓包、关闭资源。核心要点在setFilter那一行，BPF（Berkeley Packet Filter）语法是pcap系工具通用的过滤表达式，tcp and port 8080只放行TCP协议并且端口为8080的包，抓包量可能比不过滤时少几个数量级，分析压力瞬间降下来。如果过滤器字符串写错，openLive和setFilter会抛PcapNativeException，报错信息里会指出哪一段表达式无法编译。
参数说明：openLive的第一个参数65536是snaplen，第二个PROMISCUOUS表示混杂模式——在这种模式下网卡会接收目的地不是自己的包，这是流量分析软件必不可少的设置；第三个500是timeoutMillis，抓到的包会先进入内核缓冲区，最多500毫秒内就会被用户程序读取。handle.loop(0, listener)中的0表示无限抓包，直到手动调用handle.breakLoop()或程序结束。loop方法内层的回调逻辑切不可做耗时操作，比如数据库写入或大文本拼接，回调会在抓包线程里同步执行，回调慢了，内核缓冲区满了，后面的包就会被丢弃。正确的做法是把Packet对象丢给一个阻塞队列，让其他消费者线程去处理。
4. 流量数据的实时统计与展示：把抓到的包变成可视化报告
4.1 五元组聚合：在HashMap与高并发队列之间做选择
抓包回调只是采集端，能不能成为一份「软件」级别的作品，关键在于统计和展示。五元组聚合是流量分析里最常用的统计维度：按源IP、目的IP、源端口、目的端口、协议五个字段做分组key，累计每个分组的包数、字节数、开始时间和最后活跃时间，就能在界面上呈现「当前哪些TCP连接最活跃」。用Java实现时，最自然的做法是定义一个Key类，重写equals和hashCode。
import java.util.Objects; public class FlowKey { public final String srcIp; public final String dstIp; public final int srcPort; public final int dstPort; public final String protocol; public FlowKey(String srcIp, String dstIp, int srcPort, int dstPort, String protocol) { this.srcIp = srcIp; this.dstIp = dstIp; this.srcPort = srcPort; this.dstPort = dstPort; this.protocol = protocol; } @Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof FlowKey)) return false; FlowKey that = (FlowKey) o; return srcPort == that.srcPort && dstPort == that.dstPort && protocol.equals(that.protocol) && srcIp.equals(that.srcIp) && dstIp.equals(that.dstIp); } @Override public int hashCode() { return Objects.hash(srcIp, dstIp, srcPort, dstPort, protocol); } }这里重写equals和hashCode是必须的，否则存进HashMap之后，内容完全相同的key会被视为不同对象，统计就会分散。写完这个Key类之后，维护一张ConcurrentHashMap<FlowKey, FlowCounter>就能支撑并发更新。注意抓包回调线程只有一个，但统计消费线程可能有多个，用ConcurrentHashMap而不是普通HashMap可以避免扩容时报ConcurrentModificationException。FlowCounter里建议用AtomicLong而不是long，否则在多线程累加计数时会有丢失更新问题。
参数说明：protocol字段建议存字符串而不是数字，比如"TCP"/"UDP"/"ICMP"，避免后续展示时再转换。srcIp和dstIp直接用String存字符串形式，虽然比byte[4]多占内存，但对课设级流量规模（每分钟数千包）完全不是瓶颈。如果未来想做成企业级产品，可以换成TupleNetflow里的int编码表示，但那是后话，为学生项目增加太多复杂度不值得。
4.2 实时带宽计算：滑动窗口的正确实现方式
带宽是流量分析软件界面里最抓眼球的数据。常见做法是每秒采样一次：每秒钟统计该秒内累计字节数，然后除以时间间隔得到Bps。但这样算出来的带宽曲线是锯齿状的，不够平滑。实际项目中可以用「滑动窗口」来做：维护一个环形数组，数组的每个槽位存放过去N秒中某一秒的字节数，窗口整体向右滑动。
import java.util.concurrent.atomic.AtomicLongArray; public class BandwidthCounter { private final int windowSizeSeconds; private final AtomicLongArray slots; private volatile int lastSecond = -1; public BandwidthCounter(int windowSizeSeconds) { this.windowSizeSeconds = windowSizeSeconds; this.slots = new AtomicLongArray(windowSizeSeconds); } /** 每抓到一个包，记录它归属的秒以及字节数 */ public void addPacketBytes(int second, int bytes) { int idx = Math.floorMod(second, windowSizeSeconds); int currentSecond; for (;;) { currentSecond = lastSecond; if (second < currentSecond) { // 当前包属于更早的时间窗口，忽略 return; } if (currentSecond == second) { slots.addAndGet(idx, bytes); return; } // 新的一秒到来，清零下一位置并推进秒数 if (compareAndSetLastSecond(currentSecond, second)) { int nextIdx = Math.floorMod(second, windowSizeSeconds); slots.set(nextIdx, bytes); } } } /** 返回近windowSizeSeconds秒的平均带宽（Bps） */ public double getAverageBps(int currentSecond) { long total = 0; for (int i = 0; i < windowSizeSeconds; i++) { if (currentSecond - i > windowSizeSeconds) break; int historicalSecond = currentSecond - i; if (historicalSecond >= 0) { total += slots.get(Math.floorMod(historicalSecond, windowSizeSeconds)); } } return total / (double) windowSizeSeconds; } private boolean compareAndSetLastSecond(int expected, int newValue) { synchronized (this) { if (lastSecond == expected) { lastSecond = newValue; return true; } return false; } } }这段代码看起来比普通写法复杂，但它解决了两个关键问题：一是秒数回绕时槽位会被覆盖，必须在新的一秒到达时把即将使用的槽位先清零；二是多线程下lastSecond的竞争更新。注意compareAndSetLastSecond用了synchronized而不是AtomicInteger的CAS，因为这里不仅仅要比较再赋值，还要在赋值成功后立刻执行slots.set的操作，必须保证原子性。
参数说明：windowSizeSeconds取10到60之间的整数比较常见，太短了看不到趋势，太长了内存浪费且响应迟钝。addPacketBytes的第一个参数要求调用方把包的时间戳换算成Unix秒级整数。实际抓包时如果用System.currentTimeMillis()除以1000，那么每个包的处理会有毫秒级的时差，统计结果是近似正确的；更精确的做法是用pcap4j的PcapTimestamp里的秒字段，直接从底层拿硬件时间戳。
4.3 可视化落地：轻量级Web展示优于Swing
很多课程设计默认用JavaFX或Swing做界面，但在流量分析这个场景里，Web展示是更聪明的选择。理由有两点：第一，图表库的生态差距太大，JavaFX画实时折线图要写大量代码，而用ECharts或Chart.js一条折线图只需要十几行JavaScript；第二，Web界面可以脱离桌面环境访问，答辩演示时用浏览器打开localhost:8080即可，不用在乎评委机器上装没装JavaFX。我一般会在项目里加一个内嵌的HTTP服务，Java标准库的com.sun.net.httpserver.HttpServer就够了，返回JSON数据给前端渲染。
import com.sun.net.httpserver.HttpServer; import com.sun.net.httpserver.HttpHandler; import com.sun.net.httpserver.HttpExchange; import java.io.IOException; import java.io.OutputStream; import java.net.InetSocketAddress; import java.nio.charset.StandardCharsets; public class DashboardServer { private final HttpServer server; public DashboardServer(int port) throws IOException { server = HttpServer.create(new InetSocketAddress(port), 0); server.createContext("/api/bandwidth", new HttpHandler() { @Override public void handle(HttpExchange exchange) throws IOException { // 实际项目中这里应该从BandwidthCounter读数据 String json = "{\"currentBps\":102400,\"averageBps\":89120}"; byte[] bytes = json.getBytes(StandardCharsets.UTF_8); exchange.getResponseHeaders().set("Content-Type", "application/json; charset=utf-8"); exchange.sendResponseHeaders(200, bytes.length); try (OutputStream os = exchange.getResponseBody()) { os.write(bytes); } } }); server.setExecutor(null); // 使用默认执行器 } public void start() { server.start(); } public void stop() { server.stop(0); } }参数说明：createContext里的路径就是前端fetch的URL，每个handler对应一种数据接口。setExecutor(null)表示使用HttpServer内置的默认线程池，并发量不大时够用；如果改变主意要用虚拟线程或自定义线程池，在Java 17之后可以把executor换成Executors.newVirtualThreadPerTaskExecutor()。这段代码里返回的是写死的JSON，实际项目中请换成从统计类里取实时值再序列化。
既然用了HTTP服务，就要考虑接口的JSON字段能被前端chart组件直接消费，建议统一返回{code, data}结构，data里放具体的统计结果，前端根据code是否为0判断是否正常。这样调试接口和排查前端问题都比直接返回乱七八糟的字符串要快得多。
5. 避坑清单：流量分析项目最常见的5个踩坑现场
5.1 抓不到任何包：Npcap版本与权限是两大元凶
现象：程序启动不报错，但抓包循环一直在空转，等了很久一条报文都没有，控制台静悄悄的。
原因：最常见的原因是Windows上装了Npcap但没有勾选「WinPcap API兼容模式」，或者安装的是较新的Npcap版本，默认关闭了老接口兼容。第二个常见原因是以管理员身份运行——libpcap打开设备时需要root/system权限，普通用户权限下打开设备虽然不报错，但网卡不进入混杂模式，导致只能收到发给本机的包，如果本机又没有网络流量，自然一包难求。
解决：先确认Npcap能抓到包——用系统自带的Wireshark验证同一网卡是否有流量；若能，换用管理员身份运行Java程序；若Wireshark也只能看到DNS包，说明网络环境本身没流量，去Ping一下网关制造几个包再抓。Windows上另外再检查一下服务列表里Npcap服务是否启动。
5.2 抓包导致界面完全卡死：回调函数里做了重量级操作
现象：点击「开始抓包」后窗口无响应，过一会儿直接转圈圈，必须强制结束进程。
原因：抓包lookLoop的回调是在pcap内部线程里执行的，如果在回调里做数据库INSERT、JSON序列化、界面刷新等操作，每次回调都可能耗时几十毫秒甚至几百毫秒。网卡的包到达速率远高于消费速率，内核缓冲区很快被打满，丢包率飙升，界面线程又被抢占，整个程序就像死了一样。
解决：回调里只做一件事——把Packet对象丢入ArrayBlockingQueue<Packet>，队列容量设10000，put不阻塞就add。专门开一个消费者线程从队列里取包做统计、持久化、推送WebSocket。这样抓包回调的耗时被压缩到微秒级，队列成了天然的流量阀。这在流量很大的场景下依然可能丢包，但至少UI不会卡死。血泪经验是：绝对不要在回调里打印到System.out，那会比写数据库还慢。
5.3 统计结果出现负数或异常大数：并发更新没有做好同步
现象：流量监控页面偶尔出现负的带宽值，或者某个TCP连接瞬间显示几百GB流量。
原因：FlowCounter里面的totalBytes如果用long，并且多个线程同时执行totalBytes += packet.length()，在低并发下一般没问题，但在多消费者线程下，丢掉的中间位会导致数据错乱。更隐蔽的是排序算法里用了volatile long还不够。另外带宽计数器秒数回绕时没清零，导致历史值累积到新窗口上，就会看到一颗巨峰。
解决：所有计数字段一律用AtomicLong或LongAdder。带宽秒槽位清零逻辑要参照前面代码里「新一秒先清零再累加」的原则，并且要处理时钟倒退的情况——系统调整时间导致秒数回退，此时应该主动忽略当前包而不是把它累加到未来的槽位里。检查手段也简单：抓100个包后停掉，手工统计抓包文件里各五元组的字节总和，与程序输出的数对比，不一致说明并发写有问题。
5.4 过滤器写了却没用：BPF表达式被静默忽略或编译失败
现象：界面上设置了port 443，但还是能抓到80端口的包，看起来过滤完全没生效。
原因：某些代码里捕获了PcapNativeException异常之后直接打印堆栈并继续打开设备，而实际上setFilter失败的时候设备已经打开了，但过滤条件未被应用。还有一种情况是过滤器写在了openLive之前，此时底层pcap句柄尚未绑定网卡，过滤器设置被忽略。
解决：严格检查异常处理逻辑——setFilter抛出异常时，后续逻辑不应该继续执行，至少要提示用户过滤器无效。顺序上务必先openLive再setFilter。写过滤器时先在线下用tcpdump -d port 8080或Wireshark的过滤表达式框语法检查一下，确保表达式的逻辑和BPF关键字大小写正确。注意pcap4j里的BPF字符串里不能包含中文引号，网上拷贝的教程代码复制粘贴时经常会把单引号变成中文引号。
5.5 程序退出后端口被占用：句柄和HTTP服务没有释放
现象：第二次启动程序时提示Address already in use，或者Npcap设备被占用无法打开。
原因：第一次运行结束时进程被强杀，PcapHandle没有执行close，底层pcap_t资源未被释放，设备处于打开状态。同理，HttpServer没有调用stop时，监听端口被锁定。Windows上这种情况更多，文件句柄不释放还会导致后续抓包文件无法重新写入。
解决：把PcapHandle和HttpServer的生命周期交给finally块，或者实现AutoCloseable使用try-with-resources。PcapHandle的close是幂等的，多次调用不会出问题。Java程序尽可能用Runtime.addShutdownHook里做清理，防止用户直接点关闭按钮退出时资源泄漏。如果端口被占用了，用netstat -ano | findstr 8080找到PID然后强杀，但治本还是要养成释放资源的习惯。
6. 进阶：用Java策略模式把协议解析扩展成插件式框架
到这里基础链路已经全部打通：抓包、解析、统计、展示。但是评审老师大概率会追问一个问题——你这个软件以后要支持新的协议怎么办？这时候千万别回答「改代码重新编译」，引入策略模式是教科书级别的标准化答案。定义一个ProtocolParser接口，每种应用层协议（HTTP、DNS、TLS）都实现这个接口，然后通过一个ParserRegistry把协议类型和解析器做绑定，新增协议只需要加一个新实现类而不用改动主流程。
public interface ProtocolParser { boolean supports(int srcPort, int dstPort, byte[] payload); ParsedResult parse(byte[] payload, int length); }import java.util.ArrayList; import java.util.List; public class ParserRegistry { private final List<ProtocolParser> parsers = new ArrayList<>(); public void register(ProtocolParser parser) { parsers.add(parser); } public ParsedResult dispatch(int srcPort, int dstPort, byte[] payload) { for (ProtocolParser parser : parsers) { if (parser.supports(srcPort, dstPort, payload)) { return parser.parse(payload, payload.length); } } return ParsedResult.unknown(payload.length); } }这里就是用Java策略模式多种组合的具体实践。每个协议解析器是独立的策略对象，运行时动态注册；dispatch根据端口和payload特征选择最合适的解析器，而主流程完全感知不到协议种类。注册逻辑可以用构造器注入，也可以在main里手动new。启用SPI（ServiceLoader）机制还能实现自动发现，但做课设没必要，手写注册列表更直观，出错了也容易排查。
说到验证方法，最有效的做法不是拿真实流量赌运气，而是构造一套回放测试：先抓一份pcap文件存起来，然后写一段代码逐包读取pcap文件，把每个packet的字节数据按顺序喂给统计模块和协议解析模块，把输出结果和用Wireshark打开同一pcap的统计做对比。这样既能验证逻辑正确性，又能在没有网卡权限的机器上跑通全流程——这相当于给自己留了一手「后悔药」。我曾经就是靠这个验证方法在答辩前救回了一个在目标机器上死活开不了混杂模式的项目，当场用离线pcap演示出全部图表，最后评分反而比线上抓包更稳定。
最终要提醒的是：如果要做成真正的软件项目，把抓包、统计、Web展示这三个模块拆成独立的类而不是写在同一个文件里。我自己习惯的做法是把抓包线程设计成可暂停、可恢复的状态机，暂停时只是不往队列里放包，已抓的包继续完成统计，这样演示的时候能展示「暂停后带宽曲线走势不变」这种细节，很能让答辩老师眼前一亮。希望这些思路能帮你把这个项目从交差的Demo做成一个真正拿得出手的作品，也祝你在做流量分析的过程中，把Java并发、JNI交互和网络协议这三块硬功夫一次练扎实。
本文还有配套的精品资源，点击获取
