setup.cfg 已被 pyproject.toml 取代，因其不支持动态逻辑、环境标记和现代构建后端声明，且工具链全面转向 toml；python 3.13 移除 distutils 后其底层支撑消失，仅作为静态兼容层存在。
setup.cfg 无法声明构建后端，pip 23+ 默认跳过它
pyproject.toml 的 [build-system] 是 PEP 517 强制要求的唯一入口点。只要项目里存在 pyproject.toml，pip 就会忽略 setup.cfg 和 setup.py，直接按其中的 build-backend 和 requires 执行构建。即使你把所有元数据都写进 setup.cfg，只要没在 pyproject.toml 里声明构建系统，pip install . 就可能降级到 legacy 模式并报 DEPRECATION: Legacy setup.py install is deprecated。
setup.cfg 不支持动态逻辑，但真实项目总需要它
版本号从 Git tag 读取、依赖根据 Python 版本条件启用、README 内容自动注入 long_description——这些操作在 setup.py 里用几行代码就能搞定，但 setup.cfg 是纯 INI 格式，不支持表达式、函数调用或环境变量展开。结果就是：要么退回写 setup.py（违背“配置与逻辑分离”初衷），要么用 pyproject.toml 配合现代后端（如 hatchling 或 setuptools 的 dynamic 字段）来实现。
-
setup.cfg里写version = 0.1.0是静态的，改版就得手动编辑 -
pyproject.toml可写dynamic = ["version"]，再配[tool.setuptools.dynamic.version]自动拉取 -
setup.cfg无法表达install_requires = ["requests; python_version >= '3.8'"]这类环境标记
工具链已转向 pyproject.toml，setup.cfg 成为兼容层
poetry、pdm、hatch、rye 这些主流工具默认只读 pyproject.toml；pytest ≥ 6.0 虽仍支持 [tool:pytest] 在 setup.cfg 里，但新特性（如插件注册、路径模式匹配）只在 pyproject.toml 中生效；black、ruff、mypy 等工具压根不查 setup.cfg，必须用 [tool.black] 这类 TOML 块。
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
更关键的是，Python 3.13 已彻底移除 distutils，而 setup.cfg 的解析逻辑深度耦合在旧版 setuptools 的 distutils 兼容层中。它没被删除，但已失去底层支撑——就像还在用软盘驱动器接口的 USB 设备，能转，但没人再优化它。
真正被边缘化的不是文件本身，而是它的定位
setup.cfg 没有错，它只是被设计成一个过渡性配置载体：当项目只需要静态元数据 + 简单依赖时，它足够轻量；但一旦涉及构建流程控制、跨平台条件、CI/CD 集成或团队协作规范，它就暴露了表达力边界。现在几乎所有新项目初始化（hatch new、pdm init、poetry init）都直接生成 pyproject.toml，连 setup.py 和 setup.cfg 都不再创建——不是因为它们不能用，而是因为没必要再绕一圈。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
