Django能否将自定义设置写入settings.py？有无更优存放方案？

你把自定义业务配置写进项目settings.py的操作完全是官方允许的常规操作，不存在任何违规。Django从来没有给settings.py设置“只能存放官方文档定义的核心配置”的限制，这个模块从设计上就是项目全局的通用配置容器。

官方对settings模块的核心定位是：承载项目所有运行相关的参数，你可以根据业务需求在文件里追加任意自定义的全局配置变量，框架本身不会对这些自定义变量做特殊校验或拦截。

你之前把配置散落在各个独立应用的constants.py里的做法也能正常运行，但集中放到settings里会解决很多实际维护的痛点：

• 统一查找入口：所有全局可调的参数集中在同一文件，新成员接手项目时不需要翻遍各个应用目录找配置项，维护成本低很多
• 天然适配多环境切换：可以直接复用Django现成的多环境配置拆分机制（比如开发/测试/生产环境配置分离），让自定义配置也能跟着环境动态调整，不用单独写跨应用的常量加载逻辑
• 读取逻辑统一：所有配置都可以通过django.conf.settings对象统一读取，和读取Django内置配置的写法完全一致，不用写一堆跨模块导入各个应用constants.py的零散代码

为了避免配置混乱，社区通用的最佳实践是这些：

• 自定义配置项保持全大写命名风格，和Django内置配置的命名规则对齐，比如你之前写的HOURS_PER_EVENT、MAX_MEMBERS_PER_EVENTS这类命名就完全合规
• 只往settings.py里追加自定义配置，不要随意篡改Django内置配置的默认逻辑，避免破坏框架的正常运行
• 保持settings.py的纯常量属性，不要在里面写复杂的业务执行逻辑
• 如果自定义配置项数量特别多，没必要把所有零散常量都堆在settings.py里，避免把文件搞得又长又难读

要是觉得自定义业务配置和Django内置配置堆在同一个文件里观感不好，可以根据实际场景选择更灵活的存放位置：

• 在项目根目录新建统一的配置模块，按业务域拆分存放公共常量，适合配置项规模比较大、需要按业务模块分类管理的场景
• 那种只和单个应用强绑定、不需要跨应用共享、也不需要按环境动态调整的常量，完全可以继续留在对应应用的constants.py里，还能减少跨应用的耦合

内容的提问来源于stack exchange，提问作者Johnny Metz