孙玲的空间1. 进销存系统的业务复杂度远超你写过的所有CRUD
1.1 为什么ERP项目里"业务梳理"比技术选型更重要
去年我参与过一个建材贸易商的进销存系统改造项目，仓库里堆着价值几千万的管材、阀门和电线，但老板问"现在外面还欠我们多少货"，财务要算三天，销售要翻五本Excel台账，仓库管理员凭记忆告诉你说"大概有三车货在路上，具体到哪了得问司机"。这就是典型的进销存失控：不是没记账，而是账、单、货三者根本没串联起来。
接手这类项目时，我最大的体会是：技术从来不是ERP项目的瓶颈，业务模型的清晰程度才是。Spring Boot再强大，也不能替你回答"一张采购订单被部分收货后，剩余数量是否允许改价"这种业务问题。所以做进销存系统的第一步，永远是先把企业的业务链路画出来，再谈建表和写接口。这篇文章记录的，就是我从需求分析到上线部署的一套完整方案，核心围绕单据流转和物流信息管理展开，适合正在做类似ERP系统的后端开发者，也适合想从零理清进销存业务逻辑的产品经理。
1.2 一套进销存真正要管住的单据链条
进销存三个字，听起来简单，拆开以后是一长串单据的接力：采购端有采购申请、采购订单、收货入库单、采购退货单；销售端有销售报价单、销售订单、发货出库单、销售退回单；仓库内部还有领料单、调拨单、盘点单、报损报溢单；最后财务还要关联应付单、应收单。这些单据不是孤立的，它们之间存在严格的上下游关系。
以采购为例，完整链路是"采购申请→采购订单→收货入库单→应付单"。销售端则是"销售订单→发货出库单→应收单"。我设计系统时，把这类链路统称为"单证流"，每一张单据都要记录它的来源单号，比如销售订单要记录它是从哪个报价单转化来的，发货出库单要回填对应的销售订单号。这样做的价值在于：任何一张库存流水，都能向上追溯到业务源头，向下追踪到账务结果。财务对账时点开一张出库单，就能看到它对应的销售订单、对应的客户、对应的回款记录，不用再翻三个系统。
这里有一个很容易被忽视的建模细节：单据必须分"主表"和"明细表"两层的结构。主表保存单据编号、往来单位、单据日期、经手人、审核状态、备注等公共字段，明细表保存商品编码、数量、单价、折扣、金额、批次号。为什么必须拆？因为一张采购单可能包含五十种商品，如果塞在同一张表里，后续修改某个明细行、部分收货、部分退货都会非常痛苦。主从表模型是进销存系统最底层的骨架，一旦建错，后面所有基于单据的统计查询都会变得极其别扭。
1.3 基础档案：商品、仓库、往来单位的建模细节
单据流跑起来之前，先要把基础档案打牢。商品档案是最容易想简单的地方。一个商品除了编码、名称、规格型号、单位之外，还应该考虑是否启用批次管理、是否启用保质期管理、默认仓库、默认供应商、采购价、销售价、最高库存、最低库存等字段。这些字段直接决定了后面库存模块和预警模块能不能做。
仓库档案同样有讲究。很多企业的"仓库"不是一个物理概念，而是多个逻辑库：比如"主仓""退货仓""报废仓""在途仓"。我的做法是在仓库表上增加一个"仓库类型"枚举字段，并且允许设置"是否参与可用库存计算"。待检仓和报废仓的库存不应该算进可销售数量里，否则销售员看到的库存永远比实际可卖的多，最后必然引发超卖投诉。
往来单位（供应商、客户）的建模也很关键。系统里要区分客户和供应商，但更复杂的场景是一个企业既是你的供应商又是你的客户。我的建议是建一张统一的"往来单位"表，用"单位类型"字段区分，中间再建关联表。这样后续做应收应付对账时，逻辑会清晰很多。另外往来单位一定要预留"联系人""电话""地址""信用额度""结算方式"这些字段，否则做到订单环节时再回头补档案，代价极大。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构选型与工程骨架：Spring Boot单体为什么够用
2.1 单体优先：中小企业的真实技术约束
我在跟技术同行聊ERP项目时，经常有人问"要不要上微服务、要不要用Kafka"。我的回答通常很直接：先看业务规模，再看团队配置，最后才是技术时髦度。中小企业ERP的典型特征是：日活几十到几百人，数据量在百万到千万级别，并发峰值很有限，但业务流程极其琐碎复杂。这个场景下，微服务带来的分布式事务、链路追踪、服务治理成本，会让一个三五个人的开发团队直接陷入泥潭。
Spring Boot单体应用的优势在这个阶段体现得淋漓尽致：部署简单，一个jar包搞定；事务管理由Spring统一控制，多表操作不用考虑跨服务一致性；调试方便，本地起一个服务就能复现问题；性能上完全够用。我甚至见过日订单量过万的传统行业ERP，单体架构跑得稳稳当当。所以结论是：除非企业明确有多个门店/多个法人实体强烈隔离的需求，否则第一版系统不做微服务，先把业务完整性做扎实。
2.2 Maven多模块拆分：让业务代码不拧成麻花
虽然不搞微服务，但不代表代码可以全部堆在一个模块里。我用Maven多模块来构建工程，既保留了单体的部署便利，又让代码边界清晰。实际项目里，我习惯拆成下面几个模块：
| 模块名 | 职责 |
|---|---|
| erp-common | 公共工具类、统一返回结果、异常定义、常量、枚举 |
| erp-framework | Spring配置、安全配置、Redis配置、MyBatis Plus配置、通用切面 |
| erp-system | 用户、角色、菜单、部门、字典、操作日志等系统管理功能 |
| erp-business | 商品、仓库、往来单位、采购、销售、库存、盘点等核心业务 |
| erp-report | 报表查询、统计汇总、导出 |
| erp-web | 启动类、控制器层、接口路由 |
这样一个项目启动时只加载一个Spring Boot应用，但代码上彼此隔离。核心依赖方向是business依赖system，report依赖business，common谁都能依赖。这种依赖方向能避免未来某天你想把报表抽成独立服务时，发现报表模块和业务模块纠缠不清。
模块拆分还有一个隐藏好处：编译速度。业务代码量大以后，只改business模块重新打包比整个项目推倒重编快很多。CI/CD的时候也可以只对变更模块做增量构建。
2.3 依赖版本组合：Spring Boot 2.6 + MyBatis Plus + Druid
版本选择上，我当前项目用的是Spring Boot 2.6.13，搭配MyBatis Plus 3.5.2和Druid 1.2.15。之所以不追最新版，是因为团队对稳定性要求高于新特性，而且很多企业客户生产环境的JDK还是8或11。Spring Boot 2.6虽然不算新，但足够成熟，各种第三方库的兼容性问题基本都被踩平了。
这里有一个非常现实的坑：如果你用Spring Boot 2.6及以上版本，Swagger相关组件不要用老的springfox 2.x，因为Spring MVC的路径匹配策略从AntPathMatcher改成了PathPatternParser，springfox 3.0.0直接启动报错。解决方式有两个：要么把spring.mvc.pathmatch.matching-strategy调回ant_path_matcher，要么用springdoc-openapi这个新组件。我的建议是直接上springdoc，毕竟是适配了新版本Spring Boot的文档工具，后续维护更省心。
Druid连接池配置上，除了常规的initialSize、minIdle、maxActive，我强烈建议开启testWhileIdle和removeAbandoned。生产环境最怕出现连接泄漏，一个事务里开了连接没关，慢慢把连接池耗尽，线上接口全部卡死。Druid的removeAbandoned能自动回收超时未关闭的连接，虽然治标不治本，但至少能保住系统不整体宕机。
3. 单据流转：把"一进一出"变成可追踪的状态机
3.1 一张采购入库单的完整生命周期
单据流转是进销存系统的灵魂，它的本质是一个状态机。以采购入库单为例，最常见的状态流转是：草稿→已提交→待收货→部分入库→已入库→已生成应付。每一个状态都由特定的操作触发，而操作又受角色权限约束。设计状态机时，我建议先把状态枚举写死在代码里，而不是放在数据库字典里随便改。
状态机的核心是"谁能在什么状态下做什么操作"。比如"已审核"的入库单不能直接删除，只能红冲；"已提交"的采购订单不能再改单价。这些规则不写清楚，后面一定会出现操作人员"灵机一动"把流程绕过去，最终导致库存账目对不上。我的做法是设计一个DocumentStateMachine工具类，所有单据的状态流转必须经过它校验，非法流转直接抛业务异常。这套机制在项目后期对账时帮了大忙——因为每一张单据的操作链路都留痕了。
3.2 单据号、主从表结构与幂等控制
单据编号看起来是个小功能，实际上是并发问题的重灾区。我最早用"前缀+日期+数据库自增ID"的方式生成单号，上线第二天就出现两张单号重复的单据。原因很简单：多线程同时insert，自增ID拿到了还没写库，另一个线程也拿到了同一个ID。后来我改成"前缀+年月日+Redis自增序号"，每次从Redis取号并设置当天过期时间，配合数据库唯一索引兜底，再也没出现过重复单号。
主从表结构前面说了，这里补充一个明细行的幂等控制细节。当用户连续快速点击"保存"按钮时，页面会发起两个一模一样的请求，如果后端不做处理，数据库就插入两条相同的采购明细。我的方案是：前端生成一个业务流水号（UUID）作为幂等键，后端在事务里先查这个幂等键是否已存在，存在就直接返回已保存的单据，不存在才执行insert。这个机制成本极低，但能避免大量脏数据。
3.3 审批流：自己写还是上Flowable
审批流是单据流转的高阶需求。采购订单超过一定金额要总经理审批，销售出库要仓管和财务双人确认，这些规则五花八门。项目实践中，我走了一条中间路线：第一版先用自己写的简单审批钩子，在单据状态枚举里增加"待审批"和"审批不通过"，每个单据类型配置一道可选的审批人逻辑，通过Spring的事件机制发出审批通知。这样实现快，规则也够用。
等到业务方明确提出"要支持三级审批""不同部门审批链不一样""审批要能加签转签"，我才在第二版引入Flowable工作流引擎。Flowable的好处是流程定义可视化、审批历史完整、支持复杂网关；坏处是学习成本和部署复杂度成倍增加。所以我的建议是：不要一开始就上工作流引擎，先用状态机+事件机制扛住第一版业务，等需求真正复杂化再迁移。很多中小企业的审批需求其实用一个"审批模板表"就够，完全不需要引入重型框架。
3.4 单证链：从采购订单到应付账款的可追溯闭环
单据流转到最后，一定要形成闭环。什么叫闭环？就是业务单据必须能关联到财务单据，库存流水必须能关联到业务单据。我做了一张中间表document_relation，字段包括source_type（来源单据类型）、source_id、target_type、target_id、relation_type（生成/红冲/关联）。这张表是单证链的索引，所有模块查上下游关系都走它。
举例：财务要看"这个月应付账款为什么多了三十万"，她打开应付单列表，点开任意一张应付单，能跳转到对应的采购入库单；再点入库单，能跳转到采购订单；再点采购订单，能看到申请人和审批记录；再点供应商档案，能看到这家供应商所有的历史往来。这种体验建立在每张单据都在落库时主动写document_relation的基础上。这件事虽然琐碎，但做完整套系统之后，它带来的对账效率提升是质变级的。
4. 仓库与库存：让"账实相符"从月底盘点变为实时可信
4.1 库存模型：现存量、可用量、在途量的拆分
库存是进销存系统里最容易出问题、也最需要精细建模的部分。很多新手设计库存表只有"商品+仓库+数量"三列，这种做法在业务简单时能跑，一旦出现采购在途、销售占用、待检入库、调拨在途这些状态，就全乱套。我的建模方式是拆成三个概念：
- 现存量：物理上已经躺在仓库里的数量。
- 可用量：现存量减去已经被销售订单占用的数量，再减去锁定冻结的数量。
- 在途量：已经下单采购但还没到货的数量，以及已发货但客户还没签收的数量。
对应到数据库，我建了两类表。一类是inventory_balance，保存每个商品在每个仓库的现存量、可用量；另一类是inventory_transaction，保存每一条库存变动流水。流水表只增不改，balance表由流水事务性更新。这样设计的好处是，如果某个SKU的余额异常，可以通过流水表完整回放出它所有的变化历史，定位问题非常快。
4.2 库存流水的设计与并发扣减方案
库存流水的字段设计要有"业务溯源"意识。我的流水表至少包括：sku_id、warehouse_id、change_type（采购入库、销售出库、调拨入、盘盈、盘亏等）、change_qty（正数入库、负数出库）、before_qty、after_qty、source_order_no（来源单据号）、created_by、created_time。其中before_qty和after_qty是定位并发问题的关键，如果发现流水不连续，基本可以断定存在并发扣减或漏记。
扣减库存时的并发控制，我采用的是"乐观锁+唯一约束"双保险。SQL大致是这样：
sql复制UPDATE inventory_balance
SET available_qty = available_qty - #{qty},
version = version + 1
WHERE sku_id = #{skuId}
AND warehouse_id = #{warehouseId}
AND available_qty >= #{qty}
AND version = #{version}
这个SQL的意思是：只有当前可用量足够、且版本号没变时才允许扣减，影响行数为0则说明库存不足或版本冲突。在高并发场景下，再叠加Redis分布式锁，可以最大限度防止超卖。实际项目中，我发现很多超卖问题并不是并发导致的，而是业务逻辑上忘了把"已锁定但未出库"的数量扣掉，所以在订单创建阶段就要占用可用库存，而不是等到真正出库才扣。
4.3 盘点与批次保质期：最容易翻车的细节
盘点业务经常在项目上线后被吐槽，原因是设计时没考虑"盘点期间业务还在继续发生"。比如仓库凌晨盘点A商品，结果白天业务员还在正常开单出库，一觉醒来账面数字和盘点数字对不上。我的做法是引入"盘点冻结窗口"机制：创建盘点单时，把盘点的仓库+商品冻结起来，不允许发生出入库业务，直到盘点结束。虽然会影响业务，但换来的是盘点结果可信。如果业务要求不能冻结，那就必须做"盘点期间流水归集"，把盘点开始后的出入库流水额外记录，在盘盈亏计算时冲减。这个逻辑实现起来复杂得多，非必要不推荐。
批次和保质期管理的核心在于库存维度。启用批次管理后，库存的维度就从"商品+仓库"变成了"商品+仓库+批次号+生产日期+到期日期"。出库时要按照先进先出（FIFO）自动匹配批次，也就是按生产日期升序扣减。这个逻辑要用SQL写出来有一定复杂度，但绝不能省——食品、医药、化工行业的进销存，保质期预警是刚需。我通常会在定时任务里每天扫描即将到期（比如90天内）的批次，生成预警消息推给仓管员和采购员。
5. 物流信息管理：把"货在路上"变成可查询的实时状态
5.1 物流单号的采集方式：接口对接与手工维护
物流信息管理的核心诉求很简单：客户问"货到哪了"，客服不用再打电话问司机。实现上有两条路，一是与快递平台（如快递鸟、快递100）做接口对接，自动获取物流轨迹；二是纯手工维护，在系统里录一个物流单号，配上粗粒度的状态（已发货、运输中、已签收）。
如果企业用的是顺丰、德邦这些标准化快递公司，我强烈建议直接接入快递平台的物流查询API。这些平台通常提供实时轨迹查询，一个单号调用一次就能返回完整的物流节点。接入方式是：在发货出库单上增加"物流公司"和"物流单号"两个字段，出库审核通过后自动创建一条物流记录，然后定时任务定期查询未完结物流单的轨迹，并异步写入物流轨迹表。流程上要注意：物流单号允许发货后补录，因为实操中经常是仓库把货运走了，物流单号要等快递员回到网点才能拿到。
5.2 轨迹拉取与状态推送的异步化设计
物流轨迹拉取有一个非常典型的技术陷阱：外部API的响应速度不可控。如果把"查询物流轨迹"放在订单详情接口里同步执行，一旦快递平台接口超时，整个订单页面都要跟着卡住。所以我坚决把它做成异步任务：定时任务扫描状态不是"已签收"的物流单，逐批调用快递平台查询，结果更新到本地logistics_track表，并通过WebSocket推送消息给前台，前端页面被动刷新轨迹。
这种设计可以推广到所有与外部系统交互的场景。比如对接短信服务、对账平台、电子发票，一律异步化处理。我当时的做法是引入RabbitMQ做消息削峰，物流轨迹查询任务作为生产者，处理模块作为消费者，消费者失败后自动重试，重试三次仍失败就进入死信队列，由人工介入排查。后来复盘，这套异步架构帮我们扛过了一次物流高峰，快递平台限流导致接口大面积超时，但ERP主流程完全没受影响。
5.3 异常物流的告警与处理闭环
物流信息管理的另一个价值点是异常处理。我建了一套规则引擎：物流单超过48小时没有新轨迹更新、运输状态变成"异常签收"或"退回"、客户收货地址与实际签收地址偏差过大，都会触发告警。告警消息通过站内信和短信发给对应客服人员，客服直接在系统里发起"物流异常工单"，指派给物流专员跟进。
这个闭环的意义在于，物流不是发货后就不管了，而是要管到客户签收。实际业务中，大批量的"货在路上"并不复杂，复杂的是那1%的异常件——丢件、破损、错发、拒收。把异常物流纳入线上管理，能让客服从"反复打电话问承运商"的泥潭里解放出来，同时系统里留存的异常处理记录，也是未来跟承运商做赔付谈判的凭证。我甚至建议在报表模块增加一个"物流时效分析"，按承运商维度统计平均时效和异常率，帮助商务谈判拿到更低运费。
6. 权限、安全与数据隔离：系统能否上线的硬门槛
6.1 RBAC模型与Spring Security+JWT落地
ERP系统里不同角色的权限边界必须清晰：普通业务员只能看自己的单据，仓库主管能看全仓库的库存，财务只能看金额不能改数量。我用的是经典RBAC（用户-角色-权限）模型，Spring Security负责认证和授权，JWT做无状态令牌。用户登录成功后，后端生成JWT，前端每次请求在Header里携带，拦截器解析JWT获取用户ID和角色集合。
JWT实现的几个细节值得注意。一是密钥要放在配置中心或环境变量里，不能硬编码到代码库；二是token过期时间不宜过长，我一般设置2小时，配合前端基于刷新接口自动续期；三是token里不要存敏感信息，只存userId和loginName，其他信息每次请求时从缓存里取。用户注销或改密码后，要立即让旧token失效，我的方案是在Redis里维护一个用户token版本号，JWT里带上版本号，请求时比对，不一致就拒绝。
6.2 数据权限：仓库、部门、单据级别的可见性控制
RBAC控制的是"能不能访问某个功能"，但进销存里更棘手的是"同一功能下能看到哪些数据"。一个分仓管理员的角色，他能打开库存查询页面，但只能看到自己负责仓库的库存，不能看到其他仓库。这种数据权限我采用"数据范围"策略设计：给角色绑定数据范围，可选"仅本人""本部门""本仓库""全部"。
实现上我写了一个DataScopeHelper，在MyBatis Plus的查询条件里自动追加数据权限SQL片段。比如当前用户角色数据范围是"本仓库"，那查询库存时自动追加AND warehouse_id IN (用户关联的仓库列表)；查询销售订单时追加AND created_by = 当前用户。这个功能的重要程度不亚于功能权限，如果漏了，就会出现分公司A的业务员看到分公司B的报价单这种严重事故。
6.3 审计日志与敏感字段加密的实现细节
审计日志在ERP里是刚需——万一出现纠纷，要能查出来"谁在什么时候把这张销售订单的单价从100改成了80"。我用MyBatis的Interceptor统一拦截实体insert/update操作，对比修改前后的字段值，把差异写入audit_log表。实体类上通过@AuditField("商品单价")注解标注需要审计的字段，拦截器扫描注解动态生成日志内容。这个方案对业务代码零侵入，上线后帮我们发现了不少"手滑改价"的问题。
敏感字段加密这里，我处理过客户手机号和身份证号的加密存储需求。实现方式是MyBatis的TypeHandler：定义EncryptTypeHandler，insert时自动加密，select时自动解密。但要注意，加密字段不能直接做模糊查询，比如WHERE phone LIKE '%138%'对加密存储的字段是无效的。一个可行的折中方案是增加一个phone_md5字段，用于精确查询和唯一性校验，模糊查询则通过前端传入脱敏后的部分值，在应用层匹配后再查主键。这个方法不能解决所有场景，但能满足绝大多数业务需求。
7. 性能优化与踩坑实录：那些让你通宵上线的问题
7.1 库存超卖问题的本质与拦截方案
超卖是所有进销存系统上线初期最容易爆的问题，而且爆起来非常隐蔽。线上有个很典型的case：同一款SKU，两个销售同时给客户开销售单，系统查询库存都显示还有10件，两个单子都按10件锁定了，结果实际库存被扣了20件，账面变成-10。表面看是并发问题，本质是"先查后扣"这个动作不是原子的。
我最终的方案是三层防线：第一层，扣减SQL里带条件available_qty >= #{qty}，让数据库自己保证不能扣成负数；第二层，对扣减操作加Redis分布式锁，锁的粒度是sku_id:warehouse_id，保证同一商品同一仓库的扣减是串行的；第三层，在订单提交入口再校验一次可用库存并给前端明确提示。这三层下来，超卖基本被杜绝了。排查历史超卖问题时，我的经验是先查inventory_transaction流水里的before_qty和after_qty，如果发现某个商品前后两条流水不连续，就往对应的source_order_no追查，问题链路很快就能浮出来。
7.2 单据编号并发生成重复，怎么排查
单据编号重复这个问题，我要重点讲一下排查思路。现象是采购订单表出现了两个一模一样的单号，但内容完全不同。最开始我以为是并发导致的自增ID重复，查了代码发现用的是Redis自增，理论上不该重复。然后逐条日志排查，才发现问题是出在"手动新增"和"Excel导入"走了两个不同的编号生成方法，一个用了Redis，另一个用了数据库的max(id)+1。业务验证时单量小看不出问题，正式上线后两条路径同时跑，就在同一天撞号了。
这个坑给我的教训是：所有入口的编号生成必须收敛到同一个服务方法，不允许出现"这里一套、那里一套"的写法。另外数据库层面一定要加唯一索引兜底，即使代码写错，insert也会被数据库拦住，而不是让脏数据静默落库。修复之后，我又花了一个晚上把历史数据里的重复单号全部排查清理了一遍，过程极其痛苦。大家做这类系统时，请务必把唯一索引建在业务主键之外的编号字段上，并且编码规范里写死"禁止绕过统一编号服务"。
7.3 SQL执行10秒自动关闭？连接池超时配置的真相
有同行问过我"JVM或者Spring Boot会设置一个SQL执行10秒自动关闭吗"，这个问题的背景是生产环境出现了SQL执行超过10秒后报错的情况。准确地说，Spring Boot本身不会自动设置10秒的SQL超时，但如果使用Druid连接池并配置了queryTimeout，或者数据库驱动和连接池一起生效，确实可能出现10秒左右的超时中断。
我给Druid的推荐配置如下：
yaml复制spring:
datasource:
druid:
initial-size: 5
min-idle: 5
max-active: 20
max-wait: 60000
time-between-eviction-runs-millis: 60000
validation-query: SELECT 1
test-while-idle: true
test-on-borrow: false
test-on-return: false
remove-abandoned: true
remove-abandoned-timeout: 180
query-timeout: 30
注意query-timeout是按秒计的，我设成30秒而不是10秒，给慢SQL留了缓冲。但真实经验告诉我，与其调大超时时间，不如去优化那个慢SQL。系统上线后我建了一张慢查询日志表，通过MyBatis的Interceptor记录每个SQL的执行时间和参数，每天跑一次统计，把执行超过1秒的SQL列出来逐条优化。几个月下来，整个系统最慢的接口稳定在800毫秒以内。
7.4 大表分页慢，优化后从8秒降到200毫秒
库存流水表和操作日志表增长极快，半年就能到千万级。最开始的列表分页用的是MyBatis Plus的page方法，直接执行LIMIT offset, size，offset一大就慢得离谱，上万条数据的分页查询要跑8秒。问题出在全表扫描加回表上，MySQL要先把前offset条数据全部查出来扔掉，再往回取size条。
我的优化方案是覆盖索引加延迟关联。先在索引里找到当前页的主键ID集合，再用主键回表查完整数据。SQL大致是：
sql复制SELECT t.*
FROM inventory_transaction t
INNER JOIN (
SELECT id
FROM inventory_transaction
WHERE sku_id = #{skuId}
ORDER BY created_time DESC
LIMIT #{offset}, #{size}
) tmp ON t.id = tmp.id
ORDER BY t.created_time DESC
子查询只查主键，走了覆盖索引，速度极快。配合在(sku_id, created_time)上建立联合索引，分页查询从8秒直接降到200毫秒。另外，如果业务场景不需要跳页，只是"上一页/下一页"滚动翻页，更推荐用游标分页（基于created_time < 上一页最小时间的方式），性能还能再高一截。
8. 部署上线、数据迁移与二次扩展方向
8.1 从开发机到服务器的部署要点
系统开发完部署到Linux服务器，我踩过最痛的坑是时区问题。开发机上一切正常，上了服务器后所有单据时间都差了8个小时。原因很简单：服务器系统时区是UTC，MySQL连接串又没配serverTimezone=Asia/Shanghai。后来我在所有环境的JDBC连接串里强制加上serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8，并且JVM参数里也固定-Duser.timezone=Asia/Shanghai，这个问题才算彻底根治。
部署方式上，第一版我用的是systemd管理jar包，一个服务一个service文件，日志通过重定向写到文件，再用logrotate做日志切割。后来上了Docker，镜像基础用eclipse-temurin:8-jre，打包时把配置外置到/app/config目录，环境差异靠环境变量注�入。Nginx放在最前面做反向代理和静态资源托管，前端Vue打包后的dist目录直接扔给Nginx，动态接口走/api前缀反向代理到Spring Boot。这套部署架构非常稳，运维成本极低。
8.2 期初数据导入与新旧系统切换
上线最紧张的不是写代码，而是数据迁移。老系统里的商品档案、客户档案、供应商档案、期初库存、未完成订单，都要整理成符合新系统结构的Excel批量导入。我的做法是开发一个"数据导入中心"功能，支持模板下载、逐行校验、错误提示、分批导入。导完以后还要做一轮"试算平衡"：导入的期初库存金额合计，必须等于财务提供的期初存货余额；导入的应收应付合计，必须等于资产负债表上的对应科目余额。这个校验步骤不能省，否则账不平，后面所有财务分析都是错的。
新旧系统并行期我建议跑一个月。并行期间老系统照常用，新系统同时录入同一批业务，每周做一次数据比对，月底两边账目一致了再关掉老系统。这个流程虽然增加了一倍录入工作量，但能极大降低切换风险。我见过不少企业为了省事直接砍掉并行期，结果新系统跑了一个月发现有严重漏单，又灰溜溜退回老系统，这个反复的代价远高于并行期的录单成本。
8.3 后续扩展：电商对接、多租户与MES集成
进销存系统落地之后，很多企业会提出生态对接需求。最常见的是电商对接：天猫、京东、拼多多店铺的订单要自动同步进ERP，仓库发货后要回传物流单号给电商平台。这种对接的核心是接口幂等和库存实时同步，我建议在ERP侧设计一个"电商订单适配层"，统一处理平台差异，避免每个平台一套逻辑散落在业务代码里。
另一个重要的扩展方向是ERP与MES集成。ERP管的是"进销存和财务"，MES管的是"车间生产执行"，两者之间需要交互的数据主要是物料需求计划（MRP）和生产领料/成品入库单据。常见的做法是通过中间表加消息队列做异步同步，ERP下发生产工单给MES，MES完工后把产成品入到指定仓库，触发ERP的入库单。这个集成一旦打通，企业的"产、供、销、存"就真正连成了一张网，也是传统ERP项目向智能制造延伸的关键一步。
最后再分享一下我个人的落地体会。进销存系统虽然技术上不追求高大上，但它对业务理解的要求极高，如果一开始没把单据流转、库存模型这些底层设计想清楚，后期改造成本会让你崩溃。如果你也在做类似项目，我的建议是：先花两周时间把业务流程图和管理制度梳理透，再花一周确认数据库模型，最后才是动手写代码。代码写得快，业务理得清，系统才能真正用得起来。另外，上线后一定要珍惜每一次业务人员反馈的"这里不对"，那通常不是他们在找茬，而是系统设计和你没想明白的场景在提醒你补课。