简介面向Binary Ninja使用者的Python插件源码包适合安全研究员、逆向工程师以及需要定制二进制分析流程的开发者可帮助解决反汇编流程控制、函数与变量信息提取、自动化分析等场景中的个性化需求。压缩包共6个文件以Python主脚本为核心辅以plugin.json注册插件、defaults.yaml保存默认参数、README说明文档、LICENSE和.gitignore完整呈现一个插件的标准工程结构整体大小仅9KB。目前已有538人浏览学习属于轻量但典型的插件开发示例。通过阅读和运行该插件可以直观掌握Binary Ninja API的调用方式、插件命令注册流程以及配置文件的组织方法还可了解其模块化插件系统中菜单项、视图插件与事件处理器的接入思路。在此基础上可扩展开发指令高亮、函数信息提取、控制流图遍历、恶意代码分析等实用功能对提升逆向工程与自动化分析能力很有价值。1. 插件不是「代码生成」是给二进制分析装上「事件驱动」的脑子很多人第一次接触 BinaryNinja 插件时以为写插件就是在界面上加个按钮、跑段 Python 脚本、把反汇编结果导出成报告。我之前也这么想直到接手一个固件分析项目同一个函数在 32 位 ARM 和 64 位 ARM 下调用约定完全不一样厂商的 SDK 里还有大量结构体指针互相嵌套。用脚本一次性处理根本行不通——因为分析过程本身需要反复修改、回退、查看交叉引用。BinaryNinja 的 Python 插件真正的价值是把你的分析思路变成一套事件驱动的自动化流程让工具在反汇编、反编译、符号解析的每个阶段都能调用你的代码。这篇文章只讲一件事如何用 Python 在 BinaryNinja 里写出真正能反复跑、能扛住脏数据的插件。适合谁看想摆脱「手动点界面、复制反汇编代码」的逆向工程师以及想把自己的分析经验固化成团队工具的安全研究员。后面所有代码我都基于 BinaryNinja 的稳定版 API 写不依赖任何插件市场里的第三方包——很多坑恰恰来自第三方封装。2. 先搞懂 BinaryNinja 的 Python 世界API 分层、交互环境与最小插件架子2.1 API 的分层逻辑为什么有的插件只改 UI有的能改分析结果BinaryNinja 的 Python API 不是铁板一块它实际上分了三层理解了这三层你才知道自己写的插件该落在哪里。最底层是核心分析引擎处理的是BinaryView、Function、Instruction这些对象它们是反汇编和反编译的骨架。中间层是数据流与类型引擎包括HighLevelIL、MediumLevelIL、Type、Structure负责把汇编指令提升成带类型信息的伪代码表示。最上面一层是交互层包括GUI相关接口、PluginCommand、BackgroundTaskThread负责让你的插件能在界面里被调用。这三层有个关键区别底层 API 是同步的、确定性的中间层 API 有状态同一个函数分析两次可能有不同表现交互层 API 则要求你的代码必须快速返回不能在 UI 线程里跑长任务。举个例子你想让插件在反编译窗口里高亮某个 API 调用。如果只做 UI 高亮那只需要拿到Function里的指令列表检查操作数即可但如果你想让「高亮」能参与后续的数据流分析——比如让你标记的 API 调用成为交叉引用的起点——那就必须把信息写回BinaryView的注释系统或标签系统。这两者做法完全不同前者是只读遍历后者是写分析结果。我一般建议第一版插件先做成只读分析也就是遍历BinaryView里的函数和指令把结果打印到日志或文件里。这样做的好处是你不需要担心破坏 BinaryNinja 内部的分析状态踩坑成本极低。等你的逻辑稳定了再考虑把信息写回Function的注释或自定义的DataVariable。2.2 搭建最小插件工程目录、入口和 PluginCommand 的正确用法BinaryNinja 插件的标准目录结构其实很简单但你得知道它默认扫描哪些位置以及插件的加载顺序。在 Linux 和 macOS 上用户级插件目录是~/.binaryninja/plugins/Windows 上是%APPDATA%\Binary Ninja\plugins\。每个插件目录下至少要有一个__init__.py这个文件就是插件的入口。插件注册有两种方式。老的写法是直接在你的__init__.py里调用PluginCommand.register()新版本推荐用一个 plugin manifest 文件plugin.json来声明插件的名称、入口函数、运行平台和权限。我建议直接用 manifest 方式因为它的加载错误信息更可读而且 BinaryNinja 的插件管理器能识别它。一个最小插件只需要这三个文件my_analyzer/ ├── plugin.json ├── __init__.py └── analyzer.pyplugin.json的内容如下注意api字段必须声明你用的是 Python 3 API 还是老的 Python 2 API写错会导致插件静默加载失败{ name: My First Analyzer, description: A plugin that enumerates all functions and logs their addresses., version: 0.1.0, author: your_name, license: MIT, platform: [all], api: [python3], entry_point: __init__.py, dependencies: {} }到目前为止没写任何 Python 代码。现在写__init__.py它负责注册命令from binaryninja import PluginCommand from .analyzer import enumerate_functions def register_plugin(): PluginCommand.register( My Analyzer\\Enumerate Functions, 列出当前二进制中所有函数的地址和名称, enumerate_functions ) PluginCommand.register_for_function( My Analyzer\\Analyze Current Function, 对当前光标所在函数执行自定义分析, analyze_current_function )注意PluginCommand.register的第二个参数是描述字符串它会在你把鼠标悬停在菜单项上时显示第三个参数是回调函数必须接受一个BinaryViewType或BinaryView参数。register_for_function则是在右键点击函数时出现的菜单项它的回调函数接受两个参数BinaryView和Function。很多新手在这里第一个坑回调函数签名不对。register的回调接受一个参数bvregister_for_function的回调接受两个参数bv, function。如果你把两个参数的函数传给register插件菜单里能看到名字但一点击就会抛异常而且异常不会弹出来只会默默打印到日志里。2.3 用交互式终端验证 API别一上来就调show_graph_reportBinaryNinja 自带一个 Python REPL 窗口通过Python菜单打开我一直把它当作插件的「试衣间」。为什么因为插件的回调函数和 REPL 里跑的代码除了拿到的对象不同其余 API 完全一致。常见的做法是在 REPL 里先加载目标二进制然后手动遍历函数、指令、交叉引用找到你要的 feature再把这段逻辑挪进插件代码。举一个最简单的例子假设你想确认某个函数的指令数量bv binaryninja.open_view(/path/to/target) func bv.get_function_at(0x10000) print(len(list(func.instructions)))这里func.instructions是个生成器直接用len()会报错必须包一层list()。这也是第二高发的坑——API 返回生成器但你以为返回的是列表。REPL 还有一个好处就是可以快速检查BinaryView的analysis状态。很多批处理任务一上来就遍历函数但如果bv.analysis还没跑完函数列表是不完整的甚至get_function_at会返回None。在 REPL 里你可以手动触发bv.update_analysis()等待它返回后再做遍历就不会出现「插件跑完但结果明显缺一部分」的情况。2.4 第一个能跑的插件把函数列表导出成 JSON下面这个例子覆盖了插件开发最基本的三个环节拿视图、遍历数据、输出结果。它做的事情是遍历所有函数及其基本块数量输出到 JSON 文件。不要小看这个需求——在做固件分析时导出一个函数清单往往是后续批量分析的第一步。import json from binaryninja import PluginCommand, BackgroundTaskThread class ExportFunctionsTask(BackgroundTaskThread): def __init__(self, bv, output_path): super().__init__(Exporting functions..., True) self.bv bv self.output_path output_path self.results [] def run(self): self.bv.update_analysis() for func in self.bv.functions: self.results.append({ name: func.name, start: hex(func.start), end: hex(func.end), basic_blocks: len(func.basic_blocks) }) with open(self.output_path, w) as fp: json.dump(self.results, fp, indent2) def export_functions(bv): task ExportFunctionsTask(bv, /tmp/functions.json) task.start()这里用了BackgroundTaskThread因为在分析大型固件时遍历所有函数可能耗时数十秒如果直接在主线程里跑BinaryNinja 的界面会卡死用户会以为程序崩溃了。BackgroundTaskThread的run()方法在后台线程执行super().__init__的第一个参数是任务显示名第二个True表示任务可以被取消。注意run()里第一行是update_analysis()这是必须的。BinaryNinja 在打开文件后会异步执行反汇编分析如果主窗口已经加载但分析还没完成直接遍历函数会拿到不完整数据。update_analysis()是个阻塞调用会等待分析完成再返回。2.5 参数与命名习惯让插件可复用而不是一次性脚本写插件的终极目的不是给自己一次性跑一个脚本而是让它能适配不同的目标文件、不同的分析需求。我见过很多团队调研期间的插件代码全部是全局变量和硬编码路径换个文件就得改代码。这不是插件这是带着壳的临时脚本。我习惯把可配置参数都做成插件命令的选项。常用的方案是PluginCommand.register配上一个ChoiceField或TextLineField参数BinaryNinja 会弹出一个对话框让你输入。比如上面导出 JSON 的例子可以把输出路径做成运行时可指定from binaryninja import TextLineField, ChoiceField, ShowProgressField def export_functions_interactive(bv): output_path_field TextLineField(Output JSON path, /tmp/functions.json) choices [all, exported, library] filter_field ChoiceField(Function filter, choices) if not plugin_command.get_form_input([output_path_field, filter_field]): return output_path output_path_field.result selected choices[filter_field.result] task ExportFunctionsTask(bv, output_path, selected) task.start()这里get_form_input返回布尔值用户点击了「取消」则返回False你必须立即return而不是继续执行。这个设计能避免很多误操作——特别是当你的任务很重、耗时很长时用户可能点了确定就后悔至少允许他放弃。这种「参数对话框 后台任务」的模式基本满足插件开发的 80% 需求。剩下的 20% 在于事件驱动的分析逻辑也就是下一章要讲的内容。3. 三类核心插件场景事件回调、指令级处理、渲染视图3.1 包一层事件回调让插件在分析完成后自动干活插件不只是「用户点一下才动」。BinaryNinja 支持注册分析生命周期的事件回调最常用的是AnalysisCompletedEvent和DataUpdateEvent。前者在文件载入并完成分析后触发后者在用户修改数据、添加注释、重定义函数时触发。这个机制的典型用途是打开固件时自动应用一些已知的修复比如识别某个特定编译器生成的栈保护模式自动为对应的函数设置调用约定。事件回调的注册方式很简单在插件加载时用EventContext注册from binaryninja import BinaryNinjaEvent, EventContext, AnalysisCompletedEvent class MyAnalysisEventListener(EventContext): def notify(self, event: BinaryNinjaEvent): if isinstance(event, AnalysisCompletedEvent): bv event.binary_view apply_known_fixes(bv)这里有个关键点AnalysisCompletedEvent的binary_view属性在回调触发时未必完成了线性扫描所以notify里依然要调用update_analysis()保守等待。但这个调用是幂等的重复调用不会有副作用。事件驱动模式的最大优势是你不需要让用户主动去点任何东西。插件装上之后打开文件就有输出这对团队协作极其友好——你不需要提供一份操作手册只需要在notify里把自动分析的结果写入日志或注释系统。3.2 指令级处理修改反汇编的颜色不是玄学是LLILInstruction的功劳在 Visual Studio Code 里写插件时改动的一直是编辑器视图层的 token在 BinaryNinja 里做类似的事面对的是DisassemblyTextLine和FunctionGraphWidget。很多人想让某个指令高亮第一反应是去翻 GUI API其实在 BinaryNinja 里更常用的手法是把分析结果写进FunctionComment或给指令的地址打标签。以「把对printf的调用全部标记出来」为例。你需要先遍历每个函数再遍历函数的每条MediumLevelIL指令检查它是不是一个调用指令并且调用的目标地址是printf。from binaryninja import MediumLevelILOperation def tag_printf_calls(bv): printf_addr None for sym in bv.symbols: if sym.name printf: printf_addr sym.address break if printf_addr is None: return for func in bv.functions: for block in func.mlil.basic_blocks: for instr in block: if instr.operation MediumLevelILOperation.MLIL_CALL: if instr.dest.constant printf_addr: func.set_comment(instr.address, PLUGIN: call to printf)这里有个隐蔽的坑func.mlil.basic_blocks的存在依赖分析引擎已经成功为这个函数生成了MediumLevelIL。如果你修改了函数开头的指令mlil会失效——比如你重新定义了函数参数原有的 MLIL 可能被清空。所以tag_printf_calls在遍历之前最好检查一下func.mlil是否为None。指令的dest.constant只有在操作为MLIL_CALL且目标是直接地址时才有效间接调用比如通过寄存器跳转的dest是一个SSAValue没有constant属性。如果你直接访问constant抛出的异常会让你误以为是 API 出了问题。处理办法是先用isinstance(instr.dest, Constant)判断。3.3 基本块粒度的数据流为什么从LowLevelIL升到SSA是有代价的有一类插件要做「污染传播分析」——从一个不可信的输入出发追踪它流向哪些内存和寄存器。这类插件在 BinaryNinja 里有现成的框架可选MediumLevelIL和SSA形式。但我需要先泼一盆冷水SSA 形式在 BinaryNinja 里并不保证每个指令都有medium_level_il的前身。MLIL_SSA是在MLIL基础上构建的而MLIL又是从LLIL提升来的。这个提升过程会引入伪指令比如MLIL_SET_VAR它对应的是某个变量的赋值而不是真正的汇编指令。你在写污染传播时要处理的是一棵提升树不是线性指令流。举个具体例子检查一个函数是否安全地处理了来自某个全局变量的值from binaryninja import CoreArchitecture, SSAVariable def check_global_taint(bv, func, global_addr): # 找到那个全局变量对应的 SSA variable 是很麻烦的。 # 简单做法遍历 MLIL 指令匹配源操作数 for block in func.mlil.ssa_form.basic_blocks: for instr in block: for operand in instr.operands: if isinstance(operand, SSAVariable): var_name operand.var.name if var_name.startswith(global_): print(fInstr at {instr.address} touches global var {var_name})这里面有两个隐藏坑第一SSAVariable的var.name不一定以global_开头它取决于符号表和类型信息很多全局变量没有名字显示为var_0x1234你需要自己映射地址。第二ssa_form只有在分析完成并启用了 SSA 选项时才存在如果用户关闭了 SSA运行时拿到None代码就白写了。3.4 渲染类插件自定义DisassemblyTextLineRenderer的边界二进制分析工具不仅要有「对」的结果还要有「好看」的结果。BinaryNinja 支持自定义渲染器允许你把特定地址的汇编行替换成自己的文本。但这个功能有明确边界你的渲染器只影响显示不影响分析。也就是说你在渲染函数里把一条add伪装成sub交叉引用和 MLIL 仍然基于真实的add。这对 UI 类插件足够了但如果你想让显示和分析一致必须同时修改指令——那是在写二进制 Patch不是插件。我用渲染器的主要场景是标出可疑的断点地址。比如分析一个漏洞 PoC 时我想让所有落在strcpy的调用地址显示为红色加粗from binaryninja import DisassemblyTextLine, DisassemblyTextLineRenderer, Color class SuspiciousCallRenderer(DisassemblyTextLineRenderer): def __init__(self, bv, target_addrs): super().__init__(bv) self.target_addrs target_addrs def render_line(self, addr, text_line): if addr in self.target_addrs: text_line.add_tag(0, SUSPICIOUS, Color.RedColor, plugin-call-to-strcpy) return text_line这里的add_tag四个参数分别是插件的名字、显示文本、颜色和描述。注意render_line返回的是一个新的DisassemblyTextLine你不用修改原始对象。渲染器需要被「安装」到某个 widget 上而不是全局生效——这是又一个让新手困惑的点。安装过程涉及到FunctionGraphWidget的set_instruction_renderer方法不在本文展开因为实际用途相对小众。4. 避坑与排查五个让插件「看起来没生效」的典型原因4.1 现象插件菜单里能看到名字但点击后没有任何反应原因几乎都是回调函数抛了异常但 BinaryNinja 把异常吞掉了只在底层的日志文件里记录。解决方法是先打开Help - Log窗口或者直接调用log_info打印关键进度大多数情况下你能看到 traceback。第一把查错利器就是把回调函数包一层 try/exceptfrom binaryninja import log_error, PluginCommand def safe_callback(bv): try: # 你的真实逻辑 pass except Exception as e: log_error(fCallback failed: {e}) import traceback traceback.print_exc()这个包装不会影响性能但是排查问题效率能提高十倍——因为你不用猜日志直接告诉你哪一行炸了。4.2 现象遍历函数时访问func.instructions报TypeError很多 API 方法返回的不是列表而是iterator你不能对它做索引访问。这在管理端脚本里尤其常见——因为脚本里经常用func.instructions[10]想拿第十条指令但正确做法是count 0 target_inst None for inst in func.instructions: if count 10: target_inst inst break count 1或者干脆用list(func.instructions)[10]但这样会把整个指令集拉到内存里对超长函数不友好。记住一个原则凡是对象出现在「列表」上下文的先扫一眼文档确认它是 list 还是 generator。4.3 现象插件跑完但结果缺失特别是缺少最后几个函数这大概率是分析尚未完成就开始遍历。二进制分析引擎是异步的BinaryView刚创建时只有一部分函数被识别。解决的办法就是在遍历前调用bv.update_analysis()并检查返回值success bv.update_analysis() if not success: log_error(Analysis failed or was cancelled) return如果update_analysis返回False说明分析的某个阶段卡住或被终止这时候遍历也是白费。4.4 现象修改了插件代码但 BinaryNinja 里还是旧逻辑BinaryNinja 在插件加载时会缓存 Python 模块不会因为你改了.py文件就自动热重载。解决方法是重启 BinaryNinja或者用binaryninja.plugin_manager.reload_plugins()。但后者不是万能的如果你删除了一个插件目录它依然会保留在内存里直到软件重启。4.5 现象引用第三方库比如requests的插件在某些系统上加载失败BinaryNinja 的 Python API 运行在自带解释器上但这个解释器不一定会搜索系统的site-packages。如果你用了requests、numpy之类的外部包在 macOS 上常见的系统 Python 与 BinaryNinja 自带的 Python 环境不互通。最稳妥的方法是使用 BinaryNinja 自带的 pip 模块安装依赖或者干脆不引入第三方库用标准库实现必要的 HTTP 交互。如果非用 Python 的 HTTP 库urllib.request往往就够用了标准库零依赖不香吗5. 性能焦虑从单线程遍历到并行任务你需要的不是多线程是缓存5.1 为什么原生 API 的遍历总会慢那么一点BinaryNinja 的分析引擎是 C 实现的但 Python API 的遍历是同步调用的每访问一个对象都可能触发一次跨语言调用开销不可忽视。遍历几千个函数没问题但当你做数据流分析比如对每个函数单独调用func.medium_level_il并遍历其所有指令时间会爆炸。这并不是说 BinaryNinja 性能差而是提醒你尽量批量取数据不要重复请求同一块区域。比如一次拿到函数的mlil.basic_blocks列表而不是循环里反复访问func.mlil。5.2 用BackgroundTaskThread加手动取消标志上一章的示例已经用了BackgroundTaskThread这里要补一个关键设计任务必须能被取消。canceled这个特性在大量遍历时一定要有否则用户点错了按钮只能干等着。class HeavyAnalysisTask(BackgroundTaskThread): def run(self): self._cancelled False for func in self.bv.functions: if self.progress_cancelled: self._cancelled True break # 实际处理逻辑progress_cancelled是BackgroundTaskThread的属性当用户点击取消按钮时它会变为True。建议在每个函数循环结束前检查一次不要放在内层指令循环里——否则检查的频率过高影响性能。5.3 缓存设计同一个文件重复分析时让插件「会记仇」插件会被反复激发特别是事件驱动的自动分析每次打开文件、每次修改都会触发。如果你每次都要重新扫描所有函数用户会觉得插件很笨。常见做法是把分析结果缓存到BinaryView的 session data 里CACHE_KEY my_plugin_function_cache def get_cached_analysis(bv): if CACHE_KEY in bv.session_data: return bv.session_data[CACHE_KEY] # 重新计算 result heavy_compute(bv) bv.session_data[CACHE_KEY] result return resultsession_data是BinaryView上的字典生命周期和文件视图一样。文件被关闭缓存就没了不会浪费磁盘空间。5.4 模块级单例的坑多个视图共享同一份缓存上一节的session_data是「每个视图一份」这是正确的做法。但如果你把缓存放在模块级全局字典里# 错误示范 _cache {}那么打开第二个二进制文件时_cache里还留着第一个文件的数据键可能撞车。更糟的是两个文件视图可能不共享同一个BinaryView实例但你却用一个全局字典把它们的分析结果搅在了一起。永远把缓存绑到BinaryView上而不是绑到模块上。5.5 并行分析什么时候真正需要concurrent.futuresBinaryNinja 自身的分析引擎在内部已经是并行的但你的插件里的纯 Python 计算未必可以利用这个并行度。如果你要做的是「对一百个函数分别跑一遍模式匹配」可以用ThreadPoolExecutor并行跑——因为每个函数分析之间没有依赖关系。from concurrent.futures import ThreadPoolExecutor def analyze_all_functions(bv): funcs list(bv.functions) with ThreadPoolExecutor(max_workers4) as executor: results list(executor.map(analyze_one_func, funcs))注意analyze_one_func里的 API 调用一定是线程安全的——BinaryNinja 官方文档并没有明确保证每个 API 都线程安全。我在实际使用中只把「只读」操作扔进线程池并且绝不并行调用update_analysis()后者会直接导致进程崩溃。如果你不确定 API 是否线程安全用单进程多请求的方式或者老老实实顺序遍历。6. 把插件变成真正好用的分析流水线数据落盘、可配置阈值与插件间的「搭积木」6.1 定义清晰的输出结构让插件的结果不只是一堆日志很多插件跑完只打印分析日志然后就没有然后了。我的习惯是让每次分析输出一个 JSON 摘要文件即使分析目标是同一份固件也要包含时间戳和 BinaryNinja 版本号——这对复现不同机器上的分析结果极其重要。def run_pipeline(bv, output_dir): report { bn_version: binaryninja.core_version(), analysis_time: datetime.utcnow().isoformat(), file_md5: bv.file.md5.hex(), functions: [] } for func in bv.functions: report[functions].append(extract_function_features(func)) with open(os.path.join(output_dir, report.json), w) as fp: json.dump(report, fp, indent2)这个run_pipeline函数放在插件入口可以注册成一个独立的 PluginCommand让高级用户尝鲜用。6.2 让阈值可配置从「固定规则」变成「参数可调」分析固件时你经常需要动态调整「多大的函数算可疑」「多少个交叉引用算高风险」。硬编码这些阈值会让插件失效——因为不同项目差异极大。我用配置文件解决把阈值放在插件目录下的settings.json在插件加载时读取。{ min_function_size: 32, min_call_count: 3 }在代码里读取时注意处理「配置不存在」的情况import json, os BASE_DIR os.path.dirname(os.path.abspath(__file__)) def load_settings(): settings_path os.path.join(BASE_DIR, settings.json) if not os.path.exists(settings_path): return {} with open(settings_path, r) as fp: return json.load(fp)这样不同项目、不同分析目标可以共用一个插件目录只需要各自维护一套settings.json。为了避免用户改了配置后不知道要生效还是直接失效插件命令运行时重新读取即可不要缓存配置到全局变量。6.3 与其他插件协作通过FunctionComment和Tag共享状态BinaryNinja 的插件之间理论上不该互相感知但它们可以通过共享注释、标签、DataVariable来传递信息。我常用的协作方式是 A 插件给某个地址打上 tagB 插件通过检索所有 tag 快速定位目标。from binaryninja import BinaryView, Tag for tag in bv.tags: if tag.type.name SUSPICIOUS: print(fTagged address: {hex(tag.address)})这比自己维护一份跨插件全局字典要干净得多——因为 tag 的生命周期跟BinaryView一致文件保存后还能再加载出来。6.4 验证你的插件最小回归测试框架与「伪二进制」技巧插件也是代码修改后必须验证。最轻量的验证方式是用 BinaryNinja 自带的create_blank_database或者用open_view加载一个测试用的 ELF/PE 文件。问题是现成测试文件往往没法覆盖你插件用到的每个边界条件。我的做法是手搓一个只含几条汇编指令的最小 ELF然后用open_view加载它跑插件。这样你可以精确知道哪些函数名字会被识别、哪些地址会被遍历到所有断言都是确定的。printf \x7fELF... test.bin用objcopy或编译器生成一个只有 memcpy 调用的 C 文件比手搓 ELF 更快。6.5 最后一句心里话插件开发最大的坑不是 API 记不熟而是没有给自己的代码留下退路——分析是状态性的数据流是复杂的一次修改就可能让整个分析结果推翻重来。我的个人习惯是给插件写一份「分析日志」记录它做过什么修改、在哪个地址注入了什么注释。这样即使插件跑了几天出了偏差也能从日志里倒推原因。希望这些踩坑经验帮到你。本文还有配套的精品资源点击获取