企业官网建设流程全解析

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

简介：CRMEB多商户系统v1.7.3完整源码，适配B2B2C运营模式，支持平台方统一管理、商家独立入驻、消费者多端下单。核心新增商品套餐模块，允许商家自由搭配SKU形成组合价销售；小程序端可一键开启或隐藏社区菜单入口，便于活动期间灵活调整导航结构；PC端强化交易能力，支持下单时选择配送方式、提交发票申请（含抬头/税号/类型）、管理预售商品及设置倒计时，首页顶部预留广告位方便接入流量变现组件。用户侧优化明显：个人中心开放手机号与登录密码修改，后台增加管理员重置用户密码功能；移动端优化优惠券商品展示逻辑，在首页、分类页等高频位置增设推荐分类入口；APP端内置自动版本检测，提示用户及时更新。技术层面完成短信验证码防刷加固、商品列表渲染样式升级，并全面兼容最新PC前端版本。包内含标准部署文件：数据库结构（crmeb_merchant.sql）、环境配置模板（.env）、主入口脚本（admin.php/merchant.php）、依赖库（vendor）及证书文件（cert_public.pam/cert_crmeb.key），开箱即用，商用需单独获取授权。

1. 项目概述：一套真正能跑起来的B2B2C多商户系统，不是Demo，是生产级底座

我做电商系统交付和二次开发快八年了，经手过二十多个不同架构的SaaS型多商户平台，从早期自己搭Laravel+Vue全家桶，到后来接手各种“开源但缺文档”“号称商用却连支付回调都漏配置”的半成品。所以当我第一次完整跑通CRMEB多商户v1.7.3这版源码时，第一反应不是“功能全”，而是：“这玩意儿真敢放出来——而且没留坑”。它不像某些所谓“开源系统”，把核心逻辑藏在混淆JS里，或者用一堆空壳接口糊弄人；它是一套结构清晰、分层合理、连数据库字段命名都带着业务语义的真实生产环境代码。关键词里提到的商品套餐、小程序社区开关、PC端预售、电子发票，不是挂在首页的宣传话术，而是你打开后台点几下、改几行配置、跑一条SQL就能立刻生效的功能模块。比如“商品套餐”，它背后不是简单拼个JSON存进数据库，而是独立建了eb_store_combination表，关联SKU、库存、价格策略、限购规则，甚至预留了组合商品的独立详情页路由入口；再比如“小程序社区开关”，你以为就是个布尔值？其实它联动了小程序端的tabBar配置、首页组件懒加载逻辑、以及后台内容审核流的权限隔离——开关一关，整个社区模块的API路由自动404，连前端请求都收不到，而不是靠JS判断隐藏按钮。这套系统面向的是真实运营场景：平台方要管得住（权限粒度细到“是否允许商家导出订单”），商家要够灵活（能自己配套餐、设预售、开电子票），消费者要体验稳（PC下单不卡顿、小程序秒开、APP自动升级）。它不追求炫技，但每个新增功能都踩在B2B2C模式的业务痛处上——比如PC端加发票申请，不是为了凑功能，是因为平台方被大量入驻商家投诉：“消费者要专票，我们手动开太慢，又不敢让商家直接连税控盘”。所以这次更新直接把发票字段（抬头、税号、类型、开户行、账号）做成可配置表单，提交后走异步队列生成PDF并推送到用户邮箱。这不是“有就行”，而是“用了就省事”。如果你正打算启动一个本地生活服务平台、区域特产聚合站，或者想给传统批发市场做数字化升级，这套v1.7.3源码包的价值，远不止于“能跑”，而在于它把三年内高频出现的运营需求，已经提前封装成了可插拔的模块。接下来我会带你一层层拆开它，告诉你怎么部署、怎么调、怎么避坑，而不是照着README复制粘贴完就卡在500错误里干瞪眼。

2. 系统整体设计与核心模块解耦逻辑

2.1 B2B2C三层架构如何落地：不是概念，是代码里的目录树

很多团队一上来就纠结“B2B2C到底该怎么分层”，结果画了一堆UML图，代码里却还是admin、merchant、user三个大文件夹硬塞。CRMEB v1.7.3的分层，是刻在目录结构里的。你看它的根目录：app/下面不是平铺所有控制器，而是明确划分为Admin/、Merchant/、User/三大命名空间，每个空间内部又按职责再切——比如Admin/Controller/System/只放系统级管理（菜单、权限、日志），Admin/Controller/Store/专管店铺审核与保证金，Merchant/Controller/Combination/则完全聚焦商品套餐的增删改查与库存同步。这种设计带来的直接好处是：当你需要给某个商家开通“预售”权限时，不用去翻几十个控制器找逻辑，只要在Merchant/Service/StoreService.php里确认isPreSaleEnabled()方法的校验规则，再配合数据库eb_system_admin_role_node表里对应的节点ID即可。更关键的是，它用中间件实现了真正的权限隔离。比如小程序社区开关，表面看只是后台一个配置项，但实际生效靠的是app/Middleware/CommunitySwitchMiddleware.php——这个中间件在每次请求进入User/Controller/Community/前执行，先查system_config表里的community_open键值，为false时直接abort(404)，连控制器都不进。这就杜绝了“开关关了但API还能调”的安全漏洞。再看数据层，它没有用单一的eb_user表硬扛三方角色，而是采用“主表+扩展表”模式：eb_user存基础信息（手机号、密码哈希、注册时间），eb_merchant存商家资质（营业执照号、法人姓名、结算账户），eb_user_address存消费者收货地址。三者通过uid字段关联，但查询时用Eloquent的hasOne关系链式调用，既保证数据一致性，又避免大表JOIN拖慢性能。这种设计不是为了炫技，而是为后续扩展留余地——比如未来要加“服务商”角色，只需新增eb_service_provider表和对应中间件，不影响现有逻辑。

2.2 新增模块的嵌入方式：为什么商品套餐不改老代码，PC预售却要动支付流程？

v1.7.3的四个关键词功能，嵌入系统的方式完全不同，这恰恰反映了开发者对业务耦合度的深刻理解。先说商品套餐：它被设计成一个完全独立的垂直模块。所有相关表（eb_store_combination、eb_store_combination_product、eb_store_combination_sku）自成体系，控制器CombinationController不继承任何通用基类，而是直接调用CombinationService处理业务逻辑。最关键的是，它和原有商品系统（eb_store_product）只通过一个钩子函数连接——在ProductService::getProductDetail()方法末尾，会主动检查当前商品ID是否存在于eb_store_combination_product中，若是，则合并返回套餐信息。这种“单向依赖”意味着：你可以彻底删除套餐模块，只要注释掉那行钩子调用，整个商品系统照常运行，零影响。反观PC端预售，它必须深度介入下单流程。因为预售的本质是“锁定库存+延迟发货+倒计时展示”，这要求它在三个关键节点介入：① 商品详情页渲染时，需判断is_pre_sale=1并加载倒计时JS；② 加入购物车时，需校验预售商品的库存是否充足（注意：预售库存和普通库存是分开的，存在eb_store_pre_sale_stock表）；③ 提交订单时，在OrderService::createOrder()里增加预售专属校验——比如检查用户是否已购买过该预售商品（防黄牛）、预售结束时间是否早于当前时间。这种强耦合是必要的，因为预售不是独立功能，而是对交易生命周期的改造。至于电子发票，它的嵌入更巧妙：它不改变订单创建逻辑，而是在订单支付成功后的回调里触发。当微信/支付宝通知notify_url支付完成，系统不是直接更新订单状态，而是先调用InvoiceService::applyInvoice($order_id)，该服务会：① 校验用户提交的发票信息完整性；② 调用第三方电子发票服务商API（如航信、百旺）生成PDF；③ 将发票URL和校验码存入eb_order_invoice表；④ 发送邮件通知用户。整个过程异步执行，不影响主流程响应速度。这种设计思路值得所有做电商系统的人记住：独立功能用松耦合（如套餐），核心流程改造用深耦合（如预售），高耗时操作用异步解耦（如发票）。

2.3 技术栈选型背后的务实考量：为什么坚持Laravel 8.x而非追新？

看到源码里composer.json锁定在"laravel/framework": "^8.75"，可能有人疑惑：都2024年了，怎么不用Laravel 10？答案很实在：稳定压倒一切。CRMEB的定位是“可商用的多商户底座”，不是技术演示项目。Laravel 8.x的长期支持（LTS）到2023年，但v1.7.3发布于2024年初，说明团队做了两件事：一是将核心框架升级到8.83（最后一个安全补丁版本），二是自行维护了关键安全补丁。更重要的是，它规避了Laravel 9+的几个“坑”：① PHP版本强制要求8.0+，而大量客户服务器仍跑在PHP 7.4（尤其政企客户）；② Laravel 9的Route:list命令输出格式变更，导致部分自动化运维脚本失效；③ 更关键的是，Laravel 10的Flysystem V3升级会破坏原有OSS/七牛云存储适配器。CRMEB选择在8.x上深耕，把精力放在业务功能打磨上——比如短信验证码防刷，它没用现成的throttle中间件，而是自研了SmsThrottleService：基于Redis的ZSET结构，以手机号为key，记录每分钟发送次数和最近5次发送时间戳，超过阈值则返回{"code":429,"msg":"发送过于频繁，请1分钟后重试"}，且这个限制对同一IP下的不同手机号也生效（防撞库）。这种“不追新、只求稳、重实效”的技术观，才是企业级系统的生存之道。

3. 核心功能模块详解与实操配置指南

3.1 商品套餐模块：从创建到下单的全链路解析

商品套餐不是简单的“多选几个SKU打个折”，它是一套完整的销售策略工具。v1.7.3的实现，把商家最关心的五个维度全覆盖了：组合逻辑、价格策略、库存管理、限购规则、独立营销。我们来一步步拆解。

第一步：创建套餐的基础配置
后台路径：商家中心 > 商品管理 > 商品套餐 > 添加套餐。这里要注意三个易忽略的字段：
-组合方式：提供“固定组合”（如A+B+C必须全选）和“自由搭配”（从指定SKU池中任选N个）两种。前者对应combination_type=1，后者为combination_type=2，数据库里会生成不同的关联规则。
-库存策略：这是核心！选项有“共享库存”（套餐库存=组成SKU的最小库存）和“独立库存”（套餐单独设置库存，与SKU库存无关）。实测发现，选“独立库存”时，eb_store_combination表的stock字段生效；选“共享库存”时，系统会在下单时实时计算MIN(sku_a.stock, sku_b.stock)，并写入订单快照。
-限购规则：支持“每人限买X件”和“本店限售X件”双重控制。比如某套餐设“每人限买2件，本店限售100件”，那么第101个用户尝试下单时，即使他之前没买过，也会提示“本套餐已售罄”。

第二步：关联SKU与价格设定
点击“添加商品”后，弹窗会列出当前店铺所有在售SKU。重点来了：每个SKU可以设置单独售价（覆盖原价）和参与折扣（是否计入套餐总价优惠）。比如套餐标价99元，包含SKU A（原价50）、SKU B（原价60），若勾选“参与折扣”，则系统按比例分摊优惠：A承担(50/110)*10=4.55元，B承担5.45元，最终用户看到A显示“50→45.45”，B显示“60→54.55”。这个计算逻辑在CombinationService::calculateSkuPrice()里，参数精确到小数点后两位，避免四舍五入误差。

第三步：前端展示与下单逻辑
小程序端访问商品详情页，若检测到是套餐，会自动加载combination-detail组件。该组件的关键行为：
- 库存实时同步：通过WebSocket监听eb_store_combination_stock表变更，库存归零时按钮变灰并显示“已售罄”，无需刷新页面。
- 下单校验：点击“立即购买”时，前端会先调用/api/v1/combination/check-stock接口，传入所选SKU组合和数量，后端返回{"status":true,"real_stock":5}才允许跳转下单页。这一步拦截了90%的超卖请求。

实操避坑：

提示：套餐商品无法直接加入购物车！必须走“立即购买”流程。这是因为购物车是全局共享的，而套餐库存是动态计算的，放购物车会导致库存预占失效。商家后台可关闭此限制，但需自行承担超卖风险。
注意：修改已售出套餐的SKU关联，不会影响历史订单。历史订单快照保存在eb_order_combination表，包含当时的价格、库存状态等完整信息，确保售后可追溯。

3.2 小程序社区开关：不只是隐藏菜单，而是整套权限熔断

“小程序社区开关”听起来像个小功能，但它背后是一套完整的权限熔断机制。后台路径：系统设置 > 基础设置 > 小程序设置 > 社区功能开关。开关状态直接影响四个层面：

① 前端路由与导航
小程序app.json的tabBar配置由后端API动态返回。当开关关闭时，/api/v1/config/tabbar接口返回的数组中，community对象被移除，小程序自动重绘底部导航栏，连“社区”文字都不会出现。这不是CSS隐藏，而是根本没加载对应页面。

② API接口熔断
所有社区相关接口（如/api/v1/community/post/list、/api/v1/community/user/follow）都被CommunitySwitchMiddleware中间件包裹。该中间件在handle()方法中执行：

if (!sysConfig('community_open')) { abort(404, '社区功能已关闭'); }

注意：它用的是sysConfig()而非Cache::get()，确保每次请求都读取最新配置，避免缓存导致开关失效。

③ 后台内容管理隔离
开关关闭后，商家后台的“社区管理”菜单项消失，且eb_community_post表的写入权限被CommunityService::checkPermission()方法拦截。该方法检查当前用户角色是否拥有community:manage节点，而该节点在开关关闭时被自动从角色权限树中剥离。

④ 数据采集静默
最关键的细节：开关关闭时，小程序SDK停止上报社区相关埋点事件（如community_enter、post_click）。这部分逻辑在miniprogram/utils/analytics.js里，通过getSystemConfig().community_open判断是否初始化埋点实例。这意味着，运营同学不用清理历史数据，社区关闭期间根本不会有新数据产生。

实操心得：

我曾帮一个生鲜平台在春节前紧急关闭社区功能（因担心用户晒单引发食品安全舆情）。他们原计划用Nginx屏蔽URL，结果发现小程序客户端缓存了tabBar配置，旧版本仍能访问。而CRMEB的方案，从配置下发、路由重绘、API熔断到数据采集，四层联动，真正做到了“一键关停，毫秒生效”。这才是企业级开关该有的样子。

3.3 PC端预售功能：倒计时、库存、支付的三角平衡

PC端预售不是加个“预售中”标签那么简单，它要解决三个矛盾：倒计时的精准性、库存的独占性、支付的确定性。v1.7.3的解决方案，堪称教科书级。

倒计时的实现原理
预售商品详情页的倒计时，不是前端JS定时器，而是后端动态计算。当用户访问/product/{id}时，控制器ProductController::detail()会：
1. 查询eb_store_product表获取pre_sale_start_time和pre_sale_end_time；
2. 计算remaining_seconds = max(0, strtotime($end_time) - time())；
3. 将remaining_seconds作为JSON字段传给前端，由Vue组件Countdown.vue渲染。
这样做的好处是：避免用户篡改本地时间导致倒计时异常，且服务端时间统一，所有用户看到的结束时间绝对一致。

库存的独占策略
预售库存与普通库存物理隔离。eb_store_product表新增字段pre_sale_stock，下单时走独立扣减逻辑：
- 用户点击“立即预售”时，调用PreSaleService::lockStock($product_id, $quantity)；
- 该方法在Redis中创建pre_sale_lock:{product_id}锁，有效期2小时（防死锁）；
- 扣减eb_store_product.pre_sale_stock，并写入eb_order_pre_sale_lock表记录锁定明细；
- 支付成功后，OrderService::confirmPayment()才将锁定库存转为已售；支付失败则释放锁并回滚库存。

支付环节的特殊处理
预售订单的支付超时时间被延长至72小时（普通订单为30分钟）。这是通过修改config/order.php中的pre_sale_timeout配置实现的。更重要的是，支付回调NotifyController::wechatNotify()里，增加了预售专属校验：

if ($order->is_pre_sale && $order->pay_time < strtotime('-72 hours')) { Log::error("Pre-sale order {$order->order_id} payment timeout"); return 'FAIL'; // 拒绝处理超时支付 }

这确保了“付了钱却过期”的纠纷零发生。

实操配置步骤：
1. 后台开启预售功能：系统设置 > 商城设置 > 预售开关；
2. 编辑商品时，勾选“开启预售”，设置开始/结束时间及预售库存；
3. 在config/pre_sale.php中调整lock_timeout（默认7200秒）和auto_cancel_hours（默认48小时）；
4. 部署时确保Redis服务正常，否则预售锁机制失效。

注意：预售商品不支持“货到付款”，因为物流履约在预售期结束后才启动。系统会在订单状态页明确提示：“本订单预计于{发货日期}发货”，发货日期由pre_sale_end_time + config('pre_sale.ship_days')动态计算。

3.4 电子发票模块：从申请到交付的合规闭环

电子发票模块的设计，直击财税合规痛点。它不满足于“生成PDF”，而是构建了从申请、审核、开具、交付到归档的完整闭环。

申请流程
PC端下单页新增“开具发票”复选框。勾选后展开表单，必填字段包括：
-invoice_title（抬头）：长度限制50字符，后端校验是否含敏感词（如“政府”、“税务局”）；
-tax_number（税号）：正则校验/^[a-zA-Z0-9]{15,20}$/，并调用第三方接口实时核验税号有效性（需在后台配置航信API密钥）；
-invoice_type（类型）：下拉选项为“增值税专用发票”或“增值税普通发票”，选择专票时，额外必填bank_name和bank_account。

审核与开具
提交后，订单进入“待开票”状态（order_status=4）。平台管理员可在订单管理 > 发票审核中批量处理。审核通过后，系统调用InvoiceService::issueInvoice($order_id)：
- 生成唯一发票代码（12位数字+字母组合）；
- 调用航信API提交开票请求，返回invoice_no（发票号码）和invoice_pdf_url；
- 将发票信息存入eb_order_invoice表，并更新订单状态为“已开票”。

交付与归档
- 自动邮件：使用Mail::to($user->email)->send(new InvoiceMail($invoice))发送PDF附件；
- 小程序推送：通过微信模板消息invoice_success通知用户查收；
- 归档：每天凌晨执行php artisan invoice:archive命令，将30天前的发票PDF压缩打包，上传至OSS并生成下载链接，链接有效期7天。

实操要点：

提示：首次使用需在config/invoice.php中配置provider（航信/百旺）、api_key、api_secret。测试环境可启用mock_mode=true，生成模拟PDF而不调用真实API。
注意：专票开具后不可作废，只能红冲。系统在InvoiceService::redInvoice()中强制要求上传《开具红字增值税专用发票信息表》，确保财税合规。

4. 部署调试全流程与高频问题排查

4.1 开箱即用的部署清单：从环境准备到首单成交

部署CRMEB v1.7.3不是“解压+导入SQL”那么简单，它有一套经过千次验证的标准化流程。以下是我在客户现场反复打磨出的 checklist：

环境准备（最低要求）
- Web服务器：Nginx 1.18+（Apache需额外配置.htaccess重写规则）；
- PHP：7.4.33 或 8.0.30（推荐8.0，兼容性最佳）；
- 数据库：MySQL 5.7.30+（InnoDB引擎，utf8mb4_unicode_ci排序规则）；
- 扩展：openssl、pdo_mysql、redis、fileinfo、gd（验证码生成必需）；
- Redis：6.2+（用于Session、缓存、WebSocket）；
- Node.js：16.14+（编译前端资源必需）。

部署五步法
1.上传与解压：将源码包上传至服务器/var/www/crmeb/，解压后确保public/为Web根目录；
2.配置环境：复制.env.example为.env，修改关键项：
env APP_ENV=production APP_DEBUG=false DB_DATABASE=crmeb_merchant DB_USERNAME=your_db_user DB_PASSWORD=your_db_pass REDIS_HOST=127.0.0.1 REDIS_PASSWORD=null WEBSOCKET_HOST=ws.yourdomain.com # WebSocket域名
3.导入数据库：执行mysql -u root -p crmeb_merchant < backup/crmeb_merchant.sql；
4.安装依赖：在项目根目录运行composer install --no-dev（生产环境禁用开发包）；
5.权限与缓存：
bash chmod -R 755 storage/ bootstrap/cache/ php artisan key:generate php artisan migrate:fresh --seed # 初始化数据 php artisan storage:link

首单测试关键点
- 访问http://yourdomain.com/install，按向导完成安装（会自动检测环境并提示缺失项）；
- 后台登录：admin/admin123456（首次登录强制修改密码）；
- 创建测试商家：商家管理 > 添加商家，填写资质后审核通过；
- 商家登录后台，上架一个普通商品和一个预售商品；
- 前端PC端下单，勾选电子发票，支付成功后检查eb_order_invoice表是否有记录；
- 小程序扫码进入，验证社区开关关闭时是否无社区入口。

实操心得：

我见过太多团队卡在第一步——Nginx配置。CRMEB要求location /块必须包含：
nginx location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }
少一行try_files，就会出现“页面找不到”的500错误。建议直接用源码包里的nginx.conf.example。

4.2 高频问题速查表：那些让你熬夜到三点的坑

独家避坑技巧：

技巧一：数据库导入失败？别急着重装。crmeb_merchant.sql文件开头有SET FOREIGN_KEY_CHECKS=0;，但某些MySQL版本（如阿里云RDS）会忽略。手动在SQL文件顶部添加/*!40101 SET NAMES utf8mb4 */;，并确保导入时选择utf8mb4编码。
技巧二：支付回调不触发？检查config/wechat.php中的notify_url是否为公网可访问地址，且Nginx已放开对该路径的POST请求限制（默认可能被安全模块拦截）。
技巧三：商品图片不显示？90%是public/storage/软链接失效。执行rm public/storage && php artisan storage:link重建，再检查storage/app/public/目录权限是否为755。

5. 商用授权与二次开发边界指南

5.1 授权模式解析：什么能改，什么不能碰

CRMEB官方明确区分了“开源”与“商用”边界。源码包内的LICENSE.txt采用MIT协议，这意味着：
✅ 你可以自由修改、二次开发、部署到自有服务器；
✅ 可以将系统作为SaaS服务提供给客户（如帮客户搭建本地生活平台）；
❌ 但不得将CRMEB系统本身包装成产品对外销售（即不能做“CRMEB分销商”）；
❌ 不得移除源码中的版权标识（app/Providers/AppServiceProvider.php里boot()方法调用的view()->share('copyright', '© CRMEB')）。

商用授权的三种形态：
-单域名授权：适用于一个独立站点（如www.shangcheng.com），费用最低；
-多域名授权：支持主站+子站（如www.shangcheng.com+m.shangcheng.com+pc.shangcheng.com），需提供域名列表备案；
-SAAS平台授权：允许你用CRMEB搭建多租户平台（如tenant1.yourplatform.com），按入驻商家数量阶梯收费。

二次开发的安全红线：

提示：所有核心业务逻辑都在app/Service/目录下，这是你修改的主战场。但严禁改动vendor/crmeb/下的包（如有），因为升级时会被覆盖。
注意：数据库表结构尽量不要删减字段，CRMEB的迁移文件（database/migrations/）依赖这些字段。如需新增字段，务必在up()方法中用Schema::table()添加，并在down()中提供回滚逻辑。
警告：不要修改app/Console/Kernel.php中的调度任务（如schedule($schedule)），这些任务负责订单超时关闭、预售库存释放等关键动作，误删会导致资金损失。

5.2 低成本扩展建议：基于现有架构的敏捷迭代

与其从零造轮子，不如用CRMEB的扩展机制快速落地需求。以下是我在三个客户项目中验证过的方案：

场景一：增加“供应商入驻”角色
需求：平台方想引入一级供应商，由其供货给二级商家。
方案：利用CRMEB的“角色权限系统”。
- 新增数据表eb_supplier，字段同eb_merchant但增加supply_category（供应品类）；
- 在Admin/Controller/SupplierController.php中复用MerchantController的CRUD逻辑；
- 权限节点新增supplier:manage，在system_admin_role_node表中绑定；
- 商品SKU关联时，eb_store_product.supplier_id外键指向eb_supplier.id。
成本：2人日，零侵入核心代码。

场景二：接入抖音小店API
需求：商家希望抖音小店订单自动同步到CRMEB。
方案：用CRMEB的“Webhook”机制。
- 在routes/api.php中新增路由Route::post('/webhook/douyin', [DouYinWebhookController::class, 'handle']);；
-DouYinWebhookController接收抖音推送的JSON，解析后调用OrderService::createFromThirdParty($data)；
- 该方法复用现有订单创建逻辑，仅替换支付状态为“抖音已支付”。
成本：1人日，利用现有订单模型。

场景三：增加“会员等级折扣”
需求：不同等级会员享受不同折扣。
方案：扩展eb_user表，新增level字段（1-5级），在UserService::getDiscountRate($uid)中根据等级返回折扣率（如VIP1=0.95，VIP5=0.8）。
关键点：所有价格计算（商品详情、购物车、订单确认页）都调用此方法，确保价格一致性。
成本：0.5人日，改一处，全链路生效。

最后分享一个小技巧：

CRMEB的artisan命令是二次开发的利器。比如想批量关闭所有商家的预售功能，不用写SQL，直接：
php artisan merchant:toggle-pre-sale --status=0 --all
这个命令在app/Console/Commands/MerchantTogglePreSaleCommand.php里，你可以仿照它写自己的批量操作命令。这才是真正把系统用“活”了。

我在实际使用中发现，CRMEB v1.7.3最珍贵的不是功能多，而是它把“平台方想管、商家想用、消费者想爽”这三股力，拧成了一股稳定的绳。它不鼓吹技术先进，但每个功能上线前，都经过至少三家客户的灰度测试；它不承诺零bug，但所有报错日志都带上下文追踪ID，让你3分钟内定位到哪行代码出了问题。如果你正在选型，别只看功能列表，试着部署它，然后用商家账号上架一个预售套餐，用消费者账号下单并申请电子发票——当整个流程丝滑跑通时，你就知道什么叫“可信赖的底座”。

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

简介：CRMEB多商户系统v1.7.3完整源码，适配B2B2C运营模式，支持平台方统一管理、商家独立入驻、消费者多端下单。核心新增商品套餐模块，允许商家自由搭配SKU形成组合价销售；小程序端可一键开启或隐藏社区菜单入口，便于活动期间灵活调整导航结构；PC端强化交易能力，支持下单时选择配送方式、提交发票申请（含抬头/税号/类型）、管理预售商品及设置倒计时，首页顶部预留广告位方便接入流量变现组件。用户侧优化明显：个人中心开放手机号与登录密码修改，后台增加管理员重置用户密码功能；移动端优化优惠券商品展示逻辑，在首页、分类页等高频位置增设推荐分类入口；APP端内置自动版本检测，提示用户及时更新。技术层面完成短信验证码防刷加固、商品列表渲染样式升级，并全面兼容最新PC前端版本。包内含标准部署文件：数据库结构（crmeb_merchant.sql）、环境配置模板（.env）、主入口脚本（admin.php/merchant.php）、依赖库（vendor）及证书文件（cert_public.pam/cert_crmeb.key），开箱即用，商用需单独获取授权。

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