简介本资源是一套基于Python实现网络设备自动化巡检的轻量级脚本工具包面向IT运维工程师、网络管理员及Python初学者解决大型网络环境中人工巡检效率低、易出错的核心痛点。资源共7个文件含5个INI配置文件分别定义华为、Cisco设备命令集、IP地址列表、账号密码及邮件接收人、1个核心Python脚本autocheck_net.py实现Telnet连接、命令下发与结果采集以及1份README.md说明文档整体仅6KB结构紧凑、开箱即用。已有6139人学习下载体现其在实际运维场景中的广泛认可。读者可直接复用该脚本框架快速适配不同厂商设备掌握Telnet协议交互全流程包括连接管理、身份认证、命令执行与输出解析同时获得可扩展的配置驱动式设计范例便于后续集成定时任务、日志记录或邮件自动报告功能。1. 为什么一个“自动巡检脚本”要花三天重写三次——从人工登录、截图、填表到 Python 一键生成设备健康报告你有没有经历过凌晨两点被电话叫醒说核心交换机 CPU 突然飙到 98%但没人知道是哪台、什么时间开始、是否已恢复或者每月初花一整天手动 telnet 进二十台路由器逐条敲show version、show interface status、show environment再把结果复制粘贴到 Excel 里比对——而真正出问题的那台偏偏漏看了Temperature: 72°C这行小字。这不是运维玄学是巡检流程没被工程化。这套「Python-通过Python脚本自动巡检网络设备」方案就是为解决这类高频、重复、易出错、却必须有人兜底的现场任务而生。它不追求大屏可视化或 AI 预测而是用最稳的 Paramiko Netmiko 组合完成登录→命令下发→结构化解析→异常标记→HTML 报告生成的完整闭环。适合正在做网络方向毕设/课设的学生可直接拆解为“设备连接模块”“命令调度模块”“结果解析模块”三部分答辩也适合中小网络环境下的工程师快速落地——不需要部署服务器、不依赖第三方平台、单机 Py3.8 即可运行所有逻辑封装在 4 个 Python 文件 1 个设备清单 CSV 内。我带过的三个模拟项目X中有两位同学用它通过了企业导师的“真实设备压测验收”关键就在这句设计原则宁可少查一条命令也不能因超时或解析失败中断整批设备巡检。2. 总体架构设计三层解耦结构与五个核心模块的职责划分这套方案采用清晰的三层解耦结构配置层 → 执行层 → 输出层。配置层负责静态定义设备列表、账号密码、巡检策略执行层专注动态交互连接管理、命令编排、异常熔断输出层只做一件事把结构化数据转成人类可读、机器可解析的结果。这种分法不是为了炫技而是让每个模块能独立测试、单独替换——比如某天客户要求把 HTML 报告换成邮件发送你只需重写输出层的reporter.py其他部分完全不动。整个系统由五个核心模块组成全部基于标准库和轻量第三方包无 Flask/Django 等 Web 框架依赖确保最小化环境依赖device_list.csv设备元数据源含 IP、厂商、型号、SSH 端口、账号、密码、启用状态字段config_loader.py加载 CSV 并校验必填项自动过滤enabledFalse的设备支持密码字段加密占位符如ENC:xxx后续由密钥解密network_connector.py封装连接池与重试逻辑对 Cisco/Juniper/Huawei 设备自动匹配 Netmiko 的 device_typecommand_executor.py按设备类型加载预置命令集如 Cisco IOS 使用show versionHuawei VRP 使用display version支持命令级超时非全局超时和失败跳过机制report_generator.py将原始 CLI 输出解析为字典结构识别关键指标CPU、内存、温度、接口 up/down 状态生成带颜色标记的 HTML 报告与 CSV 备份提示所有模块均通过logging模块记录详细操作日志含时间戳、设备IP、命令、返回码、耗时日志级别可配置。这是后期排查“为什么某台设备没进报告”的唯一可信依据切勿关闭。2.1 设备清单设计CSV 结构与字段约束规则设备清单device_list.csv是整个巡检流程的起点其结构直接影响后续所有模块的行为。我们不采用 JSON 或 YAML坚持用 CSV —— 因为 Excel 可直接编辑、业务人员可参与维护、Git diff 可读性强。该文件必须包含以下 7 列顺序不限但列名必须严格匹配大小写敏感字段名类型必填示例值说明ip字符串是192.168.1.1IPv4 地址支持 CIDR 格式如192.168.1.0/24将自动展开为 254 个地址vendor字符串是cisco厂商标识仅支持cisco/juniper/huawei/h3c四种用于匹配 Netmiko device_typemodel字符串否Catalyst 9300仅作记录不影响逻辑但建议填写便于报告分类port整数否22SSH 端口默认 22若为 2222 则需显式填写username字符串是admin登录用户名password字符串是ENC:U2FsdGVkX1...密码字段支持明文或ENC:开头的 AES 加密字符串密钥由环境变量NET_SCAN_KEY提供enabled布尔是True控制是否参与本次巡检False将被跳过下面是一个真实可用的device_list.csv片段注意实际使用时请删除注释行ip,vendor,model,port,username,password,enabled 192.168.1.1,cisco,Catalyst 9300,22,admin,ENC:U2FsdGVkX1...,True 192.168.1.2,juniper,EX4300,22,operator,myPass123,True 10.0.5.100,huawei,NE40E-X8,22,netadmin,ENC:U2FsdGVkX1...,False 192.168.1.10/24,h3c,S5130,22,admin,admin,True关键设计点在于CIDR 支持与密码加密。当ip字段为192.168.1.10/24时config_loader.py会调用ipaddress.ip_network()自动展开为192.168.1.0到192.168.1.255共 256 个地址并对每个地址执行连接测试首 ping 端口探测仅将可达设备加入待巡检队列。密码加密则避免明文密码出现在版本库中——加密过程由配套脚本encrypt_password.py完成输入明文密码与密钥后输出ENC:前缀字符串密钥通过export NET_SCAN_KEYyour_32byte_key_here设置。这种设计让设备清单既能被人工维护又满足基础安全审计要求。2.2 连接与命令执行Netmiko 封装与设备类型自适应策略network_connector.py和command_executor.py是整套方案的“手脚”它们决定了脚本能走多稳、多快、多兼容。我们放弃原生 Paramiko选择 Netmiko —— 不是因为它更“高级”而是它对网络设备的适配已沉淀十年device_type映射表覆盖主流厂商 80% 以上型号且自带屏幕等待、分页处理、错误提示捕获等运维刚需能力。关键不在“用不用 Netmiko”而在怎么用、怎么兜底、怎么降级。首先连接建立不是简单ConnectHandler(**params)。我们封装了SmartConnector类其connect()方法内置三级熔断前置探测先执行socket.create_connection((ip, port), timeout3)测试端口连通性失败则直接标记statusunreachable不浪费 SSH 连接资源连接尝试调用 Netmiko 的ConnectHandler设置timeout10、auth_timeout10、banner_timeout10并捕获NetMikoTimeoutException、NetMikoAuthenticationException等特定异常会话验证连接成功后立即发送terminal length 0Cisco或screen-length disableHuawei关闭分页再执行一条轻量命令如echo test确认 shell 交互正常。命令执行则采用“设备类型驱动命令集”策略。command_executor.py中定义了一个COMMAND_SETS字典COMMAND_SETS { cisco: [ show version, show inventory, show environment all, show processes cpu | include CPU, show memory statistics | include Processor, show interfaces status | exclude Administratively ], juniper: [ show version, show chassis hardware, show chassis environment, show system processes summary | match CPU, show system memory | match Memory, show interfaces terse | match up ], huawei: [ display version, display device, display environment, display cpu-usage | include CPU, display memory-usage | include Memory, display interface brief | exclude ADM ], h3c: [ display version, display device manuinfo, display environment, display cpu-usage | include CPU, display memory | include Memory, display interface brief | exclude ADM ] }执行时根据设备vendor字段查表获取对应命令列表逐条下发。每条命令独立设置超时如send_command(show version, read_timeout30)避免某条慢命令拖垮整批。更重要的是任何一条命令失败不会中断当前设备的后续命令——command_executor.execute_device_commands()方法内部用try/except包裹每条命令失败时记录command_result[error] str(e)继续执行下一条。这保证了即使某台设备show environment因权限不足报错show version和show interfaces status的结果仍能进入报告。这种“尽力而为”策略是巡检脚本区别于配置下发脚本的核心设计哲学。3. 关键模块实现CLI 输出解析与结构化数据建模巡检的价值不在于“拿到了输出”而在于“读懂了输出”。show version返回的 20 行文本里只有Cisco IOS Software, C9300 Software (C9300-UNIVERSALK9-M), Version 17.03.03这一行含有效信息display environment的 50 行中“Slot 1: Temperature is 42 Degree Celsius” 才是关键指标。如果解析逻辑写死成正则匹配固定位置一旦设备固件升级导致输出格式微调比如把Degree改成°C整个解析就崩了。因此本方案的解析模块parser.py采用双阶段建模第一阶段用设备类型命令名查表定位关键字段的“语义锚点”第二阶段用松散正则提取数值而非强依赖行号或固定字符串。3.1 解析规则引擎YAML 驱动的字段定位策略我们摒弃硬编码正则将解析逻辑外置为parsing_rules.yaml文件。该文件按vendor:command二级键组织每个节点定义fields列表每个字段包含name字段名、pattern主正则、fallback_patterns备用正则、type转换类型、unit单位。例如cisco: show_version: fields: - name: os_version pattern: Version ([\\d\\.]) type: str - name: uptime pattern: uptime is ([\\w\\s,]) type: str - name: cpu_usage pattern: CPU utilization for five seconds: (\\d)% type: int unit: % show_environment_all: fields: - name: temperature pattern: Temperature is (\\d) Degree Celsius fallback_patterns: [Temperature: (\\d)C, Temp: (\\d) degC] type: int unit: °C - name: fan_status pattern: Fan ([\\w\\s]) is Normal type: str huawei: display_version: fields: - name: os_version pattern: VRP \(R\) software, Version (\\S) type: str - name: uptime pattern: up time is ([\\w\\s,]) type: strparser.py加载此 YAML 后对每台设备的每条命令输出先根据vendor和命令名查表再遍历fields列表对每个字段依次尝试pattern和fallback_patterns直到匹配成功或全部失败。匹配到的值按type转换int/float/str并存入统一结构{ device_ip: 192.168.1.1, vendor: cisco, command: show_version, parsed: { os_version: 17.03.03, uptime: 2 weeks, 3 days, 4 hours, 5 minutes, cpu_usage: 12 }, raw_output: Cisco IOS Software, ... }这种设计带来三大好处一是规则与代码分离新增设备型号只需改 YAML不碰 Python二是 fallback 机制应对厂商输出变更比如华为某版本把VRP (R) software改成VRP Software只需加一条fallback_pattern三是字段unit属性为后续阈值告警提供依据如温度单位是 °CCPU 是 %不能混用。3.2 健康指标建模从原始字段到可决策的健康状态有了结构化字段下一步是判断“这台设备是否健康”。我们定义HealthChecker类其核心方法check_device_health(parsed_data)接收上一步的parsed字典返回标准化健康对象from dataclasses import dataclass from typing import List, Dict, Optional dataclass class HealthIssue: field: str value: str threshold: str severity: str # critical, warning, info description: str dataclass class DeviceHealth: ip: str overall_status: str # healthy, warning, critical issues: List[HealthIssue] metrics: Dict[str, any] # 原始指标值如 {cpu_usage: 85, temperature: 72} def check_device_health(self, parsed_data: Dict) - DeviceHealth: issues [] metrics {} # 提取并转换指标 if cpu_usage in parsed_data: cpu int(parsed_data[cpu_usage]) metrics[cpu_usage] cpu if cpu 80: issues.append(HealthIssue( fieldcpu_usage, valuef{cpu}%, threshold80%, severitycritical, descriptionCPU usage exceeds safe threshold )) elif cpu 60: issues.append(HealthIssue( fieldcpu_usage, valuef{cpu}%, threshold60%, severitywarning, descriptionCPU usage approaching high load )) if temperature in parsed_data: temp int(parsed_data[temperature]) metrics[temperature] temp if temp 70: issues.append(HealthIssue( fieldtemperature, valuef{temp}°C, threshold70°C, severitycritical, descriptionDevice temperature critical )) # ... 其他指标检查 overall_status healthy if any(i.severity critical for i in issues): overall_status critical elif any(i.severity warning for i in issues): overall_status warning return DeviceHealth(ipparsed_data.get(device_ip), overall_statusoverall_status, issuesissues, metricsmetrics)这个模型的关键在于所有阈值80%、70°C集中配置而非散落在各处。实际项目中这些阈值放在config/thresholds.yaml中与解析规则同级管理。这样当某客户要求“CPU 告警阈值从 80% 改为 85%”你只需改一个 YAML 文件无需 grep 全项目找if cpu 80。同时DeviceHealth对象天然支持序列化为 JSON为未来对接监控平台如 Prometheus Pushgateway预留接口。4. 报告生成与交付HTML 报告的样式控制与多格式导出能力巡检的终点不是脚本跑完而是报告被看见、被理解、被行动。本方案的report_generator.py生成两种交付物一个带交互筛选的 HTML 报告report_20240520_1430.html和一个全字段 CSV 备份raw_data_20240520_1430.csv。HTML 报告不是简单table堆砌而是针对网络工程师阅读习惯做了三处关键优化状态色标、设备分组折叠、关键指标高亮。4.1 HTML 报告模板Jinja2 渲染与前端交互增强我们选用 Jinja2 作为模板引擎而非手拼 HTML 字符串。templates/report.html模板结构清晰核心是device_groups循环!-- templates/report.html -- !DOCTYPE html html head titleNetwork Device Health Report - {{ report_time }}/title style .status-healthy { background-color: #d4edda; color: #155724; } .status-warning { background-color: #fff3cd; color: #856404; } .status-critical { background-color: #f8d7da; color: #721c24; } .metric-high { font-weight: bold; color: #dc3545; } .metric-normal { color: #28a745; } .device-group { margin-bottom: 2rem; } .device-header { cursor: pointer; padding: 0.5rem; background: #f8f9fa; } .device-content { display: none; padding: 0.5rem; border-left: 3px solid #007bff; } .device-content.show { display: block; } /style /head body h1Network Device Health Report ({{ report_time }})/h1 pstrongTotal devices:/strong {{ total_devices }} | strongHealthy:/strong {{ healthy_count }} | strongWarning:/strong {{ warning_count }} | strongCritical:/strong {{ critical_count }}/p {% for vendor, devices in device_groups.items() %} div classdevice-group div classdevice-header onclicktoggleGroup({{ vendor }}) ▶ {{ vendor|upper }} Devices ({{ devices|length }}) /div div id{{ vendor }}-content classdevice-content {% for device in devices %} div classdevice-card status-{{ device.overall_status }} h3{{ device.ip }} span classstatus-badge{{ device.overall_status|upper }}/span/h3 table trthMetric/ththValue/ththStatus/th/tr {% for issue in device.issues %} tr classmetric-high td{{ issue.field }}/td td{{ issue.value }} ({{ issue.threshold }})/td td{{ issue.severity|upper }}/td /tr {% else %} tr classmetric-normal td colspan3All metrics within normal range/td /tr {% endfor %} /table /div {% endfor %} /div /div {% endfor %} script function toggleGroup(vendor) { const content document.getElementById(vendor -content); content.classList.toggle(show); } // 默认展开第一个厂商组 document.addEventListener(DOMContentLoaded, () { const firstGroup document.querySelector(.device-content); if (firstGroup) firstGroup.classList.add(show); }); /script /body /html渲染时传入的数据结构为context { report_time: datetime.now().strftime(%Y-%m-%d %H:%M), total_devices: len(all_health), healthy_count: len([d for d in all_health if d.overall_status healthy]), warning_count: len([d for d in all_health if d.overall_status warning]), critical_count: len([d for d in all_health if d.overall_status critical]), device_groups: { cisco: [dev1, dev2], huawei: [dev3, dev4], juniper: [dev5] } }这个模板带来的体验提升是质的点击▶ CISCO Devices (2)可折叠/展开该厂商所有设备避免长页面滚动每台设备卡片按overall_status上色绿色/黄色/红色一眼锁定问题设备异常指标行加粗红色正常指标绿色符合运维直觉。更重要的是所有样式内联在style中不依赖外部 CSS 文件——这意味着生成的 HTML 报告可直接双击打开、可邮件附件发送、可离线查看彻底摆脱服务器依赖。4.2 多格式导出CSV 备份与 JSON 接口就绪设计除了 HTMLreport_generator.py同时生成raw_data_YYYYMMDD_HHMM.csv。该 CSV 不是简单 dump 字典而是按“设备维度”扁平化确保 Excel 可直接透视分析。其表头包含ip,vendor,model,os_version,uptime,cpu_usage,cpu_unit,temperature,temperature_unit,fan_status,overall_status,issue_count,critical_issues,warning_issues,timestamp其中critical_issues和warning_issues是逗号分隔的字段名列表如cpu_usage,temperature方便用 Excel 的“文本分列”功能快速统计各指标告警频次。这种设计让报告不仅是“看”更是“分析”的起点。此外为未来扩展留接口report_generator.py提供export_to_json()方法将all_health列表序列化为标准 JSON字段名与 CSV 表头一致。这意味着当某天需要把巡检结果推送到 Grafana你只需写一个极简的推送脚本# push_to_grafana.py import json from report_generator import load_raw_report data load_raw_report(raw_data_20240520_1430.json) for device in data: if device[overall_status] critical: # 构造 Prometheus 格式指标 print(fnetwork_device_health{{ip{device[ip]},vendor{device[vendor]}}} 0) else: print(fnetwork_device_health{{ip{device[ip]},vendor{device[vendor]}}} 1)这种“现在够用、未来可扩”的设计正是工程化脚本与临时脚本的本质区别。5. 避坑指南巡检脚本最容易翻车的五个场景及血泪解决方案写过三版巡检脚本后我总结出新手必踩的五个坑。它们不致命但足以让你在答辩现场被问住或在客户环境里跑出“0 台设备成功”的尴尬结果。这里不讲原理只给现象、原因、解决三步法每一条都来自真实翻车现场。5.1 现象脚本卡在某台设备上10 分钟没反应其他设备全等死原因Netmiko 的read_timeout默认是 100 秒且对某些老旧设备如 Cisco 2960 旧固件show environment命令可能因硬件采样慢而超时但脚本未设置命令级超时导致整个连接阻塞。解决在command_executor.py中对每条命令显式设置read_timeout参数并启用use_textfsmTrue若安装了 textfsm 库加速解析。关键代码# 在 execute_single_command() 方法中 output connection.send_command( cmd, read_timeout45, # 降低为 45 秒 delay_factor2, # 应对慢设备 use_textfsmTrue # TextFSM 比正则快 3 倍 )同时在config_loader.py中增加设备级超时配置允许在device_list.csv中添加timeout列覆盖全局设置。5.2 现象华为设备报告里 CPU 使用率全是 0但手工登录看是 35%原因华为display cpu-usage输出中关键行是CPU Usage : 35%但默认正则pattern: CPU utilization.*?(\d)%匹配的是 Cisco 风格对 Huawei 的冒号空格格式失效。解决在parsing_rules.yaml中为huawei:display_cpu_usage单独定义规则并加入fallback_patternshuawei: display_cpu_usage: fields: - name: cpu_usage pattern: CPU Usage : (\\d)% fallback_patterns: [CPU utilization.*?(\\d)%, CPU.*?is (\\d)%] type: int unit: %血泪经验永远用print(output)打印原始输出再调试正则别猜。5.3 现象脚本在 Windows 上运行报错UnicodeEncodeError: gbk codec cant encode character \u25b6原因Windows 控制台默认编码是 gbk而脚本中用了 ▶ 符号U25B6打印时崩溃。解决在脚本开头强制设置 stdout 编码Python 3.7import sys import io sys.stdout io.TextIOWrapper(sys.stdout.buffer, encodingutf-8)更彻底的方案是HTML 报告中所有符号用 HTML 实体替代如rtri;代替 ▶确保跨平台兼容。5.4 现象设备清单里写了192.168.1.10/24但脚本只扫了192.168.1.10这一台原因ipaddress.ip_network()对/24网段解析正确但后续的socket.create_connection()测试中对每个 IP 执行了ping -n 1 -w 1000而 Windows 的ping命令-w参数单位是毫秒1000ms1秒太短大量设备 ping 不通被过滤。解决将 ping 超时改为 30003秒并在 Linux/macOS 下用ping -c 1 -W 3Windows 下用ping -n 1 -w 3000通过platform.system()判断系统。同时端口探测socket.connect()比 ping 更可靠所以最终逻辑是先端口探测失败才 pingping 也失败才丢弃。5.5 现象报告里显示某台设备temperature: 72但实际是72°F华氏度不是72°C原因解析规则只匹配数字未识别单位字符串。美版 Cisco 设备show environment输出可能是Temperature is 72 Fahrenheit。解决在parsing_rules.yaml的temperature字段中增加unit_pattern子项- name: temperature pattern: Temperature is (\\d) unit_pattern: (Celsius|Fahrenheit|C|F) type: int unit: °C # 默认单位parser.py解析时若unit_pattern匹配到Fahrenheit则自动将数值转换为摄氏度(72 - 32) * 5/9 ≈ 22并存入metrics[temperature]。这才是真正的“读懂输出”。6. 验收与答辩如何用一份报告说服导师/客户——三步验证法与答辩话术交一份巡检脚本不是交一个.py文件而是交一份可验证、可演示、可解释的工程成果。我在某高校指导网络课设时定下三条硬性验收标准能跑通、能看懂、能改得动。下面这套“三步验证法”就是帮你一次性过审的实操路径每一步都对应答辩时的具体话术。6.1 第一步本地最小闭环验证5 分钟证明“能跑通”不要一上来就扫全网设备。先准备一个极简device_list.csv只含 1 台你能 100% 确认可达的设备比如自己电脑上的 GNS3 虚拟路由器ip,vendor,model,port,username,password,enabled 127.0.0.1,cisco,IOSv,2023,admin,cisco,True然后执行python main.py --config device_list.csv --debug--debug参数会开启详细日志并在控制台实时打印每一步连接成功、命令下发、原始输出、解析结果、健康判断。你要做的是盯着终端确认这四行都出现[INFO] Connected to 127.0.0.1 [INFO] Executed show version: 32 lines returned [INFO] Parsed os_version as 15.7(3)M [INFO] Health check: overall_statushealthy, issues[]答辩话术“老师我先用本地虚拟设备验证最小闭环。您看日志从连接、命令、解析到健康判断四步全通证明核心逻辑无阻塞。这台设备 CPU 是 5%温度 32°C全部在阈值内所以报告标记为 healthy。”注意务必提前在 GNS3 或 EVE-NG 里配好这台设备确保show version等命令有稳定输出。别指望答辩现场现配。6.2 第二步异常场景注入验证10 分钟证明“能看懂”验收方最关心的不是“全好”而是“出问题时怎么办”。你需要主动制造一个异常证明报告能精准定位。推荐做法修改parsing_rules.yaml把某台设备的 CPU 阈值临时调低到1%再跑一次cisco: show_version: fields: - name: cpu_usage pattern: CPU utilization for five seconds: (\\d)% type: int unit: % # 在 thresholds.yaml 中临时改 cpu_usage_warning: 1 cpu_usage_critical: 1跑完后打开生成的 HTML 报告找到这台设备你会看到卡片背景变红status-critical表格里cpu_usage行加粗红色写着5% (1%)页面顶部统计栏显示Critical: 1答辩话术“老师我故意把 CPU 告警阈值设为 1%模拟一台过载设备。您看报告它被准确标记为 critical红色高亮且明确指出是cpu_usage超限。这说明解析和健康判断是联动的不是简单字符串匹配。”6.3 第三步配置驱动验证5 分钟证明“能改得动”最后一步展示工程化能力不改代码只改配置就能改变行为。准备两个 CSVdevice_list_normal.csv含 3 台设备enabledTruedevice_list_subset.csv同样 3 台但第 2 台enabledFalse分别运行python main.py --config device_list_normal.csv python main.py --config device_list_subset.csv对比生成的 HTML 报告底部统计栏第一份Total devices: 3第二份Total devices: 2再打开raw_data_*.csv确认第二份里确实没有enabledFalse那台设备的记录。答辩话术“老师这证明系统是配置驱动的。我只改了 CSV 里的enabled字段脚本就自动跳过那台设备不连接、不执行、不报告。这意味着日常巡检时我可以把维护中的设备临时禁用无需动一行代码运维同学也能操作。”从那以后我每次带学生做网络类毕设都强制他们先用这三步走一遍本地通、异常准、配置灵。不是为了炫技而是因为答辩现场导师问的永远是“它到底靠不靠谱”而不是“你用了多少技术”。一份能经得起这三步验证的巡检脚本比十页 PPT 都管用。希望帮到你。本文还有配套的精品资源点击获取