企业官网建设流程全解析

1. 为什么"附近的人"业务，最终都会收敛到Redis GEO

1.1 业务场景里的真实诉求

做社交App、本地生活平台，或者哪怕只是做一个企业内部的小工具，都逃不掉一个需求：根据当前用户的经纬度，找出他附近的人、附近的店铺、附近的可调度车辆。这个功能说起来一句话，做起来却有一堆细节。很多团队最开始都是用MySQL硬算，后来换成了Redis GEO，原因很简单：它把"存储坐标、计算距离、按距离圈选"这三个动作，压缩成了一组命令，而且性能非常稳定。

"附近的人"这个需求本质上包含三个步骤：先有坐标数据，再算两点或多点之间的距离，最后以某个点为圆心画一个半径圈，把落在圈里的成员捞出来。如果把这三个步骤拆开看，MySQL也能做，MongoDB也能做，Elasticsearch也能做，但Redis GEO的做法最贴合互联网高并发场景——因为坐标是高频写入的，查询是毫秒级的，而且不需要引入一套新的存储组件。我建议做后端或者架构设计的朋友，至少要把GEO的底层原理和常用命令吃透，因为这类功能在面试中出现的频率一直很高，在实际项目中也是"小功能、大讲究"。

1.2 传统方案为什么不够用

先说我见过最多的MySQL方案。很多第一版代码是这样的：在user表里加latitude和longitude两个字段，查询附近的人时，先算一个粗略的经纬度范围，再用Haversine公式精确过滤排序。当用户量到十万、百万以后，这个SQL会越写越重，因为经纬度范围查询很难走到索引的极限优化，加上距离计算又要全量扫一遍候选集。即便你把经纬度拆成字符串前缀索引，也只能做到"方格过滤"，无法真正利用空间索引。MongoDB的GeoJSON不错，能直接查$nearSphere，但前提是你愿意为这个功能引入MongoDB；如果公司主存储是MySQL + Redis，架构上不会轻易为了一个"附近的人"再养一套库。

Elasticsearch的geo_distance查询也很强，适合搜索场景，但它更重、写入成本更高、集群运维更复杂。对大多数互动型业务来说，位置数据的特点是"写入频繁、单次数据量小、查询范围可控"，这正是Redis的舒适区。Redis GEO最打动我的一点是，它把一个复杂的地理计算问题藏在了底层，上层只需要几条命令就能完成核心逻辑，给业务快速迭代留出了很多空间。

为了更直观，我把几种常见方案放在一起对比：

1.3 什么情况下别急着用GEO

所有技术都有边界，GEO也不例外。如果你的业务是全国用户都在一张大表里，而且单Key下面的成员数会冲到千万级，那Redis GEO需要谨慎评估。因为一个ZSet放进一个Redis节点，内存和热点问题会同时冒出来，这种量级更适合用分布式空间索引或分片方案。

如果查询场景带有非常复杂的多边形区域、行政边界判断，比如"判断用户是否在上海内环高架围成的区域内"，GEO的圆形半径模型就不够用了。GEO解决的是"圆型附近"问题，不是"任意多边形包含"问题。下面我写的原理部分会解释为什么GEO是圆型思维，这会帮你判断它到底适不适合你的业务。

2. 懂点原理：GeoHash和ZSet是怎么组成GEO的

2.1 GeoHash编码：把二维坐标降维成一维字符串

Redis GEO的底层是GeoHash算法加Redis自己改造的ZSet结构。GeoHash的核心思路，是把地球看作一个巨大的二维网格，通过不断二分的方式，把经纬度编码成一串二进制，再转成字符串。整个过程相当于把一张地图从全世界范围开始，一格一格地切分成越来越细的小方格，直到小到能表示一个用户坐标。

具体做法是，对经度区间[-180, 180]和纬度区间[-85.05112878, 85.05112878]分别做二分。以北京的某个点为例，经度116.397，先看它在左半区还是右半区，如果在右半区记1，然后缩小区间继续二分，反复多次；纬度39.909同样处理。最后把经度得到的二进制序列和纬度得到的二进制序列按位交错拼起来。交错的顺序是经度占偶数位、纬度占奇数位，这也是GeoHash能支持邻近搜索的关键——相邻的两个点，它们的整体编码前缀也会大概率相同。

Redis内部并不直接存"w3wpx"这种字符串，它会把GeoHash的二进制结果转成一个52位的整数，作为ZSet里的score。为什么是52位而不是64位？因为Redis的score本身是double类型，double的尾数精度是52位，所以这个设计刚好能塞进score里，不会丢精度，再说double给位置排序也足够用了。

我画了一个很好理解的类比：GeoHash就像是把地球划分成了无数个大小不同的格子，字符串前缀越长，格子越小，定位越精确。编码长度和精度有个大概对应关系：

Redis使用52位整数，定位精度大概在厘米级到米级之间，对"附近的人"完全够用。

2.2 为什么Redis选了ZSet而不是其他结构

如果你去看Redis的源码，GEO相关命令最终落地的数据结构就是ZSet。成员（member）是ZSet里的元素，GeoHash编码后的52位整数是score。ZSet天然支持按score排序，所以"按距离远近排列"这种需求直接就映射成了"按score排序"。

不过要注意一个细节：ZSet的score通常表示权重或排序值，而在GEO场景里，score被编码成了位置信息。两个用户的坐标如果很接近，他们的GeoHash编码前几位相同，score值也会很接近，这样ZSet在内存中的存储顺序就把"地理位置相近"这个物理意义也体现出来了。Redis源码里还实现了一个辅助机制，当需要对某个坐标做附近搜索时，它会把经纬度换算成对应的score范围，再结合一个特殊的GeoHash邻近格子搜索逻辑，找出候选集合，最后做精确距离过滤。

还有一个值得说的是member本身。ZSet的member只能是一个字符串，所以你没法在GEO里直接存一个用户对象。常见的做法是member里直接放用户ID，比如"uid:10001"，如果需要额外信息，要么把用户ID和某个业务标识拼接起来，要么先查出ID列表，再去用户表里批量补全详情。这一点会在后面的实战部分具体展开。

2.3 距离计算与误差控制在哪个量级

很多刚接触GEO的人会问：Redis算出来的距离到底准不准？它内部在计算两点距离时，使用的是WGS84椭球体模型下的近似公式，默认返回单位是米。这个模型把地球近似成一个椭球，而不是完美球体，所以在绝大多数场景下，基于Redis GEO算出来的距离误差非常小，通常不超过0.5%，在几十米到几公里的"附近的人"场景里几乎感觉不到差异。

真正需要留意的不是这个理论误差，而是边界条件。比如你的用户在北京东城，另一个人在北京西城，Redis算出来8.5公里，业务上完全可以接受。但如果你的业务点正好在北极圈附近，或者目标数据跨越了本初子午线两侧（东经179.9度和西经-179.9度），普通人的直觉计算会得出绕了地球一整圈的距离，而Redis的地理模型会正确处理这种跨边界场景，因为它用的是球面距离公式，不会出现"明明很近却算成19220公里"的乌龙。这一点比自己在SQL里写Haversine半吊子实现要靠谱很多。

3. 命令细节：从GEOADD到GEOSEARCH，每个参数都别用错

3.1 写入坐标：最容易犯的经度、纬度顺序问题

Redis GEO全家桶里，和写入相关的核心命令是GEOADD，语法如下：

GEOADD key [NX | XX] [CH] longitude latitude member [longitude latitude member ...]

注意了，这里是longitude latitude，先经度后纬度。我见过不止一个项目因为这个顺序搞反，导致把北京的用户存到了南美洲附近的海里。Redis这么设计虽然有历史原因，但你已经知道这个点了，就当是肌肉记忆记住：先写经度，再写纬度。

坐标范围也要提前校验一遍，经度范围是[-180, 180]，纬度范围是[-85.05112878, 85.05112878]，超出这个范围Redis会返回error。为什么纬度不是精确到[-90, 90]？因为GeoHash算法在墨卡托投影相关变体下，超过这个范围后编码会退化，Redis源码里硬编码了这个限制。实际业务用户坐标基本不会触及这个边界，但如果你接的是IoT设备的原始GPS上报，最好在业务层做一次合法性校验，避免脏数据直接写进GEO。

另外，同一个member重复执行GEOADD，效果是更新它的坐标，不会多出一个成员。如果非要区分"新增"和"更新"，可以加上CH参数，它让命令返回本次实际变更的成员数量。Redis 6.2之后还多了NX和XX选项，NX表示只有成员不存在时才写入，XX表示只有成员已存在时才更新，这个和常规Redis写入命令的语义是对齐的。

3.2 查询坐标与距离：GEOPOS和GEODIST

写入坐标之后，怎么看一个成员存进去的坐标对不对？用GEOPOS：

GEOPOS key member [member ...]

它会返回成员的经度和纬度，注意返回值里也是[经度, 纬度]的顺序。需要说明的是，由于内部的GeoHash编码会损失极少量精度，GEOPOS返回的坐标可能和原始坐标有一米以内的偏差，这不影响附近的人业务，但如果你的业务需要存储高精度坐标并回显给前端，最好还是在业务库里另存一份原始坐标，GEO只负责圈选和排序。

GEODIST用来算两个成员之间的距离：

GEODIST key member1 member2 [m | km | mi | ft]

默认单位是米，也可以指定km、mi或ft。这个命令返回的是两个member在ZSet score层面解码后的坐标计算出的直线距离，也就是球面最短距离，不是驾车距离，也不是步行导航距离。如果业务里说的是"附近的人"这种直线半径范围，那没问题；如果是外卖配送、打车调度这类需要实际道路距离的场景，GEO只能帮你缩小候选范围，精确路径距离还得交给地图服务商的路线API。

3.3 附近搜索：GEORADIUS和GEOSEARCH的实际差异

最核心的圈选命令有三个：GEORADIUS、GEORADIUSBYMEMBER和GEOSEARCH。

GEORADIUS key longitude latitude radius m | km | ft | mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count [ANY]] [ASC | DESC] [STORE key] [STOREDIST key]

这条命令以你指定的经纬度为中心，搜索radius范围内的成员。GEORADIUSBYMEMBER则是以一个已有成员为中心，相当于先把该成员的坐标取出来，再执行一次GEORADIUS。

GEORADIUSBYMEMBER key member radius m | km | ft | mi [WITHCOORD] [WITHDIST] [COUNT count [ASC | DESC]]

GEOSEARCH是Redis 6.2引入的新版命令，它用FROMMEMBER或FROMLONLAT指定中心点，用BYRADIUS或BYBOX指定半径或矩形范围。相比老命令，GEOSEARCH语义更清晰，也更推荐在新项目中使用。

GEOSEARCH key FROMLONLAT longitude latitude BYRADIUS radius km [ASC | DESC] [COUNT count] GEOSEARCH key FROMMEMBER member BYBOX width height km [ASC | DESC] [COUNT count]

FROM和BY的组合其实是两套独立维度。BYBOX适合做矩形围栏，比如判断用户是否在某个商场的3km乘2km矩形范围内；BYRADIUS则是标准的圆形半径搜索。

3.4 WITHCOORD、WITHDIST和COUNT这些选项怎么配

如果你只想拿到一批符合距离条件的Member ID，直接不加任何WITH选项，命令返回的是成员名列表。如果还需要把距离一起返回，就加WITHDIST，返回结果里每个成员会附带一个距离值；需要坐标就用WITHCOORD；需要内部的GeoHash整数就用WITHHASH。建议日常开发中按需使用，别一股脑全加上，数据量大的时候多解析几个字段对性能也有微小的损耗，虽然可以忽略，但徒增复杂度。

COUNT参数必须和排序配合理解。如果只写COUNT 10，Redis在搜索时会尽量返回任意10个符合条件的成员，但未必是按距离最近的那10个。想要"最近的前10个"，必须写COUNT 10 ASC，让Redis先按距离由近到远排序，再取前10个。这一点是线上最容易看走眼的地方，后面实战会再强调一次。

4. 实战：用Spring Boot把"附近的人"接口真正落地

4.1 先想清楚数据模型，再写第一行代码

假设你现在的业务是做一个App的"附近的人"功能。用户每次打开首页或者切换定位时，都上报一次自己的经纬度，然后App请求附近的人列表。这个功能如果直接操作数据库里的位置表，写压力会很大，而且查询也不灵活。用Redis GEO后的设计思路是这样的：每个业务域单独一个GEO key，比如用户量大的App，可以按城市拆key，key的粒度直接决定了后续查询的精准度和压力。

我的建议是key粒度控制在"城市"，比如lbs:user:geo:beijing。为什么不是lbs:user:geo全国一个key？因为一个key对应一个ZSet，如果全国几百万用户都塞进同一个key，就形成了典型的大key。大key问题在Redis Cluster环境下尤其明显，单key的写入和迁移都会成为瓶颈。按城市拆key后，每次查询先通过手机号、IP或前端上报的城市码确定要查哪个key，查询半径覆盖范围内的人，跨城用户再分别查多个key后合并，完全能满足业务。

Member设计上，直接用uid:10001这种可解析的格式就好。如果还需要知道用户的性别、昵称、等级，不要写进member里，先拿到ID列表，再去用户基础服务批量查询详情。这样GEO的职责非常单一：只回答"哪些目标在半径内、距离是多少"。

4.2 位置上报接口：用GeoOperations写入坐标

在Spring Boot项目里，我一般直接用Spring Data Redis提供的GeoOperations，它封装了底层命令，代码更清爽。先看一个上报接口的示例：

@Service public class UserLocationService { @Autowired private StringRedisTemplate redisTemplate; private static final String GEO_KEY_PREFIX = "lbs:user:geo:"; public void reportLocation(Long userId, String cityCode, double longitude, double latitude) { String key = GEO_KEY_PREFIX + cityCode; String member = "uid:" + userId; // 先写Redis GEO，保证查询立即可见 redisTemplate.opsForGeo().add(key, new Point(longitude, latitude), member); // 异步落库，保留一份最新坐标用于回显示和兜底 asyncSaveOrUpdateUserLocation(userId, cityCode, longitude, latitude); } }

注意这里我用了StringRedisTemplate，因为GEO的member是字符串，这样最直接，省去序列化器不一致的问题。Point对象来自Spring Data的org.springframework.data.geo.Point，构造时同样先传经度再传纬度。

坐标上报接口的QPS通常都会很高，不建议在接口里同步落MySQL，否则流量高峰会把数据库打爆。可以先把坐标写入GEO，然后通过MQ异步更新业务库里的最新坐标，做到最终一致。查询附近的人时，因为GEO里的数据是实时写入的，所以最新的位置一定在GEO里；而像用户个人中心展示坐标这种非实时场景，读MySQL就好。

4.3 附近的人搜索接口：GEORADIUS实战

查询附近的人时，核心代码大致如下：

public List<NearbyUserVO> nearByUsers(Long userId, String cityCode, double longitude, double latitude, double radiusKm, int limit) { String key = GEO_KEY_PREFIX + cityCode; // 注意：这里用Circle表示单位是米，所以半径要转成米 double radiusInMeters = radiusKm * 1000; Circle circle = new Circle(new Point(longitude, latitude), new Distance(radiusInMeters, Metrics.KILOMETERS)); // Redis GEO命令：GEORADIUS key longitude latitude radius km WITHDIST ASC COUNT limit GeoResults<GeoLocation<String>> results = redisTemplate.opsForGeo() .radius(key, circle, GeoRadiusCommandArgs.newGeoRadiusArgs() .includeDistance() .sortAscending() .limit(limit)); List<NearbyUserVO> voList = new ArrayList<>(); for (GeoResult<GeoLocation<String>> result : results) { String member = result.getContent().getName(); Double distanceKm = result.getDistance().getValue(); // 排除自己 if (("uid:" + userId).equals(member)) { continue; } Long uid = Long.valueOf(member.replace("uid:", "")); voList.add(new NearbyUserVO(uid, distanceKm)); } return voList; }

这里有一个非常容易踩的坑：Distance构造时，如果传了Metrics.KILOMETERS，Spring Data会按公里来解析，但底层执行时又会根据实际选项作换算。建议统一以米为单位构造Distance(radiusInMeters, Metrics.METERS)，避免单位混乱。我早期就因为km和m混用，找出来的距离大了1000倍，排查了很久才发现是单位问题。

GeoRadiusCommandArgs支持includeDistance()、includeCoordinates()等选项，如果业务只需要显示"1.2km"这种距离，就只要includeDistance，不要开启includeCoordinates，减少数据解析开销。

4.4 删除位置与数据清理

用户注销、关闭定位权限、或者一段时间不再使用App，他的位置信息不能一直留在GEO里，否则会积累大量"幽灵用户"，导致每次附近的人查询都会搜出很多无效成员。GEO删除命令其实就是ZREM：

ZREM key member

在Java里可以这样用：

redisTemplate.opsForZSet().remove(key, member);

我建议在业务层做两层清理：第一层是用户主动操作时同步删除，比如用户退出登录、关闭附近的人功能；第二层是定时任务兜底，比如每天扫描GEO里最后活跃时间超过7天的用户并移除。如果你把活跃时间存在MySQL或另一个Redis结构里，扫描时先取出GEO的member列表，再用活跃时间过滤，然后批量ZREM，这个方案在几十万用户量级下完全跑得动。

4.5 集群环境下的key分布与跨城查询

系统到了Redis Cluster阶段，key的分布由CRC16哈希决定。按城市拆key之后，一个城市的坐标会被路由到同一个slot，读写都集中在一个节点上。城市用户量大的话，这个节点仍可能偏高负载。进一步的优化是再按区域或网格拆key，比如北京按环线拆成多个子区域，key类似lbs:user:geo:beijing:chaoyang。代价是查询附近的人时需要同时查周边多个子区域，再在应用层做一次排序合并。

跨城查询的逻辑不复杂。比如用户在北京国贸，他要搜索半径50公里内的所有人，这个半径很可能覆盖到河北燕郊或天津武清。如果业务边界必须算这些人，就需要把可能命中的周边城市的key都查一遍，然后合并结果。这里有个取巧的办法：前端上报定位时，同时算出当前坐标所在的城市码以及周边城市码，后端一个个key执行GEORADIUS，最后汇总排序。虽然请求次数多了，但每次都是毫秒级，整体仍然很快。

5. 生产环境会踩的坑，我帮你提前列出来

5.1 经度纬度顺序错乱，数据写进海里

这个问题前面提过一次，但因为它太典型，值得单独拎出来讲。GEOADD写反坐标，或者接口层把RequestParam里的lat和lng映射反了，都会造成数据漂移。如果你发现上线后某些用户的位置莫名其妙出现在非洲西海岸或太平洋中间，十有八九是经纬度搞反了。

我在代码里习惯写一个统一的位置工具类，强制所有调用方先传经度再传纬度，并且加单元测试覆盖。工具内部还可以做一轮合法性检查，超出[-180, 180]和[-85.05112878, 85.05112878]的坐标直接抛异常。生产环境的数据质量，很大程度上靠入口校验扛住，不能指望下游存储兜底。

5.2 COUNT、ASC和ANY搭配产生的理解偏差

GEORADIUS命令支持COUNT参数，但不同搭配下的行为差异很大。Redis 6.2之前的版本，COUNT n的含义是"最多返回n个结果"，但计算过程仍然会扫描整个半径范围内的候选集，只是最终只返回部分；当你指定ASC时，它会先排序再取前n个。如果你没指定排序又指定了COUNT，它返回的是扫描过程中任意匹配的n个，所以出现"明明旁边有人但没返回"的情况，并不奇怪，这是命令语义决定的，不是Bug。

Redis 6.2开始支持COUNT ANY选项，它的意思是"只要找到n个任意结果就提前返回，不再继续扫描"。"附近的人"列表如果只要求随机推荐，可以用ANY提升响应速度；但如果要按距离从近到远展示，必须用COUNT n ASC，不能指望ANY帮你挑出最近的人。这两种模式混合使用时，需要额外写清楚注释，防止团队其他成员误用。

5.3 大Key和热点Key：拆Key是一门平衡艺术

当一个城市的ZSet成员数超过百万，单条指令的执行时间可能提升到几十毫秒甚至更多，虽然没有慢到不可接受，但它会拖累Redis的其它操作。更严重的是，如果这个key始终被高频查询，它在Cluster里所在的节点会成为热点节点，导致整个集群负载不均。

应对方案有两类。第一类是按更小粒度拆key，比如按行政区、按经纬度网格。第二类是给key增加副本或本地缓存，在应用层做短期缓存降低Redis压力。做LBS业务时我优先选第一类，因为拆key之后不仅可以做分布式分摊，还能配合GeoHash的网格实现更精准的区域内圈选。不过拆key会带来代码复杂度上升，所以一般团队至少要等到单key数据超过几十万，再考虑这个方案。

5.4 GEO本身没有过期时间，注意治理冷数据

GEO成员存放在ZSet里，ZSet没有TTL概念，因为一个key整体只能设置一次过期时间。如果你给一个城市key设置了24小时过期，那用户的坐标24小时后全没了，显然不行。正确的做法是定时清理冷数据，或者用双key策略：一个GEO key专门存在线用户位置，另一个Redis String或ZSet记录用户最后活跃时间，定时任务负责比对清理。

这里还有个细节，ZSet的member是去重的，同一个用户重复上报坐标只是更新score。所以如果你想让"某段时间内活跃的人"这一语义更自然，可以设计成"每次上报都重新写入GEO，且同时更新活跃时间；定时清理时只删除超过N天不活跃的member"。在活跃度高的社交产品里，这种策略比较实用，也不会让GEO无限膨胀。

5.5 精度误差与业务口径的统一

Redis GEO算出来的是直线球面距离，不是实际道路距离。社交场景展示"3.2km"没问题，但如果业务需要显示"步行需要30分钟"，那就要对接地图路网数据。更麻烦的是，不同端展示的距离口径如果不一致，用户会投诉。

我的建议是：所有距离展示统一从Redis GEO获取直线距离并换算成公里数，文案写成"直线距离约3.2km"，不要顺手写成"距离3.2km"。这样既利用高并发查询的实时性，又避免误导用户。等用户产生进一步动作，比如打车、导航，再接地图服务商的路线规划接口，用更精准的路程距离。

6. 从一个GEO功能延伸出去的架构思考

6.1 附近门店、运力调度与订单分配

"附近的人"只是GEO最典型的应用。同样的模式，可以很容易地扩展到附近门店：把门店ID和坐标放进GEO，用户查询附近门店时，先按半径圈出门店ID列表，再回MySQL查门店详情和营业状态。这个方案在门店数量几千到几万时，体验非常好，Redis每次查询都是微秒到毫秒级。

在运力调度场景里，可以按城市维度维护一个司机位置的GEO key，当新订单产生时，以订单坐标为中心搜索附近空闲司机，然后推送给司机端。相比把所有司机坐标放在内存业务代码里做双重循环，Redis GEO的圈选和排序逻辑已经能覆盖大部分调度需要。

6.2 和其它位置服务的选型对比：什么时候换路

前面提到MySQL、MongoDB、Elasticsearch都可以做位置查询，那Redis GEO适合什么样的体量？我的判断标准是：单key百万级以内，半径搜索的QPS几千到几万，业务查询模式是"圆形半径圈人"，那么Redis GEO几乎是最简单高效的方案。一旦数据量继续上涨，查询开始涉及复杂的多边形围栏、实时轨迹回放、空间分析等需求，就应该考虑引入专门的地理空间服务或PostGIS等方案的扩展接口。

这里给一个选型思路，供参考：

6.3 面试时，GEO这条线可以聊多深

如果这个话题出现在面试里，很多候选人会停在"用过GEOADD和GEORADIUS"这个层面。想表达出深度，可以重点讲讲：为什么Redis GEO选择ZSet作为底层结构，为什么score是52位整数，GeoHash编码如何影响邻近搜索，以及线上大key如何拆解。这些信息在本文前面都覆盖到了。

再往深一层，可以讨论Redis源码里关于GeoHash的近似搜索策略：每个矩形搜索框会映射到多个GeoHash格子，Redis会逐一检查邻接格子，最终在候选集合里做精确距离过滤。这个设计其实就是在"召回更多候选"和"过滤精确距离"之间做平衡。把这个逻辑讲清楚，会让面试官觉得你不仅有使用经验，还理解系统设计背后的取舍。

最后分享一个我个人的习惯：凡是和位置有关的接口，不管前端传不传坐标合法性校验，后端我都要做一遍；凡是写GEO的命令，都封装成独立方法而不是散落在业务代码里；凡是线上遇到"距离看起来不对"的反馈，第一反应永远是先查坐标顺序和单位换算，因为这两个问题至少占了我遇到的位置类故障的八成。

Redis GEO确实是一个"小而美"的功能，但它背后承载的是坐标编码、空间索引、数据分片、缓存治理这套完整的方法论。把它吃透，不光是多会了几条命令，更是对"如何用最简单的数据结构优雅解决一维问题"这件事有了更深的理解。