0、请做一下自我介绍（可选，开场使用）

问题：请做一下自我介绍。

回答：各位领导、同事大家好。我是后端开发，主要负责寄存柜业务系统后端模块的设计与开发工作。本次落地的寄存柜业务系统，面向出行旅客、商圈用户，提供就近寄存柜查询、点位导航、寄存使用指引全流程线上服务。在项目中，我主导整体模块拆分、接口设计、性能优化、异常兜底方案落地，搭建了「公共支撑底座 + 四大垂直业务模块」分层架构，完整承载用户定位、城市切换、寄存点地图检索、寄存指南展示整条业务链路。接下来，我结合项目内容，逐一进行介绍。

1、请介绍一下你最近做的项目？（需求）

问题：请介绍一下你最近做的项目。

回答：我近期主要负责寄存柜前端配套后端业务系统开发。随着线下寄存柜点位持续铺设，业务侧需要一套线上系统，让用户可以在线查找身边可用寄存柜，支撑多城市规模化运营。 基于业务目标，我们整体采用分层架构进行设计，整体分为两大板块：底层公共支撑基础模块，上层四大核心业务模块。 公共支撑模块作为系统统一底座，向下封装通用基础能力，包含六大子模块：接口鉴权与限流、多级缓存、全链路日志与用户行为埋点、数据存储与索引、监控告警、通用工具封装。底座模块被所有业务模块复用，避免重复开发、统一系统技术标准。 上层四大业务模块按照用户操作流程依次搭建：第一是用户定位模块，作为业务入口，自动获取用户地理位置；第二是城市选择模块，支持用户自主切换服务城市；第三是寄存点地图搜索模块，属于项目核心模块，根据坐标筛选附近寄存点位；第四是寄存指南模块，承载运营图文指引内容。 整套系统需要实现这些核心需求：第一，安全需求，所有接口做好访问管控，防范恶意刷取；第二，性能需求，高峰期大量用户同时查询点位，接口响应速度必须达标；第三，体验需求，完善各类异常、空白场景兜底策略，不能因为单个功能异常导致整个页面无法使用；第四，运营需求，支持城市灰度开放、页面文案动态配置，运营人员调整内容不需要发布新版本；第五，可观测需求，完整日志、监控告警，方便线上问题快速定位。 最终目标是打通用户「打开页面 - 自动定位 - 切换城市 - 查找附近寄存柜 - 查看使用规则」完整闭环，支撑后续百城寄存柜业务拓展。

2、你做的内容有什么难点，为什么会出现？（难点）

问题：你做的内容有什么难点，为什么会出现？

回答：在项目落地过程中，我主要遇到三大核心难点。 第一个难点：寄存点地理位置范围检索性能压力大。业务要求根据用户实时坐标，查询指定范围内由近到远排序的寄存点。最直观的方式是数据库实时计算两点之间直线距离，但是距离计算属于高开销运算。一旦大量用户同时发起点位查询请求，数据库 CPU 会快速打满，查询延迟急剧上升。同时随着后续点位数量持续上涨，全表计算距离的方式完全无法支撑并发场景。出现这个难点的根本原因：传统关系型数据库并不擅长大规模空间范围检索运算。 第二个难点：多模块联动场景下，缓存数据一致性难以保障。定位、城市选择、寄存点搜索三个模块存在强上下游依赖。当用户重新定位、手动切换城市时，需要同步刷新寄存点位数据。系统使用缓存降低数据库压力，若缓存刷新时机处理不当，就会出现缓存脏数据，造成前端展示点位和当前选择城市不匹配、定位刷新之后点位信息没有同步更新等问题。难点根源在于多个业务模块共享同一批缓存数据，用户主动操作触发状态变更时，缺少统一、可靠的缓存刷新机制。 第三个难点：边界场景繁多，异常链路复杂，全场景兼容成本高。用户侧会出现多种多样异常情况：手机定位权限关闭、定位服务超时、网络波动、用户选择暂未开通寄存业务的城市、当前 5 公里范围内没有任何寄存点位。只要任意一个环节出现异常，如果缺少降级兜底逻辑，就会出现页面空白、接口报错、流程中断。之所以会存在这个难点，是因为线上用户设备环境、网络环境各不相同，我们无法保证上游定位服务、数据库查询每次都 100% 成功，必须主动考虑各类失败场景。

除此之外还有衍生难点：业务持续扩张，后续会不断新增城市、新增寄存点位，架构设计必须具备良好扩展性，不能后期新增需求就大规模重构代码。

3、你是如何解决的？（解决）

问题：面对这些难点，你是如何解决的？

回答：针对上面梳理的难点，我针对性设计并落地对应的解决方案。 首先针对地理位置检索性能问题。第一，为寄存点数据表建立空间索引，依靠数据库原生空间能力做范围筛选，避免遍历全表计算距离；第二，增加查询范围限制，默认只检索用户周边 5 公里范围点位，缩小扫描数据范围；第三，引入多级缓存机制，对车站、商圈等人流密集的热点区域点位进行缓存，高频请求直接读取缓存，减少数据库查询次数；第四，限制单次接口返回点位最大条数，防止一次性返回上千条数据造成前端与后端双重压力。

其次针对多模块联动缓存一致性问题。我统一封装全局缓存操作工具，标准化缓存 key 设计，明确数据归属城市标识。约定触发缓存失效场景：用户手动切换城市、主动刷新定位、后台新增 / 修改寄存点位时，主动清理对应城市下寄存点位缓存。同时统一上下游模块数据结构体，定位模块、城市模块向外输出标准化城市编码，保证缓存筛选条件统一，减少数据解析错乱问题。

然后针对海量异常边界场景。我牵头梳理完整异常清单，对所有接口分级设计降级策略。定位服务调用失败，系统自动兜底展示默认城市；检索范围内不存在寄存点，前端展示定制化空状态提示文案；接口调用超时增加合理重试机制；所有异常情况全部打印全链路日志，同时进行埋点统计。保证无论出现哪种异常，业务流程不会直接崩溃，用户依旧可以正常操作页面。

最后面向业务拓展性，严格按照高内聚低耦合思路拆分模块，公共能力下沉到底层底座，业务功能独立拆分。后续新增功能，直接复用鉴权、缓存、监控等通用能力，不需要重复开发，降低后续迭代成本。

4、是否有其它解决方案？（拓展）

问题：针对以上问题，是否还有其它解决方案？

回答：针对项目里的核心问题，我在方案设计阶段对比过多种备选方案，下面分开说明。 第一，地理位置检索方案。当前我们采用「数据库空间索引 + 热点缓存」方案。备选方案是引入 Elasticsearch，依托 ES 内置的地理空间检索能力完成附近点位查询。ES 更适合点位数量达到百万级、超高并发检索场景。但是现阶段我们寄存点位总量不大，如果引入 ES，需要新增中间件部署、运维成本，增加项目复杂度。综合项目当前体量，现阶段数据库方案投入成本更低；等到未来点位规模大幅上涨之后，可以平滑迁移至 ES 方案。

第二，缓存一致性方案。目前我们采用主动失效缓存方案。备选方案可以引入消息队列，后台点位数据变更之后发送消息，消费端异步完成缓存清理。但是当前业务变更频次较低，引入 MQ 会增加运维组件，提升系统复杂度。短期主动清理方案完全满足需求；未来后台点位频繁批量更新场景出现后，可以引入消息队列实现最终一致性。

第三，定位能力实现方案。当前采用 GPS 定位优先、IP 定位兜底的策略。备选方案可以直接对接高德、百度地图高精度定位第三方接口。优势是定位成功率、精度更高；劣势是持续产生第三方接口调用费用。结合成本考量，当前自研降级方案可以平衡用户体验与资金成本。

第四，异常兜底层面。长期方案可以搭建统一熔断组件，对定位服务、数据库查询配置熔断策略，连续多次失败自动触发熔断，保护下游资源。现阶段异常量可控，依靠代码内降级逻辑足够支撑运行，作为后续优化储备方案。

5、项目中做过哪些优化，效果怎么样？（优化）

问题：项目中做过哪些优化，效果怎么样？

回答：项目开发与上线阶段，我从性能、业务体验、运维能力三个维度落地了多项优化工作。 第一项，接口性能专项优化。统一规范接口分页逻辑，限制点位查询最大返回数量；调整数据库索引，删除无效索引，优化 SQL 执行计划。优化完成后，定位接口响应耗时稳定控制在 200ms 以内，寄存点查询接口 P95 耗时稳定低于 300ms。高峰期上千用户同时访问，没有出现大面积接口超时，性能指标达到业务预期标准。

第二项，缓存策略精细化优化。区分冷热数据，只对高频访问城市点位进行缓存，设置差异化过期时间。避免冷数据长期占用缓存空间，同时平衡数据实时性。优化完成后，寄存点位查询对应的数据库 QPS 下降大约 40%，显著减轻数据库压力。

第三项，运营能力与用户体验优化。把空状态提示、引导文案、城市提示全部改造为后台可动态配置内容，运营人员可以随时修改文案，不再依赖开发发版迭代。同时完善全量用户行为埋点，持续采集定位失败、无寄存点位、城市切换等场景数据。产品和业务团队可以依托埋点数据分析用户痛点，指导线下点位铺设规划。

第四项，线上可观测能力优化。完善监控告警规则，针对接口平均耗时、P95 耗时、错误率设置阈值告警。一旦线上出现性能波动、报错突增，运维人员可以第一时间收到通知。故障发现时长相比优化前大幅缩短，降低线上故障带来的影响。

第五项，代码工程优化。统一封装公共异常、统一返回格式，消除各个模块重复代码；完善接口注释、数据库文档，新人接手项目可以快速理解模块依赖关系，降低后期维护成本。

整体来看，一系列优化落地之后，系统并发承载能力、稳定性、运营灵活度都得到明显提升，能够平稳支撑当前业务流量，同时为后续业务放量预留性能空间。

6、对新趋势新技术有什么了解，能否用到你的项目中？（双新）

问题：对新趋势新技术有什么了解，能否用到你的项目中？

回答：平时我持续关注后端开发领域新技术、新趋势，结合寄存柜系统现状，梳理出几项可以结合业务落地的技术方向。

第一，空间向量检索技术。目前我们依靠空间索引筛选附近寄存点。向量数据库可以把地理位置信息转化为向量实现邻近检索。未来业务发展到下一阶段，我们不止要展示附近寄存柜，还可以结合用户存取行李行为数据，构建用户行为向量，实现寄存点位个性化智能推荐。向量检索技术可以作为下一代空间检索方案备选，当点位体量持续上涨后进行技术升级。

第二，Serverless 云函数技术。系统内寄存指南、静态说明类接口，访问流量波动极大，大部分时间访问量很低。这类低频静态接口可以改造部署在 Serverless 云函数。流量低的时候自动释放计算资源，高峰自动扩容，能够有效节约长期服务器资源成本，适合后续渐进式改造落地。

第三，低代码可视化运营平台。当前运营配置能力比较单一，只能修改基础文案。引入低代码平台之后，运营人员可以自主配置活动页面、点位介绍、弹窗内容，减少大量简单需求的开发排期，释放研发人力聚焦核心业务开发。

第四，分布式链路追踪技术。当前我们具备基础日志能力，但完整链路串联能力不足。接入分布式链路追踪组件之后，可以完整串联「定位请求 - 城市筛选 - 点位查询」整条调用链路，问题定位效率会进一步提升，适合后续系统模块持续增多之后引入。

同时我也会理性看待技术选型，不会盲目追求新技术。现阶段系统首要目标保障业务稳定可靠，新技术不会立刻大规模上线。我们会在现有架构预留扩展接口，持续跟进业务增长情况，分阶段评估、平稳引入适配业务场景的新技术，做到技术服务于业务。