简介：易优第三方商家（会员变商家）商城插件是一套面向易优CMS开发者和电商平台运营者的功能扩展组件，核心目标是将平台普通注册会员升级为具备独立店铺管理权限的商家，扩充电商平台的商品供给与交易服务。资源包共526个文件、压缩后约7.47MB，以js脚本（250个）、css样式（75个）、htm模板（63个）和php后端文件为主，另有png/gif图片、woff/ttf字体及sql数据库脚本等，涵盖前端界面渲染、后端业务交互与微信小程序适配等环节。压缩包内目录结构清晰，application目录包含控制器、模型与服务逻辑，template目录负责商家店铺及商品详情页面展示，weapp目录则支持微信小程序端同步管理，便于开发者按模块二次定制。目前已有135人学习下载，适合需要快速搭建会员转商家机制、完善多端口电商运营的中小平台及易优CMS二次开发学习者使用。

1. 会员变商家插件：把注册会员升级成入驻商家的完整链路

前阵子帮一位做内容站的朋友做商城改造，站点跑在易优系系统上，后台有一批积累了几年的注册会员，想开放商家入驻，让会员自己开店卖货。我最初搜到的方案大多要求重写商城模块，要么就得动会员主表结构，耦合太深，不敢往生产环境上放。直到翻出这份会员变商家商城插件，逻辑正好是“会员变商家”：不改动原会员登录流程，新增入驻申请、后台审核、店铺资料和商品发布权限，前后台闭环完整，实测一条链路走下来基本没翻车。适合手里有易优系商城、正打算开放多商家入驻的开发者；如果你是刚入行的新手，跟着下文部署也能一次跑通。这个插件解决的不只是“多一套后台”，而是存量会员如何平滑变成商家的数据结构和权限问题。

2. 插件结构：先理解会员身份切换与店铺数据的关系

2.1 会员表加字段：商家身份标记与审核状态

先说结论：会员变商家的关键不在“多了一张商家表”，而在于会员表上如何标记身份。这套插件的做法是在users表上直接扩充两个字段：一个管“是不是商家”，一个管“商家申请走到哪一步”。这样原会员登录流程不用动，订单、积分、优惠券这些既有模块也能继续读取会员主键，改造面最小。

ALTER TABLE `users` ADD COLUMN `is_merchant` TINYINT(1) NOT NULL DEFAULT 0 COMMENT '是否商家 0否 1是' AFTER `user_id`, ADD COLUMN `merchant_apply_status` TINYINT(1) NOT NULL DEFAULT 0 COMMENT '申请状态 0未申请 1审核中 2已通过 3已驳回' AFTER `is_merchant`;

这段SQL是插件安装脚本里的核心。is_merchant只用了TINYINT(1)，0和1两种取值已经能描述“普通会员”和“商家”两种角色；merchant_apply_status主要给后台审核列表用，提交申请后置1，审核通过置2，驳回置3。两个字段都放在user_id后面，只是方便数据库工具查看，对业务没有影响。

参数说明：如果你的站点是老库，执行之前记得先备份users表；字段类型不要用INT，TINYINT就够了，几十万会员的表加索引时存储压力也小。建议给这两个字段做一个联合索引，后台按申请状态筛选商家时会快很多。另外一个容易忽略的点：users表加了字段之后，所有读取会员信息的地方都要兼容这两个字段，否则商家在别的模块里会被当成普通会员处理，这个坑后面第5章会详细说。

2.2 入驻申请与审核：一份申请表串起状态机

会员点“成为商家”时并不直接改users表，而是先写入一张商家申请表。这样驳回留痕、审核留痕都有据可查，也方便后续做“申请被驳回后再次提交”的场景。插件里的常见流程是这样一段PHP逻辑：

public function applyMerchant($userId, $data) { // 1. 先查会员是否已经是商家 $user = M('users')->where('user_id', $userId)->find(); if ($user['is_merchant'] == 1) { return ['code' => 0, 'msg' => '你已经是商家，无需重复申请']; } // 2. 写入商家申请表，状态先置审核中 $applyId = M('merchant_apply')->add([ 'user_id' => $userId, 'shop_name' => trim($data['shop_name']), 'contact_name' => trim($data['contact_name']), 'contact_mobile' => trim($data['contact_mobile']), 'apply_status' => 1, 'create_time' => time(), ]); // 3. 把会员表申请状态同步成审核中 M('users')->where('user_id', $userId)->save(['merchant_apply_status' => 1]); return ['code' => 1, 'msg' => '申请成功，等待平台审核']; }

逻辑说明：第一步先查is_merchant，防止商家重复提交申请；第二步写入申请表并拿到apply_id；第三步回写会员表的申请状态，供个人中心显示“审核中”。这里有一个容易踩的点：申请表写入失败时不能再回写users表，建议把第三步放到事务里，不然会出现“会员申请状态是审核中，但申请表里没有记录”的脏数据。

参数说明：shop_name、contact_name、contact_mobile是入驻审核要呈现给对方的关键信息，提交前要过滤HTML标签和超长字符。apply_status的1/2/3三档状态在后台审核列表中直接映射成“待审/通过/驳回”，驳回时记录一下原因字段会更友好，不过插件自带版本里这个字段是可选的，二次开发时加上就行。

后台审核通过时，才真正把商家身份写进users表，并创建店铺记录：

public function passApply($applyId) { $apply = M('merchant_apply')->where('apply_id', $applyId)->find(); if (!$apply) { return ['code' => 0, 'msg' => '申请记录不存在']; } // 1. 更新申请表状态 M('merchant_apply')->where('apply_id', $applyId)->save(['apply_status' => 2, 'audit_time' => time()]); // 2. 创建店铺记录 M('shop')->add([ 'user_id' => $apply['user_id'], 'shop_name' => $apply['shop_name'], 'shop_status' => 1, 'create_time' => time(), ]); // 3. 会员标记为商家 M('users')->where('user_id', $apply['user_id'])->save([ 'is_merchant' => 1, 'merchant_apply_status'=> 2, ]); return ['code' => 1, 'msg' => '审核通过']; }

这段代码揭示了一个设计取舍：商家身份标记和店铺数据是分开的。users表只管你是“卖家”还是“买家”，店铺资料、店名、营业状态都在shop表。这个拆分的好处是以后要做“一个会员开多店”时不需要改身份字段，只需要调整shop表和user的关联关系。

2.3 商家中心的入口判断：模板里怎么认商家身份

前台模板里到处要判断“当前登录者是不是商家”，常见做法是页面入口统一走一个公共函数，而不是在模板里到处写死判断：

function isMerchant($userId = 0) { if (empty($userId)) { $userId = session('users_id'); } $user = M('users')->where('user_id', $userId)->find(); return $user['is_merchant'] == 1; }

模板里这样用：

{if condition="isMerchant()"} <a href="{:url('merchant/index/index')}">商家中心</a> {else /} <a href="{:url('merchant/apply/index')}">成为商家</a> {/if}

逻辑说明：isMerchant函数先从session里取当前登录会员，再去查一次users表，这样比把身份状态直接存session更可靠——会员身份被后台手动改过时，模板判断能拿到最新值。性能方面，这是单条主键查询，压测下不会有明显开销。

参数说明：session键名要和你站点原来的登录态保持一致，常见易优系商城是users_id，有的版本是user_id。判断模板里括号内不要传参数时，函数会自动从session里拿；如果商家中心页需要兼容管理员预览商家身份，也可以手动传入user_id，这个接口在二次开发里很常用。

3. 部署实操：从插件包到商家中心可见的关键步骤

3.1 部署前检查与备份

拿到插件包先别急着传文件。我一般会核对三件事：站点PHP版本是否满足插件要求（常见要求PHP5.6及以上，PHP7.x表现最稳定）、MySQL是否为5.6及以上、后台伪静态规则是否正确。PHP版本尤其重要，很多老站还跑在PHP5.4上，直接上传会在安装页就白屏。

备份也是必做的：网站根目录源码打包一份，MySQL数据库导出一份。这一步不花多少时间，但后面改错字段、覆盖模板时，它就是后悔药。数据库导出用常见命令即可，导出后确认一下文件大小不为0再继续。

3.2 执行SQL建表脚本

插件包里通常会带install.sql，也可以手动执行自己建的SQL。命令行导入是最快的：

mysql -u 数据库账号 -p 数据库名 < install.sql

回车后输入数据库密码，避免密码直接写在命令行里。install.sql里建了merchant_apply、shop两张表，并给users表加字段。merchant_apply表结构大致是这样：

CREATE TABLE `merchant_apply` ( `apply_id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL DEFAULT '0', `shop_name` varchar(100) NOT NULL DEFAULT '', `contact_name` varchar(50) NOT NULL DEFAULT '', `contact_mobile` varchar(20) NOT NULL DEFAULT '', `apply_status` tinyint(1) NOT NULL DEFAULT '1', `create_time` int(11) NOT NULL DEFAULT '0', `audit_time` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`apply_id`), KEY `user_id` (`user_id`), KEY `apply_status` (`apply_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

shop表除了店铺基本信息外，还有一个shop_status字段控制前台可见状态。参数说明：审核通过后shop_status默认置1表示营业中；如果想做“暂时关店”，在店铺设置里把它置0就能在前台隐藏全部商品，这是运营会直接用到的逻辑。

导入完SQL之后，在数据库客户端里确认一下users表是否成功新增了is_merchant和merchant_apply_status两个字段。如果导入时报表已存在，多半是之前装过同类插件，需要按第5章的清理方法处理，千万不要跳过检查直接进后台。

3.3 后台菜单与插件功能入口

SQL执行完，后台左侧菜单还没有商家管理入口。常见做法是把菜单记录插到menu表里：

INSERT INTO `menu` (`menu_name`, `controller`, `action`, `status`) VALUES ('商家入驻管理', 'Merchant', 'index', 1), ('店铺管理', 'Shop', 'index', 1), ('佣金配置', 'Merchant', 'commission', 1);

插入后刷新后台页面，左侧会出现对应菜单。参数说明：controller和action要和插件路由里的控制器名完全一致。易优系系统的插件路由是“插件名/控制器/方法”三段，比如merchant/index/index，菜单插入时不要漏掉中间那一段，漏了点菜单基本就是404。

如果后台已经有“应用中心”这类安装入口，直接在线安装插件包更省事，安装成功后插件会自动注册菜单和钩子。两种方式任选一种，不要重复执行菜单SQL，否则后台菜单会重复显示。

部署完先不要急着对外发布。我习惯开一个测试账号走一遍完整链路：前台注册新会员，点“成为商家”，提交入驻申请，后台看到待审记录，点审核通过，商家中心能正常登录，再发布一件测试商品。这个流程跑通，部署才算真正完成。

4. 参数设置：入驻门槛、佣金比例与提现规则一次讲清

4.1 入驻审核模式：自动通过还是人工审核

插件配置文件里有一组核心参数，常见位置在插件包解压后的config.php里。第一次部署时问得最多的就是“会员提交申请后到底要不要人工审”。两种模式各有场景：自动通过适合测试站或私域小圈子，会员提交即开店，运营成本最低；人工审核适合正式平台，平台要控制入驻质量和类目资质。

return [ // 商家入驻审核模式：1自动通过 0人工审核 'merchant_check_mode' => 0, // 申请时是否需要短信验证 'merchant_apply_sms' => 0, ];

参数说明：merchant_check_mode置1时，applyMerchant函数执行完会立刻调用passApply($applyId)，相当于把审核流程省略成自动操作；置0时，申请单进入后台待审列表，由管理员逐条处理。merchant_apply_sms如果开起来，要确认短信服务商的通道和模板是否可用，不然用户点提交时会卡在验证码那一步。

这里有个容易踩的细节：改成自动通过模式后，申请人的店铺名和联系方式就直接进shop表了，如果前台没有做店铺名重复校验，会出现两家同名店铺。正式环境建议在applyMerchant里加一道店铺名校验，或者把shop_name设成唯一索引。

4.2 佣金比例与结算下限

平台从商家订单里抽成，是这套插件除会员升级外的另一个核心价值。配置项就一行：

'commission_rate' => 5, // 平台抽成比例，单位：% 'commission_min' => 1, // 单笔订单最低抽成金额，单位：元

逻辑说明：佣金计算在订单支付成功后触发，常见实现是“订单实付金额 × commission_rate / 100”，如果算出来的抽成金额低于commission_min，则按commission_min计算。这个参数适合用来防小额订单抽成金额太低的情况，比如一瓶9.9元的商品，按5%抽成不到0.5元，平台设了commission_min为1元后，每单实际抽1元。

参数说明：commission_rate填整数，不要填小数，很多版本没有做浮点运算的兼容处理；commission_min填0就表示不设下限。正式上线前最好把主力商品的佣金手动测算一遍，不同的运费模板和满减策略会影响实付金额，算出来的抽成可能和预期差不少。

4.3 提现最小额度与手续费

商家卖货的钱不会实时到账，而是挂在商家中心的可提现余额里。提现参数控制两个点：多少钱可以提、提现扣多少手续费。

'withdraw_min' => 10, // 商家单次最低提现金额，单位：元 'withdraw_fee' => 1, // 单次提现手续费，单位：元，0为免费 'withdraw_day' => 3, // 提现申请批准后的打款账期，单位：自然日

参数说明：withdraw_min设10元是常见做法，太低了提现操作频繁，手续费都压不住；withdraw_fee为1元时，商家提现100元实际到账99元；withdraw_day是给人工打款预留的账期，设定后商家端会显示“预计X天后到账”，避免反复追问到账时间。

这几个参数改完要记得让商家中心缓存刷新才能生效，部分版本需要清一下runtime缓存。执行：

rm -rf runtime/cache/*

Windows环境下直接删除runtime/cache目录下的文件也有效，删完再访问商家中心就会重新生成缓存文件。

5. 实测避坑：身份切换、模板覆盖与列表不刷新的五个常见问题

这块内容是一次又一次实测翻车换来的，按“现象→原因→解决”写，遇到类似报错可以直接照着处理。

5.1 现象：提交入驻申请后，前台登录态被顶掉

有测试用户点“成为商家”后，页面跳到登录页，重新登录后又回到了普通会员页面。原因：商家身份切换和原会员登录用的是同一个session键，处理入驻申请时把session内容覆写了，导致登录态失效。解决：把商家中心的session键改成独立键名，不动原会员登录session。修改后重新登录再提交申请，链路就正常了。这个坑在新装和二次开发的站点上都可能出现，排查时先看session键名是否冲突。

5.2 现象：替换模板包后，前台首页直接报错

原因：插件自带了一套商家中心前端模板，和站点正在用的主题模板目录结构不一致，上传时把两个目录合并，导致首页模板调用了不存在的公共文件，白屏或直接抛出模板语法错误。解决：先分清哪些是插件目录下的模板，哪些是主题模板。商家中心模板放到插件自己的视图目录里，不要覆盖主题模板文件。替换模板前把网站根目录的template文件夹完整备份一份，出错就整体还原。

5.3 现象：商家中心提示“没有权限”

原因：钩子文件里对商家身份的路径判断条件写错了，比如判断的controller名和实际路由中的插件标识对不上，导致isMerchant()一直返回false。解决：打开钩子注册文件，检查拦截规则里路径段和权限判断逻辑，确认当前访问路径是merchant开头才拉取商家身份校验。改完清一下第4章里的runtime缓存再试，权限判断会在第一次请求时被缓存住，不清缓存改了也不生效。

5.4 现象：商品发布成功，但商城列表里看不到

原因：商品表没有新增shop_id字段，或者新增了但商家发布时没把shop_id写入，列表查询也没对shop_status做过滤。结果就是后台能看到商品，前台列表查不到。解决：给商品表补一个shop_id字段：

ALTER TABLE `goods` ADD COLUMN `shop_id` int(11) NOT NULL DEFAULT '0' COMMENT '所属店铺ID';

发布商品时强制写入当前商家的shop_id，列表查询条件里加上shop_status=1。回填历史数据后，前台商品列表就能正常显示了。这个坑最容易发生在老商城改造时，原商品表结构里压根没有商家维度，漏了这一步前台永远看不到新商品。

5.5 现象：重复安装时SQL报“字段已存在”

原因：本地测试装过一次，回滚时只删了插件文件，没有把users表上的is_merchant和merchant_apply_status字段清掉，重装时install.sql又执行了一遍。解决：重装前先查一下字段：

SHOW COLUMNS FROM `users` LIKE 'is_merchant';

有返回就先用ALTER TABLE DROP COLUMN清掉，或者把install.sql改成带判断的建表语句。这个习惯养成了，后面换库、迁移、换服务器都省事。

6. 把插件用透：商家入驻后的店铺装修与提现闭环

6.1 店铺装修的最小挂载方式

很多朋友装完后只留下了“商家中心”链接，前台并没有独立的店铺主页。其实插件里是有店铺装修功能的，只是默认模板比较简单。常见做法是把店铺主页地址固定成merchant/shop/index?id=店铺ID，并把商家中心里设置的店铺logo、店铺banner、店铺简介字段挂上去。

店铺模板字段表：

这些字段在表结构上都有，直接用商家中心的后台表单维护即可。商家上传Banner后，前台用一段简短的模板循环就能渲染出来。赶时间的话直接把shop_id作为URL参数挂在店铺链接上，就能让每个商家的主页独立访问。

6.2 提现流水与佣金结算的闭环

提现不是简单降余额，插件把商家每笔收入、佣金抽成、提现记录都存在了独立流水表中。商家中心看到的“可提现余额”其实是累计收入减去累计佣金再减去已提现和待提现金额后的结果，这样的口径才不会被财务反复追问。

从那以后我每次做易优系商城改造，都会强制自己先走一遍“会员申请→后台审核→商家发布商品→下单结算→佣金抽成→商家提现”这条完整链路，每一步都留日志。这套流程跑通了，再去做二次开发和模板替换心里就有底。这份会员变商家商城插件的完整源码包、建表SQL和商家中心模板我整理好了一份，直接拿去按文中的步骤部署即可。希望帮到你。

本文还有配套的精品资源，点击获取