简介：面向需要处理三维点云数据的 GIS 从业者、点云开发者及遥感、建筑建模方向的学习者，这份压缩包提供 OSGeo4W 64 位环境下 PDAL 库的离线获取途径，缓解官网下载慢、依赖分散的问题。包内共 4159 个文件，约 233.75MB，以 py、h、hpp 等源码与头文件，dll、exe、lib 等运行库和安装组件为主，并含 html 文档、csv/gsb 数据文件及 bat、cmake 配置脚本，较完整地保留了 OSGeo4W 安装器与 PDAL 相关依赖的目录结构。已有 1895 人学习，适合网络条件受限、又需要快速补齐 PDAL 运行环境并配合 CloudCompare 做点云导入导出、格式转换和三维分析的用户。借助包内安装器、库文件与依赖项，读者能省去逐项检索和拼装环境的时间，也便于排查版本匹配、路径配置及依赖缺失等常见问题，提升点云数据读取、过滤与统计分析的准备效率。
1. 从 OSGeo4W 里取一个 PDAL：省下的不是安装时间，是环境配置
上周帮一个做市政测量的朋友处理一批街区扫描数据，十几份 LAS，单份两三千万点。他的做法是拿 CloudCompare 一份份点开看，卡到鼠标都拖不动，想批量去噪、抽稀、算地面点，又不想为一个命令行工具去折腾编译环境。这类需求在 Windows 上其实有个很实用的解法：走 OSGeo4W 安装器，勾一个 pdal 包，GDAL、PROJ、LAZ 这些依赖会被一并装好，环境脚本也现成。pdal 负责批处理，cloudcompare 负责看效果和交付，两边各干各的活。这套组合适合手上有一堆 LAS/LAZ 要洗、又不想碰 conda 和源码编译的测绘、点云预处理从业者，下面按我实际装过几台的顺序拆。
2. 用 OSGeo4W 装 PDAL：安装器分支、包名与 Shell 环境
2.1 Express Install 装不出 PDAL，必须走 Advanced
OSGeo4W 的安装器一启动会给两个选项，Express Install 是一套预设包清单，主体是桌面 GIS 那一套，里面没有 PDAL；要拿到 pdal.exe，只能选 Advanced Install，一路下一步到 Select Packages 界面，把 View 切到 Full 或者直接在上面的搜索框敲 "pdal"。包一般归在命令行工具那一类里，不同镜像的分类归属会变，搜名字比翻分类可靠。
如果你的机器上已经用 Express 装过一份，不用卸载重来。再跑一次安装器选 Advanced，指着同一个安装目录，它会识别成对现有安装的增量更新，只把新勾的包补进去。安装器会自己解依赖，但个别镜像的依赖解析会漏掉 PROJ 的数据包，装完发现 share\proj 下面是空的，这种事我遇到过。所以勾完 pdal 之后，顺手确认 gdal、proj 这两个也在待装列表里，多花十秒，省掉后面半小时的排查。
安装路径我一般固定成C:\OSGeo4W。老版本安装器默认会带 64 位后缀，路径变成C:\OSGeo4W64，两者只是目录名差异，下面的命令按自己的实际路径替换即可。不要装到带空格或中文的目录里，PDAL 本身能处理，但它调用的某些 GDAL 驱动和临时文件写入在那种路径下会出问题，属于能避就避的坑。
2.2 装完先核对目录，别急着敲命令
装完不要立刻开跑，先花一分钟确认东西到底在不在。OSGeo4W 的目录结构是固定的，PDAL 相关的文件分布在这几个位置：
| 路径 | 内容 | 用途 |
|---|---|---|
C:\OSGeo4W\bin\pdal.exe | PDAL 主程序 | 所有命令入口 |
C:\OSGeo4W\bin\*.dll | GDAL、PROJ、GEOS 等运行库 | pdal.exe 启动时按同目录优先加载 |
C:\OSGeo4W\share\gdal | GDAL 数据文件 | 对应GDAL_DATA |
C:\OSGeo4W\share\proj\proj.db | 坐标转换数据库 | 对应PROJ_DATA，重投影全靠它 |
C:\OSGeo4W\bin\o4w_env.bat | 环境初始化脚本 | 设置上面这些变量 |
核对方式很直接，从开始菜单找到 OSGeo4W Shell 打开，敲三条命令：
:: 确认 pdal.exe 的实际位置，排除 PATH 里还有另一个旧版本 where pdal :: 看版本号，确认装上了而不是个空壳 pdal --version :: 列出所有驱动，重点看 las / laz 读写能力是否齐全 pdal --driverswhere pdal如果返回两条以上路径，说明机器上还有别的 PDAL（比如以前装过的独立二进制包），后面所有命令都可能跑在错误的那一份上，先把多余的从 PATH 里摘掉。pdal --drivers的输出里，readers.las和writers.las必须同时在，LAZ 的压缩能力由编译时的 lazperf 或 laszip 决定，这一项直接关系到后面能不能写压缩文件。我在一台老机器上见过writers.las存在但压缩选项为空的情况，写 LAZ 时才会暴露，提前看一眼能省事。
2.3 o4w_env.bat 改了什么，为什么不能直接双击 pdal.exe
OSGeo4W Shell 的本质是一个 cmd 窗口，启动时先执行了bin\o4w_env.bat。这个脚本干的事不多：把bin目录塞进 PATH，设置GDAL_DATA指向 share\gdal，设置PROJ_DATA（老版本 PROJ 叫PROJ_LIB）指向 share\proj，再处理一下 Python 相关的变量。
很多人第一次翻车是在这里：直接双击pdal.exe，或者在自己常用的 PowerShell 里敲pdal --version，报错说找不到某个 DLL，或者窗口一闪而过。原因不在于 DLL 缺失——Windows 加载 DLL 时会优先搜索可执行文件所在目录，pdal.exe和它的依赖在同一个 bin 里，正常能找到。真正缺的是数据文件路径，proj.db找不到时，PDAL 在读带坐标系的 LAS 头部就会失败，报出来的信息往往很含糊，像是"某个投影参数非法"，实际就是数据库没定位到。
正确的做法有两种。省事的做法是从开始菜单进 OSGeo4W Shell，所有命令都在里面敲。要在自己的脚本里调用的做法，是在普通 cmd 里先 call 一下环境脚本：
:: 用 call 而不是直接执行，否则批处理结束后环境变量不会留在当前窗口 call C:\OSGeo4W\bin\o4w_env.bat :: 切回自己的工作目录，脚本执行完当前目录可能被改掉 cd /d D:\work\pointcloud pdal --version echo %PROJ_DATA%call这个细节值得说一句：直接写C:\OSGeo4W\bin\o4w_env.bat也能跑，但它是作为子进程执行的，执行完环境变量随进程一起消失，当前窗口什么都没变。加了call才是"在当前上下文里执行"，后面的命令才能继承到 PATH 和数据路径。
提示：不建议把
C:\OSGeo4W\bin加进系统级 PATH。它里面的 GDAL、PROJ 版本和 CloudCompare 自带的运行库经常打架，一旦全局可见，别的软件会莫名其妙起不来。需要用的窗口临时 call 一下就够了。
3. 跑通第一条管线：pdal info、translate 与 pipeline JSON
3.1 pdal info 分三层看，别一上来就 --all
拿到一份新数据，第一件事是看它有什么。pdal info分三个信息层级，按需使用，因为层级越高越慢。
# 摘要：点数、包围盒、坐标系，秒出，适合先摸底 pdal info --summary D:/data/site_a.las # 元数据：LAS 头里的全部字段、VLR、坐标系 WKT，不扫点 pdal info --metadata D:/data/site_a.las # 统计：每个维度的最值、均值、标准差，要全量扫一遍点 pdal info --stats --dimensions X,Y,Z,Intensity D:/data/site_a.las # 只想看某一个点的全部维度值，确认维度名到底叫什么 pdal info --point 12345 D:/data/site_a.las--summary的输出里有num_points、bounds的 min/max、还有srs里的坐标系描述。这三样东西后面每一步都要用到：点数是性能预算，包围盒能立刻看出坐标是不是落在合理范围（比如 X 是 4 开头的七位数，说明是投影坐标，单位是米；如果是 116 开头的小数，那就是经纬度），坐标系决定了重投影要不要做。
--stats慎用。它对全文件做一遍扫描，两三千万点的 LAS 大概要几十秒，上亿点就得好几分钟，而且它是单线程的。我一般的顺序是 summary 摸底、metadata 看坐标系、确实需要判断强度或高程分布时才上 stats。--point这个选项很多人不知道，它的价值在于确认维度名——不同来源的数据，强度字段可能叫Intensity也可能叫Intensity之外的自定义维度，写 filter 表达式时名字必须完全一致，先看一眼比猜快。
3.2 pdal translate：一次只挂一个 filter
pdal translate是最常用的入口，语法是输入、输出、可选的 filter 名，再来一串参数。格式转换最简单：
# LAS 转 LAZ，不挂任何 filter，纯压缩 pdal translate D:/data/site_a.las D:/data/site_a.laz # 挂一个统计离群点滤波，参数通过 --filters.阶段名.参数名 传入 pdal translate D:/data/site_a.las D:/data/site_a_denoise.las statisticaloutlier ^ --filters.statisticaloutlier.mean_k=10 ^ --filters.statisticaloutlier.multiplier=2.5 # 不知道某个 filter 有哪些参数可调，先问它 pdal translate --options filters.statisticaloutlier--options这条命令是排查参数问题的利器，它会把这个 stage 的所有可调参数和默认值打出来，比翻文档快。上面第二行里的^是 Windows cmd 的续行符，在 OSGeo4W Shell 里照抄可用，写成一行也行。
一次只挂一个 filter 是我踩过坑之后形成的习惯。刚上手时喜欢把去噪、抽稀、重投影、地面滤波全塞进一条 translate 命令里，跑完发现输出的点云位置整体偏了几十米，或者点数少得离谱，这时候根本分不清是哪一步干的。拆成单步之后，每一步的输出都能单独用pdal info --summary核对点数和包围盒，问题定位时间从半小时降到两分钟。
3.3 pipeline JSON：字段名、阶段顺序与 tag 分支
当流程超过两步，或者需要分支输出（比如一份原始数据同时出地面点和非地面点），就该写 pipeline 文件了。它是一个 JSON，核心是pipeline数组，数组里的每个对象就是一个 stage，数据按数组顺序流过去。
{ "pipeline": [ { "type": "readers.las", "filename": "D:/data/site_a.las" }, { "type": "filters.range", "limits": "Classification![7:7]" }, { "type": "filters.assign", "value": "Classification[:]=0" }, { "type": "writers.las", "filename": "D:/data/site_a_clean.laz", "compression": "lazperf", "minor_version": 4, "dataformat_id": 6 } ] }执行方式是pdal pipeline clean.json，把文件名直接跟在后面即可。几个字段的含义值得逐条说清：limits用的是 PDAL 的表达式语法，Classification![7:7]里的感叹号表示排除，意思是剔除分类码为 7 的点（7 通常是低噪点），[7:7]是闭区间写法；filters.assign把剩下的点的分类码统一重置为 0，避免上游数据带着一堆含义不明的分类码流到下游；writers.las里的compression只有lazperf和laszip两个有效值，具体支持哪个取决于编译，写错了会直接报错；minor_version和dataformat_id是一对，1.4 版本配 6 号格式才能同时容纳 GPS 时间和 RGB。
JSON 有两个容易翻车的书写细节。一是路径分隔符，Windows 的反斜杠在 JSON 里是转义符，D:\data会被解析成非法转义，统一写成正斜杠最省事。二是结尾逗号，JSON 不允许数组或对象的最后一项带逗号，手改配置时最容易在这里出错，报错信息还只给个行号。
多分支输出靠tag和inputs两个字段配合。给某个 stage 起个名字，后面的 stage 用inputs指回它，就形成了分叉：
{ "pipeline": [ { "type": "readers.las", "filename": "D:/data/site_a.las" }, { "type": "filters.smrf", "tag": "ground_filter" }, { "type": "filters.range", "limits": "Classification[2:2]", "inputs": ["ground_filter"], "tag": "ground_only" }, { "type": "writers.las", "filename": "D:/data/ground.laz", "inputs": ["ground_only"] }, { "type": "filters.range", "limits": "Classification![2:2]", "inputs": ["ground_filter"], "tag": "non_ground" }, { "type": "writers.las", "filename": "D:/data/non_ground.laz", "inputs": ["non_ground"] } ] }还有一个--stream开关，加上之后数据按块流式处理，内存占用从"整个文件"降到"一个块"，大文件必备。但它有硬性前提：管线里每个 stage 都必须支持流式。像需要全局视野的形态学滤波、六边形密度统计这类 stage 在流式模式下会直接报"non-streamable stage"，这时候要么去掉--stream，要么把它拆成两条管线跑。
4. 点云预处理四件事：去噪、抽稀、地面滤波、重投影
4.1 去噪：统计离群和半径离群不是一回事
filters.statisticaloutlier判断依据是"每个点到它 K 个最近邻的平均距离"，超过全局均值加若干倍标准差的点被判定为噪声。mean_k是邻居数，默认 8；multiplier是标准差倍数，默认 2.0。
{ "type": "filters.statisticaloutlier", "mean_k": 10, "multiplier": 2.5 }参数怎么定，看数据密度和场景。地面站扫描的街区数据，点间距一两厘米，mean_k给 10 到 12 比较稳；multiplier我一般从 2.5 起，植被多的地方必须往上调，因为树叶点本来就稀疏、离群特征明显，倍数给低了整片树冠会被当成噪声削掉，这种"洗得太干净"的翻车在现场很难解释。反过来，如果是无人机航测数据，点密度低、分布均匀，multiplier给 2.0 到 2.5 就够。
filters.radiusoutlier的逻辑不同：在给定半径内邻居数少于阈值就删。参数是min_neighbors和radius，单位跟随坐标系。它更适合"孤立飞点"这种明确的场景，比如玻璃反射造成的几个悬浮点。两者可以串联，但顺序有讲究——先半径法删掉明显的孤立点，再统计法处理粘连在主体附近的毛刺，反过来做的话半径法的邻居统计会被毛刺干扰。
4.2 抽稀：体素法和泊松采样选错了会白干
filters.voxelcenternearestneighbor把空间切成固定边长的体素，每个体素输出离中心最近的那个原始点，坐标不做平均、不产生新点。cell单位是米：
{ "type": "filters.voxelcenternearestneighbor", "cell": 0.05 }0.05 就是 5 厘米体素。这个方法的好处是输出点数可控，5 厘米体素大致对应每平方米 400 点的密度，做固定密度交付时特别好算。缺点是点云看起来会有轻微的格网感，细部特征会被抹掉一点。
filters.sample用的是泊松盘采样，参数是radius，保证任意两个保留点之间的距离不小于这个值。它的分布更自然，适合做展示和预览，但输出点数不固定，跟点云的实际分布有关，做交付规格时不好承诺。
还有一种最粗暴的filters.decimation，step设成 10 就是每 10 个点留 1 个。速度最快，但扫描仪的采集顺序往往带螺旋或线扫规律，按索引抽样会在点云上留下明显的条纹，视觉审查那关过不去，我只在纯粹为了快速预览时用它。
4.3 地面滤波：SMRF 的四个参数按坡度调，别抄默认值
filters.smrf是 PDAL 里效果比较可靠的地面滤波，四个核心参数：slope（坡度阈值）、window（窗口尺寸，单位米）、threshold（高程阈值）、scalar（阈值缩放系数）。默认值大概是 slope 0.2、window 16、threshold 0.45、scalar 1.25。
{ "type": "filters.smrf", "slope": 0.3, "window": 20, "threshold": 0.5, "scalar": 1.2, "returns": "last" }调参思路：window必须大于场景里最大建筑物的跨度，否则大屋顶会被当成地形的一部分"填平"；slope反映地形起伏，平缓城区给 0.1 到 0.2，丘陵或山地要上到 0.3 甚至更高；threshold控制的是点到拟合面的允许高差，噪声大的数据适当放宽。returns设成last表示只用末次回波参与计算，植被区能少受冠层干扰。
滤波完输出里分类码 2 代表地面。接下来要么用filters.range的Classification[2:2]把地面单独写出来，要么用Classification![2:2]剔除地面得到地物点。注意 SMRF 只改分类码，不改其他维度，所以原始的分类信息会被覆盖，如果上游数据带了人工分类，先另存一份再跑。
地形简单、只想快速拿到结果的场景，filters.pmf（渐进形态学滤波）更快，参数是max_windown_size、slope、initial_distance、max_distance，调参比 SMRF 少，但对陡坎和挡土墙的处理明显粗糙一些。我的习惯是先用 pmf 出一版看整体趋势，确认数据没问题再换 smrf 出正式成果。
4.4 重投影：顺序错了，滤波参数全部作废
这一条是真正需要记在备忘卡上的经验：所有跟距离相关的滤波，必须在投影坐标系下做，而且要在它们之前完成重投影。
原因很直白。filters.smrf的window写的是 16，单位是米；如果数据是经纬度坐标，16 的含义就变成了 16 度，覆盖范围接近两千公里，滤波结果会变成一片平地。同理，voxelcenternearestneighbor的cell: 0.05在经纬度下等于 5 公里，抽稀完只剩几个点，你还以为是数据坏了。
{ "type": "filters.reprojection", "in_srs": "EPSG:4326", "out_srs": "EPSG:32650" }in_srs可以省略，PDAL 会从 LAS 头部的坐标系 VLR 里读；但很多数据在导出时坐标系信息丢了或者是空的，这时候必须显式给in_srs，否则会报输入坐标系未设置的错误。out_srs按项目要求填，国内的市政项目常见的是各类高斯克吕格投影带，用 EPSG 代码或者带参数的 proj 字符串都行，proj.db里查得到的都能用。
把四件事串成一条完整管线，顺序应该是：读入 → 重投影（如果源不是投影坐标）→ 去噪 → 地面滤波 → 分支输出地面与地物 → 需要的话再抽稀。
{ "pipeline": [ { "type": "readers.las", "filename": "D:/data/site_a.las" }, { "type": "filters.reprojection", "out_srs": "EPSG:32650" }, { "type": "filters.radiusoutlier", "radius": 0.3, "min_neighbors": 3 }, { "type": "filters.statisticaloutlier", "mean_k": 10, "multiplier": 2.5 }, { "type": "filters.smrf", "slope": 0.3, "window": 20, "threshold": 0.5, "scalar": 1.2, "returns": "last", "tag": "gf" }, { "type": "filters.range", "limits": "Classification[2:2]", "inputs": ["gf"], "tag": "gnd" }, { "type": "filters.voxelcenternearestneighbor", "cell": 0.05, "inputs": ["gnd"], "tag": "gnd_thin" }, { "type": "writers.las", "filename": "D:/data/ground.laz", "compression": "lazperf", "inputs": ["gnd_thin"] }, { "type": "writers.las", "filename": "D:/data/nonground.laz", "compression": "lazperf", "inputs": ["gf"] } ] }这条管线跑完，ground.laz是 5 厘米抽稀后的地面点，nonground.laz保留全部非地面点。注意最后那个writers.las的inputs指向的是gf而不是某个 range 的结果，所以地物点里仍然含着地面点，这不是 bug——SMRF 只是打了分类码，要纯净的地物需要再加一个排除 2 的 range。写管线时把 inputs 的指向和分类码的关系想清楚，能避免交付后发现两套数据对不上。
5. 避坑排查：五条从报错现场拆出来的记录
5.1 现象：pdal.exe 在 PowerShell 里一闪而过或提示缺少 DLL
原因：不在 OSGeo4W Shell 里运行，GDAL_DATA、PROJ_DATA这些数据路径变量为空。缺的通常不是 DLL 本身，而是proj.db这类数据文件定位不到，PDAL 在解析坐标系时失败。
解决：从开始菜单进 OSGeo4W Shell 再执行；要在自己的脚本里用，就在开头call C:\OSGeo4W\bin\o4w_env.bat，并且记住必须用call，直接执行不会把变量留在当前窗口。
5.2 现象：报 proj.db 相关错误，或者重投影时提示无法创建坐标转换
原因：PROJ 的数据目录变量名在不同版本里不一致，新版 PROJ 用PROJ_DATA，老版用PROJ_LIB；如果手工设置过其中一个，升级后会失配。另一种情况是安装时依赖包漏了，share\proj目录是空的。
解决：先echo %PROJ_DATA%和echo %PROJ_LIB%看两个变量指向哪里，再去对应目录确认proj.db文件存在。目录空的就重跑安装器补 proj 包。临时应急可以直接在 cmd 里set PROJ_DATA=C:\OSGeo4W\share\proj，但这只对当前窗口有效。
5.3 现象：写 LAZ 时报 compression 选项非法，或输出文件大小和 LAS 差不多
原因：writers.las的compression只在编译时链接了 lazperf 或 laszip 才可用，某些构建版本里两个都不支持；另一种情况是值写成了true，那是旧版语法，新版会直接拒绝。
解决：用pdal --drivers确认writers.las存在，再用pdal translate --options writers.las看压缩相关的选项列表。列表为空就说明这套构建不支持压缩，只能输出去掉compression的 LAS，或者换一个带压缩支持的安装源。值只在lazperf和laszip里选，输出文件名带.laz但没设compression时，PDAL 不会自动压缩。
5.4 现象：CloudCompare 加载 PDAL 插件后启动崩溃，或者格式下拉框里压根没有 PDAL
原因：CloudCompare 的 PDAL 插件是动态链接 PDAL 运行库的，插件编译时对应的 PDAL 版本和你用 OSGeo4W 装上的版本不一致，加载时符号解析失败就崩。另一个原因是把C:\OSGeo4W\bin加进了系统 PATH，CloudCompare 优先加载到了 OSGeo4W 那一套 GDAL/PROJ，和自己带的版本冲突。
解决：把 OSGeo4W 的 bin 从系统 PATH 里移除，只在需要时用 Shell 临时生效；插件版本对不上就升级 CloudCompare 到与 PDAL 主版本匹配的发行版，或者干脆不用插件，把 PDAL 输出的标准 LAS/LAZ 直接拖进 CloudCompare——这条路最稳，因为 LAS 是两边都原生支持的格式。
5.5 现象：读取时报文件打不开，或者读进来了但点数比预期少一截
原因：路径里有中文或特殊字符，某些 GDAL 驱动在 Windows 下的宽字符处理不完整；另一种情况是数据本身带多个回波，PDAL 默认读全部回波，但如果上游导出时只写了首次回波，点数自然少。
解决：工作目录和文件名尽量用纯英文和数字，路径深度也别太深。点数核对用pdal info --summary看num_points，和源文件在 CloudCompare 里显示的点数比对，差得多的再查--metadata里的回波信息。
6. 交付前的双向核对：pdal info 与 CloudCompare 对拍
流程跑通之后，最后一步不是打包发走，而是拿另一套工具验证一遍。PDAL 和 CloudCompare 读 LAS 的实现路径不一样，前者走 GDAL 的 LAS 驱动，后者走自己的 LAS 插件，两边都能打开、点数一致、包围盒吻合，才算这份数据是真的没问题。
我一般做三项核对，用一个简单的表来记：
| 核对项 | PDAL 侧命令 | CloudCompare 侧看哪里 | 容差 |
|---|---|---|---|
| 点数 | pdal info --summary的 num_points | 属性面板里的点数量 | 必须完全相等 |
| 包围盒 | summary 的 bounds min/max | 属性面板的 bounding box | 允许 1e-3 量级差异 |
| 坐标系 | summary 的 srs 字段 | 属性里的 coordinates system | EPSG 代码须一致 |
| 分类码 | pdal info --stats --dimensions Classification | 标量字段列表里的 Classification | 类别集合一致 |
表格之外还有一个更省事的快速检查方式：用 CloudCompare 的命令行模式静默加载一遍，能正常退出就说明文件结构没有硬伤。命令行参数在不同版本之间有出入，用-HELP核对一下再写进脚本：
REM 静默加载 PDAL 输出的 LAZ，再另存为 LAS；打不开就什么都不会生成 "C:\Program Files\CloudCompare\CloudCompare.exe" -SILENT -AUTO_SAVE OFF ^ -O D:\data\ground.laz -C_EXPORT_FMT LAS -SAVE_CLOUDS这条命令的价值在于它是无人值守的。批量跑几十份数据时，用 for 循环套一层，跑完检查输出目录里有没有对应的 LAS 文件，有就是通过，没有就是那份数据有问题。比一份份点开看快一个数量级，也比单纯相信 PDAL 自己没报错要可靠。
真正让我养成这个习惯的，是一次交付。当时 PDAL 那边跑得干干净净，日志里一条警告都没有，结果对方在 CloudCompare 里打开发现整体位置偏了三百多公里——源数据头部带了一个错误的坐标系定义，PDAL 老老实实按它做了重投影，全程合法。从那以后我每次出成果前都强制走一遍双向核对，重点看包围盒的数值量级而不是只看有没有报错。希望帮到你。
本文还有配套的精品资源，点击获取
