企业官网建设流程全解析

简介：这是一套基于Java与SSM框架（Spring、SpringMVC、MyBatis）实现的人事管理OA办公系统毕业设计项目，面向计算机相关专业的学生、老师及初期开发者，适用于毕业设计、课程设计、项目立项演示或进阶学习。源码已通过导师指导与答辩评审，且已在macOS及Windows 10/11环境下完成运行测试，功能稳定，可在此基础上继续扩展。压缩包共286个文件，主要包含Java源码、JSP页面、XML配置、数据库SQL脚本、前端CSS/JS与图片字体等资源，整体约18MB，目录结构清晰，便于快速定位核心代码、配置文件与数据脚本。项目覆盖员工考勤、部门排班、通知公告等典型OA模块，并配套使用文档与数据库文件，可直接用于系统演示、二次开发或毕业设计论文撰写参考。目前已有109人学习或下载，适合需要完整项目源码和有关资料的高校学生与开发者参考使用。

1. 基于 Java + SSM 的人事 OA 系统：从 class 文件反推出整套设计

我拆这份资源的时候，第一件事不是看 README，而是先看了压缩包里那一串UserExample$GeneratedCriteria.class、AttendanceExample$GeneratedCriteria.class这样的编译产物。看到这些类名，基本就能断定：这是一个标准的 SSM 分层项目，而且持久层用了 MyBatis Generator 自动生成的 Example 查询体系。换句话说，这不是随手拼的 CRUD demo，而是一套包含用户、部门、考勤、排班、公告、项目六大模块的完整 OA 系统，代码结构是能扛住答辩追问的。

这份资源适合三类人：一是计算机相关专业要做毕业设计或课程设计的学生，拿到的是一套能直接跑、能讲清原理的完整源码；二是初学 SSM 框架的开发者，想找一个真实业务场景来对照学习 Spring、SpringMVC、MyBatis 是怎么协作的；三是想快速搭一套人事管理演示系统的从业者，改改页面和数据就能当项目初稿。它解决的问题很朴素：把考勤记录、排班发布、公告管理、项目进度这些 OA 里最常问的业务，用最典型的 SSM 三层架构串起来，数据库脚本、使用文档、源码都在一个压缩包里，落地成本很低。

2. SSM 三大框架的分工与整合顺序：先把依赖关系搞明白再动代码

拆这种 SSM 项目，最容易翻车的地方不是业务代码，而是框架整合的配置文件。很多人拿到源码第一件事就是跑，结果 Tomcat 一启动就报 bean 创建异常，然后开始怀疑人生。其实 SSM 整合有一套固定的依赖顺序，理解了这个顺序，后面所有报错都能顺着线索查。

2.1 三层架构的数据流：请求从 Controller 到 Mapper 的完整链路

这套人事 OA 系统是典型的 SSM 三层架构：表现层是 SpringMVC 的 Controller，业务层是 Service 接口加实现类，持久层是 MyBatis 的 Mapper 接口加 XML 映射文件。从压缩包的 class 文件名能看出来，IndexController、AttendanceExample、DeptScheduleExample这些类分别对应了登录入口、考勤模块、部门排班模块，结构非常清晰。

一个典型请求的流转过程是这样的：浏览器发请求到 Tomcat，DispatcherServlet 根据@RequestMapping找到对应的 Controller 方法；Controller 里注入 Service 接口，Service 实现类里注入 Mapper 接口；Mapper 接口的方法名和 XML 里的<select>、<insert>语句绑定。这里注意，MyBatis 的 Mapper 接口是只有一个空方法的 Java 接口，真正的 SQL 全在 XML 里，这就是为什么很多新手在 Controller 里明明调用了方法，却总是报Invalid bound statement (not found)——多半是 XML 没被扫描到，或者 namespace 写错了。

这套项目在业务层做得比较规矩的地方在于：每个模块的 Service 接口和实现类是分开的，例如考勤模块就是AttendanceService和AttendanceServiceImpl。这样做的好处是答辩的时候你可以直接说"我用的是面向接口编程，方便后续替换实现类"，这句话在毕业设计答辩里非常加分。

2.2 配置文件加载顺序：applicationContext.xml 与 spring-mvc.xml 谁先谁后

SSM 整合有四个核心配置文件：web.xml、applicationContext.xml（Spring 根容器）、spring-mvc.xml（SpringMVC 子容器）、mybatis-config.xml（MyBatis 全局配置）。加载顺序由web.xml里的配置决定，Spring 根容器先启动，SpringMVC 子容器后启动，子容器可以拿父容器的 bean，反过来不行。

<!-- web.xml 中的关键配置片段 --> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <servlet> <servlet-name>dispatcherServlet</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>

逻辑说明：ContextLoaderListener负责创建 Spring 根容器，加载applicationContext.xml，这里面通常放着数据源、SqlSessionFactory、事务管理器、Service 层的 bean。DispatcherServlet 的contextConfigLocation指向spring-mvc.xml，里面放着 Controller 扫描、视图解析器、静态资源映射。

参数说明：load-on-startup的1表示 Tomcat 启动时就初始化 DispatcherServlet，如果你是 0 或者不配，那要等第一个请求进来才创建容器，很多"第一次访问特别慢甚至超时"的问题就是这个参数引起的。

注意一个典型的坑：如果spring-mvc.xml里把@Service、@Repository这些注解也扫了，会导致 Service 层的 bean 被创建两次，事务注解有时候会失效。常见做法是applicationContext.xml只扫 service 和 dao，spring-mvc.xml只扫 controller。

2.3 mybatis-config.xml 与 Mapper 注册：让 XML 映射文件被容器发现

MyBatis 的全局配置里最核心的是别名校验、下划线转驼峰、以及 Mapper 文件的位置。很多 SSM 项目跑不起来，就是死在这一步。

<!-- mybatis-config.xml 核心配置 --> <configuration> <settings> <setting name="mapUnderscoreToCamelCase" value="true"/> <setting name="logImpl" value="STDOUT_LOGGING"/> </settings> <typeAliases> <package name="com.example.entity"/> </typeAliases> </configuration>

逻辑说明：mapUnderscoreToCamelCase设为 true 之后，数据库字段dept_name就能自动映射到实体类的deptName属性，不用手动写resultMap的每个字段映射，这是懒人福音，也是很多人忽略了导致查出来全是 null 的元凶。logImpl用STDOUT_LOGGING可以把 SQL 打印到控制台，我调试这类项目必开。

这里要强调 Mapper 的注册方式。在applicationContext.xml里配置MapperScannerConfigurer时，basePackage要填 Mapper 接口所在的包，同时 SqlSessionFactoryBean 的mapperLocations要指到 XML 文件的路径：

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="configLocation" value="classpath:mybatis-config.xml"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean>

如果mapperLocations写的是classpath:mapper/*.xml，那 XML 必须放在 resources 编译后的 classpath 根目录下。很多 IDEA 用户把 XML 放在了src/main/java目录下面，没有在 build 配置里加上资源编译，结果运行时 Mapper 接口找到了，XML 却不在 classpath 里，直接报绑定异常。血泪经验是：先看 target/classes 目录里有没有 mapper 文件夹，没有就说明资源没编译进去。

3. 核心业务模块与数据库设计：从 Example 类名反推表结构和业务关系

这份资源的 class 文件名相当于项目的目录索引，UserExample、DeptExample、AttendanceExample、DeptScheduleExample、UserScheduleExample、ProjectExample、NewsExample对应了七个核心实体。我反推表设计的时候发现，模块之间的关联关系完全是照着真实 OA 场景做的，不是随便堆几个表。

3.1 用户与部门：一对多关系与乐观锁字段设计

用户表和部门表是这套系统的基础表。用户属于某个部门，一个部门下有多个用户，这是最典型的一对多。

CREATE TABLE `t_dept` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `dept_name` VARCHAR(50) NOT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `t_user` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `dept_id` INT NOT NULL, `username` VARCHAR(50) NOT NULL UNIQUE, `password` VARCHAR(64) NOT NULL, `real_name` VARCHAR(30), `role` TINYINT DEFAULT 0, `version` INT DEFAULT 1, CONSTRAINT `fk_user_dept` FOREIGN KEY (`dept_id`) REFERENCES `t_dept`(`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逻辑说明：t_dept是部门表，t_user是用户表，通过dept_id外键关联。role字段用 TINYINT 区分管理员和普通员工，0 是普通员工，1 是管理员。version字段是乐观锁标记，每次更新用户信息时 version 加 1，通过WHERE version = #{oldVersion}来防止并发修改覆盖，这在答辩时可以讲成"我考虑了并发安全"。

参数说明：密码字段建议存VARCHAR(64)，因为 MD5 加密输出是 32 位，加盐后一般是 40 或 64 位。如果你看到的数据库脚本里密码是明文，那记得改一下，在 Service 层加一层 MD5 或 SHA-256 的加密，这在毕业设计里是安全性的加分项。

3.2 考勤模块：Attendance 表的状态字段与判定逻辑

考勤是 OA 系统里最常被问到的业务模块。从AttendanceExample$GeneratedCriteria.class可以看出，这个模块是独立的一张表，字段设计上应该包含用户、日期、上班打卡时间、下班打卡时间、考勤状态。

CREATE TABLE `t_attendance` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `user_id` INT NOT NULL, `work_date` DATE NOT NULL, `check_in` DATETIME, `check_out` DATETIME, `status` TINYINT DEFAULT 0, `remark` VARCHAR(255), UNIQUE KEY `uk_user_date` (`user_id`, `work_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逻辑说明：work_date存日期，check_in和check_out存具体的打卡时间。status字段是关键：0 正常、1 迟到、2 早退、3 缺卡。这里UNIQUE KEY uk_user_date是核心，它保证了同一个用户同一天只能有一条考勤记录，程序里插入前先查当天是否已有记录，有则执行更新而不是再插一条。

异常逻辑的常见实现是：假设上班时间是 9 点，判断check_in是否晚于当天 9 点，如果晚于就更新状态为迟到。这里要注意，work_date用 DATE 类型、check_in用 DATETIME，比较的时候用TIME(check_in) > '09:00:00'，而不是拿字符串比，否则8:59会被错误判定为迟到。

3.3 排班模块：DeptSchedule 与 UserSchedule 的发布和认领逻辑

排班模块分了两张表，部门排班（DeptSchedule）和个人排班（UserSchedule），这个设计很有意思。部门排班是管理员发布的公共班次，个人排班是员工从部门排班中认领或管理员指派后的结果，相当于一个是模板，一个是实例。

CREATE TABLE `t_dept_schedule` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `dept_id` INT NOT NULL, `schedule_date` DATE NOT NULL, `shift_name` VARCHAR(20), `start_time` TIME, `end_time` TIME, `publisher_id` INT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `t_user_schedule` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `dept_schedule_id` INT NOT NULL, `user_id` INT NOT NULL, `status` TINYINT DEFAULT 0, UNIQUE KEY `uk_schedule_user` (`dept_schedule_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逻辑说明：t_dept_schedule存的是某天某个部门的排班计划，例如"2025-05-20 早班 08:00-16:00"。t_user_schedule是这个计划的执行情况——哪位员工被安排在这个班次。status字段标识是否已确认。

这套设计最实用的地方在于：拿t_dept_schedule的start_time和考勤表的check_in做比对，就能自动算出员工当天是否迟到，而不是写死在代码里每天几点上班。我在实际项目里就是这样干的——排班表是考勤判断的依据，考勤记录直接关联当天的排班时间，改动班次时间不用重编译代码。

3.4 公告与项目模块：News 和 Project 的 CRUD 权限设计

公告和项目的表结构相对简单，重点在权限控制。从 class 文件看，News 和 Project 都是独立的 Mapper，这意味着它们的增删改查都是独立操作。

CREATE TABLE `t_news` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(100) NOT NULL, `content` TEXT, `publisher_id` INT, `publish_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `t_project` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `project_name` VARCHAR(100) NOT NULL, `owner_id` INT, `progress` TINYINT DEFAULT 0, `deadline` DATE, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

权限这块，常见做法是在 Service 层做判断：管理员角色（role=1）可以发布公告、创建项目、修改所有排班；普通员工（role=0）只能查看和更新自己的信息。判断逻辑通常在调用 Mapper 之前用当前登录用户的 role 做一次校验，而不是把role当成参数传到 SQL 里——后者容易被接口直接调用绕过。

4. 数据库脚本导入与 IDEA 本地部署：从零到跑通全流程

拿到压缩包后，最快的验证方式是先不碰代码，按"导库 → 改配置 → 部署"三步走。这套流程我跑了不下几十次，把稳定的路径和参数讲清楚。

4.1 导入 SQL 并配置数据源：连接池参数的几个关键细节

压缩包里的数据脚本一般叫oa_system.sql或db_oa.sql，直接在 Navicat 或命令行导入即可。导入后确认库名，然后改 JDBC 配置。

# jdbc.properties jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/oa_system?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=123456

逻辑说明：数据库连接池这里用的是 Spring 的DriverManagerDataSource或 dbcp，具体看applicationContext.xml里的 bean 定义。characterEncoding=UTF-8解决中文乱码，serverTimezone=Asia/Shanghai解决 MySQL 8.0 以上的时区报错——如果这里不写时区，启动时会直接抛The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，排查成本极高。

参数说明：数据库名要和你本地建的一致，密码改成自己的。如果用的是 MySQL 5.7，驱动可以换回com.mysql.jdbc.Driver，但如果你没换，用com.mysql.cj.jdbc.Driver也一样能跑，兼容性没问题。

4.2 IDEA 配置 Tomcat：Artifact 与部署上下文的正确姿势

这一步是新手重灾区。很多人用 IDEA 的 Community 版，没有 Tomcat 集成，或者 Artifact 类型选错，导致启动后访问 404。

# 部署后的访问路径示例 # 上下文路径为 /oa_system 时 http://localhost:8080/oa_system/login # 上下文路径为 / 时 http://localhost:8080/login

逻辑说明：IDEA 里配置 Tomcat 时，Deployment 选项卡里要添加 Artifact。如果是 war exploded 模式，Application context 建议先设成/oa_system，跑通后再改成/让项目作为根路径访问。改根路径有个风险：如果项目里用了${pageContext.request.contextPath}拼静态资源路径，那没问题；如果是硬编码/oa_system/，改成根路径后样式全丢。

参数说明：服务器端口默认 8080，如果被占用可以改成 8081 或 8082，改完要记得访问 URL 也同步改。JRE 版本建议用 JDK 8 或 JDK 11，SSM 项目用太高版本的 JDK 偶尔会遇到 javassist 或 cglib 兼容问题。

4.3 初始化管理员账号：登录验证的完整闭环

数据脚本里通常会初始化一个管理员账号，常见的是admin / admin123或admin / 123456。登录逻辑在IndexController里，从 class 文件名看，它承担了登录认证和首页跳转的双重职责。

// IndexController 中登录验证的核心逻辑 @Controller public class IndexController { @Autowired private UserService userService; @RequestMapping("/login") public String login(String username, String password, HttpSession session, Model model) { User user = userService.login(username, password); if (user == null) { model.addAttribute("msg", "用户名或密码错误"); return "login"; } session.setAttribute("loginUser", user); return "redirect:/index"; } }

逻辑说明：登录成功把用户对象放进 session，后续所有页面通过 session 里的loginUser判断是否已登录。注意这里返回的是redirect:/index而不是直接返回视图名，这样做的好处是刷新页面时不会重复提交登录表单。

参数说明：如果登录失败，model.addAttribute("msg", ...)把错误信息带到 JSP 页面。JSP 里用${msg}或<c:out>输出。注意检查密码是否是 MD5 加密后存储的，如果是，Service 层的login方法里应该有DigestUtils.md5DigestAsHex(password.getBytes())这一步，没有的话数据库里的密文没法匹配。

5. SSM 毕设项目常见踩坑与排查清单：五条最常遇到的报错

这类 SSM 项目我前后帮人排查过不少，遇到的问题高度重复。列五条最典型的，每条按"现象 → 原因 → 解决"记录，对照排查能省很多时间。

5.1 启动报 ClassNotFoundException 或 NoClassDefFoundError

现象：Tomcat 启动时抛java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener。

原因：IDEA 里 Artifact 打包时没有把依赖的 jar 包带进 WEB-INF/lib。常见于用 Maven 构建但 Tomcat 部署的是旧的 Artifact，或手动导入 jar 的项目漏了依赖目录。

解决：打开 Project Structure → Artifacts，选中输出目录为空的依赖项，右键选择 "Put into WEB-INF/lib"。如果是 Maven 项目，先执行mvn clean package重新构建 war，再部署。部署前检查target/oa_system/WEB-INF/lib目录下是否有 spring-web、mybatis-spring 等核心 jar。

5.2 登录成功后跳转 404

现象：登录页正常，提交账号密码后地址栏变成了/index，但页面显示 404，控制台无任何异常输出。

原因：SpringMVC 的视图解析器配了前缀/WEB-INF/views/，但 JSP 文件不在此目录下，或 DispatcherServlet 的url-pattern配成了/，把所有请求包括 JSP 都拦截了。

解决：先看spring-mvc.xml里的 InternalResourceViewResolver 配置，确认前缀目录和实际 JSP 位置一致。再看web.xml里 servlet-mapping，如果配了/，需要在 spring-mvc.xml 里加<mvc:default-servlet-handler/>，让静态资源和 JSP 能正常访问。

5.3 页面上中文全是问号或乱码

现象：登录后页面显示中文乱码，姓名变成????，或者数据库里存的中文变成乱码。

原因：三个层面的编码不统一——JSP 页面编码、数据库连接编码、数据库表编码。最常见的是jdbc:mysql://...没加characterEncoding=UTF-8，或数据表创建时DEFAULT CHARSET不是utf8mb4。

解决：三处统一。JSP 顶部加pageEncoding="UTF-8"；JDBC 连接串加useUnicode=true&characterEncoding=UTF-8；已建的库表执行ALTER TABLE t_user CONVERT TO CHARACTER SET utf8mb4;修复。乱码问题排查优先级永远是连接串优先，因为代码层面的编码问题通常在编译期就暴露了。

5.4 上下文路径问题导致静态资源 404

现象：页面能打开但 CSS、JS、图片全部加载失败，F12 看全是 404，或者登录后跳转到一个不存在的页面。

原因：JSP 里用了绝对路径（如/static/css/style.css）但项目部署的上下文路径不是根路径，导致路径拼成了/css/style.css或项目名/static/...对不上。

解决：统一在 JSP 里用<c:url>或${pageContext.request.contextPath}拼路径，例如${pageContext.request.contextPath}/static/css/style.css。或者干脆把 Tomcat 部署的 Application context 改成/，让项目作为根路径运行，但注意 5.2 里提到的 DispatcherServlet 拦截问题要一起处理。

5.5 Mapper 报 Invalid bound statement (not found)

现象：调用UserMapper.selectByExample(example)时抛org.apache.ibatis.binding.BindingException: Invalid bound statement (not found)。

原因：Mapper 接口编译进了 classpath，但对应的 XML 映射文件没有。通常是 XML 放在了src/main/java目录下，IDEA 默认只编译.java文件，XML 没被复制到target/classes。

解决：在pom.xml的 build 节点加资源编译配置：

<build> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> <resource> <directory>src/main/resources</directory> </resource> </resources> </build>

逻辑说明：第一个 resource 把src/main/java下的 XML 也打进 classpath，第二个 resource 正常编译 resources 目录。配完后重新mvn clean，再启动看target/classes下有没有生成 mapper 的 XML 文件。另外也检查一下 XML 里namespace是否和 Mapper 接口全限定名一致，这个错更隐蔽，因为运行时不会报 namespace 错误，只报 statement 找不到。

6. 把这份毕设改成自己的：逆向工程与二次开发的三个技巧

资源里带的使用文档对项目结构和启动流程已经讲得比较细了。当你把整套系统跑通之后，下一步就是往里面加自己的东西。这里分享三个我用得最多的改造技巧。

第一个技巧是用 MyBatis Generator 重新生成实体和 Example 类。压缩包里已经有UserExample、DeptExample这套东西，说明之前就是用 MBG 生成的。你在generatorConfig.xml里改数据库连接和表名，重新跑mvn mybatis-generator:generate，新的Example类就会覆盖旧文件。生成后注意把selectByExample返回的Criteria对象用起来，它是非常灵活的查询构造器，createCriteria().andDeptIdEqualTo(3)这样的链式调用能省掉大量手写 SQL，答辩时讲这个也很加分。

第二个技巧是给考勤模块加一个"迟到自动判定"。原项目里的判定逻辑通常是写死在 Service 层，我一般会在AttendanceServiceImpl里加一个validateCheckIn方法，在打卡时调用t_user_schedule和t_dept_schedule，拿到当天班次的start_time，和当前时间做比对：

public void handleCheckIn(Integer userId) { Date now = new Date(); DeptSchedule schedule = deptScheduleMapper.selectTodayByUser(userId); if (schedule != null && now.after(schedule.getStartTime())) { Attendance attendance = new Attendance(); attendance.setUserId(userId); attendance.setWorkDate(new java.sql.Date(now.getTime())); attendance.setStatus((byte) 1); // 1 表示迟到 attendanceMapper.insert(attendance); } }

逻辑说明：selectTodayByUser先查当天该员工被安排的班次，拿到startTime后和当前时间比较。这里的时间比较不再依赖字符串，而是直接用java.util.Date的after方法，避免8:59和09:00字符串比较出错。参数说明：状态 1 是迟到，如果要区分早退和缺卡，可以在打卡接口分别判断。

第三个技巧是换连接池。原项目大概率用的 Spring 自带的DriverManagerDataSource，开发环境够用，但如果你在答辩演示时遇到"连续点刷新页面偶发超时"，那多半就是连接没复用。把数据源换成 Druid，只需要在applicationContext.xml改一处 bean 定义：

<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> <property name="initialSize" value="5"/> <property name="maxActive" value="20"/> </bean>

这些改造做完，项目就不是原封不动的毕设了——表结构是原来的，但查询逻辑、业务判断、连接管理都有自己的痕迹。从那以后我拿到任何 SSM 源码，都强制自己先走一遍"导库 → 看配置依赖 → 改连接串 → 加日志 → 跑通后再动业务"的流程，因为顺序反了，你根本分不清是框架问题还是业务问题。希望这些拆解和踩坑记录帮到你。

本文还有配套的精品资源，点击获取