同一Django项目内通过API分离前后端的方案是否可行？

你的架构思路完全合理，是兼顾API复用需求和Django原生开发体验的高性价比方案，尤其适合副业项目快速迭代的场景，没有原则性的设计问题。

架构的核心优势 #

你设计的「纯JSON输出API应用 + 调用API渲染模板的前端应用」拆分逻辑，本质是在同一个Django项目内做了清晰的服务层/表现层分层，好处非常明确：

• 业务逻辑完全收敛在API应用中，后续如果要接移动端、小程序、第三方服务，直接复用现有API即可，不需要重复开发核心逻辑
• 前端应用完全保留Django视图、模板、路由、表单等成熟组件的开发体验，不需要额外搭前端工程化链路、学习新的前端框架语法，开发效率远高于Django API + React的分离栈
• 两个应用同属一个Django项目，共用配置、数据库、用户体系，本地开发不需要启动多套服务、跨域调试，排查问题的成本很低

现存痛点的优化建议 #

你提到的「Cookie存JWT维护会话便捷性差」的问题，本质是硬套了跨域前后端分离场景的鉴权方案，完全可以用更适配你当前架构的方式解决：

• 内部前端调用API直接使用Django原生Session认证即可：两个应用同根域部署的前提下，请求会自动携带Cookie中的sessionid，API侧开启SessionAuthentication权限类，和传统Django项目的鉴权逻辑完全一致，不需要手动存取、传递Token，几乎没有额外开发成本
• 如果后续需要对外开放API能力，再单独给API增加JWT/APIKey鉴权入口即可，内部调用和外部调用的鉴权逻辑完全隔离，互不干扰
• 如果一定要用JWT，也可以把Token注入、校验逻辑写到Django中间件里，前端视图层不需要手动处理Cookie读写、请求头注入的逻辑，能省掉大量重复代码

架构维护注意点 #

要保证长期可维护，只需要守住一个边界：所有数据模型、核心业务逻辑都统一放在API应用中，前端应用只负责参数校验、调用API、渲染模板，不要在前端应用里直接写数据库查询、业务处理逻辑，避免分层失效导致后续API没法独立复用。

内容的提问来源于stack exchange，提问作者Pierre Anken