跳转到内容

进销存源码详解,如何选择适合你的进销存源码?

进销存源码详解,如何选择适合你的进销存源码?

零门槛、免安装!海量模板方案,点击即可,在线试用!

免费试用

进销存源码在本质上就是一套可二次开发的库存与订单管理底层框架。对于中小企业、跨境电商、外贸贸易公司而言,选择合适的进销存源码,不仅关系到采购、销售、库存数据是否准确,更关系到未来能否平滑接入财务、CRM、生产制造甚至跨境物流系统。选择进销存源码时,最关键是看业务适配度、技术栈匹配度、扩展性与安全性,而不是单纯追求“功能越多越好”。一般建议从业务流程复杂度、团队技术能力、预算与上线周期四个维度综合评估,再结合源码开源协议、文档质量与社区活跃度,做出稳健决策。对于希望快速落地、低门槛上手的团队,可以优先考虑低代码/无代码平台搭建的进销存模板,在源码开放、可配置、可自定义的前提下,降低研发与运维成本。

《进销存源码详解,如何选择适合你的进销存源码?》


😎 一、什么是进销存源码?核心概念与价值

1.1 进销存源码的定义

  • 进销存系统:采购(进)、销售(销)、库存(存)一体化管理系统,用来记录订单、入库、出库、退货、调拨等业务。
  • 进销存源码(Source Code):构建这一系统的完整程序代码与相关配置,包括后端服务、前端界面、数据库脚本、API 接口等,可由企业或开发者自行部署与二次开发。

常见形态:

  • 完整开源项目(如 GitHub 上的 ERP/Inventory 项目)
  • 商业源码授权(付费获取完整源代码)
  • 低代码平台导出的进销存项目源码或可视化逻辑

1.2 使用进销存源码的典型场景

  1. 跨境电商/独立站卖家
  • 多仓、多平台订单同步
  • 海外仓库存管理
  • 自动生成采购建议
  1. 中小贸易公司
  • 多币种报价、收款
  • 应收应付对账
  • 简易报表快速出数
  1. 轻量制造/加工企业
  • 原材料入库、半成品/成品出库
  • 简单生产领料与成本估算
  • 与财务记账对接
  1. 线下批发零售
  • 门店库存、批次/有效期管理
  • POS 销售数据回传
  • 会员与价格策略管理(可扩展)

在这些场景中,使用进销存源码的价值主要在于:

  • 自主掌控核心业务系统,不受 SaaS 限制;
  • 支持高度定制化流程;
  • 可与现有的财务、MES、WMS、CRM 等系统深度集成;
  • 降低长期许可证费用(尤其多分公司/多实例部署时)。

😃 二、进销存源码的架构组成:从前端到数据库

选择进销存源码前,必须清楚它大致由哪些部分构成,这有助于评估可维护性与扩展性。

2.1 典型技术架构分层

常见进销存源码架构分为四层:

层级主要内容常见技术栈示例(国外)
表现层(前端)Web、移动端界面,报表可视化React、Vue.js、Angular、Flutter、React Native
应用层(后端)业务逻辑、接口服务、权限控制Node.js(Express/NestJS)、Java(Spring Boot)、.NET Core、Python(Django/Flask)
数据层数据库存储、缓存MySQL、PostgreSQL、SQL Server、MongoDB、Redis
集成层第三方接口、消息队列、外部系统对接REST API、GraphQL、gRPC、RabbitMQ、Kafka

2.2 核心模块说明

主要模块往往是源码结构中的“骨架”:

  1. 基础资料(Master Data)
  • 产品档案(SKU、条码、规格、单位)
  • 客户档案、供应商档案
  • 仓库、库区、货位
  • 价格表、税率、币种等
  1. 采购管理模块
  • 采购申请、采购订单
  • 采购入库、采购退货
  • 供应商对账单
  • 与应付账款衔接(可选)
  1. 销售管理模块
  • 报价单、销售订单
  • 出库单、销售退货
  • 配送/发货单
  • 与应收账款衔接(可选)
  1. 库存管理模块
  • 入库、出库、调拨
  • 库存盘点、盈亏调整
  • 批次/序列号/保质期管理
  • 多仓、多公司库存统计
  1. 报表与分析
  • 销售报表、采购报表
  • 库存报表(库存余额、周转率)
  • 毛利分析、畅销/滞销分析
  1. 权限与审计
  • 角色权限(RBAC)
  • 操作日志与审计
  • 单据审批流(可配置)

2.3 源码层面的关键设计点

当你打开一个进销存源码项目时,重点关注:

  • 模块解耦程度:是否易于拆分为独立服务或模块;
  • 领域模型是否清晰:如 Order、Inventory、Warehouse、Customer 等实体是否建模规范;
  • 数据库设计:表结构是否规范,有无冗余字段、命名是否统一;
  • 代码注释与文档:是否有清晰的 README、API 文档、部署指南;
  • 测试用例:单元测试/集成测试覆盖率如何。

这些因素直接影响后续二次开发成本。


😄 三、常见进销存源码技术栈与国外项目案例

3.1 主流技术栈对比

技术栈组合优点适用团队类型
Java + Spring Boot企业级稳定、生态成熟、多中大型案例有 Java 背景的企业技术团队
.NET Core + SQL Server与微软生态兼容好、Windows 环境友好使用 Microsoft 技术栈的公司
Node.js + MongoDB开发效率高、适合实时性较高的场景追求快速迭代、喜欢 JS 全栈的团队
Python + Django开发快速、ORM 强大数据分析驱动团队、小型开发团队
PHP + Laravel部署简单、服务器成本低中小企业网站/系统一体化团队
Go + MySQL性能好、并发强对性能有要求且有 Go 能力的团队

3.2 国外进销存/ERP 类开源项目(示例)

以下皆为国外知名项目或社区项目(需自行评估是否适合作为进销存源码基础):

  1. Odoo(原 OpenERP)
  • 技术:Python + PostgreSQL
  • 特点:模块化 ERP,含销售、采购、库存、会计等。
  • 优点:功能全面、社区活跃、插件丰富;
  • 注意:功能复杂、上手学习成本高。
  1. ERPNext
  • 技术:Python(Frappe 框架)+ MariaDB
  • 特点:适合中小企业的 ERP,自带进销存模块。
  • 优点:界面现代化、安装相对简单;
  • 注意:定制需了解 Frappe 框架。
  1. Dolibarr ERP & CRM
  • 技术:PHP + MySQL
  • 特点:轻量级 ERP/CRM,含基础进销存功能。
  • 优点:部署简单、对小团队友好;
  • 注意:二次开发结构化程度一般。
  1. Simple Inventory Management Systems(GitHub 多个开源项目)
  • 技术:多种(Node.js、Java、Laravel 等)
  • 特点:功能较简单,适合作为学习和二开基础。
  • 优点:结构清晰,便于阅读源码;
  • 注意:生产可用性需慎重评估。

使用这些国外源码的典型方式:

  • 直接部署为企业进销存系统;
  • 做为二次开发的基础框架;
  • 抽取其中库存、订单模块,整合到现有系统中。

😆 四、选择进销存源码前必须搞清楚的需求

4.1 业务需求自检清单

从业务角度,先回答这些问题:

  1. 你现在的业务类型?
  • 纯贸易?电商?多渠道(线上+线下)?轻制造?
  1. 仓库数量与分布?
  • 单仓?多仓?海外仓?第三方仓(3PL)?
  1. 产品类型及特点?
  • 标品?多规格?有保质期/批次?序列号产品(如电子设备)?
  1. 订单量级?
  • 每日几十单?几百单?上千单以上?
  1. 是否涉及多币种、多税率?
  2. 是否需要与现有财务系统对接?
  3. 是否有复杂审批流(多级审批、条件审批)?

整理结果后,建议用表格方式列出核心需求:

类别必须需求(Must)可选需求(Nice to have)
采购多供应商、多币种、采购入库、退货供应商评分、采购预测
销售销售订单、发货、退货、折扣多渠道订单整合、会员管理
库存多仓、调拨、盘点、库存预警批次/序列号管理、保质期管理
报表基础销售/库存报表自定义报表、BI 分析
集成导入导出 ExcelAPI 对接平台/物流/财务

4.2 技术需求自检清单

接着再从技术角度评估:

  1. 团队擅长的语言/框架
  • 若团队熟悉 Java,应优先考虑 Java 进销存源码;
  • 若是前端团队较强,可以偏向 Node.js/JavaScript 技栈。
  1. 部署环境与运维条件
  • 仅有一台云服务器?还是有 Kubernetes 集群?
  • 习惯 Linux 还是 Windows?
  1. 安全合规要求
  • 是否涉及敏感数据?是否需合规审计日志?
  • 是否有数据备份与容灾要求?
  1. 上线时间与预算
  • 是否希望 1-2 周内上线 MVP?
  • 预算更多投入在研发还是在长期运维?

这一部分会直接影响你是选择“完全自研源码”还是“基于低代码平台+进销存模板”的方案。


😇 五、如何系统评估一套进销存源码?关键维度对比

下面通过一个多维度评价表,帮助你快速判断一个进销存源码是否“值得选”。

5.1 评估维度总览

维度关键问题重要程度
功能适配度是否覆盖核心进销存业务,扩展功能是否易做★★★★☆
技术栈匹配是否与团队现有技术和运维体系匹配★★★★★
可扩展性模块可拆分性、接口设计是否合理★★★★☆
文档与社区文档完整性、社区活跃度、Issue 回复情况★★★★☆
性能与稳定性是否支持预期订单量,是否有压测/生产经验★★★★☆
安全与合规权限控制、日志审计、数据加密等★★★★★
二开成本学习曲线、代码复杂度、测试覆盖★★★★☆
授权与费用开源协议、商业授权模式★★★★☆

5.2 功能适配度:不要为了“大全套”,忽略真正需求

  • 检查源码是否包含你需要的基础模块:
  • 采购、销售、库存;
  • 报表;
  • 权限与审批;
  • 查看是否支持:
  • 多仓;
  • 多币种;
  • 批次/序列号(如需要);
  • 评估是否容易添加:
  • 定制字段;
  • 定制单据类型;
  • 定制审批流程。

5.3 技术栈与架构匹配度

重点关注:

  1. 语言与框架版本
  • 是否仍有人维护?是否使用过旧版本(如很老的 PHP 版本)?
  1. 依赖库与第三方组件
  • 是否依赖少见或停更的库?
  1. 部署难度
  • 是否提供 Docker Compose/K8s 部署脚本?
  • 是否对数据库、缓存等有明确配置说明?

5.4 可扩展性与集成能力

  • 是否提供标准的 REST API/GraphQL
  • 是否支持 Webhook 或消息队列;
  • 是否有插件或模块化机制(如 Odoo/ERPNext 的 app 模块机制);
  • 是否支持通过配置或低代码方式扩展:

在这一点上,有些企业会选择基于低代码平台的进销存模板,比如使用类似 简道云进销存 这一类可视化搭建方案,通过可配置流程、字段和报表快速构建进销存系统,当标准能力不够时再结合自定义代码或 API 集成,实现较好的扩展性与灵活性。

5.5 文档、社区和维护

  • 文档是否包括:
  • 安装部署;
  • 二次开发指南;
  • API 文档;
  • 社区活跃度:
  • GitHub Star & Issue;
  • 是否有活跃的讨论区/论坛;
  • 更新频率:
  • 最近一次提交时间;
  • 是否支持最新系统/数据库版本。

😋 六、开源进销存源码 vs 商业进销存源码:如何选择?

6.1 开源源码方案

特点:

  • 通常免费(遵循开源协议);
  • 可自由研究修改源码;
  • 适合技术力量较强的团队或有长期自研计划的企业。

优点:

  • 灵活度高,可深度定制;
  • 无强制年度许可证费用;
  • 可自行部署在任意环境(本地/云端)。

潜在成本:

  • 初期学习与二次开发时间长;
  • 若缺乏经验,架构可能被“改坏”;
  • 运维、安全、备份责任完全由企业承担。

6.2 商业源码授权方案

特点:

  • 由软件商提供源码授权;
  • 一般包含一定的技术服务;
  • 适合希望快速上线,又希望掌握源码的企业。

优点:

  • 有官方支持,问题响应较快;
  • ���常有成体系的文档与实施经验;
  • 定制需求可以与厂商协作完成。

注意事项:

  • 注意授权模式:
  • 单次买断?按年维护费?按用户数?
  • 注意源码使用限制:
  • 是否允许二次分发?
  • 是否限制部署节点数量?

6.3 基于低代码/无代码平台的进销存方案

这类方案介于“纯源码”和“纯 SaaS”之间:

  • 使用低代码平台提供的表单、流程、报表能力;
  • 通过进销存模板快速搭建系统;
  • 有的平台支持导出部分配置或逻辑,以“配置+脚本”的形式管理。

在实际应用中,不少企业会选择类似 简道云进销存 这样的进销存模板方案,通过可视化配置采购、销售、库存表单和审批流程,并支持与外部系统对接,从而在不直接管理大量底层代码的前提下,获得接近“源码可控”的可维护性。

对比小结:

类型优点适用对象
纯开源源码自由度高、可深度定制、无授权费有成熟技术团队的中大型企业
商业源码授权官方支持、相对完善、上线快有一定研发能力、重视稳定性的公司
低代码进销存方案配置灵活、上线快、技术门槛低中小企业、快速试错、资源有限团队

😎 七、从源码到上线:搭建进销存系统的完整步骤

7.1 整体实施路径

可以将“从进销存源码到正式上线”拆解为以下步骤:

  1. 需求调研与范围界定
  2. 选型与 PoC(小规模验证)
  3. 源码部署与环境搭建
  4. 功能配置与二次开发
  5. 数据迁移(历史数据导入)
  6. 联调与测试(UAT)
  7. 培训与试运行
  8. 正式上线与运维

7.2 需求梳理与 PoC

  • 梳理关键业务流程:
  • 采购:从请购到入库;
  • 销售:从报价/订单到发货;
  • 库存:入、出、盘点、调拨;
  • 制作几张流程图或时序图,用于与开发团队对齐;
  • 在选定的进销存源码项目中,搭建一个 PoC 环境:
  • 简单配置一个仓库;
  • 新建商品档案;
  • 录入一张采购和销售单,查看库存变化。

7.3 源码部署与环境搭建关键点

  • 建议使用 Git 控制进销存源码版本;
  • 准备环境:
  • 应用服务器(Linux/Windows);
  • 数据库服务器(或同机实例);
  • 备份与日志目录;
  • 尽可能使用 Docker 容器化部署:
  • 便于环境复制;
  • 便于测试与生产环境分离;
  • 配置基础安全:
  • 数据库账号权限最小化;
  • 应用配置文件中不要硬编码密码,使用环境变量或更安全的配置方案。

7.4 二次开发与配置要点

在进销存源码基础上进行开发时,建议遵循:

  1. 不直接修改核心框架代码(若有插件机制优先使用插件/模块扩展);
  2. 对于自定义字段、单据类型,尽量通过配置层实现;
  3. 加强单元测试与自动化测试,保证核心流程稳定;
  4. 将自定义代码与原始源码模块分开,以便未来升级原始项目。

对于团队技术资源有限的企业,可以考虑在低代码平台上完成部分业务配置,再通过 API 接入库存计算、订单同步等服务。例如,使用平台提供的进销存模板作为基础,通过配置字段、流程与报表组合实现个性化需求。当标准模板无法覆盖的特殊逻辑较多时,再引入额外的代码服务,这种方式可以降低直接对进销存源码进行大规模修改的风险。


😃 八、进销存源码选择的典型场景策略

8.1 中小贸易公司:轻量需求,快速上线

特点:

  • 订单量不大;
  • 仓库数量有限;
  • 需要基础进销存 + 简单对账。

推荐策略:

  • 优先考虑:
  • 低代码平台 + 进销存模板;
  • 或者轻量级开源项目 + 少量二次开发。
  • 不必追求复杂 ERP 功能;
  • 关注易用性和报表输出效率。

在这类场景中,采用可视化配置的进销存模板能显著缩短上线周期。例如,基于类似简道云进销存的模板,配置产品档案、客户档案、采购订单、销售订单和库存报表,无需从零搭建复杂的后端架构,即可获得一套完整的进销存解决方案,并能按需调整字段和流程。

8.2 跨境电商卖家:多平台、多仓、多币种

特点:

  • 订单来源多平台(独立站、亚马逊、eBay 等);
  • 多国家/地区仓库;
  • 多币种结算与汇率变化。

推荐策略:

  • 选择支持:
  • API 对接;
  • 多仓库存管理;
  • 多币种定价与报表的源码项目;
  • 考虑使用:
  • 后端以微服务方式拆分订单、库存服务;
  • 或在低代码平台中通过 API 集成跨境平台订单。

若你希望减少自研工作,可用低代码平台承接订单管理和部分报表,然后用一个稳定的库存服务作为后台。类似简道云进销存这类模板可以承担基础库存与单据记录,再通过集成接口完成跨平台订单同步与发货数据回传。

8.3 制造企业:原材料、半成品、成品一体化管理

特点:

  • 生产环节多;
  • 成本核算复杂;
  • 需要与 MES/PLM 等系统对接。

推荐策略:

  • 更适合选用:
  • 具备生产管理模块的 ERP 类开源/商业源码;
  • 关注:
  • 物料清单(BOM)支持;
  • 生产领料、工单、完工入库流程。

如果现阶段仍以贸易为主、生产环节较简单,可以先建立稳固的进销存体系,再逐步扩展生产模块,避免一次性制度过于复杂,影响系统上线。


😄 九、如何防止“选择错误进销存源码”的常见坑?

9.1 功能过度/复杂度过高

  • 问题:选了过于复杂的 ERP 源码,使用门槛高;
  • 对策:
  • 先按“最小可行版本(MVP)”选择;
  • 以后再逐步扩展模块。

9.2 技术栈不匹配

  • 问题:团队不懂某种语言/框架,后期维护困难;
  • 对策:
  • 坚持以团队已有技术能力为主;
  • 对完全陌生的栈,要特别评估培训与招聘成本。

9.3 源码文档不足

  • 问题:源码本身没问题,但缺乏清晰文档;
  • 对策:
  • 评估 README、部署指南、API 文档是否齐全;
  • 若选用文档较弱项目,必须预留足够学习时间。

9.4 没有明确版本控制与升级策略

  • 问题:二次开发后无法同步原项目更新;
  • 对策:
  • 保持与上游项目的 Git 分支关系;
  • 将自定义模块尽可能独立,减少对核心代码直接修改。

9.5 未规划数据迁移与备份

  • 问题:系统上线时历史数据无法统一导入,或数据安全无保障;
  • 对策:
  • 在实施早期就设计数据导入方案;
  • 制定例行备份与恢复流程。

😆 十、进销存源码与低代码平台结合的实践思路

10.1 混合架构:源码负责核心,低代码负责快速变化

思路:

  • 核心库存计算、订单处理逻辑由稳定的进销存源码服务承担;
  • 频繁变化的业务流程、审批流、报表由低代码平台承载;
  • 通过 API/消息队列将两个世界打通。

优势:

  • 核心系统保持稳定;
  • 前端业务可灵活配置,响应业务需求变化;
  • 技术与非技术人员可协同完成业务变更。

在这样的混合架构中,类似简道云进销存的模板可用于快速构建采购、销售、库存的表单和报表,并且通过接口与后端库存逻辑或其他业务系统打通,既保证核心数据的一致性,又保持业务层变更的敏捷性。

10.2 典型架构示例

  • 后端:
  • 一个 Java/Node.js 编写的库存服务,维护真实库存;
  • 中台:
  • 低代码平台维护订单审批、采购流程、报表;
  • 前端:
  • Web+移动端(低代码平台自动提供);
  • 集成:
  • 第三方电商平台、物流平台通过 API 接入。

😇 十一、如何在团队内推进进销存源码项目落地?

11.1 角色分工

  • 项目负责人:协调业务与技术;
  • 业务顾问/产品经理:梳理流程与需求;
  • 开发工程师:负责源码部署与二次开发;
  • 实施人员:负责培训与数据迁移;
  • 运维人员:负责环境稳定与监控。

11.2 推进节奏建议

  1. 第 1-2 周:需求调研 + 选型 + PoC;
  2. 第 3-4 周:部署环境 + 核心模块实现;
  3. 第 5-6 周:数据导入 + 用户培训 + 试运行;
  4. 第 7 周起:收集反馈 + 优化 + 拓展功能。

😋 十二、进销存源码未来发展趋势与总结

12.1 未来趋势预测

  1. 更多项目采用云原生架构
  • 微服务 + 容器化 + DevOps 上线;
  • 方便大规模扩展和多租户部署。
  1. 低代码与进销存结合更紧密
  • 越来越多的进销存系统会以“模板 + 配置”的方式交付;
  • 核心逻辑由源码实现,业务变化通过可视化配置支持。
  1. 数据分析与智能决策能力增强
  • 进销存系统将内置更多预测与分析能力;
  • 例如采购建议、补货算法、滞销预警等。
  1. 跨境化、多平台集成成为常态
  • 对接多个电商平台、支付渠道和物流服务;
  • 统一库存与订单视图。

12.2 总结:如何选择适合你的进销存源码?

综合全文,可以将选择进销存源码的核心决策逻辑归纳为:

  1. 先明确业务与技术能力
  • 不要盲目追求“功能最全”或“技术最新”;
  • 最重要的是适配你的业务复杂度与团队能力。
  1. 评估源码项目的功能、架构与文档
  • 功能是否覆盖;
  • 技术栈是否熟悉;
  • 文档与社区活跃度如何。
  1. 考虑开源、商业源码与低代码方案的组合
  • 对于中小企业,使用低代码平台进销存模板是一条更稳妥的路;
  • 对于技术能力强的团队,可在此基础上进一步用源码深度定制。
  1. 制定清晰的上线与迭代计划
  • 以最小可行版本先上线,逐步优化;
  • 建立持续维护和升级机制。

最后分享一个我们公司在用的进销存系统模板,需要的可以自取,可直接使用,也可以自定义编辑修改: https://s.fanruan.com/8bn69

精品问答:


什么是进销存源码,如何理解它在企业管理中的作用?

我刚接触进销存系统,听说进销存源码很重要,但不太清楚它具体指什么?想了解进销存源码的定义,以及它在企业库存和销售管理中的实际作用是什么?

进销存源码是指用于管理企业采购(进货)、库存(存货)和销售流程的软件源代码。它帮助企业实现库存精准管理、销售数据追踪和采购优化,提升运营效率。比如,通过源码自动化处理库存预警,减少缺货率达20%,通过销售数据分析辅助决策,提升销售额10%以上。理解进销存源码的结构,有助于企业根据自身业务需求定制系统,实现数字化转型。

选择适合我的进销存源码时,哪些核心功能必须重点考虑?

我想选一款适合公司的进销存源码,但市场上功能众多,不知道哪些功能是必须具备的,有没有具体的功能清单或建议?

选择进销存源码时,核心功能包括:

  1. 采购管理:支持供应商管理、采购订单自动生成;
  2. 库存管理:实时库存更新、库存预警、批次和保质期管理;
  3. 销售管理:订单处理、客户管理、销售报表;
  4. 数据分析与报表:可视化销售趋势、库存周转率分析;
  5. 多终端支持:支持PC和移动端操作。 例如,一款源码支持自动生成采购订单和库存预警,可降低缺货率15%以上,提升管理效率,确保业务流畅。

进销存源码的技术架构如何影响系统的稳定性和扩展性?

我不太懂技术,但听说源码的架构很关键,想知道进销存源码的技术架构具体指什么?它如何影响系统的性能和未来升级?

进销存源码的技术架构通常包括前端展示层、业务逻辑层和数据库层。良好的架构设计保证系统稳定运行和易扩展。例如,采用微服务架构可以使系统模块独立升级,减少维护风险;使用关系型数据库如MySQL保证数据一致性。案例:某企业采用分层架构后,系统响应速度提升30%,新功能上线周期缩短40%。因此,选择源码时应关注其架构设计,确保符合企业长期发展需求。

如何通过对比不同进销存源码的性能指标,选择最适合我的系统?

市场上进销存源码很多,我想通过数据对比来选出最适合自己公司的源码,但不清楚该重点看哪些性能指标,能给出具体建议吗?

选择进销存源码时,可通过以下性能指标对比:

指标说明理想数值/案例
系统响应时间用户操作到系统反馈的时间< 2秒,某系统响应时间1.5秒
并发用户支持量同时在线操作的用户数量支持500+并发用户,满足企业高峰需求
数据处理能力每日处理订单和库存记录的数量支持每日处理10万条订单数据
稳定性系统无故障运行时间99.9%在线率,保障业务连续性
通过上述指标量化对比,配合企业实际业务规模,能科学选择最合适的进销存源码,提高投资回报率。

文章版权归" "www.jiandaoyun.com所有。
转载请注明出处:https://www.jiandaoyun.com/nblog/486245/
温馨提示:文章由AI大模型生成,如有侵权,联系 mumuerchuan@gmail.com 删除。