Python配置复杂度应通过AST解析统计嵌套字典深度、If节点数及Call表达式频次，避开exec/eval；pycodestyle与radon对配置文件效果有限，deepdiff可量化多环境差异，隐式加载逻辑才是复杂度黑洞。
用 ast 解析源码统计结构复杂度
Python 没有内置的“配置复杂度”指标，但实际中所谓“配置复杂”，往往指 settings.py 或 config.py 里嵌套太深、条件分支太多、动态计算逻辑过重。最直接的办法是把配置文件当普通 Python 模块解析成 AST，再数关键节点。
常见错误现象：ImportError 或 NameError 在导入配置时才暴露，说明变量依赖关系混乱；getattr(settings, 'XXX') 频繁失败，反映属性访问路径不可靠。
- 只对纯 Python 配置文件有效（不支持
.env或 YAML） - 避开
exec()、eval()动态执行的配置段——AST 看不到运行时行为 - 重点统计
Dict嵌套层级、If节点数量、Call表达式出现频次（比如大量os.getenv()或pathlib.Path()） - 示例：用
ast.walk()扫描Dict节点，递归计算keys的最大嵌套深度
pycodestyle 和 radon 对配置文件效果有限
这两个工具默认面向业务代码，对配置文件容易误判。比如 radon cc（圈复杂度）会把 if DEBUG: 算作一个分支，但配置里的条件通常只是开关，不增加真实维护负担。
使用场景错位：它们擅长测函数内逻辑分支，但配置文件的“复杂”常来自数据组织方式（如多层嵌套字典映射环境），而非控制流。
立即学习“Python免费学习笔记（深入）”；
-
pycodestyle报E501 line too long在配置里很常见，但拉长一行字典不如拆成多行可读——这时该忽略 -
radon raw统计行数/注释比有用些，但radon cc数值参考价值低 - 若硬要用，建议限定范围：
radon cc -s config.py，并手动过滤掉顶层赋值语句（Assign节点）
用 deepdiff 量化不同环境配置的差异量
真正的复杂度常藏在“多个配置文件之间细微却关键的差别”里，比如 prod.py 和 staging.py 只差两行，但其中一行是 DEBUG = False → True，就可能引发泄露。
这不是静态分析能覆盖的，得靠对比。
- 安装：
pip install deepdiff - 核心操作：
DeepDiff(config_prod, config_staging, ignore_order=True) - 重点关注输出里的
values_changed和type_changes—— 类型从str变int或值从'https'变'http'都算高风险差异 - 避免直接比整个模块对象，先用
{k: v for k, v in vars(module).items() if not k.startswith('_')}提取公开配置项
别忘了配置加载时的隐式复杂度
很多问题不出现在配置文件本身，而出现在加载逻辑里：比如 django-environ 自动转换类型、pydantic-settings 的字段验证、或自定义的 Config.from_yaml() 方法。
这些会让“写配置”和“生效配置”之间产生 gap，而这个 gap 就是复杂度黑洞。
- 检查是否用了
environ.Env.read_env()—— 它会递归加载.env并覆盖 Python 配置，此时 AST 分析完全失效 - 如果用了
pydantic.BaseSettings，注意Field(default_factory=...)会在每次访问时重新计算，不是静态值 - 最易忽略的一点：
import顺序。比如from .base import *; from .prod import *导致后者覆盖前者，但 AST 看不出覆盖关系
配置复杂度最难量化的部分，永远在 import、覆盖、运行时求值这三步交界处。
