企业官网建设流程全解析

1. 为什么后端代码一定要分层

先说个身边的真实场景。前两年团队里来了个刚转行的新人，第一次独立负责一个订单查询接口，他直接在 Controller 里写了五十行 SQL 拼接逻辑，把数据库连接、字段映射、JSON 组装全部塞进一个方法里。接口上线第一周没出问题，第二周产品说要加一个字段，他改了两处；第三周要加一个权限判断，他改了四处；第四周那个大方法已经膨胀到两百多行，他彻底不敢动了。后来我帮他重构，拆成 Controller、Service、Mapper 三层，改一个需求只需要动一层，他跟我说的第一句话是：“原来代码还能这么写？”这不是他笨，是我们太习惯把“分层”当成理所当然，却很少跟新人解释清楚：分层到底解决的是什么问题。

分层架构的核心逻辑，跟组织一个公司是一个道理。老板（Controller）只负责接待客户（前端请求），把客户的需求记下来，然后转给业务部门（Service）；业务部门负责理清楚业务流程、校验规则、事务边界，再把“需要存下来的数据”交给仓储部门（DAO）；仓储部门只管跟数据库打交道，把数据存进去、取出来，其他一概不管。任何一个部门出了问题，只换掉这个部门就行，其他部门不受影响。这就是分层的第一价值和意义：隔离变化、各司其职、降低耦合。国内绝大多数后端项目，只要不是玩具项目，都跑不出 Controller、Service、DAO、Model 这四层框架。

1.1 不分层到底会出什么事

有人觉得小项目不分层更快，这个观点我部分认同，但它有个前提：项目生命周期不超过一个月，且永远不会迭代。只要项目要活过三个月，要加需求、修 bug、换人维护，不分层的代价就会显现出来。我见过最典型的反面教材，是某 ERP 项目里一个查询报表的接口，方法体四百多行，里面混着权限校验、数据解析、Excel 导出、日志记录、异常处理，六种职责五花八门挤在一起。产品要求加个导出字段，开发改了三天，因为要在一堆业务堆里找字段的源头，改完导出又发现数值格式不对，再去翻数据转换的逻辑。这还只是改代码，最痛苦的是测试：这个方法没有清晰的输入输出边界，写单元测试根本无从下手，只能靠人工点页面验证。

分层架构的第二个价值是标准化。团队里有五个人，如果每个人都有自己习惯的代码风格，那这个项目就是灾难。分层架构给所有人定了一个心照不宣的规范：请求进来找 Controller，逻辑处理找 Service，数据访问找 DAO。新人入职看代码，只要分层清晰，不用问人就能顺着调用链读下去。我招人面试时，最看重候选人能不能说清自己项目里每个类的职责。说不清楚的人，写出来的代码大概率是一锅粥。

1.2 经典分层模型长什么样

最经典的 Java 后端分层长这样：

• Controller 层：接收 HTTP 请求，做参数初步校验（格式、必填项），调用 Service 层，把结果封装成统一响应体。
• Service 层：编写业务逻辑，事务控制、业务规则校验、调用 DAO 层获取数据、组装返回对象，这是核心层。
• DAO 层（Mapper）：只做数据库的增删改查，不写业务规则，不拼装复杂业务对象。
• Model 层（Entity/DTO/VO）：承载数据流转的对象，Entity 对数据库表，DTO 对接口传输，VO 对视图展示。

这个模型不是什么高深理论，是 Java 生态多年实践沉淀下来的最佳实践。Spring Boot 更是把这一套固化进了框架，你新建一个项目，天然就是 Controller、Service、Mapper、Entity 的包结构。RuoYi 这类开源后台管理框架，把这一套玩到了极致，你打开它的源码，哪怕没写过 Java，也能一眼看出代码的组织方式。这就是分层的魅力——它让程序员的思维有了一个统一的坐标系。

1.3 从三层到四层：模型对象该放哪

很多初学者搞不明白 Entity、DTO、VO 有什么区别，为什么要拆得这么碎。简单解释一下：Entity 是跟数据库表一一对应的对象，比如 user 表里有个 id、name、password，这些字段可能是内部数据，不该暴露给前端。DTO（数据传输对象）是接口层的契约，比如前端提交注册请求，可能只需要 name 和 password，但不需要 id 和 create_time，这时候就该用 DTO 来接收，而不是直接把 Entity 暴露出去。VO（视图对象）是给前端展示用的，比如用户列表页要展示 name 和 avatar，但不需要 password，VO 就是干这个的。分这些对象不是追求设计模式，而是为了让接口契约和数据模型解耦——数据库表结构改了，只要不动接口契约，前端就感知不到变化。

2. 一次请求穿过各层时发生了什么

光知道分层结构还不够，得知道一次请求穿过各层时发生了什么。我常说的一句话是：程序员要有“请求视角”，你的思维得跟着一次请求从头走到尾，这样出了问题才知道去哪一层排查。

2.1 从 URL 到数据库的完整调用链

拿前后端分离项目最常见的场景举例：前端调用GET /api/user/1获取用户信息。这条请求的真实路径是这样的：

第一站是网关层（如果有的话）。大型项目通常有 Nginx 或 Spring Cloud Gateway 做路由，把/api开头的请求转发到后端服务，同时做鉴权、限流、跨域处理。小项目可能没有网关，请求直接打到 Spring Boot 内置的 Tomcat。

第二站是 Controller 层。Spring 的 DispatcherServlet 根据 URL 映射找到对应的 Controller 方法，通过@PathVariable拿到路径参数 id，然后调用 UserService 的 getUserById 方法。这里有一个很容易忽略的点：Controller 其实不应该持有任何业务逻辑，它只做“翻译”工作——把 HTTP 请求翻译成 Java 方法调用，再把 Service 返回的对象翻译成 JSON 响应。很多人把参数校验放在 Controller 里用@Validated做，这没问题，但注意这仅限于格式校验，比如“id 必须是数字”“name 不能为空”。业务校验像“用户不能删除自己”，必须放到 Service 层，因为业务校验往往需要查库或者依赖上下文状态。

第三站是 Service 层。这是业务逻辑的大本营。UserService 接收到 Controller 传过来的 id 后，先做必要的业务判断，比如这个用户是否存在、是否有权限查看，然后调用 UserMapper 的 selectById 方法。事务边界一般也在这里声明，@Transactional注解标注在 Service 方法上，这样一个方法内所有 DAO 操作要么全部成功，要么全部回滚。

第四站是 DAO 层。UserMapper 的 selectById 执行 SQL，MyBatis 会根据 XML 或注解生成 SQL 语句，返回 User 对象后，Service 层再决定是直接返回 Entity，还是转成 DTO/VO 再返回。最后 Controller 把对象交给 Jackson 序列化成 JSON 回给前端。

这条链路听起来简单，但每一步都有讲究。很多性能问题、安全隐患、数据一致性问题，都藏在层与层之间的边界上。比如 Service 层查询一个用户，结果发现 Controller 返回时把密码也带出去了，这就是没做好 DTO/VO 分离的典型坑。

2.2 事务边界为什么必须划在 Service 层

事务边界这个问题，可以说是分层架构里最容易踩坑的地方，没有之一。新手最常见的问题是：在 Controller 里调用两次 Service 方法，然后用@Transactional标注 Controller 方法，试图让两次调用处于同一个事务里。这在 Spring Boot 里是不生效的。原因很简单：Spring 的声明式事务是基于 AOP 代理实现的，只有通过 Spring 代理对象调用的方法才会被拦截，而 Controller 本身不参与业务代理，事务拦截器压根不会处理 Controller 上的@Transactional。哪怕你用编程式事务，把事务控制写在 Controller 里，也会让 Controller 承担了太多职责，破坏分层。

正确的做法是：如果两个数据库操作必须保证原子性，就把它们封装在同一个 Service 方法里，在 Service 方法上标注@Transactional。比如转账操作，扣款和加款必须在一个事务里，那就写一个 transferMoney 方法，内部调用两次 DAO 操作。这才是事务边界的正确划法：事务应该跟业务用例绑定，而不是跟 HTTP 请求绑定。反面的例子也看过不少：把两个独立业务操作硬塞进一个事务里，结果并发场景下数据库锁冲突频繁，性能急剧下降。事务粒度太大和太小都是问题，分层架构解决的是“放在哪一层”，粒度问题还是要靠业务分析来把控。

2.3 分层与前后端交互的接口设计

后端分层架构越成熟，对接口设计的约束就越明显。现在的项目基本都是前后端分离，前端团队和后端团队通常是两拨人，接口契约就是他们之间的“合同”。这个合同必须在 Controller 层彻底固化下来。我负责过的项目里，最头疼的就是接口不规范：有的接口返回{code: 0, data: {...}, msg: "成功"}，有的接口只返回一个裸对象，还有的接口错误码五花八门，前端拿到之后不知道该怎么处理。后来我们统一封装了一个Result类，包含 code、message、data 三个字段，所有接口都返回这个结构，前端只需要对该结构做一次统一处理即可。

再一个常见的接口细节是“重复提交”。前后端对按钮重复提交的校验方法，本质上是后端在 Controller 或 Service 层做幂等控制。最简单的方式是用 Token 机制：前端在渲染表单时先向后端请求一个令牌，提交请求时带上令牌，后端处理完后令牌失效。更高效的做法是使用 Redis 的 SETNX 命令，同一个业务 ID 在短时间内只能被处理一次，这样可以防止用户双击按钮导致重复下单。这个校验的实现位置，我的建议是：令牌的生成和校验放在 Controller 或一个 AOP 切面里，而业务 ID 去重的逻辑放在 Service 层，因为后者涉及真实的业务数据判断。分层的好处在这里体现得淋漓尽致：不同粒度的校验天然落在不同层。

更令人头疼的是跨域问题。前后端分离后，前端跑在http://localhost:3000，后端跑在http://localhost:8080，浏览器的同源策略会直接拦截请求。解决跨域的方式很多：CORS 跨域资源共享、Nginx 反向代理、JSONP（现在基本淘汰了）。我建议在后端如果采用的是 Spring Boot，直接用一个@CrossOrigin注解或者配置一个 CorsFilter 搞定局部或全局的 CORS，后端配置 CORS 本质上是响应头Access-Control-Allow-Origin的控制。要注意的是，跨域配置一般放在 Spring MVC 或是网关层，而不应该深入 Service 层，原因很直觉：跨域是 HTTP 层面的问题，跟业务逻辑没有关系，不该进入业务层。这个例子可以很好地说明，分层架构不仅是代码结构的问题，更是责任边界的问题。

3. 不同技术栈下的分层实现对照

分层架构这套思想不是 Java 的专利。我接触过用 Python 写后端的朋友，问我说 FastAPI 这种框架怎么分层，我只能说套路是一样的，只是语言生态里工具不同。优秀的分层架构都是相似的，混乱的代码各有各的乱法。

3.1 Java Spring Boot：标准三层落地实操

Spring Boot 项目里，我比较推荐的包结构是这样的：

com.example.project ├── controller # 接收请求，返回响应 ├── service # 业务逻辑接口 │ └── impl # 业务逻辑实现 ├── mapper # MyBatis 的 Mapper 接口 ├── entity # 数据库实体 ├── dto # 入参/出参对象 ├── vo # 视图对象 ├── config # 配置类 └── common # 公共工具、统一响应等

这个结构最核心的约束是依赖方向：Controller 依赖 Service，Service 依赖 Mapper，永远不允许反着来。Service 接口和实现的分离，是 Java 项目里的常见约定，它的好处是方便测试时用 Mock 替换真实实现，也是给未来实现切换留了一条路。不过如果你只是个小项目，接口+impl 的写法其实有点过度设计，我见过很多团队直接把 Service 写成具体类，没接口也活得好好的。我的建议是：看团队规模和项目复杂度来定。如果项目超过五个开发，接口+impl 值得上；如果就两三个人写一个后台管理项目，直接让类互调反而更高效。

RuoYi 这个开源框架我提过很多次，它的分层就是教科书级别，但也有值得警惕的地方。RuoYi 里很多查询方法是直接在 Service 层写 SQL 字符串的，代码是简单了，但这么做境界远不如 MyBatis 的 XML 映射。你可以参考它的业务分层和组织结构，但不要盲目照搬它的 SQL 风格。分层架构的意义在于职责清晰，而不是为了分层而分层，写 SQL 的方式也要跟随团队规范走。

3.2 Python FastAPI：轻量分层怎么落地

Python 后端和 Java 后端的最大差别在于，Python 多以异步为主，框架更灵活，约束更少，所以分层架构更要靠自觉。FastAPI 是我现在看 python 后端最喜欢用的框架之一，因为它的依赖注入系统和类型提示让代码很优雅。用 FastAPI 写分层架构，推荐的结构是：

app ├── api # 路由层，对应 Controller │ └── v1 │ └── user.py ├── schemas # Pydantic 模型，对应 DTO/VO ├── services # 业务逻辑层 ├── models # SQLAlchemy ORM 模型 ├── repositories # 数据访问层（可选） └── core # 配置、安全、常用工具

最关键的一点是：路由处理函数要轻。FastAPI 的Depends机制可以很方便地做依赖注入，比如把数据库 Session、当前用户信息注入到路由函数里，但尽量不要在路由函数里写业务逻辑。我见过一些 FastAPI 项目，路由函数三五行就调 service，清晰的井井有条。但也见过不少项目，pydantic 模型啥校验都不写，路由函数里全是 SQLAlchemy 的 query，后期维护时基本靠猜。FastAPI 的分层要义在于利用类型提示把层与层的接口契约钉死，比如定义一个CreateUserRequestschema，你很难传错参数，因为这会在编译期就暴露问题（实际上运行期会做校验，但是经验的教训值得推广这个做法）。

3.3 前后端分离项目里后端分层的位置

前后端分离对后端分层的影响，不只是接口格式的问题，它还改变了后端的部署形态和团队协作方式。以前 Java Web 项目用 JSP，前端页面和后端代码混在同一个 WAR 包里，分层主要是为了代码可维护性。现在前后端彻底分离，后端完全变成一个 API 服务，前端是独立的工程，两者通过 HTTP 交互。这个转变让后端分层变得更纯粹：Controller 层就是 API 入口，Service 层就是业务核心，DAO 层就是数据库访问。

对后端开发来说，接口契约的稳定性和幂等性成为新的核心命题。以前页面的状态在后端 session 里，现在 token 一抛，后端完全无状态。这也决定了分层里要引入一层“鉴权逻辑”，比如 Spring Security 或自定义拦截器处理 JWT，这个逻辑通常放在 Controller 层的外围（过滤器、拦截器层），不污染业务层。很多同学会混淆拦截器和 AOP 切面，简单说：拦截器工作在 Spring MVC 的请求链路里，可以拿到 HttpServletRequest；AOP 切面工作在 Bean 方法调用链里，通常不能直接拿 HTTP 原始对象。两者的职责边界不同，导致它们在后端分层中扮演不同角色。

4. 分层架构里最常见的坑与排查方法

分层架构本身不复杂，复杂的是在分层架构里写代码时踩的坑。这么多年下来，有几类问题出现的频率极高，几乎每个后端项目都躲不过。它们不是分层的错，而是分层不彻底、边界不清晰导致的。

4.1 循环依赖：ServiceImpl 互相引用的病怎么断

循环依赖是 Spring 项目里最让人头大的问题之一。A 类调 B 类，B 类调 A 类，Spring 启动时就会报BeanCurrentlyInCreationException。面对这种情况，新手往往是给一个类加@Lazy注解，或者把 Bean 作用域改成 prototype，但这是治标不治本。循环依赖的本质是业务边界没划干净，A 和 B 的职责存在纠缠。

我整理一个很典型的场景：OrderServiceImpl 需要调用 UserService 查询用户信息，UserServiceImpl 又需要调用 OrderService 查询用户最近的订单。这看起来合理，实际上暴露了一个设计问题：查询“用户最近订单”这个需求到底属于订单域还是用户域？如果属于订单域，那 UserService 就不该反过来依赖 OrderService；如果属于用户域，那 OrderService 也不该依赖 UserService。合理的做法是把查询用户信息的逻辑抽成一个更底层的服务，比如 UserQueryService，或者干脆让 OrderService 直接调 UserMapper，跨过 Service 层。这个原则在分层里也很重要：同层之间的互相调用要克制，跨层调用要有明确的箭头方向。如果箭头绕成环，说明你的业务拆分需要重新审视。

Spring 官方在新版本里默认禁止了循环依赖，这其实是好事，逼着开发者把设计做清楚。

4.2 事务注解失效与异常的坑

@Transactional失效的场景，网上的“八股文”总结已经很多了，我挑几个实际工作中真正遇见的。

第一个是同类内部调用。ServiceImpl 里的一个公共方法调用了同类里的另一个被@Transactional标注的方法，事务会失效。原因是 Spring AOP 代理只拦截外部调用，内部this调用不会经过代理。解决办法是把被调方法拆到另一个类，或者注入自身的代理对象，最干净的是重新设计方法边界——内部方法不要自己控制事务。

第二个是异常被吞。@Transactional默认只在 RuntimeException 回滚，如果你捕获了异常不抛出，事务就不会回滚。我的习惯是：Service 层完全不捕获异常，让异常向上抛到 Controller 层的全局异常处理器统一处理。这样代码清爽，也保证了事务边界不会被异常处理逻辑打断。

第三个是数据库引擎不支持事务。MySQL 里 MyISAM 引擎不支持事务，如果一个项目用了 MyISAM，你会很奇怪为什么事务不生效。好在现在的新项目基本都用 InnoDB，这个问题正在消失，但它曾经踩过的人不少，值得提。

4.3 层与层之间的对象转换与性能

分层带来了对象转换的开销，这是一个常被诟病但没法避免的问题。Entity 转 VO，DTO 转 Entity，每层之间都要 copy 一遍数据。Java 里最常用的工具是 MapStruct，它在编译期生成转换代码，性能好而且类型安全。也有团队习惯用 BeanUtils.copyProperties，用起来确实便捷，但它是反射实现的，性能差一些，且字段名不一致时会静默地不复制，容易埋坑。我的建议是：项目里统一选一种方案，不要混用，否则后期排查数据丢失问题时会非常痛苦。

另一个跟性能相关的点是“N+1 查询”问题。Service 层循环调用 DAO 层查询，比如查一个订单列表，然后对每个订单查一次用户信息，这就产生了 N+1 次查询。要解决它，需要在 DAO 层设计批量查询接口，或者在 Service 层做数据聚合。分层架构在这里的作用是：性能问题定位迅速，ORM 层的查询优化和业务组装逻辑分开，不会把 SQL 优化和业务代码搅在一起。这也是我去面试时最爱问的问题之一：你的分层层级很清晰，那你的 N+1 查询在哪一层解决？能答得上来的，是真做过项目的。

4.4 电子签名、授权等场景在分层中的位置

最近做电商类项目时，遇到了电子签名前后端实现的需求。这类功能很有代表性，因为它涵盖“签名请求生成-签名操作-签名校验”三个环节，分别对应不同的分层位置。签名请求生成涉及业务数据的封装和摘要计算，放在 Service 层；签名操作往往需要前端配合，比如调用第三方 SDK 在页面上采集签名，后端只需要接收签名结果并保存；签名校验放在 Service 层或一个独立的签名服务中。这个例子告诉我们，即便是领域感很强的功能，分层架构依然能给出清晰的职责归属。有些团队把所有第三方工具类调用都塞进 Controller，等到签名逻辑要复用时就傻眼了，因为 Controller 的方法无法被另一个需要签名的业务调用。正确做法永远是：外部系统交互逻辑封装成 Service，Controller 只负责暴露 HTTP 端点。

5. 分层架构的本质：职责边界与演进方向

聊了这么多，其实都在围绕一个核心词展开：职责边界。分层架构之所以能经历这么多年而不衰，是因为它符合人类组织复杂系统的天性——把大问题拆成小问题，让每个小问题有一个明确的归属。理解了这一点，再去看各种复杂架构模式，你会发现很多都是分层思想的衍生。

5.1 贫血模型与充血模型的边界选择

经典的三层架构，一般配合“贫血模型”使用：Entity 只有数据没有行为，数据操作都放在 Service 层。这种模型的好处是简单直观，缺点是不符合面向对象思想，领域行为散落在 Service 里，当业务逻辑复杂时，Service 会变得巨大无比。后来的 DDD 领域驱动设计提倡“充血模型”：把领域逻辑放进实体里，Service 层只负责编排。两种模型的取舍，本质上是一个“逻辑放哪里的问题”：贫血模型把行为放 Service，充血模型把行为放领域对象。对于大多数后台管理系统来说，贫血模型完全够用；如果你的业务复杂度已经到了需要 DDD 的程度，那意味着你可能不再需要传统三层架构，而是需要按业务模块划分“限界上下文”。

我想说的是，分层不是死的。它可以横着分层（Controller/Service/DAO），也可以竖着切模块（订单域/用户域/商品域）。两者不冲突，甚至可以混合使用。我参与过的多个 Java 后端项目中，模块合并的要点就是：先确认竖切边界，再确认横向依赖方向。换句话说，不同业务模块之间的依赖关系要清楚，同一模块内部才是经典的垂直分层。合并两个项目时，最怕的是 A 模块的 Service 直接调 B 模块的 Controller，这种跨模块依赖一旦形成，项目就会越来越拧巴。

5.2 后端面试八股文里的分层考点

市面上流传的 Java 后端面试八股文里，分层架构相关的问题出现概率极高。这既是好事也是坏事。好事是它沉淀了行业共识，坏事是很多人只记住了答案，不理解背后的逻辑。常见的问题我梳理几个：

• “Controller 层能不能直接操作数据库？”答案当然是不能，但更值得思考的是为什么不能。因为 Controller 的职责是处理 HTTP，一旦它开始操作数据库，职责就混乱了，无法单独测试，也无法复用。
• “Service 抛异常还是返回错误码？”这个问题没有标准答案，但主流做法是抛异常，由全局异常处理器统一映射为错误响应。返回错误码会让业务逻辑里到处是 if-else 判断，可读性极差。
• “分层后 Service 层太臃肿怎么办？”我建议把 Service 拆分成多个职责单一的小 Service，或者引入领域服务层。一般做到这一步，说明你的业务复杂度已经超越了简单的 CRUD。

面试官问这些问题时，最想听到的不是背诵，而是你的理解。比如问事务为什么放在 Service 层，你要说清楚 AOP 代理的机制，说清楚“一次业务用例，一个事务边界”的设计原则。这也是我写这篇文章的初衷：把知识点背后的原理讲透，而不是让读者死记硬背。

5.3 AI 辅助开发对分层架构的影响

最近 AI+后端开发的话题非常热，我也实践了挺长一段时间。AI 工具对分层架构的影响，我认为是双向的。一方面，AI 让写代码的速度大幅提升，但它生成代码时更倾向于“平铺直叙”，常常一把梭把逻辑都写在一个方法里，这对分层架构产生了冲击。比如我用 ChatGPT 生成一个用户管理接口，它给你的代码大概率是 Controller 里直接调用 Mapper，省略了 Service 层。因为它只关心“实现功能”，不关心“如何组织代码”。这就需要一个有经验的开发者来规整它。

另一方面，AI 也能辅助分层设计。你给 AI 描述业务流程，让它生成 Service 层的方法签名和 DAO 层的接口，它通常能给出不错的结果。关键是要给 AI 清晰的上下文，比如先定义好分层的目录结构，再让它在各层填充代码。AI 不是银弹，它不会自动帮你维护架构，但它可以帮你省去写重复代码的体力活。分层架构的思想在 AI 时代不是过时了，而是变得更难得——因为默认的 AI 输出往往是反分层的。

5.4 芯片后端与软件后端的“分层”之争

顺便说一个有意思的现象。热词里出现了“芯片后端”和“数字后端”，这其实是半导体行业里的概念。芯片后端（Back End）指的是芯片设计流程里的物理设计阶段，比如布局布线、时钟树综合、时序收敛，这和软件后端完全是两码事。我曾经被一个转行做 FPGA 的同事问“你们后端和我们的后端有啥关系”，我说唯一的共同点可能是“都是整个流程里属于后段的部分”，但解决的问题完全不同。分层架构里的“后端”特指服务器端开发的代码组织方式，而“芯片后端”是硬件设计的重要阶段。这两种“后端”放在一起，很容易让新人混淆。其实每个行业都有自己的“后端”，在技术社区里交流时，最好先确认对方的“后端”是软件还是硬件语境，免得把话题聊岔了。写到这里，我想起曾经做的一个前后端分离项目，后端用 Java Spring Boot，前端用 Vue。后期维护时，我们就是靠分层边界来确定修改目标：前端报错先看接口返回，接口报错进 Controller 入口，业务数据错进 Service，数据库字段错进 Mapper。这套排查路径，每个新人都能快速学会，这就是分层架构给团队带来的最朴素的价值。它不是高深的学术理论，而是一种让团队所有人用同一种方式思考问题的方法论。不管你是写 Java、Python，还是做前端跨到后端，只要你写的代码背后有数据、有状态、有业务规则，分层这件事就值得你认真对待。