Spring Boot微服务架构与数据库设计：从面试考点到工程实战

面试这件事我这些年带过不少候选人也模拟过很多次大厂Java岗的流程。一个特别常见的现象是八股文背得滚瓜烂熟JVM、并发、集合都能讲但面试官把话锋一转问到“你们这个微服务当时是怎么拆的”“订单表为什么这样设计”很多人就开始支支吾吾。原因很简单知识点是别人的项目是自己的中间缺了一座桥。这篇博文我想把这座桥搭起来。主题很直接Spring Boot微服务架构与数据库设计这是后端面试里出现频率最高、也最容易被问出深度的两块。我会从面试官的真实考察逻辑出发拆解微服务架构中的版本选型、服务拆分、服务调用、中间件组合再到数据库设计里的ER建模、典型业务表结构、索引与分库分表最后附上一批我实际遇到过的追问链和应对思路。适合正在准备大厂Java面试的朋友也适合那些手头有项目但不知道怎么讲出彩的后端开发。不保证你看完立刻拿offer但至少能把高频考点从“背过”变成“答会”。1. 从面试官视角看大厂Java岗到底怎么问微服务与数据库1.1 面试题的三层逻辑八股文只是入场券先说个很多人没想明白的事。面试官问“Spring Boot的自动配置原理是什么”和问你“你们项目里有没有自定义过starter”这俩问题的分量是完全不同的。前者是校验你有没有认真看过源码后者是校验你有没有真刀真枪干过活。大厂的面试其实分三层第一层是基础知识的广度也就是大家常说的八股文这部分决定了你能不能过简历筛选和一面第二层是技术选型和场景匹配的能力比如“你们为什么用Redis做缓存而不用本地缓存”这决定了你能不能进二面第三层是对方案取舍和代价的理解比如“Redis缓存和数据库一致性你们怎么保证”这直接决定了你的评级。很多候选人栽就栽在只准备了第一层。Spring Boot的自动配置原理背得滚瓜烂熟但一问到“你们项目启动的时候有哪些自动配置生效了”立刻卡壳。真正的面试高手会怎么做他们会把八股文当作一座冰山的水下部分水面之上是自己项目的具体实践。面试官问到任何原理他们都能顺势接回自己的项目场景用真实案例来印证原理。这种“以项目带知识点”的回答方式才是大厂面试最吃香的。1.2 微服务与数据库题目在面试中的出现节奏从我统计过的上百场面试记录来看微服务和数据库的题目分布很有规律。一面通常以Java基础为主但只要是稍微有点规模的项目Spring Boot相关问题一定会占30%左右比如自动配置、starter机制、日志框架、配置加载顺序。到了二面面试官开始深挖项目微服务的服务拆分、注册中心选型、服务间调用方式、分布式事务几乎一个不落。数据库那边则是索引原理、事务隔离级别、SQL调优、表结构设计尤其是给你一个业务场景让你现场设计表这种题在二面三面特别常见。所以准备策略也要跟着调整。别一上来就背“微服务全套面试题”那是低效的。正确做法是把自己做过的项目从架构到表结构完整复盘一遍画出系统架构图梳理出核心业务流程对应的接口和表再针对每个技术点准备“为什么这么做”的解释。我见过一个候选人他做的只是一个中等体量的后台管理系统但因为把用户表、角色表、权限表的设计逻辑讲得清清楚楚还主动解释了为什么用RBAC模型而不是更复杂的ABAC面试官当场给了很高的评价。这就是复盘的力量。1.3 准备面试的正确姿势把面试当项目复盘这里分享一个我带人常用的方法拿出一张白纸把你负责的系统从上到下画一遍。入口是什么网关做了什么注册中心用的什么服务之间怎么调用每个服务连了什么数据库缓存和消息队列在哪一层日志和监控怎么做的。画完之后针对每个环节问自己三个问题为什么这么选有没有别的方案那个方案为什么没选这个“三问法”几乎能把面试中80%的追问都覆盖到。比如你画到服务间调用用的是OpenFeign就得想想为什么不用Dubbo为什么不用gRPCRESTful接口在内部服务调用中的性能瓶颈是什么如果你能说清楚OpenFeign的HTTP调用走的什么协议、默认超时时间是多少、怎么配置熔断降级这一块就能拿高分。关于数据库也是同样的套路你画到订单表就得能答出来为什么订单号和用户ID分别建索引订单状态字段为什么用tinyint不用varchar这些问题看似细碎但正是面试官区分“真做过”和“看过项目”的关键。2. Spring Boot微服务架构核心考点从工程化到底层原理2.1 版本选型Spring Boot 2.x到3.x面试官在追问什么Spring Boot版本这个点很多候选人不当回事觉得不过是gradle或maven里一个坐标而已。但从2023年开始这个问题变得越来越高频。面试官通常这么问“你们项目用的Spring Boot哪个版本为什么不用最新的”或者“Spring Boot 3.0相比2.x有哪些破坏性变更如果让你升级你会怎么处理”实际上Spring Boot 3.x是一个分水岭。它强制要求JDK 17及以上把javax命名空间换成了jakarta这导致所有依赖Spring的第三方库都要跟着升级。Spring Security 6的配置方式和5.x差异很大很多老的SecurityConfig类直接编译不过。我记得有个候选人就卡在这上面他项目还是Spring Boot 2.7 Spring Security 5面试官一问“Spring Security的过滤链配置在Boot 3里有什么变化”他诚实说没研究过结果那一题直接丢了印象分。Spring Security 6里WebSecurityConfigurerAdapter被删了改为组件化的SecurityFilterChain Bean配置这个变化是面试官特别爱问的因为网上大量旧教程还在教适配器方式能熟练掌握新写法的候选人确实不多。还有一个热点是JDK 21的虚拟线程。Spring Boot 3.2开始支持虚拟线程3.5版本对这块做了进一步完善。面试时如果你能说出“Java 21的虚拟线程是JVM管理的轻量级线程挂起唤醒不再依赖操作系统内核线程Spring Boot里可以通过spring.threads.virtual.enabledtrue开启非常适合IO密集型场景比如服务间HTTP调用、数据库访问”这绝对是加分项。但要注意面试官很可能会接着问“虚拟线程适合CPU密集型任务吗”这时候你得诚实回答不适合因为CPU密集型任务需要的是更多计算核心虚拟线程解决的是线程阻塞时的资源浪费问题。2.2 服务拆分与服务间调用OpenFeign、gRPC与注册中心的选型逻辑服务怎么拆是大厂面试里的必问题也是区分度特别高的题。面试官想听的绝对不是“按业务域拆分”这种教科书答案而是你真正面对过的取舍。比如一个商城的后端是拆成用户服务、商品服务、订单服务、支付服务四个还是拆得更细拆得太细服务间调用链路变长排查问题难度指数级上升拆得太粗又回到了单体应用的老路。我的经验是按“业务变更频率 团队组织边界”来拆。商品和订单的变更频率明显不同拆开用户和支付牵涉到资金安全拆开并加上独立的审计。另外还要考虑数据隔离服务拆分必然带来数据库拆分订单库和用户库不能放在同一个库里否则跨库查询就是噩梦。服务间调用方式面试中最高频的考察点是OpenFeign。尤其喜欢问“OpenFeign和Dubbo有什么区别”“OpenFeign底层是HTTP调用性能瓶颈在哪里”。这里有一个容易踩坑的地方OpenFeign的版本和Spring Boot版本有对应关系尤其是引入了io.github.openfeign相关扩展包时版本不匹配会导致Bean创建失败、接口代理异常等问题。面试时可以提一句“我们在pom里通过Spring Cloud BOM统一管理版本避免OpenFeign和Spring Boot的兼容性冲突”这个细节能体现你是个对工程化有感知的人。至于gRPC现在很多大厂的新项目开始用它做内部服务间通信。面试官如果问到核心考察的是你对HTTP/1.1、HTTP/2和Protobuf的理解。你可以这么回答gRPC基于HTTP/2支持多路复用和二进制协议序列化用Protobuf性能比JSON HTTP/1.1高很多但代价是调试不方便浏览器、Postman都不直接支持需要grpcurl这样的专门工具所以一般只在性能敏感的内部服务间使用对外接口还是用RESTful或GraphQL。这个回答把优点、缺点、适用场景全讲到了面试官很难再追问倒你。2.3 中间件选型的“送命题”Redis、MinIO这些组件为什么出现在你的架构里微服务架构里不可能只有Spring Boot和数据库中间件选型是面试中另一大考点。Redis几乎必问而且问法五花八门。最常见的追问链是缓存穿透、缓存击穿、缓存雪崩分别是什么怎么解决这三个问题你要是只是把定义背出来面试官一定会追问“你们项目里实际用了哪种方案”。我建议准备一个自己项目里的真实案例比如用Redis做热点商品缓存设置随机过期时间防止雪崩用布隆过滤器防止穿透用互斥锁解决击穿一套组合拳下来面试官会觉得你真的处理过线上问题。MinIO在热搜词里也出现了这是个很好的信号。说明现在很多项目开始用MinIO做对象存储替代传统的FastDFS。面试官如果问到你就可以说MinIO是纯Go写的兼容S3协议部署简单一个二进制文件就能跑起来配合Nginx可以做访问域名绑定适合存图片、附件、音视频这种非结构化数据。还可以补一句“它的分片上传对大文件支持很好我们之前做过的文件服务就是基于MinIO的预签名URL实现直传减轻服务器带宽压力”。这就是把中间件选型讲出了项目感。消息队列也是微服务里绕不开的但我不建议你在面试中主动提一堆Kafka、RocketMQ、RabbitMQ的对比背诵。更好的方式是结合业务比如订单创建后要发通知、扣库存、记录日志如果同步调用三个服务响应时间会很长这时候引入消息队列做异步解耦。面试官想听的是你“为什么要异步”的思考过程而不是“Kafka吞吐量比RabbitMQ高”这种参数背诵。2.4 微服务工程落地的“隐形考点”日志、配置与IDE实操除了架构层面的东西面试官偶尔也会问一些“工程落地”层面的细节这些题看似随意却非常考验真实经验。比如“你们微服务这么多线上怎么排查问题”这里的关键词是链路追踪。你可以说我们在日志里埋了traceId通过网关生成下游服务通过MDC传递这样在日志平台按traceId一搜就能看到一次请求经过的所有服务日志。如果你们接了SkyWalking或Zipkin还可以补充链路拓扑图的查看方式。这块是很多候选人没准备到的地方答好了会很出彩。还有一个特别实战的问题是“IDEA里微服务多模块怎么快速启动所有服务”。这个题出现在热搜词里我一点也不意外因为真的有人在这种细节上翻车。其实IDEA的Services面板就是干这个用的在View - Tool Windows - Services里打开把Spring Boot的Run Configuration加进去就能看到所有服务的运行状态一键启动、一键停止还能查看每个服务的端口和日志。另外可以通过Compound Configuration把多个服务合并成一个配置一键全部拉起。如果在微服务架构面试里聊到“部署拓扑”或“本地联调”顺带提一嘴这个工具技巧会让面试官觉得你是个真正在一线写过代码的人。还有一个实操问题也常见IDEA启动Spring Boot项目不显示端口号。这个虽然不是面试核心题但作为运维排查思路的考察偶尔会出现。原因一般是这几种一是日志级别配置过高把Spring Boot启动日志过滤掉了检查logback或log4j2配置里的root level二是当前类没有加SpringBootApplication注解根本没启动成Spring容器三是端口号被占用了启动失败但控制台信息没刷出来。排查思路其实就是顺着启动流程走一遍看控制台有没有“Started Application in X seconds”这段标志性日志没有就看有没有异常堆栈有异常就顺着堆栈找。这个回答展现了你的问题排查方法论比单纯说出答案更有说服力。说到启动问题还有一个编译问题很常见java: 警告: 源发行版 17 需要目标发行版 17。这本质上是IDEA的Java编译器级别和项目实际JDK版本不一致导致的。检查三处Project Structure里的Project SDK、Modules里的Language Level、Maven或Gradle的编译配置source和target版本。面试里问这种问题的概率不高但如果被问到你能快速说出“编译器级别和JDK版本不匹配”的根因然后补充排查三步法面试官对你的工程经验评价会明显高于只会背八股的人。3. 数据库设计实战从ER图到面试官认可的落库方案3.1 拿到题目后的标准思考流程实体、关系、约束、索引数据库设计题在面试中几乎100%出现而且多以大题形式存在给你一个业务场景让你现场设计表结构时间通常10到20分钟。很多人拿到题就开始写CREATE TABLE这是最大的错误。正确的流程应该是先划实体、定关系、画ER图再落成表结构最后补索引和约束。用PowerDesigner或者draw.io画ER图是这个环节的神器PowerDesigner尤其适合面试笔试场景因为它可以同时展示概念模型和物理模型还能正向生成建表SQL。具体来说第一步是读题划实体。比如面试官让你设计一个博客系统你脑子里要快速列出用户、文章、分类、标签、评论五个实体。第二步是确定关系用户和文章是一对多文章和分类是多对一文章和标签是多对多文章和评论是一对多。第三步是考虑多对多关系需要中间表于是文章标签关联表就出来了。第四步才是设计字段每个表的主键用什么、哪些字段要唯一约束、哪些字段要索引、需不需要逻辑删除字段和审计字段。这里要特别强调一个面试加分动作字段类型的选择要说出理由。用户ID用BIGINT还是VARCHAR(32)如果未来可能做分库分表自增主键就有冲突风险所以我倾向用雪花算法生成的BIGINT或者用UUID转成无横线字符串。手机号字段用VARCHAR(20)还是CHAR(11)手机号是定长的理论上CHAR(11)更省空间但如果考虑到国家码和扩展VARCHAR(20)更稳妥。面试官不一定要求你选“标准答案”但一定希望看到你“有意识地做选择”而不是随手写上去。3.2 经典业务场景的表设计拆解商城、外卖、博客、讲座预约面试中的数据库设计题翻来覆去就那几类我把出现频率最高的四种场景拆开讲。第一类是商城系统几乎是必考题。核心表有用户表、商品表、SKU表、购物车表、订单主表、订单明细表。这里最容易出错的是订单和商品的关系。订单明细表必须冗余商品名称、商品快照价格而不是直接关联商品表。为什么因为商品价格会变如果订单明细通过商品ID去联查当前价格历史订单的价格就全错了。这个“订单快照”思想面试官特别看重几乎算是一个隐藏加分点。第二类是外卖系统跟商城类似但多了配送和门店维度。记得有一份经典的“苍穹外卖”数据库设计文档在网上流传很广里面设计了店铺表、菜品表、套餐表、购物车表、订单表、订单明细表、地址簿表还涉及分类表和口味表。面试时如果你能提到“套餐是菜品的组合用套餐菜品关联表实现”再补充一句“购物车数据通常用Redis存减少数据库压力提交订单时一次性写入订单表”面试官会认为你不光会建表还懂性能优化。第三类是博客系统。核心表是用户、文章、分类、标签、文章标签关联、评论。这里有一个经常被考察的设计细节点文章的点赞数、评论数、浏览数字段是实时count查出来还是冗余在文章表里答案很明显冗余字段每次点赞或评论时用事务更新计数。如果数据量大了可以进一步引入Redis计数异步落库但在表设计层面先要预留这些冗余计数字段。第四类是校园讲座预约系统。基础表包括讲座表、场次表、用户表、预约记录表。这个场景有一个独特的难点并发预约下怎么保证座位不超卖。这时候表设计要配合锁机制预约记录表加唯一约束user_id, session_id防止同一用户重复预约讲座场次的剩余座位数用版本号或乐观锁更新如果并发再高就得靠Redis分布式锁或者Redis原子扣减座位数再异步落库。这个案例能很好地把数据库设计和并发控制串起来面试答好了非常亮眼。3.3 数据库设计面试的评分点范式与反范式、索引、分库分表面试官在评价你的数据库设计方案时心里一般装着这么几个评分维度。第一是范式掌握程度。你至少得能解释清楚什么是第一范式、第二范式、第三范式并且知道什么时候该违反它。比如订单明细表存冗余商品名这违反了第三范式的传递依赖但实际业务必须这么做。你能说清楚“这里我故意做了反范式设计因为商品名称在历史订单里必须保持不变”面试官就知道你理解范式的本质是减少冗余而不是为了规范而规范。第二是索引设计能力。面试官给你的表设计挑毛病时最常问的就是“这张表查询量最大的SQL是什么索引建在哪些字段上”你要掌握几个原则WHERE条件里的字段优先建索引、ORDER BY和GROUP BY字段建索引、区分度低的字段比如性别不适合建索引、联合索引遵循最左前缀原则。如果面试官追问“联合索引里字段顺序怎么排”你可以回答区分度高的放前面经常等值查询的放前面范围查询的字段尽量放后面并且可以用覆盖索引避免回表。这一套答下来数据库这块基本就稳了。第三是分库分表意识。面试官最爱问“订单表数据量达到一亿行怎么办”这时候你要先评估而不是直接说分库分表。一亿行在MySQL里如果索引合理、定期归档其实还能扛真正需要分表通常是在日订单量百万级以上。如果你判断需要分表可以按订单ID哈希取模分表或者按用户ID分库让每个用户的订单落在同一个库、同一张表里这样查询用户订单列表不需要跨库查询。分库分表中间件选型上ShardingSphere是目前的主流选择面试时提这个项目名会显得你技术栈比较新。但一定要记住分库分表是最后的兜底手段能通过索引优化、归档、读写分离解决的就不要先上分库分表。3.4 用户信息表的经典设计一个被问了无数次的“第1关”热搜词里有“第1关数据库表设计 - 用户信息表”这绝对是新手入行的第一个坎也是面试官最爱用来试水的基础题。别看它简单真能设计好的人不多。基础字段大家都想得到id、用户名、密码、手机号、邮箱、状态、创建时间、更新时间。但加分的细节至少有四个密码字段用哈希值存储长度至少VARCHAR(64)以适配BCrypt加密结果用户名和手机号加唯一索引这是防重复注册的底线状态字段用TINYINT而不是VARCHAR因为状态是有限的枚举值用数字类型更省空间、查询更快必须包含create_time和update_time这两个审计字段这是所有业务表的标配且update_time在更新时自动更新建表SQL里写成DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。再往深一层面试官可能会追问“用户头像存哪里”。这就涉及对象存储的知识你可以回答用户表的avatar字段存的是对象存储的路径或URL而不是图片二进制。图片文件放MinIO或云OSS数据库只存一个字符串引用。这样设计的好处是数据库体积小、读写快图片文件可以单独做CDN加速和防盗链。你看一个看似简单的用户信息表从字段类型到存储策略全讲透需要不小的知识储备这也是为什么大厂面试官喜欢拿这种简单题目开刀——基础题最容易看出一个人是背过答案还是真的理解设计原则。4. 常见问题与排查技巧实录那些容易被问懵的细节4.1 微服务架构的经典追问链与应对思路我模拟面试的时候最喜欢用的一个追问链是这样展开的。“你项目里服务是怎么部署的”候选人答Docker容器部署。“那服务挂了怎么发现”答用了Nacos注册中心服务实例下线会自动摘除。“如果下游服务变慢了怎么办”这里很多人会卡住。正确的思路是先分级上游调用下游接口设置超时时间比如OpenFeign默认连接超时和读取超时都要显式配置不能靠默认然后接熔断降级用Sentinel或Resilience4j实现当错误率达到阈值时快速失败返回兜底数据最后是重试注意重试要设置最大次数且要考虑接口是否幂等否则重复扣款这种事故分分钟发生。还有一个高频追问“两个服务都要操作同一张表怎么办”这是典型的设计失误题。微服务架构里服务间应该通过API通信而不是共享数据库表。如果订单服务和支付服务都在操作订单表这个拆分就有问题。正确的做法是在订单服务里提供订单状态变更的原子接口支付服务通过调用接口来更新订单状态而不是直接改库。回答这个问题时你可以顺便提一下分布式事务的两种主流方案2PC的Seata AT模式适合一致性要求高的场景但性能开销大消息队列可靠消息最终一致性更适合大多数业务即本地消息表和MQ事务消息配合使用。这个回答展示了实战经验、踩坑感悟、方案选型三个层次。4.2 数据库设计的追问链从一个表设计发散到一个系统数据库设计的追问链更容易让人措手不及因为面试官会从你的表结构里找漏洞。举一个真实的模拟案例候选人设计了一个商品表包含商品ID、名称、价格、库存。面试官问“现在要做促销部分商品打八折你怎么设计折扣字段”有人会说在商品表加一个discount字段这样简单但问题来了如果不同用户群体的折扣不一样呢比如VIP用户九折普通用户无折扣。这时候你就需要一张独立的促销表或价格策略表了。面试官的言外之意是你能不能从“一个商品字段”抽离出“一个价格体系”。再比如候选人设计了一个订单表订单状态字段用VARCHAR存了“待支付”“已支付”“已发货”“已完成”。面试官问“如果我要统计每天成功支付的订单量SQL怎么写”你会写WHERE order_status 已支付但问题在于中文字段作为查询条件既慢又不安全而且如果之后状态枚举值改了名字代码里所有地方都要改。这时候你就意识到订单状态应该用TINYINT或枚举类Java侧用Enum映射。而且统计每天支付成功量如果订单表的支付时间字段pay_time没有索引这个查询注定是慢查询所以还要补充索引设计。一个简简单单的订单表就这样被面试官拆成了状态设计、索引设计、时间字段设计三个考点。这种追问的应对方法只能是平时设计表时多想一层“这个字段未来会怎么被查询”。4.3 那些看起来“偏门”但确实出现过的面试题面试不可能全在大纲之内。有些题目看起来偏门但背后的考察逻辑是一致的——快速学习能力和解决问题的思路。比如“你有没有用过java源码混淆工具”这个问题出现的原因大概率是面试官在做代码交付或知识产权保护相关的项目。你如果没用过不要直接说“不会”可以说“我了解过ProGuard和Allatori但项目中很少用因为Java是字节码语言混淆只能增加反编译成本而不能完全防止而且混淆后堆栈信息会变得难以阅读需要保留mapping文件才能定位线上问题”。这个回答展示了你对利弊的思考。再比如“java获取DNS”这种题本质是在问网络编程基础。你可以从InetAddress.getByName讲起延伸到DNS解析在微服务里的应用场景比如服务发现、配置中心的域名解析、公网API调用的DNS缓存策略。如果面试官感兴趣你还可以提一句“像云厂商的SLB域名解析经常因为本地DNS缓存导致服务迁移后仍然访问旧IP这时候可以用dig命令排查Java侧可以调低JVM的DNS缓存时间”。一个偏门题被你拉回到了实际问题这比死记硬背知识点强得多。还有热搜词里出现的“基于ONNX的车牌识别”其实是项目亮点题。如果候选人简历里写了类似的项目面试官一定会问“ONNX模型怎么部署的推理速度多少”这时候你要能说清楚ONNX Runtime的API调用流程、输入图片的前处理和输出结果的解码以及模型在CPU和GPU下的性能差异。这个题目本质上考察的是你是否真的做过这个项目因为没做过的人连“ONNX Runtime和PyTorch的导出关系”都说不清楚。我对这类项目的建议是如果没有从头到尾跑通过就不要往简历上写被追问三句就会露馅。4.4 排查问题的通用方法论面试中救命的“三板斧”最后分享一个面试中的救命技巧叫“排查问题三板斧”。不管面试官抛出一个你没实际遇到过的问题你都可以用这套方法论来接“第一先复现确定稳定复现还是偶发偶发问题先抓现场日志第二沿着调用链路逐层排查前端、网关、服务、数据库、中间件每一层看日志和监控指标第三找到根因后先止血恢复可用性再讨论根治方案。”这个方法论几乎能应对所有“线上问题排查”类的问题无论是“内存溢出怎么排查”还是“接口突然变慢怎么处理”套上三板斧至少能保证你不冷场。但这招绝对不能滥用。如果面试官问的是具体的“你用jstack看过线程状态吗”你就得老老实实讲你看过的案例比如遇到过死锁时线程状态是BLOCKEDCPU飙高时用top -Hp pid找到线程ID再jstack定位业务代码。这些细节没有实际的排查经历是编不出来的。所以我一直觉得面试技巧能帮你把八十分的真实水平发挥到九十分但没法把六十分包装成九十分。踏踏实实把手头项目的坑都填一遍天然就是最好的面试准备。这三次热搜词里还包括了“java后端完整成长路线”“java基础面试题”“java学习路线”说明很多人还在打基础的阶段。我得说一句大实话微服务和数据库设计的大题是给有一定项目经验的人准备的。如果你的Java基础还不够扎实HashMap的底层实现、并发编程的synchronized和volatile区别、JVM内存模型这些还没吃透先别急着啃微服务。把基础打牢再上架构层面的东西顺序反了会很痛苦。基础题决定你能不能进场架构和数据库题决定你能走多远两者的优先级都很高但时间安排上请一定先基础后架构。