简介在二进制分析与软件供应链安全领域识别编译器的家族与版本是一项基础而关键的分类任务。其核心原理在于不同编译器在指令序列、字节分布与节区结构上会留下独特的“指纹”通过提取这些有区分度的特征并构建有监督分类模型即可实现自动化识别。实际工程中特征工程质量往往决定模型上限而交叉编译矩阵的构建与防数据泄漏的设计更是成败关键。该技术广泛应用于恶意软件检测、漏洞溯源与供应链审计等场景。针对此类任务树模型因其对低维特征、小样本的稳健表现成为默认起点配合宏F1评估与阈值校准可有效提升跨版本泛化能力。本文从训练集构造到模型调参再到论文与答辩输出提供了一套完整的实践路径。1. 编译器版本识别这题到底在考什么拿到这个赛题时很多人第一反应是“这算什么数学建模”。一根二进制文件摆在面前要你说出它是哪个编译器、哪个版本编出来的——听起来像取证不像建模。但等到真正动手你才会发现这道题的核心不是“识别”而是“在一堆特征与一堆标签之间找到一条让分类器稳定的路”。编译器版本识别本质上是一个典型的有监督分类问题输入是编译产物的指令序列、字节分布、节区结构输出是编译器家族与版本号。它考察的不是你有没有现成的模型而是你能不能自己造出高质量的训练集、提取出有区分度的特征并在一套不完美的评测约束下把实验做干净。这道题适合两类人。一类是准备冲奖的队伍完整走一遍能积累扎实的特征工程经验另一类是对二进制分析感兴趣、想在后续做恶意软件检测或供应链审计的从业者——版本识别往往是这些方向的前置步骤。我建议把它当成一次工业级分类项目来对待而不是当成题目来答。下面这六章会按这个思路展开先讲训练集的构造再讲特征和模型然后是论文与PPT的输出最后把最容易翻车的地方一次性排掉。2. 先别碰模型把训练集做出来才算入门2.1 指令序列与字节分布两类最值得提取的原始特征编译器版本识别的特征来源常见做法是两级递进。第一级是反汇编级特征把二进制文件反汇编成指令序列统计各类指令的频率、指令搭配的规律。不同编译器在生成指令时存在明显倾向比如某个编译器在循环优化时偏好使用特定跳转指令另一个编译器则倾向用更短的字长编码。这套特征能直接反映编译器的代码生成策略信息量最高。第二级是字节级特征直接分析二进制文件的原始字节分布、信息熵、N-gram频率等。字节级特征不需要反汇编工具处理速度快而且对编译器加壳或混淆不敏感。但它的问题也很明显——单看字节直方图你很难区分“版本差异”和“代码自身差异”所以我在实际项目中通常把它当辅助特征而不是主力。提取指令序列这步我一般会先对二进制做一次预处理剔除符号表和调试信息避免模型学到“文件名直接暴露编译器”这类作弊特征。反汇编工具常见的有 Capstone、objdump、Ghidra、radare2赛题环境下我优先用 Capstone因为它是 Python 库好写管线也能直接处理比赛中常见的二进制格式。下面这段代码演示如何把 ELF 文件反汇编成指令助记符序列from capstone import Cs, CS_ARCH_X86, CS_MODE_64 from elftools.elf.elffile import ELFFile def extract_instructions(filepath): 从 ELF 文件中提取反汇编指令序列 instructions [] with open(filepath, rb) as f: elf ELFFile(f) code elf.get_section_by_name(.text) if code is None: return instructions data code.data() base_addr code[sh_addr] md Cs(CS_ARCH_X86, CS_MODE_64) md.detail True for insn in md.disasm(data, base_addr): instructions.append(insn.mnemonic) return instructions这段代码的核心逻辑是打开 ELF 文件取.text节也就是真正存放代码的区域把这一节的原始字节交给 Capstone 做线性反汇编得到一串助记符序列。逻辑说明有一点需要特别注意——线性反汇编对数据混在代码段里的情况会有误判但对赛题来说已经够用。参数说明里CS_ARCH_X86, CS_MODE_64是针对 64 位 x86 架构的如果你拿到的样本是 ARM 或 32 位这两个参数要跟着换。.text节是代码段不假但现代编译器还会生成.init、.plt等附加代码节追求完整的话可以把多个节的指令都合并进来这一点在后面的避坑章节会展开。拿到指令序列后不要急着统计频率。先把高维指令序列压成指令类别。x86 指令上千种但同一类功能的指令比如所有条件跳转可以合并成一类这能大幅降低特征维度。接下来的统计维度我建议按下面几个来算指令类别频率、Top 20 指令的占比、指令长度分布、基本块平均长度。这四个维度组合起来基本能把“编译器在代码生成层面的风格”刻画出来而不仅仅是“某个指令出现了几次”。2.2 多版本编译样本的生产流程交叉编译矩阵与划分赛题一般会直接给一批二进制文件但直接拿题目给的样本来训练大概率翻车——数量不够、类别不均衡、标签可能也不细。所以常见的可靠做法是先搞一批开源 C 代码用本地环境交叉编译出不同编译器、不同版本的样本自己构建一个有规模的训练集。我把这个过程叫作交叉编译矩阵。矩阵的行是编译器版本列是优化级别-O0、-O1、-O2、-O3、-Os再加上目标架构、是否开启静态链接等参数。之所以必须把优化级别作为独立的维度是因为同一编译器在不同优化级别下生成的代码差异极大如果训练集里只覆盖了-O2评测样本里一旦出现-O0模型会瞬间崩盘。编译器版本识别最容易翻车的点不是“分不清 GCC 的两个小版本”而是“把优化级别差异当成了编译器差异”。下面这段 Bash 脚本展示了如何构建一个最小可用的交叉编译矩阵#!/bin/bash # 构造编译器版本识别训练样本以 3 个编译器 x 5 个优化级别为例 declare -a compilers(gcc-9 gcc-12 clang-14) declare -a optlevels(-O0 -O1 -O2 -O3 -Os) SRC_DIR./bench_src OUT_DIR./train_samples for comp in ${compilers[]}; do for opt in ${optlevels[]}; do outdir${OUT_DIR}/${comp}${opt//-/_}/ mkdir -p $outdir for src in $SRC_DIR/*.c; do fname$(basename $src .c) $comp $opt -o $outdir/$fname $src 2/dev/null done done done脚本的逻辑说明compilers和optlevels两个数组构成笛卡尔积每个组合一个独立目录目录名直接带上编译器名和优化级别这等于给样本打上了标签。opt//-/_是把-O0转成_O0避免目录名歧义。参数说明里comp变量是你系统里实际安装的编译器命令名不同 Linux 发行版可能把 GCC 装成gcc-9、gcc-12这样的多版本共存结构$opt直接作为编译参数传给编译器你要是想覆盖架构差异还可以在这个脚本里加一个-march参数。2/dev/null把编译报错丢弃是为了在批量处理时不被无关错误打断。编译源文件我建议选十几段功能差异明显的真实代码比如压缩库、哈希函数、矩阵运算、JSON 解析器等。不要用那种只有几百字节的模板代码太短的函数会让编译器没有优化空间不同编译器之间的风格差异体现不出来。每组编译产物尽量控制在几十 MB 的量级特征提取是 CPU 密集操作样本太庞大会拖慢后面的实验迭代。数据集划分这步非常关键。我踩过一个坑——直接按文件随机切训练集和测试集模型准确率飙升到 99%。后来换成“按源码划分”即在训练集和测试集里出现的源代码互不重叠准确率立刻跌到 90% 以下。这说明模型之前已经记忆了源码特征而不是在学习编译器特征。对编译器版本识别而言数据泄漏是最容易犯、也最致命的错误具体原因我会在第 5 章展开。2.3 特征向量化从原始字节到固定维度拿到一票样本之后要把每个二进制文件转成一条固定长度的数值向量。这一步决定了后面模型的上限处理不好会导致算法再好也白搭。特征工程的关键逻辑是这样反汇编后的指令序列长度不一文件字节数也不一但分类器要求输入维度一致。所以要做的是把“变长结构”折算为“定长向量”。我对每个样本提取以下维度的特征组合成一个 40 维左右的向量特征分组具体维度维度数量指令类别频率跳转、算术、逻辑、访存、栈操作、调用、返回、其他8Top 指令占比频率最高的前 20 条指令各自占比20字节统计熵、冗余度、文件大小对数3结构特征节区数量、.text节占比、符号数量3基本块特征平均基本块长度、基本块数量2N-gram 特征字节对2-gram最频繁的 4 项及其频率4不要把原始字节向量直接喂给模型那样维度高、噪声大还容易过拟合。我一般会先用 Python 把这些特征固化到磁盘上方便不同模型共享特征集。import numpy as np def extract_features(inst_seq, byte_entropy, text_ratio, n_sections, n_syms): 将反汇编指令序列转成定长特征向量 inst_categories { jmp: 0, je: 0, jne: 0, jg: 0, jl: 0, # 跳转 mov: 1, lea: 1, push: 1, pop: 1, # 访存/栈 add: 2, sub: 2, xor: 2, mul: 2, # 算术 call: 3, ret: 4, # 调用 } vec [0] * 5 for ins in inst_seq: if ins in inst_categories: vec[inst_categories[ins]] 1 total len(inst_seq) or 1 vec [v / total for v in vec] vec [byte_entropy, text_ratio, n_sections, n_syms] return np.array(vec, dtypenp.float32)逻辑说明代码把指令助记符映射到 5 个大类统计每个类别的占比再拼接上字节熵、节区占比、节区数量和符号数量最终得到 9 维向量——实际工程中你应该在这个基础上继续扩展类别映射表。参数说明里byte_entropy是文件字节熵反映二进制内容的随机程度不同编译器产物的熵值通常有差异text_ratio是.text节字节数占总字节数的比例结合节区数量基本能排除掉“文件大不是因为代码多而是因为数据多”的干扰。这段代码是个骨架你拿到实际赛题数据后应当把特征数扩到 40 维左右再往模型里送。到这里训练集和特征管线已经就绪。接下来模型选择就有了基础——你可以用同一份特征矩阵快速比较不同算法而不需要为每个算法单独做特征工程。3. 模型选型为什么树模型是这类题目的默认起点3.1 特征维度不高树模型比神经网络更稳编译器版本识别的典型特征是维度低几十维、样本量不大几百到几千条、特征间存在明显交互。这种数据形态下树模型天然占优势因为它的决策边界是分段常数单棵树就能捕捉“某个优化级别导致某条指令占比显著上升进而指向某个编译器版本”这样的规则。我在实际项目中最早用过神经网络准确率看得到上升但有两个问题很被动一是工业场景下要解释“为什么把样本判成 GCC 12”神经网络给不出一个清晰的人工可读规则二是小样本下几层全连接网络很容易过拟合训练集里的非典型样本。换成随机森林之后准确率没有掉太多但调试时间缩短了一半——你能直接看特征重要性知道模型到底在用哪些特征做判断这对论文里的“模型分析”一节简直雪中送炭。选择树模型还有一个理由它对特征尺度不敏感。特征向量里的“熵”和“节区数量”量纲差异巨大逻辑回归或 SVM 需要先做标准化而树模型只需要做分裂不需要关心尺度。这省掉一步预处理也让特征的含义可以保持原始语义在论文里解释起来更顺。梯度提升树GBDT通常比随机森林更能压精度但参数多调参成本也高。我的习惯是先用随机森林跑通基线再试一版 XGBoost 或 LightGBM比较宏 F1 之后决定最终提交版本。3.2 基线实验交叉验证与评价指标选择赛题普遍是类别不平衡的版本多的编译器天然比版本少的更容易被预测。所以评价指标不要只盯 accuracy要往 macro-F1 和混淆矩阵这两个方向看。macro-F1 对每个类别一视同仁能暴露“模型只学好了样本多的编译器版本冷门版本全判错”的问题。三类样本特别容易出现这种情况因为样本数量也许相差十几倍。基线代码逻辑上要一次性完成三件事加载特征矩阵、划分数据、做带分层和打乱的交叉验证。分层stratified保证每一折里各类别占比接近总体否则小版本类别可能在某折里消失导致分数剧烈波动。import pandas as pd from sklearn.model_selection import StratifiedKFold, cross_val_score from sklearn.ensemble import RandomForestClassifier df pd.read_csv(features.csv) # 每行一个样本 X df.drop(columns[label, filepath]).values # 去掉标签和文件路径 y df[label].values skf StratifiedKFold(n_splits5, shuffleTrue, random_state42) model RandomForestClassifier( n_estimators400, max_depth20, min_samples_leaf3, max_featuressqrt, n_jobs-1 ) # 使用 宏F1 作为主要评估口径 scores cross_val_score(model, X, y, cvskf, scoringf1_macro) print(macro-F1: %.4f (/- %.4f) % (scores.mean(), scores.std()))逻辑说明交叉验证的每一折里模型只看到 80% 的样本再拿剩下 20% 做预测。shuffleTrue配合random_state42是为了让划分可复现同时避免样本按文件路径排序带来的顺序偏差。参数说明里max_depth20在 40 维特征场景下已经偏深更大的深度不会带来显著提升反而容易把训练噪声记住max_featuressqrt表示每次节点分裂只随机考察 7 个特征40 的平方根它强制模型去尝试不同的特征组合间接提升对未见样本的泛化能力。n_jobs-1是让所有 CPU 核心并行训练特征少、数据量中等时这一步能省大量时间。交叉验证之后我还会把完整训练集上训练出来的模型保存到本地作为最终识别工具的基线。保存模型和读取模型两行代码就够但建议把模型文件和特征列表一起保存否则换环境后特征顺序不一致预测结果会变成玄学。3.3 调参的三个抓手树深、叶子大小、特征采样模型调参不是网格搜索一把梭。我经验有限时瞎调过一轮结论是先把随机种子固定再依维度逐个看模型对参数的反应。对于编译器版本识别有 3 个参数要优先调第一个是max_depth。树深直接控制模型复杂度。编译器版本识别里浅树5-10 层通常已经能捕捉“某些版本独有指令占比异常”这样的大规则深树30 层几乎必然在教模型背出训练样本里的个别文件特征。常见调法是先设大值让模型去学然后逐步剪枝看宏 F1 的拐点。第二个是min_samples_leaf。这个参数的意义是防过拟合的防线——每个叶子节点至少要有多少样本量。设成 1模型容易把单个异常样本学成规则设成 10模型会牺牲掉尾部的少数类精度。我通常从 3 开始逐步增加到 30观察的是“宏 F1 是否在更多规则被剪掉后出现下降”。第三个是max_features。这个参数削弱单棵树的表达能力靠增加树之间的差异性来提升整体稳定性。编译器版本识别中特征组之间相关性不大指令频率和字节熵几乎独立适当调小这个参数往往能收获微弱的涨点。参数影响对象常见区间风险max_depth模型复杂度8 - 25过大则记忆噪声min_samples_leaf抗噪声能力3 - 30过大则漏掉尾部类别max_features特征多样性0.3 - sqrt(n)过小则单棵树太弱第 5 章避坑部分会再说到另一种情况你发现准确率出奇地高不是模型调得好而是特征里混入了不该出现的字段。在调参之前先把数据管干净。4. 从论文到答辩把建模过程变成可评审的成果4.1 论文结构每部分该写什么评审在看什么很多队伍代码跑得很顺最后栽在论文上。数学建模评阅对“硬核指标”看得重但这个题目的特殊之处在于评委预期你能完整展示一套从原始二进制到最终识别的闭环。论文结构上我建议直接按五段来组织问题重述、数据集构建、特征工程与基线、模型比较与灵敏度分析、结果讨论与不足。数据集构建这一节是最容易被忽略的却往往是论文拉开分差的关键。把第 2 章的交叉编译矩阵放上去明确写出编译器版本列表、优化级矩阵、源码数量然后把样本总量写清楚。评委看到你的数据集是自己构建的会立刻认为你理解了题目本质而不是拿题目附带样例硬跑一个模型然后堆几个指标。问题重述部分不要复述题目原话把问题翻译成“编译器版本识别属于软件供应链场景下的细粒度分类问题”这种表述目标是把问题嵌入一个真实的工程语境。优化级别作为环境变量这一点要在问题重述时明确提出因为多数队伍可能会忽视它才是识别任务的最强干扰项。4.2 PPT 的逻辑链一页流程图讲完识别流程PPT 做答辩时最怕的是把论文内容全贴上去评委的问题你没有覆盖。我建议 PPT 主线控制在 10-15 页逻辑链是题目理解 - 数据生产 - 特征提取 - 模型比较 - 案例分析 - 改进方向。每页必须有唯一结论比如“交叉编译矩阵覆盖 3 编译器 x 5 优化级共 1500 个训练样本”。流程图的画法建议采用一条横向流水线输入二进制文件 - 静态解析与节区提取 - 反汇编并归一化指令 - 特征统计与拼接 - 树模型分类 - 输出版本标签 置信度。这条链要一页画完让评委一眼看到你的技术路线。答辩时评委最常见的问题有两个。第一个是“你的模型在真实世界的编译器上效果怎么样”对应的是跨版本迁移验证你需要准备一张测试表列出模型从没见过的编译器版本写清楚准确率下降幅度。第二个是“如果替换了优化级别怎么办”这考察的是你对任务本质的理解回到论文里对优化级别的分析来答即可。补充一句PPT 上不要贴完整代码挑核心代码页放一屏就够了重点在结构。4.3 灵敏度分析把“为什么选它”补成实验证据“为什么用随机森林而不是 SVM”这类问题单靠理论解释很容易被追问。最稳的回答方式是摆实验。灵敏度分析就是做这个用的——固定其他条件在一个维度上变动观察指标怎么变用曲线说话。我一般做三组灵敏度实验改变训练样本量从 500 到 2000 条步进 250观察宏 F1 是否趋于收敛改变特征维度10 维到 50 维识别关键特征是哪个改变优化级别是否参与训练考察模型在未知优化级上的鲁棒性。这三组实验呈现在论文里既证明了“选树模型是实验筛选出的结果”又体现你对数据规模敏感度的理解。这部分的表格建议用两列变动项和指标变化趋势。比如实验维度观测结果训练样本量宏 F1 在样本量 1500 时趋于平缓特征维度40 维为最优超过 50 维开始过拟合优化级别是否参与训练参与训练后宏 F1 提升 6%跨版本稳定性显著增强每张表都要有一句话解读不要让评委自己猜结论。这三张表会被评委反复挑刺所以做实验时要保留中间结果答辩被追问“为什么在 40 维收敛”时你才能就地展开特征重要性排名和数据细节而不是打补丁式辩护。5. 编译器版本识别避坑指南数据泄漏与特征错觉5.1 现象一测试集准确率虚高到接近满分现象随机切分训练/测试集随机森林宏 F1 达到 0.98你以为项目成了。但把训练好的模型放到新收集的二进制文件上准确率骤降到 0.8 以下。 原因同一份源码文件被编译成多个版本训练集和测试集里包含来自同一源码的产物。模型学到的是“这个源码的函数调用结构对应哪个版本”而不是“不同版本编译器生成的代码有什么差异”。 解决划分数据集时以源码文件为粒度每个源码对应的所有编译版本分到同一侧。具体说交叉编译矩阵生成样本后按源码名 hash 分入训练/测试保证测试集里的任何源码不在训练集中出现。5.2 现象二换一个编译器小版本就崩现象模型在 GCC 9、GCC 10 上表现不错但评测时加入 GCC 11宏 F1 断崖式下跌。 原因训练集中把优化级别作为混在特征里的标量字段或者没有覆盖多种优化级别。模型无法把“GCC 11 在 -O3 下的代码风格”同它见过的其他优化级别建立关联。 解决扩展交叉编译矩阵把优化级别覆盖全。至少保证每个编译器版本都有-O0、-O2、-O3三档。测试时最好专门留一档评测期才出现的优化级别用来量化模型的跨条件鲁棒性。5.3 现象三信息熵特征几乎不提供区分度现象单用字节直方图和熵做特征模型分类准确率只有五成和随机猜差不多水平。 原因熵和直方图是全局统计量不同编译器生成的代码在宏观统计上差异不大差异集中在指令序列的结构与组合方式上。全局统计掩盖了序列内部的排列信息反而把微弱信号淹没了。 解决引入指令 n-gram 频率特别是 2-gram 和 3-gram。同一个指令前后拼接的方式比单个指令频率更能反映编译器的调度算法倾向。补充基本块平均长度、最长跳转距离这类序列结构特征。5.4 现象四把节区信息当特征后效果反而变差现象加入.text节偏移地址、节区数量、节区大小后训练集上分数不错但跨机器/跨环境验证时分数明显下降。 原因节区偏移地址与链接脚本、机器环境相关与编译器本身的代码生成策略关联极弱。模型把环境特征学进去当成“编译器版本”的特征来用。 解决只保留有代码生成语义的特征。节区数量和.text占比可以用但“节区在文件中的物理偏移”这类布局特征不要进模型。你甚至可以做一个快速验证把二进制文件用工具重写一遍节区顺序看模型预测有没有变化变了就说明模型又被布局特征带偏了。5.5 现象五类别不平衡导致冷门版本全部被判错现象模型打印出的 classification_report 里样本量多的编译器版本 F1 值很高冷门版本 F1 为 0。 原因默认的分裂准则偏向多数类加上交叉验证分层时类别太少冷门类的训练样本量本身就不足以支撑决策边界。 解决训练时给少数类样本加 class_weight或者用 SMOTE 过采样作为基线比较。另一个技巧是把冷门版本的种族特征备份到展示数据里论文里专门放一个混淆矩阵方块图说明模型对冷门类别的实际误差模式和标注质量问题——这类讨论往往是拿分点。这些坑没有优先级高低的区别任何一个都可能让冲刺加分变成翻车冷汗。实操时我建议先按第 2 章的流程完整走一遍再回头逐条对照比自己从模型调参开始摸索快得多。6. 进阶技巧用阈值校准和混淆矩阵把论文做实模型跑通只是第一步。要让论文有说服力、答辩有支撑还差两层功夫一是预测置信度处理二是错误模式分析。置信度处理上树模型输出的概率不能直接当成最终标签用。随机森林的平均机制会导致概率值偏向 0.5 附近尤其在类别不平衡时输出 0.55 的预测可能早就该被判成别的类。我的习惯是做一次阈值校准在验证集上按宏 F1 最大化的原则搜索分类阈值。具体做法是遍历 0.3 到 0.7 的阈值范围找到让宏 F1 最高的临界值然后在预测阶段把“低于该阈值的样本”标记为低置信度留给人工复核而不是强行给出一个可能错误的标签。def find_best_threshold(model, X_val, y_val, step0.05): 在验证集上搜索最优置信度阈值返回使宏F1最高的阈值 from sklearn.metrics import f1_score proba model.predict_proba(X_val) best_thr, best_f1 0.5, 0 # 把置信度阈值从0.3扫到0.7每隔0.05试一次 for thr in np.arange(0.3, 0.75, step): pred (proba[:, 1] thr).astype(int) score f1_score(y_val, pred, averagemacro) if score best_f1: best_f1, best_thr score, thr return best_thr, best_f1这段函数对有标注的验证集计算每个阈值的 F1返回最优阈值与对应分数。逻辑说明二分类代码展示的是核心寻找逻辑你若要扩展到多分类就要把各类的概率列看成一个矩阵策略改成“取最大概率与二阶概率差值”作为置信度。参数说明里的step0.05决定了搜索粒度阈值样本少时可以设小些。这个最优阈值等答辩时写在论文里比直接报告模型默认 0.5 阈值的 F1 可信得多。错误模式分析要落到混淆矩阵上。单独贴一张ConfusionMatrixDisplay图很常见但真正有价值的是能从矩阵里读出来的规律明显相邻编译器版本互相误判说明模型在学连续演化特征这是合理的样本量大的主流版本误判到旁边版本说明标签标注有交叉需要回头检查数据集构造脚本有没有在编译器参数上给错标签如果是冷门版本被系统性误判成相近的主流版本那大概率是交叉编译矩阵里有源码重叠数据泄漏的锅。我在实际项目中吃过一次亏。模拟项目X里测试集按文件随机切模型得分很高答辩现场评委只问了一句“测试集和训练集源码重复吗”就卡住了。后来我把划分逻辑改回按源码重新跑模型论文里专门加了一节“划分策略对评估结果的影响”反而成了亮点。做一个题的收获不在把题做完而在把“为什么这么做”想透。每做完一轮实验我都会把失败现象、原因、解决方式整理成记录再回头看时之前踩坑的模糊记忆全变成可复用的判断清单。这篇文档按这个流程走下来上手大约需要两到三天第一天搭交叉编译矩阵和特征提取第二天跑模型和阈值校准第三天写论文补实验图表。如果你的目标是赛题拿奖压缩到两天也能跑完但答辩提问环节会少很多背靠实验过程的底气。希望这些拆解能帮你在编译器版本识别这个方向上少走几步弯路做得比大多数人更靠前一点。本文还有配套的精品资源点击获取