进销存数据库哪个好？如何选择最适合的进销存数据库方案？

笋迁熊

·

2026-05-15 21:58:10

阅读27分钟

已读13次

选择进销存数据库方案时，应优先关注系统稳定性、扩展性、安全性与易用性。适合进销存管理的数据库并不是单一某一款，而是要结合业务规模、数据量、并发访问量、预算、团队技术栈以及与现有 ERP/电商系统的集成能力来综合评估。一般而言，中小企业更适合选择云数据库 + 低代码进销存系统的组合方案，以保证快速上线与后期可扩展；大型企业则更适合分布式关系型数据库 + 专业中台，配合完善的数据仓库与报表分析。在实际落地时，推荐通过 PoC（小范围试点）、性能压测与数据迁移演练来验证选型是否真正满足进销存业务的长期需求。

《进销存数据库哪个好？如何选择最适合的进销存数据库方案？》

---

🧭 一、进销存数据库的核心需求与评估思路

在考虑“进销存数据库哪个好”之前，先明确进销存系统（Inventory, Purchase & Sales Management）的业务特点和数据特征，才能知道该如何选择最适合的数据库方案。

1.1 进销存业务的典型特征

进销存系统主要用于管理库存、采购、销售与财务相关数据，典型特征包括：

• 高频写入 + 高频查询
• 采购入库、销售出库、库存调整等操作频繁发生
• 需要实时查询库存、订单、物流、财务对账信息
• 数据强一致��要求高
• 不能出现“库存负数”、“重复扣减”、“账实不符”等问题
• 多终端操作下，要求库存数据几乎实时一致
• 多维度查询复杂
• 按仓库、门店、SKU、批次、供应商、客户等多维查询
• 支持多条件筛选、汇总统计、趋势分析
• 历史数据累积大
• 订单、库存流水、日志、对账记录等会持续累计
• 数据保留年限较长，存储成本与性能都要考虑
• 多系统协同
• 可能要对接电商平台、ERP、财务系统、物流系统等
• 需要 API 接口与数据同步机制

因此，适合进销存的数据库需要兼顾：事务性（OLTP）能力、查询性能、扩展能力、成本可控以及安全合规性。

1.2 评估进销存数据库方案的关键维度

在选择进销存数据库时，可以从以下几个维度进行评估：

1. 数据模型与事务支持

• 是否支持关系模型（表结构清晰、外键、约束等）
• 是否支持 ACID 特性（事务一致性，对进销存非常重要）

2. 性能与扩展性

• 并发处理能力（支持多少用户同时操作）
• 数据量增长后的扩展方式（垂直扩容 or 水平扩展）
• 对读写分离、分库分表的支持

3. 可用性与稳定性

• 主从复制、故障自动切换
• 备份与恢复能力
• SLA 保证（特别是云数据库）

4. 安全性与合规性

• 访问控制、权限管理、审计日志
• 加密存储（静态加密 / 传输加密）
• 是否满足企业所在国家或行业的合规要求

5. 运维成本与使用成本

• 自建 vs 云托管的成本对比
• 数据库管理员（DBA）的人力成本
• 是否易于监控、调优、备份与升级

6. 生态与兼容性

• 是否支持主流 ORM 框架
• 是否容易与现有应用系统集成
• 是否有成熟的进销存 SaaS 或模板支持

结合这些维度，可以初步筛选出适合自身业务场景的进销存数据库方案。

---

📚 二、常见进销存数据库类型与适用场景对比

不同类型的数据库在进销存中的角色与优势各不相同。以下将从关系型数据库、NoSQL、云数据库及 NewSQL/分布式数据库几个层面进行说明。

2.1 关系型数据库：进销存的“主力军”

进销存数据结构相对清晰（订单、库存、商品、供应商、客户等），并且对事务一致性要求高，因此**关系型数据库（RDBMS）**一直是主流选择。

常见关系型数据库（国外产品为主）

• MySQL / MariaDB
• PostgreSQL
• Microsoft SQL Server
• Oracle Database
• IBM Db2（在一些大型传统企业中）

关系型数据库适用场景

• 中大型企业的统一进销存系统
• 有复杂业务逻辑、需要事务强一致的场景
• 多维度报表查询、复杂 SQL 分析

关系型数据库优缺点概览

类型	优点	缺点	典型适用
MySQL / MariaDB	社区成熟、生态丰富、易用、兼容性强、云端支持广泛	原生分布式能力相对有限，需要依赖中间件或云厂商能力	中小企业、互联网业务
PostgreSQL	支持复杂查询、事务能力强、扩展性佳、功能接近商业数据库	学习曲线略高，部分运维场景偏复杂	中大型企业，对数据一致性要求极高
SQL Server	与 .NET 系统一致性高，图形化管理工具完善	偏向 Windows 环境，许可费用需要控制	已有微软技术栈企业
Oracle	强大的事务与高可用能力，适合大型复杂系统	许可与维护成本高，运维要求高	大型集团、金融级场景
IBM Db2	企业级、稳定，适合大型企业的遗留系统	部署成本与维护成本较高	传统大型企业

对于大多数进销存系统，MySQL / PostgreSQL + 云厂商托管服务是非常常见且性价比较高的组合。

2.2 NoSQL 数据库：进销存的辅助角色

NoSQL（如 MongoDB、Cassandra、Redis 等）在进销存系统中通常扮演缓存、日志存储、或辅助查询的角色，而不是主库存事务数据库。

NoSQL 在进销存中的定位

• Redis

• 用作缓存层：加速商品信息、库存快照、热销数据等查询

• 用于分布式锁，避免重复扣减库存

• MongoDB / Document Store

• 适合存储非结构化的商品描述、日志、扩展字段

• 用于报表或灵活查询场景，但不建议直接作为核心库存账本

• Cassandra / DynamoDB（云服务）

• 适合超大规模写入场景，如日志、历史流水

• 对进销存主交易数据来说，一致性管理相对复杂

总体来说，NoSQL 更适合作为进销存数据库方案中的“辅助手”，不宜单独承担核心库存交易数据。

2.3 云数据库与托管服务：中小企业的高性价比选择

对于没有专职 DBA 的企业，选择云厂商的托管数据库是显著降低成本的方式。

常见国外云厂商数据库服务包括：

• Amazon RDS / Aurora（AWS）
• Google Cloud SQL / Cloud Spanner
• Microsoft Azure SQL Database
• Oracle Cloud Database

这些云数据库通常提供：

• 自动备份、自动扩容、自动故障切换
• 按需计费，支持从小规模试点到大规模长远扩展
• 配套监控、调优工具

对于需要快速上线进销存系统、又希望控制成本的团队，云数据库 + SaaS/低代码进销存方案是一种非常实用的路径。

2.4 NewSQL 与分布式数据库：大型与高并发场景

NewSQL 或分布式关系型数据库，结合了 NoSQL 的水平扩展能力与传统 RDBMS 的事务一致性。例如：

• Google Spanner
• CockroachDB
• TiDB（偏亚太场景）
• 部分云厂商提供的分布式数据库服务

这类数据库适用于：

• 海量订单、库存数据
• 多地域、多数据中心部署
• 兼顾强一致性与高扩展性

对于一般中小企业来说，NewSQL 可能超出实际需求和预算；但对大型电商、连锁零售企业、跨国业务而言，分布式数据库在进销存系统中具有明显优势。

---

🧪 三、典型进销存数据库架构方案（从小到大）

为了更直观地理解如何选择进销存数据库方案，可以按企业规模和复杂度，拆解几种典型架构模式。

3.1 单体数据库 + 进销存应用（小微企业）

适用对象：

• 小微企业、创业团队
• 单仓库或单门店
• 用户数较少、并发不高，预算有限

典型方案：

• 数据库：MySQL / PostgreSQL 单实例（可采用云厂商免费/入门级方案）
• 应用：现成的 SaaS 进销存系统或低代码平台构建
• 部署：单机或轻量级云服务器

优点：

• 成本低，上线快
• 架构简单，维护难度低
• 使用现成模板或者现成系统即可，比如可以使用基于云数据库的进销存模板，减少自研成本

缺点：

• 扩展能力有限，适用规模有限
• 数据库故障时，整体系统中断（可通过云备份缓解）

3.2 主从 + 读写分离（中小企业）

适用对象：

• 多门店、多仓库
• 并发查询逐渐增加，需要分担读压力
• 有一定的 IT 团队，愿意做基本的架构升级

典型方案：

• 数据库：
• 主库负责写入（订单、库存变更）
• 从库负责报表查询、统计分析
• 架构：
• 使用中间件或应用层实现读写分离
• 结合缓存（Redis）提高查询性能

优点：

• 提升系统整体性能，特别是查询性能
• 成本可控，适合处于成长阶段的企业

缺点：

• 需要一定运维能力，处理复制延迟等问题
• 业务逻辑需要考虑读写一致性的影响（短时间内数据延迟）

3.3 分库分表 + 分布式数据库（中大型企业）

适用对象：

• 订单量和库存变更量巨大
• 多地区、多业务线
• 要求高可用、高扩展性

典型方案：

• 使用分布式 MySQL 集群（或 NewSQL、云分布式数据库）
• 按业务线或按仓库、区域分库分表
• 强化数据库中间层（数据库网关、读写路由）
• 结合消息队列、缓存、搜索引擎（如 Elasticsearch）做复杂查询与分析

优点：

• 支撑大规模并发与数据量
• 对业务增长友好

缺点：

• 架构复杂，开发 & 运维成本较高
• 对团队技术要求高，需要专业人员负责

---

📦 四、进销存数据库选型：按企业规模与行业场景划分

在“进销存数据库哪个好”这个问题上，没有放之四海皆准的唯一答案，但可以按规模和行业给出参考选型思路。

4.1 小微企业：优先考虑 SaaS + 云数据库

特征：

• 预算有限
• IT 人员少或无专职开发
• 更重视“好用、上手快、稳定、成本低”

推荐思路：

1. 选择成熟的 SaaS/低代码进销存系统

• 由提供商负责数据库运维
• 多数采用 MySQL / PostgreSQL + 云数据库

2. 利用模板降低实施成本

• 选择支持自定义字段、流程、报表的系统
• 便于随业务变化调整进销存逻辑

在这类场景中，可以考虑使用具备进销存模板能力和云数据库支撑的系统。例如，一些平台提供的进销存模板支持商品、仓库、采购、销售、库存报表等全流程管理，并且可在模板基础上自定义字段和流程，用以适配不同行业。 在选择模板型系统时，可评估其是否支持对接常见云数据库、是否支持 API 集成，以及报表与数据导出的灵活性。

4.2 成长型企业：读写分离 + 报表分析

特征：

• 多仓库、多门店，业务量持续增长
• 需要精细化管理库存与资金
• 希望通过报表、BI 进行销售与库存分析

推荐思路：

• 数据库选 MySQL / PostgreSQL（建议云托管）
• 实现主从复制与读写分离
• 使用 Redis 做缓存，提升响应时间
• 使用报表工具或 BI 工具对接数据库，实现多维分析
• 结合低代码平台快速构建特定业务场景的进销存应用

在这类企业中，数据库架构的稳定性与扩展性非常重要，同时还要考虑进销存系统与财务系统、CRM 等的对接能力。

4.3 大型企业与连锁集团：分布式数据库 + 中台化

特征：

• 多品牌、多事业部、多国家/地区
• 订单量、库存变更量巨大
• 需统一管控、但又要保持灵活性

推荐思路：

• 使用分布式数据库（如云厂商提供的分布式 MySQL / NewSQL）
• 部署统一的库存中台、订单中台
• 利用消息队列和事件驱动设计，保证各系统之间数据同步
• 建立数据仓库和数据湖，用于长期分析与预测

这类企业的进销存数据库方案往往是综合架构工程，需要数据库、架构、业务多方协同规划。

---

🧱 五、进销存数据库的关键设计要点

无论选择哪种数据库方案，合理的数据模型设计与数据库规范是进销存项目成功的基础。

5.1 核心数据模型设计（表结构）

典型进销存系统中，主要包含以下几类核心表：

• 商品相关

• 商品档案表（Products）

• SKU / 批次表（Product_SKU / Batch）

• 条码、规格、属性等扩展表

• 库存相关

• 库存现存量表（Inventory）

• 库存事务流水表（Inventory_Transaction）

• 采购相关

• 采购订单表（Purchase_Order）

• 采购入库表（Purchase_Inbound）

• 供应商档案表（Supplier）

• 销售相关

• 销售订单表（Sales_Order）

• 销售出库表（Sales_Outbound）

• 客户档案表（Customer）

• 财务相关

• 应收账款 / 应付账款表（AR/AP）

• 收款 / 付款记录表

良好的进销存数据库方案要保证：库存流水与库存现存量有严格的对应关系，通过事务和约束防止出现“数据孤岛”或“账实不符”。

5.2 事务与并发控制

在进销存系统中，常见并发问题包括：

• 多人同时出库导致库存被重复扣减
• 同时操作采购入库与出库产生不一致
• 出入库流水与财务记录不同步

解决这些问题的关键是：

• 使用数据库事务（Transaction）保证一组操作要么全部成功，要么全部失败
• 针对库存扣减等关键动作，使用行锁或乐观锁机制
• 对于跨系统操作（如 ERP + 电商），需要设计消息补偿机制或对账机制

5.3 索引与查询优化

进销存系统中，常见查询包括：

• 按商品和仓库查询库存
• 按日期、客户、供应商查询订单
• 按门店、区域、业务员分析销售数据

合理的索引设计可以大大提升查询性能，但索引过多会影响写入性能。一般建议：

• 为库存、订单主键、外键建立索引
• 对常用查询条件列（例如商品编码、仓库、日期）建立组合索引
• 定期分析索引使用情况，移除冗余索引

---

🔐 六、进销存数据库的安全与合规要点

进销存数据库承载大量业务数据和敏感信息（客户信息、供应商信息、价格折扣、财务数据等），安全和合规是选型时不可忽视的重要因素。

6.1 权限控制与访问管理

• 实施最小权限原则，不同角色仅能访问必要的进销存数据
• 区分读写权限，限制普通用户直接修改核心库存表
• 使用角色管理（Role-Based Access Control，RBAC）规范审批和操作权限

6.2 数据加密与传输安全

• 使用 SSL/TLS 保证数据库连接的加密
• 对敏感字段（如银行账号、联系方式等）进行加密存储
• 定期审查数据库访问日志，发现异常访问行为

6.3 备份、恢复与容灾

• 制定明确的备份策略：全备 + 增量备份
• 定期做恢复演练，确保在实际故障时能快速恢复进销存数据库
• 对关键数据（如库存、订单）做好跨地区备份和容灾方案

---

🧩 七、进销存数据库方案与进销存系统的协同选择

数据库只是进销存解决方案的一部分，更关键的是数据库 + 应用系统 + 报表分析 + 运维管理的整体协同。

7.1 为什么建议考虑“数据库 + 低代码/模板化进销存系统”

很多企业在实践中发现：完全自研进销存系统的成本非常高，需要数据库设计、后端开发、前端开发、测试、部署、运维等多方面投入。 因此，越来越多企业选择：

• 采用低代码平台或进销存模板，快速搭建业务流程
• 由平台提供数据库能力（包含备份、恢复、监控等）
• 在模板基础上定制字段、流程、报表，以适配自身需求

这类模式的优势是：

• 技术门槛较低，业务部门可以直接参与配置
• 功能迭代速度快，能快速响应业务变化
• 一般内置报表与统计分析能力，方便管理层决策

例如，有一些平台提供可直接使用的进销存系统模板，支持商品档案管理、库存管理、采购销售管理、库存报表等模块，并通过可视化界面实现字段与流程的自定义编辑。在这类平台中，数据库通常托管在云上，企业不用自己维护数据库实例，只需关注业务配置与数据使用。

在需要构建进销存数据库方案时，如果希望减少自研成本，可以评估这类模板型系统是否符合以下需求：

• 是否支持表结构与字段的自定义
• 是否支持多仓库、多门店管理
• 是否支持审批流程和权限控制
• 是否支持与现有系统对接（通过 API 或导入导出）

---

🧮 八、进销存数据库方案的实践步骤与选型流程

为了避免在选型中迷失，建议按照明确步骤进行进销存数据库方案的规划与验证。

8.1 制定业务与技术需求清单

先从业务角度定义需求：

• 预计管理多少商品 SKU？
• 每天平均订单量、峰值订单量是多少？
• 有多少仓库、门店需要纳入管理？
• 需要与哪些系统集成（电商平台、财务系统等）？
• 数据需要保存多少年？

再从技术角度明确：

• 是否有专职 DBA？
• 是否有自建机房，还是全部在云上？
• 是否需要 7x24 小时高可用？
• 预算范围是多少？

8.2 初步选型与方案设计

结合需求，选择数据库类型与架构：

• 小微企业：云数据库 + SaaS / 低代码进销存
• 中小企业：云 MySQL / PostgreSQL + 主从 + 缓存
• 大型企业：分布式数据库 + 中台化架构

同时，考虑使用模板化系统来加速进销存应用的构建。例如，使用一个已经构建好的进销存模板，只需稍加配置即可上线，有助于快速验证业务流程与数据库结构是否合理。

8.3 PoC（概念验证）与性能测试

在正式实施前，建议先进行 PoC：

• 搭建小规模环境
• 导入部分真实数据
• 模拟真实订单、库存操作
• 测试响应时间、并发能力、报表生成效率

根据测试结果，调整数据库配置、索引方案与应用逻辑。

8.4 数据迁移与正式上线

对于已有旧系统的企业，数据迁移是关键环节：

• 对旧系统数据进行清洗与校验
• 设计数据映射规则，将旧表结构映射到新结构
• 迁移后，通过对账工具验证库存、订单、财务数据的一致性
• 上线初期设定灰度期或双轨运行，确保安全平滑过渡

---

🌐 九、进销存数据库方案中的云化与混合云趋势

随着云计算与 SaaS 的普及，进销存数据库方案正出现明显的云化趋势。

9.1 上云的优势

• 减少自建机房与硬件投入
• 自动扩容，按需付费
• 提供一站式监控、备份、恢复工具
• 易于跨地域部署与访问

9.2 混合云与多云策略

部分企业选择混合云或多云方案：

• 核心进销存数据库部署在主云平台
• 报表分析或备份同步到另一家云厂商
• 部分敏感数据保留在本地私有云中

这种模式可以在安全性、灵活性与成本之间取得平衡。

---

📊 十、如何评估一个具体进销存数据库方案是否“适合”你？

把“哪个好”换成“适合不适合”，可以从三个维度来简单评估：

10.1 从业务视角

• 能否支持当前和未来 2-3 年的业务规模？
• 是否支持当前业务所有核心流程（采购、销售、库存、财务）？
• 是否支持多仓、多门店、多组织结构？

10.2 从技术与运维视角

• 是否有足够成熟的稳定性保障？
• 出现数据库故障时，恢复时间能否接受？
• 是否能方便地进行性能监控与调优？

10.3 从成本与 ROI 视角

• 初始上线成本是否在预算内？
• 后续扩容和运维成本是否可控？
• 是否能通过提升效率、减少库存浪费来带来明显收益？

---

🧾 十一、示例：结合模板与数据库的进销存实践路径

为帮助理解“选择合适进销存数据库方案”的落地路径，可以举一个典型实践路线：

1. 确认业务需求与约束：

• 多仓库、多门店，需要实时库存
• 有采购、销售、退货、盘点等标准流程
• 无专职开发团队，希望尽量低代码化

2. 确定数据库与系统策略：

• 采用云托管数据库（如 MySQL/ PostgreSQL）作为底层
• 上层采用支持进销存模板的系统，快速搭建业务流程

3. 选用进销存模板进行配置：

• 使用现成的进销存模板，包含商品、库存、采购、销售、报表等模块
• 通过可视化方式配置字段、审批流程、报表
• 调整适配自身的业务规则（例如不同仓库的权限控制，不同行业的特殊字段）

4. 测试与上线：

• 使用自动化测试与模拟数据验证库存一致性
• 部分门店先行试运行，再逐步推广

在这类场景下，类似于一个可配置的进销存解决方案可以显著降低项目周期和数据库运维难度。 例如，一些平台提供的进销存系统模板不仅自带标准的表结构与字段，还继承了云数据库的备份、恢复和权限管理能力，适合中小企业在有限资源下快速构建进销存数据库方案。

---

🔮 十二、总结与未来趋势：如何持续优化你的进销存数据库方案？

综合全文，可以总结为：

• 进销存数据库哪个好，取决于业务规模、技术能力与预算；没有绝对统一的答案，但关系型数据库 + 云托管目前仍是绝大多数企业的主流选择。
• 对于中小企业，云数据库 + 模板化/低代码进销存系统往往是更容易落地、成本更可控的方案。
• 对于大型企业，分布式关系型数据库 + 中台化架构能够承载高并发和多业务线的复杂需求。

未来，进销存数据库方案将呈现以下趋势：

1. 全面云化：越来越多的进销存系统会直接构建在云数据库和 SaaS 平台之上，弱化自建数据库运维。
2. 数据一体化：库存数据、销售数据、采购数据会与 BI、预测模型、供应链管理系统深度集成，实现精细化运营与智能补货。
3. 低代码与模板化普及：越来越多企业会通过模板和低代码方式快速搭建进销存系统，在统一数据库基础上持续迭代业务能力。
4. 安全与合规强化：随着数据保护法规与行业标准的完善，进销存数据库方案将更强调访问控制、审计、加密和合规性。

在实践中，建议以小步快跑、持续迭代的方式来构建进销存数据库方案：先使用成熟模板与云数据库快速上线，再结合实际使用情况优化架构与性能，而不是一开始就追求复杂而昂贵的系统。

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

精品问答:

---

进销存数据库哪个好？

我在选择进销存数据库时，发现市场上的产品很多，不知道哪个进销存数据库性能更好，稳定性如何，适合中小企业使用吗？

选择进销存数据库时，建议关注以下关键指标：

1. 性能表现：如响应速度、并发处理能力。根据2023年调研数据，MySQL和PostgreSQL因其高效的查询性能，广泛应用于进销存系统。
2. 稳定性与数据安全：支持事务（ACID）和数据备份机制的数据库更适合进销存业务。
3. 易用性与扩展性：支持多种数据结构和易于集成的数据库能提升维护效率。

例如，MySQL适合中小企业，因其开源且社区支持强大；而大型企业可能更青睐Oracle数据库，因其强大的安全和扩展功能。综合以上，MySQL和PostgreSQL通常被认为是目前进销存数据库的最佳选择。

如何选择最适合的进销存数据库方案？

我负责公司进销存系统的数据库选型，面对性能、安全性和成本等多方面考量，不知道如何系统地选择最适合的进销存数据库方案？

选择最适合的进销存数据库方案，应从以下几个维度综合评估：

维度	说明	推荐数据库
性能	查询响应时间，数据处理量	MySQL, PostgreSQL
安全性	数据加密，访问控制	Oracle, SQL Server
成本	许可费用、维护费用	MySQL (开源免费)
扩展性	支持集群、分布式	PostgreSQL, Oracle
易用性	管理界面、社区支持	MySQL, PostgreSQL

通过对比企业规模、预算及业务需求，结合以上指标权衡，能更科学地选出最适合的进销存数据库方案。例如，中小企业推荐开源且社区活跃的MySQL或PostgreSQL，而对数据安全和性能有高要求的大型企业则可考虑Oracle或SQL Server。

进销存数据库的性能指标有哪些？

我想了解进销存数据库的性能指标具体包含哪些内容，这些指标如何影响系统的整体运行效率？

进销存数据库性能指标主要包括：

1. 查询响应时间：影响用户体验，通常以毫秒(ms)计量。
2. 并发处理能力：支持同时处理的事务数量，关键于高峰期业务稳定。
3. 事务吞吐量：单位时间内完成的事务数，衡量数据库处理能力。
4. 数据一致性保障：确保在多用户操作时数据准确无误。

案例：某大型零售企业使用PostgreSQL，优化索引和缓存后，查询响应时间从平均200ms降低至80ms，并发处理能力提升30%，显著提升了系统稳定性和用户满意度。

进销存数据库如何保障数据安全？

我担心进销存系统中的关键业务数据安全性，想知道数据库层面有哪些安全机制可以有效保护数据？

进销存数据库保障数据安全的机制主要包括：

• 访问控制：基于角色的权限管理，限制用户操作范围。
• 数据加密：传输层（SSL/TLS）和存储层加密保护数据隐私。
• 事务日志和备份：支持自动备份与恢复，防止数据丢失。
• 审计功能：记录操作日志，便于追踪异常行为。

例如，Oracle数据库提供高级加密标准（AES）和细粒度访问控制，帮助企业实现符合ISO27001标准的数据安全管理。根据IDC报告，采用完善安全机制的数据库系统，数据泄露事件减少了45%。

181

×

微信分享

扫描二维码分享到微信