配置与业务数据必须严格分离：settings.py、环境变量、配置类等仅容静态参数；用户ID、订单号等动态数据须从请求、DB或缓存实时获取，禁止硬编码或模块级初始化。
Python 配置写进 settings.py 但混了业务数据
配置文件里塞数据库连接、API 密钥这类静态参数没问题，但一旦把用户 ID、订单号、时间戳等动态业务数据也硬编码进去，就等于把运行时状态固化成配置——下次重启服务，这些值不会更新，甚至可能直接报错。
常见错误现象：KeyError 找不到预期的订单 ID；AttributeError 访问一个本该由请求生成却在模块加载时就初始化失败的对象；线上环境用测试用户的 token 调用生产接口。
- 业务数据必须从请求上下文、数据库或缓存中实时获取，不能出现在
settings.py或任何模块级变量初始化位置 - 如果非要用“类配置”方式组织业务参数，改用函数封装，比如
get_current_user_id()，而不是CURRENT_USER_ID = get_user_from_db() - Django 项目尤其要注意：所有在
__init__.py或apps.py中执行的代码，在 Django 启动时就会运行，此时还没有 request 对象
用 os.environ 加载配置时混入业务值
环境变量适合传入部署相关参数（如 DATABASE_URL），但它不是业务数据的中转站。把临时生成的 token、session key、加密 nonce 写进 os.environ，不仅污染进程环境，还可能被子进程继承、日志误打、甚至泄露到监控系统。
使用场景：CI/CD 注入密钥、容器启动时指定 Redis 地址——这些是启动前就确定、整个生命周期不变的值。
立即学习“Python免费学习笔记（深入）”；
-
os.environ是进程级全局状态，修改后无法安全清理，也不支持线程/协程隔离 - 业务数据该走参数传递就传递，该走局部变量就局部变量，别图省事往
os.environ塞 - 若真需要“运行时配置”，优先考虑依赖注入或上下文管理器（如
contextvars.ContextVar）
配置类里定义了 @property 却依赖业务状态
写一个 Config 类，里面用 @property 包一层数据库查询，看起来很优雅，实则埋雷：这个属性会在每次访问时触发查询，而配置类通常被当成单例反复引用，容易造成 N+1 查询、连接泄漏，或者在异步环境中引发事件循环阻塞。
性能影响：一次 HTTP 请求里多次读取 config.current_tenant，结果每次都在查库；单元测试因为没 mock 掉这个 property，直接连真实 DB。
- 配置类只做静态映射，所有带 IO、依赖 request、需鉴权的逻辑，必须移出配置层
- 如果必须动态计算，明确拆成
get_tenant_config(request)这类函数，让调用方控制时机和上下文 - 检查 IDE 提示：如果
config.xxx的类型提示是Any或没提示，大概率已经脱离了配置语义
Django settings.py 里 import 了 models 或 views
这是最隐蔽也最危险的混用：表面上只是加了一行 from myapp.models import User，实际导致 Django 在启动时就加载模型，进而触发数据库连接、信号注册、迁移检查——而此时 DB 可能还没 ready，或者配置还没完全加载完毕。
错误信息典型如：django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.；或者更诡异的 ImportError 循环，因为 models 又反向 import 了 settings。
- settings 文件必须保持“纯数据 + 环境判断”，禁止任何 import 涉及 app 层代码
- 需要动态决定模型行为？用字符串形式延迟引用，比如
AUTH_USER_MODEL = 'myapp.CustomUser' - 真要根据业务条件切换配置项？用函数包装，例如
def get_cache_timeout(): return 300 if is_production() else 10，但函数体里也不能 import models
config，而在它是否随请求变化、是否需要上下文、是否承担副作用。越早把这两者物理隔离，后面 debug 越少翻车。 
