CRMEB Pro 商品上下架二开避坑：一个开关为什么会牵动审核、购物车和活动商品？

摘要

商品上下架看起来只是一个is_show开关，但在商城系统里，它会影响购物车是否可购买、移动端是否展示、商品推荐位是否出现、活动商品是否还能继续卖、批量操作是否需要走队列，甚至会和商品审核、强制下架、自动上架时间产生联动。

CRMEB Pro 当前商品模块里，单商品上下架、批量上下架、商品审核、批量审核和活动检测都有独立入口。二开时如果只改商品表的is_show，很容易出现后台已下架但购物车还能买、审核拒绝后移动端还显示、批量全选操作超时等问题。

这篇从源码入口出发，整理商品状态二开的关键边界。

一、上下架不是只改商品主表

后台路由在crmeb_pro/route/admin.php：

PUT product/product/set_show/:id/:is_show 单商品上下架 PUT product/product/product_show 批量上架 PUT product/product/product_unshow 批量下架 POST product/product/set_verify/:id 商品审核 POST product/product/batch_verify 商品批量审核 GET product/product/check_activity/:id 检测商品是否有活动开启

前端接口在crmeb_pro_admin/src/api/product.js：

PostgoodsIsShow 单商品上下架 productShowApi 批量上架 productUnshowApi 批量下架 productReviewApi 商品审核 productBatchVerifyApi 批量审核 checkActivityApi 检测活动

真正的状态处理在：

crmeb_pro/app/services/product/product/StoreProductServices.php setShow() verify() batchVerify() checkActivity()

也就是说，状态二开要看 Controller、Services、购物车、活动和缓存，而不是只看字段。

二、单商品上下架会同步购物车状态

后台单商品上下架入口是：

StoreProduct::set_show()

它会先做供应商商品权限校验，再调用：

StoreProductServices::setShow([$id], $is_show)

服务层里会处理几件事：

1. 上架时检查回收站商品不能直接上架 2. 批量更新购物车商品 status 3. 更新商品 is_show 4. 手动上架时清空 auto_off_time 5. 同步商品关联关系展示状态 6. 触发 product.status 事件 7. 清理商品缓存

这说明商品是否可买，不是只看商品表。购物车里也有状态字段，如果商品下架后不更新购物车，用户可能还能从购物车继续下单。

二开建议：

商品下架必须同步购物车不可用 商品恢复上架要确认是否允许恢复购物车 回收站商品不能绕过恢复流程直接上架 状态变化后要清缓存并触发事件

三、批量上下架分单页和全选两种处理

product_show()和product_unshow()都会接收：

ids 当前选中的商品 ID all 是否全选 where 当前筛选条件

如果all == 0，说明只处理当前勾选商品，Controller 会直接调用setShow()。

如果all == 1，说明用户点的是“所有页全选”，这时不会把所有 ID 一次性塞进请求，而是把筛选条件交给队列：

QueueServices::setQueueData() BatchHandleJob::dispatch()

这点很适合大商品量场景。二开时如果新增批量状态，不要直接把所有商品 ID 查出来在一次请求里循环更新。更稳的做法是：

当前页少量商品：同步处理 所有页或大批量商品：进入队列 队列按筛选条件分批取 ID 操作完成后清缓存和记录日志

这样后台不会因为一次批量操作卡死。

四、审核和上下架是两套状态，不能混成一个字段

商品审核入口是：

StoreProduct::setVerify() StoreProduct::batchVerify()

服务层方法是：

StoreProductServices::verify() StoreProductServices::batchVerify()

当前审核逻辑会处理：

is_verify 审核状态 refusal 拒绝原因 is_show 是否展示 auto_on_time 自动上架时间

如果设置了自动上架时间，服务层会把商品先设为未上架：

auto_on_time 有值时，is_show = 0

审核时还会把购物车里该商品的可用状态更新为不可用。这个处理很重要，因为审核失败、强制下架、等待自动上架，都不应该继续允许用户从购物车购买。

二开时要分清：

is_show 控制商品是否展示/销售 is_verify 控制商品是否审核通过 is_del 控制是否进入回收站 auto_on_time / auto_off_time 控制定时上下架

不要用一个字段同时表示“审核失败”和“下架”，否则后续列表筛选、头部统计、运营处理都会乱。

五、活动商品下架要先检查活动关联

后台提供了检测活动的入口：

product/product/check_activity/:id

服务层checkActivity()会检查商品是否存在进行中的：

秒杀 砍价 拼团

如果仍有活动开启，会抛出“商品有活动开启，无法进行此操作”。

虽然当前setShow()中下架检测有注释保留，但这个能力仍然很关键。二开时如果要强制下架、批量下架、删除商品或修改 SKU，建议先确认活动关联。否则可能出现：

普通商品下架了，活动页还在卖 活动库存和普通库存不一致 用户从活动入口下单失败 售后退回库存找不到原商品状态

更稳的做法是把“是否允许下架”做成统一服务方法，批量下架、强制下架、删除商品都调用同一套检查。

六、供应商、门店、平台商品要做归属限制

商品状态接口里多处会调用类似权限校验：

checkSupplierProductAuth()

批量处理时，如果是供应商登录，还会把筛选条件改成：

type = 2 relation_id = 当前供应商 ID

商品批量操作服务里也会区分平台、门店、供应商归属：

type = 0 平台 type = 1 门店 type = 2 供应商

二开状态时不要只按商品 ID 更新。尤其是供应商后台、门店后台、平台后台共用商品表时，一定要先限定归属范围，再执行批量操作。

七、推荐的商品状态二开流程

1. 明确新增状态属于展示、审核、删除、定时还是活动控制 2. 后台按钮只提交状态意图，不直接写库 3. Controller 只做参数和权限校验 4. Services 统一处理购物车、活动、关联商品、事件和缓存 5. 单页操作同步处理，全选操作走队列 6. 移动端列表和详情接口同步过滤 is_show、is_verify、is_del 7. 记录操作日志或审核原因，便于运营追溯

商品状态越多，越需要控制入口。不要每个页面都写一份“上下架逻辑”。

八、关键代码/目录说明

crmeb_pro/route/admin.php 后台商品上下架、审核、批量审核、活动检测路由。 crmeb_pro_admin/src/api/product.js 后台前端商品状态相关接口封装。 crmeb_pro/app/controller/admin/v1/product/StoreProduct.php 商品后台 Controller，包含 set_show、product_show、product_unshow、batchVerify、check_activity。 crmeb_pro/app/services/product/product/StoreProductServices.php 商品服务，setShow 负责上下架联动，verify 和 batchVerify 负责审核联动。 crmeb_pro/app/services/product/product/StoreProductBatchProcessServices.php 商品批量操作服务，负责按筛选条件批量处理商品。 crmeb_pro/app/jobs/BatchHandleJob.php 批量上下架等任务的队列入口。

九、注意事项

• 不要直接更新is_show后就结束。
• 下架、审核拒绝、强制下架要考虑购物车状态。
• 回收站商品不能直接上架，应先恢复。
• 全选批量操作要走队列，不要一次请求循环所有商品。
• 活动中的商品下架、删规格、删除商品前要检查秒杀、砍价、拼团。
• 供应商和门店端必须限制商品归属，避免跨主体操作。
• 状态变化后要清理商品缓存，并考虑触发事件给搜索、推荐或统计模块。

标签建议

CRMEB CRMEB Pro 商品上下架 商品审核 二次开发 队列 商城系统