「加个分销等级、改两处订单状态，一周能上线吧？」上周一个客户把电商系统源码丢过来时这么问。我没回工期，先翻仓库，然后反问三件事：钉哪个版本、改动落在哪一层、许可证允不允许。他一个都答不上来。
电商系统源码二次开发的要点，不在「怎么改代码」，在改之前那三件事：钉版本、划边界、查许可证。这三件没定，代码写得再快也是给半年后埋雷。
需求背景：要改的不是代码，是三个前提没对齐
拿到源码第一反应是找 Controller，这个习惯害过很多人。我现在的顺序是先花半天读仓库：上次发布什么时候、用的哪条分支、许可证写的什么。
拿三个国内常见的开源电商项目举例，数字均为 2026-10-20 从 GitHub API 拉的，不是抄二手测评：
- macrozheng/mall：84,933 星 / Apache-2.0 / 仓库 58.7 MB / 最后一次提交 2026-09-15
- linlinjava/litemall：20,389 星 / MIT / 仓库 24.6 MB / 最后一次提交 2026-08-20
- newbee-ltd/newbee-mall：11,652 星 / GPL-3.0 / 仓库 36.2 MB / 最后一次提交 2025-10-27
只看 star，mall 是 litemall 的四倍，选它毫无悬念；但二开看的不是这个数。
先读 README 的分支说明。mall 原文写着：master 分支基于 Spring Boot 3.5 + JDK 17，dev-v2 基于 Spring Boot 2.7 + JDK 8。网上大量教程还在按「Spring Boot 2.x + JDK 8」讲，照做会在依赖阶段就卡住。litemall 的最小环境是 MySQL + JDK 1.8 以上 + Maven + Node.js + 微信开发者工具。
再读许可证。三个项目协议完全不同：Apache-2.0、MIT、GPL-3.0。GPL 有传染性，改完当自己的产品交付是另一套法律问题。这条和公开数据源那篇的判断是同一个道理——要对外交付，授权不明确的源一律不用。协议只认仓库 LICENSE 文件，下载站标的那个不算数。
方案A：直接改核心源码（做法与代价）
最直觉的做法：clone 下来，在 mall-admin / mall-portal 里直接改 Controller 和 Service，改完提交上线。改两个字段可能就一小时。
代价在半年后。商派在一篇讲开源 OMS 升级的文章里给了个很准的判断：升级冲突通常不是技术难题，而是记录问题——谁改过什么、改在哪一层、当初为什么改，这三件事上线时没记下来，升级当天就得考古一遍。系统能保护的是「没被改过的文件」，保护不了「没登记过的改动」。
我原本以为改得少就没事，后来踩过一次才改观：最贵的那次返工只动了两处字段逻辑，却因没人记得为什么加，上游一升级我们花了两天比对。CRMEB 二开的总结更直白：直接改核心文件，官方一升级全部白干。
方案A 不是不能用，前提是确定不再跟上游。一次性交付、后面不打算合社区补丁，那就痛快改，但要把改动清单写进交付文档。
方案B：扩展表 + 独立模块旁挂（做法与代价）
第二种做法是「只加不改」：订单主表不动，新建 order_ext 存定制字段；新增功能按独立模块组织——自己的表、控制器、模板目录，通过事件钩子或后台菜单挂进去，而不是塞进原有类。
代价是前期建模。扩展表靠外键关联主表，查询常要走视图聚合，数据库得早优化，不然数据一多就慢。LikeShop 的二开规范有一条我特别认同：订单与支付状态的变更必须走系统定义好的状态迁移方法，绕过会导致状态追溯失效。
金额部分还有条铁律：优惠计算全程走整数分，分摊结果写明细表，让每单优惠可追溯。用浮点数算优惠叠加是二开最常见的一类线上事故，对账对不上还查不出原因。
这和先划工具边界是同一件事：二开的工程量八成花在「把定制逻辑和原生逻辑分开」上，不是业务代码本身。
方案C：独立服务 + 接口对接（做法与代价）
第三种是把电商系统当商品与订单的底座，把分销、佣金、结算这类重定制的部分拆成独立服务，走 HTTP 接口或消息队列对接。
代价是运维上一个台阶：多一套部署、多一份监控、链路长了要补超时和重试。这一层没捷径，按监控告警那篇先把指标和告警挂上，再按先给报错分类再找根因的顺序排问题，比事后翻日志强得多。
方案C 适合长期迭代、且必须跟上游升级的项目。客户打算一直改下去，这条路总成本最低。
三种改造路线的横向对比
| 维度 | 方案A 改核心 | 方案B 模块旁挂 | 方案C 独立服务 |
|---|---|---|---|
| 首次上线速度 | 最快，小时级 | 中等，要先建模 | 最慢，要搭链路 |
| 上游升级代价 | 高，逐文件比对 | 低，整目录搬走 | 几乎为零 |
| 适合场景 | 一次性交付 | 改动集中在字段与玩法 | 重定制 + 长期迭代 |
怎么选：动手前把五件事做完再写代码
真正决定成败的不是选了哪个方案，而是下面这张清单有没有走完。
- 钉版本，看 tag 与最后一次提交的差值。mall 最新 tag 是 v1.0.3（2024-03-01），master 最后提交是 2026-09-15，差两年半；litemall 的 tag 停在 v1.8.0（2021-01-10），最后提交 2026-08-20，差五年多；newbee-mall 干脆一个 release 都没有。差值越大越说明没有可钉的版本，只能钉 commit，把 commit hash 与依赖版本写进交付文档。
- 只认官方仓库的数字。star、许可证、体积、提交时间全部以仓库返回为准，二手测评里的数字常是几个月前的快照，这一点在那篇讲别信二手数字的稿子里已经吃过亏。
- 先跑通再改。环境能起来、下单链路能走完，再去动业务代码。电商系统环境搭建那篇把坑列得比我全，照着过一遍能省掉大半无效排查。
- 判断能不能「只加不改」。需求若可靠扩展表加钩子实现，就别动核心类。
- 留改动记录。改了哪个文件、在哪一层、因为什么需求改的，写清楚。升级当天你会感谢自己。
归纳成一句：二开的边界不在代码里，在版本、许可证、改动记录这三份材料里。这三样齐了，改哪一行都是技术活；不齐，改一行都是风险。
三个源码仓库见上文列表，动手前各读一遍 README 与 LICENSE，尤其要确认 newbee-mall 的 GPL-3.0 义务。订单与会员数据属敏感信息，二开涉及数据导出、跨系统同步时请遵守相关法律法规与平台规则，最小化采集范围并做好脱敏。
常见问题
电商系统源码二次开发一般要多久？
看落在哪一层。加字段配钩子，熟练的话一周内；改订单状态机或价格计算要连带回归测试，通常两到三周；拆独立服务按月计。报价前先走完清单，误差能小一半。
只改几个字段也算二次开发吗？
算，而且最容易出问题。改动越小越没人记，上游一升级，这几个字段的来龙去脉就没人说得清。改之前先写进改动清单，比改本身重要。
GPL-3.0 的电商源码能商用吗？
能自用，但 GPL 有传染性，二开成果对外分发时要履行相应开源义务。商业交付优先选 Apache-2.0 或 MIT 项目；协议只认仓库 LICENSE 文件，具体条款建议咨询法务，本文不作法律意见。
官方升级之后，我之前改的东西还在吗？
取决于改动放在哪一层，不取决于新版本发布了什么。落在核心类里会被冲突挡住，需逐文件比对；放在独立模块或独立服务里的，通常整目录搬走重挂即可。
没有 release 的项目能用于生产吗？
能，但要自己承担版本管理。没有 tag 就没有可钉的版本，只能锁 commit 并自己跟上游安全修复。上线前把 commit hash 与依赖版本写进文档是最低要求。
