软件供应链安全分析框架：从缺陷密度到CI准入策略

简介：《2024中国软件供应链安全分析报告》以PDF格式呈现，面向安全研究人员、软件开发人员及企业安全管理人员，围绕软件供应链攻击手段、自主开发源代码缺陷、开源生态风险与漏洞治理展开分析，可用于威胁认知、安全评估和策略制定。压缩包共1个PDF文件，约7.31MB，内容按概述、源代码安全、开源软件生态、企业开源应用、风险实例及总结建议组织，便于按章节查阅。报告依托实测数据讨论大型开源项目漏洞增长、关键基础开源软件运维风险、NPM生态恶意组件窃取敏感信息、二十多年前老旧漏洞仍被使用及许可协议风险等具体问题，并以操作系统、PHP、国产数据库供应链攻击实例辅助理解。已有105人学习，适合在漏洞管理、开源软件选型与供应链安全评估中作为参考。

1. 从「老漏洞打出 0day 效果」说起：这套分析要解决什么

一个多年前就公开披露过的压缩库后门，2024 年依然能在生产镜像里被扫出来。翻开这份年度软件供应链安全分析报告（2024 版，第四期），最显眼的不是新奇的攻击手法，而是数据反复验证的一件事：因为软件供应链足够复杂，「外来」组件里的「老漏洞」完全能发挥「0day 漏洞」的攻击作用——二十多年前的漏洞至今仍存在于多个软件项目中。

这套方案要解决的，就是把软件供应链安全从一句口号拆成可测量、可复现、可验收的指标：自研代码的缺陷密度、开源软件引入的漏洞存量、许可协议风险、运维层面的版本失控，以及恶意组件的识别方法。它适合三类人：要交毕设或课设、需要一套能自圆其说的分析框架的学生；要出企业级安全评估方案的从业者；以及刚接手软件成分分析和漏洞管理、手上堆了一摞扫描报告却不知道怎么开口讲的人。

2. 分析框架设计：混源代码四阶段模型与四类风险指标

2.1 四阶段模型：一条链上四个可测量的点

软件不是「写完就交付」的，它是自主开发代码与开源代码等第三方代码集成后形成的混源代码，再经过编译、链接等构建过程形成制品，最后交付到用户环境里运行。这条链上每一个环节都可能引入安全问题，所以框架的第一层不按「技术类型」切，而按「阶段」切——阶段决定数据源，数据源决定指标能不能算出来。

我一般会把这四个阶段和对应的数据源固定成一张对照表，写方案时直接引用，答辩时也不会被问住：

这张表的价值在于：它把「供应链安全」这个听起来很玄学的词，落到了四组能取数的字段上。任何一个项目，只要能拿到依赖清单和扫描结果，就至少能算出前两行的指标；拿到 CI 记录，后两行也能补上。做毕设的同学最容易犯的错是只做第一行——扫一遍代码、算出缺陷数就结束了，那只是一个静态扫描报告，不是供应链分析。

2.2 四类风险指标：为什么不能只用「漏洞数」说话

漏洞数量是最容易被滥用的指标。一个项目有 83 个已知漏洞，另一个有 120 个，能直接说后者更危险吗？不能——前者可能全是中危、且都不可达；后者可能只有一个超危、但正好在认证路径上。所以我在方案里把风险拆成四类，各自有独立的统计单位和处置人：

第一类是代码缺陷，单位是「个/千行」。它衡量的是自研代码本身的健壮性，归属研发，靠安全编码规范和代码审计降低。第二类是组件漏洞，单位是「个/项目」。它衡量的是引入第三方代码带来的暴露面，归属安全团队，靠升级和替换降低。第三类是许可协议风险，单位是「项目占比」。它不产生技术故障，但会产生法律纠纷，归属法务和产品，靠替换组件或调整发布方式解决。第四类是运维风险，包括活跃度、版本滞后和版本碎片化，它是时间维度的，今天合规的组件两年后可能就没人维护了。

分开的理由很实际：这四类指标的责任人不同、修复周期不同、验收方式也不同。混在一起做加权总分，看起来很专业，一旦被追问「这个 78 分是怎么来的」就答不上来了。通常的做法是分层展示，先给四类各自的分布，再给项目的整体画像，而不是硬凑一个综合分。

2.3 样本与口径：1858、2248、1763 三个分母不能混用

这份报告的数据之所以能站住，靠的是三组独立的样本，而这三组样本的分母完全不同，这是写方案时最容易翻车的地方：

• 自研代码样本：1858 个企业自主开发项目，检测代码总量 408,909,802 行，发现安全缺陷 5,216,473 个，其中高危 211,355 个。
• 开源代码样本：2248 个开源项目，检测代码总量 309,522,947 行，发现安全缺陷 5,108,161 个，其中高危 355,721 个。
• 企业使用样本：1763 个企业软件项目中开源软件的使用情况，平均每个项目使用 166 个开源软件，平均每个项目存在 83 个已知开源软件漏洞。

三组数据的统计对象分别是「自研代码」「开源代码本体」「项目里的依赖」，谁也不能替代谁。我见过有人拿 12.76 个/千行去和一个项目的漏洞数相除，得出一个毫无意义的比值——分母是代码行，分子是漏洞条目，单位根本对不上。

提示：凡是出现比值的指标，先在纸上写清「分子是什么、分母是什么、单位是什么」，写不清就别放进图表。

除了分母，还要区分「密度」和「检出率」这两个词。缺陷密度是缺陷数除以代码行数，衡量的是代码有多「脏」；检出率是含有某类缺陷的项目数除以项目总数，衡量的是这类问题有多「普遍」。输入验证类缺陷检出率 49%，说的是近一半项目都有这类问题，不是一半的代码行有问题。这两个词在报告里交替出现，抄进自己方案时必须改对，否则整段分析都会失真。

3. 代码侧评估：缺陷密度、典型缺陷与统计脚本

3.1 语言分布先看结构：Java 占 67.7% 背后的样本偏差

1858 个自研项目里共用了 17 种编程语言，项目数排名前三的是 Java 1258 个、C/C++ 246 个、Python 118 个，Java 项目占比 67.7%，比上一年的 76.1% 有所下降，但依然绝对领先。开源侧的 2248 个项目涉及 10 种语言，Java、C/C++、JavaScript、Python 四种合计约占四分之三。

这组数字第一个用途不是排名，而是提示样本偏差。Java 占三分之二，意味着整体缺陷密度几乎由 Java 项目决定，C/C++ 项目里的内存类问题（空指针引用、资源管理）在总量上会被稀释。所以我在方案里从来不直接报一个「总体缺陷密度」就收工，而是按语言分组再算一遍，看各组的分布是否一致。如果某一种语言的密度明显高于其他语言，那才是值得展开写的分析点。

第二个用途是对照。开源项目的语言结构和企业自研项目的语言结构并不相同，开源侧 Java、C/C++、JavaScript、Python 更均衡，这直接影响后面的横向比较——拿两个语言结构不同的样本直接比总密度，结论是不牢靠的，更稳的做法是同语言对比。

3.2 十类典型缺陷的检出率：71.1% 这个数字怎么读

报告统计了注入、密码管理、日志伪造、跨站脚本、NULL 引用、配置管理、输入验证、资源管理、路径遍历、API 误用这十类典型安全缺陷。自研代码样本的总体检出率是 71.1%，上一年是 74.1%，基本持平；开源代码样本的总体检出率是 76.7%，比前两年略有升高。

拆开看更有意思。自研侧，输入验证类和跨站脚本类排在前两位，输入验证类高达 49%；配置管理类和日志伪造类排在最后两位；NULL 引用类的检出率较往年有明显下降。开源侧，除密码管理类有较大幅度提升外，其余都在正常波动范围内；输入验证、路径遍历、资源管理三类长期在 30% 以上，日志伪造、跨站脚本、配置管理三类在 20% 以下。

这张对比表能直接支撑一个管理结论：输入验证类问题是「跨语言、跨项目类型」的普遍短板，适合做成统一的编码规范与公共组件；而日志伪造、配置管理这类问题在两类样本里都低，说明现有的框架和脚手架已经把大部分场景覆盖掉了，再投入人力的边际收益不高。写方案时把资源往高检出率的类别倾斜，比平均用力有效得多。

还要注意 NULL 引用类的下降。它不是因为代码变好了，而是因为语言和工具在变——现代语言把空安全做进了类型系统，静态分析工具对这类模式的识别也越来越准。这类「因为外部条件改善而下降」的指标，在趋势分析里必须单独说明，否则会被误读成团队治理的成果。

3.3 缺陷密度计算：分母、分子和加权方式

报告给出的两个核心密度是：自研代码整体缺陷密度 12.76 个/千行、高危缺陷密度 0.52 个/千行；开源代码整体缺陷密度 16.50 个/千行、高危缺陷密度 1.15 个/千行。这两个数都能用原始数据复算出来，比如 211,355 ÷ 408,909,802 × 1000 ≈ 0.52，5,216,473 ÷ 408,909,802 × 1000 ≈ 12.76，5,108,161 ÷ 309,522,947 × 1000 ≈ 16.50。

复算这一步一定要自己做一遍。下面这段脚本就是我从扫描结果聚合出密度的最小实现，可以直接改成课程设计的统计模块：

# defect_density.py # 输入：扫描结果列表，每个元素是一个项目的统计记录 # 输出：整体或指定语言下的缺陷密度（个/千行） import json def density(records, lang=None): total_lines = 0 total_defects = 0 high_defects = 0 hit_projects = 0 # 命中项目数，用于算检出率 for p in records: if lang and p["language"] != lang: continue hit_projects += 1 total_lines += p["code_lines"] # 有效代码行，不含空行与纯注释行 total_defects += p["defect_count"] high_defects += p["high_count"] # 只计 high 及以上，且同一位置不重复计数 if total_lines == 0: return None return { "样本项目数": hit_projects, "整体缺陷密度": round(total_defects / total_lines * 1000, 2), "高危缺陷密度": round(high_defects / total_lines * 1000, 2), } if __name__ == "__main__": with open("scan_result.json", encoding="utf-8") as f: data = json.load(f) print("全量", density(data)) for lang in ("Java", "C/C++", "Python"): print(lang, density(data, lang))

几个参数和口径必须说清楚。code_lines用的是有效代码行，不是wc -l出来的物理行，因为注释和空行会把分母虚增，密度被稀释后看起来「很干净」。high_count只统计 high 及以上，且同一处缺陷被多个规则命中时要去重，否则一个空指针会被重复计十几次。乘以 1000 是把「个/行」换算成「个/千行」，这是行业惯例，也是报告里所有密度数字的单位。

最关键的坑在聚合方式上。上面的写法是「先加总分子分母，再做除法」，也叫加权平均，大项目权重大，结果稳定。另一种写法是「每个项目各算一个密度，再对项目取平均」，看起来更公平，实际上会让几千行的小项目和三百万行的大项目拥有同等话语权，小项目里几个缺陷就能把平均值拉到几十个/千行。我见过一份材料里出现 40.52 个/千行这样的数字，和明细数据算出来的 0.52 差了两个数量级，基本就是口径没对齐造成的。自己写方案时，方法在正文里写一句「采用加权平均，分母为有效代码行总数」，就能省掉答辩时的十分钟解释。

3.4 自研与开源的横向对照：12.76 和 16.50 说明什么

把两组数字放在一起，开源代码的整体缺陷密度 16.50 高于自研代码的 12.76，高危密度 1.15 高于 0.52，看起来「开源代码质量更差」。这个结论下得太快。

差异至少有三种解释。一是项目类型不同，被检测的开源项目大多是基础设施类组件，逻辑密度高、边界条件多，本身比业务代码更容易出问题。二是维护模式不同，开源项目由多人协作、跨时区提交，代码风格和防御性写法不统一。三是检测规则适配不同，同一条规则在业务代码里可能误报率很高，在组件代码里却准确，导致检出量本身不可比。

所以我在方案里用这组对照，只做一件事：说明「不能因为组件是开源的，就默认它比自研代码安全」。这一句就足够支撑后面的门禁策略——既然是同等甚至更高的缺陷密度，那依赖引入就必须走和自研代码一样的审查流程，而不是「装上去能跑就行」。

4. 依赖侧画像与企业落地：从开源漏洞统计到准入门禁

4.1 漏洞存量与增量：64,938 与 7,107 的口径差别

截至统计期末，公共漏洞库中共收录开源软件相关漏洞 64,938 个，其中 7,107 个是当年新增。这两个数字的用法完全不同：64,938 是存量，代表「历史包袱有多重」，适合做趋势图和生态健康度描述；7,107 是增量，代表「这一年新欠了多少债」，适合做响应能力评估。

按项目看，历史漏洞总数排名靠前的集中在几个典型角色上：操作系统内核类项目长期位居第一，浏览器内核类项目紧随其后，邮件客户端、关系型数据库、云厂商的内核分支、CI/CD 平台、图像处理库、脚本运行时也都在前列。这一年的增量榜同样是内核类项目最高，一次新增就超过 600 个，浏览器内核类和邮件客户端类项目分列其后。

这份榜单的正确用法不是「点名批评」，而是识别「高产出、高消耗」的组件。一个项目历史漏洞几千个，但维护者响应快、修复版本发得勤，实际风险可能低于一个只有几十个漏洞、但两年没发版的组件。所以在方案里，我把「漏洞总数」和「当年增量」做成两个维度画散点，落在「总数高、增量也高」象限的组件，才是需要重点管理的对象——要么锁定版本并密切跟踪，要么找替代品。

还有一类更容易被忽略：关键基础开源软件。主流生态各有自己的核心组件清单，这些组件被大量项目间接依赖，一旦出问题影响面极大，而报告显示这类组件的漏洞披露情况并未明显改善，只是整体运维风险有所改观。这类组件在我的方案里是单独一张清单，不走常规的版本升级流程，而是走「替换评估 + 隔离运行」的特殊流程。

4.2 活跃度与版本碎片化：68.7% 不活跃项目意味着什么

开源生态的整体规模在这一年增长很快，主流包生态的项目总量从 5,499,977 增长到 7,959,049，一年增长 44.7%，平均每个项目有 11.3 个版本，与前几年基本持平。八个典型生态里，JavaScript 生态项目数最多，达到 4,170,641，增速也最快，达 79.1%；Go 生态的项目数增长 58.1%；Java 构建生态的项目数不算最多，但平均每个项目有 23.6 个版本，是名副其实的「最勤奋」生态。

规模之外，活跃度是更值得关注的一面。统计显示 68.7% 的开源软件项目处于不活跃状态，这个比例虽然比往年有所下降，但依然意味着：随便挑三个依赖，就有两个大概率已经没人维护了。同时，版本频繁更新的项目比上一年增长了 21.6%，说明生态在向两端分化——一部分项目高频迭代，另一部分彻底停更。

不活跃本身不是罪，很多成熟组件功能稳定，不需要天天提交。问题在于「不活跃」和「有漏洞」叠加的时候：没人改，就意味着漏洞只能靠使用者自己打补丁或者隔离。所以我在方案里把活跃度当成一个筛选器，而不是一个扣分项：先看漏洞，再看这个组件还活不活，最后决定是升级、隔离还是替换。

版本碎片化是另一个独立问题。企业侧的数据显示，多个二三十年前的老旧开源软件版本仍在使用，同一开源软件的各版本使用依然混乱。检查方法很直接，一条 SQL 就能把项目内的重复组件捞出来：

-- 统计单个项目内同一组件出现多个版本的情况（版本碎片化） SELECT component, -- 组件名，按坐标归一化后去重 COUNT(DISTINCT version) AS version_cnt, -- 该项目内出现的版本数量 GROUP_CONCAT(DISTINCT version) AS versions -- 便于人工核对具体版本 FROM project_dependencies WHERE project_id = :project_id -- 传入待检查的项目 ID GROUP BY component HAVING version_cnt > 1 -- 只保留多版本并存的组件 ORDER BY version_cnt DESC;

这条查询跑出来的结果通常很吓人：一个中等规模项目里，同一个 JSON 处理库出现三四个版本是常态，同一个日志门面出现五六个版本也不稀奇。原因是不同上游组件各自锁定了不同版本，构建工具做了依赖仲裁但没有统一。危害不只是包体积变大，更麻烦的是漏洞修复时你以为升了一个版本就干净了，实际上另外几个旧版本还留在制品里，扫描器照样报。治理办法是在构建阶段强制统一版本，把仲裁结果写进依赖锁定文件，并在流水线里加一条「同组件多版本即告警」的规则。

4.3 许可协议与恶意组件：46.9%、1/5、95% 三个数字怎么用

许可协议风险在企业侧的表现是：最流行的那一种宽松许可协议在 46.9% 的项目中使用，同时超过五分之一的项目使用了含有超危、高危许可协议的组件。这两个数字放在一起说明一件事——大部分项目的许可结构是「主流宽松协议打底 + 少数高风险协议埋雷」，风险集中在长尾里。

所以许可检查不能做成「有没有 copyleft」的二值判断，而要做成分级清单：禁止类（会传染到自有代码、要求整体开源的）、需评审类（允许动态链接、但有条件约束的）、放行类。分级之后，把「超危、高危许可协议」的组件单独拉一张清单，逐个确认是直接依赖还是传递依赖。传递依赖引入的许可风险最容易被漏掉，因为开发者压根没见过那个组件名。

恶意组件是这一年新增的重点。数据显示，超过 95% 的恶意开源组件以窃取敏感信息为目标，包括浏览器保存的凭据、会话数据、金融信息。攻击手法也在升级：有人在主流包管理器上批量注册与热门通信、云服务 SDK 高度相似的包名，利用域名仿冒让开发者敲错一个字符就装错；还有人伪造仓库的星标数量，让恶意仓库在搜索结果里看起来「很受欢迎」，这套打法被称为星标劫持。

更隐蔽的是长期潜伏型。某压缩库被人以近乎「正规贡献者」的方式逐步取得信任，最终在构建脚本里植入后门，只有满足特定构建条件时才激活，普通代码审查根本看不出来。这类事件对方案的启示是：恶意组件的识别不能只靠包名黑名单，必须叠加来源校验和行为检测——包名与仓库地址双向比对、要求构建来源证明、对新版本做差异审查，三件事缺一不可。

提示：恶意组件检测的误报代价很高，一旦把正常组件判黑，整条流水线会停摆。建议先做告警观察两周，确认误报率可接受再转成阻断。

4.4 准入策略配置：把报告里的指标写成 CI 门禁

前面所有指标，如果不能变成流水线里的一条规则，就只是 PPT。下面这份策略文件是我从这类报告的数据里提炼出来的最小可用版本，把「平均 166 个依赖」「88% 项目存在已知漏洞」这些行业水位，翻译成了可执行的阈值：

# gate-policy.yaml 依赖准入策略，在构建阶段执行 project_gate: dependency_budget: max_direct_deps: 120 # 直接依赖上限，超出需架构组评审 max_transitive_deps: 400 # 传递依赖上限，参考行业均值 166 的 2 倍余量 vulnerability: block_on: ["critical", "high"] # 超危/高危阻断构建 warn_on: ["medium"] # 中危仅告警，进整改队列 ignore_window_days: 30 # 中危允许 30 天整改窗口 reachable_only: false # 暂不启用可达性过滤，先全量拦截 staleness: max_major_lag: 2 # 主版本落后不超过 2 个 max_release_age_days: 730 # 依赖版本发布超过两年需登记说明 license: deny: ["AGPL-3.0", "SSPL"] # 高危许可，默认禁止进入闭源产品 review: ["LGPL-3.0", "MPL-2.0"] # 需法务评审后放行 malicious: verify_source: true # 包名与仓库地址双向校验，防域名仿冒 require_provenance: true # 要求构建来源证明或制品签名

几个参数的设定逻辑值得说清楚。max_transitive_deps定在 400，是因为行业均值已经到 166，卡在均值上会让大部分存量项目直接失败，定在 2 倍左右既能拦住异常膨胀的项目，又不至于一上线就全员报警。reachable_only先关掉，是因为可达性分析需要额外的调用图构建，误判率还不稳定，一上来就启用会出现「明明有漏洞却放行」的争议，稳妥的做法是先全量拦截，把误报清单攒够再优化。ignore_window_days给中危留 30 天，是承认修复需要排期，但必须有截止时间，否则告警会被永久忽略。

策略之外还要有闭环。我的做法是把治理流程压成四步：构建时生成成分清单并落库、扫描结果按项目聚合、超阈值自动开单并指派到人、每周出一份「新增漏洞 / 已修复 / 超期未修」的三列看板。看板上「超期未修」这一列是最有说服力的，它比任何安全评分都更直接地反映治理水平。

5. 避坑与常见问题排查：五类最容易翻车的地方

5.1 指标量级对不上：0.52 被写成 40.52

现象：同一份材料里，概述部分写的高危缺陷密度是 40.52 个/千行，明细部分给的原始数据是 211,355 个高危缺陷、408,909,802 行代码，按定义算出来是 0.52 个/千行，相差两个数量级。

原因：分子分母的口径没对齐。要么是分母取了单个项目的行数，要么是把「缺陷数」当成了「缺陷密度」，还有一种是先按项目求平均再汇总，小项目把均值拉高了。

解决：所有密度类指标一律用「先加总、后相除」的加权算法，公式写进方案正文，并在附录留一段可复算的脚本。图表里的每个数字都要能追到原始记录，做不到就不放进图表。

5.2 样本分母混用：1858、2248、1763 张冠李戴

现象：拿「开源项目缺陷密度 16.50」去和企业项目「平均 83 个漏洞」做比较，得出「开源软件比自研代码危险 20 倍」这类结论。

原因：三个样本的统计对象分别是自研代码、开源代码本体、项目依赖，单位和维度都不同，除以不同的分母得到的比值没有可比性。

解决：画一张样本说明表，把样本量、检测代码行数、统计单位、时间范围四列写全，凡是跨样本的对比都在图注里注明。跨样本只做定性比较，不做定量倍数。

5.3 漏洞重复计数：一个组件报出十几个相同编号

现象：扫描报告里某个项目的漏洞数异常高，点开一看，同一个漏洞编号在不同路径下被重复报了十几次。

原因：传递依赖的多个版本同时存在，扫描器按「组件 + 版本 + 路径」的粒度逐条输出；另外已修复但未重新扫描的旧记录也会留在库里。

解决：统计前先按「漏洞编号 + 组件坐标」去重，再按项目聚合；同时固定扫描快照时间，每次统计都基于同一时刻的成分清单。报表里区分「漏洞条目数」和「唯一漏洞数」两个字段，避免口径打架。

5.4 活跃度误判：只看最后提交时间

现象：一个组件被标记为「不活跃」并进入替换清单，结果发现它是官方归档版本，维护工作已经转移到新的主版本上，功能完全正常。

原因：活跃度只用了最后提交时间一个维度，没有区分「归档」「合并到上游」「单人维护但稳定」这几种情况。

解决：活跃度至少看三个信号——最近一次发布距今多久、近一年提交人数、是否有仍在维护的继任版本。三个信号里有两个正常就降级为观察，不要一刀切进替换流程。

5.5 恶意组件只做名称匹配

现象：黑名单里的包名一个都没命中，但事后溯源发现确实引入了恶意组件，只是对方用了域名仿冒的变体。

原因：恶意组件的命名空间、发布者、仓库地址都可以伪造，纯字符串匹配只能拦住最粗糙的一批。

解决：把校验点前置到安装环节，包名与仓库地址双向比对、校验发布者与历史版本是否一致、要求构建来源证明；对首次引入的新包做人工复核。这三条比维护一份黑名单有效得多。

6. 验收与答辩：怎么证明这套分析站得住

方案写完不等于能交差，验收环节最常被问的三个问题是：数据从哪来、指标怎么算、结论有什么用。前两个靠复算，第三个靠场景。

我一般会准备一张验收对照表，把每一项交付物和验收方法钉死：

答辩时最容易失分的不是数据少，而是讲成了数字朗读会。「平均每个项目 166 个开源软件、83 个漏洞、68.1% 含易利用漏洞」——把这串数字念完，评委记不住任何东西。有效的讲法是沿着一条链路走：一个组件从被引入开始，经过版本仲裁、漏洞扫描、许可检查、来源校验，最后进入制品，这条链路上哪一步没拦住，就会演变成报告里说的那种「老漏洞打出 0day 效果」。

第二个技巧是主动交代局限。样本以 Java 项目为主、可达性分析未启用、恶意组件检测依赖来源证明的覆盖率——这些短板自己先说出来，比被追问出来强得多。我吃过一次亏，答辩时被问到「你的高危密度为什么和小项目算出来的差一百倍」，当场答不上来，后来才想明白是加权方式的问题。从那以后我每次做统计，都会先把分子、分母、加权方式写在一张纸上，再动笔写结论。

第三个技巧是留一个能现场演示的东西。哪怕只是一个能输入项目依赖清单、输出风险分级的小脚本，也比二十页图表有说服力。评委看到可运行的输出，对整套方案的信任度会立刻不一样。

希望帮到你。

本文还有配套的精品资源，点击获取