做这个郑州本地盲盒小程序，是因商户抱怨线下流量难以触达而起。项目从需求会谈开始，我就质疑：核心是玩法吸引人，还是系统能扛并发？最终定调为“玩法+工程双保险”。

      前端选用小程序原生框架配合 canvas 与 lottie 动效，资源放 CDN 做客户端缓存。遇到的问题是 Android 卡顿，排查发现是大图解码阻塞主线程，于是把关键帧拆为 sprite，降低单帧像素，体验明显好转——这是实操里容易忽视的小成本优化。

      后端用 TypeScript + Koa，持久层 MySQL，热数据和频率控制交给 Redis。抽奖逻辑放在服务端计算，采用 HMAC-SHA256 的 commit-reveal 思路，既保证可验证性，也方便后续审计。并发时的库存扣减用 Redis Lua 原子脚本，避免超卖；出现异步失败则通过 RabbitMQ 进行补偿型重试。

      支付和发券是复杂点。微信支付回调实现幂等设计：用 out_trade_no 做唯一键，数据库加唯一索引，回调前先做 Redis 请求去重，幂等校验通过才走事务创建订单。曾遇到过回调丢包，定位到网关超时后重试导致重复回调，改成短链路确认后异步补偿后问题缓解。

      监控与压测不该只是上线前的仪式。我们用 Artillery 做阶段性压测，监测 95/99 分位延迟，配合 Prometheus + Grafana 实时观察 Redis 命中率和队列积压。结果告诉我，盲盒活动的痛点在于短时间内的爆发，弹性伸缩策略必须调到位。

      营销层面，玩法设计上我倾向“低门槛+稀缺激励”：免费抽奖次数与付费提速并存，优先发放可兑换本地店铺折扣券。埋点细化到每一步，事件通过 Kafka 入湖，相关转化率可量化。实操经验是，数据越细，运营越能做精细化投放。

      开发总结：技术细节决定体验，工程策略决定能否承载营销成功。未来我会把更多精力放在可观测性与灰度策略上，慢慢把不确定性降到可控范围内。