我是从一张乱七八糟的Excel台账开始说起这件事的。当时某公司要把散落在业务系统里的数据资源统一管起来负责人拿出的所谓数据资产清单是一份几十MB的表格里面同一个指标有四种叫法有的填了来源系统有的只写了个名称更新日期还停在半年前。我一看就明白这不是靠Excel能解决的事。于是动手做了一套基于Spring Boot Vue的企业数据资产登记系统把每一项数据资源从没人说得清变成编码唯一、责任到人、状态可追、检索可达的资产台账。这套系统的代码结构清晰附带部署文档和演示数据挺适合两类人参考一类是学完Spring Boot和Vue想找个完整全栈项目练手的开发者另一类是要在公司内部搭建数据治理基础平台的技术负责人。1. 为什么企业需要数据资产登记系统而不是一张Excel表1.1 先聊聊我看到的真实痛点很多企业内部并不缺数据缺的是对数据的目录感。生产库、报表平台、数据仓库、文件服务器各自为政业务部门知道自己在用某张报表但问不出三个问题这个数从哪来谁负责维护更新频率是多少一旦遇到口径分歧两个部门拿出的统计结果对不上最后只能靠人肉翻代码、翻表结构效率极低。我接手这个项目时梳理过一遍现状几十套业务系统数据量大、类型杂但真正被当成资产管理的少之又少。所谓资产管理基本停留在DBA维护的库表清单层面业务人员根本看不懂也查不到。登记系统要解决的就是这个断层让技术人员能把库表、接口、指标、文件等资源按统一规范录入让业务人员能按业务语义检索、查看数据归属和权限让管理者能看到资产总量、分类分布和活跃度。1.2 登记系统到底登记了什么市面上的数据资产管理平台往往很重从元数据采集、数据血缘到质量评估一整套都上。但很多企业现阶段只需要先解决有没有台账、能不能查、谁来负责这三个问题。我做的这套系统核心登记对象有四类数据表/视图物理库表、字段明细、主键、索引、存储位置。数据接口接口路径、入参出参、调用方、限流状态。数据指标指标名称、口径说明、计算公式、来源表。数据文件文件名、格式、存储路径、更新方式。每类资产都挂在一个统一的分类目录下拥有唯一的资产编码记录责任人、所属部门、安全级别、发布状态。这样一套登记下来企业至少能回答我有什么数据、在哪、归谁管。1.3 系统做到什么程度算能用我的判断标准很简单普通员工能自己检索到想要的资产资产负责人能维护自己名下资产管理员能通过审批流程控制发布质量。如果这三个角色都能在一个页面上完成操作不依赖开发人员介入那这套系统就真正落地了。这个标准也直接决定了后续的功能设计所有模块都围绕登记、检索、审批、维护四条主线展开。2. 技术选型为什么锁定Spring Boot Vue这对组合2.1 后端选型的现实考量选择Spring Boot不是因为它最潮而是因为它最适合这类企业内部管理系统的场景。第一Java在企业里存量最大后续交给别的团队维护没有门槛第二Spring Boot的生态极其成熟权限、缓存、消息、任务调度都有现成方案不用从零造轮子第三内嵌Tomcat让部署变成一个Jar包配合Nginx做反向代理就能快速上线。我对比过其它方案。用Go写性能确实好但团队招聘成本高用Node做原型快但碰到复杂事务和定时任务时心智负担重如果用Spring Cloud那套微服务对这种单体就能解决的系统属于过度设计反而把部署和排障变复杂。最终选型是Spring Boot 2.7 MyBatis-Plus MySQL 8 Redis简单直接够用且稳定。2.2 前端为什么用Vue而不是别的前端我选了Vue 3 Element Plus Vite Pinia。原因也很现实Vue在国内开发者群体中普及率高Element Plus的表格、表单、树、弹窗组件能覆盖后台管理系统九成以上的界面需求不需要自己写复杂组件。相比ReactVue的模板语法对后端转前端的同事更友好上手快。有一点值得说清楚选择Vue 3 Element Plus时要注意版本匹配。Element Plus只支持Vue 3如果项目里还有老代码依赖Vue 2就要评估整体升级成本。我这个项目是全新开发直接上Vue 3没有历史包袱是比较理想的状态。如果接手老项目Vue 2 Element UI也完全够用不必为了追新而重写。2.3 前后端分离的工程结构前后端分离的意义不只是技术上的更重要的是职责边界清晰。前端处理界面交互后端处理业务规则和数据两边通过JSON接口通信联调时用Swagger文档对齐字段发布时前端静态文件交给Nginx后端打Jar包独立运行。后端目录我按标准分层拆com.company.datareg ├── controller # 接口层只做参数接收和结果封装 ├── service # 业务逻辑层资产注册、审批流转 ├── mapper # MyBatis-Plus数据访问层 ├── entity # 数据库实体 ├── dto # 接口传输对象避免直接把实体暴露给前端 ├── config # 安全、跨域、Knife4j配置 └── common # 统一返回结构、异常处理、工具类前端目录按Vue规范组织src ├── api # 接口请求模块按业务域拆分 ├── views # 页面组件资产、审批、系统管理 ├── router # 路由配置包含动态路由逻辑 ├── store # Pinia状态管理存用户信息和权限标识 ├── components # 通用组件分类树、文件上传等 └── utils # axios封装、格式化工具这样的结构能让新接手的人十分钟内找到入口也方便后续扩展模块。3. 功能模块拆解从资产目录到审批链路先画好系统骨架3.1 数据资产目录分类树才是系统的门面登记系统的首页和导航核心不是统计报表而是资产目录。用户进入系统第一眼看到的就是一棵分类树类似于文件资源管理器的目录结构。我设计了三级分类主题域例如经营分析、客户管理、财务核算→业务域例如客户画像、订单分析→资产类别数据表、指标、接口、文件。这样设计是为了兼顾管理和检索主题域偏管理视角业务域偏使用视角资产类别则决定了登记表单的差异。分类树的数据结构不复杂但有一个设计点要注意树节点必须支持无限层级。虽然推荐三级但不同企业的组织架构差异很大有的想按事业部再细分一层有的想按地域分。所以数据库层面用parent_id自关联前端用递归组件渲染不写死层级。节点变更时要注意维护路径字段path方便做某个节点下所有资产的统计查询。3.2 资产注册与详情字段级元数据怎么建模资产注册是系统的核心操作。用户点击某个分类节点后可以新增资产。不同资产类型展示不同的表单数据表要填库名、表名、存储引擎、行数预估数据指标要填口径说明、计算公式、统计周期。这种差异化通过前端动态表单实现后端用asset_type字段区分用JSON字段extra_attrs存不同资产的扩展属性。字段级元数据是数据表类资产特有的能力。登记一张表时用户可以继续录入字段明细包括字段名、字段类型、是否主键、字段注释、示例数据、是否敏感字段。这些信息对数据治理的价值非常大相当于给每张表建了一份可读性极高的说明书后续做数据血缘、质量规则、脱敏策略都可以基于这份明细展开。我在前端做成弹窗式字段编辑器支持从Excel批量粘贴字段定义效率比逐行录入高很多。3.3 审批流让登记具备业务严肃性数据资产不是谁随便添一笔就能生效的。如果注册完全放开系统里很快就全是重复、错误、过期的脏数据。所以我设计了一套轻量审批流资产创建后先进入草稿状态提交后流转到待审核由资产所属分类的管理员审核审核通过后状态变为已发布资产才正式对全员可见。审核不通过则退回并记录驳回原因。状态机是这套审批流的核心我用一个字段asset_status表示DRAFT(草稿)、PENDING(待审核)、PUBLISHED(已发布)、REJECTED(已驳回)、OFFLINE(已下线)。所有状态变更都只允许通过服务层的统一方法操作禁止在Controller里直接改状态字段。这样审计日志才能完整记录谁在什么时间把资产从什么状态改到了什么状态。3.4 检索和统计决定系统日常使用频率登记系统如果只增不查很快就会变成僵尸系统。检索模块我做了两个入口一是顶部全局搜索框支持按资产名称、编码、责任人模糊搜索二是资产列表页的筛选区支持按分类、类型、状态、安全级别组合过滤。搜索结果用高亮关键词的方式展示点击进入资产详情页。统计模块服务于管理视角包括资产总量、各分类下资产数、本周新增数、状态分布、字段级元数据覆盖率。这部分用简单的SQL聚合就能实现不需要引入专门的报表引擎。真正要花心思的是统计维度要与分类树联动例如用户点击某个分支后统计卡片跟着刷新而不是只显示全公司总量。4. 数据库设计一张主表怎么撑起整套资产台账4.1 核心表结构与字段说明这套系统的表不算多我把核心业务表控制在八张以内避免过度拆分。表名用途关键字段sys_user用户表username, dept_id, statussys_role / sys_user_role角色及其关联role_code, 用户角色中间表sys_menu菜单/按钮权限表parent_id, perms, menu_typeasset_category资产分类树parent_id, category_name, path, sort_nodata_asset资产主表asset_code, asset_name, category_id, owner_id, asset_type, extra_attrs, statusdata_asset_column字段级元数据asset_id, column_name, column_type, comment, is_pk, is_sensitiveasset_audit审批记录asset_id, action, from_status, to_status, auditor_id, commentasset_oper_log操作日志asset_id, operator_id, operate_type, contentdata_asset是绝对的核心表几乎所有业务查询都要跟它打交道。设计时我把通用属性抽出来作为固定字段把差异属性放到extra_attrs JSON字段里。这样既保证了统一字段可以建索引、做筛选又不会因为每个资产类型都要几十个自定义字段导致表结构爆炸。4.2 为什么资产编码、版本号、状态字段缺一不可资产编码是数据资产的身份证号我采用分段规则生成DAS-{类型码}-{年月}-{四位流水}例如DAS-TB-202506-0018。月度重置流水号让编码好读且有规律类型码让编码本身就能区分资产类别。资产编码一旦生成就不可变更即使资产下线重上也要保留原编码因为外部系统可能已经通过编码引用该资产。版本号asset_version解决的是资产登记信息被改乱的问题。资产发布后如果责任人想修改口径或字段不应该直接覆盖原记录而应该记录一次变更。我采用的方式是主表保存最新版本变更前把旧内容写入历史表中。这个做法在审计和追溯场景下非常有用比如半年后想查这个指标当时的口径和现在有什么区别一条SQL就能拉出历史快照。状态字段前面已经说过配合审批流使用。这里补充一个细节数据库里状态字段我存的是编码而非中文比如0草稿、1待审核、2已发布、3已驳回、4已下线。界面通过数据字典翻译展示。这样做的原因是状态编码稳定中文名可以随时改且可以用数字比较实现只允许经理以上角色审核这类规则。4.3 分类树的递归与冗余路径字段资产分类树用parent_id自关联是标准做法查询某个分支的子树时用递归。但递归查询在数据量大时会比较吃力尤其是要统计某个分支下所有资产的时候。我的解决办法是牺牲一点写入成本换一个path字段。例如父节点path是01.03子节点path就是01.03.05查询分类下的全部资产时直接WHERE category_path LIKE 01.03%走索引也很快。插入新节点时维护path并不复杂读取父节点path拼接自身sort_no即可。删除节点时要注意级联处理子节点和其下资产我建议采用逻辑删除deleted标记物理删除容易误删而且审批记录会引用资产ID物理删除会把审计链路弄断。5. 后端实现要点编码、导入、权限与状态流转5.1 资产编码生成Redis计数器和锁的配合资产编码看起来是个小事但高并发下做不好就会重复。我用Redis的自增计数配合日期前缀来生成编码。核心逻辑是每天零点后第一次生成编码时以asset:serial:202506为key调用INCR得到当天的流水号然后拼接成完整编码。为了防止并发请求同时拿到同一个流水号INCR本身就是原子操作不需要额外加锁。使用Redis生成编码前要确保系统里Redis是可用依赖。如果不方便引入Redis可以用数据库表维护一个日期序列号的计数器加上行锁或乐观锁也能实现但Redis实现最干净。这里踩过一个坑Redis持久化策略如果配置不当重启后会从RDB快照恢复计数器导致流水号回退重复所以务必开启AOF持久化或者至少接受极端重启后编码不连续但保证不重复的兜底方案。5.2 用EasyExcel做批量导入而不是手写POI只有手工录入是不现实的已经有Excel台账的企业希望直接批量导入。我选用阿里巴巴的EasyExcel来做它在POI基础上封装了流式读取处理几万行数据内存占用很稳定。导入流程我做成三步上传Excel文件到临时目录后端解析并校验每行数据生成成功行和失败行列表校验通过的数据进入草稿状态等待再次确认后批量提交。解析时我自定义了一个监听器在invoke方法里做逐行校验把错误信息累积到行号对应的Map中。全部解析完成后把包含错误行的汇总结果返回给前端前端在页面表格里用红色标记错误行用户修正后重新上传。这个处理方式比碰到第一行错误就中断友好得多用户不需要一遍遍重复传文件。![注意]导入Excel时字段级元数据也可以一并导入我约定的格式是sheet名称为资产信息sheet内第一行是字段名后续每一行是一个字段定义。这样一次导入就能完成建表字段两条登记操作。5.3 认证授权与数据权限的落地登录认证我用Sa-Token相比Spring Security配置量更小集成JWT也更直观。登录成功后颁发token前后端通过Authorization: Bearer xxx传递后端用拦截器校验token并解析当前用户信息存入上下文。Sa-Token框架自带踢人下线、账号封禁能力后续做用户管理很方便。权限控制分为菜单权限和数据权限两层。菜单权限就是用户能看到哪些页面、按到哪些按钮通过用户-角色-菜单的关联关系控制。数据权限处理的是谁能看到哪些资产系统里每个资产都有所属部门普通用户只能查看本部门发布的资产跨部门查看需要管理员授权。我通过AOP注解在Service层做数据权限过滤注解里传入表别名切面自动给SQL追加WHERE dept_id ?或WHERE owner_id ?条件。5.4 状态流转与审计日志状态流转逻辑我统一封装在AssetStatusService里核心方法是changeStatus(asset, fromStatus, toStatus, operator, comment)。方法内部先校验当前状态是否符合预期再执行状态变更最后写入asset_audit和asset_oper_log。之所以强制传入fromStatus是为了防止并发场景下两个请求同时把同一资产从草稿状态分别改成发布和驳回导致状态错乱。审计日志的写入使用独立事务。资产状态更新和日志写入如果放在同一个事务里出现异常时日志也会回滚反而丢失排查线索。我的做法是把状态更新作为主事务日志通过Transactional(propagation REQUIRES_NEW)单独提交这样即使状态更新失败日志也能记录失败尝试。这个小细节在排查谁反复提交、为什么被驳回时特别管用。6. 前端实现要点列表、分步表单、树形组件与权限路由6.1 资产列表页让用户一眼能找到目标资产列表是前端使用频率最高的页面我用Element Plus的el-table实现启用stripe斑马纹和border边框列包括资产编码、资产名称、分类、类型、负责人、状态、更新时间。状态列用el-tag加不同颜色已发布绿色、待审核橙色、已驳回红色、草稿灰色视觉上比纯文字醒目得多。筛选区放在表格上方支持按关键字模糊搜索、按分类下拉选择、按状态多选、按类型单选。筛选条件通过URL参数同步到地址栏这样用户可以把常用筛选存为书签下次打开直接进入想要的视图。分页组件用el-pagination后端返回总条数前端维护pageNum和pageSize切换时重新请求接口。列表与分类树的联动是核心交互左侧树点击某个节点右侧列表刷新为该节点及其所有子孙节点下的资产。这个联动实现不复杂关键在于左侧树节点点击后要拿到完整的path再传给后端接口做LIKE查询。6.2 注册表单分步引导加动态校验资产注册表单我设计成三步向导而不是一个长页面。第一步填基本信息资产名称、所属分类、资产类型、负责人、安全级别。第二步填扩展属性根据资产类型动态渲染不同字段数据表需要填库名表名指标需要填口径公式。第三步填字段级元数据数据表类或确认提交。分步的好处是用户在每一步面对的字段较少不容易产生畏难情绪而且可以在step切换时做分步校验。Element Plus的el-form支持在指定步骤上触发validateField我在点击下一步时只校验当前步骤的必填项全部步骤校验完成后才允许提交。提交按钮在审核流里分为保存草稿和提交审核两个动作草稿随时能改提交后则不可再编辑必须等待审核结果。动态扩展属性用v-if根据assetType控制渲染组件后端返回的extraSchema决定当前类型下要展示哪些字段。这样一个表单组件就能适配数据表、指标、接口、文件四种资产类型后续新增类型只需要维护schema不用改页面结构。6.3 树形组件分类选择与节点管理分类树在注册表单和左侧导航里都要用所以单独封装成通用组件CategoryTree.vue。组件基于el-tree实现支持异步加载子节点、搜索过滤、拖拽排序可选。注册表单中点击分类字段弹出一个树选择对话框选中后回显完整路径例如经营分析 / 客户画像 / 数据表。树节点管理包括新增子分类、重命名、移动、删除。新增和重命名比较简单删除前要弹窗确认并提示该分类下N项资产将同步标记为待迁移用户体验比直接报错好很多。移动节点时要谨慎移动后path字段必须重新计算否则LIKE查询会失效。我在实现移动时是让前端把源节点ID和目标父节点ID传给后端由后端统一更新path和sort_no避免前端自行计算出错。6.4 动态路由与按钮权限权限系统在前端的核心是路由和按钮。登录接口返回当前用户的菜单列表和权限标识集合前端遍历菜单列表生成可访问的动态路由用router.addRoute逐个注册。未授权页面直接不加载配合后端接口的二次校验双保险防止越权访问。按钮权限我实现了一个自定义指令v-permission用法如el-button v-permissionasset:audit审核/el-button。指令内部检查当前用户权限集合是否包含指定标识不包含则删除该DOM节点。这个方案比v-if简单且不会因为用户切换角色后重新登录导致缓存问题因为每次刷新都会重新拉取权限。6.5 Axios封装与统一错误处理所有前端请求都走一个封装的Axios实例。我在拦截器里做了三件事请求头自动携带token、响应时统一剥离{ code, message, data }包裹结构、HTTP状态码非200时统一弹错误提示。对登录失效的响应401状态拦截器会自动清除本地token并跳回登录页。上传大Excel文件时要在Axios配置里设置timeout: 60000避免默认10秒超时导致导入失败。后端上传限制也要同步调大Spring Boot中spring.servlet.multipart.max-file-size默认只有1MB我用的是50MB前端上传前还会先做文件类型和大小预检拦截明显不合规的文件。7. 部署交付Nginx、跨域、时区那些绕不开的坑7.1 部署拓扑与整体流程生产环境我采用经典的前后端分离部署前端打包成静态文件放入Nginx的html目录后端打成一个可执行Jar包独立部署Nginx将/api路径的请求反向代理到后端服务。这套拓扑的好处是后端端口不直接暴露外网只开放80/443安全性更高前端静态文件由Nginx处理性能也够。系统依赖MySQL和Redis。MySQL负责业务数据持久化Redis负责缓存、登录会话、资产编码序列。生产环境强烈建议把MySQL和Redis分别部署在不同机器或至少不同容器里避免单点宕机导致整个系统不可用。如果公司容器化程度高也可以用Docker Compose把后端、前端、MySQL、Redis编排起来但要注意持久化卷的挂载容器重建别把数据库数据弄丢。7.2 Nginx配置示例与说明Nginx的关键配置如下server { listen 80; server_name asset.example.com; # 前端静态资源 root /data/asset-web; index index.html; # 前端路由是history模式必须回退到index.html location / { try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 上传文件体积限制 client_max_body_size 50m; }try_files回退到index.html是Vue Router history模式必须的配置漏掉这行会出现访问子路径直接404的问题。proxy_pass后面的URI拼接要注意如果后端接口是/api/asset/list代理配置写成proxy_pass http://127.0.0.1:8080;则会把整个/api/asset/list原样转发写成http://127.0.0.1:8080/api/;则会用/api/替换匹配到的/api/前缀效果等价但不易出错。我习惯写成带/api/的形式后端Controller统一以/api开头一眼就能对齐。7.3 部署阶段最容易踩的几个坑跨域配置是前后端分离最容易出问题的地方。开发阶段用Vite代理比较方便生产环境有了Nginx反代通常不需要后端开启跨域。但如果后端需要直接面对其他域名前端就要在Spring Boot里配置CorsFilter这时候千万注意allowCredentials(true)不能和allowedOrigins(*)同时使用浏览器会直接拒绝携带Cookie的跨域请求。解决方案是allowedOriginPatterns(*)配合allowCredentials(true)。数据库连接串里的时区参数不能省。MySQL的serverTimezone要显式设置成Asia/Shanghai并且连接串加上useUnicodetruecharacterEncodingutf8否则会出现日期差8小时、中文乱码这类经典问题。我的连接串长这样jdbc:mysql://127.0.0.1:3306/data_reg?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrueJWT密钥在生产环境要用环境变量注入而不是硬编码在配置文件里。我吃过这个亏测试环境密钥和线上不一致导致线上重启后所有旧token失效用户全部被踢下线。另外如果做多实例部署所有实例必须使用同一个密钥否则请求落到另一个实例会校验失败。Sa-Token的token除了JWT还可以选择Redis存储模式多实例天然共享不过我更倾向JWT加Redis黑名单的混合方案兼顾无状态和注销及时性。8. 交付之后文档怎么组织、演示数据怎么准备8.1 部署文档和设计文档怎么写才不白写项目交付内容包括源码、LW论文/说明文档和部署文档。很多开发觉得文档是负担但维护这套系统的人换了几轮之后文档就是救命稻草。我的文档组织分三份部署文档从环境要求到启动步骤按命令逐条写。包括JDK版本、MySQL初始化脚本、Redis配置、后端配置文件修改点、前端构建命令、Nginx配置样例。每个步骤附带验证方式例如启动成功后访问/api/system/ping应返回pong。设计文档写清表结构、状态机、权限模型、关键接口的请求响应示例。不只贴代码要解释为什么这么设计方便后续扩展。操作手册面向业务用户写普通用户怎么检索资产、责任人怎么维护资产、管理员怎么审核。这一份往往最容易被忽略但它决定系统在业务侧能否被顺畅使用。8.2 演示数据与演示流程的准备空跑的系统没有说服力。我在初始化SQL里预置了一套演示数据三个主题域、每个主题域下两到三个业务域、每个业务域下若干资产其中包含数据表、指标、接口三种类型状态覆盖已发布、待审核、草稿。演示时建议按这个顺序走管理员登录展示全公司资产总量统计和分类分布普通用户检索一个指标查看资产详情和字段级元数据责任人新增一张数据表录入字段后提交审核管理员审批通过列表页实时出现新资产。这套演示动线基本覆盖了系统所有核心模块五分钟内能让听者理解系统价值。演示数据里建议不要用真实业务数据防止敏感信息泄漏我用的都是脱敏后的虚构数据字段名也做了混淆处理。8.3 后续可以扩展的方向系统交付后如果业务侧持续使用会有不少可扩展点。个人认为优先级最高的是数据血缘在资产详情里展示这个指标的来源表是哪些、下游又被哪些报表使用这样数据问题的追责和影响分析会清晰很多。其次是数据质量规则允许资产负责人配置质量校验规则例如空值率、重复率阈值定期生成质量报告。第三是标签体系给资产打核心资产涉敏资产临期数据等标签配合检索和统计能更精细地支撑权限管控。这些扩展不会改变登记系统的主干但会让资产台账从静态名录逐步变成动态治理平台。这也是当初立项时最值得期待的演进方向。最后分享一个我自己的操作体会登记类系统的成败往往不在技术多炫而在录入是否省事、检索是否顺手、状态是否明确。花大力气做的审批流和审计日志可能在演示时看不到直观效果但真正上线跑起来负责治理的同事会非常感激。你如果也在做类似的系统建议优先把这三个体验打磨好再来加那些锦上添花的功能。