企业官网建设流程全解析

简介：VSCode 插件开发进阶指南，围绕跳转到定义、自动补全、悬停提示三大语言服务功能展开，适合已有一定 VSCode 基础、希望深入开发实用插件的开发者。文档以真实场景演示实现思路：跳转到定义部分以 package.json 的 dependencies/devDependencies 为例，通过 registerDefinitionProvider 注册 provider，结合正则匹配动态构造 Location 跳转到对应依赖包，并讨论按住 Ctrl 时高亮范围的限制；自动补全部分使用 registerCompletionItemProvider 实现输入 this.dependencies.xxx 时自动带出依赖列表，覆盖 provideCompletionItems 与 resolveCompletionItem 等关键方法；悬停提示部分讲解 registerHoverProvider 提供变量函数信息的技巧。三个功能是 VSCode 智能感知的重要组成，整体思路清晰，代码片段可直接复用。资源为 PDF 格式，共 1 个文件，大小 248KB，内容精炼便于随时查阅，已有 45541 人学习下载，适合希望提升插件开发效率的 VSCode 使用者。

1. 跳转到定义、自动补全、悬停提示：一个插件撑起编辑器体验的三根柱

大多数编辑器插件需求，最后都会落到三个动作：让用户能跳到符号定义处、在输入时给出候选、在悬停时解释这段代码是什么意思。这篇攻略围绕这三件事展开，用一套可完整运行的扩展示例——一个叫 mydialog 的自定义语言插件——把跳转到定义、自动补全、悬停提示从注册 Provider 到踩坑排查全部走一遍。适合两类人：第一次写 VSCode 插件、被各种 API 名称绕晕的新手；以及已经能写出插件但搞不清为什么有时候右键没有跳转到定义、写代码没有提示的老手。读完你能得到一份可复现的最小工程：package.json 怎么写、Provider 怎么注册、参数怎么调、出问题先查哪几个开关。

2. 先搞清楚架构：Provider 模型、LSP 与 Extension Host 的分工

写插件之前把三件事想明白，后面排错能省一半时间：你的代码跑在哪个进程、你的功能以什么形式暴露给编辑器、编辑器什么时候会调用你的代码。

2.1 三个 Provider 的注册点与生命周期

VSCode 把语言能力抽象成一组 Provider 接口。跳转对应 DefinitionProvider，补全对应 CompletionItemProvider，悬停对应 HoverProvider。这三种接口的注册函数都在vscode.languages命名空间下，签名分别是：

const vscode = require('vscode'); // 跳转到定义 const d = vscode.languages.registerDefinitionProvider( { language: 'mydialog', scheme: 'file' }, { provideDefinition(doc, pos, token) { /* ... */ } } ); // 自动补全，最后一个参数是触发字符 const c = vscode.languages.registerCompletionItemProvider( { language: 'mydialog', scheme: 'file' }, { provideCompletionItems(doc, pos, token) { /* ... */ } }, ':' ); // 悬停提示 const h = vscode.languages.registerHoverProvider( { language: 'mydialog', scheme: 'file' }, { provideHover(doc, pos, token) { /* ... */ } } ); // 统一交给 context.subscriptions 管理 context.subscriptions.push(d, c, h);

三个函数都会返回一个 Disposable 对象。最常见也是最容易被忽略的写法是把它们全部 push 进context.subscriptions，插件停用或窗口关闭时由 VSCode 统一释放。如果你手动在deactivate里再调用一次dispose()，反而可能重复清理，这也是第 5 章会展开讲的一个坑。

documentSelector 是这个模型的第一个核心参数。{ language: 'mydialog', scheme: 'file' }的意思是：只在语言 ID 为 mydialog、来源是磁盘文件的文档上触发。加上scheme: 'file'可以避免在未保存的临时文件、输出面板、diff 视图里误触发。很多“插件没生效”的案例，最后查出来是 documentSelector 里的语言 ID 和实际语言 ID 对不上。

2.2 三条实现路线：直接 Provider、LSP 语言服务器、混合式解析

同样是实现跳转和补全，工程上通常有三条路线可选。选择标准从来不是“哪个高级”，而是“你的语言有多复杂”。

直接注册 Provider 是最快的落地姿势。以 mydialog 这套示例为例，符号表就是一个 components.txt 文件，几十行文本，完全没有必要为它起一个语言服务器进程。相比之下，IntelliJ 平台那套 PSI 体系要先往树里塞数据才能做补全和跳转，VSCode 这种 Provider 模型把复杂度压在你的数据侧。当你解析逻辑膨胀到几千行、需要增量索引时，再把解析拆到独立进程走标准的语言服务器协议，插件侧只需要改数据来源，Provider 的返回结构基本不变。

2.3 最小工程骨架：package.json 与 launch.json

写代码之前先把工程骨架搭起来。一个最小扩展只需要两个文件加一个启动配置。

{ "name": "mydialog-helper", "displayName": "MyDialog Helper", "version": "0.0.1", "engines": { "vscode": "^1.84.0" }, "activationEvents": ["onLanguage:mydialog"], "main": "./extension.js", "contributes": { "languages": [ { "id": "mydialog", "extensions": [".dialog"], "configuration": { "wordPattern": "[A-Za-z0-9_]+" } } ] } }

activationEvents里的onLanguage:mydialog表示：当 VSCode 打开了一个语言 ID 为 mydialog 的文件时，才激活这个插件。新版 VSCode 对部分 contributes 项会自动推断激活时机，但显式写出来有两个实际好处：一是兼容旧版本，二是在排查“插件到底有没有跑起来”时，你能明确知道激活条件是什么。wordPattern影响编辑器对“单词”的切分，如果补全项没有显式设置补全范围，VSCode 默认用它来圈定要被替换的文本，这个配置在后面补全那一章会再次碰到。

{ "version": "0.2.0", "configurations": [ { "name": "Run Extension", "type": "extensionHost", "request": "launch", "args": ["--extensionDevelopmentPath=${workspaceFolder}"] } ] }

按 F5 后，VSCode 会启动一个“扩展开发宿主”窗口，这个新窗口自动加载当前工程里的插件。--extensionDevelopmentPath指向工程根目录，launch.json 里的${workspaceFolder}会自动替换成当前打开的工作区路径。在这个新窗口里，你可以打开.dialog文件、按 F12、触发补全、悬停，全部行为都在真实编辑器环境里发生。

3. 跳转到定义：从 Provider 注册到跨文件跳转的参数与实现

跳转功能实现起来不难，真正容易翻车的是：返回的 Location 行号算错、跨文件时 URI 拼错、没判空导致单文件场景下直接抛异常。这一章用一个完整可运行的示例把链路讲透。

3.1 最小实现：为 mydialog 语言注册 DefinitionProvider

先定义我们这套示例语言的规则。.dialog文件里写的是组件引用：

import [comp:Button] import [comp:Panel]

组件定义集中在components.txt里：

[comp:Button] name = 按钮 desc = 点击事件入口 [comp:Panel] name = 面板 desc = 容器

跳转语义很直白：光标落在某个组件名上，按 F12 跳到components.txt里对应的[comp:xxx]行。最小实现如下：

const vscode = require('vscode'); const fs = require('fs'); function findComponent(componentName) { const folder = vscode.workspace.workspaceFolders?.[0]; if (!folder) return null; const defFile = vscode.Uri.joinPath(folder.uri, 'components.txt'); const content = fs.readFileSync(defFile.fsPath, 'utf-8'); const lines = content.split('\n'); for (let i = 0; i < lines.length; i++) { const m = lines[i].match(/\[comp:(.+)\]/); if (m && m[1] === componentName) { return new vscode.Location(defFile, new vscode.Position(i, 0)); } } return null; } function activate(context) { const provider = vscode.languages.registerDefinitionProvider( { language: 'mydialog', scheme: 'file' }, { provideDefinition(document, position) { const lineText = document.lineAt(position.line).text; const m = lineText.match(/import\s+\[comp:([^\]]+)\]/); if (!m) return null; return findComponent(m[1]); } } ); context.subscriptions.push(provider); } function deactivate() {} module.exports = { activate, deactivate };

这段代码里有两个关键参数：vscode.Position(i, 0)的i是 0-based 行号，编辑器状态栏显示的是 1-based，初写插件的人经常在这里混。另一个是vscode.Uri.joinPath(folder.uri, 'components.txt')，第一个参数必须是 Uri 对象，不是字符串路径。provideDefinition返回null时，右键菜单里的“跳转到定义”会置灰，这是正常行为，不是 Bug。菜单项置灰恰恰说明 Provider 已经被正确注册，当前光标位置没有可跳转的目标而已。

3.2 跨文件跳转：用缓存索引避免每次读文件

上面的实现每次跳转都全量读一次 components.txt。文件几十行无所谓，等符号表涨到几千行、用户频繁 F12 时就会感到卡顿。更稳的做法是给符号建一个带失效机制的索引。

class ComponentIndex { constructor() { this._positions = new Map(); this._mtimeMs = -1; } getPosition(name) { this._ensureIndexed(); return this._positions.get(name) ?? null; } _ensureIndexed() { const folder = vscode.workspace.workspaceFolders?.[0]; if (!folder) return; const uri = vscode.Uri.joinPath(folder.uri, 'components.txt'); const stat = fs.statSync(uri.fsPath); if (stat.mtimeMs === this._mtimeMs) return; const content = fs.readFileSync(uri.fsPath, 'utf-8'); this._positions.clear(); const lines = content.split('\n'); for (let i = 0; i < lines.length; i++) { const m = lines[i].match(/\[comp:(.+)\]/); if (m) this._positions.set(m[1], new vscode.Position(i, 0)); } this._mtimeMs = stat.mtimeMs; } }

用stat.mtimeMs做缓存失效判断，能覆盖大多数场景。它的边界问题在于：如果两次写入发生在同一毫秒内，mtime 相同，缓存不会被刷新。这属于极端情况，但生产环境我更推荐监听vscode.workspace.onDidSaveTextFile事件，在保存动作发生时直接清空_positions。两个方案可以叠加，前者兜底，后者处理同毫秒写入。

这里还有一个新手容易踩的坑：fs.readFileSync在文件不存在时会抛异常。单文件场景下，用户只打开了一个.dialog文件，没打开工作区文件夹，workspaceFolders是undefined，上面的?.已经兜了一层。但工作区存在而 components.txt 被改名或删除，statSync和readFileSync都会抛错。稳妥做法是把读文件包一层 try/catch，失败时返回空 Map，让跳转安静地失效。

3.3 返回 LocationLink：跳转预览与目标高亮

单一Location是够用的，但 VSCode 还支持返回LocationLink，它能控制在跳转预览里高亮哪一段、以及光标最终落在哪一行。区别在于，LocationLink是对象数组，允许你区分“整个定义范围”和“应该选中的名字范围”。

function buildLocationLink(defUri, pos, lineText, name, originLine) { const lineRange = new vscode.Range(pos, pos.translate(0, lineText.length)); const nameStart = pos.translate(0, '[comp:'.length); const nameRange = new vscode.Range( nameStart, nameStart.translate(0, name.length) ); return { targetUri: defUri, targetRange: lineRange, targetSelectionRange: nameRange, originSelectionRange: new vscode.Range( originLine, 0, originLine, lineText.length ) }; }

四个字段里，targetRange是跳转后预览窗口展示的整个区域，targetSelectionRange是光标最终选中/高亮的区间，originSelectionRange是来源文档里触发跳转的那段词。返回LocationLink数组时，VSCode 还会在按住 Ctrl 悬停时显示预览卡片，体验上比硬跳转舒服一些。如果你只返回单个Location，这些高亮细节都用不了。

4. 自动补全与悬停提示：两个 Provider 的触发时机与内容组装

跳转定义解决“这段代码从哪来”，自动补全解决“接下来能写什么”，悬停提示解决“这段代码是什么”。这两个 Provider 的代码结构和跳转类似，但各自有一套容易出问题的参数。

4.1 CompletionItemProvider 的最小实现：触发字符与补全范围

补全最常见的失败姿势是：输入[comp:之后什么都不弹。原因在于 VSCode 默认的补全触发时机依赖单词边界，而[comp:这种中间带方括号和冒号的文本根本不是“单词”。这时就要靠第三个参数——触发字符——来告诉编辑器主动询问一次。

const vscode = require('vscode'); const fs = require('fs'); function listComponentNames() { const folder = vscode.workspace.workspaceFolders?.[0]; if (!folder) return []; const uri = vscode.Uri.joinPath(folder.uri, 'components.txt'); if (!fs.existsSync(uri.fsPath)) return []; const content = fs.readFileSync(uri.fsPath, 'utf-8'); const names = []; for (const line of content.split('\n')) { const m = line.match(/\[comp:(.+)\]/); if (m) names.push(m[1]); } return names; } function activate(context) { const provider = vscode.languages.registerCompletionItemProvider( { language: 'mydialog', scheme: 'file' }, { provideCompletionItems(document, position) { const linePrefix = document.lineAt(position.line).text.slice(0, position.character); const m = linePrefix.match(/\[comp:([^\] ]*)$/); if (!m) return []; const insertRange = new vscode.Range( position.line, position.character - m[1].length - '[comp:'.length, position.line, position.character ); return listComponentNames().map((name) => { const item = new vscode.CompletionItem(name, vscode.CompletionItemKind.Class); item.range = insertRange; return item; }); } }, ':' ); context.subscriptions.push(provider); }

insertRange是这段代码里最关键的参数。它告诉 VSCode：当你确认某个补全项时，要替换从[comp:开头到当前光标的整段文本。不设置range时，VSCode 只会替换它自己识别的“当前单词”，而[comp:这种带特殊字符的前缀会被截断成残渣。在[comp:后面继续输入字母时，正则会用([^\] ]*)$捕获已输入的部分，比如你输入了B，m[1]就是B，insertRange 的起点自动往回收一个字符，补全列表会正确过滤出以 B 开头的候选。

4.2 文件读取要异步化：补全弹出的速度决定体验

上面的listComponentNames用了同步读文件。跳转场景里同步读还能忍，补全场景每次按键都可能触发一次读取，文件一大会有明显的卡顿。provideCompletionItems支持返回 Promise，改成异步版本后，UI 不会被 IO 阻塞。

const { promises: fsPromises } = require('fs'); async function listComponentNamesAsync(token) { const folder = vscode.workspace.workspaceFolders?.[0]; if (!folder) return []; const uri = vscode.Uri.joinPath(folder.uri, 'components.txt'); const content = await fsPromises.readFile(uri.fsPath, 'utf-8').catch(() => ''); if (token?.isCancellationRequested) return []; const names = []; for (const line of content.split('\n')) { const m = line.match(/\[comp:(.+)\]/); if (m) names.push(m[1]); } return names; }

这段代码里有两个工程细节。第一，await之后必须再做一次token.isCancellationRequested检查。用户在补全弹出的瞬间继续打字，前一个请求已经被取消，但我们还是会把一批旧数据返回去，白白增加一次组件渲染。第二，catch(() => '')兜住文件不存在的异常，否则readFile抛错会导致整个补全列表消失，同时状态栏弹错误提示。

排序参数sortText值得单独说。VSCode 默认会根据用户输入做模糊匹配排序，但它的排序规则是字符串字面量比较。想让某些项固定排在最前面，可以用数字前缀控制权重：'10'排在'9'前面，因为字符串从第一位开始比较。要固定顺序，前缀需要补零成等长字符串，比如'01'、'02'，再用名字做后缀。如果你想指定默认选中的项，给CompletionItem设preselect = true，编辑器会在弹出时直接高亮这一项。

4.3 HoverProvider 的最小实现：Markdown 组装与光标范围判断

悬停提示的实现比前两个更简单，但大多数人在这里犯的错是：正则匹配到组件名，却没判断光标是否真的落在组件名上。

function findComponentDescription(name) { const folder = vscode.workspace.workspaceFolders?.[0]; if (!folder) return null; const uri = vscode.Uri.joinPath(folder.uri, 'components.txt'); const content = fs.readFileSync(uri.fsPath, 'utf-8'); const lines = content.split('\n'); for (let i = 0; i < lines.length; i++) { const m = lines[i].match(/\[comp:(.+)\]/); if (m && m[1] === name) { for (let j = i + 1; j < lines.length && j <= i + 5; j++) { const dm = lines[j].match(/desc\s*=\s*(.+)/); if (dm) return dm[1]; } return '该组件没有描述'; } } return null; } const hoverProvider = vscode.languages.registerHoverProvider( { language: 'mydialog', scheme: 'file' }, { provideHover(document, position) { const line = document.lineAt(position.line).text; const m = line.match(/\[comp:([^\]]+)\]/); if (!m) return null; const nameStart = m.index + m[0].length; const nameEnd = nameStart + m[1].length; if (position.character < nameStart || position.character > nameEnd) return null; const desc = findComponentDescription(m[1]); if (desc === null) return null; const md = new vscode.MarkdownString(`**${m[1]}**\n\n${desc}`); md.isTrusted = true; return new vscode.Hover(md); } } );

nameStart的计算方式是正则需要点。m.index是整个匹配结果在行文本里的起始位置，m[0]是匹配到的完整文本[comp:Button]，m[0].length包含了右方括号，但这种写法在这里只是用于从m.index往后推到名字起点。更准确的起点应该是m.index + '[comp:'.length。两种写法在恰好都在Button前一个字符处，区别在于当正则里有多个方括号嵌套时，基于m[0]的写法会算错，所以统一用m.index + '[comp:'.length更可靠。

悬停返回的对象是vscode.Hover，构造参数可以是一个 MarkdownString，也可以是数组，数组里每一项会依次渲染成段落。md.isTrusted = true允许 Markdown 里的链接和命令可点击，默认 false 会禁用这些交互。如果该行有多个[comp:xxx]，当前这个match只取第一个，更完整的实现应该用全局匹配matchAll循环判断光标落在哪一个区间里，实战里这个边界很值得补上。

5. 避坑/排查：三个功能最常见的 5 个翻车现场

前四章把功能跑通，这一章把我在实际开发里踩过、以及帮别人排查过的典型故障汇总在一起。每一条都是“现象 → 原因 → 解决”的完整链路。

5.1 右键没有跳转到定义：先查语言选择器再查返回值

现象：在.dialog文件里按 F12，没有任何反应，右键菜单里的“跳转到定义”是灰色不可点的。

原因有一个容易误判的：灰色不可点不一定代表注册失败。provideDefinition返回null时 VSCode 就会置灰菜单项。我先看输出面板里的“扩展宿主”日志，确认activate有没有执行、registerDefinitionProvider有没有被调用。然后才怀疑 documentSelector 里的语言 ID 与实际文件不匹配。用命令面板里的“Developer: Inspect Editor Tokens and Scopes”能直接看到当前文件的 language ID，这是最快的方式。

解决：按“现象 → 语言 ID 是否匹配 → 光标位置正则是否命中 → Provider 是否返回 null”的顺序排查。常见反转是：语言 ID 写成了mydialog，文件实际语言是plaintext，因为.dialog后缀可能被你本机的files.associations设置覆盖了。这种时候先清除用户级覆盖配置再测试。

5.2 补全不弹出：activationEvents、triggerCharacters、range 三连

现象：在[comp:后面疯狂按 Ctrl+Space，补全列表就是不出现；或者出现了但确认后文本变成[comp:Button，前缀残留。

原因基本逃不出三个：插件没激活、触发字符没配、range 没设置。插件没激活时，你在provideCompletionItems里打的断点根本不会命中，需要在输出面板确认activate执行了。触发字符没配时，编辑器默认只在自己认为的“单词边界”上发起补全请求，冒号显然不算。range 没设置则会导致确认补全时只替换当前的“单词片段”。

解决：把activationEvents: ["onLanguage:mydialog"]、registerCompletionItemProvider(selector, provider, ':')、item.range 三个位置全部检查一遍。如果你在 VSCode 里写 C 语言没有代码提示，排查套路完全一样：先看 C/C++ 扩展有没有被激活，再看文件是不是被误判成了别的语言 ID。补全这种“玄学不弹”的问题，绝大多数不是算法问题，而是这三个开关里的某一个没打开。

5.3 悬停提示闪一下或内容为空：Hover 构造与 Promise 的坑

现象：鼠标放到组件名上，弹窗出现了，但内容是空白的，或者显示一瞬间就消失。

原因分两类。一类是provideHover返回了new vscode.Hover('')或空数组，VSCode 会把空内容渲染成一个小到几乎看不见的弹窗。另一类是函数体里await了一个永不 resolve 的 Promise，比如某个回调没触发，编辑器一直等不到你的返回值。

解决：先明确一个约定——不打算展示内容时，直接返回null，编辑器不会创建悬停弹窗；返回空字符串反而会产生一个空白弹窗，这是“闪一下”的常见来源。Promise 链路里所有catch分支都返回null，不要在 async 函数里让异常裸奔。另外MarkdownString.isTrusted默认 false，如果你在 Markdown 里写了相对路径图片或命令链接，它们不会渲染，这也是“内容为空”的一种表现。

5.4 跳转位置偏移：用 document.positionAt，不要手算行列

现象：跳转成功，但光标落在了目标文件的第一行行首，而不是符号所在行；或者差了一行。

原因：编辑器状态栏显示的是 1-based 行号，vscode.Position是 0-based。很多人从indexOf拿到的是字符偏移量，然后手算行列，算错一位是常态。字符偏移和行列之间不是简单除法关系，因为中间有换行符、Tab、全角字符。

解决：拿到字符偏移后，用document.positionAt(offset)转成 Position，再由编辑器负责跳转。如果你的解析是逐行扫描，直接用循环变量作为 0-based 行号是安全的。手算和读文件时的不一致，是这类偏移 Bug 最典型的来源。

const content = fs.readFileSync(defFile.fsPath, 'utf-8'); const offset = content.indexOf('[comp:' + componentName + ']'); const doc = await vscode.workspace.openTextDocument(defFile); const pos = doc.positionAt(offset);

5.5 热重载后行为重复：Provider 的 dispose 与 deactivate

现象：改完插件代码，按 F5 重新打开了一个开发窗口，但旧窗口还在工作，两个窗口的行为互相干扰；或者插件在多窗口下补全列表重复。

原因：context.subscriptions里的 Disposable 会在插件停用时自动清理，真正出问题的是那些没有走subscriptions.push的资源——比如setInterval、文件监听器、自定义事件回调。这些资源在插件热重载后不会自动销毁，两个实例的监听叠加，行为自然重复。

解决：凡是自己创建的资源，一律塞进context.subscriptions。不要手动在deactivate里调用subscriptions.forEach(d => d.dispose())，VSCode 本身会在卸载时处理，手动清一次反而可能触发二次释放。

6. 进阶验证：在 Extension Development Host 里做端到端验证

功能写完，最高效的验证方式不是手动点点点，而是直接在扩展开发宿主里用断点和命令做回归。

6.1 断点打在 provideXxx 里：启动与命中时机

按 F5 启动扩展开发宿主后，打开一个.dialog文件，在provideDefinition函数体第一行打上断点。把光标移到Button上按 F12，断点应该命中。命中那一刻，左侧变量面板里能直接看到document、position、m三个关键值——document 的语言 ID、position 的行列、正则匹配结果，整个跳转链路的数据一目了然。

如果断点不命中，先检查两件事：一是 launch.json 里--extensionDevelopmentPath是否指向了工程根目录，二是输出面板里“扩展宿主”的日志是否显示插件已激活。VSCode 对插件代码的调试本质上是把 Extension Host 当作一个 Node.js 进程来附加，所以调试面板的运行时选择只要是“扩展开发宿主”即可，不用手动配置 Node 路径。

6.2 用 executeDefinitionProvider 命令做回归测试

手动断点只能验证单次行为，回归验证要换成命令式调用。VSCode 为每个语言功能都暴露了对应的命令，在扩展代码里可以直接执行：

const vscode = require('vscode'); async function assertDefinition() { const doc = await vscode.workspace.openTextDocument('/path/to/demo.dialog'); await vscode.window.showTextDocument(doc); const position = new vscode.Position(0, 15); const locations = await vscode.commands.executeCommand( 'vscode.executeDefinitionProvider', doc.uri, position ); console.log(locations.map((loc) => loc.uri.toString())); } assertDefinition();

vscode.executeDefinitionProvider返回的是Location[]或LocationLink[]，和你在provideDefinition里返回的内容一一对应。对应地，补全可以用vscode.executeCompletionItemProvider主动触发，悬停可以用vscode.executeHoverProvider主动查询。我习惯把这三个命令包成一个runAssertions函数，改动解析逻辑后直接跑一遍，看输出是否符合预期，再手动感受一次交互。

这套验证方法的另一个用途是排查性能问题。补全弹出慢的时候，用console.time包住executeCompletionItemProvider，把耗时拆成“读文件耗时”和“组装 item 耗时”两部分，数据会直接告诉你瓶颈在 IO 还是构造逻辑。我在每次交付插件前都会把这三个命令跑一遍，三行命令能省掉大半手动测试时间。希望帮到你。

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