企业官网建设流程全解析

拿到“java玻璃厂运营管理系统”这个毕设题目的第一反应，是觉得它无非就是一套进销存加报表。但真正沿着“玻璃制品企业信息化管理平台”的定位去拆需求，才发现玻璃制造行业全流程数字化管控把一小段生产链条拆开之后，涉及的业务面一点不比别的行业少。原料采购、配料、熔制、成型、退火、切割、磨边、钢化、质检、入库、发货，环环都要有记录、有流转、有追溯。这篇就把我从需求拆解、技术选型、数据库设计、核心功能实现到踩坑修复的完整过程讲清楚，给准备做类似Java毕设或者刚接触制造行业信息系统的朋友一份可以照着落地的参考。

1. 先拆需求：玻璃厂到底需要管什么

1.1 玻璃制造的业务链条比想象中长

普通进销存系统管的是“商品进库、出库、开单”，但玻璃厂不是这么简单。石英砂、纯碱、石灰石、白云石这些原料进厂后，先要经过配料、混合，再到熔窑里熔制成玻璃液，然后成型、退火，变成原片。原片还要根据订单规格进行切割、磨边、钢化、镀膜等深加工，最后才能检收入库。这个过程里有个很现实的问题：切割一定会有损耗，熔制过程会有废品，磨边会碎边，这些损耗如果不在系统里记录，库存账面数量和仓库实际数量就永远对不上。

所以“全流程数字化管控”不是概念包装，而是要把每道工序的动态变成数据。我在设计时就确定了主线：原料领用要关联到生产工单，工单要关联到订单，质检结果要写入批次记录，最终发货要扣减成品库存。每一条数据都能反向追溯到“这批货是哪天生产、用了哪批原料、是谁检的”。这个思路听着简单，但很多毕设项目只做到订单和库存两张表，一追问生产环节就说不清了。

1.2 角色权限与业务流程的映射

玻璃厂一个完整的管理闭环里，涉及的岗位至少包括：销售员、销售主管、采购员、生产计划员、车间工人、质检员、仓管员、财务。系统里的角色就得跟着这些岗位走，不能只做“管理员”和“普通用户”两种。我当时按RBAC权限模型设计了7个角色，菜单和按钮权限都挂到角色上。

权限设计的粒度要把握一个原则：谁经手的数据，谁才能改。比如质检员可以录入检验结果、判定等级，但不能修改订单单价；仓管员能做出入库操作，但不能取消订单；销售员能看到客户价格，但看不到原料采购成本。这些都是玻璃厂实际管理的敏感点。答辩时如果老师问“为什么这样设计权限”，你就可以拿“质检数据影响财务结算，所以质检和财务必须分权”这种业务逻辑去答，比说“权限模型是网上模板”有说服力得多。

1.3 技术栈选择与理由

技术选型我按多数毕设项目的落地习惯来定：后端用Spring Boot + MyBatis + MySQL，前端用Vue 3 + Element Plus，权限部分用JWT + 拦截器。如果前端基础不够扎实，直接用Spring Boot + Thymeleaf服务端渲染也能完整交工，只是页面交互会朴素一些。

为什么不用更老牌的SSM组合？Spring Boot本身内置了Tomcat、自动配置了数据源和事务管理器，可以把精力集中在业务逻辑和表结构设计上，而不是浪费在反复配XML上。MyBatis在多表联查、动态SQL这块比JPA更直观，特别是报表统计要按日期、规格、产线分组时，手写SQL能把控制权握在自己手里。数据库用MySQL 5.7或8.0都行，注意连接串里加上时区和字符编码配置，不然很容易在启动时报时区错误或者中文乱码。

2. 核心功能模块与数据库设计

2.1 九个核心功能模块与数据主线

系统功能不能东一块西一块，要让评审一看就觉得是完整的业务闭环。我梳理出的模块划分如下：

• 系统管理：用户、角色、菜单、操作日志
• 客户管理：客户档案、信用等级、联系记录
• 订单管理：销售下单、订单审核、发货管理
• 采购管理：供应商管理、采购计划、原料入库
• 生产管理：生产计划、工单下发、车间报工
• 库存管理：成品库、原料库、原片库、半成品库
• 质检管理：来料检验、过程检、成品检、等级判定
• 设备管理：设备台账、维保计划、故障记录
• 报表统计：销售统计、成本核算、质量合格率

这九个模块之间有一条清晰的数据主线：客户下订单，订单审核通过后生成生产工单，生产环节按工单领用原料，质检合格后成品入库，订单发起发货时扣减库存。采购模块负责在原料低于安全库存时补货，整个链条都是联动的。

2.2 玻璃行业特色字段：规格、等级、损耗

玻璃产品不能像普通商品那样只建一个“名称+编码”的物料档案。比如一片成品玻璃，需要记录的属性至少包括：长（mm）、宽（mm）、厚度（mm）、颜色（透明/茶色/灰色）、工艺类型（原片/钢化/Low-E/镀膜）、等级（优等品/一等品/合格品）、单位（片/平方米/吨）。

这里有个非常容易踩坑的点：单位切换。玻璃行业采购原片按“片”或“重箱”算，销售报价按“平方米”，成本核算又经常按“吨”。如果数据库里只存一个主单位和数量，报表统计时就得靠人工换算，很容易算错。我当时在订单明细表和库存表里同时存了数量、面积、重量几个关键冗余字段，面积用长乘宽自动算，重量按厚度系数估算，这样统计的时候不用反复联表计算，性能还更快。

损耗也要单独设计字段。切割损耗、破损数量、降级数量，这些都影响成本和库存。如果只是简单地把损耗摊到总数量里，时间一长库存台账就对不上了。

2.3 数据库表设计与关键表关系

表结构是整个系统的基础。我列一下核心表及其关键字段，供参考：

两张核心表的建表语句可以这样参考：

CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, product_id INT NOT NULL, quantity DECIMAL(10,2) NOT NULL COMMENT '片数', area DECIMAL(10,2) COMMENT '面积(平方米)', weight DECIMAL(10,2) COMMENT '重量(吨)', unit_price DECIMAL(10,2) NOT NULL, amount DECIMAL(10,2) NOT NULL, CONSTRAINT fk_order_item_order FOREIGN KEY (order_id) REFERENCES orders(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE inventory_record ( id INT PRIMARY KEY AUTO_INCREMENT, record_no VARCHAR(32) UNIQUE NOT NULL, product_id INT NOT NULL, warehouse_type TINYINT NOT NULL COMMENT '1成品库 2原料库 3原片库', change_type TINYINT NOT NULL COMMENT '1入库 2出库 3报损 4退货', change_qty DECIMAL(10,2) NOT NULL, damage_qty DECIMAL(10,2) DEFAULT 0 COMMENT '破损数量', source_no VARCHAR(32) COMMENT '来源单号如订单号/工单号', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建表的核心原则是：库存永远不要只存当前数量，必须配套流水表。玻璃行业的破损、损耗、退货都太常见了，没有流水记录，盘点差异出现时根本查不到原因。另外，大字段（比如订单明细）和主表拆开，是为了让订单主表保持简洁，也方便以后扩展一单一货、一单多货的灵活场景。

3. 实操过程：从登录到全流程下单

3.1 登录认证与权限拦截实现

登录认证我选择的是JWT加拦截器，没有引入完整的安全框架。对于毕设项目来说，这个方案足够轻量，答辩时也好讲清楚原理。

实现逻辑分三步。第一步，用户提交用户名和密码，后端用BCrypt校验密码（密码不存储明文，写完这个细节是加分项），校验通过后生成Token返回前端。第二步，前端把Token存在本地，每次请求在Header里带上Authorization: Bearer xxx。第三步，后端写一个拦截器，对所有非登录接口校验Token，同时根据用户的角色标识判断是否有接口访问权限。

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { response.setStatus(401); return false; } try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); String uri = request.getRequestURI(); // 简单判断当前角色是否允许访问该路径 if (!AuthUtil.hasPermission((String) request.getAttribute("role"), uri)) { response.setStatus(403); return false; } return true; } catch (Exception e) { response.setStatus(401); return false; } } }

注意一个细节：拦截器只做认证和粗粒度权限判断，真正的按钮级权限还得在前端配合。前端根据当前角色渲染不同的菜单和按钮，比如质检员角色只显示“质检管理”菜单，看不到“库存管理”入口。这样双重控制，既不笨重，又能应对答辩时的安全类提问。

3.2 核心业务流转：从下单到发货

完整业务流程我是按这个顺序实现的：

1. 销售员创建客户订单，选择玻璃规格，填写数量和单价，自动计算出面积和金额。
2. 销售主管审核订单，重点核对规格是否符合生产工艺，交期是否排得过来。
3. 系统根据订单明细生成生产工单，生产计划员安排车间和计划日期。
4. 车间按工单领用原片和辅料，报工录入实际完成数量和破损数量。
5. 质检员对完工产品进行检验，录入厚度、外观、尺寸偏差等结果，判定等级。
6. 仓管员办理成品入库，生成入库流水，库存实时增加。
7. 销售员在订单详情页发起发货申请，仓管员确认出库，扣减库存。
8. 财务在报表模块查看应收账款和销售毛利。

这里最难的是第3步，订单到工单的自动生成。因为一张订单可能包含多种不同厚度、不同工艺的玻璃，每种配置都要生成独立的工单。我在实现时按order_item一行生成一个工单，工单号规则是“WO + 日期 + 流水号”，这样每个加工批次都有唯一标识，后续质检、追溯都挂在这个工单号上。

3.3 库存预警与负库存处理

玻璃厂经常遇到的情况是：客户急着要货，但仓库里对应规格的原片不够，或者某批原料已经低于安全库存。库存预警必须做成主动提醒，不然系统就是个被动的记账工具。

我在库存表里加了一个min_stock字段，也就是安全库存线。首页数据看板定时查询所有库存记录，凡是quantity <= min_stock的物料，全部列进预警列表，同时采购模块会给出建议采购数量：建议采购量 = (安全库存 - 当前库存) + 预计待出库量。这个公式简单，但好用，比单纯看库存数量更贴近实际采购场景。

负库存处理是另一个必须解决的问题。库存扣减不能先查出数量再在Java代码里判断再UPDATE，因为并发访问时会出现“两边都查到库存够用，两边都扣减成功”的问题。最稳妥的做法是让数据库自己保证数量约束：

UPDATE inventory SET quantity = quantity - #{qty}, area = area - #{area} WHERE product_id = #{productId} AND warehouse_type = #{warehouseType} AND quantity >= #{qty};

这条SQL执行后，如果受影响行数为0，说明库存不足，业务层直接抛出异常，提示仓管员“库存不足，无法出库”。用条件更新的方式，既避免了超卖，又不用加锁，性能开销还小。我在做发货和领料出库时都用这个思路，实测下来并发场景没再出过错。

4. 常见问题与记录：实现过程中踩过的坑

4.1 报错与解决方案速查表

开发过程中一定会遇到一些问题，我把常见的高频情况整理成速查表，基本都能解决：

其中报表慢的问题最容易被忽视。玻璃企业的订单时间跨度大，规格又多，如果不给常用查询字段建立索引，数据量稍微上来一点，联表查询就会非常吃力。我建议在orders(order_date)、order_item(order_id)、inventory_record(product_id, create_time)上都加上普通索引，90%的慢查询都能解决。

4.2 毕设答辩时的高频追问

有几个问题几乎是每次答辩必问的，提前准备能省很多压力：

• 这个系统和普通进销存有什么区别？回答要点：普通进销存只管出入库和钱，玻璃厂系统重点解决生产工单流转、损耗记录、质量等级管理、库存单位换算，围绕玻璃制造工艺特点来设计。
• 为什么表要这样设计？回答要点：围绕业务数据流拆，订单、工单、库存、质检形成闭环；库存流水表保证可追溯，不能只留当前数量。
• 并发情况下怎么保证数据一致性？回答要点：事务加条件更新，库存扣减用数据库层面的数量约束，不依赖程序里先查后改。
• 如果要在真实工厂落地，还差什么？回答要点：需要对接产线数据采集设备，比如熔窑温度、退火窑温度、切割损耗数据自动采集进入系统，减少人工录入，同时扩展移动端扫码报工。

4.3 值得补的加分亮点

时间允许的情况下，下面这几个功能很能给项目加分：

• 首页数据看板：今日订单数、本月销售额、待发货订单、库存预警数、产品合格率。用统计接口加循环定时刷新，视觉上和业务深度都能上一个档次。
• 简单成本核算：根据工单领用的原料成本、加工工时、报废数量，自动估算单笔订单成本，再对比订单金额算出毛利。
• 成品追溯码：每个入库批次生成一个唯一追溯二维码，扫码可以看到生产日期、生产工单、质检员、原料批次。这个功能贴近行业真实需求，也容易在答辩时作为亮点展示。

我在做看板的时候有个真实感受：一开始只放订单和库存数据，页面空；后来把质检合格率、采购到货及时率加进来，整个系统才真正像一个“管控平台”，而不仅仅是“记录工具”。

做了这个系统之后，我最大的体会是，一个企业管理系统的难点从来不是增删改查怎么写，而是怎么把业务流程里默认的行业习惯落成一条条规则。玻璃厂的老师傅看一眼玻璃颜色就知道这批料匀不匀，但系统如果不记录熔炉温度和批次信息，就永远只能靠人传。如果后面还有时间，我最想继续加的就是数据采集层，把产线上的温度、液位、切割损耗数据接进来，让报表不止是操作台账，而是一个能反馈生产问题的工具。对于和我一样从零做这类系统的朋友，我的建议是：先把业务流程图完整画出来，再开始建表，最后再写代码。顺序一旦反了，改表结构、改接口、改前端，返工成本真的会高到让人崩溃。