<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[CRMEB小程序商城的博客]]></title><description><![CDATA[CRMEB小程序商城系统的官方博客！]]></description><link>https://blog.youkuaiyun.com/CRMEB</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; CRMEB]]></copyright><item><title><![CDATA[老商城加功能，测试补不齐怎么动手]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/169943415</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/169943415</guid><author>CRMEB</author><pubDate>Tue, 03 Nov 2026 14:50:39 +0800</pubDate><description><![CDATA[我习惯不动老代码，先把新功能挂在新包里，入口单独开。动手前画一张调用图：从新入口进去，会读到哪几张表、会调到哪些老接口。砍价活动要读商品、要写订单，订单创建那一段是老逻辑，我就把它的入参出参先抄一遍，确认哪些字段是外部传的、哪些是内部算的。接手过一个跑了两三年的老商城，需求是加好友砍价功能。打开工程我就心里一凉：Controller 层几百个接口，Service 里一个类两千多行，测试目录基本是空的。这种项目加功能，代码写完只是开始，怎么保证不把老流程带崩，才是费精力的地方。]]></description><category></category></item><item><title><![CDATA[代码评审时，我在电商项目里常提哪几个问题]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/169455088</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/169455088</guid><author>CRMEB</author><pubDate>Thu, 29 Oct 2026 14:09:12 +0800</pubDate><description><![CDATA[提得比较多的是金额计算。电商里到处是钱：商品价、优惠价、实付、运费、退款。用 double 做加减乘除，遇到小数就出精度问题；我一般会问三个问题：单位是元还是分、全程有没有统一、舍入规则写没写。单位混用是个隐性炸弹，页面上传的是元、库里存的是分，中间某一环漏乘一百，对账的时候能对到天亮。带电商项目这几年，代码评审是我一直在做的环节。早期把它当走过场，后来提的问题越来越集中，慢慢沉淀出自己的一张清单。这里说的都是我在实际评审里反复遇到的问题，不涉及具体业务，供参考。]]></description><category></category></item><item><title><![CDATA[多端登录态统一，商城场景下的实践]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/169356917</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/169356917</guid><author>CRMEB</author><pubDate>Wed, 28 Oct 2026 14:08:54 +0800</pubDate><description><![CDATA[先是小程序，然后是 App，再往后是 H5 和运营后台。我踩过的坑是：每个端各接一套登录态，token 格式不一样，过期逻辑各写一遍，用户在一端改了密码，另一端还在正常刷订单。多端复用同一份身份信息，但 token 必须能分辨是从哪来、在哪台设备上。顺带说一句，端类型的枚举要收敛。我见过一个项目，小程序一会儿叫 mini，一会儿叫 weapp，还有 wx-mini，查问题时逐个对暗号。小程序偏长，App 随卸载而终，后台跟着员工离职走。端类型不同，续期策略和失效要求根本不是一回事。]]></description><category></category></item><item><title><![CDATA[后台报表导出，数据量大时的两个办法]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/169251334</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/169251334</guid><author>CRMEB</author><pubDate>Tue, 27 Oct 2026 11:23:59 +0800</pubDate><description><![CDATA[早期我们图省事，导出逻辑直接写在 Controller 里，查询、拼装、写文件一条线走完。现在的做法是拆成三步：接口只负责接单，把导出条件写进任务表，返回一个任务 ID；前端轮询任务状态，完成后再给下载地址。后台报表导出这件事，我踩过的坑比写过的功能还多。最早做商城项目的时候，订单表涨到几百万行，运营点了一下「导出全部」，接口直接把内存打满，服务挂了半小时。后来再遇到类似需求，我都会先把两个问题想清楚：数据从哪来，写到哪去。我一般的习惯是任务表里带上创建人、查询条件快照和文件路径，排查问题时能直接复现。]]></description><category></category></item><item><title><![CDATA[商城数据迁移，停机窗口只有两小时怎么办]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/169151047</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/169151047</guid><author>CRMEB</author><pubDate>Mon, 26 Oct 2026 11:24:44 +0800</pubDate><description><![CDATA[做过几次商城系统的数据迁移，我慢慢摸出一个规律：真正决定成败的，不是停机那两个小时里做了什么，而是窗口开始之前准备了多少东西。去年接了个活，老商城要从单库迁到新实例，对方给的窗口就是两小时，超时按事故算。两小时听起来短，但如果前面功课做足，切换动作本身半小时就能收尾。订单表往往是重头，一年以上的库很容易到千万级。我的习惯是只迁近两年的活跃数据，更早的走归档库或离线备份。这一步省下来的时间，经常是几个小时级别的。我的做法是提前写好核对脚本：两边行数对得上，关键字段的汇总值一致，再抽样几条订单逐字段比对。]]></description><category></category></item><item><title><![CDATA[对接微信支付，回调通知要当心重复]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/168864008</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/168864008</guid><author>CRMEB</author><pubDate>Fri, 23 Oct 2026 11:25:00 +0800</pubDate><description><![CDATA[微信支付的结果通知不是只来一次。按官方文档的策略，商户没有正确应答时，通知会按一定间隔重复推送，持续一天以上。也就是说，重复回调是这套机制设计上的常态，不是异常，对接时就得按"一定会重复"来做预案。支付联调时我踩过一个印象很深的坑：用户明明付了款，订单却显示未支付；还有一单更离谱，积分加了两次，仓库发了两个包裹。排查到最后，问题都不在支付本身，而在回调通知的处理上。很多初版实现把回调当成"支付成功事件"来处理：收到通知，直接改订单状态、加积分、通知仓库发货。只来一条没事，连着来几条就全乱套。]]></description><category></category></item><item><title><![CDATA[库存超卖这件事，代码层面怎么兜住]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/168754049</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/168754049</guid><author>CRMEB</author><pubDate>Thu, 22 Oct 2026 11:25:12 +0800</pubDate><description><![CDATA[先说一套很常见的写法。很多项目里扣库存分两步：先查一下当前库存，判断够不够，够的话再执行更新。单线程环境下这套逻辑没毛病，一旦并发进来，两个请求可能同时查到"还剩 1 件"，然后都通过了判断，库存就扣成了负数。促销那晚，用户拍下商品，支付成功，仓库却说没货。这种事故我踩过，复盘来复盘去，问题都落在库存扣减这一个动作上。]]></description><category></category></item><item><title><![CDATA[优惠券叠加规则，先想清楚互斥再动手]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/168645233</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/168645233</guid><author>CRMEB</author><pubDate>Wed, 21 Oct 2026 11:25:32 +0800</pubDate><description><![CDATA[先说一种常见的情况。用户手里有张满 100 减 20 的店铺券，购物车里正好 100 块，结账的时候又自动带出一张品类券。两张券能不能一起用？能用的话，先减哪张？减完还算不算满 100？这几个问题没在需求阶段问清楚，到头来受罪的还是写代码的人。做电商的，优惠券这东西看着简单，真正写代码的时候才知道里面全是坑。我踩过的一个大坑，就是叠加规则没提前想清楚，等运营在后台配出一个明显翻车的价格，半夜被叫起来查数据。]]></description><category></category></item><item><title><![CDATA[购物车结算，价格计算放在哪一层更合理]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/168542458</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/168542458</guid><author>CRMEB</author><pubDate>Tue, 20 Oct 2026 11:24:38 +0800</pubDate><description><![CDATA[早年我在一个项目里，把价格逻辑全写在 Controller 层。商品原价、会员折扣、优惠券、运费，一个结算接口三百多行。能跑，但活动一多就出事：小程序端要加一张券，PC 端要改运费规则，同一个接口改三遍，还不敢动老逻辑。后来复盘，问题出在分层上。价格计算本质是业务规则，不是接口参数拼装。Controller 该做的是接参数、鉴权、组装响应；把满减互斥、券的可用性判断塞进去，等于让接口层背了规则引擎的活。购物车看着简单，真到结算环节，价格计算放哪一层，能吵半天。我踩过这个坑，说点实际体会。]]></description><category></category></item><item><title><![CDATA[订单状态机，字段加着加着就乱套了]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/168442542</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/168442542</guid><author>CRMEB</author><pubDate>Mon, 19 Oct 2026 14:24:25 +0800</pubDate><description><![CDATA[最早的设计是一个 status 走天下：0 待付款，1 已付款，2 已发货，3 已完成，4 已取消。感受是状态值本身拆得都不算复杂，麻烦的都在边界上：订单状态和售后单谁说了算，取消时库存和优惠券怎么回补，这些细节才真正花时间。支付渠道是微信还是支付宝，这是事实，该进单独字段。售后中到底是订单状态还是售后单的状态，也要拆开——一个订单可以挂着一条已关闭的售后记录，同时正常往下走。我见过一套代码，同一个含义在表里叫 pay_status，DTO 里叫 payState，前端叫 zhifu，三份映射靠人肉对。]]></description><category></category></item><item><title><![CDATA[商品 SKU 设计，从简单规格到多规格踩过什么]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/168139405</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/168139405</guid><author>CRMEB</author><pubDate>Fri, 16 Oct 2026 16:23:39 +0800</pubDate><description><![CDATA[我踩过的一个坑，是把 SPU 和 SKU 混成一团。SPU 是"这款卫衣"，SKU 是"这款卫衣的红色 L 码"。混在一起的表现就是：改个商品标题要批量更新几十行库存记录，加一个规格维度要改表结构。做商城绕不开的模型就是商品。起初我们的表特别简单：一张商品表，名称、价格、库存全塞在里面，跑得挺开心。直到运营说要上"红色 L 码"这种组合，才发现一个商品到底怎么定义，之前根本没想清楚。后来拆成商品表、规格表、SKU 表三层，各管各的，才清爽下来。]]></description><category></category></item><item><title><![CDATA[商城系统选型，我把开源和自研算了两笔账]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/168138709</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/168138709</guid><author>CRMEB</author><pubDate>Fri, 16 Oct 2026 15:59:06 +0800</pubDate><description><![CDATA[第一笔账是开发成本。自研看起来可控，就是把需求交给内部团队排期，但真正开工以后，商品、订单、会员、营销这几块没有一块是省油的灯。一个能跑起来的最小可用版本，前后端加起来投入两个人月以上并不稀奇，这还没算测试和试运行的时间。开源路线则是另一本账：基础设施别人已经写完了，你要付的主要是阅读理解的成本，通常几天到两周能跑通主流程。去年公司要做线上商城，我经历过一轮选型。当时摆在桌面上的路主要有两条：自己组团队从零开发，或者基于开源系统做二次开发。我把两条路的成本粗算了一遍，记下来给后面要做类似决策的人参考。]]></description><category></category></item><item><title><![CDATA[前后端技术栈全面换代！CRMEB 多商户（Java）v3.0更新预告]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/167698618</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/167698618</guid><author>CRMEB</author><pubDate>Mon, 12 Oct 2026 16:29:34 +0800</pubDate><description><![CDATA[后台页面加载更快、操作更流畅，代码质量更高、出错概率更低；技术底座全面焕新：管理端（Element）与用户端（uni-app）均升级至 Vue3 + TypeScript，后端 SpringBoot 升级至 4.1、JDK 升级至 21，整套系统更快、更稳、更能打；用户端（uni-app多端框架）：H5、小程序、APP同样升级至Vue3 + TypeScript，用户端页面渲染更快、交互更顺滑，多端体验与维护效率同步提升。做多商户平台电商，生意越好，系统压力也越大：商户多了、订单也多、用户生成的内容更多。]]></description><category></category></item><item><title><![CDATA[前后端技术栈全面换代！CRMEB 多商户（Java）v3.0更新预告]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/167390274</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/167390274</guid><author>CRMEB</author><pubDate>Fri, 09 Oct 2026 16:17:50 +0800</pubDate><description><![CDATA[后台页面加载更快、操作更流畅，代码质量更高、出错概率更低；技术底座全面焕新：管理端（Element）与用户端（uni-app）均升级至 Vue3 + TypeScript，后端 SpringBoot 升级至 4.1、JDK 升级至 21，整套系统更快、更稳、更能打；用户端（uni-app多端框架）：H5、小程序、APP同样升级至Vue3 + TypeScript，用户端页面渲染更快、交互更顺滑，多端体验与维护效率同步提升。做多商户平台电商，生意越好，系统压力也越大：商户多了、订单也多、用户生成的内容更多。]]></description><category></category></item><item><title><![CDATA[买 SaaS 还是买源码？连锁门店系统的三年成本账]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/164398191</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/164398191</guid><author>CRMEB</author><pubDate>Sat, 05 Sep 2026 11:16:05 +0800</pubDate><description><![CDATA[<think>我们根据用户指令，需要生成文章摘要，字数限制≤150字。文章内容主要讲SaaS vs源码私有化部署的选择，基于门店数量和年限。需要浓缩核心观点：结论、临界点、选择建议。摘要应该简洁，涵盖关键信息。 注意：用户要求“根据以下内容，生成≤150字的文章摘要”，我们要从长文中提炼要点。摘要不要代码块或图片描述。字数严格≤150字。中文。 我们需要包括：门店≤5家或3年内不扩张用SaaS；门店>8家或长期用源码总成本更低；关键看重复付费；第四年成本差异；迁移成本考虑；数据所有权等。但摘要要非常精炼。 ]]></description><category></category></item><item><title><![CDATA[多门店、多商户、标准版商城，到底差在哪]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/164398179</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/164398179</guid><author>CRMEB</author><pubDate>Sat, 05 Sep 2026 11:15:09 +0800</pubDate><description><![CDATA[<think>我们根据要求生成摘要，不超过150字。内容核心是三类产品线的区分标准：货是谁的、谁交付、谁收钱。标准版B2C，多商户平台，多门店连锁。还要提避坑和自检。需要精简。</think>摘要：判断产品线不看功能多寡，而看货权、交付与分账。标准版自产自销，多商户招第三方卖家抽佣，多门店管同品牌线下门店的预约与核销。私域直播选Pro。自检三问：有第三方开店选多商户；需线下排班核销选多门店；只自己卖货用标准版。]]></description><category></category></item><item><title><![CDATA[CRMEB标准版系统（Java）v3.1公测版发布]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/164223249</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/164223249</guid><author>CRMEB</author><pubDate>Mon, 31 Aug 2026 16:44:21 +0800</pubDate><description><![CDATA[<think>我们只需要根据内容生成摘要，不超过150字。内容是关于CRMEB标准版系统v3.1公测版的发布，主要升级点：前后台升级Vue3，性能提升；新增移动端商家管理；订单支付、系统安全、主题装修等30+优化。摘要要简洁概括。注意字数。</think>CRMEB标准版系统v3.1公测版发布，前后台全面升级Vue3，操作流畅度与稳定性大幅提升；新增移动端商家管理，支持随时随地处理订单、修改商品、核销及用户维护；并优化订单支付、安全管理、主题装修等30余项细节。]]></description><category></category></item><item><title><![CDATA[CRMEB多商户系统（Java）v2.4公测版发布]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/164216863</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/164216863</guid><author>CRMEB</author><pubDate>Mon, 31 Aug 2026 15:10:06 +0800</pubDate><description><![CDATA[<think>我们根据提供的内容生成文章摘要，要求≤150字。核心要点：CRMEB多商户系统Java v2.4公测版发布，重点新增自动分账（对接微信支付收付通，实现跨店合单支付、自动分账、分账记录、退款原路返还等）和库存管理（出入库单自动生成、盘点暂存、良残转换、上下限预警、多规格联动等）；同时优化分类页样式、定时上下架、未发货退款免审等功能。需简洁概括。</think>CRMEB多商户系统（Java）v2.4公测版发布，重点新增自动分账与库存管理。自动分账对接微信支付收付通，支持跨店合单支付、智能分账、分]]></description><category></category></item><item><title><![CDATA[不懂设计也能有精美商城？CRMEB 主题广场与可视化装修的“千店千面“实操]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/164147652</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/164147652</guid><author>CRMEB</author><pubDate>Fri, 28 Aug 2026 15:41:02 +0800</pubDate><description><![CDATA[CRMEB 的主题广场（crmeb.com/theme）把官方和社区做好的精美模板开放一键下载导入，再配合后台 20+ 装修组件的可视化拖拽，做到"3 分钟换装、千店千面"。真实场景：一个新开的食品小程序商城，店主不懂设计，进主题广场挑一个食品类模板，下载导入，首页立刻有模有样，当天就能上架商品开卖。真实场景：一家连锁茶饮，平日用清新绿主题，会员日切暖橙主题，春节切红金主题——节庆感有了，品牌识别还在。对比请设计外包：过去是"提需求—等排期—改两版—上线"，现在半天闭环，设计费也省了。]]></description><category></category></item><item><title><![CDATA[连锁品牌如何用 CRMEB 多门店系统管住几百家店？三级管控+跨店核销拆解]]></title><link>https://blog.youkuaiyun.com/CRMEB/article/details/164147627</link><guid>https://blog.youkuaiyun.com/CRMEB/article/details/164147627</guid><author>CRMEB</author><pubDate>Fri, 28 Aug 2026 15:40:12 +0800</pubDate><description><![CDATA[CRMEB 连锁多门店系统用"总部—区域—门店"三级管控，加上跨店核销、智能导购、微信服务商分账和数据驾驶舱，把这几件事收进一个系统里解决。A：CRMEB 多门店系统管"连锁门店的门店、收银、会员、分账"；真实场景：一个全国美业连锁，总部统一发"会员日"活动，华东区针对本地商圈加一层满减，单店再挂自己的技师排班——三级各管一段，活动当周就能全国落地，不用总部逐个店沟通。真实场景：加盟门店每笔交易，系统按"总部抽 X%、门店得 Y%"自动分账，门店当天看到自己到账，总部月底汇总，不再月初熬通宵对账单。]]></description><category></category></item></channel></rss>