说起做电商App，很多人脑子里第一反应是“前端炫不炫，后端稳不稳”，但真正坑死人的，往往不是大场面扛不住，而是那些藏在细节里的“我以为”和“你以为”。
我是老李，一个在电商圈摸爬滚打八年的“老兵”。今天不聊高大上的架构，就聊聊我们团队在做一个轻量级电商App时，从后端接口设计到Android端数据解析，到底踩了哪些让人想砸键盘的坑，以及最后怎么爬出来的。
一、 后端接口设计的“隐形地雷”
1.1 商品主图字段：你以为只有一张图？
坑点：
一开始设计商品接口，我们觉得商品图片挺简单，直接放一个 imageUrl 字符串得了。结果测试一上架，运营说：“老李，SKU图片怎么不一样？” 我们才意识到，商品图、SKU变体图、详情页图、推广图，根本不是一个概念。
真实案例： 我们有一个连衣裙商品，主图是模特穿红色，但用户点击“选颜色”切换到蓝色时，图片没变，还报错了。
避坑指南： 接口设计必须考虑多维度图片，并且图片要有优先级和尺寸规范。
// ❌ 错误示范：简单粗暴
"product": {
"id": 1001,
"name": "连衣裙",
"image": "http://cdn.example.com/img1.jpg"
}
// ✅ 正确姿势：结构清晰，包含多种图片类型
"product": {
"id": 1001,
"name": "连衣裙",
"images": {
"main": "http://cdn.example.com/img1_main.jpg", // 主图，正方形，建议800x800
"skus": [ // SKU图片，key是skuId
{"skuId": "S001", "url": "http://cdn.example.com/img1_red.jpg"},
{"skuId": "S002", "url": "http://cdn.example.com/img1_blue.jpg"}
],
"detail": "http://cdn.example.com/img1_detail.jpg" // 详情长图
},
"price": {
"original": 299.00,
"current": 199.00,
"currency": "CNY"
}
}
关键点：
- 所有URL必须https，避免混合内容问题。
- 图片要支持缩略图和原图两种格式，Android端列表用缩略图，详情页用原图，节省流量。
- SKU图片一定要和
skuId绑定，不能只靠顺序对应，顺序乱了就是灾难。
1.2 价格字段：用整型还是浮点？
坑点：
很多新手程序员喜欢用 float 或 double 存价格，结果出现 199.00 显示成 199.000000000001 的尴尬情况。更有甚者，直接存字符串 "199.00"，但不同语言解析方式不一致，导致前端显示错误。
真实案例：
一次大促活动中，某个商品原价999.00，折扣后价格算出来是888.9999999999999，用户支付时金额对不上，客服被打爆。
避坑指南： 金额永远用整型（分）传输，前端再展示。
// Android端接收
public class Product {
public long originalPrice; // 单位：分
public long currentPrice; // 单位：分
}
// 展示时转换
String priceText = String.format("¥%.2f", currentPrice / 100.0);
关键点：
- 后端存储用
DECIMAL或BIGINT（分），不要用FLOAT。 - 接口统一返回
long类型金额，避免精度丢失。 - 前端展示时再做除法，且必须保留两位小数。
1.3 分页接口：总数到底要不要返回？
坑点： 有的接口只返回当前页数据，有的返回总数，有的返回“是否有下一页”。Android端为了做“上拉加载更多”，需要判断是否还有更多数据。如果后端不返回总数，前端只能靠“如果当前页数据少于每页数量，则没有下一页”来判断，这在数据动态变化时（比如有人删了商品）会出错。
真实案例： 用户翻到第10页，最后一共只有5条数据，但后端依然返回了5条，前端判断“还有下一页”，用户继续加载，结果空转，体验极差。
避坑指南： 分页接口必须返回总数，同时返回当前页数据和是否还有下一页的明确标识。
{
"code": 200,
"data": {
"list": [...], // 当前页商品列表
"total": 150, // 总商品数，用于前端计算总页数
"page": 10,
"pageSize": 10,
"hasMore": false // 明确告知是否还有下一页，避免猜测
}
}
关键点：
total用于显示“共XXX件商品”。hasMore用于控制加载更多按钮的显示/隐藏。- 不要让用户自己去算，直接给明确答案。
二、 Android端数据解析的“坑中之坑”
2.1 JSON解析：Gson vs Jackson，谁更靠谱？
坑点：
我们一开始用Gson，因为配置简单。但遇到后端字段类型不匹配时，Gson会直接报错，导致整个页面崩溃。比如后端返回"price": "199.00"（字符串），而我们的模型是long price，Gson解析失败。
真实案例： 一次版本更新后，后端改了某个接口的返回格式，把整数ID改成了字符串ID（可能是超长ID），Android端直接Crash，用户反馈炸了。
避坑指南：
使用Gson时，务必配置setLenient()和自定义TypeAdapterFactory，或者改用Jackson，它对类型不匹配更宽容。
// Gson 容错配置
Gson gson = new GsonBuilder()
.setLenient()
.disableHtmlEscaping()
.create();
// 自定义适配器，处理字符串ID转Long
public class StringIdToLongAdapterFactory implements TypeAdapterFactory {
@Override
public <T> TypeAdapter<T> create(Gson gson, TypeToken<T> type) {
Class<T> rawType = (Class<T>) type.getRawType();
if (!rawType.equals(Long.class) && !rawType.equals(long.class)) {
return null;
}
@SuppressWarnings("unchecked")
TypeAdapter<T> longAdapter = (TypeAdapter<T>) gson.getAdapter(Long.class);
return new TypeAdapter<T>() {
@Override
public void write(JsonWriter out, T value) throws IOException {
longAdapter.write(out, value);
}
@Override
public T read(JsonReader in) throws IOException {
if (in.peek() == JsonToken.NULL) {
in.nextNull();
return null;
}
// 如果是字符串，尝试转Long
String str = in.nextString();
try {
return (T) Long.valueOf(str);
} catch (NumberFormatException e) {
return null; // 或者返回默认值0
}
}
};
}
}
关键点：
- 网络请求失败或数据异常时，要有兜底策略，不能直接Crash。
- 使用
try-catch包裹解析过程，记录日志，方便排查。 - 考虑使用
Moshi，它比Gson更现代，性能更好，且对异常处理更友好。
2.2 图片加载：内存泄漏与OOM
坑点：
电商App图片多，我们一开始用BitmapFactory.decodeStream()直接加载，结果滑动列表时频繁OOM（内存溢出），App闪退。
真实案例： 商品列表有20个商品，每个商品4张图片，用户快速滑动，内存瞬间飙升到500MB，手机发烫，App卡死。
避坑指南： 必须使用图片加载库（如Glide或Coil），并配置缓存策略和内存优化。
// 使用Glide加载商品图片
Glide.with(context)
.load(imageUrl)
.placeholder(R.drawable.placeholder) // 占位图，提升体验
.error(R.drawable.error) // 错误图
.override(200, 200) // 限制尺寸，避免加载大图
.centerCrop() // 裁剪适配，避免变形
.into(imageView)
关键点：
- 永远不要手动管理Bitmap的生命周期，交给Glide/Coil。
- 列表中的图片务必设置
override()，限制分辨率，小图别加载原图。 - 开启Glide的磁盘缓存和内存缓存，减少重复加载。
2.3 数据缓存：网络断了怎么办？
坑点： 用户没网时，App直接显示空白，体验极差。我们后来加了缓存，但缓存策略混乱，导致用户看到的信息不是最新的。
真实案例： 商品价格改了，但用户本地缓存的还是旧价格，下单时才发现价格不对，投诉不断。
避坑指南： 采用“网络优先，缓存兜底”策略，并设置缓存过期时间。
// 伪代码逻辑
public class ProductRepository {
public LiveData<Product> getProduct(long productId) {
// 1. 先从本地数据库读取缓存
Product cachedProduct = productDao.getById(productId);
// 2. 返回缓存数据（即使网络失败，用户也能看到旧数据）
MutableLiveData<Product> liveData = new MutableLiveData<>();
if (cachedProduct != null) {
liveData.setValue(cachedProduct);
}
// 3. 异步请求网络，更新数据
api.getProduct(productId).enqueue(new Callback<Product>() {
@Override
public void onResponse(Call<Product> call, Response<Product> response) {
if (response.isSuccessful()) {
Product freshProduct = response.body();
// 更新数据库
productDao.insert(freshProduct);
// 更新UI
liveData.setValue(freshProduct);
} else {
// 网络失败，保持缓存数据不变
if (cachedProduct == null) {
liveData.setValue(null); // 显示加载失败
}
}
}
});
return liveData;
}
}
关键点：
- 缓存要有过期时间（如1小时），避免数据长期不一致。
- 关键数据（如价格、库存）建议每次拉取，或设置较短过期时间。
- 使用Room数据库做本地缓存，结合LiveData或StateFlow做数据驱动UI更新。
三、 前后端联调的“沟通陷阱”
3.1 字段命名不一致
坑点：
后端用snake_case（product_id），前端用camelCase（productId），对接时一脸懵逼。
真实案例：
联调时，前端一直说“字段为空”，后端说“我返回了”，结果发现是命名不一致，前端在找productId，后端返回的是product_id。
避坑指南：
统一使用camelCase，并在API文档中明确标注。
// API文档示例
{
"endpoint": "/api/product/detail",
"method": "GET",
"response": {
"productId": "Long, 商品ID",
"productName": "String, 商品名称",
"currentPrice": "Long, 当前价格（分）"
}
}
关键点：
- 使用Swagger或YApi等工具自动生成文档，避免人工维护错误。
- 前后端约定好命名规范，并写入项目规范文档。
3.2 错误码不统一
坑点：
有的接口错误码是字符串（"ERROR"），有的是数字（404），有的是对象（{"code": "INVALID_PARAM"}），前端解析时头疼。
真实案例： 前端写了三个错误码处理分支，结果后端改了一个接口，错误码格式变了，导致某个错误没被捕获，App表现异常。
避坑指南： 制定统一的错误码规范，并使用枚举或常量类。
// 统一错误码定义
public class ErrorCode {
public static final int SUCCESS = 200;
public static final int INVALID_PARAM = 1001;
public static final int PRODUCT_NOT_FOUND = 1002;
public static final int INSUFFICIENT_STOCK = 1003;
public static final int NETWORK_ERROR = 9999;
}
// 响应体统一结构
public class ApiResponse<T> {
private int code;
private String message;
private T data;
}
关键点：
- 错误码要唯一且有意义，方便前端和用户理解。
- 错误信息要友好，不要直接把后端异常抛给用户（如“NullPointerException”）。
- 前端统一处理错误，不要每个页面都写一堆if-else。
四、 老李的“血泪”总结
- 接口设计要“向前兼容”：不要删字段，要加字段。万一前端版本低，不会崩。
- 数据解析要“宽容”：后端尽量返回完整数据，前端解析时要考虑字段缺失、类型不匹配的情况。
- 图片加载要“克制”：别加载原图，别手动管理Bitmap，用库。
- 缓存策略要“清晰”：什么数据缓存，缓存多久，都要有明确约定。
- 沟通要“书面化”：所有接口变更，必须走文档更新，别靠嘴说。
电商App开发，坑多但可防。关键是流程规范和细节把控。希望老李的这些踩坑经验，能帮到正在路上的你们。
如果你们也在做电商App，欢迎评论区交流，看看还有没有更深的坑！