配置和代码必须严格分离，代码只负责加载、类型转换与校验配置，配置应通过环境变量、.env文件、YAML/JSON/TOML或远程配置中心等外部源管理，敏感信息严禁硬编码。
配置和代码在 Python 项目中必须严格分离——代码定义“怎么做”，配置决定“做什么”或“用什么值”。混在一起会导致环境切换困难、安全风险（如密钥硬编码）、协作冲突和部署失败。
配置应独立于代码文件
把配置写进 .py 文件（比如 config.py）看似方便，实则危险：容易被意外提交到 Git、难以按环境区分、无法被非开发者安全修改。正确做法是使用外部配置源：
-
环境变量（推荐用于敏感项和运行时差异，如
DATABASE_URL、DEBUG=True） -
.env文件（配合python-dotenv加载，适合本地开发） - YAML/JSON/TOML 配置文件（适合结构化、多环境配置，如
config.yaml） - 远程配置中心（如 Consul、Apollo，适合微服务集群）
代码只负责读取和校验配置
Python 代码不应包含任何具体配置值，只做三件事：加载、类型转换、必要校验。例如：
✅ 好的做法：
立即学习“Python免费学习笔记（深入）”；
import os<br>from pydantic import BaseSettings<br><br>class Settings(BaseSettings):<br> db_url: str = os.getenv("DATABASE_URL", "")<br> debug: bool = False<br><br> class Config:<br> case_sensitive = False<br><br>settings = Settings()❌ 避免的做法：
# config.py<br>DEBUG = True<br>DATABASE_URL = "postgresql://user:pass@localhost/db"
这样写会让测试环境也连上生产数据库，且密码明文暴露。
按环境分层管理配置
不同环境（dev/staging/prod）应有不同配置，但共用同一套代码。推荐结构：
-
config/base.py：通用默认值（如日志级别、基础路径） -
config/dev.py：本地调试专用（启用 debug、mock 服务） -
config/prod.py：生产约束（关闭 debug、设置超时、启用监控） - 通过
ENV=prod python app.py或环境变量动态加载对应配置
敏感信息绝不进代码仓库
API 密钥、数据库密码、JWT 秘钥等必须由运维或 CI/CD 注入，而非写在文件里。可借助：
-
os.getenv("SECRET_KEY")直接读取系统环境变量 - Kubernetes Secrets / Docker Swarm configs
- CI/CD 工具的加密变量（GitHub Actions Secrets、GitLab CI Variables）
- 本地开发用
.env，但确保.gitignore包含它
不复杂但容易忽略：配置不是代码的附属品，而是系统行为的控制开关。把它管好，项目才真正可维护、可迁移、可信任。
