简介：DeepSeek API调用指南是一份面向软件工程师、科研人员及对AI应用集成感兴趣的技术人员的完整操作手册，系统梳理了从获取API访问权限（包括提交必要信息、等待审核获取密钥）到深入阅读官方接口文档、明确不同接口适用场景、选定开发环境与编程语言、安装依赖库、构造带鉴权信息的请求并进行响应解析的完整链路，并覆盖了后续测试排错与集成进真实项目的关键步骤。文档以Python为例给出可直接套用的调用代码框架，对请求URL、参数、请求头（如Bearer Token）设置及返回数据处理等易出错细节做了说明，可帮助希望接入DeepSeek服务的开发者缩短环境搭建和接口联调时间，提升应用的智能化水平。资源包内为1个docx文档，体积仅16KB，内容精炼、便于直接查阅和批注。目前已有1254人学习过该指南，适合初学者按步骤跟随示例代码实操，也可供有经验者作为快速上手的参考清单。

1. DeepSeek API调用：从拿不到密钥到跑通第一个请求

做AI服务开发的人一定经历过这种场景：手上有一个很好的DeepSeek模型，文档翻了几遍，申请表单填了三次，结果卡在“密钥审核通过后不知道下一步该干什么”。我最早接触DeepSeek API时也是这个状态——文档里每个字都认识，但真到用Python发出第一次数据请求时，还是踩了不少坑。这篇笔记就是把我完整走一遍的流程拆开讲：从申请访问权限开始，到读API文档、建开发环境、装依赖、写请求代码、调试错误，最后把调用逻辑集成进自己的业务项目。它不是一个泛泛的概念介绍，而是一份可以直接照着操作的接入手册。适合所有想在自己的深度学习应用或AI服务里接入大模型能力的软件工程师、研究者，以及所有被API文档挡住过一次的开发者。

2. 接入链路拆解：从申请访问权限到鉴权机制

2.1 申请密钥的过程里有哪些容易被忽略的字段

申请DeepSeek API访问权限是整套流程的第一步，也是最容易被随手糊弄过去的一步。大多数人在开放平台点“申请”时，只想着赶紧拿到一个密钥，表格里的“使用场景”和“预计调用量”随手填几行就提交了。我自己的经验是，这两项恰恰决定审核速度和后续配额。

申请表单里常用的字段包括个人或企业基本信息、使用场景描述、预计调用频率、是否需要流式响应能力等。使用场景这一栏不要写“测试”两个字就完事，最好落到具体业务类型，比如“在内部知识库工具中接入对话能力，用于文本摘要生成，日均调用量预估在五千次以内”。审核人员看到的是明确的使用边界和量级预估，而不是一个来路不明的请求。预计调用量写太离谱也会有问题——写低了怕配额不够用，写高了可能让平台方觉得你还没想清楚就来做接入。我的习惯是写真实数字再乘以两到三倍作为余量，后面不够再申请扩容，比卡死在配额上舒服得多。

拿到密钥之后还有一件容易翻车的事：控制台里可能同时存在多个密钥，有的标记为“测试”有的标记为“生产”。千万别图省事把测试密钥直接放到线上配置里。我在一个模拟项目里就干过这事，测试密钥的配额上限低，请求量稍微上来就返回429限流错误，排查了半天才发现是密钥选错了。

2.2 鉴权请求头：Bearer Token的结构与演进

拿到API密钥之后，真正写代码之前，要理解请求里鉴权信息是怎么传的。DeepSeek API的常见做法是采用HTTP Bearer Token认证，也就是在请求头里加一行Authorization字段，值的前缀是“Bearer”，后面跟一个空格和你的API密钥。

import requests api_key = "sk-xxxxxxxxxxxx" url = "https://api.deepseek.com/v1/chat/completions" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } payload = { "model": "deepseek-chat", "messages": [ {"role": "user", "content": "你好，请介绍一下你自己"} ], "stream": False } response = requests.post(url, json=payload, headers=headers, timeout=60) print(response.status_code) print(response.json())

这段代码比文档里的框架多做了两件事：一是把Content-Type显式声明为application/json，避免部分HTTP客户端自动推断导致请求体被序列化错；二是给requests.post传了timeout参数，防止网络异常时请求一直挂着不返回。

Bearer Token这种鉴权方式的含义是“持有此令牌者即可访问”。服务端拿到请求头里的密钥后，会先校验格式和有效期，再做配额的判断。常见的一个误区是有人把API密钥拼在URL的query参数里传，形如?key=xxx。这在某些老旧的内部接口里还能见到，但对于这类AI开放平台接口来说，密钥走请求头才是标准姿势，放进URL容易被日志系统明文记录下来，等于把密钥裸奔在日志里。我在本地调试时曾经把请求打印到控制台，结果完整密钥被输出到日志文件里，后来不得不去控制台把密钥作废重新生成了一次。

密钥在代码里直接硬编码只是本地快速验证的临时方案。稍微正式一点的项目就应该把密钥放到环境变量里读取，写进配置文件再提交到代码仓库属于事故隐患。后面第四章会专门说这个改造方向。

3. 开发环境准备：Python虚拟环境与依赖管理

3.1 先用venv把请求代码和系统环境隔离

很多新手拿到示例代码之后第一件事是pip install requests，装完就跑，这是在给自己埋坑。不同项目的依赖版本往往互相冲突——这个项目要requests 2.28，那个项目可能要求旧版本。Python的虚拟环境就是干这个用的，它在当前项目目录里建一个独立的Python解释器和一套独立的site-packages包目录。

创建和使用venv的成本很低，值得养成习惯：

cd your_project_dir python3 -m venv .venv source .venv/bin/activate

执行完这三行之后，终端提示符前面会出现(.venv)字样，说明当前shell已经切进了虚拟环境。在这个状态下用pip安装的包不会污染系统全局环境，也不会被系统里其他项目干扰。

虚拟环境建好之后再做依赖安装。调用DeepSeek API这一步主要的依赖其实只有一个requests，但如果后面想接流式输出、做并发请求或者写异步逻辑，依赖会逐渐多起来。我一般会顺手把python-dotenv也装上，用于从.env文件读取环境变量，这样密钥不用写进代码，即使项目不小心被分享出去也不会泄露密钥。

pip install requests python-dotenv pip freeze > requirements.txt

pip freeze这一步很多人会忘记。它的作用是把当前虚拟环境里所有包名和版本号快照到requirements.txt里。将来换了电脑、或者同事要复现这个项目，只需要执行pip install -r requirements.txt就能装回一模一样的依赖组合。这比手写一份依赖清单可靠得多，因为文件里记录的版本号是实测过的，不是凭记忆写的。

3.2 密钥管理的标准做法：从.env到环境变量

开发环境里把API密钥直接写在代码里可以跑，但一旦进入协作阶段就不好使了。代码仓库是共享的，不是每个人都该看到你的密钥，也不是每个人都有同一个密钥。行业里的常见做法是利用环境变量把配置从代码里剥离出来。

先用python-dotenv把.env文件加载进环境：

import os from dotenv import load_dotenv load_dotenv() api_key = os.getenv("DEEPSEEK_API_KEY") if not api_key: raise ValueError("请在.env文件中设置 DEEPSEEK_API_KEY")

对应的.env文件长这样：

DEEPSEEK_API_KEY=sk-xxxxxxxxxxxx DEEPSEEK_BASE_URL=https://api.deepseek.com/v1 DEEPSEEK_MODEL=deepseek-chat

这种做法的好处有三个层面。第一，密钥不出现在代码文件里，即使代码被分享、被上传到仓库，密钥也不会跟着泄露；第二，不同环境可以加载不同的.env文件，本地调试用测试密钥，服务器上用生产密钥，切换环境只需要改文件不需要改代码；第三，项目启动时会自动检测密钥是否配置，缺少配置时直接报错，而不是等请求发出去了才收到401。

有一个血泪教训值得说：.env文件要写进.gitignore，否则它会被提交进仓库。我见过不止一次有人把密钥文件推送到远端仓库，最后只能作废旧密钥重新生成——这个操作本身不复杂，但会打断所有人的开发节奏。密钥这东西，一旦出过一次库就应该当作泄露处理，不存在“改个文件名继续用”的侥幸说法。

3.3 其他语言的接入路径参考

Python不一定是所有人的主语言。DeepSeek API是标准的RESTful接口，理论上任何能发起HTTP请求的语言都可以调用。Java环境里常用的是OkHttp或Spring RestTemplate，C#会用HttpClient，Node.js可以用axios。选用哪个语言核心看你的技术栈——如果你的项目本来就是一个Spring Boot服务，没必要为了调用API再起一个Python进程，直接用Java写个RestTemplate请求就行。

但有一点建议：就算主力语言不是Python，首次调通接口仍然建议先用Python跑一遍。为什么？因为Python的requests库调试体验最好，返回的JSON结构可以直接用print()打在终端上，没有任何类型转换的负担。在Python里把接口的逻辑、参数组织方式都摸清楚了，再翻译成Java或C#代码，基本上就只剩下语法转换工作。

Java场景里有一个常见的翻车点：有些HTTP客户端库默认会缓存DNS解析结果或者复用连接池，导致改了密钥后请求还是用旧的鉴权信息发出去。遇到这种玄学问题，先考虑清空连接池再发下一个请求，而不是怀疑服务端没生效。

4. 核心请求实现：从单次调用到流式响应的完整链路

4.1 一个真正能跑的数据请求模板

第三章里那段示例代码只覆盖了最基本的非流式请求。这一节我把它扩展成一个更接近生产可用状态的版本：加了环境变量读取、状态码校验、返回结果解析和异常分支。

import os import requests from dotenv import load_dotenv load_dotenv() API_KEY = os.getenv("DEEPSEEK_API_KEY") BASE_URL = os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com/v1") MODEL_NAME = os.getenv("DEEPSEEK_MODEL", "deepseek-chat") def call_deepseek(prompt: str, temperature: float = 0.7, max_tokens: int = 1024): url = f"{BASE_URL}/chat/completions" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "model": MODEL_NAME, "messages": [ {"role": "system", "content": "你是一个乐于助人的AI助手。"}, {"role": "user", "content": prompt} ], "temperature": temperature, "max_tokens": max_tokens, "stream": False } try: resp = requests.post(url, json=payload, headers=headers, timeout=90) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] except requests.exceptions.HTTPError as e: print(f"HTTP错误: {e}, 状态码: {resp.status_code}") print(f"响应详情: {resp.text}") raise except requests.exceptions.Timeout: print("请求超时，请检查网络或延长timeout参数") raise except (KeyError, IndexError) as e: print(f"响应结构解析失败: {e}") print(f"原始响应: {resp.text}") raise

这段代码把参数从具体值提升成了函数参数，调用方只需要传prompt就能拿到模型返回的文本内容。temperature控制生成结果的随机性，0到1之间，值越小输出越确定，适合抽取、分类这类任务；值越大输出越多样，适合头脑风暴场景。max_tokens限制生成内容的最大长度，按token数计算，中文大约一个汉字消耗1到2个token，设置太小会出现答案被截断的问题。

响应解析这里有个细节：data["choices"][0]["message"]["content"]取的是第一个候选结果的消息内容。非流式模式下choices列表一般只有一个元素，但保持这种防御性的取值方式可以避免数据结构变化时报出“IndexError”这种不明所以的异常。如果返回结果里还有usage字段，这通常是用量统计，里面包含prompt_tokens、completion_tokens、total_tokens三项。我做计费统计或成本分析的时候会把这个字段单独打印出来落库。

4.2 流式响应：让内容边生成边输出

非流式请求会等模型生成完整个回答再一次性返回，在长文本生成场景下等待时间可能长达几十秒，用户体验很差。很多在线对话应用采用流式响应，也就是SSE（Server-Sent Events）模式，服务端每生成一小段内容就推送给客户端，前端可以逐字显示。

import requests import json def call_deepseek_stream(prompt: str): url = f"{BASE_URL}/chat/completions" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "model": MODEL_NAME, "messages": [ {"role": "user", "content": prompt} ], "stream": True } with requests.post(url, json=payload, headers=headers, stream=True, timeout=120) as resp: resp.raise_for_status() for line in resp.iter_lines(): if not line: continue line_text = line.decode("utf-8") if not line_text.startswith("data:"): continue data_str = line_text[5:].strip() if data_str == "[DONE]": break try: chunk = json.loads(data_str) content = chunk["choices"][0]["delta"].get("content", "") if content: print(content, end="", flush=True) except json.JSONDecodeError: continue

流式请求的关键在于请求体里的"stream": True，以及响应处理时不能用resp.json()一口气读完，而是用iter_lines()逐行读取。每一行以data:开头，后面跟着一段JSON，也就是一个增量chunk。chunk里的choices[0].delta是这次推送新增的内容，多行拼起来才是完整回答。当收到data: [DONE]时，服务端告诉客户端消息发送完毕，循环退出。

实测中流式请求的耗时分布和非流式完全不同。非流式是长时间无反馈然后一次性返回全部结果，流式是第一行数据很快就到，后面的内容持续不断地刷出来。从用户体验角度看，流式的“首字延迟”更低，适合聊天机器人、写作助手这类需要逐字交互的产品形态。从后端日志角度看，流式请求是持续占用连接，日志里看到请求时间特别长是正常现象，不要误判为超时挂起。

4.3 请求参数里那些影响结果的隐藏配置

除了temperature和max_tokens，DeepSeek API的请求体里还有几个值得关注的参数。

top_p和temperature是一对可以配合使用的采样参数。如果两个都设置了，实际生效的策略会按两者的综合结果来采样。我的习惯是只固定其中一个，temperature控制在0到1之间，top_p不传或固定为1。两个都做精细调节容易导致输出结果和预期差异很大，调参时要改一次跑一次对比，不要一次同时改两三个变量。这种单变量控制的做法在调参时能少很多玄学问题。

stop参数可以传入一个字符串数组，模型生成到这些标记时会自动停下来。做结构化输出时很实用——比如希望模型只输出JSON、不要输出解释性文字，可以把stop设置成["\n\n"]，让生成在遇到空行时停止。这个参数在不同的任务里表现差异很大，需要针对你的prompt风格实测几次才能找到稳定的停靠点。

presence_penalty和frequency_penalty这两个参数控制生成内容对词汇重复的惩罚强度。前者鼓励模型谈论新的话题，后者抑制模型重复刚说过的词。官方文档里这两个参数有默认值，一般不需要调整。我做过一组对比测试，在中文文本摘要任务里调高frequency_penalty反而会让摘要句子结构变碎，所以不建议新手一上来就动它们。

最后是user字段，它不是给最终用户看的，而是开发者用来打标记的。可以在请求体里加一个与当前会话关联的ID，平台方如果做滥用监控时能通过这个字段定位到具体用户。我在生产环境里会把它设置成内部用户ID的哈希值，排查问题时能快速对应到某次具体的异常请求。

5. 调试与避坑：调DeepSeek API时最容易出问题的六个环节

5.1 高频错误码：先看懂状态码再动手排查

调用DeepSeek API报错时，第一步不是改代码，而是看HTTP状态码。把常见错误码整理成了一张表，排查时对着看能省很多时间。

其中422报错是我自己遇到频率最高的。根本原因大多是messages数组元素的role字段写错了——deepseek的chat接口要求role必须是system、user或assistant的其中一个，但很多人会写成"role": "robot"或"role": "AI"这类不规范的取值。服务端校验不通过，直接把整个请求体报废。排查重心放在请求payload上就好，不要在代码逻辑里找原因。

5.2 密钥相关的三个经典翻车现场

密钥报401是新手期最常见的卡点。一种情况是复制密钥时把空格带进去了，肉眼看不出来，但Base64解码时字符串末位可能多出空白字符。解决方法是把api_key赋值后打印len(api_key)，正常长度应该与平台页面显示的一致，如果不同就说明复制过程出了问题。

另一种情况是同时申请了多个密钥，手里一个测试一个生产，代码里写死的是旧的失效密钥。测试密钥过期时间通常比生产密钥短，如果日志里出现间歇性的401，先怀疑是不是密钥过期了，而不是怀疑网络或服务端。我养成的习惯是把每个密钥创建时间和用途记在密码管理工具里，一旦代码报401，直接去核对是否过期。

还有一次比较极端的案例：我配置好环境变量后启动服务，发现请求一直报401，怎么排查都找不到问题。后来打印环境变量本身才发现，.env文件里的DEEPSEEK_API_KEY值带了一对双引号，python-dotenv加载时把这引号当成了值的一部分。这类问题属于典型的字符处理陷阱，遇到鉴权失败时多打印一下实际拿到的值，比自己脑补原因高效得多。

5.3 超时与重试：网络问题不该靠手点重跑

请求超时的表现形式有两种：requests.exceptions.ConnectTimeout出现在建立TCP连接阶段，说明目标地址不可达；requests.exceptions.ReadTimeout出现在等待响应阶段，说明连接建好了但服务端迟迟没返回数据。两者在日志里的表现都像“卡死了”，但处理方式不同。

连接超时的常见原因是本地网络环境或代理设置问题。我在企业内网环境下经常遇到这种情况——公司网络做了层代理，requests默认没走代理，连接直接超时。解决办法是在请求时检查环境里的代理变量，或者显式给requests传proxies参数。另一种可能就是你所在网络的防火墙拦截了对api.deepseek.com的访问，这种情况靠改代码解决不了。

读超时的常见原因是请求耗时超过了客户端设置的timeout上限。非流式请求生成长文本时耗时可能超过一分钟，如果timeout设成30秒，中途就会被客户端掐断。规范做法是：普通请求设60秒，长文本生成设120秒，流式请求不用timeout控制而是靠SSE的心跳判断连接是否存活。

重试机制也要区分场景。429和500这类状态码值得重试，网络层面的ConnectionError也可以做一次重试。但401不要重试，重试多少次都是同样的结果。合理的重试策略是：对429做退避重试，等待时间按1秒、2秒、4秒递增；对500做固定间隔重试最多三次；对于幂等性不明确的请求宁可报错也不要盲目重试，避免造成重复扣费。

import time from requests.exceptions import HTTPError def call_with_retry(func, retries=3, base_delay=1.0): for attempt in range(retries): try: return func() except HTTPError as e: status = e.response.status_code if status in (429, 500) and attempt < retries - 1: delay = base_delay * (2 ** attempt) print(f"请求失败({status})，{delay}秒后重试...") time.sleep(delay) continue raise

这段代码实现了一个简单的指数退避重试。base_delay是首次等待时间，每次重试翻倍，3次重试的间隔分别是1秒、2秒、4秒。实际使用时把它包在原有调用函数外面就行，不用改动原函数的任何逻辑。

5.4 响应内容解析失败时的通用排查顺序

拿到200状态码但代码里resp.json()报错，或者解析出来的字段不对，这是另一类常踩的坑。排查顺序我建议固定为三步。

第一步，打印原始响应文本，看返回的到底是什么格式。有些网关会在正常JSON前包一层包装结构，有些错误响应是纯文本而非JSON格式。print(resp.text)这一步花十秒钟，能砍掉一半的定位时间，比我之前“看报错猜原因”的方式高效得多。

第二步，检查JSON层级结构。DeepSeek的chat接口返回结构是root下面有choices数组，choices数组元素里有message对象，message里有content字段。如果用的字段路径和实际json路径对不上，很容易抛出KeyError。最直接的验证方式是把响应保存到本地，用json.loads之后逐层打印type(data)和data.keys()，把结构摸清楚再写取值代码。

第三步，确认是不是走了代理或中间层。公司网络里的统一网关有时会对响应做拦截或改写。我遇到过一次网关把大响应体截断导致JSON末尾残缺的问题，现象是文本内容显示不全而且json解析报错。排查时看一眼完整的响应体长度，对比Content-Length头是否一致，能快速判断是不是中间环节吞了数据。

5.5 流式响应拼接时的隐性bug

流式模式有一个容易忽略的坑：服务端推送的chunk顺序并不严格保证每个chunk都是完整的一句话，很多时候一句话被切成了七八个chunk。如果前端逻辑是每收到一个chunk就立即解析并当作完整句子处理，那输出会变得七零八落。

解决方案有两个层面。展示层面，逐字追加即可，不需要等句子完整再渲染；业务处理层面，如果需要对内容做语义分析、摘要提取，应该等服务端返回[DONE]后把所有chunk的content字段拼成一个完整文本再交给下游处理。注意流式响应里每个chunk的delta里通常只有content字段，而最终用量统计往往在最后几条chunk的usage里，拼接时不要误把usage字段当成内容打印出来。

我踩过的另一次坑是处理SSE时只判断了data:前缀，但有些情况服务端会先发一条注释行或者事件名行，导致代码在前几行上直接跳过。兼容一点的写法是忽略所有不以data:开头的行，只处理真正的数据行和[DONE]信号，这个思路在上面那段流式代码里已经体现了。

5.6 余额扣费与配额监控：别在月底才发现费用超了

调用量监控这事大家都觉得应该做，但真做的人不多。DeepSeek API是按token数计费的服务，同样的prompt在不同的模型版本下计费单价不同。没有监控的话，等到收到账单才发现某个测试任务消耗了几十万token，这种翻车经历我属实不想再体会第二次。

常见的做法是定时拉取用量接口的数据写入本地数据库，配合企业微信或钉钉机器人做告警。成本最低的验证方案是每天定时跑一个脚本，从响应里的usage字段解析当天累计消耗量，超过阈值就发个邮件提醒。这样既不依赖平台端有没有配额告警功能，也能让调用方自己有“这个月跑了几条请求、花了多少token”的概念。

在代码层面尽量把用量统计做进公共调用函数里，每个请求拿到响应后就把usage字段记录下来。非流式请求直接从响应体里取，流式请求在最后一条chunk里取。这样就算平台接口偶尔抽风查不到历史用量，本地也有完整的数据可以回溯。

6. 二次开发改造：从能跑到好用，封装一个Service层

把DeepSeek API接入业务项目时，不建议直接把call_deepseek函数撒得到处都是。真实项目里一个接口往往要同时管密钥注入、日志埋点、降级策略、并发控制这些横切关注点。我的做法是抽一个独立的Service层，把模型调用细节封装在类内部，业务代码只面对一个简洁的方法签名。

class DeepSeekClient: def __init__(self, api_key: str, model: str = "deepseek-chat"): self.api_key = api_key self.model = model self.base_url = os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com/v1") self.session = requests.Session() self.session.headers.update({ "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" }) def chat(self, messages: list, temperature: float = 0.7, max_tokens: int = 1024): payload = { "model": self.model, "messages": messages, "temperature": temperature, "max_tokens": max_tokens, "stream": False } resp = self.session.post(f"{self.base_url}/chat/completions", json=payload, timeout=60) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

这个封装有两个关键点。第一，用requests.Session()复用TCP连接，连续多次调用时不会每次都重新建连，性能上明显优于裸requests.post。第二，把鉴权头固化在Session的headers里，业务代码不需要关心鉴权细节，只传消息内容即可。

接下来是异步改造。如果项目里同时有多个请求要发给DeepSeek——比如一个批量任务要把一百条文本逐个做摘要——串行调用会让总耗时线性增长。改用asyncio配合httpx.AsyncClient可以把并发请求数量拉上去，但要注意一个核心约束：API服务端有每分钟请求数限制，并发开太高会触发429，做一批请求测一次阈值比盲目加大并发安全得多。

再往后就是降级与缓存。AI服务调用失败在所难免，成熟项目的常见做法是在Service层加一层缓存——对相同输入参数的结果做短时缓存，命中缓存就直接返回，不消耗token。降级逻辑则是在调用失败后走备用通道，比如返回一个默认的兜底文案，避免用户直接看到错误信息。这两个改造都在Service层完成，业务代码的调用方式不需要变。

如果项目管线本身就依赖多轮对话，需要注意messages数组的维护方式。把整个对话历史每次请求都塞进去是最简单的，但token消耗很快。我的实践是：超长对话时只保留最近几轮加上最初一轮系统指令，中间的历史上下文做摘要压缩。这套策略我用了很久，平衡了上下文连续性和成本两个维度。从那以后我每次做API集成都会先给Service层画好边界——哪些功能由SDK做、哪些由业务层做、哪些降级兜底，三个月后再回来看代码依然觉得清晰。希望这篇笔记能帮你在接DeepSeek API时少踩几个我踩过的坑，顺利把第一个真实请求跑起来。

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