1. 从"数据管理"到"数据资产化"：这个系统到底在解决什么
先说一个我自己做项目的感受：做了这么多年后台管理系统，大多数项目本质上是"换皮增删改查"，但这个基于SpringBoot+Vue的企业数据资产登记系统，是我遇到过少有的、需要先在业务层面把逻辑想清楚才能动手写代码的项目。为什么？因为"数据资产"这个词听起来很热，但落到企业实际场景里，大多数人说不清楚自己到底有什么数据。
1.1 数据资产登记的核心逻辑
数据资产登记，通俗讲就是给企业的每一条数据"上户口"。一个企业可能有几十个业务系统，ERP里有订单数据、CRM里有客户数据、HR系统里有员工数据，还有一堆Excel表、报表文件、接口服务。这些数据分散在各个系统里，由不同部门维护，安全级别不同，使用范围不同——如果没有人对它们进行统一登记，就会出现三类典型问题：数据家底不清（老板问"我们有哪些数据"，没人能答全）、数据责任不明（出了问题找不到负责人）、数据共享靠人情（想跨部门拿数据，只能靠打听）。
这个系统的核心逻辑，就是把"数据资产"当作类似于固定资产、无形资产的对象来管理。固定资产有台账、有编号、有责任人、有领用记录，数据资产也一样：需要唯一编号、需要记录归属部门、需要标明安全等级、需要跟踪从登记到变更到归档的全生命周期状态。
1.2 系统要解决的四个核心痛点
我接触过几家企业客户之后，把需求收敛成了四个核心痛点，这也是数据资产登记系统区别于普通台账系统的关键所在：
第一，资产识别标准化。不同部门对同一个数据源的叫法各不相同，系统必须提供统一的分类树和命名规范，让登记人按标准填写。比如"客户信息"就不能一会儿叫"客户资料"，一会儿叫"CRM客户主档"。
第二，字段级元数据管理。登记的表单如果只记录"这个业务系统有哪些表"，其实是不够的。实际业务中，使用方最关心的是"这张表里有哪些字段、哪些字段敏感、主键是什么"。所以系统要支持到字段级别的登记，这也是很多企业内部数据地图产品的常见设计。
第三，生命周期状态跟踪。数据资产不是登记完就结束了：它会被修改、被下线、可能被归档。系统需要有一套明确的状态机，让每一步操作都留有痕迹。这个机制虽然简单，但能解决非常大的管理问题。
第四，审批与责任绑定。不是任何一个人都能登记和修改资产信息的。系统需要把"登记人—审批人—维护人—使用人"这几种角色分开，登记提交后要经过审批才能生效，操作记录要可追溯。
1.3 我最终圈定的系统边界
技术项目最忌讳的是范围蔓延。我在项目落地前反复和需求方确认过，这个系统不是要做成完整的数据治理平台，不包含数据质量稽核、数据血缘分析、数据服务API网关那么大而全的功能。它聚焦在三件事上：资产登记（录入基本信息、字段信息）、资产台账（分类检索、明细查看、统计分析）、资产生命周期管理（审批、变更、归档）。想明白边界，后面所有技术决策都会清晰很多——这也是我给做同类系统的朋友最实在的建议：先划线，再动手。
2. 技术选型落定：为什么是SpringBoot + Vue，以及各个依赖怎么选
技术选型这个环节，很多人上来就问"用哪个框架好"，但实际项目里最合理的问法是"这个系统要部署在哪里、谁在用、团队维护能力如何"。基于前面讲的三块核心功能，我做了如下选型，整个过程走下来还是比较稳的。
2.1 为什么继续保持前后端分离
企业数据资产登记系统的用户场景是典型的后台管理：管理员、资产登记员、审批人分散在不同办公网络环境下，需要通过浏览器访问，并且系统后续大概率要嵌入到企业统一门户或办公平台里。前后端分离在这个场景下是标准方案：后端提供纯API，前端独立部署，两边可以独立开发、独立扩展，也为将来可能做的移动端适配留了余地。
如果这个系统只是单机小范围使用，我可能会考虑服务端渲染之类的更简单方案。但考虑到企业后续大概率会要求单点登录对接、内容嵌入门户、甚至出移动审批，前后端分离的收益明显大于成本。
2.2 后端框架选型的实际考量
后端我选用的是SpringBoot 2.7 + MyBatis Plus 3.5 + MySQL 8.0 + Redis + Sa-Token这个组合。每个组件都不是随便选的：
- SpringBoot：不用多解释，企业级Java应用的默认选择。它最大的价值是自动化配置，把Spring繁琐的Bean装配简化掉，同时生态成熟，找资料、招人都方便。
- MyBatis Plus：为什么不用Spring Data JPA？因为这类台账系统查询条件复杂，需要灵活拼接SQL，而且MyBatis Plus内置了分页插件、逻辑删除、字段自动填充这些功能，几乎是为管理后台量身定做的。特别是它的
LambdaQueryWrapper，写条件查询非常清爽，不用拼字符串，减少低级错误。 - Sa-Token vs Spring Security：我在这两者之间犹豫过。Spring Security功能全面但配置重；Sa-Token轻量、API直观、自带踢人下线、权限校验注解，对单体后台项目来说完全够用且上手成本低。实际用下来，权限这套东西从配置到调通只花了不到半天。
- Redis：用来缓存数据资产分类树和字典数据。这类数据读多写少，没必要每次请求都查数据库。
2.3 前端框架选型的实际考量
前端我选用的是Vue 3 + Vite + TypeScript + Element Plus + Pinia + Vue Router。
这里有一个现实问题需要说明：Vue 2在2023年底就停止维护了，新项目如果还从Vue 2起步，等于从出生就在积累技术债。所以哪怕很多旧项目资料是Vue 2的，我也建议新项目直接上Vue 3。实际体验下来，Vue 3的组合式API写业务代码比选项式API舒服太多，逻辑复用也更自然。
- Vite：开发服务器启动速度和热更新体验比Webpack快一个量级，这个对开发效率的提升是实打实的。
- Element Plus：后台管理项目的UI，用Element生态是最稳妥的。表格、表单、树形组件、弹窗，都有现成方案，而且和Vue 3配合没有兼容性问题。
- Pinia：状态管理。比Vuex轻，TS支持好，用来存用户信息、侧边栏菜单状态足够了。
- TypeScript：很多人觉得TS增加学习成本，但做这种长周期维护的系统，TS对接口返回类型、表单数据结构这些的约束能力非常有用，能减少大量联调阶段的低级错误。
3. 数据库设计：给每一条数据资产建立"身份档案"
数据资产登记系统的数据库设计，核心不是设计一张大表把所有信息塞进去，而是要拆成"主表 + 明细表 + 辅助表"的结构。我直接把我最终落地的表设计分享出来，并解释每张表为什么这么建。
3.1 资产主表：data_asset
资产主表是整套系统的核心，记录一条数据资产的基本档案。字段设计如下（我截取关键部分）：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| asset_no | varchar(64) | 资产编号，格式如 AST-20240512-001 |
| asset_name | varchar(128) | 资产名称 |
| category_id | bigint | 所属分类ID，关联分类表 |
| source_type | tinyint | 数据源类型：1-数据库，2-文件，3-API接口 |
| db_type | varchar(32) | 数据库类型（MySQL/Oracle/PostgreSQL等），数据源类型为1时有效 |
| db_host / db_port / db_name | varchar/ int / varchar | 连接信息，数据源类型为1时有效 |
| table_name | varchar(64) | 对应数据表名 |
| file_path | varchar(255) | 文件路径，数据源类型为2时有效 |
| api_url | varchar(255) | 接口地址，数据源类型为3时有效 |
| owner_dept | bigint | 归属部门ID |
| owner_user | bigint | 负责人ID |
| security_level | tinyint | 安全等级：1-公开，2-内部，3-秘密 |
| status | tinyint | 状态：0-草稿，1-待审批，2-已登记，3-已驳回，4-已归档，5-已下线 |
| version | int | 版本号，每次变更+1 |
| remark | varchar(500) | 备注 |
| create_time / update_time | datetime | 创建/更新时间 |
这里有一个很容易被忽略的设计：version字段。数据资产登记不是一锤子买卖，后续修改资产信息时不能直接覆盖，而是需要记录"第几版"。这个字段配合后面的变更日志表，就能追查出资产从登记到当前的完整演变过程。
3.2 字段元数据表：data_asset_field
登记一条资产时，如果只登记到"表"这一层，后续使用方还是不知道自己能拿哪些字段、这些字段是什么含义。所以从第一版设计开始，我就坚持要做字段级明细：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| asset_id | bigint | 关联资产主表ID |
| field_name | varchar(64) | 字段名 |
| field_comment | varchar(255) | 字段注释/业务含义 |
| field_type | varchar(32) | 数据类型，如 varchar、int、date |
| max_length | int | 最大长度，可空 |
| is_pk | tinyint | 是否主键：0-否，1-是 |
| is_nullable | tinyint | 是否可空：0-否，1-是 |
| is_sensitive | tinyint | 是否敏感字段：0-否，1-是（如手机号、身份证号） |
| sort_order | int | 展示顺序 |
把字段明细拆成独立表的好处有两个：一是主表保持精简，避免超宽表问题（一条资产可能有几百个字段，如果存在主表的JSON字段里，后续查询和统计会非常痛苦）；二是为后续做资产关联和敏感数据统计留好了扩展空间。
3.3 分类表、审批记录表和变更日志表
除了资产主表和字段表之外，三个辅助表撑起了"管理"能力：
- asset_category 分类表：id、parent_id、name、sort，自关联实现无限层级分类。分类树属于典型读多写少的数据，启动时加载到Redis，修改后刷新缓存。
- asset_approval 审批记录表：id、asset_id、approver_id、action（提交/通过/驳回）、comment、create_time。这张表记录一条资产每次审批的全过程。注意，同一资产可以多次审批（驳回后修改再提交），所以是一对多关系。
- asset_changelog 变更日志表：id、asset_id、change_type（修改/下线/归档）、change_content（JSON格式，存储变更前后差异）、operator_id、create_time。变更内容存JSON的好处是通用，加字段不需要改表结构；坏处是无法针对某个字段做SQL级统计，但对这个项目来说够用了。
审批记录表和变更日志表看似简单，却是这个系统"有据可查"的关键支撑。做这类管理系统，不要小看历史记录的积累能力，上线半年后去追溯一条资产的来源和变更，就是靠这两张表。
4. 后端实现：登记、审批、变更、归档的完整链路
后端最核心的部分不是CRUD接口怎么写，而是状态机的合理设计和几个特殊业务场景的处理。这两个点想清楚了，接口写起来就是体力活。
4.1 状态机设计：用一张状态表管理资产全生命周期
前面我把资产状态定成了：草稿、待审批、已登记、已驳回、已归档、已下线六个状态。这六个状态之间不是随便乱跳的，必须通过明确的动作触发：
- 登记人保存表单 -> 状态为草稿（草稿不进入审批流，只有登记人自己可见）
- 登记人点击"提交审批" -> 状态变为待审批
- 审批人通过 -> 状态变为已登记（此时资产正式生效）
- 审批人驳回 -> 状态变为已驳回，退回给登记人修改
- 已登记的资产可以做变更，变更也需要走审批，通过后版本号+1
- 已登记的资产可以下线，下线后状态为已下线
- 资产负责人可以申请归档，归档后进入只读状态，不可修改
这个状态机对应的Java实现，我没有引入Flowable这类工作流引擎。原因很简单：状态数量少、流转路径固定、参与人角色固定，用工作流引擎是过度设计。我的做法是在Service层封装一个StateTransitionService，用一张枚举表定义所有允许的流转路径，切换状态时校验合法性，非法流转直接抛业务异常。这样代码量小、可读性强，后续即使要加状态，改动也很集中。
4.2 资产登记接口与一个"必踩的坑"：逻辑删除和唯一索引冲突
登记接口的核心逻辑是：保存基本信息 + 保存字段明细。我的接口设计如下：
@PostMapping("/api/asset/register") public Result<Long> register(@RequestBody @Valid AssetRegisterVO vo) { // 1. 校验资产编号唯一 // 2. 保存主表基本信息，状态置为草稿 // 3. 保存字段明细列表 // 4. 返回资产ID }这里有一个我在好几个项目里踩过的坑，分享给大家：MyBatis Plus的逻辑删除功能和数据库唯一索引是冲突的。如果你在asset_no上建了唯一索引，同时又开了逻辑删除（del_flag），那么当一条资产被逻辑删除后，再用同样的编号登记新资产，数据表因为唯一索引的原因会插入失败——哪怕旧记录在业务层面已经"删除"了。
我的解决方案是：不在asset_no上建数据库唯一索引，而是在Service层查询物理表（包括逻辑删除记录）做编号唯一性校验。具体做法是使用@Select自定义SQL绕过逻辑删除自动过滤功能：
@Select("SELECT COUNT(*) FROM data_asset WHERE asset_no = #{assetNo}") int countPhysicalByAssetNo(String assetNo);核心原则是：编号生成的算法同时保证唯一性。我用的编号规则是前缀+日期+当日序号：AST-20240512-001，并且生成序号时用Redis的INCR指令保证并发下不重复：
String key = "asset:no:" + LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE); Long seq = redisTemplate.opsForValue().increment(key); String assetNo = String.format("AST-%s-%03d", dateStr, seq);这样就几乎没有重复的可能，即便偶尔有并发冲突，Service层校验也能兜住。
4.3 元数据自动解析：从建表SQL一键提取字段明细
这是一个最初需求里没有、但实际使用中"真香"的功能。企业登记数据资产时，如果让登记员一行一行手动录入字段信息，既慢又容易出错。我的做法是：支持上传一段CREATE TABLE建表语句，后端用正则解析出字段名、类型、长度、注释，自动生成字段明细，登记人只需要在页面上勾选哪些是敏感字段，甚至可以直接一键提交。
解析的核心代码如下（简化版）：
private static final Pattern COLUMN_PATTERN = Pattern.compile("`?([a-zA-Z_][a-zA-Z0-9_]*)`?\\s+([a-zA-Z]+\\(?[^\\)]*\\)?)\\s*(COMMENT\\s+'([^']*)')?", Pattern.CASE_INSENSITIVE); public List<AssetFieldVO> parseCreateTableSql(String sql) { List<AssetFieldVO> fields = new ArrayList<>(); Matcher matcher = COLUMN_PATTERN.matcher(sql); while (matcher.find()) { AssetFieldVO field = new AssetFieldVO(); field.setFieldName(matcher.group(1)); field.setFieldType(matcher.group(2)); if (matcher.group(4) != null) { field.setFieldComment(matcher.group(4)); } fields.add(field); } return fields; }我自己第一版正则写得比较粗糙，遇到decimal(10,2)这类带精度的类型、遇到多个空格、遇到NOT NULL DEFAULT子句就会漏解析。后来看同事的写法才意识到，正则对MySQL建表语句的适配需要反复调，建议测试用例覆盖这些常见写法。这个功能上线后，登记人员的工作效率提升了不止一倍，也是项目汇报时的一个亮点功能。
4.4 审批与数据权限：SQL层动态拼接
审批接口的逻辑并不复杂：查询当前待审批列表，审批人通过或驳回，写入审批记录表，更新资产状态。比较关键的是数据权限控制——企业场景下，不是所有角色都能查看全部资产信息。我的处理方式是：
- 通过Sa-Token的注解
@SaCheckRole("auditor")控制接口级权限； - 在MyBatis Plus的查询构造器里，根据当前登录用户的部门ID动态拼接
owner_dept = 当前部门的条件； - 重点：数据权限过滤必须在SQL层做，不能靠前端隐藏按钮或查完再内存过滤。原因很简单，如果接口返回了全量数据再过滤，权限就形同虚设，任何人抓包都能看到所有部门的资产信息。
具体实现上，我封装了一个DataScopeHelper工具类，在Service层构建QueryWrapper时统一调用：
QueryWrapper<DataAsset> wrapper = new QueryWrapper<>(); wrapper.eq(DataAsset::getOwnerDept, dataScopeHelper.currentDeptId()); if (securityLevelFilter != null) { wrapper.le(DataAsset::getSecurityLevel, securityLevelFilter); }这样一条权限控制逻辑在整个系统里保持一致，后续如果要调整规则（比如开放跨部门只读权限），只需要改这一处。
5. 前端实现：Vue 3 + Element Plus 的台账页面与动态登记表单
前端部分我拆成两条线来讲：一条是"让登记员快速录入"的表单页，一条是"让管理者快速浏览"的台账页。这两条线的交互设计差别很大，也是我认为前端实现中最有含金量的部分。
5.1 前端工程化准备与路由规划
工程初始化我用的是npm create vite@latest，选择Vue + TypeScript模板。然后安装依赖：
npm install element-plus @element-plus/icons-vue npm install pinia vue-router axios npm install -D sass unplugin-auto-import unplugin-vue-components这里推荐使用unplugin-auto-import和unplugin-vue-components这两个Vite插件，它们可以自动按需引入Element Plus组件和API，不用全量引入，打包体积更小。配置一次之后写代码非常舒服，不会出现ElMessage未定义的困扰。
路由规划上，我划分了六个主路由模块：登录页、数据概览、资产登记、资产台账、审批中心、变更记录。每个模块独立成一个目录，views下面按页面建文件夹，每个页面的子组件放Components子目录。路由守卫在router/index.ts中统一处理：
router.beforeEach((to, from, next) => { const token = useUserStore().token; if (!token && to.path !== '/login') { next('/login'); } else if (token && to.path === '/login') { next('/'); } else { next(); } });关于路由守卫，我多说一句自己的体会：路由守卫只能作为UI层的导航控制，不能作为真正的安全边界。真正决定能不能访问某个API、能不能操作某条数据，最终要靠后端的角色权限和数据权限校验。前端守卫的意义在于提升用户体验，而不是承担安全责任。很多新手项目把安全全部押在前端路由守卫上，这是不合理的。
5.2 动态登记表单：根据数据源类型切换录入项
资产登记页面是这个项目前端最复杂的部分，难点在于表单的"动态性"：当数据源类型选择"数据库"时，显示数据库连接信息输入项；选择"文件"时，显示文件路径输入项；选择"API接口"时，显示接口地址输入项。
我用的是Vue 3的组合式API + Element Plus的表单组件实现。核心代码如下：
<el-form ref="formRef" :model="form" :rules="rules" label-width="120px"> <el-form-item label="数据源类型" prop="sourceType"> <el-radio-group v-model="form.sourceType"> <el-radio :value="1">数据库</el-radio> <el-radio :value="2">文件</el-radio> <el-radio :value="3">API接口</el-radio> </el-radio-group> </el-form-item> <template v-if="form.sourceType === 1"> <el-form-item label="数据库类型" prop="dbType"> <el-select v-model="form.dbType"> <el-option label="MySQL" value="mysql" /> <el-option label="Oracle" value="oracle" /> <el-option label="PostgreSQL" value="postgresql" /> </el-select> </el-form-item> <el-form-item label="数据库地址" prop="dbHost"> <el-input v-model="form.dbHost" placeholder="192.168.1.10" /> </el-form-item> <el-form-item label="数据库名" prop="dbName"> <el-input v-model="form.dbName" /> </el-form-item> <el-form-item label="数据表名" prop="tableName"> <el-input v-model="form.tableName" /> </el-form-item> </template> <template v-else-if="form.sourceType === 2"> <el-form-item label="文件路径" prop="filePath"> <el-input v-model="form.filePath" placeholder="填写服务器或NAS上的文件路径" /> </el-form-item> </template> <template v-else-if="form.sourceType === 3"> <el-form-item label="接口地址" prop="apiUrl"> <el-input v-model="form.apiUrl" placeholder="http://.../api/data" /> </el-form-item> </template> </el-form>这里要注意的点：el-radio在Element Plus里的用法，value属性在较新的版本里取代了旧的label属性作为选中值。如果用label当选中值，会出现点击选中后无法正确回显的问题。这个坑我在联调阶段排查了将近一个下午。
字段明细部分，我做得比较激进：直接嵌了一个el-table作为可编辑表格，每一行对应一个字段，可以修改注释、勾选是否敏感字段、调整顺序。左侧放一个"解析建表SQL"按钮，点击后弹出对话框，粘贴SQL并提交到后端解析接口，返回结果后自动填充表格数据。这个交互模式比传统的"添加一行"表单高效得多。
5.3 台账列表页：状态标签、多条件筛选与详情抽屉
资产台账页面是这个系统的门面，页面核心功能是列表展示、筛选、查看详情。列表用的是el-table，状态列用el-tag配合动态类型渲染：
<el-table-column label="状态" width="100"> <template #default="{ row }"> <el-tag :type="statusTypeMap[row.status]"> {{ statusTextMap[row.status] }} </el-tag> </template> </el-table-column>状态映射我用一个常量文件集中管理，不用在模板里写死：
export const ASSET_STATUS = { 0: { text: '草稿', type: 'info' }, 1: { text: '待审批', type: 'warning' }, 2: { text: '已登记', type: 'success' }, 3: { text: '已驳回', type: 'danger' }, 4: { text: '已归档', type: 'primary' }, 5: { text: '已下线', type: '' } } as const;详情展示我选用了el-drawer而不是新开路由页面，好处是用户查看完详情可以马上回到列表继续操作，符合检索场景的交互习惯。抽屉内部用el-descriptions展示基本信息和字段明细，字段明细如果太多就折叠成可展开的表格。变更历史放在抽屉下方，通过时间线组件el-timeline展示，直观看到一条资产从登记到现在的所有操作节点。
审批中心页面的核心交互是待办列表 + 审批弹窗，弹窗里显示资产完整信息（复用详情抽屉的组件），审批人填写审批意见，选择通过或驳回。这个页面我在实现时做了一个小优化：待办列表进入时轮询刷新，因为审批是多人协作场景，别人的操作会实时影响当前列表状态。
5.4 状态管理与接口封装
前端状态管理用Pinia，我建了两个store：userStore（用户信息、Token、角色、部门）和appStore（侧边栏折叠状态、菜单列表）。没有搞很重的状态设计，凡是后端返回的数据，原则上不进store，只存在组件内部或通过props传递。这是我在多个前端项目中总结出的经验：过度集中管理后端数据会导致store变成垃圾场，状态更新逻辑复杂，反而容易出bug。后端数据就是"请求到就渲染，跳转走就丢弃"，只有用户身份、全局UI状态这类多个组件共享的数据才放进store。
接口请求封装，我用axios实例统一处理：
const service = axios.create({ baseURL: '/api', timeout: 15000 }); service.interceptors.request.use(config => { const token = useUserStore().token; if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { ElMessage.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } return res.data; }, error => { if (error.response?.status === 401) { useUserStore().logout(); router.push('/login'); } ElMessage.error(error.response?.data?.message || '网络异常'); return Promise.reject(error); } );把api接口按模块拆分文件管理，比如api/asset.ts、api/approval.ts，每个函数返回类型定义清楚。这块是前后端联调效率的关键：类型一但定义清楚了，前端根本不用去翻后端接口文档。
6. 联调、部署与上线前后踩过的几个"不大不小"的坑
前后端分离项目，联调和部署阶段的问题往往比开发阶段更多。这个项目从开发到部署，我依次解决了好几个问题，每一个都是实打实会卡住团队进度的坑。
6.1 开发环境跨域与生产环境反代
开发环境中，前端跑在5173端口（Vite默认），后端跑在8080端口，浏览器直接请求localhost:8080/api/...必跨域。我没有在后端写CORS配置类，而是用Vite代理解决：
// vite.config.ts server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }这样前端请求/api/...会在开发服务器被转发到后端，浏览器层面没有跨域问题。到了生产环境，我直接用Nginx反向代理，同样的路径规则：
location /api { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }为什么要统一用/api前缀？因为开发环境Vite代理和生产环境Nginx代理都基于这个前缀识别请求。如果前后端分离项目在设计之初没有统一前缀约定，后面的联调就会乱成一团。
6.2 LocalDateTime序列化与前端日期显示问题
这个坑几乎每个SpringBoot+Vue项目都会遇到。默认情况下Jackson序列化LocalDateTime，输出格式是2024-05-12T10:30:00，前端直接显示分秒之间有字母T，非常丑。我的处理方案是在application.yml中统一配置：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8同时前端axios请求时不特意处理时间，直接把后端序列化好的字符串渲染即可。注意时区也要一并设置，否则会出现数据库里存的是14点，接口返回却是6点（UTC转本地时差问题）的情况。
6.3 分页查询中的排序与联表字段冲突
MyBatis Plus的分页插件好用是真好用，但有一个细节容易踩坑：当查询涉及联表（LEFT JOIN分类表查分类名称），而排序字段是分类名称时，生成的SQL里ORDER BY category_name如果没有加上表别名前缀，某些版本的MySQL会报Unknown column 'category_name' in 'order clause'。实际报错原因是分页插件会对排序SQL包一层包裹，导致外层SQL无法识别内层表字段。
解决办法也很简单：不要直接在QueryWrapper的orderBy里写分类名称字段，而是在VO层先查出来再内存排序——因为台账页管理场景的数据量通常在千条以内，内存排序完全没有性能问题。或者也可以在SQL里明确写ORDER BY c.name。这类问题本质上是要理解分页插件的SQL拼装机制，别盲信"框架自动处理一切"。
6.4 数据库备份与配置外置
上线部署时，我把配置做成了application-prod.yml与application-dev.yml分离，启动命令用--spring.profiles.active=prod指定环境。数据库连接信息、Redis地址这类敏感配置，我还在考虑是否引入配置中心，但目前规模下用YAML外置就够了——不要为了架构上的"先进"去引入系统复杂度，尤其是一个人维护的阶段。
数据库备份是上线前一定要做的。我写了一个简单的shell脚本，每天凌晨用mysqldump备份全库，保留最近7天的备份文件。这个脚本不复杂，但能保证将来出现误删数据的情况时可以快速恢复。
6.5 上线后的运营经验：系统好用比系统先进更重要
最后聊几句上线后的体会。这个数据资产登记系统技术上的难度其实不算高，真正难的是让业务部门愿意把数据资产登记上来。我在试运行阶段做了三件"非技术"的事，效果反而很好：
第一，准备了历史资产的Excel批量导入模板。很多系统上线最大的阻力是"存量数据迁移"，我的做法是允许登记员先用模板批量导入，上线后再逐步完善字段信息，降低使用者的起步成本。
第二，把"资产编号"做得像身份证号一样有规律可读。业务部门的同事一看编号就能知道登记时间和顺序，心理上更容易接受这个系统。
第三，上线一个月后主动找各使用部门收集反馈，把使用频次最高的"解析建表SQL"和"Excel模板导入"做成默认功能入口，而不是藏在二级菜单里。这个系统后来能在一线用起来，靠的其实是这些细节。
做这类管理系统的经验，用一句话来概括就是：把它当成一个真正有人用的产品来做，而不是当成毕业设计或者演示Demo来做。前端组件选型要考虑维护者的技术栈，后端状态设计要考虑业务的真实流转，部署方式要考虑IT运维的接管成本。理解了这些底层逻辑，你会发现基于SpringBoot+Vue落地一套数据资产登记系统，并没有想象中那么复杂，但它能带给企业的管理价值，却比单纯写一套CRUD要高得多。
