做这个项目之前我们公司的服务器销售信息基本靠Excel表格加微信群在管销售在群里报一个机型配置库管翻Excel看有没有现货财务再反查合同回款到没到账。单子少的时候还凑合客户一多价格对不上、序列号查不到、回款逾期没人提醒整个流程乱成一锅粥。后来我用SpringBoot完整搭了一套企业内部服务器销售信息管理平台把客户、报价、订单、库存、合同回款全部串起来这套系统在公司跑了快一年基本稳定。这篇文章就把这套系统的设计思路、核心实现和踩坑记录都整理出来适合准备做类似信息管理平台的后端开发以及想在企业内部快速落地销售管理系统的团队参考。1. 先梳理业务流程销售信息管理平台的核心价值1.1 为什么这类系统天然适合用SpringBoot做单体企业内部管理平台有一个很典型的特征用户量不大但业务流程复杂、数据状态多、角色分工明确。服务器销售业务又比普通商品销售更特殊单价高、配置细、每台机器都有唯一序列号还要区分现货和在途报价时经常有折扣审批回款还可能是分阶段到账。这一套流程如果全部靠人肉协调早晚要出大问题。我见过不少团队上来就想拆微服务、上容器编排实际上这类项目用SpringBoot做一个模块化单体应用是最省力的解法。原因很简单几十个到几百个人用的内部系统并发压力很小核心矛盾是数据一致性和流程清晰度。单体应用单库单应用出了问题顺着接口日志往下查就行任何人接手都能快速看懂。微服务那套链路追踪、分布式事务、服务注册发现在这个体量下全是额外负担硬上只会让开发效率和稳定性双双下降。所以这个项目从一开始就定了基调SpringBoot单体项目按业务模块分包不搞跨服务调用所有事务边界都控制在Service层内。数据正确性靠数据库约束和事务保证性能靠索引和合理SQL保证这就足够了。1.2 核心模块划分报价、订单、库存、回款四条主线整个销售信息管理平台我拆成了七个模块客户管理、商品与库存、报价管理、订单管理、合同回款、统计报表、系统管理。每个模块的边界要非常清晰否则后边写代码会到处互相调用改一个需求牵一发动全身。客户模块不只是存一个公司名称还要维护联系人、电话、地址、信用等级。服务器销售很多是老客户复购联系人经常换这些信息必须单独建表。商品与库存模块负责服务器产品型号维护、现货资产入库、序列号状态流转。报价模块管的是报价单的生成、折扣审批、报价转订单。订单模块承接报价单生成正式销售订单并触发库存预占与出库。合同回款模块把订单归集到合同下制定回款计划并登记实际到账。统计报表模块汇总销售额、回款逾期、库存周转等核心指标。系统管理模块管用户、角色、权限、操作日志和基础参数。这七个模块里最核心的是报价、订单、库存三个因为整个业务流程是“客户询价 - 销售报价 - 审批通过 - 转订单 - 扣库存 - 出库 - 回款”一条链路串下来中间任何一环出错都会影响后续环节。回款虽然偏财务但它直接决定了能不能继续给这个客户发货所以也必须在同一套系统里闭环管理。1.3 技术选型不是拍脑袋每个选择都有明确理由技术栈选型如下SpringBoot 2.7 JDK 8 MyBatis-Plus MySQL 8 Redis JWT前端用Vue 3 Element Plus。这套组合在今天看起来不算新但放在企业内部项目里非常稳。SpringBoot 解决的是“快速开发”和“统一配置”的问题。依赖版本由父POM统一管理内嵌Tomcat让部署变成一个jar包配置文件支持多环境切换这些东西在内部系统里能省掉大量环境搭建时间。MyBatis-Plus 提供单表CRUD和分页插件复杂查询写XML日常开发效率比纯JDBC高很多。MySQL 8 的窗口函数和JSON能力够用完全不需要上更重的数据库。Redis 在这里承担两个职责一是会话缓存和Token状态管理二是缓存客户列表、产品参数这类变更频率低的热点数据。Vue 3 Element Plus 做后台管理界面很成熟表格、表单、弹窗、权限按钮都有现成组件开发速度非常快。为什么不引入MQ、ES、微服务这类东西答案很简单现阶段业务没有这个需求。引入中间件意味着增加运维成本和故障点一个内部管理系统如果还要专人维护一套消息队列那就本末倒置了。等单量和数据量真正上来再做局部演进而不是一开始就把架构搞复杂。2. 数据库设计把服务器销售拆成一张张表2.1 服务器型号与资产分离避免配置信息重复存储一开始我把服务器的“型号”和“具体某一台机器”混在一张表里结果发现一个型号会卖很多台每台机器有独立序列号、独立保修期、实际库房、采购成本都不一样混在一起根本没法管理。后来拆成两张表server_model存型号公共参数server_asset存每一台具体机器的实例信息。型号表存的是品牌、CPU型号、内存大小、硬盘配置、机架单位、建议售价这些静态属性资产表存的是序列号、所属型号、当前状态、所在库位、采购成本、保修截止日期。这样查询型号列表时只读model表查询现货库存时读asset表通过model_id关联。这段DDL可以给你一个直接参考CREATE TABLE server_model ( id BIGINT PRIMARY KEY AUTO_INCREMENT, model_code VARCHAR(64) NOT NULL, brand VARCHAR(64), cpu_model VARCHAR(128), memory_gb INT, disk_info VARCHAR(256), rack_unit INT, warranty_months INT, price_suggest DECIMAL(12,2), UNIQUE KEY uk_model_code (model_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT 服务器型号表; CREATE TABLE server_asset ( id BIGINT PRIMARY KEY AUTO_INCREMENT, serial_no VARCHAR(128) NOT NULL, model_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1在库 2预占 3出库 4返修 5报废, location_code VARCHAR(32), cost_price DECIMAL(12,2), warranty_end DATE, in_at DATETIME, out_at DATETIME, order_id BIGINT COMMENT 出库关联订单ID, UNIQUE KEY uk_serial_no (serial_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT 服务器资产表;序列号必须加唯一索引这是防止重复出库的最后一道防线靠代码判断总有漏掉的时候数据库约束永远不会骗你。2.2 报价单与订单历史快照和状态机缺一不可服务器销售里报价是最高频的动作。客户问“这个配置多少钱”销售先查历史成交价再结合当前折扣权限给出报价单。这里有一个非常容易踩的坑报价单不能只存型号ID和单价因为型号表里的价格和配置随时可能调整如果报价单直接引用型号表三个月后回看历史报价就全变样了。所以报价单要拆主表和明细表明细表里冗余一份“配置快照”也就是把下单那一刻的型号名称、CPU、内存、硬盘、单价、折扣全部原样存下来。订单生成时同样做快照订单明细不再依赖报价明细ID去反查当时的配置。状态机也要设计好。报价单状态草稿 - 待审批 - 已批准 - 已转订单 - 已取消。订单状态待审核 - 备货中 - 已出库 - 已完成 - 已取消。状态流转要集中在一个Service方法里做不能散落在Controller里到处改状态否则后边加审批层级时会非常痛苦。比如报价单审批只允许待审批状态被审批已取消的报价单不能直接转为订单这些规则用状态字段加异常校验来控制。2.3 合同回款与客户信用欠钱的客户必须能被系统拦下来合同和回款这种偏财务的表设计时要把“计划”和“实收”分开不能简单在一个合同表里放一个“已回款金额”。因为服务器销售经常是预付款加到货款加质保尾款三笔钱对应三个时间点如果只有一个字段根本没法做逾期提醒。我的做法是contract表存合同号、客户ID、总金额、签订日期、备注receipt_plan表存回款计划每条计划有期次、计划金额、到期日、实收金额、实收日期、状态。这样财务录入一笔回款时系统自动匹配到对应的回款计划逾期未收的在首页看板直接标红。客户表加一个credit_level字段信用等级分高、中、低三档。低信用客户在创建订单时系统强制要求财务复核。这个规则听上去简单但在真实业务里救过我一次有个客户连续三次逾期系统自动拦截了新订单后来了解到那个客户资金链已经出了问题如果没有拦截我们就要压一批服务器库存和应收账款。2.4 RBAC权限模型销售不能看成本价财务不能改库存内部系统最怕权限失控。销售如果能看到采购成本报价谈判时就会很被动库存管理员如果能改订单状态就可能绕过出库流程。所以权限必须做成RBAC模型user、role、user_role、role_permission四张表角色与权限多对多关联。我分了五类角色销售、销售主管、库存管理员、财务、超级管理员。销售只能维护自己的客户、创建报价单、提交订单销售主管可以审批本组报价、查看组内订单库存管理员只负责入库、出库、盘点看不到单价和折扣财务能看合同、回款、逾期数据但不能动库存。超级管理员原则上不参与业务操作只负责配置参数和创建账号。角色核心权限禁止操作销售客户维护、创建报价、提交订单查看成本价、修改库存销售主管报价审批、查看本组数据修改回款信息库存管理员入库、出库、盘点、库位调整修改订单价格财务合同登记、回款录入、逾期查看修改库存状态超级管理员全部权限、参数配置无这里有个实践心得前端菜单按权限隐藏按钮但后端接口必须再校验一次因为有人可以直接调接口绕过界面。接口层统一用Spring Security的权限注解控制不需要走界面直接请求接口也能被拦下来。3. 后端核心模块实现3.1 认证鉴权与操作审计登录只是开始留痕才是重点认证方案我用了Spring Security JWT Redis。用户登录后校验密码密码用BCrypt加密存储登录成功生成JWTToken字符串返回前端同时在Redis里记录会话状态。后续请求都带Authorization: Bearer token后端通过过滤器解析Token并设置SecurityContext。登录接口的核心代码并不复杂但有几个细节必须注意PostMapping(/login) public RLoginResp login(RequestBody LoginReq req) { User user userService.findByUsername(req.getUsername()); if (user null || !passwordEncoder.matches(req.getPassword(), user.getPassword())) { return R.error(用户名或密码错误); } String token jwtUtil.createToken(user.getId(), user.getRoles()); return R.ok(new LoginResp(token, user.getNickname())); }第一个细节是密码错误提示不要区分“用户不存在”和“密码错误”否则别人可以通过接口爆破出有效账号。第二个细节是JWT密钥不要写死在代码里要放在配置文件中生产环境用环境变量注入。第三个细节是Token过期时间内部系统我设置为8小时太短影响体验太长不安全。操作审计这件事很多内部系统都不做但我强烈建议做。用AOP切面加自定义注解AuditLog在报价审批、订单生成、出库确认、回款录入这些关键写操作上标注一下切面自动记录操作人、操作时间、操作类型、业务单号、请求参数和旧值变更。平时这个功能完全没存在感一旦出现对账争议、客户投诉、内部分歧它就是唯一的证据来源。3.2 报价审批与订单生成业务流程写在Service层别散在Controller里这块是整个业务系统的核心痛点。报价单提交后进入审批流审批依据是折扣比例折扣在95折以内销售主管直接批低于9折需要财务复核毛利。所以报价单上存了成本价和成交价销售界面看不到成本价但主管审批时能看到预计毛利。审批通过后订单模块有一个“转订单”按钮。这个动作的逻辑是读取报价单快照生成订单主表和订单明细表同时调用库存服务预占库存。在Service层用Transactional包住整个流程任何一个步骤失败都整体回滚避免出现订单生成了但库存没扣的情况。Transactional(rollbackFor Exception.class) public Long createOrder(Long quotationId, Long customerId) { Quotation quo quotationService.getById(quotationId); if (!Status.APPROVED.equals(quo.getStatus())) { throw new BusinessException(报价单未审批通过不能生成订单); } Order order OrderConvert.toOrder(quo); order.setCustomerId(customerId); orderService.save(order); stockService.occupy(order.getId(), quo.getItems()); return order.getId(); }这里有一个Spring事务的经典坑Transactional只在通过代理调用时生效如果在同一个类内部调本类的另一个方法事务会失效。所以我习惯把跨实体的复杂操作放到独立的Service类里或者注入自己的代理对象调过来避免自调用问题。订单号生成我用了“日期类型序号”的规则比如SO20250407001每天从1开始自增。这个序号不能用数据库主键因为主键是全局自增会露出业务量。用一个order_seq表按日期记录当天序号在事务里加行锁再更新防止并发生成重复单号。3.3 库存扣减并发控制乐观锁加唯一索引双保险才敢说稳服务器库存是按台数量管理的不是像日用品那样按库存数量扣减。每台机器有独立序列号、独立状态所以核心操作是“把某台机器的状态从在库改成出库”。并发问题在于两个人同时点了同一台机器的出库如果不加控制两个事务都会读到“在库”状态然后都更新成功一台机器被卖两次。解决这个问题的标准做法有两种我两种都上了。第一种是用条件更新代替先查后改把状态判断放进UPDATE语句UPDATE server_asset SET status 3, out_order_id #{orderId} WHERE id #{assetId} AND status 1这个操作如果影响行数为0说明这台机器已经不是待出库状态直接抛业务异常“库存状态已变化”前端就会提示用户重新选择。第二种兜底是在库存流水表上加唯一索引比如(order_id, asset_id, operation_type)即使业务代码有漏洞数据库也会拦住重复出库。库位管理也是很容易被忽略的细节。服务器有库房名称、机柜编号、机位编号我用location_code表示比如SH-A01-03代表上海库A机柜01第3位。盘点和出库定位全靠这个字段最好不要省。3.4 统计报表与慢查询优化先查库数据量大了再上重型武器内部系统的报表需求通常是月销售额、销售排行榜、回款逾期清单、库存周转率这些。初期直接查业务表聚合就行完全不必要引入单独的报表系统或者大数据组件。月度销售统计一个SQL就能出来SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, SUM(order_amount) AS amount, COUNT(*) AS order_cnt FROM sales_order WHERE create_time #{start} AND create_time #{end} GROUP BY day ORDER BY day;报表查询需要注意的点金额字段用DECIMAL(12,2)不要用float否则浮点误差会让你对账对到崩溃。WHERE条件里不要对列做函数运算比如WHERE DATE(create_time) CURDATE()会导致索引失效要写成create_time 2025-01-01 00:00:00 AND create_time 2025-01-02 00:00:00这种范围条件。如果业务数据真的大到连这种聚合都变慢了再考虑建每日汇总表用Spring定时任务凌晨跑一次汇总报表只查汇总表。至于整合Flink这类流计算框架内部系统现阶段完全用不到别给自己找麻烦。4. 前端联调与交互细节界面能做出来不等于接口能跑通4.1 用Vue3搭建后台管理界面先搭框架再填业务前端我选了Vue 3 Element Plus Vite开发效率和组件成熟度都很好。页面结构相对固定登录页、工作台首页、客户管理、产品与库存、报价单列表、订单列表、合同回款、统计报表、系统管理。工作台首页放四个核心指标卡片本月销售额、待审批报价数、待出库订单数、回款逾期金额。菜单权限在前端做了一层按角色隐藏但这层只是提升用户体验真正的控制必须依赖后端接口权限。比如销售角色看不到“成本价”列前端直接不渲染那列但接口返回数据时后端就已经过滤掉了成本字段这样才安全。路由守卫的逻辑很简单用户没登录跳转登录页登录后根据角色过滤菜单。实际开发中我最大的体会是页面复杂度不在列表展示而在表单校验。报价单明细行、订单状态流转、回款计划录入这些表单的字段联动非常多一定要先把接口返回的数据结构定好再写页面否则前后端对字段名能对到怀疑人生。4.2 跨域与Token传递把请求统一走一个入口问题少一半前后端分离开发时前端本地跑在8080端口后端跑在8081端口直接请求就是跨域。开发环境我用了Vite的跨域转发配置把/api的请求转发到后端地址前端代码里只写相对路径不写localhost。生产环境由Nginx统一入口转发同一个域名下不存在跨域问题动静分离也更方便缓存前端静态资源。Token传递必须统一规范。前端在请求拦截器里统一加上Authorization请求头后端用一个OncePerRequestFilter拦截所有请求解析Token并放入SecurityContext。响应体也统一封装成{ code, message, data }结构。这里要特别强调千万不要把用户密码、Token明文、成本价等信息塞进响应体里接口返回越精简越好。4.3 两个常见联调翻车现场日期格式和金额精度日期格式是最典型的联调翻车点。SpringBoot默认序列化LocalDateTime时返回的是带T的ISO格式比如2025-04-07T10:30:00前端直接展示会很难看。解决办法是在配置文件里统一指定格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8金额精度是另一个容易炸的坑。前端JavaScript的浮点数运算存在精度问题比如0.1 0.2并不等于0.3所以在报价明细、回款金额这类场景前端计算只能用decimal.js或big.js后端使用BigDecimal数据库字段用DECIMAL。任何一层用了浮点类型早晚会有一次对账对不上。5. 部署上线与运维排障能跑起来不算完稳定运行才是目标5.1 一台Linux服务器怎么部署整套系统生产环境一台Linux服务器就够了部署结构很简单MySQL、Redis、SpringBoot服务、前端静态文件。不要一开始就搞多机、集群、负载均衡那是给C端高并发留的方案企业内部系统一台物理机足够支撑。部署的步骤我给你列一下。第一步安装JDK、MySQL、Redis做好基础配置比如MySQL字符集要用utf8mb4时区设置为08:00。第二步后端代码用Maven打包成jar包放到/opt/server-sales目录下通过systemd托管启动而不是直接java -jar跑因为systemd能保证服务异常退出后自动拉起还能统一管理日志。systemd服务配置示例[Unit] Descriptionserver-sales-api Afternetwork.target [Service] Userdeploy WorkingDirectory/opt/server-sales ExecStart/usr/bin/java -Xms512m -Xmx1024m -jar /opt/server-sales/server-sales-api.jar --spring.profiles.activeprod Restartalways RestartSec5 [Install] WantedBymulti-user.target这里有个经验JVM内存不要无脑给大这类内部系统512m到1g已经非常宽裕了给太多反而会占用系统page cache影响MySQL和Redis的性能。第三步前端npm run build之后把dist目录放到Nginx的静态目录下由Nginx统一入口转发API请求。第四步初始化数据库执行建表SQL和初始数据脚本然后访问域名验证登录、报价、下单、出库、回款全流程。5.2 常见问题排查速查表系统上线后最常遇到的就是下面几类问题我整理成了一个排查速查表你按图索骥就行现象可能原因处理思路接口报无法连接数据库MySQL未启动、网络不通、密码错误检查3306端口、账号授权、连接配置页面能打开但接口500参数类型不匹配、SQL异常查看服务日志重点看异常堆栈登录后很快就退出服务器系统时间不准配置NTP时间同步让系统时钟保持准确前端请求拿不到数据静态资源路径或入口转发配置不对检查Nginx配置确认API路径正确转发库存扣减出现重复事务边界错误或缺少数据库约束把事务放到Service层检查唯一索引报表数据不对时区或查询条件不统一统一数据库时区明确开始结束时间边界排查问题时第一件事永远是看日志。所以日志一定要配置好控制台日志加文件日志文件按天滚动至少保留30天。应用出问题先看异常堆栈再看SQL日志绝大多数问题都能自己定位不用等开发上线看。5.3 上线前的检查清单这里分享一份我自己每次上线前都会过一遍的检查清单全部打勾才算完数据库备份是否正常备份脚本是否加入了定时任务生产环境配置是否外置数据库密码和Redis密码不能写在代码里MySQL字符集是否统一为utf8mb4时区是否设置为东八区Redis是否设置了访问密码生产环境不允许无密码访问防火墙只放行80和443端口应用端口不对公网开放操作日志和登录日志是否正常记录关键角色是否各分配了最小权限账号不要多人共用超级管理员出一台样机走全流程客户创建 - 报价 - 审批 - 下单 - 扣库存 - 出库 - 回款验证异常场景重复点提交按钮、库存不足时下单、未审批报价单转订单前端页面在手机上打开至少保证核心操作可以查看不要出现严重排版错乱这套检查看起来繁琐但能避免绝大多数上线后才发现的低级问题。尤其是重复提交和异常场景内部系统的用户没那么有耐心一但点出BUG他们对整个系统的信任度都会下降。在做这类内部销售信息管理平台的过程中我个人最大的体会是技术永远不是最难的部分把业务流程理清楚、把字段设计想明白、把权限边界划清楚这些才是真正决定项目成败的地方。别一上来就追求架构完美先把“谁在什么条件下可以对什么数据做什么操作”写明白系统自然就稳了。另一个忠告是库存和回款这两块一定要留好审计日志后面对账和扯皮全靠它。这套系统上线后我们少加了无数个无效班会销售、库管、财务第一次对同一份数据达成一致这件事比任何炫酷的技术方案都值钱。