在郑州做上门预约软件的那段日子，最先撞到的不是界面美观，而是“谁先到、谁放心”的派单痛点。家政、 beauty、美业与教培各有规则：美业讲预约时间窗，家政强调频次与同一技师稳定性，教培需要排课与老师资质绑定。于是我的第一个决定是把业务边界拆成若干有界上下文，用领域驱动（DDD）把共性与特性分离，而不是一开始就把所有功能塞进单体控制器里。

      技术选型上，我倾向于前端用 Vue 3 + TypeScript + Vite，移动端同时维护一个微信小程序和基于 Flutter 的跨平台应用；后端主服务用 Go 1.20 做高并发 API，结算与复杂业务流程用 Spring Boot 2.7 编写。数据层采用 PostgreSQL（主库分区、只读副本）+ Redis（缓存与 GEO 索引），异步用 RabbitMQ；部署在 Kubernetes（Helm 管理），监控用 Prometheus+Grafana，日志走 Loki。这样组合不是唯一正确，但满足本地服务对实时性与可运维的现实要求。

      针对地理匹配，我把位置索引交给 Redis GEO 和 geohash 预筛，先用粗粒度网格过滤，再用精确 Haversine 计算距离排序；派单采用加权优先队列，权重由技师评分、历史接单率、空闲窗口与行程距离共同计算。实操发现，单纯依赖 geohash 会出现“网格边界效应”，最后加了邻区合并与阈值回退逻辑，减少误判。

      支付与回调是另一个坑：微信/支付宝回调可能重试、延迟或签名异常。我的做法是统一入口做幂等校验（幂等键、状态机）并用本地事务＋异步补偿（Saga 模式）处理账务。遇到并发扣款竞争，用 Redis RedLock 控制关键段，短时间内降低事务冲突，牺牲些延迟换取数据正确性——这是权衡，不是绝对优解。

      图片与音视频资料常超过带宽预算，所以采用阿里云 OSS + CDN，上传走分片直传，后端仅保存元数据；离线转码用 FFmpeg 在异步任务池中处理，处理进度放到 Kafka，前端通过 WebSocket 拉取实时进度。实战告诉我：务必在上传环节做断点续传与校验，否则用户会因单次失败反复重传，体验很差。

      排查技巧很简单也很关键：遇到延迟，先看调用链（Jaeger），再看数据库慢查询与连接池使用，最后看网络包。曾经一次订单延迟来自 pgsql 连接池配置太小，外加 ORM N+1 查询；把 pgbouncer 加入后，延迟明显回落。这类“流水线问题”常常不是单点，而是二三项小问题叠加。

      对本地化需求要敏感：支持本地身份证校验、培训记录、营业执照上传，并对接郑州常用地图与物流接口。技术上建议先做模块化单体，验证业务后再拆微服务；上线频繁时采用灰度发布与 Feature Toggle，避免一次性全量风险。这是我在多次迭代中形成的习惯。

      最后，给几点实操建议：优先把派单与结算做成幂等可回溯的流程；监控要覆盖 SLO 级别的业务指标而不仅是 CPU/内存；代码契约与集成测试要早做。未来可以考虑把调度算法逐步替换为在线学习优化，但在本地区化场景下，增量改进往往比完全重构更划算。