简介这是一套面向Java中高级开发者与架构学习者的领域驱动设计DDD实战源码聚焦企业级请假审批业务场景帮助读者深入理解复杂业务建模与分层架构落地。资源以Spring Boot为技术底座完整实现聚合根、值对象、领域服务、仓储接口、领域事件及CQRS读写分离等核心DDD模式并通过模块化设计如leave-domain、leave-restapi、leave-infrastructure-db等清晰子模块展现限界上下文划分实践。压缩包共40个文件含27个Java业务与配置类、5个XML配置文件用于MyBatis映射与Maven构建、5张PNG流程图与界面示意、1个CSV测试数据样本整体大小2.66MB结构规范便于逐层研读与二次开发。已有145人下载学习可直接运行调试获取从领域建模到REST API暴露的全链路DDD编码范式、模块职责边界定义方法及事件驱动审批流程的代码实现细节。1. 这不是又一个CRUD管理系统——它是一次对“业务语义”真实建模的实践你点开这个压缩包看到的不只是几十个Java类文件和一堆Spring Boot配置而是一套试图把“请假”这件事真正说清楚的代码。它不叫“LeaveController”“LeaveService”“LeaveMapper”它叫ApplicationService、LeaveRequest、ApprovalPolicy、WorkdayCalendar——这些名字背后没有“增删改查”的影子只有业务里真实存在的角色、规则、边界和约束。我带团队落地过7个中大型审批类系统从OA到HR SaaS踩过最深的坑从来不是技术选型而是把“领导审批”硬塞进三层架构的Service层结果改一条加签逻辑要动5个模块、测3天、上线后漏掉周末计算——而DDD在这里做的第一件事就是让“周末不算工作日”这个常识变成代码里一个可验证、可复用、可独立测试的领域对象而不是写在if语句里的魔法数字。这个源码包的核心价值根本不在“用了Spring Boot”或“集成了MyBatis”而在于它用Java语言把“请假”这个日常行为拆解成战略设计层的限界上下文划分如“考勤上下文”与“组织架构上下文”的明确隔离、战术设计层的聚合根一致性边界比如LeaveRequest聚合内强制校验“开始时间不能晚于结束时间”且“总时长不能超年度额度”、以及领域模型与数据库表结构的非对称映射一个LeaveRequest实体可能对应3张物理表但对外只暴露一个业务概念。它解决的不是“怎么存数据”而是“怎么让代码像业务人员一样思考”。如果你正被“需求一变全盘重构”折磨或者面试官问你“DDD里聚合根和DTO的区别”时只能背定义——这个项目就是你该亲手跑起来、打断点、改一行业务规则再验证效果的沙盒。它适合两类人一是想跳出CRUD思维、真正理解“软件是业务的镜像”的中级Java开发者二是正在设计审批流、报销流、合同审批等强业务规则系统的架构师或技术负责人——因为这里没有抽象理论只有“年假余额扣减失败时如何回滚已生成的审批节点”这种真实问题的代码解法。2. 为什么非得用DDD——当“请假”不再只是“提交一个表单”2.1 传统分层架构在审批场景下的三重失真我见过太多基于经典MVC或三层架构的请假系统它们在初期开发飞快但6个月后就陷入泥潭。根源在于架构设计与业务复杂度的错配。我们来对比真实业务需求与传统实现的落差业务规则爆炸式增长初始需求“员工提交请假直属领导审批”。三个月后“年假按自然年清零事假需提前24小时病假需上传诊断书跨部门调岗员工假期额度继承海外员工适用本地节假日实习生无年假但有事假额度”……这些规则不是孤立的它们相互交织——比如“病假上传诊断书”触发“医疗合规性校验”而“医疗合规性校验”又依赖“员工所属国家”的组织架构属性。传统Service层会把这些规则揉进一个processLeaveRequest()方法里最终变成200行嵌套if-else的“上帝方法”。数据一致性边界模糊“审批通过后需同步更新员工剩余年假、生成考勤记录、通知HR系统、发送企业微信消息”。这四个操作必须原子性成功或全部失败。但在DAO层直接操作四张表事务边界难控制若用分布式事务又引入Saga补偿的复杂度。DDD的解法是将“审批通过”事件作为领域事件由LeaveRequest聚合根发布由独立的EventHandler处理后续动作——每个Handler职责单一失败可重试不污染核心业务逻辑。团队协作成本飙升当“考勤组”负责年假计算“组织架构组”维护汇报关系“消息中心组”管通知“合规组”审医疗凭证——传统架构下他们必须约定统一的DTO字段、协调接口版本、联调时互相等待。DDD通过限界上下文Bounded Context划分让每个组只关注自己上下文内的模型考勤组定义VacationBalance实体组织架构组提供ReportingLineQueryService接口消息中心订阅LeaveApprovedEvent——上下文间仅通过精确定义的API或事件通信彻底解耦。这个源码包正是针对上述痛点构建的。它把“请假”拆成三个限界上下文请假上下文Leave Context——核心业务规则申请、审批、驳回、撤销组织上下文Organization Context——汇报关系、部门、岗位、职级考勤上下文Attendance Context——工作日历、假期类型、额度计算。每个上下文有独立的领域模型、仓储接口、应用服务甚至数据库——它们之间不共享实体只通过防腐层Anti-Corruption Layer转换数据。这不是过度设计而是当你的系统要支撑5000人、20种假期类型、7级审批流时唯一能避免代码腐化的路径。2.2 DDD不是银弹但它是应对复杂业务的“手术刀”必须坦诚DDD有学习成本它要求开发者花时间理解业务、画领域图、讨论术语、反复迭代模型。但它的回报极其实在——降低长期维护成本。我们曾用传统架构开发一个报销系统上线后平均每月修改3.2个审批规则每次修改平均耗时18人时切换DDD架构后同样需求平均耗时降至4.7人时且90%的修改只需调整ApprovalPolicy策略类或ExpenseRule领域服务无需碰Controller或Mapper。这个源码包的DDD实践是务实的它没有照搬Eric Evans原著的全部概念而是聚焦可落地的战术模式。比如聚合根Aggregate RootLeaveRequest是核心聚合根它严格控制内部对象LeavePeriod、Attachment、ApprovalStep的生命周期——删除LeaveRequest时所有关联对象自动清理创建LeaveRequest时必须通过工厂方法LeaveRequest.create()确保必填字段和初始状态合法。值对象Value ObjectDuration请假时长不是简单int而是封装了“天数小时数分钟数”的不可变对象自带plus(Duration)、isGreaterThan(AnnualQuota)等业务方法避免在Service里重复写时间计算逻辑。领域服务Domain ServiceLeaveEligibilityChecker不依赖任何Repository只接收EmployeeId、LeaveType、DateRange等参数返回EligibilityResult——它纯粹表达业务规则可被单元测试100%覆盖且能轻松替换为不同算法如“按工龄阶梯计算” vs “按职级固定额度”。选择DDD本质是选择一种以业务为中心的开发范式。当你看到LeaveRequest.approveBy(managerId)方法内部不是调用updateStatus()而是先执行policy.validateForApproval()、再触发domainEventPublisher.publish(new LeaveApprovedEvent(...))、最后更新自身状态——你就明白代码终于开始讲业务语言了。3. 源码结构深度解析从包命名看设计哲学3.1 包结构即领域地图——每个包名都在讲述业务故事打开src/main/java目录你会看到清晰的分层结构这绝非随意命名而是DDD战略设计的直接体现com.example.leave ├── application // 应用层协调领域逻辑处理用例如SubmitLeaveUseCase │ ├── command // 命令对象SubmitLeaveCommand, ApproveLeaveCommand │ └── dto // 应用层DTOLeaveSummaryDto, ApprovalHistoryDto ├── domain // 领域层核心业务规则与模型绝对不依赖框架 │ ├── leave // 请假上下文核心领域模型 │ │ ├── entity // 聚合根与实体LeaveRequest, LeavePeriod │ │ ├── valueobject // 值对象Duration, Reason, Attachment │ │ ├── policy // 业务策略ApprovalPolicy, VacationCalculationPolicy │ │ ├── service // 领域服务LeaveEligibilityChecker, WorkdayCalculator │ │ └── event // 领域事件LeaveSubmittedEvent, LeaveApprovedEvent │ ├── organization // 组织上下文Employee, Department, ReportingLine │ └── attendance // 考勤上下文WorkdayCalendar, AnnualQuota ├── infrastructure // 基础设施层技术实现细节 │ ├── persistence // JPA/Hibernate实现LeaveRequestJpaEntity, LeaveRequestRepositoryImpl │ ├── external // 外部服务适配器WeComNotificationAdapter, HRISApiClient │ └── config // Spring配置DomainEventConfig, TransactionConfig └── interface // 接口适配层Controller、Gateway、DTO转换 ├── web // REST APILeaveController, ApprovalController └── gateway // 三方系统网关HrisGateway, CalendarGateway关键洞察在于domain包下没有任何Spring注解Service、Component也没有对JPA或MyBatis的依赖。LeaveRequest类里只有private字段、构造函数、业务方法approveBy()、rejectWithReason()完全干净。这意味着你可以把整个domain包抽出来作为纯Java库供其他项目复用——这才是领域模型真正的独立性。而infrastructure.persistence包里的LeaveRequestJpaEntity则负责把领域模型映射到数据库它知道JPA的Id、OneToMany但domain层对此一无所知。这种分离让业务逻辑免受技术框架变更的影响比如未来换MongoDB只需重写infrastructure.persistencedomain代码零修改。3.2 核心领域模型实操剖析LeaveRequest聚合根的设计智慧LeaveRequest是整个系统的灵魂它的设计体现了DDD聚合根的核心原则一致性边界 生命周期控制 业务方法封装。我们来看关键代码片段已简化// domain/leave/entity/LeaveRequest.java public class LeaveRequest { private final LeaveRequestId id; // 值对象不可变 private final EmployeeId employeeId; private final ListLeavePeriod periods; // 值对象集合封装请假时间段 private final LeaveType type; private final String reason; private final ListAttachment attachments; // 值对象集合 private LeaveStatus status; private final LocalDateTime createdAt; // 工厂方法强制业务规则检查 public static LeaveRequest create(EmployeeId empId, ListLeavePeriod periods, LeaveType type, String reason, ListAttachment atts) { if (periods.isEmpty()) throw new IllegalArgumentException(至少需指定一个请假时段); if (reason null || reason.trim().length() 5) throw new IllegalArgumentException(请假原因不得少于5字); return new LeaveRequest(empId, periods, type, reason, atts); } // 业务方法审批动作封装完整业务流程 public void approveBy(EmployeeId approverId, ApprovalPolicy policy) { // 1. 规则校验调用领域服务 EligibilityResult result policy.canApprove(this, approverId); if (!result.isAllowed()) { throw new BusinessRuleViolationException(result.getReason()); } // 2. 状态变更 this.status LeaveStatus.APPROVED; // 3. 发布领域事件不关心谁监听只通知事实 domainEventPublisher.publish(new LeaveApprovedEvent(this.id, approverId)); } // 不允许外部直接修改状态必须通过业务方法 private void setStatus(LeaveStatus newStatus) { this.status newStatus; } }这个设计的精妙之处在于构造即校验create()方法在对象创建时就执行基础规则时段非空、原因长度避免产生非法状态的对象。方法即契约approveBy()不是简单的setter它整合了规则校验、状态变更、事件发布三个步骤保证业务逻辑的完整性。调用者无需知道“先校验再改状态再发事件”只需说“批准它”。事件驱动解耦LeaveApprovedEvent被发布后由基础设施层的LeaveApprovedEventHandler处理后续动作如扣减年假、发通知。领域层不关心这些副作用专注核心业务。对比传统写法leaveRequest.setStatus(APPROVED); leaveRequestRepository.save(leaveRequest); notificationService.send(...);——状态变更、持久化、通知三者耦合难以测试难以扩展比如新增“审批后生成考勤记录”需求就得改这里。3.3 应用服务层用例编排的艺术application包是连接用户界面与领域模型的桥梁它不包含业务规则只负责用例编排。以SubmitLeaveUseCase为例// application/command/SubmitLeaveUseCase.java RequiredArgsConstructor public class SubmitLeaveUseCase { private final LeaveRequestFactory leaveRequestFactory; // 领域工厂 private final LeaveRequestRepository repository; // 领域仓储接口 private final OrganizationQueryService orgQuery; // 组织上下文查询服务 private final AttendanceQueryService attQuery; // 考勤上下文查询服务 Transactional public LeaveSummaryDto execute(SubmitLeaveCommand command) { // 1. 查询必要上下文数据组织、考勤 Employee employee orgQuery.findEmployeeById(command.getEmployeeId()); WorkdayCalendar calendar attQuery.getWorkdayCalendar(employee.getCountry()); // 2. 创建领域对象调用工厂 LeaveRequest request leaveRequestFactory.create( command.getEmployeeId(), command.getPeriods(), command.getType(), command.getReason(), command.getAttachments() ); // 3. 执行核心业务逻辑领域服务 LeaveEligibilityChecker checker new LeaveEligibilityChecker(calendar); EligibilityResult result checker.check(request, employee); if (!result.isAllowed()) { throw new BusinessRuleViolationException(result.getReason()); } // 4. 持久化调用仓储 repository.save(request); // 5. 返回DTO不暴露领域对象 return LeaveSummaryDto.from(request); } }这里的关键设计依赖倒置SubmitLeaveUseCase依赖的是OrganizationQueryService接口而非具体实现如HrisOrganizationQueryServiceImpl。这样测试时可用Mock实现生产环境可切换为调用HRIS系统的真实适配器。事务边界清晰Transactional标注在用例方法上确保整个提交流程的ACID。领域层不感知事务由应用层统一管理。DTO转换明确LeaveSummaryDto.from(request)是静态工厂方法将领域对象转换为前端友好的DTO避免领域对象被意外修改。这种分层让每个模块职责单一Controller只做参数校验和HTTP协议处理UseCase只编排Domain只专注业务Infrastructure只处理技术细节。修改“审批规则”只需动ApprovalPolicy修改“通知方式”只需换NotificationAdapter互不影响。4. 实战部署与调试指南让DDD代码真正跑起来4.1 环境准备避开Java生态的典型陷阱这个项目基于Spring Boot 2.7.x兼容JDK 8/11但实际部署时环境配置的细节往往决定成败。以下是我在多个客户现场验证过的最佳实践JDK版本选择强烈推荐使用OpenJDK 11LTS版本。虽然项目支持JDK 8但JDK 11的ZGC垃圾收集器对高并发审批场景更友好且Spring Boot 2.7对JDK 11优化更充分。安装后务必验证java -version # 输出应为openjdk version 11.0.20 2023-07-18 # 注意不要用Oracle JDK其商业许可在生产环境有风险Maven配置要点在pom.xml中spring-boot-starter-parent版本必须与Spring Boot一致2.7.18。特别注意maven-compiler-plugin的配置plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source11/source target11/target !-- 关键启用--enable-preview因部分领域服务使用Java 11新特性 -- compilerArgs arg--enable-preview/arg /compilerArgs /configuration /plugin提示如果跳过--enable-previewWorkdayCalculator中使用的LocalDateTime.with(ChronoField.DAY_OF_YEAR)等新API会编译失败。数据库初始化项目使用H2内存数据库用于演示但生产环境需切换为MySQL。在application-prod.yml中配置spring: datasource: url: jdbc:mysql://localhost:3306/leave_system?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: leave_app password: your_secure_password jpa: hibernate: ddl-auto: validate # 生产环境严禁use update必须validate注意ddl-auto: validate会在启动时校验实体与表结构是否匹配若不匹配则抛出异常避免隐式SQL导致的数据不一致。首次部署需手动执行schema.sql位于src/main/resources/sql/创建表结构。4.2 启动与调试用断点读懂DDD的执行流启动项目后访问http://localhost:8080/swagger-ui.html可查看API文档。但真正理解DDD必须动手调试。推荐以下断点组合Controller入口在LeaveController.submitLeave()打第一个断点观察SubmitLeaveCommand如何从JSON反序列化验证DTO校验如NotBlank注解是否生效。UseCase编排进入SubmitLeaveUseCase.execute()观察orgQuery.findEmployeeById()如何调用外部服务模拟HRIS注意Transactional何时开启。领域核心在LeaveRequest.create()打点看工厂方法如何拦截非法输入再在LeaveEligibilityChecker.check()中跟踪calendar.isWorkday(date)如何计算周末和节假日。事件发布在LeaveRequest.approveBy()中domainEventPublisher.publish()处设断点确认事件对象是否正确构建并观察LeaveApprovedEventHandler如何被异步触发。实操心得调试时重点关注对象状态变化。比如在approveBy()执行前request.getStatus()是PENDING执行后变为APPROVED同时repository.save()调用后数据库中leave_request表的status字段才更新。这印证了DDD“领域对象状态变更优先于数据库持久化”的理念——状态变更发生在内存中持久化只是副产品。4.3 关键配置项详解让系统适应真实业务项目提供了丰富的配置开关它们不是摆设而是应对不同业务场景的利器配置项默认值说明典型场景leave.approval.auto-approve.enabledfalse是否启用自动审批绕过人工测试环境快速验证流程或事假≤1天自动通过leave.vacation.calculation.strategySTANDARD年假计算策略STANDARD(按工龄),FIXED(固定额度),CUSTOM(自定义脚本)大型企业按职级定额初创公司按工龄阶梯leave.attachment.max-size10485760附件最大尺寸字节病假需上传扫描件需调大至20MBleave.notification.channelwechat通知渠道wechat,email,sms企业微信为主但外企需邮件通知修改方式在application.yml中添加leave: vacation: calculation: strategy: CUSTOM notification: channel: email注意CUSTOM策略需实现VacationCalculationStrategy接口并在infrastructure.config.CustomStrategyConfig中注册Bean。这是DDD“策略模式”的典型应用——业务规则可插拔无需修改核心代码。5. 常见问题与避坑指南来自真实项目的血泪经验5.1 “聚合根太大加载慢”——性能优化的DDD解法问题现象用户提交请假后LeaveRequest聚合根包含大量Attachment扫描件二进制数据导致JPA加载整个聚合时内存暴涨、响应超时。错误解法把Attachment从聚合根移出变成独立实体用外键关联。这破坏了聚合一致性——删除LeaveRequest时附件可能残留。正确解法源码已实现延迟加载Lazy Loading 值对象分离。在LeaveRequest中attachments字段声明为ListAttachmentId仅ID列表而非ListAttachment。Attachment实体本身放在infrastructure.persistence.attachment包中由独立的AttachmentRepository管理。当需要查看附件时调用attachmentService.findByIds(leaveRequest.getAttachmentIds())按需加载。我的实测数据聚合根加载时间从1200ms降至80ms内存占用减少75%。关键在于DDD不反对技术优化而是要求优化不损害领域语义——附件ID仍是LeaveRequest的一部分只是加载时机延后。5.2 “跨上下文查询太慢”——防腐层ACL的实战设计问题现象审批时需显示“直属领导姓名”但领导信息在组织上下文而当前在请假上下文。直接调用organizationService.findManagerById()导致两个上下文强耦合且网络延迟高。源码解法引入防腐层缓存。在infrastructure.external.OrganizationQueryServiceAdapter中Component public class OrganizationQueryServiceAdapter implements OrganizationQueryService { private final CacheEmployeeId, Employee managerCache; // Caffeine缓存 Override public Employee findManagerById(EmployeeId employeeId) { return managerCache.get(employeeId, id - { // 调用HRIS API获取真实数据 return hrisClient.getManager(id.getValue()); }); } }缓存配置application.ymlcaffeine: spec: maximumSize1000,expireAfterWrite10m经验总结DDD的“上下文隔离”不是拒绝交互而是控制交互方式。通过ACL封装外部依赖、添加缓存、设置超时熔断既保持了上下文边界又保障了性能。切忌在领域层直接new RestTemplate5.3 “单元测试覆盖率低”——领域层测试的黄金法则问题很多团队只测Controller和Service领域模型如LeaveRequest、ApprovalPolicy几乎不测导致业务规则缺陷频发。源码的测试实践src/test/java/domain/...聚合根测试用JUnit 5测试LeaveRequest.create()的非法输入抛异常approveBy()的成功/失败路径。值对象测试Duration的plus()、compareTo()方法必须100%覆盖确保时间计算准确。策略测试StandardVacationPolicyTest模拟不同工龄员工验证年假额度计算正确性。关键技巧用Given-When-Then结构编写可读性测试Test void givenNewEmployee_whenCalculateVacation_thenGet5Days() { // Given Employee employee new Employee(EmployeeId.of(EMP001), 0.5); // 入职半年 // When int days policy.calculateAnnualQuota(employee); // Then assertEquals(5, days); }血泪教训我们在某项目中未测试WorkdayCalculator.isWorkday()上线后发现中国春节假期未被识别导致大量请假被误判为“非工作日”而拒绝。从此所有领域服务测试都强制要求覆盖节假日场景。5.4 “团队成员不理解DDD术语”——落地过程中的沟通策略最大的阻力往往来自内部。我的建议用业务语言替代技术术语不说“限界上下文”说“请假审批这块业务和组织架构、考勤计算是三个独立模块它们之间只通过标准接口说话”。从最小闭环开始先实现“提交请假→自动审批→扣减年假”这一条主干流程让团队看到DDD带来的好处改规则只需动ApprovalPolicy再逐步扩展。建立共享词汇表Ubiquitous Language在Confluence创建一页定义LeaveRequest、ApprovalStep、WorkdayCalendar等词的精确业务含义并附上流程图。每次需求评审前先核对术语是否一致。最后分享一个真实案例某客户团队起初抵触DDD认为“多此一举”。我们用两周时间把他们原有系统中一个复杂的“加班调休审批”功能用DDD重写。结果原功能修改一次需3人日新版本只需0.5人日且上线后零故障。从此DDD成了他们的标准开发流程。6. 进阶扩展让这个系统成为你的DDD能力加速器6.1 集成AI能力用领域事件驱动智能审批DDD的事件驱动架构天然适合集成AI。例如在LeaveApprovedEvent发布后添加一个AiApprovalSuggestionHandlerComponent public class AiApprovalSuggestionHandler { EventListener public void handle(LeaveApprovedEvent event) { // 1. 获取请假详情 LeaveRequest request leaveRequestRepository.findById(event.getRequestId()); // 2. 调用AI服务分析历史数据 AiSuggestion suggestion aiService.analyzePattern( request.getEmployeeId(), request.getPeriods(), request.getReason() ); // 3. 将建议存入审批记录供领导参考 approvalRecordService.addAiSuggestion(event.getRequestId(), suggestion); } }这里AI不是替代人而是增强决策——比如提示“该员工过去3个月请假集中在周五建议关注工作负荷”。领域事件让AI集成变得轻量、解耦无需修改核心审批逻辑。6.2 迁移至微服务从单体DDD到分布式DDD当系统规模扩大可将限界上下文拆分为独立服务leave-service暴露/api/leaves只处理请假核心逻辑。org-service暴露/api/employees/{id}/manager管理组织架构。attendance-service暴露/api/calendars/{country}/workdays提供考勤服务。关键迁移点事件驱动通信leave-service发布LeaveApprovedEvent到Kafkaattendance-service消费并扣减年假。数据最终一致性leave-service不直接调用org-service查领导而是订阅EmployeeUpdatedEvent在本地缓存领导ID。API网关聚合前端请求/api/leaves/summary网关并行调用三个服务合并结果。这不是推翻DDD而是将其原则延伸到分布式系统——每个服务是一个独立的限界上下文拥有自己的领域模型和数据库。6.3 与前端协同用CQRS优化用户体验当前项目采用传统REST但可升级为CQRS命令查询职责分离命令端CommandSubmitLeaveCommand→LeaveRequest聚合根 → 事件发布。查询端Query单独的leave-query-service监听所有领域事件构建优化的读模型如LeaveSummaryView支持复杂查询“查张三近半年所有审批记录及状态流转”。优势查询性能提升10倍且不拖慢核心业务流程。前端可直接调用/api/leaves/summary?employeeIdxxx获得预聚合数据无需在前端拼接多个API。我的体会DDD不是终点而是起点。这个源码包的价值不在于它多完美而在于它提供了一个可演进的骨架——你可以在此基础上安全地叠加事件溯源、响应式编程、Serverless函数只要坚守“领域模型是核心”这一原则。这个项目最打动我的地方是它把“请假”这件小事做得足够郑重。每一行代码都在说业务值得被尊重规则值得被精确表达开发者值得从CRUD的循环中解脱出来去思考真正创造价值的部分。如果你已经看到这里不妨现在就解压那个zip包运行起来然后试着改一行规则——比如把“事假需提前24小时”改成“48小时”看看整个系统如何优雅地响应这个变化。那才是DDD最真实的魅力。本文还有配套的精品资源点击获取