很多后端初学者写项目时最容易出现一个问题所有代码都堆在接口函数里。接口里既接收参数又查数据库又写业务逻辑又调第三方 API又拼返回结果。刚开始能跑后面一改就崩。分层架构就是为了解决这个问题。【一、为什么要分层】不分层的代码通常是这样路由函数- 校验参数- 查询数据库- 判断权限- 调用模型 API- 写日志- 返回结果所有逻辑混在一起问题是- 难测试。- 难复用。- 难定位问题。- 换数据库或换模型 API 很麻烦。- 新人看代码很痛苦。分层后每一层只做自己的事。【二、常见三层结构】后端项目里常见Controller / API 层处理请求和响应Service 层处理业务逻辑Repository / DAO 层处理数据库访问在 FastAPI 里Controller 通常就是 router。【三、API 层做什么】API 层负责- 接收 HTTP 请求。- 解析路径参数、查询参数、请求体。- 调用 Service。- 返回响应。- 处理状态码。API 层不应该写大量业务规则。示例router.post(/knowledge-bases)def create_kb(req: KnowledgeBaseCreate, userDepends(get_current_user)):kb kb_service.create_kb(user_iduser.id, namereq.name)return kb它只负责把请求转给 Service。【四、Service 层做什么】Service 层负责业务逻辑。例如创建知识库class KnowledgeBaseService:def create_kb(self, user_id: int, name: str):if self.repo.exists_by_name(user_id, name):raise BizError(知识库名称已存在)return self.repo.create(user_iduser_id, namename)这里的规则是同一个用户不能创建重名知识库。这种规则不应该散落在多个接口里。【五、Repository 层做什么】Repository 层只关心数据访问。class KnowledgeBaseRepository:def exists_by_name(self, user_id: int, name: str) - bool:return self.db.query(KnowledgeBase).filter_by(user_iduser_id,namename).first() is not None它不应该关心 HTTP也不应该关心前端传了什么。【六、为什么这样更适合测试】如果业务逻辑在 Service 层你可以单独测试def test_create_kb_duplicate_name():service KnowledgeBaseService(fake_repo)with pytest.raises(BizError):service.create_kb(user_id1, name默认知识库)不用启动整个 Web 服务也不用真的连数据库。【七、AI 项目更需要分层】AI 应用后端里经常还有这些组件- LLM Client调用大模型。- Retriever检索知识库。- Tool Executor执行工具。- Workflow编排多步骤流程。- Prompt Builder拼接提示词。- Evaluator评估输出。如果不分层Agent 项目很容易变成一坨流程代码。推荐API 层提供接口Service 层业务流程Workflow 层Agent/RAG 编排Client 层调用 LLM、向量库、外部 APIRepository 层保存用户、任务、日志、文档【八、常见坑】- 为了分层而分层小项目拆得过碎。- Service 只是简单转发没有业务价值。- Repository 里写大量业务判断。- API 层直接写 SQL。- 所有工具类都叫 utils最后 utils 巨大无比。- 类名很高级但实际代码没有清晰职责。【九、面试常问】1. 为什么后端项目要分层分层可以让请求处理、业务逻辑和数据访问职责清晰降低耦合便于测试、复用和维护。2. Service 层和 Repository 层区别是什么Service 层负责业务规则和流程编排Repository 层负责数据库读写不应该关心 HTTP 请求和业务流程。3. 分层是不是越多越好不是。分层要服务于复杂度。小项目可以简单拆复杂项目再增加领域服务、客户端、工作流等层次。