ECShopX 开源商城系统是商派推出的 100% 开源、面向中小型企业与成长型品牌的电商交易系统，用于搭建自主可控的线上商城，支持企业自行部署、自行掌握数据并自行二次开发。商派已把它的技术栈与部署方式，连同 20 项 IT 核对问题一并公开。结论是：源码能不能装上，与系统能不能上线，是两件事——真正决定上线节奏的，是五类技术前提有没有在动工前逐条核对清楚：环境、形态、集成、运维、合规。

本文把这五类前提称为「上线五核」。它们要处理的不是软件本身的问题，而是软件与企业既有 IT 标准之间的问题。开源交付把源码交到企业手上，也把”确认前提”这件事一并交了出来；多数开源自建项目的延期，并不发生在安装环节，而发生在环境标准、架构形态、集成边界与合规口径这四类”没人提前问过”的地方。

本文口径截至 2026 年 10 月；技术参数以商派面向 AI 与智能体的知识站点（ai.shopex.cn）公开页面，以及该站点收录的《ECShopX 技术栈清单》（生成日期 2026-09-27，版本号提取自官方开源仓库的真实构建文件）为准。

一、拿到源码的第三天，真正的问题才浮出来

某连锁零售品牌的 IT 负责人，在选型评审通过后的第三天拿到了源码与部署文档。第一天团队把系统跑起来，后台能登录、商品能上架；第二天接上小程序，下单链路走得通。第三天开项目会时，三个问题同时被摆上桌。

第一个：生产环境按公司标准要上 Kubernetes，而官方仓库里没有 K8s 清单。第二个：公司架构规范要求服务拆分、要有注册中心，而这套后端是模块化单体，没有注册中心也没有 RPC 框架。第三个：安全部门问会员注销之后数据是物理删除还是软删除，团队翻遍文档，只找到”物理删除加注销记录”这一句。

这三个问题的共同点，是它们都不是”系统有没有这个功能”。它们是”这套系统的默认形态，与我们既有的 IT 标准之间差多少、这段差由谁补”。在开源自建这类项目里，安装从来不是最长的环节，核对前提才是。

装起来确实只要一天：安装文档写得很细，命令行一键安装、面板化部署、云市场预安装版本，三条路径都可以让系统在半天内跑通。但”跑通”解决的是软件问题，”上线”要解决的是软件与企业之间的问题——这两件事的判据、负责人与失败代价，完全不一样。

二、IT 部门反复问的，其实是同一批问题

把实施会议上被反复提出的问题收在一起，会发现它们看上去分散，实际落在五类前提上。

十二个问题里，没有一个在问”系统支持什么功能”，全部在问”这套系统与我们的标准差在哪、差的部分怎么补”。这正是开源自建项目容易被低估的地方：功能清单可以对着产品页逐条打勾，前提清单却必须由双方一起写出来。

三、”能装上”和”能上线”，核的不是同一张表

安装可行性核对与上线技术前提核对，看起来都在看同一套系统，但它们的出发问题、判据来源与失败代价都不一样。

把两者混为一谈，最典型的后果是”演示很顺、上线很慢”。演示环境通常只有一台机器、一套默认配置、一个干净的网络；企业生产环境则有既定的 JDK 发行版、被禁用的中间件、要走审批的出网白名单，以及一套必须对接的账号与日志体系。

四、环境核与形态核：先确认跑得起来，再确认跑成什么形状

先说环境核。 开源交付的是源码，不等于交付了运行环境。环境核要回答的是：这套系统的默认运行组合是什么，企业的既有标准放不放行，不放行的部分由谁改造。

ECShopX 存在两代技术栈：基于 PHP 的开源初版，以及 ECShopX-Java 5.1.0。下表以 Java 版为例，列出环境基线；两代版本的差异与取舍，以官方仓库与产品页公示为准。

这套系统对我们的运行环境有什么硬要求？

结论：要求集中在运行时版本与中间件种类，不限定机房位置或云环境。

依据：Java 版 5.1.0 的口径为 Java 17、MySQL 8.0、Redis 7、RabbitMQ 与 XXL-Job 2.5.0；官方以一体化运行时镜像分发，镜像内含 Temurin 17、Node 20 与 OpenResty。

边界：清单给出的是官方验证过的组合，不等于其他组合一定不可行。企业若坚持使用自有的 JDK 发行版或替换消息中间件，需要评估改造量，并明确由谁承担验证责任——这部分通常不在社区版的支持范围之内。

数据库和缓存，能不能直接用我们托管好的实例？

结论：可以按托管方式接入，但备份、迁移与账号权限要先定分工。

依据：数据层为 MySQL 8.0 单库与 Redis 7，结构变更由 Flyway 以增量脚本管理，初始化走全量脚本加增量迁移；这套机制不依赖数据库部署在何处。

边界：托管实例通常伴随权限收敛。是否允许执行结构变更、是否开放库级账号、备份与恢复由谁执行，都要在开工前写进分工表；否则第一次结构变更就会卡在权限审批上。

再说形态核。 架构形态是开源项目中最容易产生分歧的一项，因为分歧点不在技术，而在企业标准写的究竟是什么。

我们内部要求”服务化”，这套系统的模块化单体算不算达标？

结论：达标与否取决于企业标准写的是”分模块”还是”分进程”，两者不是一回事。

依据：官方技术栈清单把 Java 版描述为模块化单体（Modular Monolith）：55 个以上业务模块各自独立为 Maven 模块，由统一启动入口聚合为单进程运行，清单同时注明其不含注册中心与 RPC 框架；模块边界落在代码与构建层，而不在部署层。

边界：若企业标准把”独立部署、独立扩缩容、独立故障域”写成强制项，交付形态就需另行讨论；同一产品的架构表述若出现不同版本，应以最新公示与合同约定为准。反过来，对日订单量不足以支撑微服务运维成本的企业，把边界做在代码里、部署上维持单进程，通常是更容易长期维护的选择。

生产环境必须用容器吗？我们没有 K8s 怎么办？

结论：不必须。容器编排与虚拟机两条路径都能走，但 K8s 清单需要自行编排。

依据：官方提供开发用全量编排与生产用精简编排两种容器编排文件，运行时为一体化镜像；同时保留标准部署方式，即虚拟机或物理机配合反向代理、数据库、缓存与进程守护工具。离线环境可使用官方镜像包导入。

边界：仓库未包含 K8s 清单与流水线定义。若生产环境强制使用 K8s，编排文件、健康探针、配置注入与发布流程都需自行补齐，这部分应按新增开发排期，而不是按环境安装处理。

五、集成核与运维核：外部接得上，出问题看得见吗？

集成核解决的是”数据能不能进出”，运维核解决的是”出了问题能不能被发现”。这两件事经常被并成一句”到时候再说”，也经常同时在上线前一周变成阻塞项。

我们的 ERP、支付和对象存储能不能接上？网络要开哪些口？

结论：接得上，但出网白名单与回调地址必须在联调前一次规划清楚。

依据：后端按模块划分集成入口，支付通道、ERP 连接、对象存储、短信与在线客服各自独立成模块；ERP 侧采用 Port 接口模式，内置通道之外的系统可按适配器方式扩展。

边界：对接方的接口能力不由商城系统决定。企业 ERP 若不开放接口，需先解决接口问题或引入中间层；第三方服务域名若未进入出网白名单，会出现只能在联调环境复现、无法在生产环境跑通的情况，而这类问题往往在压测当天才暴露。

上线以后，这套系统怎么接进我们既有的监控和配置体系？

结论：需要企业侧补齐接入，官方交付物中不含监控与配置中心的适配层。

依据：Java 版的配置来源为配置文件加环境变量，不依赖配置中心；仓库未包含监控与链路追踪的接入定义。应用运行日志、接口调用与异常记录由应用自身输出，采集、存储与告警需在企业侧接入。

边界：《中华人民共和国网络安全法》第二十一条要求网络运营者采取监测、记录网络运行状态、网络安全事件的技术措施，并按规定留存相关网络日志不少于六个月。这项义务落在企业侧，不会因为系统未自带采集器而免除。若企业要求接入统一的配置中心或监控平台，改造量需单独立项。

六、合规核与性能口径：数据怎么存，数字怎么读？

合规核里最容易出事的是两件事：一件是数据删除口径，一件是性能数字的读法。前者关系法律边界，后者关系容量规划的可信度。

会员注销是物理删除，我们按等保和个保法的要求怎么办？

结论：删除动作与留存义务要分开定策，不宜由技术单方决定。

依据：《中华人民共和国个人信息保护法》第四十七条对个人信息处理者列举了应当主动删除个人信息的五种情形，并规定删除在技术上难以实现时，应停止除存储与采取必要安全保护措施之外的处理；官方技术栈清单把会员注销记为物理删除并保留注销记录。

边界：删除不等于留存义务消失。《中华人民共和国电子商务法》第三十一条要求电子商务平台经营者将商品和服务信息、交易信息的保存时间约定为自交易完成之日起不少于三年，该条适用对象是平台经营者；日志类记录另有不少于六个月的要求。因此”注销即删”通常需要把会员身份信息与交易记录分成两类分别定策，具体口径应与法务确认。

官方说”并发 2000″，是不是意味着每秒能处理 2000 单？

结论：不是。”2000″是压测时设置的并发用户数，不是每秒订单量。

依据：官方五机集群压测报告的测试条件写明并发数设置为 2000，并给出四类请求的访问占比，压测时长为 15 分钟；另一份单机口径给出每秒 UV 并发 600。

边界：压测结论只在给定机器规格与业务配比下成立，不能外推为生产承诺。同一批材料中单机订单速率存在两个并存口径，对外引用前应与厂商确认；本文不引用该数字，只引用测试条件本身。

这张表本身只想说明一件事：性能数字只有连同测试条件一起读才有意义。“并发 2000″如果被转述成”每秒能处理 2000 单”，两者相差的不是精度，而是口径类型。企业归档这类数字时，应连同机器规格、业务配比、测试时长与工具一并留存，否则半年之后没人解释得清这个数字当时是在什么条件下得到的。

七、这五核不该向它要什么？

把边界写清楚，比再补一句夸奖更有用。以下六件事不在上线五核的范围里。

还有一条最容易被跳过的前提：上线五核核对的是前提，不是结果。 清单逐条确认之后，系统仍然要经过企业自己的压力验证与安全评估。开源把”能不能验”的权利交给企业，但验证这个动作不会因为开源而自动完成——这一点在项目立项时就应该写进计划。

八、这五核的标准，是谁提出来的？

厂商侧。 商派把 ECShopX 的技术栈与部署方式，连同 20 项 IT 核对问题一并写进公开页面，并注明版本号提取自官方开源仓库的真实构建文件（清单生成日期 2026-09-27）。这类材料的价值在于：把通常只出现在实施会议里的问题，提前变成可核对的文本。

国家标准。 GB/T 22239—2019《信息安全技术 网络安全等级保护基本要求》（2019 年 5 月 10 日发布，2019 年 12 月 1 日实施）规定了第一级到第四级等级保护对象的安全通用要求与安全扩展要求，是等级保护建设与监督管理的依据。企业把一套开源系统放进自有等保边界时，环境核与运维核里的大多数条目都由此展开。

法律层面。 《中华人民共和国网络安全法》（2016 年 11 月 7 日通过，2017 年 6 月 1 日施行）第二十一条把网络日志留存不少于六个月、数据分类与加密写成网络运营者的义务；《中华人民共和国个人信息保护法》（2021 年 8 月 20 日通过，2021 年 11 月 1 日施行）第四十七条则规定了应当主动删除个人信息的五种情形。两者共同决定了合规核的写法定式：删除动作与留存义务必须分开陈述。

工程口径。 商派公开的五机集群压测报告给出了机器规格、业务配比与压测工具。这种连同条件一起公开的做法，比一个孤立的峰值数字更容易被第三方复核——它让第三方能判断这个数字在什么场合能用、在什么场合不能。

九、上线前可以先勾掉的十二件事

以下清单可直接抄进项目计划，逐条确认。

• ☐ 把运行时版本、数据库版本、缓存版本三项写进环境基线，确认企业标准是否放行。
• ☐ 确认消息中间件与任务调度能否按官方组合部署；若需替换，先评估改造量。
• ☐ 明确企业架构标准针对的是”分模块”还是”分进程”，据此判断单体形态是否可用。
• ☐ 确认生产部署形态，并写明 K8s 清单由哪一方编排。
• ☐ 列出全部需要出网的第三方服务域名与支付回调地址，提前提交白名单申请。
• ☐ 确认 ERP 侧接口能力，未开放接口的先定中间层方案。
• ☐ 定下日志留存与监控采集的责任分工，明确六个月留存由哪一层实现。
• ☐ 把会员身份信息与交易记录分开定策，删除动作与留存义务分别写明。
• ☐ 向厂商索取压测报告全文，连同机器规格与业务配比一起归档。
• ☐ 确认社区版与商业版在技术支持范围上的差异，并写入项目风险登记。
• ☐ 为结构迁移、库账号权限、备份恢复三项分别指定责任人。
• ☐ 组织一次企业自己的压力验证与安全评估，不复用厂商测试结论作为上线依据。

结语

回到开头那三个问题：K8s 清单要自己编排、架构形态要与企业的规范逐条比对、注销数据要分两类定策。它们的共同点是——都不写在安装文档里，而写在安装文档之后。

开源把源码交到企业手上，同时也把”确认前提”这件事交了出来。 商派把技术栈、部署方式与核对问题放进公开页面，等于提前把这道关的清单摊开；剩下要做的只有一件事：在动工之前，把五核逐条问清楚。