简介这是一份面向高校计算机专业学生与Java Web开发初学者的固定资产管理系统毕业设计文档围绕浏览器/服务器模式下的资产信息化管理需求解决传统人工方式在查找、更新与维护上的低效问题。资源包内共1个doc文件约2.77MB内容涵盖摘要、绪论、系统设计与实现等完整章节可直接作为课程设计或论文写作的参考模板。文档以JSP、Struts、Hibernate和Spring技术架构为主线采用表现层、业务层与数据访问层三层设计详细阐述了资产管理模块与用户管理模块的实现思路并包含操作员与管理员分级权限控制方案。目前已有214人学习下载适合需要理解SSH框架整合、掌握B/S架构开发流程或准备同类课题的读者参考借鉴。1. 从一份“Java固定资产管理系统设计与实现.doc”说起这套东西到底解决什么问题很多公司的固定资产管理最初都是一张 Excel 表行政在表里登记电脑、打印机、办公桌椅谁领走了就在备注里写一行。等到年底盘点表里写着“在用小新 14 一台”实际人已经离职三个月机器在谁手上没人说得清。这个场景几乎每家中型公司都会遇到也正是“Java固定资产管理系统设计与实现”这个题目真正要解决的问题——把资产的采购、入库、领用、调拨、维修、报废、盘点串成一条可追溯的链路而不是靠一张随时会过期的表格。这套系统适合谁做一是计算机相关专业的毕业设计需要一套结构完整、能跑起来、能讲清楚设计思路的项目二是刚入行的 Java 开发想找一个业务闭环清晰、技术栈主流的练手项目三是中小企业里被 Excel 折磨过的行政或 IT想自己搭一套轻量系统。它不追求高并发追求的是业务字段齐全、状态流转正确、权限分得清。下面我按“先想清楚数据模型再动手写代码最后踩坑收尾”的顺序把整套方案讲透。2. 需求拆解与数据建模固定资产管理系统的骨架怎么搭2.1 先分清“资产”和“资产流转记录”两张核心表固定资产管理系统最容易翻车的地方不是代码写不出来而是表设计一开始就错了。很多人把“谁在用”“在哪个部门”“什么状态”全塞进一张资产表结果一次调拨就要改好几行历史数据盘点时根本查不到“这台电脑上个月在谁手上”。正确的做法是拆成两层资产主表记录这台设备本身的固有属性编号、名称、分类、采购日期、金额、序列号流转记录表记录它每一次状态变化入库、领用、调拨、维修、报废。资产主表里只保留“当前状态”和“当前持有人”两个冗余字段用于快速查询真正的历史全部落在流转表里。常见做法是资产主表叫asset流转表叫asset_record两者通过asset_id关联。这样设计的好处是任何一次操作都是往流转表插一条记录同时更新主表的当前状态既保证可追溯又保证查询快。2.2 用一张表把状态机定死避免“状态乱跳”资产状态如果不定死代码里就会出现“已报废的资产还能被领用”这种玄学 bug。我一般会在设计阶段就把状态枚举写清楚并在数据库和代码两层做约束。状态值含义允许的下一步操作0待入库入库1在库领用、调拨、报废2已领用归还、调拨、维修、报废3维修中归还入库、报废4已报废无这张表看起来简单但它是后面所有业务校验的依据。比如“领用”操作只能对状态为 1 的资产执行“报废”只能对状态为 1 或 2 或 3 的资产执行。把这些规则写成常量或枚举在 Service 层统一判断比散落在各个 Controller 里可靠得多。2.3 建表 SQL 与字段说明下面是我常用的建表语句字段命名尽量直白方便后面 MyBatis 映射。注意金额用decimal不要用float否则盘点总价会出现几分钱的误差对账时很头疼。-- 资产主表 CREATE TABLE asset ( id BIGINT PRIMARY KEY AUTO_INCREMENT, asset_no VARCHAR(32) NOT NULL UNIQUE COMMENT 资产编号如 GD-2024-0001, asset_name VARCHAR(64) NOT NULL COMMENT 资产名称, category_id BIGINT NOT NULL COMMENT 分类ID, purchase_date DATE COMMENT 采购日期, price DECIMAL(12,2) COMMENT 采购金额, serial_no VARCHAR(64) COMMENT 设备序列号, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待入库 1在库 2已领用 3维修中 4已报废, holder_id BIGINT COMMENT 当前持有人ID, dept_id BIGINT COMMENT 当前所属部门ID, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 资产流转记录表 CREATE TABLE asset_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, asset_id BIGINT NOT NULL COMMENT 关联资产ID, action TINYINT NOT NULL COMMENT 1入库 2领用 3归还 4调拨 5维修 6报废, from_user BIGINT COMMENT 操作前持有人, to_user BIGINT COMMENT 操作后持有人, from_dept BIGINT COMMENT 操作前部门, to_dept BIGINT COMMENT 操作后部门, remark VARCHAR(255) COMMENT 备注, operator BIGINT NOT NULL COMMENT 操作人, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );asset_no加了唯一索引防止重复录入status用TINYINT而不是字符串查询和索引效率更好asset_record里同时记录操作前后的人和部门这样调拨历史一目了然。建完这两张表整个系统的骨架就立住了剩下的分类表、用户表、部门表都是常规设计不再展开。3. 技术选型与项目分层Spring Boot MyBatis 怎么落地3.1 为什么这套系统用 Spring Boot 而不是传统 SSM传统 SSM 要配一堆 XML光applicationContext.xml和spring-mvc.xml就能劝退一半新手。Spring Boot 把依赖和配置都收敛到pom.xml和application.yml启动类一跑就能起服务对毕业设计和练手项目来说省下来的时间可以花在业务逻辑上。我一般选 Spring Boot 2.7.x 配 MyBatis不选 JPA。原因是固定资产管理里有大量“按条件动态查询”的场景比如“查某个部门下所有在库的、金额大于 5000 的、采购日期在今年的资产”这种动态 SQL 用 MyBatis 的if标签写起来很顺手JPA 的 Criteria 反而绕。前端可以用 Thymeleaf 做服务端渲染也可以用 Vue 前后端分离看个人时间。如果时间紧Thymeleaf 更快出活。3.2 项目分层Controller / Service / Mapper 各管什么分层不是形式主义是为了让状态校验有唯一入口。我的习惯是Controller只做参数接收和返回封装不写业务判断Service负责状态机校验、事务控制、流转记录写入Mapper只做单表 CRUD 和简单联表查询。这样当“已报废资产不能被领用”这条规则要改时只需要动 Service 一层不会漏掉某个 Controller。下面是一个领用操作的 Service 核心代码。Service public class AssetService { Autowired private AssetMapper assetMapper; Autowired private AssetRecordMapper recordMapper; /** * 资产领用 * param assetId 资产ID * param toUserId 领用人ID * param operator 操作人ID */ Transactional(rollbackFor Exception.class) public void lend(Long assetId, Long toUserId, Long operator) { Asset asset assetMapper.selectById(assetId); if (asset null) { throw new BizException(资产不存在); } // 只有“在库”状态才能领用 if (asset.getStatus() ! 1) { throw new BizException(当前状态不允许领用); } // 更新主表状态和持有人 asset.setStatus(2); asset.setHolderId(toUserId); assetMapper.updateById(asset); // 写入流转记录 AssetRecord record new AssetRecord(); record.setAssetId(assetId); record.setAction(2); record.setToUser(toUserId); record.setOperator(operator); recordMapper.insert(record); } }这段代码的关键点有三个第一Transactional保证更新主表和写记录要么都成功要么都回滚第二状态判断放在更新之前避免脏数据第三流转记录的from_user可以从asset.getHolderId()取更新前的值这里为了简洁省略了。参数方面assetId和toUserId由前端传入operator从登录会话里取不要相信前端传的操作人。3.3 动态查询与分页MyBatis 条件构造的写法资产列表页通常要支持按名称、分类、状态、部门组合筛选。用 MyBatis 的 XML 写动态 SQL 最直观。select idselectByCondition resultTypecom.example.entity.Asset SELECT * FROM asset where if testassetName ! null and assetName ! AND asset_name LIKE CONCAT(%, #{assetName}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if if teststatus ! null AND status #{status} /if if testdeptId ! null AND dept_id #{deptId} /if /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /selectwhere标签会自动处理第一个AND不用手写11。分页参数offset和pageSize由 PageHelper 插件或手动计算传入。注意LIKE用CONCAT拼接不要用${}否则会有 SQL 注入风险。这套写法在资产列表、流转记录查询里都能复用。4. 核心功能实现入库、领用、调拨、盘点的代码路径4.1 资产入库编号生成与批量导入入库是资产第一次进入系统核心是生成唯一编号。我一般用“前缀 年份 四位流水号”的规则比如GD-2024-0001。流水号可以用数据库自增 ID 补零也可以用 Redis 计数器小系统直接用SELECT MAX加一也行但要注意并发下加锁。public String generateAssetNo() { String prefix GD- Year.now().getValue() -; // 查询当年最大编号 String maxNo assetMapper.selectMaxNoByPrefix(prefix); int seq 1; if (maxNo ! null) { seq Integer.parseInt(maxNo.substring(prefix.length())) 1; } return prefix String.format(%04d, seq); }批量导入用 EasyExcel 读 Excel每行校验必填字段和编号重复校验通过后批量插入。注意批量插入不要循环单条 insert用foreach拼批量 SQL一千条以内性能差别不大但习惯要养好。4.2 调拨一次操作改两个部门的数据调拨和领用的区别在于调拨是资产从一个部门转到另一个部门持有人可能不变。实现时要同时更新dept_id和写流转记录记录里from_dept和to_dept都要填。Transactional(rollbackFor Exception.class) public void transfer(Long assetId, Long toDeptId, Long operator) { Asset asset assetMapper.selectById(assetId); if (asset.getStatus() ! 1 asset.getStatus() ! 2) { throw new BizException(当前状态不允许调拨); } Long fromDept asset.getDeptId(); asset.setDeptId(toDeptId); assetMapper.updateById(asset); AssetRecord record new AssetRecord(); record.setAssetId(assetId); record.setAction(4); record.setFromDept(fromDept); record.setToDept(toDeptId); record.setOperator(operator); recordMapper.insert(record); }这里有个容易忽略的点调拨后如果资产是“已领用”状态持有人还在原部门逻辑上要决定是“人随资产走”还是“资产走人留下”。我一般让调拨只改部门持有人不变如果需要换人再单独做一次领用或归还。这个规则要在需求阶段和业务方确认否则后期扯皮。4.3 盘点生成盘点单与差异处理盘点是固定资产管理里最复杂的环节。常见做法是管理员发起一次盘点系统按部门或分类生成盘点单每条资产记录应有状态和实际状态盘点人逐条确认最后汇总差异。盘点单表可以设计成inventory_task盘点任务和inventory_item盘点明细。生成任务时把符合条件的资产快照进明细表盘点时只更新明细表的实际状态和差异说明不影响资产主表。盘点结束后管理员审核差异确认盘亏的走报废流程盘盈的新建资产。这样设计的好处是盘点过程不干扰日常业务盘点结果可追溯。-- 盘点任务表 CREATE TABLE inventory_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_name VARCHAR(64) NOT NULL, dept_id BIGINT COMMENT 盘点部门空表示全盘, status TINYINT DEFAULT 0 COMMENT 0进行中 1已完成, create_by BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 盘点明细表 CREATE TABLE inventory_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id BIGINT NOT NULL, asset_id BIGINT NOT NULL, expect_status TINYINT COMMENT 账面状态, real_status TINYINT COMMENT 实际状态, diff_remark VARCHAR(255) COMMENT 差异说明 );盘点功能不需要写太复杂的代码核心是快照和差异对比。真正花时间的是和业务方对齐“盘亏怎么处理、盘盈怎么入账”这些规则定清楚了代码就是体力活。5. 避坑与排查固定资产管理系统落地时最容易翻车的 5 个点5.1 现象领用后资产状态没变但流转记录多了一条原因Service 方法没有加Transactional或者异常被 catch 后没有重新抛出导致更新主表失败但记录插入成功。解决在类或方法上加Transactional(rollbackFor Exception.class)并且不要在 Service 里吞异常。如果用了 try-catch要么在 catch 里throw new BizException要么手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。5.2 现象资产编号重复插入时报唯一索引冲突原因并发入库时两个请求同时查到相同的最大编号各自加一后生成相同编号。解决给编号生成加锁可以用synchronized关键字单机够用也可以用数据库的SELECT ... FOR UPDATE或者干脆用 Redis 的INCR。小系统最省事的做法是在asset_no唯一索引冲突时捕获异常并重试一次。5.3 现象盘点时明明资产在库盘点单里却显示已领用原因生成盘点明细时直接读了资产主表的当前状态但盘点期间资产可能被领用或归还导致快照和实际不一致。解决盘点明细生成后实际状态由盘点人填写账面状态保留生成时的快照。对比差异时以快照为准不要实时读主表。如果盘点周期长可以在盘点期间锁定资产操作但一般不建议会影响日常业务。5.4 现象删除分类后资产列表查不到数据原因分类表用了物理删除资产表里的category_id成了孤儿数据联表查询时INNER JOIN直接过滤掉了。解决分类、部门这类基础数据一律用逻辑删除加is_deleted字段查询时带上is_deleted 0。资产表关联查询用LEFT JOIN即使分类被删也能查出资产只是分类名为空。5.5 现象前端传了status2想直接改资产状态后端没拦住原因Controller 直接接收了前端传来的 status 字段并更新绕过了 Service 的状态机校验。解决所有状态变更必须走 Service 的专用方法lend、returnAsset、transfer、scrapController 不暴露通用的 updateStatus 接口。前端传参只传业务参数资产 ID、目标用户、目标部门状态由后端根据业务动作推导。这是权限和状态安全的基本功别偷懒。6. 进阶技巧用行级权限和操作日志把系统做“厚”6.1 行级权限让普通用户只能看到自己的资产基础版系统里所有人能看到所有资产。但实际使用中普通员工只应该看到自己领用的资产部门主管能看到本部门的管理员看全部。这就是行级权限实现方式是在查询条件里动态拼holder_id或dept_id。// 在 Service 层根据当前登录用户角色拼接数据范围 public ListAsset listAssets(AssetQuery query, LoginUser user) { if (user.getRole() Role.EMPLOYEE) { query.setHolderId(user.getUserId()); } else if (user.getRole() Role.DEPT_MANAGER) { query.setDeptId(user.getDeptId()); } // 管理员不加限制 return assetMapper.selectByCondition(query); }这段代码的关键是LoginUser从会话或 Token 里取不能从前端参数取。行级权限是很多毕业设计忽略的点加上之后系统的完整度会明显提升面试时也能讲出东西。6.2 操作日志用 AOP 记录谁在什么时候改了什么固定资产系统涉及资产归属变更操作日志是后悔药。我一般用 Spring AOP 加自定义注解在 Service 方法执行前后记录日志。Aspect Component public class LogAspect { Autowired private OperLogMapper logMapper; Around(annotation(operLog)) public Object around(ProceedingJoinPoint pjp, OperLog operLog) throws Throwable { long start System.currentTimeMillis(); Object result pjp.proceed(); // 方法执行成功后记录日志 OperLogEntity entity new OperLogEntity(); entity.setModule(operLog.module()); entity.setAction(operLog.action()); entity.setMethod(pjp.getSignature().toShortString()); entity.setCost(System.currentTimeMillis() - start); logMapper.insert(entity); return result; } }OperLog注解加在 Service 方法上比如OperLog(module 资产, action 领用)。日志表记录模块、动作、方法名、耗时、操作人从 ThreadLocal 取。这样出问题时能快速定位是哪次操作导致的比翻数据库 binlog 快得多。6.3 验证方法怎么确认状态机没写漏写完状态机后我习惯用一张“状态 × 操作”的矩阵表逐个验证。行是当前状态列是操作格子里填“允许”或“拒绝”然后写单元测试覆盖所有“允许”和几个典型“拒绝”场景。当前状态领用归还调拨维修报废在库允许拒绝允许允许允许已领用拒绝允许允许允许允许维修中拒绝允许拒绝拒绝允许已报废拒绝拒绝拒绝拒绝拒绝这张表填完Service 里的 if 判断就有了依据。单元测试用 JUnit 加 MockitoMock 掉 Mapper只测 Service 的状态校验逻辑跑起来很快。我见过太多项目状态机写漏上线后出现“报废资产被领用”的血泪教训花半小时写测试能省后面几天排查时间。最后说个我自己的习惯每次改状态机相关代码先把这张矩阵表翻出来对一遍确认没有新增状态或操作漏掉。固定资产管理系统不难难的是细节不出错。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 10:59:03 · 阅读 1.2k Java固定资产管理系统设计与实现：从数据建模到状态机落地
简介这是一份面向高校计算机专业学生与Java Web开发初学者的固定资产管理系统毕业设计文档围绕浏览器/服务器模式下的资产信息化管理需求解决传统人工方式在查找、更新与维护上的低效问题。资源包内共1个doc文件约2.77MB内容涵盖摘要、绪论、系统设计与实现等完整章节可直接作为课程设计或论文写作的参考模板。文档以JSP、Struts、Hibernate和Spring技术架构为主线采用表现层、业务层与数据访问层三层设计详细阐述了资产管理模块与用户管理模块的实现思路并包含操作员与管理员分级权限控制方案。目前已有214人学习下载适合需要理解SSH框架整合、掌握B/S架构开发流程或准备同类课题的读者参考借鉴。1. 从一份“Java固定资产管理系统设计与实现.doc”说起这套东西到底解决什么问题很多公司的固定资产管理最初都是一张 Excel 表行政在表里登记电脑、打印机、办公桌椅谁领走了就在备注里写一行。等到年底盘点表里写着“在用小新 14 一台”实际人已经离职三个月机器在谁手上没人说得清。这个场景几乎每家中型公司都会遇到也正是“Java固定资产管理系统设计与实现”这个题目真正要解决的问题——把资产的采购、入库、领用、调拨、维修、报废、盘点串成一条可追溯的链路而不是靠一张随时会过期的表格。这套系统适合谁做一是计算机相关专业的毕业设计需要一套结构完整、能跑起来、能讲清楚设计思路的项目二是刚入行的 Java 开发想找一个业务闭环清晰、技术栈主流的练手项目三是中小企业里被 Excel 折磨过的行政或 IT想自己搭一套轻量系统。它不追求高并发追求的是业务字段齐全、状态流转正确、权限分得清。下面我按“先想清楚数据模型再动手写代码最后踩坑收尾”的顺序把整套方案讲透。2. 需求拆解与数据建模固定资产管理系统的骨架怎么搭2.1 先分清“资产”和“资产流转记录”两张核心表固定资产管理系统最容易翻车的地方不是代码写不出来而是表设计一开始就错了。很多人把“谁在用”“在哪个部门”“什么状态”全塞进一张资产表结果一次调拨就要改好几行历史数据盘点时根本查不到“这台电脑上个月在谁手上”。正确的做法是拆成两层资产主表记录这台设备本身的固有属性编号、名称、分类、采购日期、金额、序列号流转记录表记录它每一次状态变化入库、领用、调拨、维修、报废。资产主表里只保留“当前状态”和“当前持有人”两个冗余字段用于快速查询真正的历史全部落在流转表里。常见做法是资产主表叫asset流转表叫asset_record两者通过asset_id关联。这样设计的好处是任何一次操作都是往流转表插一条记录同时更新主表的当前状态既保证可追溯又保证查询快。2.2 用一张表把状态机定死避免“状态乱跳”资产状态如果不定死代码里就会出现“已报废的资产还能被领用”这种玄学 bug。我一般会在设计阶段就把状态枚举写清楚并在数据库和代码两层做约束。状态值含义允许的下一步操作0待入库入库1在库领用、调拨、报废2已领用归还、调拨、维修、报废3维修中归还入库、报废4已报废无这张表看起来简单但它是后面所有业务校验的依据。比如“领用”操作只能对状态为 1 的资产执行“报废”只能对状态为 1 或 2 或 3 的资产执行。把这些规则写成常量或枚举在 Service 层统一判断比散落在各个 Controller 里可靠得多。2.3 建表 SQL 与字段说明下面是我常用的建表语句字段命名尽量直白方便后面 MyBatis 映射。注意金额用decimal不要用float否则盘点总价会出现几分钱的误差对账时很头疼。-- 资产主表 CREATE TABLE asset ( id BIGINT PRIMARY KEY AUTO_INCREMENT, asset_no VARCHAR(32) NOT NULL UNIQUE COMMENT 资产编号如 GD-2024-0001, asset_name VARCHAR(64) NOT NULL COMMENT 资产名称, category_id BIGINT NOT NULL COMMENT 分类ID, purchase_date DATE COMMENT 采购日期, price DECIMAL(12,2) COMMENT 采购金额, serial_no VARCHAR(64) COMMENT 设备序列号, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待入库 1在库 2已领用 3维修中 4已报废, holder_id BIGINT COMMENT 当前持有人ID, dept_id BIGINT COMMENT 当前所属部门ID, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 资产流转记录表 CREATE TABLE asset_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, asset_id BIGINT NOT NULL COMMENT 关联资产ID, action TINYINT NOT NULL COMMENT 1入库 2领用 3归还 4调拨 5维修 6报废, from_user BIGINT COMMENT 操作前持有人, to_user BIGINT COMMENT 操作后持有人, from_dept BIGINT COMMENT 操作前部门, to_dept BIGINT COMMENT 操作后部门, remark VARCHAR(255) COMMENT 备注, operator BIGINT NOT NULL COMMENT 操作人, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );asset_no加了唯一索引防止重复录入status用TINYINT而不是字符串查询和索引效率更好asset_record里同时记录操作前后的人和部门这样调拨历史一目了然。建完这两张表整个系统的骨架就立住了剩下的分类表、用户表、部门表都是常规设计不再展开。3. 技术选型与项目分层Spring Boot MyBatis 怎么落地3.1 为什么这套系统用 Spring Boot 而不是传统 SSM传统 SSM 要配一堆 XML光applicationContext.xml和spring-mvc.xml就能劝退一半新手。Spring Boot 把依赖和配置都收敛到pom.xml和application.yml启动类一跑就能起服务对毕业设计和练手项目来说省下来的时间可以花在业务逻辑上。我一般选 Spring Boot 2.7.x 配 MyBatis不选 JPA。原因是固定资产管理里有大量“按条件动态查询”的场景比如“查某个部门下所有在库的、金额大于 5000 的、采购日期在今年的资产”这种动态 SQL 用 MyBatis 的if标签写起来很顺手JPA 的 Criteria 反而绕。前端可以用 Thymeleaf 做服务端渲染也可以用 Vue 前后端分离看个人时间。如果时间紧Thymeleaf 更快出活。3.2 项目分层Controller / Service / Mapper 各管什么分层不是形式主义是为了让状态校验有唯一入口。我的习惯是Controller只做参数接收和返回封装不写业务判断Service负责状态机校验、事务控制、流转记录写入Mapper只做单表 CRUD 和简单联表查询。这样当“已报废资产不能被领用”这条规则要改时只需要动 Service 一层不会漏掉某个 Controller。下面是一个领用操作的 Service 核心代码。Service public class AssetService { Autowired private AssetMapper assetMapper; Autowired private AssetRecordMapper recordMapper; /** * 资产领用 * param assetId 资产ID * param toUserId 领用人ID * param operator 操作人ID */ Transactional(rollbackFor Exception.class) public void lend(Long assetId, Long toUserId, Long operator) { Asset asset assetMapper.selectById(assetId); if (asset null) { throw new BizException(资产不存在); } // 只有“在库”状态才能领用 if (asset.getStatus() ! 1) { throw new BizException(当前状态不允许领用); } // 更新主表状态和持有人 asset.setStatus(2); asset.setHolderId(toUserId); assetMapper.updateById(asset); // 写入流转记录 AssetRecord record new AssetRecord(); record.setAssetId(assetId); record.setAction(2); record.setToUser(toUserId); record.setOperator(operator); recordMapper.insert(record); } }这段代码的关键点有三个第一Transactional保证更新主表和写记录要么都成功要么都回滚第二状态判断放在更新之前避免脏数据第三流转记录的from_user可以从asset.getHolderId()取更新前的值这里为了简洁省略了。参数方面assetId和toUserId由前端传入operator从登录会话里取不要相信前端传的操作人。3.3 动态查询与分页MyBatis 条件构造的写法资产列表页通常要支持按名称、分类、状态、部门组合筛选。用 MyBatis 的 XML 写动态 SQL 最直观。select idselectByCondition resultTypecom.example.entity.Asset SELECT * FROM asset where if testassetName ! null and assetName ! AND asset_name LIKE CONCAT(%, #{assetName}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if if teststatus ! null AND status #{status} /if if testdeptId ! null AND dept_id #{deptId} /if /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /selectwhere标签会自动处理第一个AND不用手写11。分页参数offset和pageSize由 PageHelper 插件或手动计算传入。注意LIKE用CONCAT拼接不要用${}否则会有 SQL 注入风险。这套写法在资产列表、流转记录查询里都能复用。4. 核心功能实现入库、领用、调拨、盘点的代码路径4.1 资产入库编号生成与批量导入入库是资产第一次进入系统核心是生成唯一编号。我一般用“前缀 年份 四位流水号”的规则比如GD-2024-0001。流水号可以用数据库自增 ID 补零也可以用 Redis 计数器小系统直接用SELECT MAX加一也行但要注意并发下加锁。public String generateAssetNo() { String prefix GD- Year.now().getValue() -; // 查询当年最大编号 String maxNo assetMapper.selectMaxNoByPrefix(prefix); int seq 1; if (maxNo ! null) { seq Integer.parseInt(maxNo.substring(prefix.length())) 1; } return prefix String.format(%04d, seq); }批量导入用 EasyExcel 读 Excel每行校验必填字段和编号重复校验通过后批量插入。注意批量插入不要循环单条 insert用foreach拼批量 SQL一千条以内性能差别不大但习惯要养好。4.2 调拨一次操作改两个部门的数据调拨和领用的区别在于调拨是资产从一个部门转到另一个部门持有人可能不变。实现时要同时更新dept_id和写流转记录记录里from_dept和to_dept都要填。Transactional(rollbackFor Exception.class) public void transfer(Long assetId, Long toDeptId, Long operator) { Asset asset assetMapper.selectById(assetId); if (asset.getStatus() ! 1 asset.getStatus() ! 2) { throw new BizException(当前状态不允许调拨); } Long fromDept asset.getDeptId(); asset.setDeptId(toDeptId); assetMapper.updateById(asset); AssetRecord record new AssetRecord(); record.setAssetId(assetId); record.setAction(4); record.setFromDept(fromDept); record.setToDept(toDeptId); record.setOperator(operator); recordMapper.insert(record); }这里有个容易忽略的点调拨后如果资产是“已领用”状态持有人还在原部门逻辑上要决定是“人随资产走”还是“资产走人留下”。我一般让调拨只改部门持有人不变如果需要换人再单独做一次领用或归还。这个规则要在需求阶段和业务方确认否则后期扯皮。4.3 盘点生成盘点单与差异处理盘点是固定资产管理里最复杂的环节。常见做法是管理员发起一次盘点系统按部门或分类生成盘点单每条资产记录应有状态和实际状态盘点人逐条确认最后汇总差异。盘点单表可以设计成inventory_task盘点任务和inventory_item盘点明细。生成任务时把符合条件的资产快照进明细表盘点时只更新明细表的实际状态和差异说明不影响资产主表。盘点结束后管理员审核差异确认盘亏的走报废流程盘盈的新建资产。这样设计的好处是盘点过程不干扰日常业务盘点结果可追溯。-- 盘点任务表 CREATE TABLE inventory_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_name VARCHAR(64) NOT NULL, dept_id BIGINT COMMENT 盘点部门空表示全盘, status TINYINT DEFAULT 0 COMMENT 0进行中 1已完成, create_by BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 盘点明细表 CREATE TABLE inventory_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id BIGINT NOT NULL, asset_id BIGINT NOT NULL, expect_status TINYINT COMMENT 账面状态, real_status TINYINT COMMENT 实际状态, diff_remark VARCHAR(255) COMMENT 差异说明 );盘点功能不需要写太复杂的代码核心是快照和差异对比。真正花时间的是和业务方对齐“盘亏怎么处理、盘盈怎么入账”这些规则定清楚了代码就是体力活。5. 避坑与排查固定资产管理系统落地时最容易翻车的 5 个点5.1 现象领用后资产状态没变但流转记录多了一条原因Service 方法没有加Transactional或者异常被 catch 后没有重新抛出导致更新主表失败但记录插入成功。解决在类或方法上加Transactional(rollbackFor Exception.class)并且不要在 Service 里吞异常。如果用了 try-catch要么在 catch 里throw new BizException要么手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。5.2 现象资产编号重复插入时报唯一索引冲突原因并发入库时两个请求同时查到相同的最大编号各自加一后生成相同编号。解决给编号生成加锁可以用synchronized关键字单机够用也可以用数据库的SELECT ... FOR UPDATE或者干脆用 Redis 的INCR。小系统最省事的做法是在asset_no唯一索引冲突时捕获异常并重试一次。5.3 现象盘点时明明资产在库盘点单里却显示已领用原因生成盘点明细时直接读了资产主表的当前状态但盘点期间资产可能被领用或归还导致快照和实际不一致。解决盘点明细生成后实际状态由盘点人填写账面状态保留生成时的快照。对比差异时以快照为准不要实时读主表。如果盘点周期长可以在盘点期间锁定资产操作但一般不建议会影响日常业务。5.4 现象删除分类后资产列表查不到数据原因分类表用了物理删除资产表里的category_id成了孤儿数据联表查询时INNER JOIN直接过滤掉了。解决分类、部门这类基础数据一律用逻辑删除加is_deleted字段查询时带上is_deleted 0。资产表关联查询用LEFT JOIN即使分类被删也能查出资产只是分类名为空。5.5 现象前端传了status2想直接改资产状态后端没拦住原因Controller 直接接收了前端传来的 status 字段并更新绕过了 Service 的状态机校验。解决所有状态变更必须走 Service 的专用方法lend、returnAsset、transfer、scrapController 不暴露通用的 updateStatus 接口。前端传参只传业务参数资产 ID、目标用户、目标部门状态由后端根据业务动作推导。这是权限和状态安全的基本功别偷懒。6. 进阶技巧用行级权限和操作日志把系统做“厚”6.1 行级权限让普通用户只能看到自己的资产基础版系统里所有人能看到所有资产。但实际使用中普通员工只应该看到自己领用的资产部门主管能看到本部门的管理员看全部。这就是行级权限实现方式是在查询条件里动态拼holder_id或dept_id。// 在 Service 层根据当前登录用户角色拼接数据范围 public ListAsset listAssets(AssetQuery query, LoginUser user) { if (user.getRole() Role.EMPLOYEE) { query.setHolderId(user.getUserId()); } else if (user.getRole() Role.DEPT_MANAGER) { query.setDeptId(user.getDeptId()); } // 管理员不加限制 return assetMapper.selectByCondition(query); }这段代码的关键是LoginUser从会话或 Token 里取不能从前端参数取。行级权限是很多毕业设计忽略的点加上之后系统的完整度会明显提升面试时也能讲出东西。6.2 操作日志用 AOP 记录谁在什么时候改了什么固定资产系统涉及资产归属变更操作日志是后悔药。我一般用 Spring AOP 加自定义注解在 Service 方法执行前后记录日志。Aspect Component public class LogAspect { Autowired private OperLogMapper logMapper; Around(annotation(operLog)) public Object around(ProceedingJoinPoint pjp, OperLog operLog) throws Throwable { long start System.currentTimeMillis(); Object result pjp.proceed(); // 方法执行成功后记录日志 OperLogEntity entity new OperLogEntity(); entity.setModule(operLog.module()); entity.setAction(operLog.action()); entity.setMethod(pjp.getSignature().toShortString()); entity.setCost(System.currentTimeMillis() - start); logMapper.insert(entity); return result; } }OperLog注解加在 Service 方法上比如OperLog(module 资产, action 领用)。日志表记录模块、动作、方法名、耗时、操作人从 ThreadLocal 取。这样出问题时能快速定位是哪次操作导致的比翻数据库 binlog 快得多。6.3 验证方法怎么确认状态机没写漏写完状态机后我习惯用一张“状态 × 操作”的矩阵表逐个验证。行是当前状态列是操作格子里填“允许”或“拒绝”然后写单元测试覆盖所有“允许”和几个典型“拒绝”场景。当前状态领用归还调拨维修报废在库允许拒绝允许允许允许已领用拒绝允许允许允许允许维修中拒绝允许拒绝拒绝允许已报废拒绝拒绝拒绝拒绝拒绝这张表填完Service 里的 if 判断就有了依据。单元测试用 JUnit 加 MockitoMock 掉 Mapper只测 Service 的状态校验逻辑跑起来很快。我见过太多项目状态机写漏上线后出现“报废资产被领用”的血泪教训花半小时写测试能省后面几天排查时间。最后说个我自己的习惯每次改状态机相关代码先把这张矩阵表翻出来对一遍确认没有新增状态或操作漏掉。固定资产管理系统不难难的是细节不出错。希望帮到你。本文还有配套的精品资源点击获取