电商商品类不应强制继承抽象基类，而应通过接口约束核心业务方法；属性命名无需与数据库字段一致，应通过getter方法封装展示逻辑；价格和库存须用整数存储以防精度问题；平台数据映射应交由独立PlatformMapper类处理。
商品类该不该继承抽象基类
实战中多数电商项目不强制要求商品类继承抽象基类，除非你明确要统一管理多类型商品（如实体商品、虚拟卡密、服务类商品）。强行套用 abstract class ProductBase 会增加耦合，反而让增删字段、适配新渠道（比如淘宝API返回结构突变）更麻烦。真正需要的是接口约束，比如定义 ProductInterface 强制实现 getPrice()、isInStock() 这类业务方法，而不是把数据库字段或JSON序列化逻辑塞进父类。
属性命名要不要跟数据库字段完全一致
不要。比如数据库字段叫 goods_sn，类里直接暴露 $goods_sn 会导致模板层或API输出时反复写 htmlspecialchars($product->goods_sn)，既冗余又易漏。更合理的做法是：内部用 $sn 存储，提供 getSn() 方法做转义或格式化；库存字段用 $stock，但 getStockDisplay() 可返回“仅剩3件”这类前端友好字符串。这样业务逻辑和展示逻辑分离，改UI文案不用动模型层。
价格和库存该不该用整数存储
价格必须用整数（单位：分），库存也建议用整数。浮点数在PHP中做运算可能产生精度误差，比如 0.1 + 0.2 === 0.3 返回 false，订单金额校验会出问题。实战中见过因 float 类型价格参与优惠计算，导致支付差0.01元而触发风控拦截。库存同理，避免用 1.0 或 "5" 这类弱类型值，构造时就强制 (int)$data['stock']，并在 setStock() 中加类型断言。
怎么处理淘宝/拼多多等平台的商品数据映射
别在商品类里硬编码平台字段。用一个独立的 PlatformMapper 类负责转换：接收原始API响应数组，按平台标识（taobao、pinduoduo）调用对应规则，输出标准化数组，再由商品类的 fromArray() 构造。这样当拼多多某天把 min_group_price 改成 group_min_price，你只改 mapper 里的一个键名，不影响商品核心逻辑。容易踩的坑是把平台字段直接赋给 $this->min_group_price —— 一旦多平台接入，类属性会爆炸式增长，且无法静态分析。
立即学习“PHP免费学习笔记（深入）”；
封装商品类真正的难点不在语法，而在判断哪些状态该由类自己维护（比如库存是否可售），哪些该交给外部协调（比如跨仓调拨后的实时库存同步）。后者往往需要配合消息队列或缓存失效策略，不是加个 private 就能解决的。
