Oracle Spatial GIS数据组织与查询：从SDO_GEOMETRY到空间索引实战

简介：基于Oracle Spatial的GIS数据组织及查询是一份面向GIS开发者与数据库管理员的技术文献，聚焦空间数据和属性数据的一体化存储与查询难题。内容系统阐述Oracle Spatial扩展模块的架构，采用对象-关系模型统一组织GIS数据，并对比数据导入方式后选用EasyLoader完成批量加载，随后通过四元树索引构建高效空间索引，最后以Java结合JDBC实现空间查询。资源为单篇PDF文档，大小243KB，共1个文件，内容紧凑，便于直接阅读与收藏。目前已有97人学习下载，适合需要了解在Oracle环境中管理地理空间信息、为WebGIS应用集成空间查询能力的读者参考，可据此快速掌握从数据建模、导入到索引与查询的完整技术路径。

1. 一个PDF标题背后：Oracle Spatial的GIS数据组织与查询不是把坐标塞进表里

“基于Oracle Spatial的GIS数据组织及查询”这个标题，第一眼很像一份普通文档，但它实际指向的问题很具体：手上有大批点、线、面数据，要么来自Shapefile，要么来自GeoJSON或CAD导出，要装进Oracle，并让业务系统能按“某个点附近有哪些设施”“某条管线是否穿过这个地块”这类空间关系做查询。真正做过这类库的人都会同意：建表、插坐标、建索引只是开始；数据组织规则没定好，空间查询就会变成黑匣子，执行计划偶尔走索引、偶尔全表扫，改一个SRID参数结果就完全对不上。这篇笔记打算顺着生产落地的顺序讲：先把SDO_GEOMETRY和元数据怎么组织讲清楚，再给空间算子和SQL的组合写法，中间补上坐标系清洗与Python查询空间数据的操作，最后收敛到常见的翻车现象和验证方法，希望对正在搭建空间数据中台或维护Oracle空间库的开发者有帮助。

2. 数据组织：SDO_GEOMETRY、元数据和空间索引怎么才能不翻车

2.1 一张业务表装一个图层：SDO_GEOMETRY的点线面组织方式

Oracle Spatial里最核心的类型是SDO_GEOMETRY，它是一个对象类型，但很多人第一次直接看它的构造参数时会犯晕。一个完整几何对象通常由四段信息组成：几何类型GTYPE、坐标系SRID、SDO_POINT、SDO_ELEM_INFO和SDO_ORDINATES。GTYPE用四位数表达，第一位是维度，后三位是几何类型。举例来说，2001代表二维点，2002代表二维线，2003代表二维面；如果看到3001就是三维点。SRID是空间参考ID，例如4326代表WGS84经纬度，3857代表Web墨卡托投影。这个SRID必须和数据本身的真实坐标系统一，否则后期查询结果就是“看起来没错，落地全偏”。

用SQL创建一个点图层，通常这样写：

CREATE TABLE roadside_trees ( tree_id NUMBER PRIMARY KEY, tree_no VARCHAR2(32), tree_name VARCHAR2(64), geom SDO_GEOMETRY ); INSERT INTO roadside_trees (tree_id, tree_no, tree_name, geom) VALUES ( 1, 'T20240001', '国槐', SDO_GEOMETRY( 2001, 4326, SDO_POINT_TYPE(121.47, 31.23, NULL), NULL, NULL ) );

这里SDO_GEOMETRY的第一个参数2001说明是一个二维点；第二个参数4326是WGS84经纬度；第三段用SDO_POINT_TYPE直接给坐标；后两段传NULL。如果是线，比如一段路网，写法就换成坐标数组：

CREATE TABLE road_centrelines ( road_id NUMBER PRIMARY KEY, road_name VARCHAR2(100), geom SDO_GEOMETRY ); INSERT INTO road_centrelines (road_id, road_name, geom) VALUES ( 101, '中山路', SDO_GEOMETRY( 2002, 4326, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(121.00, 31.00, 121.10, 31.05, 121.20, 31.10) ) );

SDO_ELEM_INFO_ARRAY里的三个数字分别表示：坐标数组起始位置从1开始、元素类型为2即直线段、只有一个元素段。面则用2003，元素类型1003表示外环，如果是洞则是2003或者用2003作为内环类型。一个面数据的最小示例是：

INSERT INTO land_parcels (parcel_id, parcel_no, geom) VALUES ( 1, 'P001', SDO_GEOMETRY( 2003, 4326, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY( 121.0, 31.0, 121.1, 31.0, 121.1, 31.1, 121.0, 31.1, 121.0, 31.0 ) ) );

面数据最后一个坐标点必须回到第一个坐标点，形成闭合环。我在实际项目中一般要求每个图层单独建表，也就是“一张业务表装一个图层”，原因很简单：空间索引是按单列建的，混合点线面会让索引效果变得很差，查询时还要不断用GTYPE过滤数据。如果确实有多类型数据，至少要加一个geometry_type字段，并把同一类型的几何放在同一表里，避免一张大表中堆满各种几何。

2.2 USER_SDO_GEOM_METADATA注册与空间索引：顺序和参数决定查询下限

建好表、插入几何不等于Oracle会把它当成空间数据。大多数入门踩坑都出在这：表里有几何，却忘了往USER_SDO_GEOM_METADATA注册元数据，空间索引根本建不上。元数据表的作用是告诉Oracle“某张表的某个列是空间列，它的维度范围是多少，SRID是什么”。这一步必须在创建空间索引之前完成。

常见做法是这三步按顺序执行：

INSERT INTO user_sdo_geom_metadata ( table_name, column_name, diminfo, srid ) VALUES ( 'ROADSIDE_TREES', 'GEOM', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('LON', -180, 180, 0.000000001), SDO_DIM_ELEMENT('LAT', -90, 90, 0.000000001) ), 4326 ); CREATE INDEX roadside_trees_sidx ON roadside_trees(geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX;

先解释一下SDO_DIM_ARRAY。它至少包含两个SDO_DIM_ELEMENT，第一个描述经度轴，第二个描述纬度轴，每项的四个参数分别是轴名称、最小值、最大值、容差。容差不是“坐标精度”，而是Oracle做空间计算时判断两个点是否重合的临界值。经纬度数据我习惯给0.000000001，约等于毫米级；投影坐标数据则根据业务精度给0.001米或0.01米。维度数组和坐标必须一致，如果几何是三位的，这里就要给三个SDO_DIM_ELEMENT。

再解释元数据中的SRID。元数据表里的SRID和每个SDO_GEOMETRY里带的SRID必须一致。比如几何对象里写4326，元数据里也必须是4326。如果某个表已经存在历史数据，里面有些几何的SRID填错了，最好先用查询把不一致的行筛出来再统一变更，不要直接建索引，否则会出现ORA-29855或者索引建立后查询结果不稳定的问题。

空间索引创建后，可以用下面这句确认索引存在：

SELECT index_name, index_type FROM user_indexes WHERE table_name = 'ROADSIDE_TREES';

索引类型应该是DOMAIN。只有DOMAIN索引的列才能被SDO_RELATE、SDO_ANYINTERACT、SDO_NN这些空间算子有效利用。如果发现索引类型不对，基本可以判断数据组织阶段出了问题：要么没注册元数据，要么维度信息写得和实际数据不匹配。

3. 查询：从空间算子到SQL写法的组合拳

3.1 四个高频空间算子：ANYINTERACT、INSIDE、WITHIN_DISTANCE与NN

空间查询和普通SQL最大的不同在于，WHERE条件里通常不能写WHERE geom = xxx，而是调用空间算子。Oracle Spatial最常用的四个算子是SDO_ANYINTERACT、SDO_RELATE、SDO_WITHIN_DISTANCE和SDO_NN。SDO_ANYINTERACT用来判断两个几何是否“有任意接触”，它掩盖了具体关系，是最通用的相交判断，优点是快。SDO_RELATE则通过mask参数细分关系，比如mask=INSIDE表示完全在内部，mask=COVEREDBY表示被覆盖，mask=TOUCH表示边界相接。

下面是一个典型的业务查询：给定一个多边形范围，查出所有与其相交的地块，并把地块编号字段带出来。

SELECT p.parcel_no, p.area FROM land_parcels p WHERE SDO_ANYINTERACT( p.geom, SDO_GEOMETRY( 2003, 4326, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY( 121.05, 31.02, 121.08, 31.02, 121.08, 31.05, 121.05, 31.05, 121.05, 31.02 ) ) ) = 'TRUE';

这里的第二个参数是一个临时构造的窗口多边形。把窗口几何写成常量而不是另一张表的字段，优化器更容易选择空间索引。如果要判断“完全落入某个行政区”，写法换成SDO_RELATE：

SELECT b.building_no FROM buildings b, districts d WHERE SDO_RELATE(b.geom, d.geom, 'mask=INSIDE') = 'TRUE' AND d.name = '人民公园片区';

SDO_RELATE返回的是字符串'TRUE'，不是数字1，经常看到有人写成= 1，这样不仅结果错，还会影响优化器判断。这一点算是频率仅次于SRID问题的踩坑点。

SDO_WITHIN_DISTANCE用于做缓冲区类查询，例如查路边树周围100米内有哪些公交站。参数distance和unit要一起写，unit=m表示米；如果坐标系是4326，Oracle会按地球曲率换算成米。代码可以写成：

SELECT s.stop_name FROM bus_stops s WHERE SDO_WITHIN_DISTANCE( s.geom, SDO_GEOMETRY( 2001, 4326, SDO_POINT_TYPE(121.47, 31.23, NULL), NULL, NULL ), 'distance=100 unit=m' ) = 'TRUE';

SDO_NN用来找最近邻。它本身分词法和谓词两种用法，谓词写法是：

SELECT stop_name, distance FROM ( SELECT stop_name, SDO_NN_DISTANCE(1) AS distance FROM bus_stops WHERE SDO_NN( geom, SDO_GEOMETRY( 2001, 4326, SDO_POINT_TYPE(121.47, 31.23, NULL), NULL, NULL ), 'sdo_num_res=5 unit=m', 1 ) = 'TRUE' ) ORDER BY distance;

注意SDO_NN_DISTANCE(1)里的1要和SDO_NN参数的最后一个1对应，它表示第几个距离值。sdo_num_res=5限制返回最近5条。若两个点在投影坐标系里，单位参数可以不写，因为坐标单位就是米；但4326下尽量显式写unit=m，否则返回的距离单位是度，数值含义不直观。常用空间算子的关系可以按这张表选型：

3.2 Python连接Oracle查询空间数据：绑定SRID并按距离过滤

业务系统很少直接暴露PL/SQL给前端，通常做法是Python提供接口，从Oracle查空间结果后转成GeoJSON给Web端。标准做法是用oracledb库，这是cx_Oracle的新版本，安装后连接和查询都保持类似习惯。一个最小查询示例：

import oracledb conn = oracledb.connect( user="gis_app", password="change_me", dsn="127.0.0.1:1521/orclpdb1" ) cur = conn.cursor() cur.execute(""" SELECT stop_id, stop_name, SDO_UTIL.TO_GEOJSON(geom) AS geojson FROM bus_stops WHERE SDO_WITHIN_DISTANCE( geom, SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(:lon, :lat, NULL), NULL, NULL), 'distance=1000 unit=m') = 'TRUE' """, {"lon": 121.47, "lat": 31.23}) for stop_id, stop_name, geojson in cur: print(stop_id, stop_name, geojson.read()) cur.close() conn.close()

这段代码有两个值得说明的地方。第一，参数用命名绑定变量传入坐标，不要通过字符串拼接把用户输入的经纬度拼进SQL，否则既可能注入，又会导致每次坐标变化都让Oracle重新硬解析SQL。第二，SDO_UTIL.TO_GEOJSON返回的是CLOB类型，Python拿到的上一个对象是LOB，必须调用.read()才能得到完整的GeoJSON字符串；如果直接打印，很可能只看到<oracledb.LOB object at ...>这样的东西。

Oracle连接池在空间查询场景下也需要稍微注意。每次都要新建连接的话，第一次建立连接的开销可能比查询本身还大，接口并发一上来就会变慢。常见做法是把oracledb的ConnectionPool创建一次，循环复用连接：

pool = oracledb.create_pool( user="gis_app", password="change_me", dsn="127.0.0.1:1521/orclpdb1", min=2, max=10, increment=1 ) with pool.acquire() as conn: with conn.cursor() as cur: cur.execute("SELECT count(*) FROM bus_stops") print(cur.fetchone()[0])

空间查询返回的数据量通常比普通查询大，特别是面图层转GeoJSON时，一个百万级多边形的结果集可能几十MB。接口层最好限制返回条数，或者先用SDO_GEOM.SDO_SIMPLIFY做抽稀，避免应用服务器和数据库带宽同时被打满。

3.3 空间连接：SDO_JOIN和嵌套循环怎么选

两张表都有空间索引，并且业务需求是“把所有相交对输出出来”，比如每个保护地块和每个建筑物做叠加统计，这属于空间连接。初学的时候最容易写成两表嵌套循环：

SELECT /*+ ordered */ p.parcel_no, b.building_no FROM land_parcels p, buildings b WHERE SDO_ANYINTERACT(p.geom, b.geom) = 'TRUE';

小数据量这样没问题；数据量大以后，计算量会变成两表几何互相检查的笛卡尔积，即使每个判断都走索引，代价也很高。Oracle Spatial从10g开始提供SDO_JOIN算子，表示要求优化器用空间连接方式计算：

SELECT p.parcel_no, b.building_no FROM land_parcels p, buildings b WHERE SDO_JOIN(p.geom, b.geom, 'mask=ANYINTERACT') = 'TRUE';

使用SDO_JOIN的前提是两列的元数据和空间索引都齐全。Oracle的SDO_JOIN内部会先对两个图层做索引匹配，生成候选对，再逐对验证实际相交，这样能把大量明显不相干的几何对提前过滤掉。我在实际操作中会先用小数据量对比一下两种写法的执行时间，因为优化器并不总是选择SDO_JOIN，有时嵌套循环反而更快。判断标准就是看执行计划里有没有出现SPATIAL_JOIN或者JOIN关键字配合DOMAIN INDEX访问路径。如果表很小，比如几百条记录，嵌套循环足够；一旦任何一张表超过几十万几何，优先尝试SDO_JOIN。

4. 坐标与格式：SRID判重、文本型坐标和字段清洗

4.1 SRID：为什么4326和3857不能在同一张表里混放

做GIS数据组织时，坐标系往往是最先翻车的环节。4326是WGS84经纬度坐标系，坐标单位是度；3857是Web墨卡托投影，坐标单位是米。把3857的坐标当成4326存进去，空间查询不会立刻报错，但距离、面积全部是错的，叠加到在线地图上会明显偏移。判断一个图层用什么SRID，不要只看元数据表，最好抽查几个几何的坐标值范围：4326的经纬度落在正负180和正负90之间；3857坐标的绝对值理论上不超过两千万。

如果要统一坐标系，常见做法是新增一个SRID列或一张转换后的表，而不是直接UPDATE原几何列。转换几何可以用SDO_CS.TRANSFORM，最简单的写法是：

SELECT road_id, SDO_CS.TRANSFORM(geom, 3857) AS geom_web FROM road_centrelines;

这句会把原4326几何动态转成3857，但不会修改原表。如果确认转换结果正确，再考虑用如下方式落到新列：

ALTER TABLE road_centrelines ADD (geom_web SDO_GEOMETRY); UPDATE road_centrelines SET geom_web = SDO_CS.TRANSFORM(geom, 3857) WHERE geom IS NOT NULL; INSERT INTO user_sdo_geom_metadata ( table_name, column_name, diminfo, srid ) VALUES ( 'ROAD_CENTRELINES', 'GEOM_WEB', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('X', -20037508.34, 20037508.34, 0.001), SDO_DIM_ELEMENT('Y', -20037508.34, 20037508.34, 0.001) ), 3857 ); CREATE INDEX road_centrelines_web_sidx ON road_centrelines(geom_web) INDEXTYPE IS MDSYS.SPATIAL_INDEX;

这里有个细节：元数据表里SDO_DIM_ELEMENT的最小值和最大值要跟坐标系相匹配。3857的维度范围用官方Web墨卡托边界即可，容差可以给0.001米。有人为了省事把维度范围写成-10000000, 10000000，如果数据超出这个范围，Oracle的索引构建会提示数据与维度不匹配。相类似，4326的维度范围也不要写成-180, 0, -90, 0，只覆盖半个地球会让超出范围的几何被判定为无效。

4.2 从Shapefile/GeoJSON进库：文本型坐标与GIS字段的清洗步骤

从外部数据进入Oracle Spatial，真正的硬骨头不是几何本身，而是属性字段。Shapefile的字段类型和Oracle并不是一一对应，FeatureClass里的字符串编号在Oracle里经常被截断或变成文本型数字。一个GIS里写着"00123"的用地编号，如果导成Oracle的NUMBER列，前面的0会丢；如果导成VARCHAR2，又要防止长度不足。常用做法是先建立一张“原始表”，把外部数据的字段全部按VARCHAR2接收进去，再写SQL做第二遍清洗。文本型坐标也是同样的逻辑：很多CAD导出的文本里坐标以字符串存在，形如121°47'30"，直接塞进SDO_GEOMETRY是不行的。清洗分三步：先去掉度分秒符号，再TO_NUMBER，最后拼成SDO_ORDINATE_ARRAY。

举例，一张临时表里有两个文本字段lon_txt和lat_txt，清洗步骤可以写成：

UPDATE cad_points SET lon = TO_NUMBER( REPLACE(REPLACE(REPLACE(lon_txt, '°', '.'), '''', ''), '"', '') ), lat = TO_NUMBER( REPLACE(REPLACE(REPLACE(lat_txt, '°', '.'), '''', ''), '"', '') );

度分秒转十进制的逻辑实际上还要除以60和3600，这里直接用REPLACE替换并不严谨，真实业务里我会先判断字段里是否包含特殊符号，再按常规公式转换，否则会把“121度30分”误转成“121.30”。正确公式是度加分除以60加秒除以3600。与其在SQL里硬写，不如在GIS工具的字段计算器里先转换好，这也是很多GIS教程里的常规方案，批量操作比逐个改快得多。

GeoJSON进库更直接。较新版本的Oracle支持SDO_UTIL.FROM_GEOJSON，把GeoJSON文本加SRID转成SDO_GEOMETRY，写起来是一句SQL：

SELECT SDO_UTIL.FROM_GEOJSON(:gj, 4326) AS geom FROM DUAL;

旧版本则常见做法是先转成WKT，再使用SDO_GEOMETRY(WKT格式, SRID)构造几何。值得一提的坑是：SDO_UTIL.FROM_GEOJSON只接受标准GeoJSON几何格式，如果输入的是FeatureCollection，需要先取出geometry数组再入库，直接塞整段FeatureCollection会报错。另外，入库前先跑一遍几何验证，因为GeoJSON里的Polygon规则和Oracle的环方向规则不完全一致，常有自相交问题在入库后才爆发。

5. 避坑：Oracle Spatial日常最容易翻车的4个细节

5.1 现象：表有坐标也有索引，空间查询仍走全表扫描

执行计划里看到TABLE ACCESS FULL，空间索引好像完全没被使用。我一开始也以为SQL写错，后来查USER_SDO_GEOM_METADATA才发现，表名大小写不对。Oracle的数据字典对表名存储默认是大写，元数据插入时如果写错了大小写，比如表名写成'roadside_trees'全小写而实际表名是'ROADSIDE_TREES'，索引建立时不报错，因为Oracle会做大小写转换，但查询优化器无法把空间算子和正确元数据关联。另一个常见原因是WHERE子句里对空间列做了函数包装，比如把SDO_UTIL.TO_GEOJSON(geom)用在SDO_NN里，这会让索引失效。解决办法是：先确认USER_SDO_GEOM_METADATA里记录的TABLE_NAME和COLUMN_NAME与真实表、列一致，再检查SQL里有没有对几何列套函数；必须保持SDO_xxx(列, 参数)这个形态，列单独裸露才能走域索引。

5.2 现象：同一个点在两张表里，叠加分析结果对不上

两个图层分别单独查都正常，放到同一SQL里做SDO_JOIN，匹配数量明显偏少，或者有的点在A表统计后落在了错误区域。原因十有八九是两张表用了不同SRID，却都标注成4326。比如一张表的数据是从地方平面坐标系转换来的，另一张直接用的WGS84经纬度，数值范围相近，肉眼分不出来。解决办法是先做一个“坐标值范围检查”：把两张表的坐标最大值、最小值分别查出来，看是否落在经纬度合理范围。再进一步，用SDO_CS.TRANSFORM把其中一张表动态转换到另一张的SRID再做叠加。我一般不会直接UPDATE原表，而是先建立一张视图或临时表验证结果，确认后重建空间索引，避免把原始数据改坏又没有后悔药。

5.3 现象：面边界明明在屏幕上看着正常，验证却报ORA-13349

ORA-13349通常指多边形边界自相交。屏幕显示正常不代表几何合法，因为很多GIS软件会自动把可见图形“拧正”，Oracle Spatial内部严格要求环不能自交、顶点顺序不能乱。出现这个问题最常见的原因是两个相邻多边形共享一条边界，但两边顶点顺序不一致，导入Oracle时被当成互相穿越。解决办法是先定位问题记录：调用SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT逐行验证，返回'TRUE'表示合法，返回错误码则说明几何有问题。定位后可以用SDO_GEOM.SDO_SELF_INTERSECT找出自交位置，也可以回到源GIS工具里对图层执行修复，清理重复点和自相交边界，再重新导出。注意容差参数不能给过大，给0.01米可能把一些细微拐角当成无效，但给太小又会把本来合法的边界误判成自交。

5.4 现象：INSERT成功，CREATE INDEX却报ORA-29855

ORA-29855是创建空间索引时的通用错误，后面的具体信息往往指向MDSYS.SPATIAL_INDEX状态不是VALID。遇到这个错，先不要怀疑Oracle坏了，绝大多数是几何数据有脏数据。INSERT成功是因为SDO_GEOMETRY对象能写进表里，不等于几何满足空间索引的合法性要求。处理步骤是：确认元数据存在，再对整表做一次图层级验证，例如将数据按照图层验证的SQL集合输出所有无效行；这些无效行排除后再建索引。如果脏数据太多，优先修源数据，而不是数据库放宽容差。空间索引不是清洗工具，它会把几何问题原样暴露出来。

6. 验证技巧：用EXPLAIN PLAN给空间索引“验真身”

空间索引建好，不代表每次查询都能命中。我每次写完一条新的空间查询SQL，会先用EXPLAIN PLAN验证一段，再用一小批真实数据跑结果，两件事都通过才敢把SQL交给业务接口。验证执行计划的方法很简单：

EXPLAIN PLAN FOR SELECT stop_name FROM bus_stops WHERE SDO_WITHIN_DISTANCE( geom, SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(121.47, 31.23, NULL), NULL, NULL), 'distance=100 unit=m' ) = 'TRUE'; SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY);

输出里如果出现DOMAIN INDEX或SDO_...关键字对应的索引访问步骤，说明空间索引生效；如果只见TABLE ACCESS FULL，就需要按第5章提到的问题逐个排查。第二个验证方式是构造最小数据集：手工插入两三个已知距离的点，分别用SDO_NN和SDO_WITHIN_DISTANCE查，核对返回的距离和坐标是否与预期一致。很多看起来像“缓冲区偏移”的问题，实际不是算法问题，而是坐标系或单位参数写错，这个小实验能在三分钟内暴露出来。

我在数据加载和修改SRID之后，还会养成一个固定习惯：查看USER_SDO_GEOM_METADATA里登记的SRID和维度范围，再抽查几行真实坐标，确认它们相匹配。这个习惯帮我避开了好几次“表里全是3857坐标但SRID标成4326”的隐藏问题。空间数据组织没有太多玄学，大部分坑都集中在元数据、SRID和几何合法性这三件事上，把它们在前期定死，后续查询和业务开发基本可以稳定推进。希望这些步骤和踩坑记录，能帮你在做Oracle Spatial的GIS数据组织时少走几段弯路。

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