项目最开始源于一次进村调研：农户拍了一堆菜照，发到多个微信群，订单零散、商品描述不一致，流量难聚合。做技术的人往往先想架构，但我选择从数据规范入手——定义SKU模板、图片质量标准和可机读的溯源字段。实践告诉我，规范比花哨功能更能立刻带来成交。

      技术栈落地上，我选用TypeScript + Koa做后端，React Native做移动端，PostgreSQL存储核心业务数据，Redis做热点缓存，Elasticsearch负责检索。选择Postgres并非情绪性偏好：pg_trgm扩展对模糊匹配效果好，JSONB便于迭代SKU扩展。那次解决模糊搜索慢的问题，就是靠在name字段上建gin_trgm索引，响应时间从500ms降到30ms。

      商品图片是关键。为应对农村网络波动，我在客户端做渐进式压缩，首选WebP格式并落地到MinIO，上传走分片并支持断点续传。服务端用图片哈希检测重复，结合S3签名上传避免二次代理。记得一次批量上图卡死，排查靠wireshark和nginx日志发现是Keep-Alive配置不当，改写后并发上传稳定了。

      订单链路采用异步化：RabbitMQ做订单队列，消费端分拆支付、库存与通知三条流。遇到分布式事务问题，我避免全局事务，转用状态机+幂等设计，消息里携带幂等ID。遇到库存竞态，实践证明乐观锁结合小粒度重试，比悲观锁吞吐要高很多。

      运维与部署方面，Docker镜像分层优化，Kubernetes在边缘节点做灰度部署，GitLab CI实现流水线。监控用Prometheus＋Grafana，错误用Sentry。曾因数据库连接池默认太小导致高峰抛错，排查到Node池设置和Pg max_connections不匹配，调整后系统平稳过爆单。

      功能上，我把重点放在帮助农户“可展示与可买单”两点：一是标准化商品页模版，二是对接微信/支付宝直连支付并出具电子发票。业务对接第三方冷链物流时，遇到接口不稳定，就用本地缓存策略+重试队列来削峰，经验显示短重试间隔比无限重试更容易收敛故障。

      总结两点实操建议：把可观测性放在设计初期，别等问题发生再补监控；与真实农户做快速迭代，数据规范会比任何新功能更先带来收入。未来可以把轻量级的供需预测放到边缘设备，减少网络依赖，但前提是先把基础链路做稳。