眠子子子很多后端开发拿到这套“企业级图书进销存管理系统源码”时，第一反应往往是：先跑起来，然后再看 SpringBoot 怎么写的、Vue 页面长什么样。这没有错，但我发现大部分人对源码的消化基本就停在这一层，看完之后除了会改几个接口，对“进销存”这套业务本身依然没有建立起真正的全局认知。
我做过不少进销存、供应链类的管理项目，今天就借这套基于 SpringBoot + Vue + MyBatis + MySQL 的完整源码，把图书进销存系统的业务价值、表结构设计、库存扣减思路、环境搭建坑位一次说透。这篇文章适合三类人：拿源码练手的学生、准备把进销存项目写进简历的求职者，以及刚接手图书类管理系统、需要快速理解业务模型的开发。
进销存系统看起来是 CRUD，但 CRUD 背后藏着完整的业务流转和资金链路。如果只盯着技术名词而不理解业务为什么这么走，那这份源码对你的价值至少丢掉了一半。
1. 图书进销存到底在解决什么业务痛点
1.1 手工台账时代最让人崩溃的四个场景
先把业务场景想清楚，再去碰代码。图书进销存管理系统的核心不是“管图书”，而是解决书店或图书批发商在经营中反复出现的几类问题。
第一类，库存不清楚。畅销书到底还剩几本？仓库实际库存和 Excel 里记的数字对不上，盘点时才发现某本书丢了、破损了，或者采购入库时漏记了一批。第二类，采购靠拍脑袋。不知道哪些书卖得快、哪些书积压了，进货量全凭店长经验，结果滞销书堆满仓库，畅销书补货又跟不上。第三类，账目对不齐。供应商送了多少货、退了多少货、应付多少钱；客户买了多少、退了多少、应收多少钱，手工记账很容易遗漏和算错。第四类，没法追溯。顾客说上周买的一本书有质量问题要退，店员查不到这笔销售记录，也没法核实这本书是从哪个供应商进的货。
这四个场景，本质上是信息不实时、数据不唯一、流程不闭环造成的。图书进销存管理系统要解决的，就是把这些散落的 Excel、纸质单据、口头沟通，收敛成一套以“单据 + 流水”为核心的闭环数据链。
1.2 “企业级”这三个字对系统提出了什么要求
标题里带了“企业级”，很多人以为指微服务、分布式、高并发。真不是。图书进销存这类后台管理系统，单店或中小型企业的并发量并不高，真正配得上“企业级”的，是下面几点业务能力。
一是权限要分角色。采购员只能做采购单，销售员只能做销售出库，库管员负责入库审核，财务看报表，不能一人跑到别人的功能模块里乱操作。二是单据要有状态流转。采购单要有“草稿、待入库、部分入库、已完成、已取消”等状态，不能改来改去没痕迹。三是关键操作必须有记录。谁在什么时间入库了哪批货、扣了哪本书的库存，都要能回溯。四是库存和资金账要能对得上。系统不只是一块电子记账板，得把采购、销售、退货、盘点这些动作串成一条能追查的完整链路。
如果一个所谓“企业级”项目只有几个 CRUD 页面，没有状态管理，没有流水记录，那它只能算教学 Demo，离企业真实使用还有距离。而图书进销存的完整源码之所以值得细读，就是因为它在业务链路上比普通教学项目完整得多。
1.3 图书这个行业，SKU 的复杂性不低
图书库存不能简单等同于普通商品库存。图书特征非常突出：同一本书有不同出版社、不同版次、精装和平装之分，书名可能一样，但内容、售价、进货价完全不同。所以图书表必须以 ISBN 或内部条码作为唯一商品标识，不能拿书名做主键。
图书行业还有“码洋”和“实洋”的概念。码洋是图书封底标价，实洋是按折扣实际结算的金额。采购时供应商给折扣，销售时书店也可能打折。一套系统如果只存售价，不存进价和折扣，后面做利润报表就会非常吃力。
还有退货和报损。图书是易损耗品，运输途中可能磕碰，销售后可能因为印刷质量问题被退回。这些动作都会引起库存和资金变化，必须流经统一的数据通道，而不是单独在哪张表里加加减减。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术栈选型复盘：SpringBoot、Vue、MyBatis、MySQL 各自承担的职责
2.1 后端为什么是 SpringBoot，而不是更高大上的框架
这套源码的后端选 SpringBoot，是典型的中小企业管理软件方案。SpringBoot 的核心价值是“内嵌容器 + 约定优于配置 + Starter 自动装配”，只要引入依赖并写配置，就能快速启动 Web 服务，不需要像传统 SSM 那样手工装配大量 XML。
SpringBoot 2.7.x 是目前企业存量项目里最常见的版本区间，对应 JDK 8，生态成熟，资料多。很多用这套技术栈做毕设或工作的朋友会碰到 SpringBoot 版本过高的问题——比如 SpringBoot 3.x 要求 JDK 17，而且原来熟悉的 javax.servlet 包全部换成了 jakarta.servlet，老代码直接启动报错。源码项目为了降低门槛，用 2.x 加 JDK 8 是合理选择，也适合绝大多数人的本机环境。
有读者可能会问：现在不是流行 Spring Cloud 微服务吗？为什么不拆成商品服务、订单服务、库存服务？答案很简单：图书进销存是一个典型的单体业务系统，数据表之间有强事务关联，拆微服务只会增加分布式事务成本。单体分层架构在项目早期是最高效的，真正需要拆的时候，也应该从模块边界开始梳理，而不是盲目引入一套注册中心和网关。
2.2 Vue 负责的，其实是后台管理中最烦的交互
图书进销存的页面形态非常固定：左侧菜单、顶部用户信息、中间是各种表格和表单。采购单要弹窗选书，销售单要动态添加明细行，库存列表要支持多条件筛选，这些需求如果把 Vue 换成传统 jQuery 加服务端渲染，开发效率和维护体验会差很多。
Vue 提供了数据双向绑定和组件化开发。比如采购明细表格中，用户改了某个图书的采购数量，前端要自动重新计算当前单据总金额，如果用原生 DOM 操作，需要手动去更新多个节点；在 Vue 里只需要维护一个采购明细数组，计算属性会帮你自动刷新所有依赖这个总金额的地方。
前端工程一般配合 Element UI 或 Element Plus 使用，表格、弹窗、表单校验、分页组件都有现成方案，能快速搭建出观感规范的运营后台。组件化之后，图书选择弹窗可以被采购单、销售单、盘点单多处复用，这也是 Vue 组件思考方式给项目带来的优势。
2.3 持久层为什么是 MyBatis 而不是 JPA
进销存系统最考验持久层的场景是什么？多表联查和动态 SQL。
打开采购单列表时，筛选条件往往不是固定的：按单号模糊查、按供应商查、按日期区间查、按状态查。如果只用 JPA，面对这种多条件组合查询，要写一堆 Specification 或者 @Query 拼接，非常痛苦，也很难排查 SQL 问题。而 MyBatis 把 SQL 直接写在 XML 文件里，可以直观地看到表关联、条件拼接和结果映射，适合查询需求复杂的业务系统。
MyBatis 里还有一个所有面试都会问的细节——#{} 和 ${} 的区别。在 mapper 文件里写动态查询时，如果条件值用 ${} 直接拼接，存在 SQL 注入风险；换成 #{} 后会走 PreparedStatement 预编译，参数以占位符方式传递。图书进销存中模糊查询很常见，应该写成 where book_name like concat('%', #{keyword}, '%')，而不是把关键字直接拼进 SQL。
此外，像 MyBatis 缓存机制、MyBatis-Plus 的逻辑删除和乐观锁插件，也都是业务中会涉及的知识点。进销存的库存数据强调实时性，查询时最好禁用二级缓存或用完立即清空，否则很容易出现上游已经扣了库存，下游查询还读到旧值的情况——我见过不止一个项目在这里翻车。
2.4 MySQL 保存的，不只是库存数字
MySQL 在整套体系里承上启下。后端处理完业务逻辑，最终要把数据落地到 MySQL 中；前端所有表格的展示，也是从 MySQL 查出来再经接口返回。选择 MySQL 8.x 比较合适，InnoDB 引擎保证事务能力，数据库免费开源，社区资料丰富，部署运维成本低。
建库时要把字符集定成 utf8mb4，而不是 utf8。MySQL 的 utf8 只能存 3 字节字符，遇到生僻字或特殊符号会报错；utf8mb4 是完整版本，兼容性更好。图书书名、作者名中偶尔会出现特殊字符，字符集选错，测试时可能发现不了，正式跑一阵子后突然某本书入库失败，排查起来很被动。
整体请求链路可以这样理解：Vue 页面通过 axios 发起 HTTP 请求，请求先到达 SpringBoot 的 Controller，Controller 不写业务逻辑，只做参数接收和结果封装，然后调用 Service 层处理业务，Service 层通过 MyBatis 的 Mapper 接口操作 MySQL，查询结果再逐层返回，最后 Vue 把接口返回的 JSON 数据渲染成页面表格。
3. 数据模型是底层地基：主从表、库存流水与核心表设计
3.1 先看完整表结构，在脑子里装一张地图
拿到源码，我建议不要先看代码，而是把数据库里的表结构全部拉出来看一遍。图书进销存系统一般会包含下面这些核心表，这里列个总览：
| 表名 | 业务含义 | 需要特别留意的字段 |
|---|---|---|
| sys_user | 系统用户 | 用户名、密码、角色ID、状态 |
| sys_role | 角色表 | 角色编码、角色名称 |
| book_category | 图书分类 | 分类名称、父分类ID |
| book_info | 图书基本信息 | ISBN、书名、作者、出版社、分类ID |
| supplier | 供应商 | 供应商名称、联系人、电话 |
| customer | 客户 | 客户名称、类型、联系人 |
| purchase_order | 采购主表 | 采购单号、供应商ID、总金额、状态 |
| purchase_order_item | 采购明细表 | 采购单ID、图书ID、数量、进价 |
| sale_order | 销售主表 | 销售单号、客户ID、总金额、状态 |
| sale_order_item | 销售明细表 | 销售单ID、图书ID、数量、售价 |
| inventory_flow | 库存流水表 | 图书ID、业务类型、出入方向、数量变动 |
| stock_check | 盘点单（可选） | 盘点单号、差异数量、操作人 |
从总览可以看出，采购和销售都是“主表 + 明细表”的结构，而所有引起库存变动的动作都会汇聚到库存流水表中。数据模型一旦有了这条主线，后面阅读代码会是降维式的轻松。
3.2 采购单为什么要拆成主表和明细表
新手最容易犯的错误，是把一张采购单里的多本书直接存成一行，或者用逗号拼接图书 ID。这种设计在展示当前订单时很方便，但一旦涉及供应商对账、部分入库、部分退货，就完全失控。
正确做法是主表存单据头信息：采购单号、供应商、采购日期、整单总金额、当前状态。明细表存每一本书的采购数量、进价、小计金额。主表和明细表通过 purchase_order_id 关联，加上外键索引。
这样设计有几个实际好处。财务要对账时，只需要查主表就能知道这张单子的总金额；库管收货时，可以针对明细行逐条登记实收数量，一旦只有部分图书到货，系统可以把主表状态改成“部分入库”，而不是整单完成或整单取消。下次扩展采购审批流时，也只需要在主表上增加审核状态字段，不需要动明细表结构。
3.3 库存流水表是整个系统的“账本”
图书当前库存字段通常维护在 book_info.stock 里，但真正能保证库存数据正确性的，不是这个 stock 字段本身，而是 inventory_flow 库存流水表。任何一笔入库、出库、退货、报损，都必须同时产生一条流水记录。下面是常见的流水表结构：
sql复制CREATE TABLE inventory_flow (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
book_id BIGINT NOT NULL COMMENT '关联图书ID',
biz_type TINYINT NOT NULL COMMENT '业务类型：1采购入库 2销售出库 3采购退货 4销售退货 5盘点调整',
direction TINYINT NOT NULL COMMENT '库存方向：1入库 2出库',
quantity INT NOT NULL COMMENT '本次变动数量',
before_stock INT NOT NULL COMMENT '变动前库存',
after_stock INT NOT NULL COMMENT '变动后库存',
biz_no VARCHAR(64) NOT NULL COMMENT '来源单据号，如采购单号',
create_by BIGINT NOT NULL COMMENT '操作人ID',
create_time DATETIME NOT NULL COMMENT '操作时间',
KEY idx_book_time (book_id, create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存流水表';
为什么要多维护一张流水表？第一，可追溯。只有 book_info.stock 的数字，你无法解释库存为什么变成这个值；有了流水表，每一本图书的每一个库存变化都能找到来源单据和操作人。第二，可对账。库存表一旦因为异常运维被改乱，可以用流水表重新汇总，恢复正确数值。第三，可分析。月度销售分析、热销榜单都可以直接从流水中聚合出来，而不需要去扫描复杂的订单明细。
现实项目里经常有逻辑删除的设计需求。我的建议是：系统用户表、图书表这类基础资料可以加 del_flag，删除时走逻辑删除；但库存流水表必须物理保留，不能逻辑删除，它是审计和财务对账的原始凭证。
3.4 表结构里必须留意的几个字段约定
图书表里要有 ISBN、书名、作者、出版社、分类 ID、进价、售价、当前库存、预警库存、状态等字段。书架和仓库管理如果暂时不做，直接一个 stock 字段就够；如果想做得更细，可以拆分独立库存表，按仓库 ID 记录每个仓库的库存，但演进成本会高一些。
金额字段推荐 DECIMAL(10,2)，正好覆盖图书这种几元到几百元的定价区间。Java 实体类中对应使用 BigDecimal，不能使用 double 或 float。二进制浮点数运算可能产生精度误差，在涉及钱的计算上是绝对不能接受的。
所有核心表建议保留 create_time、update_time、create_by、update_by 四个公共字段，方便后面做操作审计。逻辑删除字段加到这里也是惯例，但要注意：业务单据表尽量少用逻辑删除，单据发生错误应该用反审核、红冲等业务动作去修正，而不是物理删行。
4. 核心环节拆解：采购入库、库存扣减与并发安全
4.1 一次采购入库，背后经历了什么
把业务链路走通，是理解这套源码的关键。以采购入库为例，正常流程是这样的：
前端页面上，采购员创建采购单，选择供应商，再点击“添加图书”从图书列表中选择要采购的书，填写数量和进价。提交后生成状态为“待入库”的采购单。货到后，库管员在采购入库页面打开这张单子，逐条确认实收数量，点击“确认入库”。后端的 Service 层收到请求后，在一个数据库事务里完成以下操作：校验采购单状态必须是待入库或部分入库；检查本次入库数量不能超出未入库数量；逐条更新图书表的当前库存字段；逐条写入库存流水；更新采购主表状态；最后把入库结果返回前端。
中间任何一步失败，整个事务都要回滚。如果事务回滚不彻底，会看到图书库存已经增加了，但采购单还停留在待入库状态，这是严重的数据不一致问题。
4.2 库存扣减不能写成“先查再改”
图书库存扣减是这套系统里最需要提升警觉的地方。很多新手在实现销售出库时，会习惯这样写：先根据 bookId 查出当前库存，判断库存是否充足，然后 update 减库存。
这个逻辑在单用户测试时没有问题，但只要有两个销售员同时提交了同一本书的出库单，就可能发生超卖。数据库的并发控制在这里很重要：如果两个请求同时读到库存剩余 1 本，都判断库存充足，然后都执行库存减 1，最后一次更新时库存就变成了 -1。
正确做法是把库存充足校验和库存更新放进同一条 SQL，让数据库的原子性来保证正确性：
sql复制UPDATE book_info
SET stock = stock - #{quantity}
WHERE id = #{bookId}
AND stock >= #{quantity}
这条 SQL 执行后返回受影响行数。如果返回 1，说明扣减成功；如果返回 0，说明当前库存不足或图书不存在，Service 层直接抛出业务异常提示“库存不足”。这样从根上避免了并发超卖的问题，不需要程序员手工在代码里 “select 出来判断再 update”。
除了 SQL 层面的原子更新，还有一种做法是用悲观锁，在事务中先执行 SELECT * FROM book_info WHERE id = #{bookId} FOR UPDATE 锁住行记录，然后再做判断和更新。这种方式实现直观，但会持有数据库行锁直到事务结束。图书进销存系统的并发量一般不大，用 update 条件更新更轻量实用。如果项目里用的是 MyBatis-Plus，也有乐观锁插件，但插件模式需要实体类里维护 version 字段，实际效果不如直接在 SQL 里加 stock >= #{quantity} 条件来得朴素可靠。
4.3 @Transactional 的坑：不是随便加一个注解就完事
采购入库和销售出库这类涉及多表更新的操作，必须在类或方法上标注 @Transactional(rollbackFor = Exception.class)。
我强调 rollbackFor，是因为 Spring 默认只在遇到 RuntimeException 时才回滚，而很多业务代码会抛出受检异常或者自定义异常，自定义异常如果不继承 RuntimeException，默认不回滚。曾经有人写事务方法，业务出现异常后抛了一个继承自 Exception 的自定义异常类，结果前几条 SQL 已经提交，库存改了，单据状态却还处于待处理状态，查了一晚上才找到是这个原因。
还有一个容易踩的坑：同一个类内部调用带事务的方法，事务会失效。比如 PurchaseService 的 createPurchaseOrder 方法调用了本类的 addBookStock 方法，而这是直接 this 调用，不会经过 Spring 代理对象，addBookStock 上的 @Transactional 不会生效。所以事务控制最好放在 Service 层入口类的 public 方法上，不要把事务切到私有方法或内部调用链中间层。
4.4 退货、盘点、报损：所有库存变动都要走同一条通路
千万别只在采购入库和销售出库里更新库存，退货、盘点、报损就不写库存流水了。一套合格的进销存系统，所有影响库存的业务动作，最后都要落到同一条“校验条件 → 更新库存 → 写流水”的通道里。
销售退货的场景是客户把书退回来，库存要增加，同时还要生成一张销售退货单，关联原销售单，便于财务退款核对。采购退货的场景是库房把有质量问题的书退给供应商，库存要减少，同时生成采购退货单，冲减对供应商的应付款。盘点调整则是在实际盘点后，把系统库存纠正为真实库存，差异部分也可以理解成一笔“非业务性”的库存变动，同样要记录原因和操作人。
把这么多入口交给同一个库存服务接口去处理，可以减少规则分散带来的维护风险。如果每个业务模块都各自写一套库存增减 SQL，用不了多久就会因为漏改某一个入口，导致数据不一致。
5. 从源码到跑通流程：环境搭建与高频踩坑记录
5.1 环境版本先对齐，能省掉一半的报错
拿到完整源码后，不用急着在 IDE 里双击启动。先看一眼文档里的环境要求，或者直接看 pom.xml。图书进销存这套源码通常建议 JDK 1.8 或 11，Maven 3.6 以上，MySQL 8.0，Node.js 16 以上。版本差异过大会触发一类非常隐蔽的问题，例如 SpringBoot 版本与 JDK 不匹配导致启动报 IllegalStateException，或者 Lombok 版本与 JDK 不兼容导致编译报错找不到 getter/setter 方法。
后端引入 Lombok 时要注意：JDK 8 和旧版 Lombok 是绝配，但如果本机装了 JDK 17 还强行跑 Lombok 1.18.20 以下的版本，会出现诡异的编译异常。遇到这种情况优先改 pom.xml 中的 Lombok 版本，不要和 IDE 版本死磕。
5.2 数据库初始化：字符集和连接串是关键
先在 MySQL 中创建数据库，字符集设置为 utf8mb4：
sql复制CREATE DATABASE IF NOT EXISTS book_store DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
然后选择 book_store，把源码提供的 sql 文件执行一遍。执行完成后检查一下核心表是否存在，尤其是 sys_user 和 book_info。很多资料误把 MySQL 8 的驱动类名写成 com.mysql.jdbc.Driver，这个类在 MySQL 8 里已经被移除了，必须使用 com.mysql.cj.jdbc.Driver。
SpringBoot 的 application.yml 数据源配置一般长这样：
yaml复制spring:
datasource:
url: jdbc:mysql://localhost:3306/book_store?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
username: root
password: your_password
driver-class-name: com.mysql.cj.jdbc.Driver
连接串有几个细节容易被忽略。serverTimezone=Asia/Shanghai 是解决 java.sql.SQLException 报时区错误的标准配置；allowPublicKeyRetrieval=true 解决 MySQL 8 使用 caching_sha2_password 认证时报 Public Key Retrieval is not allowed 的问题；useSSL=false 适合本地开发，避免 SSL 握手警告干扰日志。
5.3 后端启动和前端启动要注意的事项
后端部分，使用 IDEA 打开项目后，等 Maven 把依赖下载完成，直接运行主启动类。如果端口冲突，在 application.yml 中改 server.port。需要打印 MyBatis 执行的 SQL 时，加一行配置：
yaml复制mybatis:
mapper-locations: classpath:mapper/**/*.xml
configuration:
log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
这样控制台会输出每条 SQL 的完整语句和执行参数，排查查询异常会轻松很多。
前端部分是 Vue 工程，控制台进入 frontend 目录后执行：
bash复制npm install
npm run dev
npm install 如果下载速度慢或者卡住，可以把 npm 源切换成国内镜像，然后再执行安装。启动后按终端提示访问 http://localhost:端口 即可。
5.4 运行期常见的报错与解决办法，直接对照
| 现象 | 大概率原因 | 处理方式 |
|---|---|---|
| 启动报 Public Key Retrieval is not allowed | MySQL 8 认证插件兼容问题 | 连接串加 allowPublicKeyRetrieval=true |
| 驱动类找不到 | 驱动类名写错 | 改成 com.mysql.cj.jdbc.Driver |
| 中文乱码 | 数据库或连接字符集不对 | 库和表统一 utf8mb4，连接串加 characterEncoding=utf8 |
| 前端请求跨域 | 前后端端口不一致 | 后端配置 CORS 允许前端地址，或用代理转发 |
| MyBatis 提示找不到 Mapper XML | mapper-locations 配置缺失 | 配置 classpath:mapper/**/*.xml |
| 刷新页面 404 | 前端路由 history 模式没有后端配合 | 本地改用 hash 路由，或用 Nginx 配置 try_files 指向 index.html |
跨域问题在前后端分离项目中几乎是必踩项。Vue 开发服务默认在 5173 或 8080，SpringBoot 后端是 8080，浏览器默认限制跨端口 Ajax 请求。可以粗暴地在后端加一个全局 CORS 配置类，也可以在前端 vite.config.js 中配置 proxy 代理，推荐后者，这样生产环境切换更平滑。
6. 源码到手之后，我建议你先改这三个地方
6.1 先做一套权限模型，哪怕只是简化版
很多完整版源码会让初始管理员直接登录系统，所有用户共用一套权限。这种做法教学可以，但如果你准备把项目写进简历或者做二次开发，建议优先补上用户、角色、菜单三张表，再用拦截器或 AOP 实现对接口访问的控制。
图书进销存里的业务天然能拆出角色边界：库存查看、采购下单、销售结算、财务报表，不同角色对应不同菜单和数据范围。一个带权限控制的进销存系统，讲出来比单纯的 CRUD 有深度得多，面试时也可以顺着讲“我用拦截器校验 Token，并基于 RBAC 模型做接口鉴权”。
6.2 盯着库存流水和扣库存逻辑做验证
不要因为系统能跑通，就觉得库存代码没问题。建议你专门做一次“超卖小实验”：在代码里模拟两个请求同时购买同一本书，看最终库存是否变成负数。如果不为负数，再看系统是否给出了清晰的“库存不足”提示。
除了并发，还需要检查库存流水的完整性。采购入库一次，流水表应该多一条入库记录；销售出库一次，流水表应该多一条出库记录。如果只有业务表的数据变化，而 inventory_flow 却少记录，就是这个系统的数据追溯能力有缺漏，需要修复。
6.3 统一返回结构和全局异常处理，越早做越省事
打开 Controller 看一眼，如果每个接口返回的数据格式都不一样——有的返回 boolean、有的直接返回实体对象、有的返回 Map，那后续前端联调会非常痛苦。建议统一封装一个 JsonResult
全局异常处理能解决很多隐蔽问题，比如参数校验失败、数据库唯一键冲突、空指针等，不至于把堆栈直接抛给浏览器。这一步做完，前端和后端的协作体验会有质的提升。
如果你准备基于这套系统继续扩展，后续可以考虑加图书借阅模块、库存预警、进货商对账单、销售利润统计图表，甚至接入条形码扫码枪。每次扩展前，先想清楚这笔业务会落到哪张表、会影响哪些库存流水，系统才不会越改越乱。
说到底，源码只是起点。真正吃透它的人，不是会启动项目就结束，而是能把“采购、销售、库存、流水”这条业务主线的每一次流转都说得清楚。这本书一旦读通，以后换到任何进销存、供应链项目，你都会觉得套路似曾相识。