第一次接到郑州本地婚庆行业的产品需求时，痛点很直接：供应方信息割裂、档期冲突频发、合同与支付流程不透明。于是我和团队决定做一个“一站式筹备”平台，把场地、摄影、化妆、司仪、物料等环节串起来，覆盖咨询→比价→签约→交付。需求看似简单，落地细节却把人整懵；从项目一开始我就把可观测性与并发保障放在优先级。

      架构上我们采用微服务分层：Go 做核心业务服务（高并发路径、事务处理），用 gRPC 做服务间通信；外部 API 用 REST/JSON；搜索与筛选交给 Elasticsearch，主数据放在 Postgres（JSONB 存一些供应商可变属性）。选这些技术不是为了潮流，而是因为它们能把复杂查询与强一致性各自放到擅长的存储层。实践里我常用 Postgres range 类型来做档期冲突检测，配合乐观锁与 Redis 分布式锁处理抢单场景，减少死锁概率——这是反复调试的经验。

      客户端采用 Vue 3 + TypeScript 打管理后台，移动端选 Flutter 一套代码覆盖 Android/iOS，小程序保留原生方案以便接入微信生态。支付接入了微信与支付宝，遇到的坑不少：比如商户证书、异步通知幂等需要在网关层做幂等键，退款流程要把重试与状态机拆成幂等步骤。实时沟通用 WebSocket 做长连接，失败回退到消息队列，再异步写入聊天历史；这一点在现场协调时非常关键。

      媒体资产管理的复杂度常被低估。我们用 S3 兼容对象存储，边缘 CDN，后台异步用 FFmpeg 做转码与缩略图，视频采用 HLS 切片以兼顾带宽。数据层面，我做了定期的去重与版本管理策略，避免供应商上传重复素材拖垮存储。日历与约会调度则用事件溢出检测和物料依赖图，必要时把计算下沉到数据库视图以提升查询效率。

      运维上走容器化与 CI/CD：Docker + Kubernetes（Helm 部署），Prometheus+Grafana 做监控，ELK 聚合日志，Jaeger 做调用链。安全上以 OAuth2/JWT 做鉴权，外加接口限流与文件扫描。经验是：不要一开始就追全功能，先把交易链路稳定、可观测、可回滚；再做体验细节。未来我会在指标驱动下逐步细化推荐与自动排期规则，但首要是把基础做到可控。