1. 为什么选SpringBoot+Vue做贸易行业CRM：一次课设到实战的完整复盘
如果你正在为毕业设计、课程设计或者单纯想系统学一遍前后端分离开发而发愁，拿“贸易行业CRM系统管理平台”当项目载体，是我比较推荐的路子。原因很简单：CRM这个业务域足够“大而全”——客户、商品、订单、回款、联系人、跟进记录、报表统计，几乎覆盖了Java后端和Vue前端所有高频技术点。而SpringBoot+Vue这套组合，本身又是目前国内中小型企业内部系统最主流的技术栈形态之一，做完一个完整项目拿得出手，也算踩在了真实就业市场的需求点上。
这个项目表面上是一个“管理系统”，但实际上它训练的是三件事：第一，你怎么把一个模糊的“贸易公司管理需求”拆解成清晰的模块和表结构；第二，你怎么用SpringBoot把RESTful接口设计得干净、规范、安全；第三，你怎么用Vue3或Vue2把后台页面的数据流转、权限控制、交互体验做得像模像样。很多人毕设翻车，不是代码能力不行，而是没搞懂这层逻辑——题目给的是“平台”，你需要交付的是“思路 + 实现 + 工程化习惯”。
我实际把这个项目完整搭过一遍，从数据库设计到部署上线全都走了个来回。这篇文章不跟你聊虚的，就直接把这套系统怎么拆解、怎么落库、怎么编码、怎么避坑，全部摊开讲清楚，你可以把这篇文章当成一份“能抄作业但希望你抄完能理解为什么这样写”的完整参考。
2. 系统整体设计与技术选型背后的那些考虑
2.1 为什么贸易行业CRM不能照搬通用CRM
很多人一拿到题目就直接打开若依或者出一套所谓“通用CRM”的架子，然后往里面塞几个表就交差，这种做法是很可惜的。通用CRM它管的是销售线索、商机、合同这一条线，但是贸易公司本质上是“中间商赚差价”的生意模型，它的核心业务链条是：客户询价、按件报价、生成订单、采购备货、报关发货、回款对账。这说明什么？说明贸易行业的CRM系统，至少得覆盖客户、商品、供应商这三类主数据，以及报价单、销售订单、进货单、回款记录这四类业务单据。
另一个容易忽略的点是贸易公司的“商品”和“客户”之间往往是多对多的交叉关系。一个客户可能同时采购你五种商品，而一个商品可能卖给几十个客户；同时，贸易公司的订单通常还带有“数量阶梯价”“单位换算”这种特有逻辑。所以你在设计数据表的时候，就得提前把这种业务特征考虑进去，否则做到后面订单模块会发现越做越别扭。
我的建议是，核心数据域至少包含下面这些内容：
- 客户主数据：公司名、联系人、电话、邮箱、地址、客户等级、所属业务员、来源渠道
- 商品主数据：品名、型号、规格、单位、采购价、销售价、库存数量、供应商
- 供应商主数据：名称、联系人、供货周期、付款条件
- 订单主数据：订单编号、客户ID、下单日期、交货日期、订单状态、总金额、折扣、备注
- 订单明细表：订单主表ID、商品ID、数量、单价、金额
- 回款记录表：订单ID（或客户ID）、回款金额、回款日期、回款方式、备注
这个设计思路的意义在于，你的每张业务单据都有主数据做支撑，每张主数据表都有业务单据做引用，数据是有“血缘关系”的，而不是一堆各自独立的表躺在数据库里。
2.2 技术栈选型的底层逻辑
后端用SpringBoot，这个基本没什么争议。SpringBoot的核心价值就是“约定优于配置”，你不需要像早年SSH那样去写一大堆XML配置，一个启动类、几个注解就完事。配合MyBatis Plus做ORM，能让单表CRUD的代码量直接砍掉一多半，分页查询也是一个PageHelper或者MyBatis-Plus的分页插件就能解决。
前端用Vue，这个也是现在后台管理系统的主流选择。Vue的响应式数据绑定做得非常顺手，写表格表单这类交互密集的页面效率非常高。组合上Element UI组件库，你就能像拼积木一样把客户列表、订单表单、弹窗确认这些UI快速搭起来。具体用Vue2还是Vue3，我的建议是：如果毕业设计周期紧、教程多，Vue2 + Element UI最稳；如果你想顺带学点新东西，就上Vue3 + Element Plus + Vite，但要注意配套的组件库版本兼容问题。
这里解释一下为什么很多教程生硬地给你塞进来Redis、RabbitMQ、Elasticsearch这些东西。真实原因是：毕设答辩时候，老师会问“你这个系统和高并发系统有什么区别”，如果你引入了这些组件，你就有话可答。但是你要知道，对于贸易行业的内部CRM来说，并发量通常也就几十个人同时用，引入Redis缓存用户会话没必要，引入MQ做异步通知更没必要。项目里炫技可以适度，但核心模块（登录鉴权、订单CRUD、权限控制、报表统计）的代码质量才是决定你答辩分数的关键。
工具方面我补充一点实操经验：MySQL就用8.0，别再用5.7了，8.0的窗口函数、默认字符集UTF8MB4都能省不少心。IDE用IntelliJ IDEA，前端开发用VS Code或IDEA都行。数据库可视化工具推荐Navicat或者DataGrip，后端接口调试用Postman或Apipost。这套组合我实测下来是最顺手的搭配，也是绝大多数公司内部的真实环境。
2.3 项目目录结构如何从第一天就保持清爽
很多毕设项目做到一半就崩盘，不是因为功能多复杂，而是代码目录乱得自己都找不到文件。我建议你按照下面这种结构来组织SpringBoot后端：
com.example.crm ├── controller // 控制层：接收前端请求，调用service ├── service // 业务层：写核心业务逻辑，事务控制 ├── mapper // 数据访问层：MyBatis的Mapper接口 ├── entity // 数据库实体类 ├── dto // 数据传输对象：比如组合查询条件的对象 ├── vo // 视图对象：返回给前端展示的数据结构 ├── config // 配置类：跨域配置、拦截器、MyBatisPlus配置等 ├── common // 通用类：返回结果封装、常量、异常处理等 └── utils // 工具类：JWT工具、日期处理等前端Vue项目里，我也建议分得规矩一点：
src ├── api // 所有的axios请求封装，按模块拆分文件 ├── router // 路由配置 ├── store // Vuex或Pinia状态管理 ├── views // 页面组件，按模块建子目录 ├── components // 公共组件：比如上传组件、分页组件 ├── utils // 请求拦截器、工具函数 └── assets // 静态资源这样分的直接好处是，你写接口的时候容易找到controller，改页面的时候容易找到views，出问题的时候排查链路也短。别小看这种小习惯，它在答辩演示时的影响甚至比功能本身还大——因为老师会打开你的工程结构看代码组织，一个结构混乱的工程会让老师直接怀疑你整个项目的完成度。
3. 核心模块细节解析：从表结构到接口鉴权
3.1 表结构设计精讲：没有外键会更好用
数据库设计可能是这个项目最关键的环节之一。实话说，很多人的CRM系统垮掉，不是垮在编码上，而是垮在表设计上——字段缺失、关系混乱、类型不匹配，后面写代码处处受牵制。
我这里给你一个可以直接用的精简库表结构方案。首先，数据库命名为crm_db，字符集直接用utf8mb4_general_ci，因为客户和商品名称里很可能有生僻字。
客户表customer核心字段：id、customer_name、contact_person、contact_phone、email、address、customer_level（枚举：A/B/C）、owner_id（业务负责人用户ID）、source、remark、create_time、update_time。这里注意owner_id要建索引，因为客户列表页经常按“我负责的客户”过滤。
商品表product核心字段：id、product_name、model（型号）、spec（规格）、unit（单位，如件/箱/吨）、purchase_price（采购价，DECIMAL(10,2)）、sale_price（销售价）、stock_quantity、supplier_id、status。注意价格字段必须用DECIMAL而不是FLOAT，否则面试必被问“你懂不懂浮点数精度问题”，而且真实贸易报价也确实不能容忍一分钱的误差。
订单表sales_order核心字段：id、order_no（订单编号，唯一索引）、customer_id、order_date、delivery_date、total_amount、discount、pay_status（未付/部分付/已付）、order_status（草稿/已确认/已完成/已取消）、created_by、create_time。订单明细表sales_order_item的字段就是order_id、product_id、quantity、unit_price、subtotal。
回款表payment_record核心字段：id、customer_id、order_id（可空）、payment_amount、payment_date、payment_method（转账/现金/支票）、remark、create_time。
这里有一个经验分享：在设计表的时候，我强烈建议不要建物理外键，就把customer_id这种当一个普通字段，然后通过索引来维护关联查询效率。原因有两条：一是物理外键在插入和删除时容易造成锁竞争和级联问题，在真实业务系统里开发规范一般都禁用；二是你将来做批量导入、数据修复时会非常痛苦。数据完整性由Service层代码和事务来保证就够了，这也是企业开发中的主流做法。
3.2 登录鉴权与权限控制：必须写透的两个机制
登录认证这块，别再用Session那一套了，面试会被问掉价的。现在主流做法是JWT无状态认证。流程上是这么走的：
用户输入账号密码，后端接收后把密码用BCrypt加密的密文跟数据库比对（密码绝不能明文存储，在实体类里也不要有getPassword直接返回这种危险操作），校验通过后，后端生成一个JWT Token，里面包含用户ID、用户名、角色，然后设置过期时间（一般是2到24小时），返回给前端。
前端拿到Token之后存起来，一般是存在localStorage或者sessionStorage，然后在axios请求拦截器里加上这样一段逻辑：
// axios拦截器 service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config })后端用拦截器统一解析请求头里的Token，校验有效之后放行。不需要校验的接口（登录、验证码）要加到白名单里面。关键接口还要做角色校验，比如只有管理员能删除客户、普通业务员只能看自己的客户数据。
具体实现时，SpringBoot上可以用一个简单的HandlerInterceptor来实现Token解析，也可以用Spring Security + JWT这套方案。如果毕设时间紧，我建议用拦截器手写一个轻量的认证流程，10分钟就能搞定，还不用被Spring Security的过滤器链绕晕。但如果你想让项目看起来更“专业”，那用Spring Security + JWT + RBAC（角色权限模型），数据表里增加sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu这五张表，把权限控制做成动态菜单，是非常加分的亮点。
这里给你一个最小可用的轻量认证拦截器代码参考：
@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } // 从header中取token String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); } // 校验token的逻辑... if (!StringUtils.hasText(token) || !JwtUtil.verify(token)) { response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录或登录已过期\"}"); return false; } return true; } }然后在WebMvcConfigurer里把拦截器注册进去，同时配置放行路径（如/api/auth/login、/api/auth/captcha、静态资源路径）。注意跨域问题也要在这里配置，前后端分离项目，前端地址是http://localhost:5173，后端是http://localhost:8080，不配跨域的话前端请求会被浏览器直接拦下来。
3.3 核心接口设计：统一返回体与状态码约定
接口设计这件事，很多人一开始不在意，等到前端联调的时候就哭了。你返回的数据格式一会儿是{data: [...], success: true}，一会儿又变成{rows: [...], code: 0}，前端同学真的会打人。所以我在项目里从第一天就约定一个统一的返回体结构：
@Data public class Result<T> { private Integer code; // 200成功 500失败 401未认证 private String msg; // 提示信息 private T data; // 响应数据 }成功时返回Result.success(data)，失败时返回Result.error(msg)，分页查询时返回Result.success(PageResult.of(list, total))。这样前端在axios响应拦截器里统一判断code === 200，非200统一弹错误提示，代码量能省出一大截。
接口路径的设计，我建议遵循RESTful风格，但也别把REST搞得太极致。比如/api/customer/list、/api/customer/{id}、/api/customer/save、/api/customer/delete/{id}这样的风格，通俗好懂，接手的同学一眼就明白。REST风格接口确实规范，但对于接口数量极多的内部管理系统，过度的REST约束反而会让开发效率变低，所以能在“规范”和“实用”之间找平衡才是真经验。
3.4 报表统计怎么用SQL和ECharts组合起来
报表模块在这个项目里是很重要的门面，答辩老师一定会看。贸易公司老板最关心的三个指标是：销售额趋势、应收款余额、客户分布。这三张图表你只要做出来，整个项目的业务完成度立刻就上去了。
销售额趋势怎么做？核心就是一条SQL语句配合日期函数。比如统计最近30天的每日销售额：
SELECT DATE(order_date) AS day, SUM(total_amount) AS amount FROM sales_order WHERE order_status != '已取消' AND order_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE(order_date) ORDER BY day;然后前端用ECharts画一个折线图。注意，在实际开发中日期别在前端算好再传给后端，直接在SQL里按数据库时间分组，这样时区问题、数据遗漏问题都能避免。
客户分布怎么做？按照客户等级、客户来源分组统计客户数量，用饼图展示。这个更简单，一条GROUP BY就能出来。前端ECharts的饼图组件拿来就画，不需要额外算法。
后端给前端返回的数据结构就直接是[{name: 'A级客户', value: 12}, {name: 'B级客户', value: 28}]这种，ECharts接收以后直接渲染。很多人卡在ECharts数据格式对不上，其实多写几个工具方法，把后端的统计列表转成前端可用的name/value结构，就能解决绝大多数问题。
4. 实操过程：从零搭建这个贸易行业CRM平台
4.1 环境和初始化：别在起步阶段浪费时间
先把环境准备好。这部分我非常建议按下面这个清单走，避免版本问题浪费时间：
- JDK 1.8或11（不要用JDK 17甚至21，除非你确定所有依赖都兼容）
- Maven 3.6以上（用来管理后端依赖）
- Node.js 16.x或18.x（前端构建工具链的基础）
- MySQL 8.0（数据库）
- IDEA（开发工具，社区版也足够用）
- Navicat或DataGrip（数据库可视化）
后端创建SpringBoot项目时，建议直接去Spring Initializr网站生成，依赖选择：Lombok、Spring Web、MyBatis Framework、MySQL Driver。注意别忘选Lombok，这个插件能帮你省掉一大堆getter/setter模板代码，但是注意正式生产项目里对于Lombok的使用要谨慎，这个你自己调研了解后会有自己的判断。
前端用Vite创建项目，命令如下：
npm create vite@latest crm-web -- --template vue cd crm-web npm install npm install vue-router@4 axios element-plus echarts npm run dev这里特别提醒一句，Element Plus在Vue3下不要用app.use(ElementPlus)全量引入的做法，看起来省事，但打包体积大、按需加载难配。建议在main.js里只全局注册常用组件，或者干脆在页面里按需引入。我当时图省事全量引入了，打包出来的JS超过1.5MB，加载页面要转好几圈，后来切成按需引入，体积降了差不多一半，体验立刻不一样。
4.2 后端核心代码落地：权限、客户、订单写给你看
我挑三个核心模块给你展示具体的落地写法，这三段代码如果你完全理解，整个项目八成以上的代码你都能照葫芦画瓢。
第一个，登录鉴权模块。用户登录成功后，我们需要做三件事：生成Token、把Token返回前端、把用户基本信息（不含密码）也一并返回。核心代码大概长这样：
@Service public class AuthService { @Autowired private SysUserMapper sysUserMapper; public Result<?> login(LoginDTO dto) { // 根据用户名查询用户 SysUser user = sysUserMapper.selectOne( new LambdaQueryWrapper<SysUser>() .eq(SysUser::getUsername, dto.getUsername())); // 用户不存在或密码错误 if (user == null || !BCryptUtil.matches(dto.getPassword(), user.getPassword())) { return Result.error("用户名或密码错误"); } // 用户被禁用 if (user.getStatus() == 0) { return Result.error("该账号已被禁用"); } // 生成JWT Token String token = JwtUtil.createToken(user.getId(), user.getUsername(), user.getRole()); // 返回登录结果 Map<String, Object> data = new HashMap<>(); data.put("token", token); data.put("userId", user.getId()); data.put("username", user.getUsername()); data.put("role", user.getRole()); return Result.success(data); } }这里注意一个容易踩的坑：前端密码传输最好先用MD5或SHA256加密一次再发到后端，后端再用BCrypt二次哈希。虽然HTTPS协议能解决传输层明文问题，但毕设环境往往没有证书，加一道前端摘要算法，也算是一个安全意识的体现，答辩时候能多聊几句。
第二个，客户管理模块。客户列表查询肯定要有多条件组合过滤（客户名模糊、客户等级、负责人、时间范围），还要分页。用MyBatis-Plus的LambdaQueryWrapper就能写得很简洁：
public PageResult<CustomerVO> pageQuery(CustomerQueryDTO query) { Page<Customer> page = new Page<>(query.getPageNum(), query.getPageSize()); LambdaQueryWrapper<Customer> wrapper = new LambdaQueryWrapper<>(); // 动态拼接查询条件 wrapper.like(StringUtils.hasText(query.getCustomerName()), Customer::getCustomerName, query.getCustomerName()) .eq(query.getCustomerLevel() != null, Customer::getCustomerLevel, query.getCustomerLevel()) .eq(query.getOwnerId() != null, Customer::getOwnerId, query.getOwnerId()) .orderByDesc(Customer::getCreateTime); // 分页查询 customerMapper.selectPage(page, wrapper); // 将entity转成vo返回，隐藏无关字段 List<CustomerVO> voList = page.getRecords().stream() .map(CustomerConvert.INSTANCE::toVO) .collect(Collectors.toList()); return PageResult.of(voList, page.getTotal()); }这个写法里最精髓的就是like和eq调用前的判断——前端传了那个条件就拼上，没传就跳过。这比你自己拼SQL字符串安全多了，能有效防止SQL注入。
第三个，订单创建模块。订单创建是典型的“一主多从”事务场景：插入订单主表记录，同时插入若干条订单明细，还要更新商品库存。这个必须用@Transactional保证原子性：
@Transactional(rollbackFor = Exception.class) public Result<?> createOrder(OrderDTO dto) { // 生成订单号，比如 yyyyMMddHHmmss + 4位随机数 String orderNo = generateOrderNo(); // 计算订单总金额 BigDecimal totalAmount = BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { BigDecimal subtotal = item.getUnitPrice() .multiply(new BigDecimal(item.getQuantity())); totalAmount = totalAmount.add(subtotal); } // 保存订单主表 SalesOrder order = new SalesOrder(); order.setOrderNo(orderNo); order.setCustomerId(dto.getCustomerId()); order.setTotalAmount(totalAmount); // ...省略其他字段set salesOrderMapper.insert(order); // 保存订单明细 + 扣减库存 for (OrderItemDTO item : dto.getItems()) { SalesOrderItem orderItem = new SalesOrderItem(); orderItem.setOrderId(order.getId()); orderItem.setProductId(item.getProductId()); orderItem.setQuantity(item.getQuantity()); // ...省略 salesOrderItemMapper.insert(orderItem); // 扣减库存 productMapper.reduceStock(item.getProductId(), item.getQuantity()); } return Result.success("下单成功", order.getId()); }这里有个特别重要的细节：计算金额时一个小数差都不能有，所以所有涉及金额的字段都必须是BigDecimal，千万不能直接用double或float。这也是面试官最爱问的经典题——“浮点数为什么不能用于金额”，我劝你认真理解一次，0.1 + 0.2 != 0.3这种经典问题在答辩时被问到的概率极高。
4.3 前端关键页面实现：登录页、客户管理页、订单页
前端页面我挑最有代表性的三个来说。
登录页比较常规，一个居中卡片，用户名、密码、登录按钮，调/api/auth/login接口，成功后存Token，然后router.push('/dashboard')。但要注意加一个简单的表单校验规则：用户名非空、密码长度至少6位。Element的表单校验组件用起来非常顺手，把rules定义好、在el-form上绑定即可。
客户管理页是后台系统里最典型的“表格+搜索+弹窗表单”结构。这个页面建议你写透，因为它几乎就是这套系统的模板页面。页面结构是：顶部搜索栏（客户名输入框、等级下拉框、搜索与重置按钮）、中间操作栏（新增、批量删除按钮）、主体表格（列定义+分页）、弹窗表单（新增和编辑共用一个对话框）。
当选中一行客户点击编辑时，代码大致如此：
<el-dialog v-model="dialogVisible" :title="title" width="600px"> <el-form ref="formRef" :model="formData" :rules="formRules" label-width="100px"> <el-form-item label="客户名称" prop="customerName"> <el-input v-model="formData.customerName" placeholder="请输入客户名称" /> </el-form-item> <!-- 其他表单项 --> </el-form> <template #footer> <el-button @click="dialogVisible = false">取消</el-button> <el-button type="primary" @click="handleSubmit">保存</el-button> </template> </el-dialog>保存按钮的回调方法是：formRef.validate()校验通过后，判断是新增还是编辑（通过formData.id是否为空），然后调用对应的API，操作成功后刷新表格、关闭弹窗。这个套路在客户、供应商、商品、订单四个页面里通用，写熟了以后整个系统就是复制粘贴改字段。
订单页相对复杂，因为它有明细行、商品选择和金额合计。我的建议是订单表单用动态表格来录入明细，每一行可以选商品、填数量、自动计算小计；当商品或数量变化时，重新计算总金额。这块逻辑用Vue的watch或计算属性就能做到：
const calculateTotal = () => { const total = orderItems.value.reduce((sum, item) => { return sum + Number(item.unitPrice) * Number(item.quantity) }, 0) totalAmount.value = total.toFixed(2) }把calculateTotal绑定到明细行的change事件上，顾客选商品、改数量、填价格都会触发重算，体验会非常流畅。订单列表页设置状态列（草稿/已确认/已完成/已取消）以及“确认订单”的按钮操作，确认之后库存扣减，这就是业务状态机的体现。
4.4 部署与上线：从本地跑通到服务器发布
开发阶段本地跑通之后，最终还是要弄一个演示环境出来，方便答辩时老师访问。部署方案最省事的是用Docker Compose，把nginx、mysql、springboot应用三个容器编排起来。
前端构建产物放在Nginx的html目录，Nginx配置里把/api开头的请求反向代理到SpringBoot应用，这样浏览器访问的始终是同一个域名，既避免了跨域问题，又符合生产环境真实做法。核心Nginx配置片段如下：
server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; # 解决Vue路由刷新404问题 } location /api/ { proxy_pass http://crm-server:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这个try_files指令是整个部署里最容易踩的坑：不加上它，Vue项目在路由深链路刷新页面时就会出现404。解释一下原因：前端路由切换是走history模式的，刷新时浏览器按URL找后端资源，后端自然找不到/customer/list这个路径，于是用try_files把所有路径都回退到index.html，让Vue Router接管后再自己路由渲染。
SpringBoot的Dockerfile非常简单：
FROM openjdk:8-jre-alpine WORKDIR /app COPY target/crm-server.jar crm-server.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "crm-server.jar", "--spring.profiles.active=prod"]然后把application-prod.yml里的数据库地址从localhost改成mysql-container这个Docker容器名，SpringBoot就能在容器内部网络里正确连接数据库了。这里如果你自己测试时不熟悉Docker网络配置，也可以直接用docker run -p 3306:3306 -p 8080:8080把容器端口暴露给宿主机，让两条链路都走宿主机的localhost，能省掉不少排查时间。
5. 常见问题与排查技巧：我实测踩过的坑
5.1 前端常见问题速查
前端的问题注定比后端多，因为JavaScript的报错信息往往不够直白。我挑几个高频问题列一下排查思路：
问题一：前端点击登录按钮一片空白，控制台报CORS错误。
这几乎是100%的前后端联调第一坑。根源是后端没有允许前端源域的跨域访问。解决方法是后端加一个全局跨域配置：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }但要注意：如果你引入了Spring Security或JWT拦截器，这种配置往往还不够，因为浏览器会先发送一个OPTIONS预检请求，这个请求不会带Token头。所以拦截器代码里必须放行OPTIONS请求，并且CORS配置和拦截器要共同作用。我见过有人在拦截器卡了整整一天的案例，就是因为预检请求被拦截了。
问题二：刷新页面就404。
这个就是我在部署章节里讲过的try_files问题。如果你在本地开发环境用Vite，没有这个问题，因为Vite开发服务器自己处理了history回退；但一旦build完丢到Nginx、Tomcat或后端static目录里跑，就会炸。除Nginx配置外，如果你是把前端构建产物放SpringBoot的resources/static里部署，那么还要保证后端路由跟前端history路由不冲突，最稳妥的做法是生产环境全走Nginx。
问题三：ECharts图表不显示，控制台提示Cannot read property 'xxx' of undefined。
这种错误绝大多数是数据格式问题。检查后端返回的数据字段名和前端ECharts配置的字段名是否一致。比如后端返回了{day: '2025-01-01', amount: 100}，前端ECharts用的字段却是date和value，那自然显示不出来。调试技巧是先在浏览器console.log打印接口原始数据，确认字段结构再写映射，这是最快的排查路径。
5.2 后端常见问题速查
问题一：数据库连接失败，报Access denied for user 'root'@'localhost'。
这个绝大多数情况是密码不对，或者用户没有授权。MySQL8默认的认证插件是caching_sha2_password，如果你的JDBC驱动版本较老，会出现认证不通过。排查思路：确认驱动版本（8.0.33以上的mysql-connector-java应该都没问题）、确认用户名密码、确认有远程授权（如果是Docker或远程主机部署，需要GRANT ALL ON crm_db.* TO 'root'@'%';）。
问题二：接口返回了404，但Controller里明明写了映射。
排查顺序：启动类能不能扫描到Controller包（@SpringBootApplication的包路径是否覆盖了controller包）、Controller类上的@RequestMapping路径和方法的路径是否拼接错误、项目是否成功编译并重启了。我见过最冤的案例是IDEA没有自动编译，代码改了但运行的还是旧class文件。在Maven项目里执行mvn clean package，再启动就能排除这个问题。
问题三：分页查询的数据总是重复或缺失。
先检查MyBatis-Plus的分页插件是否配置了PaginationInnerInterceptor。很多人只引入了MyBatis-Plus但没配拦截器，导致Page对象被全表查询后再内存截断，看起来分页是生效了，实际上每页都重新查了全表，不仅慢，而且结果不对。另外一个坑是排序字段没建立索引，数据量大以后分页页深了会非常慢。给order_no、create_time这些常用排序字段补上索引，性能立即改善。
5.3 两个值得分享的高级排查技巧
技巧一：启用MyBatis SQL日志输出。
在application.yml里加上：
logging: level: com.example.crm.mapper: debug这样跑起来以后控制台会打印Mapper执行的具体SQL和参数，排查SQL拼接错误、数据过滤不对这类问题效率翻倍。这个方法我几乎每天都会开，你可以在开发环境长期开着，对性能影响几乎可以忽略。
技巧二：前端统一错误提示但静默处理特定错误。
在axios响应拦截器里，你可以统一拦截401、403、500等错误码，分别做跳转登录页、提示权限不足、弹通用错误。但要注意，某些业务场景下后端会返回一个业务错误码，你并不想弹全局错误提示。这时候可以在业务代码里用catch自行处理，或者在后端返回对象里设计一个code字段来区分系统异常和业务校验失败，前端在拦截器里只处理系统级别的错误，业务错误统一回到业务代码里处理。
6. 扩展思路：这个CRM项目还能怎么往上长
很多做完线上毕业设计就想交差的同学其实错过了项目真正增值的机会。我个人经验是，既然代码已经成型、框架已经跑通，再往上叠加几个亮点，不管是答辩还是将来写简历，性价比都非常高。这里我分享几个亲测可行的扩展方向。
第一个是引入数据权限功能。当前系统的权限多是“菜单权限”，也就是能看哪些页面，但“数据权限”这种更细的权限——比如业务员只能看到自己名下的客户数据，经理能看到整个部门的客户数据——往往会成为评分亮点。实现思路也不复杂，在查询客户列表时根据当前用户角色动态拼SQL条件，管理员不加条件、经理查本部门、业务员只查owner_id = 当前用户ID。这样既不需要改表结构，也不需要动前端，后端一个条件判断就能完成，但是说出来却很让人信服，因为涉及了真实的业务边界。
第二个是导出功能。贸易行业的CRM，客户清单、订单明细、回款流水，都是要导Excel的。后端用EasyExcel或Poi工具，前端放一个“导出”按钮，调用后端的导出接口，生成Excel文件流返回给前端下载。这算是一个所有管理系统都会用到的功能，写一遍代码，所有列表页都能复用，性价比极高。
第三个是仪表盘首页。做一个带统计卡片（今日销售额、本月订单数、累计客户数、待回款金额）和销售趋势折线图、客户等级饼图的首页。这个模块需要写3到5个统计SQL，前端用ECharts组合展示。做完以后整个系统立刻就有了“商业智能”的味道，答辩演示时打开系统的第一屏就很抓人。
第四个是操作日志记录。用Spring AOP做一个自定义注解@OperationLog，标注在需要记录操作的Controller方法上，通过切面把操作人、操作时间、操作类型、操作详情写入日志表。这个功能代码量不大，模型又很清晰——AOP的概念、注解的定义、反射的运用全都能体现出来，面试聊起来也有深度。
我个人实际做的顺序建议是：先加仪表盘统计，再做数据权限，然后是Excel导出，最后有空再加操作日志。这样每加一个功能，系统看起来的“完整度”都会肉眼可见地提升一截，而且这四个方向都是在现有基础上改进，不需要推翻重来。
另一个值得做的工程化改进是把项目从单体拆出模块化结构，比如在Maven里划分成crm-common、crm-system、crm-business、crm-report这几个子模块。虽然实际的代码运行逻辑还是同一个SpringBoot应用，但工程结构清晰之后，无论是你自己代码组织还是答辩讲项目架构，都好说很多。注意，过度拆模块也会引入复杂性，所以我的经验是，在这个量级的毕设项目里，先保证包名和目录合理，比强行拆Maven多模块更重要。
7. 最后留几句实话：做完这个项目，我切身的体会和心得
如果你看完前面内容打算照着做一个，我再根据自己的实际经验，提炼几条最有价值的建议，能帮你少走弯路。
第一条，拿到题目先花三到五天做需求拆解和数据表设计，代码晚一个星期写完全来得及，但表结构一旦定错，返工成本是成倍的。我见过太多人当天就开始敲代码，然后做到订单模块发现客户表里没邮箱、没等级、没负责人，最后只能一边敲代码一边改表，越改越崩溃。可以先在纸上画一遍页面原型，列清楚每个页面要展示什么字段、要做什么操作，再反推数据库表结构，这个习惯能让你后面所有功能开发都是顺水推舟的状态。
第二条，有疑问就多跟有经验的人交流思路，不要卡在某个技术上死磕。比如你觉得登录鉴权很难，去看看成熟的通用权限开源项目是怎么做的；你觉得前端表格做起来太繁，去了解一下组件库里的el-table的属性和插槽，很多细节文档里都有。编程这东西，经验可以靠踩坑积累，但更重要的是学会一条路径最短的方法论：先跑通最小闭环，再优化细节。
第三条，答辩或者面试的时候，多讲“为什么这么做”，而不是“做了什么”。老师问“为什么客户表和订单表不建外键”，你说“避免级联删除的隐患、减少写入锁竞争、数据完整性由服务层保证”，比你说“我用MyBatis所以没建”要强得多。多讲业务理解，少背八股文，这是我从多次评审经历中得到的心得。
做这类管理系统，最大的收获其实不是CRUD本身，而是你开始理解一套业务系统是怎么从需求变成数据的、数据怎么流转成页面上的信息、角色权限如何影响每一次查询。这个过程对刚入行的同学来说是特别有价值的一次完整演练。希望这篇文章能让你少走一点弯路，更顺利地把自己的CRM平台做出来。
