1. 技术选型的底层逻辑为什么这对组合适合银行客户管理1.1 Spring Boot 3到底给老项目带来了什么变化先说一个很多人容易忽略的事实Spring Boot 3并不是给Spring Boot 2“简单升个版本”那么简单。它踩在Spring Framework 6之上整个基础都换了——Java 17是起步要求Java EE的命名空间统一迁到了Jakarta EE。拿我做过的一个改造项目举例从Spring Boot 2.7升到3.x最直观的冲击就是所有 javax 开头的包全部要换成 jakarta。你没听错javax.persistence、javax.validation、javax.servlet这一大批你写了几年的import全部要改。如果你用了老版本的MyBatis-Plus、Sa-Token或者某些生成器插件大概率还要蹲在GitHub issue里翻半天才能找到兼容版本。所以如果决定用Spring Boot 3就得做好整个技术栈一起升级的心理准备。但正是因为这种“伤筋动骨”换来的长期收益才更明显Spring Security 6的配置模型更干净了Spring的AOT编译与GraalVM Native Image支持也逐步成熟Spring Data的仓储接口在响应式场景下也能无脑复用。对银行客户管理系统这种典型CRUD为主、但又对权限和数据安全敏感的业务系统来说Spring Boot 3的起点够高后续扩展空间也够大。1.2 Vue 3 Vite对开发效率的真实提升很多人在Vue 3和Vue 2之间犹豫本质上是在“熟悉”和“先进”之间做取舍。我的建议很简单新项目直接Vue 3没有历史包袱就别给自己挖坑。Vue 3带来的组合式API和script setup语法确实比Options API更适合中后台系统。银行客户管理这种页面往往有大量表单、列表、详情抽屉、弹窗校验逻辑分散在各个生命周期里用Vue 2的写法一个组件几百行是常事。换到组合式API之后核心思路变成“把一个业务逻辑的输入、状态、业务函数收拢到一起”代码的阅读成本明显降低。页面复杂之后还能很方便地抽成useCustomerList、useAccountForm这样的组合式函数复用到不同模块。Vite同样值得单独说说。Vite 3/4/5核心原理是浏览器原生ESM开发环境下不需要像Webpack那样先把所有模块编译打包而是按需启动所以冷启动速度是毫秒级的。实际操作中我从执行npm run dev到页面可访问通常只需要一两秒这在之前Webpack项目里几乎不可能。Vite还内置了预构建依赖的能力对Element Plus这种体积比较大的组件库首屏加载优化策略也好做很多。1.3 为什么不是其他组合我也必须坦诚说一下选型对比避免大家以为这套组合是万能的。如果只需要一个非常轻的内网工具直接用Spring Boot Thymeleaf模板就够了根本没必要上前后端分离如果团队更熟React那就不要为了Vue而Vue如果对响应式吞吐有硬指标那应该考虑Spring WebFlux或者Quarkus而不是Spring MVC。说到底Spring Boot 3 Vue 3最适合的场景是团队已经具备Java后端基础、前端希望用组件化方式交付中后台界面、且未来系统会持续迭代的这类项目。银行客户管理系统恰好落在这个区间里。2. 业务模块拆解银行客户管理不只是“增删改查”2.1 客户主数据与KYC信息建模银行客户管理系统里的“客户”和普通CRM里的“联系人”不是一个重量级。银行场景下客户主数据通常分为个人客户和对公客户两类每类都要关联一套完整的证件信息、联系方式、职业/经营信息、风险等级、黑名单状态等。这里有一个核心概念绕不开KYCKnow Your Customer了解你的客户。KYC不是一个页面字段而是一套流程。系统里至少要包含客户证件类型身份证、护照、港澳台通行证等、证件有效期、客户风险等级划分、受益所有人信息对公客户、是否属于政治公众人物等。在实际建模时我会把这些拆成客户基本信息表、客户证件表、客户风险评级表、客户联系信息表而不是把所有字段塞进一张大表。为什么这么拆因为银行场景下这些信息的更新频率不同。证件可能五年才换一次联系方式可能一年更新几次风险评级可能要按季度重评。如果全塞一张表每次修改都要带上整行数据不仅冗余还容易因为并发覆盖导致数据错乱。拆分之后每次变更都能做独立的留痕和审计。2.2 账户、资产与交易流水的数据边界客户是“人”账户是“资产载体”交易流水是“行为记录”。这三层的数据边界必须清晰。我有一次评审别人设计时看到有人把账户余额字段直接存到客户表里当时就觉得大事不妙——因为余额是一个会高频变化的状态值而客户信息是低频率变化的基线数据把它们放一起性能和并发都会出问题。账户表应该只保存账号、账户类型活期、定期、信用卡等、币种、账户状态正常、冻结、销户、开户时间这些“相对稳定”的信息。交易流水表则记录每笔收支的金额、时间、对方账号、交易类型、渠道等不能修改只能追加。余额这类统计值要么通过流水实时汇总适合数据量不大时要么在账户表里保存一个余额字段并用乐观锁控制更新。我在这个项目里推荐的做法是账户表保留余额字段但所有余额变动必须通过统一的交易接口处理禁止Service层直接改余额。2.3 客户分群、客户经理与业绩归属银行客户管理系统之所以和普通CRM不同还在于存在“客户分层经营”的逻辑。一个支行可能有几万客户不可能每个客户都给配客户经理所以系统里要有客户级别普通、金卡、白金、私行等、客户归属关系客户经理ID、所属网点以及客户分配规则。客户经理与客户的归属关系在业务上是一个很敏感的点。两个人争客户的事情在实际项目中并不少见所以系统设计时至少要做到归属关系有生效时间和失效时间变更要留痕客户经理只能操作自己名下客户的数据如果需要跨归属查看必须走审批授权。这部分功能在技术上没什么困难但在权限模型里必须考虑进去否则后期纠纷不断。2.4 非功能性需求清单除了功能模块银行客户管理这类系统还要把非功能性需求放在同等重要的位置。我从经验里整理了一份基础清单操作审计谁、在什么时间、从哪个IP、对哪条数据、做了什么操作全部要能回溯。数据脱敏列表页和导出文件中的身份证、手机号、地址等敏感字段必须脱敏展示。权限隔离分行、支行、部门、个人四级数据范围控制。并发控制余额变动、客户资料更新、状态流转都要防止同时操作造成覆盖。日志规范统一日志格式error级别必须带全上下文信息不能只输出一行干巴巴的NullPointerException。3. 后端骨架搭建从分层架构到认证鉴权3.1 分层规划与包结构设计后端我习惯按controller、service、mapper、entity、dto、vo、config、security、aspect这样的包结构组织。你可能觉得这种分层老套但银行项目要的不是花哨而是稳定和可维护。entity对应数据库表结构dto负责接收前端请求参数和承载查询条件vo负责输出给前端的数据视图。注意如果某个字段只在查询列表时需要算出来而数据库表中并没有这个字段那要放在VO里不能直接加在entity上。这个细节可以帮助你避免很多“为什么这个字段莫名其妙被持久化了”的诡异问题。Service层的命名也有讲究。我习惯把“查询列表”和“查询详情”分开因为列表通常需要支持分页、排序、条件组合而详情要求一次性返回全部关联信息两者性能特征不一样。把逻辑拆开后后面做缓存优化也更有抓手。3.2 统一响应、全局异常与参数校验前后端分离项目里最怕的就是接口返回结构五花八门。一会儿code、一会儿status前端拦截器没法写。我的固定套路是public class ResultVOT { private int code; private String message; private T data; }code为200表示成功非200表示业务异常。所有接口都返回这个结构。另外定义一个BusinessExceptionService层遇到业务规则不满足时直接抛出配合全局异常处理器RestControllerAdvice统一转成ResultVO返回。这样Controller里就不会出现一堆try/catch。参数校验这一块Spring Boot 3沿用了Jakarta Validation。实体字段上加NotBlank、Email、Pattern这些注解Controller入参上加Validated几乎是标配。但要记住一点不要过度依赖注解校验来承载业务规则。比如“客户年龄必须在18到65之间”这是业务规则应该写在Service里否则换个接口或者换种调用方式规则就失效了。3.3 Spring Security 6 JWT的集成步骤Spring Security 6和之前的配置方式差异非常大。旧版经常看到的WebSecurityConfigurerAdapter已经被彻底移除了现在主流写法是定义一个SecurityFilterChain的Bean。直接给一段可用的核心配置Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf.disable()) .sessionManagement(sm - sm.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth - auth .requestMatchers(/api/auth/login, /api/auth/captcha).permitAll() .anyRequest().authenticated() ) .exceptionHandling(eh - eh.authenticationEntryPoint(restAuthenticationEntryPoint())) .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); return http.build(); } }这里最关键的一点是SessionCreationPolicy.STATELESS。既然我们用JWT做无状态登录就不能让Spring Security再去创建HttpSession否则后端的“无状态”就名存实亡了集群部署时Session同步问题又会冒出来。JWT过滤器的主要职责是从请求头里读取Authorization字段解析Token校验签名和有效期然后把用户信息塞进SecurityContextHolder。注意校验Token不能让它只校验“能不能解出来”还必须在数据库里确认用户状态是正常的。曾经遇到过一个真实案例用户已经被管理员禁用但因为JWT还没过期他仍然能继续访问系统。所以每次请求都应该把用户ID查一下状态这个代价很小但安全性提升很大。3.4 事务、锁与并发控制的落地方案客户管理系统中事务管理和并发控制是银行场景的命门。Spring的Transactional声明式事务确实方便但很多人只知道加注解不知道它默认只对RuntimeException回滚。如果代码里抛了个Exception事务不会回滚数据就留在了一半状态这种bug是银行项目里最恐怖的。我的习惯是在事务方法上明确指定回滚策略最少也要搞清楚默认行为。核心业务比如“客户开户同时创建多个账户”必须放在同一个事务里而像“异步发送短信通知”这种操作要等事务提交之后再执行否则会出现会话还没提交短信已经发出去的情况。并发控制方面客户资料的更新用乐观锁。实体上加Version字段更新时带上version条件更新行数为0就说明被其他人改过这时要友好提示用户刷新重试。余额变动这类高并发操作我会在事务里先select for update把账户行锁住再执行余额计算和流水插入避免“两人同时消费一张卡”这种问题。4. 前端工程化落地Vue 3项目从初始化到联调4.1 Vite初始化与目录规划创建Vue 3项目我用Vite官方脚手架一条命令搞定npm create vitelatest bank-customer-management -- --template vue但要注意默认模板不会自动引入路由、状态管理、UI组件库这些需要手动追加。我的依赖清单一般是vue-router、pinia、axios、element-plus再加一个sass用于样式预处理。其中Element Plus因为体积比较大我建议按需自动导入用unplugin-auto-import和unplugin-vue-components这两个插件这样最终打包体积会小很多。目录规划上我通常会做src/ api/ // 接口定义一个模块一个文件 assets/ // 静态资源 components/ // 公共组件 composables/ // 组合式函数 router/ // 路由配置 stores/ // Pinia模块 views/ // 页面 utils/ // 工具函数request封装等4.2 路由守卫与动态权限加载银行客户管理系统的页面权限不能简单做“隐藏菜单”因为用户可以手动在地址栏输入未授权路由。所以路由守卫必须在前端拦截每次跳转前先判断用户是否已经登录再判断他是否有权限访问目标路由。一个可行的方案是后端登录接口返回该用户可访问的菜单/权限标识列表前端通过router.addRoute动态添加该用户拥有的权限路由不在权限列表里的路由地址一律匹配到403页面。这里有个容易踩的坑动态添加路由后如果用户刷新浏览器Pinia状态清空了路由也全没了。所以初始化时必须先从本地存储或后端重新拉取用户信息和权限列表等权限加载完成后再router.replace到目标页面否则会出现“刷新即白屏”的问题。4.3 Axios拦截器与接口层设计Axios拦截器是前后端联调体验的关键点。我会在utils/request.js里统一做三件事请求拦截带上Authorization请求头和当前访问的菜单权限标识如果需要签名也在这里统一处理。响应拦截如果后端返回的code不是200直接弹出错误消息如果是401说明Token过期清除本地用户信息并跳转登录页。重复请求处理用请求URL和参数做Map缓存短时间内相同请求直接取消上一个避免用户快速点击提交时产生重复操作。接口层设计上我推荐一个模块对应一个文件比如api/customer.js。每个接口用一个函数导出export function getCustomerPage(data) { return request.post(/api/customer/page, data) }页面里只需要引入函数并使用await调用不要在每个页面里直接写axios.post。这样后端接口一旦变化只需要在api层改一处全项目引用处的改动成本几乎为零。4.4 组件拆分与列表搜索三件套中后台页面最常见的模式就是“搜索栏 表格 分页”我会把这套模式抽成一个通用组合式函数比如usePageList输入请求函数、默认查询参数、分页参数。输出loading状态、列表数据、分页信息、search方法、reset方法、handleCurrentChange方法。这样每个业务页面里只需要编写查询条件对象和表格列配置剩下的逻辑全部复用。刚开始抽这个函数可能会觉得有点绕但一旦页面超过五个代码量节约的效果会非常明显。Element Plus的表格具备多选、排序、固定列等功能但在客户列表这种场景下我额外建议身份证号、手机号这类敏感字段不要在表格里直接展示明文应该调用一个统一的脱敏函数去格式化前端脱敏虽然不能完全替代后端脱敏但至少能防“肩部攻击”。4.5 联调阶段的跨域与命名约定开发环境下最常见的坑是跨域。Vite提供了server.proxy配置把前端请求代理到后端服务export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端请求/api/customer/page实际会被代理到http://localhost:8080/api/customer/page绕开了浏览器跨域限制。部署时我建议Nginx做同样的事前端只配一个反向代理路径不要在前端代码里写死后端IP否则换环境就要重新打包非常麻烦。另一个联调高频bug就是字段命名。数据库里是customer_name这种下划线风格Java实体用customerNameJSON通常也是customerName但如果你在VO里又设置了customer-name这种中划线风格前端就要到处兼容。我的建议很简单统一用驼峰风格后端配置Jackson的PropertyNamingStrategy不修改前端也全部用驼峰不做任何额外转换。这件事一定要在项目启动时约定好否则联调阶段每天都在“为什么这个字段取不到”。5. 银行场景的硬性要求审计日志、脱敏与数据安全5.1 用AOP实现操作留痕避免手工写日志代码银行项目被审计的概率极高所以每一个关键操作都要留下完整的审计记录。如果靠人肉在Service里一行一行写入日志表很快会因为漏写、忘写而失控。我的做法是自定义一个AuditLog注解配合AOP切面统一完成记录逻辑。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface AuditLog { String value(); // 操作名称如修改客户基本信息 }切面里通过Before、AfterReturning、AfterThrowing三种通知分别记录请求参数、响应结果、异常信息。审计内容至少包括操作人ID、操作时间、客户端IP、请求URL、操作类型、涉及的业务主键、操作前后数据快照。有人可能觉得快照太重了但银行场景恰恰需要你解释清楚“为什么这个字段从A变成了B”所以数据快照很有必要。5.2 敏感字段脱敏的方案对比数据脱敏有三种常见方案数据库层脱敏、后端脱敏、前端脱敏。我会优先用后端脱敏因为它既能保证接口返回的数据是干净可控的又不影响数据库里存明文以实现后续的数据分析或监管报送。后端脱敏最简单的做法是定义几个脱敏工具方法比如手机号保留前3后4身份证号保留前4后4然后在VO的getter里直接调用。但这会让VO非常零散而且如果有两种角色普通柜员、客户经理看到的数据粒度不同就得控制每个字段的展示规则。更优雅一点的方式是用注解Jackson序列化器自定义一个SensitiveField注解支持指定脱敏策略序列化时自动处理。这样只需要在VO字段上标注一下规则集中管理逻辑也清晰。5.3 密码与密钥管理客户管理系统里会涉及系统用户的登录密码和可能对接第三方系统的密钥。我在这里和老项目做个对比Spring Security 5之后BCrypt是默认的密码编码器凡是用明文存密码的一律视为严重安全事故。用户注册或改密时后端只保存BCrypt加密结果登录时用PasswordEncoder.matches比对不需要也不能反解密码。第三方对接密钥不要硬编码在配置文件或者代码里更别往Git提交。密钥应当放在环境变量里或者接入Spring Cloud Config、Nacos这类配置中心。如果项目比较简单至少用jasypt-spring-boot对配置里的密文进行加解密再把加密密码放在环境变量中。这个成本很低但能避免密钥跟着代码库到处流转。5.4 日志打印的纪律与logback配置银行项目的日志是有监管意义的。不只是排查Bug出事时要能快速定位“当时发生了什么”。我见过太多线上问题是因为日志打得太少或者把所有信息都打在一行导致查一次问题要翻半天。Spring Boot 3项目默认支持Logback我通常会自定义一个logback-spring.xml把日志拆分到几个文件里info.log记录正常业务日志error.log记录异常日志audit.log单独给审计回调记录。这样排错时直接查error.log出了安全性问题直接看audit.log不用从海量日志里大海捞针。日志内容也有讲究日志里不要打印完整身份证号和密码打印金额时带上币种异常日志必须附带异常堆栈和关联的业务单号这样排查问题时能准确关联到某一次客户操作。5.5 部署阶段的几个经典坑Spring Boot 3 Vue 3项目部署时我踩过几个非常典型的坑值得在这里说一下。第一个是前端部署到Nginx后刷新某个路由出现404。这是因为Vue Router是history模式直接访问/customer/list时Nginx会去磁盘找这个物理路径找不到就404了。解决办法是在Nginx配置里加一段try_files $uri $uri/ /index.html;让所有前端路由请求都回到index.html入口。第二个是打包后浏览器报Uncaught SyntaxError: Unexpected token。这个基本可以断定是服务器没有对JS文件响应正确的MIME类型或者CDN压缩格式和处理逻辑不匹配导致浏览器拿到的JS内容不完整。检查方向是Nginx是否开启了gzip且类型配置正确JS文件大小是否超过缓存限制以及浏览器缓存是否还在使用旧版本文件。第三个是接口部署的环境配置。很多人会把后端地址写在前端代码里固定下来结果换环境就要重新打包。更稳的做法是前端请求统一用相对路径/api由Nginx反向代理到后端的实际地址。这样无论部署到测试、预发还是生产前端包只需要构建一份环境差异全部交给代理层解决。6. 一些不太会写进文档的心得这个系统如果从头自己搭前后端加起来大概需要两到三周但大部分时间不是在写CRUD而是在处理权限、审计、并发、边界条件这些“看不见的需求”。银行客户管理系统的难点从来不是技术框架而是业务规则是否被准确翻译成了代码逻辑。我的经验是在动手写代码之前花一整天跟业务方确认四个问题客户归属变更时的权限怎么处理证件过期的客户还能不能办理业务交易异常需要通知到哪些角色审计日志要保留多久、导出格式是什么这四个问题如果不在设计阶段定清楚开发阶段的返工率会非常高。给我自己总结一个实用的小建议接这种类型的项目第一周不要急着写代码先画出客户、账户、交易、权限的四张ER图和五条核心链路。把“开户、改资料、冻结账户、客户移交、审批复核”这五条链路走通系统的主心骨就有了。剩余的页面和功能都只是在这五条链路上延伸的枝叶。
