Django开发中何时需使用startapp命令创建新应用

首先说权威资料的获取渠道：不用找十几年前的老讨论，你当前使用的Django对应版本的官方文档中，「Applications」「Reusable apps」两个章节就是最权威的现行规范，所有内容都是跟着版本同步更新的，完全适配现在的AppConfig、自动发现机制等设计，那些2008年的回答针对的是Django 1.0之前的版本，当时的app设计逻辑和现在差异极大，参考价值很低。

实操选型判断标准 #

我从Django 1.8用到现在5.0版本，团队里拆app基本就看三个维度，从来没出过问题：

• 看复用性：如果这部分功能抽离出来，改改配置就能直接用到其他Django项目里，比如通用的第三方登录、文件上传管理、评论系统这类，就单独用startapp建应用；如果是和当前项目业务100%绑定、换个项目根本用不上的逻辑，比如某定制营销活动的专属规则计算，就没必要单独拆，放在项目核心目录的业务模块里就行。
• 看业务边界：如果一组模型、视图、模板完全围绕同一个独立业务域展开，和其他模块的耦合度很低，比如电商系统里的售后模块，所有逻辑都是围绕退款、退货申请、售后审核走的，和商品、订单模块只有少量外键关联，就适合拆成独立app；如果只是几个零散的工具函数、没有独立数据模型的简单视图，硬拆app纯属于增加目录层级，找代码都麻烦。
• 看协作成本：如果是多人协作开发的中大型项目，不同人负责不同业务块，拆成独立app之后大家各自维护自己模块的路由、模型、测试用例，能大幅减少代码合并冲突，权限划分也更清晰；如果是个人做的小工具、展示类站点，总共加起来不到10个页面，硬拆七八个app完全是给自己添堵。

几个常见误区 #

不要把拆app当成必须走的流程。startapp本质就是个脚手架命令，帮你自动生成Django约定的app默认文件结构（apps.py、models.py、admin.py这些），你手动按结构建目录效果完全一样，没有任何特殊魔法，不用把它当成什么必须严格遵守的开发仪式。
别走到两个极端：既不要为了“符合规范”硬拆一堆只有几行代码的空app，把路由配置绕得层层叠叠；也不要把所有代码都堆在和项目同名的根目录下，等你找一个视图要翻二十多个文件的时候，就该拆模块了。

拆app没有绝对的对错标准，只要你自己和团队找代码方便、维护成本低，就是合适的拆分方式。

内容的提问来源于stack exchange，提问作者Matías Rivas