LikeShop 的订单表 ls_order 上有 admin_remark（商家备注）字段，订单详情页可以编辑，批量备注的原生能力并不存在。审单人员每天的工作是：打开待发货列表，逐单点进去看收货地址、看商品、看买家留言，判断“这单要不要先联系客户”“这单是不是刷单”“这单要不要拆开发”，然后把判断结果手写进备注框。这套流程的问题不在“备注”本身，而在判断和记录是同一个动作。审单员的判断依据是地址

LikeShop 本身是有商品采集功能的。官方说明里写得很清楚：使用前需要购买采集次数套餐，支持一键采集淘宝、天猫、京东、1688，采集的是基础数据，并且明确提醒“最好自行编辑完善再上架”。后台存在两个采集入口，其中一个依赖 99api 接口，不配置就采不了。这说明原生的“采集”解决的是“把外部商品的基础字段拉进来”，但它没有解决采集之后的重话：规格层面：外部平台返回的SKU 规格是源平台的自由文

LikeShop 多商户标准版的功能表里，“商家PC管理后台”是明确存在的，标注“可自适应大小屏幕”，商家入驻审核通过后自动开通独立商家后台，可以上架商品、设置秒杀拼团，平台统一结算后由商家提现。订单管理覆盖待支付、待发货、待收货、已完成、已关闭五个状态，基础的浏览和单条操作是通的。但原生商家 PC 后台的工作方式是“目录式”的：左侧菜单 → 进入商品列表 → 翻页查找 → 逐条操作。它没有工作台

LikeShop 多商户版的结算模型是平台统一收款、按“商家维度”的费率和扣减平台交易服务费，再结算给商家。官方文档给出的对账结算公式为：已结算入账金额 = 已结算营业额 - 已结算分销佣金金额 - （(已结算营业额 - 已结算分销佣金金额) x 平台交易服务费）这个公式的落点是一个商家级的聚合金额。平台交易服务费虽然可以在商家管理按“主营类目”设置不同的百分比，但结算时是按商家当前的整体费率一次

LikeShop 的营销模块采用插件化、模块化的开发思路，所有营销玩法都做到业务轻耦合、代码轻耦合，便于后续扩展。营销逻辑不直接操作订单，而是通过规则校验 + 价格计算的方式接入主交易链路， 中预留了营销计算的方法入口。这套扩展模型对优惠券、拼团、秒杀这类“状态相对静态、决策一次完成”的活动是够用的。但红包雨的运行特征和它们完全不同。红包雨是“瞬时高并发 + 概率发放 + 多类型资金/权益出账”的

LikeShop 原生的会员体系是免费成长值模型。 记录用户当前等级， 表通过 、、、 定义升级条件，消费和签到积累成长值后自动升级。等级权益通过 数组下发，原生支持购物折扣、全场免邮、会员优惠券、专属客服四类权益。这套模型解决的是“消费越多、等级越高、权益越多”的问题，但没有任何“付费购买会员身份”的入口。没有会员卡商品，没有订阅周期，没有自动续费，没有“到期降级”的概念。用户在 上的等级只

LikeShop 原生的在线客服配置里，service_type 区分“人工客服”和“在线客服”，online_type 支持“第三方 H5 客服”，并通过 h5_url 字段挂载外部客服页面。这意味着商城侧的“企业客服”入口，本质上是一个跳转动作：用户点击客服按钮，跳到企业客服的 H5 链接或小程序路径，会话发生在企业微信侧，商城系统不感知消息内容、保存会话记录、不关联用户身份。LikeShop

LikeShop 原生的发票功能是“用户申请 + 商家手工处理”的轻台账模式。用户在结算页或订单详情页勾选开票，填写发票类型（增值税普通发票/专用发票）、抬头、税号等信息，提交开票申请。商家在后台“发票管理”中看到申请，手工开具（上传 PDF 或填写发票代码、号码），然后回填到系统。商家后台“经营设置”中有发票开关，关闭后结算页不显示开票入口。这条链路能“用”，但没有任何自动化：没有对接税务开票系

先把事情说清楚。LikeShop 单商户高级版确实有“供应商管理”菜单，平台管理可以输入供应商名称搜索查询，点击新增供应商，填写供应商编号、名称、分类、联系人、手机、座机、邮箱、所属地区、详细地址、银行账号、开户银行、持卡人姓名、税务登记号、排序等信息，并对供应商做编辑、删除。看起来该有的字段都有，但它的核心用途只有一句话：商家发布商品时可以选择供货商，方便货源管理，且供货商目前仅限后台管理员可查

LikeShop 多商户版原生提现链路很清晰：商家在后台“提现账号”李添加收款账号 → 对账结算后待结算营业额转为已结算 → 在财务中心点击提现 → 平台人工审核 → 人工手动转账。官方文档明确标注“多商户暂未做分账功能，需要人工手动转账”。在这个链路里，有两个硬约束直接对应本次二开的核心方向：第一，手续费是单一费率，不是阶梯。原生提现配置里只有一个 withdraw_service_charge

LikeShop 的原生支付是一次性结清模型。ls_order_pay_status 只有“未支付/已支付”两态，支付成功后订单直接进入待发货，库存扣减、积分发放、分销绑定全部在 OrderLogic::paySuccess()中一次性完成。这套模型假设“钱一次付完、货一次发出”，没有为“钱分几次付、订单跨时间履约”留出任何中间态。分期支付和预售、混合支付都不同。预售是“定金锁资格、尾款定成交”，

LikeShop 的原生支付是单通道模型；一次支付回调的链路是 PayController 接收回调 → PayLogic 验签和订单校验 → PayService 封装渠道 SDK → OrderLogic::paySuccess()执行状态流转、库存扣减和流水写入，核心操作在同一事务中完成；订单表上的 pay_status 是一个布尔式的状态：0 未支付，1 已支付；没有“部分支付”“组合支付

LikeShop 原生确实有“商品限购”的功能，单商户高级版 v2.3.0 更新记录中明确写着“商品增加限购功能”；但这个能力是商品级的、静态的：运营在商品编辑页设置“每人限购 N 件”，系统在用户下单时校验该用户历史已购数量；它解决的是“一个人买太多”的问题，但对“一群人用不同账号、同一设备、同一地址集中下单”几乎无效——每个账号的购买量都在限购范围内，风控形同虚设。原生系统没有同 IP 限购、

LikeShop 原生后台确实有批量发货的功能，但它的形态是Excel 文件导入，操作路径为“订单列表 → 批量发货 → 选择文件 → 立即导入”，且有两个硬约束：只适用于待发货订单，单次最多导入 2000 条；除此之外，商品批量上下架、批量改价、批量改库存、批量改分类、订单批量备注、批量改地址，原生后台都不具备。这意味着二开的核心不是“加几个勾选框”，而是建立一套统一的批量任务框架，让商品侧和订

LikeShop 的签到数据以“连续天数”为核心组织；签到列表接口 /shopapi/sign/lists 返回的 lists 数组中，每一项包含 day（如“1天”“2天”）、integral（赠送积分）和 is_sign（对应天数是否已签到），用户侧同时返回 continuous_days（当前连续签到天数）和 today_sign（今日是否已签到）；连续签到规则的编辑接口参数为 days（连

LikeShop 原生功能清单中确实列有“足迹气泡”和“商品收藏”，足迹气泡覆盖访问商城、浏览商品、加入购物车、领取优惠券、下单支付等场景；但仔细看会发现，足迹气泡是一个氛围型轻提示组件，它不落库、不按用户维度持久化，更不参与任何推荐计算；商城功能同样停留在“商品收藏”的开关状态，没有分类、没有备注、没有行为权重。这意味着二开的核心不是“加一个页面”，而是把行为数据从展示层下沉到数据层：足迹要变成

LikeShop 的 ls_goods 表通过 goods_type 字段区分商品类型，原生支持实物商品和虚拟商品两类；虚拟商品不参与物流发货，订单完成后直接进入“已完成”状态，无需填写收货地址和物流单号；但原生的虚拟商品仅支持“一次性交付”模式——用户购买后系统交付一个固定的虚拟内容（如课程链接、网盘地址），没有卡券化、兑换码化、有效期管理和核销记录的能力。缺口一：无卡券实体与库存管理。原生的虚

LikeShop 的 ls_after_sale 表已经为退货物流预留了字段：express_name（快递公司名称）、invoice_no（快递单号）、express_time（买家退货时间）、confirm_take_time（确认收货时间）；子状态也覆盖了“卖家已同意，等待买家发货”(12)、“买家已发货，等待卖家收货”(13)、“卖家已收货，等待卖家处理”(14) 等逆向节点。但从操作链路

LikeShop 的商品体系采用经典的主表（SPU）+ 规格表 + SKU 表三层结构，ls_goods 存储商品基础信息，ls_goods_item 存储规格组合的价格与库存；每个 SKU 通过 spec_value_ids 唯一标识，拥有独立的 sell_price 和 stock。购物车表 ls_cart 记录与加入购物车的商品，通过 goods_id 和 item_id 定位具体的 SKU

LikeShop 的分销体系以 ls_user 表的上下级关系字段为核心；每个用户通过 invite_user_id （或类似字段）记录其直接上级，三级分销的佣金计算依赖这条链路的逐级向上查找。分销关系的绑定逻辑为：A 分享商品或邀请链接给 B，B 通过链接注册或首次绑定后，A 成为 B 的上级。如果 A 是 B 的上级，B 是 C 的上级，那么 B 是 C 的一级分销，A 是 C 的二级分销；C