去年帮一个做手工皮具的物网朋友搭了个购物App，上线三个月，站开日活卡在两百人上下。物网我翻了下后台数据，站开发现用户平均停留时间只有47秒——点开首页，物网划两下，站开退出。物网问题不在商品，站开在首页那个轮播图。物网三张图轮播，站开每张停留3秒，物网用户还没看清第二张的站开折扣信息，第一张已经切走了。物网后来把轮播改成静态三栏入口，站开停留时间跳到2分12秒，物网下单率翻了近一倍。这事让我意识到，购物App的首页不是展示橱窗，是货架通道，用户要的是“一眼找到”，不是“慢慢欣赏”。
商品列表页的加载速度比UI美观重要得多。测试过一款日活百万的电商App，把列表页图片从高清换成WebP格式，体积压缩60%，首屏渲染时间从1.8秒降到0.9秒。别小看这0.9秒，转化率差了7个百分点。用户滑动列表时，每张卡片必须在一帧内完成布局，否则就会掉帧。掉帧带来的卡顿感，比图片模糊更劝退。我习惯在开发阶段用Chrome的Performance面板录屏，盯着FPS曲线看，低于55就回去改代码。
购物车逻辑是最容易埋坑的地方。有个做零食的客户，购物车支持“满199减30”，但用户修改数量时，优惠计算没实时更新。用户把数量从5改成4，总价降到189，优惠没减，结算时突然多出30块。这种体验直接导致客诉。后来改成每次数量变更都触发一次价格重算，用防抖函数控制频率，300毫秒内只算一次。结算页的地址选择器也折腾过——最初用三级联动下拉，用户要滚三次。改成搜索+最近使用地址置顶，填写时间从45秒压到12秒。
支付环节的容错设计比支付方式数量更关键。接微信支付时，遇到过用户点支付后网络中断，订单状态卡在“待支付”。用户以为没付成功，重新下单，结果付了两笔。后来在支付回调里加了幂等校验，同一订单号重复回调只处理一次。同时前端轮询订单状态，超过15秒未更新就弹窗提示“支付结果确认中，请勿重复操作”。这个弹窗文案改过三版，最初写“支付失败”，用户恐慌；改成“网络延迟”，用户茫然；最后用“确认中”，配合一个转圈动画，客诉降了八成。
后台管理端常被忽视，但它决定运营效率。给一个卖茶叶的团队做后台，最初商品上架要填28个字段，运营小姑娘录一个商品花6分钟。后来把字段分组折叠，必填项缩到9个，非必填的规格、产地、冲泡建议放到“高级设置”里。上架时间降到90秒。订单导出功能也改过——原来导出Excel要等30秒，改成流式导出，边查边写，3秒出文件。运营不用干等，可以继续处理其他订单。
数据埋点别贪多。见过一个App埋了200多个事件，结果关键路径的漏斗分析反而看不清。我通常只盯四个节点：首页曝光、商品详情浏览、加入购物车、支付成功。每个节点带三个参数：来源页面、商品ID、用户ID。够用了。有次发现“加入购物车”到“支付成功”的转化率突然从38%掉到22%，查下来是购物车页的“去结算”按钮被一个运营活动弹窗遮住了。埋点数据不会说谎，但得知道看哪里。
购物App开发没有银弹。每个功能点背后都是具体的人、具体的操作路径、具体的等待时间。把轮播图换成静态入口，把图片压小，把购物车计算做实时，把支付回调做幂等——这些琐碎的决定堆起来，才撑得住一个能用的购物车。技术选型反而不是最难的，React Native也好，Flutter也罢，甚至原生开发，都能跑。难的是愿不愿意蹲下来，看用户到底在哪一步皱眉头。