GIS二次开发的实验课里，矢量文件创建与编辑这一章，看着就是个赶工就能过关的“小实验”，实际上卡人的地方都在后面。我见过很多同学在实验三用鼠标在界面上点几个点、画几条线就算交差，等到实验四做空间查询、实验五做缓冲区分析的时候，数据要么坐标对不上，要么属性字段读不出来，后面全乱了。这个实验真正要解决的不是“怎么在屏幕上画图形”，而是搞清楚一个矢量文件从无到有、从写死到可编辑的完整链路：点、线、面要素怎么在程序里表示，属性表和几何对象怎么绑定，坐标系和文件格式怎么配合，以及最重要的——程序怎么把这一整套东西正确落盘，还能安全地改回来。
这篇内容适合正在做GIS二次开发实验的学生、想补数据操作底子的开发者，甚至带实验课的助教，都可以把这篇当作一次完整的实验复盘。下面我会从数据设计、环境准备、创建实现、编辑实现到问题排查一路讲下去，代码都能直接跑，思路也适用于其他GIS开发环境。
1. 先把思路捋清楚：矢量创建与编辑到底在解决什么问题
1.1 从一个图层拆开看
矢量数据这个概念，在GIS里说直白点就是“坐标序列 + 一张属性表”。一个点图层，每个要素对应一组坐标和一行描述信息；一个面图层，每个要素对应一组闭合的坐标序列以及面积、名称等字段。很多人写代码之前没意识到这一点，把“画图”当成纯图形操作，结果做出来的东西只是个图形文件，不是地理数据。
我特别强调一个词：绑定。在矢量文件里，几何和属性是分开存储的，比如Shapefile就是shp、shx、dbf三个文件配合工作，但读取时必须作为一个整体出现。程序创建要素时要分别设置几何对象和字段值，再把这个“整体”写入到图层里。这是理解后面所有代码的关键，也是实验三最大的认知门槛。
在二次开发场景里，创建与编辑又比手动操作多了一层要求：程序必须可重复、可批量、可回滚。比如1000个基站坐标要从表格里批量入库生成shp，手动画不现实，必须写代码循环创建。这也是实验三放在课程前期的原因：后续所有分析功能都要依赖一份结构正确的矢量数据，这一步错了，后面全是空中楼阁。
1.2 选格式、定坐标、设计字段
动手写创建代码前，有三个前置决定躲不开：用什么文件格式，用什么空间参考，字段表怎么设计。
格式方面，我的建议是分清“交结果用”和“干活用”。如果只是验证实验逻辑，GeoJSON是最好的选择，它就是一个文本文件，编码统一为UTF-8，用任意文本编辑器都能看结构，很多Web GIS框架直接支持加载。如果需要和主流桌面GIS软件互传数据，Shapefile依然是默认选择，但要注意它有三个配套文件，字段名限制10个字符，属性编码又不统一，到处是坑。FileGDB更适合管理海量数据，但读写依赖的驱动不一定每个环境都有。实验三阶段，我一般建议先用GeoJSON把逻辑跑通，最后再统一导出一份Shapefile作为成果文件。
坐标系决定“这些坐标落在哪里”。如果数据是经纬度，就明确写EPSG:4326；如果是米制投影坐标，必须选对应的投影带，比如常用的UTM分带，或者工程上常见的高斯-克吕格投影带号。这一项如果漏掉，生成的shp没有prj文件，别人打开时软件只能靠猜，坐标经常偏到完全不对的地方。
字段表设计与普通数据库表设计的逻辑一致：字段名短、含义清楚、类型固定，避免中文名和特殊字符。Shapefile对字段名长度有硬限制，超长会被截断，重名还会被自动加下划线，这些都要在设计阶段规避。不要觉得这些都是小事，我见过太多实验报告交上来，字段名变成一长串怪字符，老师连数据都看不懂。
1.3 为什么程序化生成比鼠标点选更适合实验
有人会问，桌面GIS软件里手工创建shp不就行了，为什么还要二次开发？因为实验的目标从来不是“产出一个shp”，而是建立“用代码操作数据”的能力。真实项目里，数据来源通常是数据库导出、传感器坐标流、表格文件，每天几千条增量，这时候只靠鼠标就彻底歇菜了。
程序化还有一个隐藏优势：可复现。实验报告要求写“实验过程”，如果用代码完成，每一步做了什么、参数是什么都体现在脚本里，将来数据错了能回溯。手工操作则很难精确复现，这也是很多工程团队禁止在正式数据上乱用鼠标编辑的原因。
从开发角度说，创建与编辑是很多工具的基础。批处理格式转换、数据清洗入库、自动制图模板，底层都是这一套“创建数据源-定义图层-写入要素-释放”的流程。学会这个框架，再去学空间分析、地图服务发布，会发现全是同一个套路。这部分找准了，实验三就不只是作业，而是一把工具钥匙。
2. 环境准备与最小工程骨架
2.1 数据层方案怎么选
GIS二次开发涉及的面很广，有桌面组件式开发，有Web服务端，也有数据批处理。但无论哪种，数据层的操作逻辑是通用的：都要有一个“数据访问驱动”负责读写不同格式，都有一套“图层/要素/字段”对象模型。我在这个实验里选择用开源的数据访问库GDAL/OGR配合Python来演示，原因很简单：它覆盖格式最全、跨平台、不需要授权，而且它读写的是最底层的数据结构，理解清楚后再去用商业GIS组件的编辑接口，几乎是无缝迁移。
这里补一句组件式开发的路子：在常见组件式GIS中，操作序列一般是这样：创建或者打开一个工作空间，获取要素数据集，在数据集里定义要素类的字段表，然后通过游标逐条插入要素，最后显式地保存编辑状态。这条链路和GDAL/OGR的“创建数据源→创建图层→创建字段→创建要素→释放数据源”是一一对应的。所以不管实验室装的是什么平台，底层的模式是同一个，把概念对应上，代码框架随手就能迁移。
2.2 环境搭建与验证
Python环境的安装不多说，关键是GDAL库的安装。GDAL这个库带不少本地编译产物，不同平台的安装体验不一样。Windows下建议直接用预编译的whl包，Linux下如果pip装不上，优先考虑conda的conda-forge渠道。装完以后一定要跑一下验证，别等写代码的时候才发现导入失败。
验证代码很简单：
from osgeo import ogr print("GDAL版本:", ogr.VersionInfo()) print("支持的驱动数量:", ogr.GetDriverCount())还可以打印驱动列表，确认Shapefile和GeoJSON的驱动都在：
for i in range(ogr.GetDriverCount()): print(ogr.GetDriver(i).GetName())这一步相当于开机自检，两分钟能省后面两小时。如果输出里没有ESRI Shapefile，说明安装出了问题，后面所有代码都会直接报错。另外，GDAL版本如果比较新，OGR Python绑定的默认异常行为是“静默返回空”，强烈建议在脚本开头调用ogr.UseExceptions()，让错误直接抛出来，方便定位问题。
2.3 工程目录与编码设置
工程结构我习惯这样组织：
experiment3/ ├── data/ # 原始表数据、示例坐标 ├── output/ # 生成结果 └── scripts/ ├── create_stations.py ├── edit_stations.py └── check_result.py简单清晰，output目录专门放产物，避免把脚本和生成的shp混在一起。数据文件和脚本分离，将来清理、备份都方便。
编码设置容易被忽略，但我建议每个脚本开头固定写一行：
from osgeo import gdal, ogr gdal.SetConfigOption("SHAPE_ENCODING", "UTF-8")Shapefile本身不保存编码信息，属性乱码问题大多出在这里。设成UTF-8之后，在主流GIS软件里打开能看到正确中文。如果你生成的shp要交给只认旧编码的软件，也可以改成对应编码，但UTF-8是当下兼容性最好的选择。除此之外，Python脚本源码也统一声明UTF-8编码，源码和文件编码一起保证，基本可以杜绝中文乱码带来的漫长排查。
3. 创建矢量文件的完整实现
3.1 先定Schema再写代码
很多初学者拿到需求第一件事就是打开编辑器开始写循环，写到一半才发现字段没设计好、类型不匹配，返工成本极高。我更建议先在纸上或者注释里把Schema定下来。比如实验要求创建“城市轨道站点数据”，就可以先定义：
| 字段 | 类型 | 说明 |
|---|---|---|
| station_id | 整数 (OFTInteger) | 站点编号 |
| station_name | 字符串 (OFTString, 32位) | 站点中文名 |
| line_name | 字符串 (OFTString, 16位) | 所属线路 |
| is_transfer | 整数 (OFTInteger) | 是否换乘站：0否 1是 |
再明确几何类型：点要素。空间参考：如果需要米制坐标就选投影坐标系，用经纬度就选WGS84。Schema定完，代码其实就变成了按表填空。这里有个重要经验：字段类型能整数就别用字符串，能定宽度就定宽度，不要全部用默认长度。字段类型混乱会导致后面统计、符号化的时候各种难受。
3.2 点、线、面三种要素的创建代码
先别急着复制代码，说明一下整体套路：它先删除旧文件避免驱动返回空数据源，然后通过驱动创建数据源，在数据源内部创建点图层，设置空间参考，定义四个字段，最后用循环把站点记录一条条写进去。整个过程严格遵循“建数据源→建图层→建字段→写要素→释放”五步，所有格式的创建代码都可以套这个模板。以“城市轨道站点”为例，格式用Shapefile，先看完整代码：
import os from osgeo import gdal, ogr, osr ogr.UseExceptions() gdal.SetConfigOption("SHAPE_ENCODING", "UTF-8") out_path = os.path.join("output", "metro_stations.shp") if os.path.exists(out_path): os.remove(out_path) # 1. 创建数据源和图层 driver = ogr.GetDriverByName("ESRI Shapefile") ds = driver.CreateDataSource(out_path) layer = ds.CreateLayer("metro_stations", geom_type=ogr.wkbPoint) # 2. 设置空间参考（示例使用UTM投影，实际按数据范围选择） srs = osr.SpatialReference() srs.ImportFromEPSG(32650) layer.SetSpatialRef(srs) # 3. 创建字段表 fid_f = ogr.FieldDefn("station_id", ogr.OFTInteger) layer.CreateField(fid_f) name_f = ogr.FieldDefn("station_name", ogr.OFTString) name_f.SetWidth(32) layer.CreateField(name_f) line_f = ogr.FieldDefn("line_name", ogr.OFTString) line_f.SetWidth(16) layer.CreateField(line_f) trans_f = ogr.FieldDefn("is_transfer", ogr.OFTInteger) layer.CreateField(trans_f) # 4. 写入要素 stations = [ (1, "模拟站A", "一号线", 0, 370500.0, 3400500.0), (2, "模拟站B", "一号线", 1, 371000.0, 3401000.0), (3, "模拟站C", "二号线", 0, 370800.0, 3402000.0), ] for sid, sname, line, trans, x, y in stations: feat = ogr.Feature(layer.GetLayerDefn()) feat.SetField("station_id", sid) feat.SetField("station_name", sname) feat.SetField("line_name", line) feat.SetField("is_transfer", trans) geom = ogr.Geometry(ogr.wkbPoint) geom.SetPoint_2D(0, x, y) feat.SetGeometry(geom) layer.CreateFeature(feat) feat = None # 5. 关闭数据源，必须释放 ds = None print("创建完成")注意代码里我特别写了feat = None。OGR在循环里如果用同一个变量反复创建Feature对象，Python端不显式释放的话，内存里可能积累大量待写入引用，轻则数据错乱，重则文件损坏。这是我在实际代码里吃过亏的地方。
线的创建逻辑和点几乎一样，只是几何对象换成wkbLineString，坐标用AddPoint_2D逐个追加。这个接口的命名很直白，就是向线上追加一个二维坐标点，一条线可以加任意多个点形成折线。需要注意，线要素对坐标顺序非常敏感，因为后续计算线长度、判断点在线哪一侧时都要依赖顶点的排列顺序，实验里画路线、河流、道路中心线时，最好在数据准备阶段就把顺序整理清楚。代码如下：
layer_line = ds.CreateLayer("route_lines", geom_type=ogr.wkbLineString) line = ogr.Geometry(ogr.wkbLineString) line.AddPoint_2D(370500.0, 3400500.0) line.AddPoint_2D(371000.0, 3401000.0) line.AddPoint_2D(371200.0, 3401500.0) feat = ogr.Feature(layer_line.GetLayerDefn()) feat.SetGeometry(line) layer_line.CreateFeature(feat)面的差别在于要先建一个线性环，把闭合边界的点按顺序加进去，再把这个环作为外边界添加到Polygon对象里。注意环必须闭合，也就是最后一个点和第一个点坐标相同。如果不闭合，有些软件会强行帮你闭合，有些直接显示不出面。这个闭合要求是初学者最容易踩的坑，写成代码时一定要在末尾重复一遍起点坐标：
layer_poly = ds.CreateLayer("service_areas", geom_type=ogr.wkbPolygon) ring = ogr.Geometry(ogr.wkbLinearRing) ring.AddPoint_2D(370000.0, 3400000.0) ring.AddPoint_2D(370500.0, 3400000.0) ring.AddPoint_2D(370500.0, 3400500.0) ring.AddPoint_2D(370000.0, 3400500.0) ring.AddPoint_2D(370000.0, 3400000.0) # 闭合点 polygon = ogr.Geometry(ogr.wkbPolygon) polygon.AddGeometry(ring) feat = ogr.Feature(layer_poly.GetLayerDefn()) feat.SetGeometry(polygon) layer_poly.CreateFeature(feat)这三个示例覆盖了矢量几何的三大基础类型。实际实验中，建一个点图层或者线图层就能满足大多数作业要求，但我的建议是把三种都跑一遍，因为后面做空间分析时面积、长度计算都是基于这些几何对象的。
3.3 落盘细节：空间参考、释放与追加写入
代码写完了，但“能跑”和“在专业软件里表现正确”是两回事。第一个高频问题就是空间参考。上面代码里调用了ImportFromEPSG(32650)，还调用了layer.SetSpatialRef(srs)。有些同学只设置图层空间参考，但创建几何时坐标却来自经纬度，结果软件打开后要素飞到了完全不对的位置。正确做法是：创建前就确定数据的真实际坐标系，坐标本身和空间参考必须一致。如果拿到的坐标是经纬度，就用EPSG:4326；如果是米制，就选投影坐标系。怎么确认？用srs.ExportToPrettyWKT()打印出来看，或者打开生成后带出来的.prj文件用文本方式观察内容。
第二个细节是释放。Shapefile驱动在写文件时，虽然我们已经调用了CreateFeature，但很多时候数据还没有真正刷到磁盘上；只有把数据源对象置为None，或者脚本正常退出，数据源才会正确收尾关闭，生成完整的三件套文件。如果忘记这一步，直接去打开shp，轻则提示文件被占用，重则shx文件损坏。类似的，调试时如果在桌面软件里打开了output目录下的shp，程序再去写同一个文件会报权限错误，因为桌面软件会独占文件，这是Windows平台最常见的坑。
第三个细节是追加写入。Shapefile一旦生成，就不能用CreateDataSource再次写进同一个路径，否则会返回一个空数据源甚至报错。追加数据正确做法是用driver.Open(path, 1)，第二个参数表示可写模式，然后往图层里继续创建要素。这一点我放在下一章细讲。
4. 矢量编辑：几何编辑、属性编辑与事务控制
4.1 编辑操作到底有哪些
创建完成了，实验三后半段一定是“编辑”。常见编辑操作归结起来就是四类：
- 新增要素：往已有图层里继续加记录，相当于数据库里的INSERT。
- 修改几何：移动点位置、改变线形状、调整面边界，相当于UPDATE geometry。
- 修改属性：改名称、改类型、改数值，相当于UPDATE attributes。
- 删除要素：按条件移除记录，相当于DELETE。
桌面GIS软件里这些操作都是鼠标点点，但二次开发里全是函数调用。值得留意的是，很多组件式GIS独有的“编辑会话”概念，在文件型数据源里表现得比较隐晦：GDAL/OGR对Shapefile没有显式事务，但对支持事务的数据源提供了StartTransaction、CommitTransaction这类接口。实验三阶段，大家只要记住一个原则：编辑前后做好备份，批量修改前先在最小数据集上试跑。
4.2 几何编辑与属性编辑的代码拆解
先讲新增。这里继续用上一章的metro_stations.shp，直接打开可写模式追加一个站点：
import os from osgeo import ogr out_path = os.path.join("output", "metro_stations.shp") ds = ogr.Open(out_path, 1) if not ds: raise RuntimeError("无法打开数据源，请检查文件是否存在或被占用") layer = ds.GetLayer() feat = ogr.Feature(layer.GetLayerDefn()) feat.SetField("station_id", 4) feat.SetField("station_name", "模拟站D") feat.SetField("line_name", "三号线") feat.SetField("is_transfer", 0) geom = ogr.Geometry(ogr.wkbPoint) geom.SetPoint_2D(0, 371500.0, 3402500.0) feat.SetGeometry(geom) layer.CreateFeature(feat) feat = None ds = None注意ogr.Open返回None的情况很多，尤其是当文件已经被其它软件打开。所以我习惯在Open之后立刻判断是否为空，否则后续调用会直接报空指针。
修改几何和属性的写法也很直白。比如把FID为0的要素平移一段距离，并把is_transfer改成1：
ds = ogr.Open(out_path, 1) layer = ds.GetLayer() feat = layer.GetFeature(0) if feat: geom = feat.GetGeometryRef() if geom: geom.Translate(50.0, 200.0) # 整体平移 feat.SetGeometry(geom) feat.SetField("is_transfer", 1) layer.SetFeature(feat) feat = None ds = None删除用layer.DeleteFeature(fid)一行就能做到。但这里有两个暗坑：一是Shapefile删除要素后，只是做了逻辑删除标记，物理记录还在dbf里，一些软件打开时可能仍然显示；二是删除操作后，要素的顺序和FID都会发生变化，如果程序里还用旧的FID去访问，就会拿到别的要素。
提示：Shapefile的DeleteFeature本质是逻辑删除，不是物理删除。批量删除或大批量更新前，一定先备份原文件。
所以在编辑代码里，强烈不建议硬编码FID，而是用属性条件或者空间位置查出来再操作。查出候选要素的经典方式是遍历后加判断，也可以用过滤器方法，实验阶段遍历足够。
4.3 事务、备份与拓扑检查
再往深一点说，真实的项目里编辑不是“打开-改-保存”这么简单。首先要做备份。一套数据在批量编辑之前，至少复制一份到备份目录，或者用代码直接复制一份带时间戳的副本。我在带实验时反复强调这一点，因为删错了、改坏了，如果没有备份，重建起来的时间和心理成本远大于备份的几秒钟。
其次，当数据量非常大，比如几万要素时，逐要素调用SetFeature会非常慢。这时候有两个优化方向：一是把读写操作放在一个图层循环里批量执行，不要频繁打开关闭数据源；二是如果数据源支持事务，把整批修改包在StartTransaction和CommitTransaction之间，失败时回滚，能保证数据一致性。
最后是几何合法性。编辑面要素时，拖一个节点很容易把面弄成自相交或者缺口，这在业务上会产生很多连锁错误。程序编辑后建议加一段检查：
geom = feat.GetGeometryRef() if geom and not geom.IsValid(): print("发现非法几何，尝试自动修复") fixed = geom.MakeValid() feat.SetGeometry(fixed) layer.SetFeature(feat)MakeValid()是GDAL新版中常用的几何修复函数，能解决大部分自相交、重叠问题。但别指望它是万能药，特别复杂的编辑还是人工介入比较稳妥。
5. 实验过程实录与高频问题排查
5.1 一次完整实验过程的现场记录
说个我印象比较深的模拟场景：有位同学A，实验要求基于表格数据创建公交站点shp并编辑出3条线路。他拿到一个实验用的站点表格，里面既有X、Y坐标，又有字段值。开始的时候A同学很顺利，跑完创建脚本，用桌面软件打开一看，站点是有了，但所有文字都是问号，字段名也被截断成了奇怪的形式。他第一反应是桌面软件问题，重新装了软件还是没用。
我帮他一层层查：先看脚本最前面有没有设置Shapefile编码，没有；再看读取表格的地方用了什么编码，桌面软件默认读取Shapefile属性时又按什么编码猜。根因就是创建时属性用UTF-8写入，但桌面软件按本地编码去猜，两边对不上。补上编码设置后，中文正常了。接着他又遇到第二个问题：输出目录里确实生成了prj文件，但站点位置和底图对不上，一查坐标系，底图是经纬度Web墨卡托，shp却是UTM投影坐标，本质就是“坐标系混用”。最后统一改成WGS84之后，站点全部落到底图正确位置。第三个问题是在编辑环节，他删除了一条线路的5个站点后，用软件查询属性表发现部分记录还在，又以为是删除没成功——其实那是Shapefile逻辑删除的典型特征，需要在软件里刷新才看不出来。
这个例子能覆盖这一章绝大部分要点：编码要统一、坐标要匹配、删除是逻辑删除。做实验时最忌讳“一个报错改一个地方”，最好先整体梳理一遍数据流的每个环节，再按环节排查。
5.2 高频故障排查速查表
把实验中最高频的问题整理成一张表，直接对照处理：
| 现象 | 可能原因 | 处理方法 |
|---|---|---|
| CreateDataSource返回None | 路径不存在或文件已存在 | 先用os.makedirs再判断是否存在，存在则先删除或换文件名 |
| 打开shp提示权限不足 | 文件被桌面GIS软件占用，或旧数据源未释放 | 关闭占用软件；把脚本里旧数据源全部置None，等待几秒重试 |
| 属性中文乱码 | 写入编码与读取猜测不一致 | 创建前SetConfigOption("SHAPE_ENCODING", "UTF-8")，读取端同样设置 |
| 要素位置偏到天边 | 坐标系设置错误或坐标与坐标系不匹配 | 统一用EPSG代码，确认数据真实坐标系，检查prj文件内容 |
| 面要素看起来没填充 | 环未闭合，或坐标顺序混乱 | 检查环首尾坐标是否一致，用geom.IsValid()验证 |
| 字段名被截断或变成下划线 | Shapefile字段名超10字符或重名 | 设计阶段控制字段名长度，全英文无空格 |
| 无法在原有shp上追加 | 用了CreateDataSource而不是Open写模式 | 改用ogr.Open(path, 1)，注意第二参数传1 |
| 删除要素后记录还在 | Shapefile逻辑删除机制 | 软件内刷新或用压缩工具清理；批量删除前先备份 |
| 脚本跑到一半内存暴涨 | 循环内未释放Feature对象 | 每次CreateFeature后执行feat=None，批量场景考虑分批提交 |
这张表的每一行都是我在实际开发或带实验时真实碰到过的。里面最隐蔽的是最后两行，尤其“逻辑删除”这一条，很多人会被它误导，以为代码写错了，其实文件格式本身就是这样设计的，不必恐慌。
还有一个很有用的命令行检查工具是ogrinfo，写完文件之后在终端跑一下：
ogrinfo -al -so output/metro_stations.shp ogrinfo -al output/metro_stations.shp-so只输出图层概要，包括字段、坐标系、要素数量；去掉-so则会把每个要素的属性和几何信息都打印出来。如果这个命令读出来的内容和预期一致，基本可以放心把shp交给任何软件；如果这个命令都读不对，就别浪费时间去调别的软件了，一定是文件本身的问题。而且ogrinfo的输出是纯文本，特别适合写进实验报告作为验证证据，比截图还直观，这是我很喜欢它的原因。
5.3 绕开弯路的小经验
最后说几点我从实验三里长期总结出来的体会，不算教程内容，但很实用。
第一，任何一个新建矢量文件的任务，时间分配应该是：数据设计四成、代码两成、调试四成。很多人代码写半小时，调试一晚上，根源就在于前面没想清楚。字段、坐标、格式三个问题只要在设计阶段定死，后面写代码只是体力活。
第二，调试时不要只盯着桌面GIS软件看，要学会用命令行工具检查和脚本自动验证。我通常会写一个十几行的验证脚本，创建完立刻重新打开数据源，打印要素数和前几条要素的字段值，跑完就相当于自检通过。这套“创建-读取-校验”的闭环能让自己几秒钟内发现问题，比反复用鼠标刷新省得多。
第三，关于坐标系，最好的习惯是永远在代码里显式写明EPSG编号。哪怕是默认的WGS84，也要写一句ImportFromEPSG(4326)。别留隐式默认值，因为“默认”的坐标参考在后续环节里几乎一定会被某处误判。这一点无论用开源库还是商业组件都一样。
第四，批量编辑前先备份，且备份文件带时间戳。有时候你以为只要备份一份，结果改到一半发现备份也被同步覆盖了。我的做法是往备份目录里写带日期的文件，宁可多存几份，也不要回头找救命数据时发现全没了。
最后，如果实验环境里用的是商业GIS组件，而不是这里的开源库，其实只需要把“数据源/图层/要素/字段”这几个概念对应过去，代码框架完全一致。遇到问题的时候，先把问题拆成“几何层”和“属性层”两个方向排查，能少走一半弯路。
