企业官网建设流程全解析

简介：DirectX SDK 是微软面向 Windows 游戏开发与图形程序开发提供的软件开发工具包，适合需要调用 GPU、音频及输入设备接口的开发者，也可为“网狐”等依赖 DirectX 技术的项目提供编译与运行支持。压缩包为 zip 格式，约 18.62MB；文件总数与类型明细暂无数据，包内通常包含 Direct3D、DirectSound、DirectInput、DirectShow 等组件相关的库、头文件、示例代码、文档与调试工具，便于理解图形渲染、音频处理和输入控制流程。目前已有 285 人浏览学习。对于需要排查旧项目编译环境、补齐 DirectX 接口认知或参考示例实现的读者，这份 SDK 可作为较完整的工具集，帮助定位图形与多媒体功能接入中的关键环节。

1. DirectX SDK 不是装完就能跑：先看清头文件、库和工具的边界

很多人拿到 DirectX SDK 的第一反应是双击安装，然后在工程里写#include <d3dx11.h>，编译时才发现头文件找不到，或者链接阶段报LNK1104: 无法打开文件“d3dx11.lib”。这不是安装包坏了，而是 DirectX SDK 的目录结构和工程平台没有对上。它更像一套“图形、音频、输入、工具”的集合：头文件、静态库、运行时 DLL、示例和命令行工具分开摆放，x86 与 x64 的库也分开放。这个资源适合正在维护旧 D3D9/D3D11 示例、需要 D3DX 工具链、或者要补 XAudio2/XInput 旧接口的从业者；如果你只写现代 D3D12，很多头文件已经在新系统 SDK 里，不必整套搬进来。先认清边界，后面配置才不会翻车。

2. 解包与工程接线：Include、Lib 和运行库的三处硬配置

2.1 先认目录：Include、Lib、Utilities 各管什么

DirectX SDK 安装完成后，根目录通常会有Include、Lib、Utilities、Samples、Redist、Documentation这几块。新手最容易犯的错，是把整个根目录一股脑塞进工程的附加包含目录，结果旧头文件和新系统头文件打架。比较稳的做法是先认清楚每个目录负责什么，再按需接线。

DXSDK_DIR是安装器通常会给的环境变量，指向安装根目录。我一般不会把它的Include和Lib写进系统全局 PATH，因为一旦机器上存在多套 SDK，命令行和 IDE 很容易读到不同版本，编译结果就成了玄学。工程里显式引用$(DXSDK_DIR)，比依赖全局环境更可控。

先确认环境变量是否存在：

echo %DXSDK_DIR% if not defined DXSDK_DIR set DXSDK_DIR=D:\SDK\DirectX

这段批处理的逻辑很简单：先打印当前值，如果没有定义，就给一个本地兜底路径。参数说明：D:\SDK\DirectX只是示例安装位置，实际要换成你机器上的根目录。注意不要写成D:\SDK\DirectX\Include，因为后面工程属性里还要再拼Include和Lib\x64，多拼一层会直接找不到头文件。

2.2 工程属性三处硬配置：包含目录、库目录、附加依赖项

真正要让一个 DirectX SDK 工程跑起来，至少要对三处：附加包含目录、附加库目录、附加依赖项。很多人只加了包含目录，编译过了，链接时却找不到d3dx11.lib；也有人库目录加了 x86，工程平台却是 x64，最后报模块计算机类型冲突。血泪经验是：这三处必须和当前平台一起看，不能分开配。

工程属性里可以这样写：

附加包含目录: $(DXSDK_DIR)Include 附加库目录: $(DXSDK_DIR)Lib\$(Platform) 附加依赖项: d3d11.lib;dxgi.lib;d3dcompiler.lib;d3dx11.lib;xinput.lib

$(Platform)在 32 位工程下通常是Win32，在 64 位工程下是x64，但 DirectX SDK 的目录名是x86和x64，所以更稳的写法是按平台分别配置：32 位写$(DXSDK_DIR)Lib\x86，64 位写$(DXSDK_DIR)Lib\x64。不要指望一个宏自动把Win32翻译成x86，这部分经常需要手动分开。

如果不用 IDE，用命令行验证更直接：

cl /EHsc /I"%DXSDK_DIR%Include" /LIBPATH:"%DXSDK_DIR%Lib\x64" minimal.cpp

这段命令的含义：/EHsc打开 C++ 异常处理，/I指定头文件搜索路径，/LIBPATH指定库搜索路径，minimal.cpp是源文件。参数里最容易错的是/LIBPATH后面必须跟库目录，而不是Include目录；另外 x64 工程就要用Lib\x64，不能拿Lib\x86凑合。命令行能过、IDE 不能过时，优先检查 IDE 的当前平台和附加库目录是否一致。

再加一个最小源文件，确认头文件和库都能被找到：

#include <d3d11.h> #include <d3dx11.h> #include <xinput.h> #pragma comment(lib, "d3d11.lib") #pragma comment(lib, "dxgi.lib") #pragma comment(lib, "d3dcompiler.lib") #pragma comment(lib, "d3dx11.lib") #pragma comment(lib, "xinput.lib") int main() { // 这里不创建对象，只验证编译和链接链路 return 0; }

#pragma comment(lib, ...)的作用和“附加依赖项”等价，适合做最小验证。逻辑说明：先只验证头文件能不能包含、库能不能链接，不要一上来就写窗口和交换链。参数说明：d3d11.lib提供设备创建，dxgi.lib提供交换链相关符号，d3dcompiler.lib提供着色器编译，d3dx11.lib是旧 D3DX 接口，xinput.lib是输入接口。这里只链接不调用，链接器仍可能因为未使用而忽略部分库，但缺库时会直接报错，足够定位配置问题。

2.3 运行库与部署：开发机和目标机不是一回事

开发机上装了 DirectX SDK，程序能跑，不代表拷到目标机也能跑。旧版 D3DX 接口依赖对应的运行时 DLL，常见现象是开发机正常，目标机弹窗提示缺少某个d3dx11_xx.dll。这类问题不是代码写错，而是部署链路没补齐。Redist目录里通常放着可再分发的运行时文件，具体清单以安装包内为准，不要凭记忆手写文件名。

检查一个 exe 依赖了哪些 DLL，可以用：

dumpbin /dependents .\x64\Debug\Demo.exe

/dependents会列出导入表里的 DLL。参数说明：路径要指向实际生成的 exe，x64 程序就用 x64 版本的工具查看，不要拿 32 位工具去读 64 位镜像，否则会得到误导性的结果。看到d3dx11_xx.dll这类条目，就要确认目标机是否具备对应运行库；如果不想依赖旧 D3DX，就把纹理加载迁移到 DirectXTex 一类的新库，少一个运行期依赖，部署会轻很多。

还有一个细节：x86 和 x64 的运行时 DLL 不能混放。32 位程序旁边放 64 位 DLL，系统不会把它当回事，最后仍然报找不到模块。部署前先确认 exe 的位数，再把对应位数的运行库放到可搜索路径里，这一步没有后悔药，只能在打包前检查。

3. 第一个可复现窗口：D3D11 设备、交换链和清屏参数怎么填

3.1 交换链描述：BufferCount、Format、SwapEffect 的取值边界

DirectX SDK 里最容易让人产生“装好了但就是黑屏”的，是交换链描述填错。DXGI_SWAP_CHAIN_DESC的字段不少，但真正影响第一帧能不能显示的就那几个：缓冲区数量、格式、刷新率、输出窗口、采样描述、窗口模式和交换效果。新手不需要一上来就开 MSAA，也不需要在旧 D3D11 路径里强行用新交换模型，先把最小可显示链路跑通。

SwapEffect用DISCARD时，BufferCount通常至少为 1，双缓冲写 2 比较常见。不要在没有检查设备能力的情况下把SampleDesc.Count改成 4 或 8，MSAA 需要配合ResolveSubresource或交换链的采样设置，第一版很容易因为不支持而创建失败。全屏模式也不是第一版该碰的，窗口模式能减少显示模式切换带来的黑屏问题。

3.2 创建设备：D3D11CreateDeviceAndSwapChain 的调用顺序

设备、上下文和交换链可以一起创建，函数是D3D11CreateDeviceAndSwapChain。调用顺序不要乱：先填交换链描述，再准备特性等级数组，最后传设备标志。调试标志只在 Debug 下开，Release 包不要带，否则目标机没有调试层时会直接创建失败。

DXGI_SWAP_CHAIN_DESC scd = {}; scd.BufferCount = 2; scd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM; scd.BufferDesc.RefreshRate.Numerator = 60; scd.BufferDesc.RefreshRate.Denominator = 1; scd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT; scd.OutputWindow = hWnd; scd.SampleDesc.Count = 1; scd.Windowed = TRUE; scd.SwapEffect = DXGI_SWAP_EFFECT_DISCARD; UINT flags = 0; #ifdef _DEBUG flags |= D3D11_CREATE_DEVICE_DEBUG; #endif D3D_FEATURE_LEVEL levels[] = { D3D_FEATURE_LEVEL_11_0, D3D_FEATURE_LEVEL_10_1, D3D_FEATURE_LEVEL_10_0 }; ID3D11Device* device = nullptr; ID3D11DeviceContext* ctx = nullptr; IDXGISwapChain* swap = nullptr; HRESULT hr = D3D11CreateDeviceAndSwapChain( nullptr, D3D_DRIVER_TYPE_HARDWARE, nullptr, flags, levels, _countof(levels), D3D11_SDK_VERSION, &scd, &swap, &device, nullptr, &ctx); if (FAILED(hr)) { return hr; }

逻辑说明：第一个参数传nullptr表示使用默认适配器；第二个参数D3D_DRIVER_TYPE_HARDWARE表示优先硬件设备；flags里按需加调试层；levels按从高到低排列，创建失败时会继续尝试下一档；D3D11_SDK_VERSION必须传，不能写 0；最后三个输出参数分别是交换链、设备、上下文。参数说明：如果返回DXGI_ERROR_UNSUPPORTED，常见原因是当前环境没有可用硬件设备，比如远程会话或虚拟机，这时可以降级到D3D_DRIVER_TYPE_WARP再试一次。不要直接把 WARP 当默认，它性能低，只适合排错和兜底。

3.3 清屏与 Present：一帧最小循环和 HRESULT 检查

设备创建成功只是第一步，还要拿到后台缓冲区、创建渲染目标视图、设置渲染目标、清屏、调用Present。这一串里任何一步漏掉，表现都可能是黑屏或窗口无响应。最简单的最小帧循环如下：

ID3D11Texture2D* backBuffer = nullptr; HRESULT hr = swap->GetBuffer(0, __uuidof(ID3D11Texture2D), (void**)&backBuffer); if (FAILED(hr)) { return hr; } ID3D11RenderTargetView* rtv = nullptr; hr = device->CreateRenderTargetView(backBuffer, nullptr, &rtv); backBuffer->Release(); if (FAILED(hr)) { return hr; } ctx->OMSetRenderTargets(1, &rtv, nullptr); float clearColor[4] = { 0.1f, 0.2f, 0.3f, 1.0f }; MSG msg = {}; while (msg.message != WM_QUIT) { if (PeekMessage(&msg, nullptr, 0, 0, PM_REMOVE)) { TranslateMessage(&msg); DispatchMessage(&msg); continue; } ctx->ClearRenderTargetView(rtv, clearColor); hr = swap->Present(1, 0); if (FAILED(hr)) { break; } }

逻辑说明：GetBuffer(0, ...)拿第 0 个后台缓冲区；CreateRenderTargetView创建渲染目标视图；OMSetRenderTargets把视图绑到输出合并阶段；ClearRenderTargetView的第二个参数是 RGBA 四元组；Present第一个参数是同步间隔，1表示开启垂直同步，0表示立即呈现，第二个参数是标志位，第一版写0即可。参数说明：如果Present返回DXGI_STATUS_OCCLUDED，它不是失败，表示窗口被遮挡，可以稍后重试；如果返回DXGI_ERROR_DEVICE_REMOVED，就要去查设备移除原因，不能继续循环。

这里最容易翻车的地方是：只创建了设备，没有创建渲染目标视图就清屏；或者ClearRenderTargetView传了空视图；或者窗口句柄还没准备好就创建交换链。出现黑屏时，先确认hWnd有效，再确认CreateRenderTargetView返回成功，最后看Present的 HRESULT。不要一上来就怀疑驱动，DirectX SDK 工程里大部分第一帧问题都是参数和顺序问题。

4. 着色器与纹理资源：HLSL 编译、D3DX 迁移和离线工具链

4.1 用 D3DCompile 编译 HLSL：入口点、目标模型和错误信息

旧示例里常见D3DX11CompileFromFile，但这条接口依赖 D3DX，迁移时更推荐D3DCompileFromFile。两者都是运行时编译，区别在于后者属于更通用的着色器编译接口，链接d3dcompiler.lib即可。先准备一个最小 HLSL：

struct VSInput { float3 pos : POSITION; }; struct VSOutput { float4 pos : SV_POSITION; }; VSOutput VSMain(VSInput input) { VSOutput output; output.pos = float4(input.pos, 1.0f); return output; } float4 PSMain(VSOutput input) : SV_TARGET { return float4(1.0f, 0.5f, 0.2f, 1.0f); }

编译代码可以这样写：

ID3DBlob* vsBlob = nullptr; ID3DBlob* errBlob = nullptr; HRESULT hr = D3DCompileFromFile( L"triangle.hlsl", nullptr, nullptr, "VSMain", "vs_5_0", D3DCOMPILE_DEBUG | D3DCOMPILE_SKIP_OPTIMIZATION, 0, &vsBlob, &errBlob); if (FAILED(hr)) { if (errBlob) { OutputDebugStringA((const char*)errBlob->GetBufferPointer()); errBlob->Release(); } return hr; }

逻辑说明：D3DCompileFromFile的第一个参数是文件路径，第二个参数是宏定义数组，第三个参数是 include 处理接口，第四个参数是入口点，第五个参数是目标模型，第六个参数是编译标志，第七个参数是效果标志，最后两个输出编译结果和错误信息。参数说明：vs_5_0对应特性等级 11_0；如果设备只到 10_0，就要改成vs_4_0。D3DCOMPILE_DEBUG和D3DCOMPILE_SKIP_OPTIMIZATION只建议在 Debug 下使用，Release 下关掉，否则着色器体积和运行效率都会受影响。入口点大小写要和 HLSL 里完全一致，VSMain写成vsmain在某些编译路径下会直接报找不到入口。

错误信息不要只看返回码，errBlob里通常有行号和原因。很多“着色器编译失败”其实不是语法错，而是文件路径相对于工作目录变了，或者宏定义没传进去。把errBlob输出到调试窗口，比盯着 HRESULT 猜要快得多。

4.2 纹理加载：D3DX11CreateTextureFromFile 的便利和迁移边界

旧 D3DX 加载纹理确实方便，一个函数就能从文件创建资源和视图：

D3DX11_IMAGE_LOAD_INFO info = {}; info.Width = D3DX11_DEFAULT; info.Height = D3DX11_DEFAULT; info.Depth = D3DX11_DEFAULT; info.FirstMipLevel = 0; info.MipLevels = D3DX11_DEFAULT; info.Usage = D3D11_USAGE_DEFAULT; info.BindFlags = D3D11_BIND_SHADER_RESOURCE; info.CpuAccessFlags = 0; info.MiscFlags = 0; info.Format = DXGI_FORMAT_FROM_FILE; info.Filter = D3DX11_FILTER_POINT; info.MipFilter = D3DX11_FILTER_LINEAR; ID3D11Resource* tex = nullptr; ID3D11ShaderResourceView* srv = nullptr; HRESULT hr = D3DX11CreateTextureFromFile( device, L"brick.dds", &info, nullptr, &tex, &srv);

逻辑说明：D3DX11_IMAGE_LOAD_INFO控制加载时的尺寸、mip 层级、用途、绑定标志、格式和过滤方式；Format设为DXGI_FORMAT_FROM_FILE表示按文件内容识别；MipLevels用D3DX11_DEFAULT表示按文件生成；Filter和MipFilter只在需要缩放或生成 mip 时起作用。参数说明：如果纹理只做采样，BindFlags用D3D11_BIND_SHADER_RESOURCE；如果要作为渲染目标，还要加对应标志。D3DX11CreateTextureFromFile的最后一个参数可以直接输出 SRV，省一次创建，但也意味着资源格式和视图格式被绑定在一起，迁移时要拆开看。

迁到 DirectXTex 时，思路要变成“先加载纹理数据，再创建资源，再创建视图”。常见做法是用CreateTextureFromFile拿到ScratchImage，再用CreateShaderResourceView创建视图。边界在于：旧 D3DX 支持的某些压缩格式和新库不一定完全一致，DDS 文件本身也有 DX10 扩展头和无扩展头两种写法。遇到加载失败，先用texconv把源文件转成标准 DDS，再回头看代码，不要直接在加载函数里猜格式。

4.3 工具链：fxc、texconv 和调试输出各管一段

DirectX SDK 的Utilities目录里，fxc.exe和texconv.exe是两个很实用的离线工具。fxc把 HLSL 编译成字节码，适合在构建阶段生成.cso，运行时就不需要把源码和编译器一起带出去；texconv把常见图片转成 DDS，并能控制压缩格式、mip 层级和尺寸。

离线编译的一个直接好处是：目标机不需要运行着色器编译流程，少一个运行期依赖。代价是调试时改一行 HLSL 就要重新跑构建，所以开发阶段可以保留运行时编译，发布前再切到离线字节码。

fxc /T vs_5_0 /E VSMain /Fo triangle_vs.cso triangle.hlsl texconv -f BC7 -m 0 -o .\textures .\textures\brick.png

fxc的参数里，/T是目标模型，/E是入口点，/Fo是输出文件；texconv的-f BC7指定压缩格式，-m 0表示生成完整 mip 链，-o指定输出目录。注意-m 0不是“不生成 mip”，而是按完整链生成；不想生成 mip 时要查对应工具的开关，不要凭感觉写。离线产物要纳入版本管理或构建缓存，否则换一台机器很容易出现“代码没变但画面变了”的问题。

5. 避坑与排查：x86/x64、D3DX 缺失和版本冲突的五个现场

5.1 链接期翻车：LNK1104、LNK1112 和 LNK2019

现象一：LNK1104: 无法打开文件“d3dx11.lib”。
原因通常不是库文件不存在，而是附加库目录没配，或者工程平台和库目录位数不一致。解决时先确认DXSDK_DIR是否指向正确根目录，再看附加库目录是Lib\x86还是Lib\x64。可以用dumpbin /headers看库文件的机器类型，别靠目录名猜。

dumpbin /headers "%DXSDK_DIR%Lib\x64\d3dx11.lib" | findstr /i "machine"

/headers读取文件头，findstr过滤机器类型。参数说明：x64 库应该显示 x64 相关机器字段，x86 库显示 x86 字段。如果工程是 x64，库目录却指向Lib\x86，链接器就会报模块计算机类型冲突。

现象二：LNK1112: 模块计算机类型“x64”与目标计算机类型“x86”冲突。
原因很直接：工程平台是 x86，附加库目录却用了 x64。解决方法是把库目录按平台拆开配置，32 位工程用$(DXSDK_DIR)Lib\x86，64 位工程用$(DXSDK_DIR)Lib\x64。不要用一个固定路径同时服务两个平台，后面一定还会再翻车。

现象三：LNK2019: 无法解析的外部符号 D3D11CreateDeviceAndSwapChain。
原因通常是没链接d3d11.lib，或者只写了函数声明但没有把库加进链接输入。最小验证可以在源文件里加：

#pragma comment(lib, "d3d11.lib") #pragma comment(lib, "dxgi.lib")

这两行等价于在工程属性里加附加依赖项。参数说明：d3d11.lib提供设备创建，dxgi.lib提供交换链和 DXGI 相关符号。如果用了D3DCompileFromFile，还要加d3dcompiler.lib；用了 XInput 就加xinput.lib。缺哪个补哪个，不要一次把整个 Lib 目录所有库都塞进去，链接时间会变长，冲突也更难查。

5.2 运行期翻车：D3DX DLL 缺失、黑屏和调试层失效

现象四：开发机正常，拷到目标机提示缺少d3dx11_xx.dll。
原因是目标机没有对应的 D3DX 运行库，而开发机装了 DirectX SDK，所以本地能跑。解决方式有两种：随程序部署Redist中对应位数的运行库，或者把纹理加载迁移到不依赖 D3DX 的新库。前一种更快，但要确认 x86/x64 不能混；后一种更干净，但需要改代码。部署前用dumpbin /dependents看导入表，比在目标机上反复弹窗试要快。

现象五：D3D11CreateDeviceAndSwapChain返回DXGI_ERROR_UNSUPPORTED，或者窗口一直黑屏。
原因可能是当前环境没有硬件设备，比如远程会话、虚拟机或驱动异常；也可能是交换链描述不合法，比如OutputWindow为空、SwapEffect和BufferCount不匹配。解决时先做 WARP 回退，把“设备创建失败”和“交换链创建失败”分开：

HRESULT hr = D3D11CreateDeviceAndSwapChain( nullptr, D3D_DRIVER_TYPE_HARDWARE, nullptr, flags, levels, _countof(levels), D3D11_SDK_VERSION, &scd, &swap, &device, nullptr, &ctx); if (hr == DXGI_ERROR_UNSUPPORTED) { hr = D3D11CreateDeviceAndSwapChain( nullptr, D3D_DRIVER_TYPE_WARP, nullptr, flags, levels, _countof(levels), D3D11_SDK_VERSION, &scd, &swap, &device, nullptr, &ctx); }

WARP 是软件光栅化路径，适合确认参数和逻辑是否正常。参数说明：如果 WARP 能创建成功而硬件路径失败，问题更可能在驱动或环境；如果 WARP 也失败，优先检查交换链描述和窗口句柄。调试层开启后仍看不到输出，可能是调试组件没装，或者flags只在 Debug 下加，Release 下根本没开。

现象六：加了D3D11_CREATE_DEVICE_DEBUG后创建失败。
原因是目标环境没有可用的调试层，或者调试标志和当前特性等级、驱动组合不兼容。解决方法是先在 Release 下去掉调试标志跑通，再回到 Debug 环境补调试组件。生产包不要带调试标志，这不是性能问题，而是会导致部分机器直接创建失败。

5.3 配置期翻车：头文件顺序和全局 PATH 的隐性污染

现象七：编译时报d3d11.h里某个类型重定义，或者同一工程里新旧接口打架。
原因是 DirectX SDK 的Include和系统自带的新版 SDK 头文件同时进入搜索路径，顺序不同就会读到不同版本。解决时不要把整个Include全局塞进所有工程；必须用旧 D3DX 的源文件单独隔离，其他文件继续用系统头文件。能迁移的接口优先迁移，迁移不了的再局部包含旧头，减少污染面。

现象八：命令行能编译，IDE 不能编译，或者反过来。
原因通常是全局 PATH、系统环境变量和工程属性指向了不同 SDK 版本。解决时在工程里显式写$(DXSDK_DIR)，不要依赖 PATH；检查系统环境变量里有没有残留的旧路径。配置类问题最怕“看起来都一样”，实际每个入口读到的路径不同。把工程属性、命令行环境和 IDE 当前平台三处对齐，再谈代码问题。

6. 把问题钉在具体 API 上：调试层、帧循环和一次最小验证

最后一章不再铺功能，收在一个习惯上：每拿到一套 DirectX SDK 包，先跑最小设备创建和清屏，再碰着色器和纹理。这样做的原因是，设备创建、交换链、渲染目标视图这三步覆盖了大部分环境问题；如果这三步能过，后面的问题更容易定位到具体 API，而不是在“黑屏”里猜。

我常用的 HRESULT 检查宏如下：

#define DX_CHECK(expr) do { \ HRESULT _hr = (expr); \ if (FAILED(_hr)) { \ char _buf[256]; \ sprintf_s(_buf, "HRESULT 0x%08X at %s:%d", \ (unsigned)_hr, __FILE__, __LINE__); \ OutputDebugStringA(_buf); \ return _hr; \ } \ } while (0)

逻辑说明：宏把表达式包在do...while(0)里，避免作用域问题；失败时把 HRESULT、文件名和行号输出到调试窗口，然后直接返回。参数说明：sprintf_s的缓冲区大小要够，%08X输出 8 位十六进制；__FILE__和__LINE__用来定位调用点。这个宏不适合所有场景，比如需要清理资源后再返回的地方，就要手动展开，但它能把“哪一行失败”钉死。

常见 HRESULT 可以对照看：

验证顺序我一般固定成四步：第一步，只创建窗口和设备，不画任何东西；第二步，创建渲染目标视图并清屏，确认Present返回成功；第三步，编译一个最简单 VS/PS，画一个三角形；第四步，加载一张 DDS 纹理，确认采样和 SR

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