yii搭建商城后端接口核心在于分层清晰、逻辑解耦、兼顾性能与可维护性，围绕商品、订单、用户、支付四大主线，依托activerecord、restful路由、behavior、验证规则及扩展组件实现业务稳定。
Yii 搭建商城后端接口，核心在于分层清晰、逻辑解耦、兼顾性能与可维护性。不是堆功能，而是围绕商品、订单、用户、支付四大主线，用 Yii 的 ActiveRecord、RESTful 路由、行为（Behavior）、验证规则和扩展组件把业务稳住。
商品模块：用 AR + SearchModel 做高效查询与管理
商品表（product）需关联分类（category）、品牌（brand）、SKU（product_sku）。不要在控制器里写 JOIN 查询，而是通过 AR 关系定义：
- 在
Product模型中声明getCategory()、getDefaultSku()等关系方法 - 列表接口用
ProductSearch类继承ActiveDataProvider，支持按分类 ID、关键词、价格区间、上架状态筛选 - 详情接口查主商品 + 默认 SKU + 分类路径（用缓存预存 breadcrumb）
- 库存变更不直接改
stock字段，走ProductSku::decreaseStock($skuId, $num)方法，加数据库行锁或乐观锁防超卖
订单流程：状态机驱动 + 事务 + 异步补偿
订单（order）不是 CRUD，是状态流转。建议用 yii2-activerecord-state-behavior 或自定义状态字段（如 status）配合严格校验：
- 创建订单时开启事务：扣减库存 → 生成订单主表/子表 → 写入支付流水 → 发送下单成功事件
- 支付回调必须做幂等：用订单号 + 支付单号双唯一索引，回调中先查订单是否已支付成功，再更新状态
- 超时未支付自动关单：用 Yii 控制台命令（
yii order/close-expired）定时扫描，或接入 Redis 过期监听 + Lua 脚本触发 - 退款需同步调用第三方支付平台 API，并记录
refund_log表，失败时推入消息队列重试
用户与权限：RBAC + Token + 行级隔离
商城后台需区分管理员、运营、客服角色；APP/小程序接口则面向 C 端用户。Yii 自带 RBAC 可复用，但要注意：
- 前端传来的
access_token解析后，必须校验用户状态（是否禁用）、token 是否过期、是否绑定设备（可选） - 敏感操作（如修改手机号、删除地址）需二次验证（短信/密码），不能仅靠 token
- 用户数据接口（如收货地址列表）强制加
andWhere(['user_id' => \Yii::$app->user->id])，避免越权查看他人数据 - 后台接口用
authManager分配权限节点，如order/view、product/update，控制器中调用$this->checkAccess('order/view')
接口规范与稳定性：统一响应 + 日志 + 限流
对外接口不是写完就上线，得有“出厂标准”：
- 所有 JSON 接口继承统一基类
ApiController，统一包装结构：{ "code": 0, "msg": "ok", "data": [...] }，异常统一捕获InvalidParamException等并转为对应 code - 关键接口（如下单、支付）记录完整请求参数与响应结果到 ELK 或 MySQL
api_log表，保留 7 天 - 防刷：对登录、注册、提交订单等接口，用
yii2-redis实现 IP + 用户维度的滑动窗口限流（如 5 次/分钟） - 大字段（如商品描述）不在列表接口返回，详情页单独加载；图片地址统一走 CDN，后端只存相对路径
不复杂但容易忽略：每个接口上线前，用 Postman 做边界测试（空参、超长字符串、SQL 注入字符、负数金额），再跑一遍 PHPStan 级别 5 的静态分析。Yii 是利器，但业务稳不稳，取决于你怎么用它管住状态、锁住数据、兜住异常。
