Python 工程现代化：uv、Ruff、Pyright、pytest、pre-commit 的组合实践——横纵综合报告 未开始

题记与说明

课题：Python 工程现代化：uv、Ruff、Pyright、pytest、pre-commit 的组合实践
场景约束：Windows 单人项目模板视角
时间截面：2026-10-31
文档性质：终稿（2026-10-31 按独立审读意见逐条修订后定稿）

综合说明：本报告由同课题两份章节稿综合而成——纵轴稿（output/reports/parts/2026-10-31-Python工程现代化-uv-Ruff-Pyright-pytest-pre-commit-vertical.md，发展脉络）与横轴稿（output/reports/parts/2026-10-31-Python工程现代化-uv-ruff-pyright-pytest-precommit-horizontal.md，横向对比）。两稿之间存在三处版本号/日期矛盾，综合时已用当日一手数据（PyPI JSON API 与 GitHub REST API 实时查询）逐一裁定，裁定过程与结论见文末"两稿矛盾勘定记录"。凡两稿中无法从一手来源证实的信息，本报告继续显式标注"未经核实"，不做润色性消除。本次终稿按八条独立审读意见逐条修订：钩子运行器建议前后接榫（TL;DR、2.4、2.6、3.6）、"两条命令、两份配置"落地（TL;DR、2.7）、"模板收敛"等论断补源或标注（1.1、1.2、1.5）、交叉引用写法统一（3.2、3.4）、Pyright 速度数字补口径（2.4）、Ruff 规则数与 formatter style 两组说法调和（2.3）、PEP 逐条括注与参考来源补全（1.2、1.6、1.8、五）、模板骨架可操作性补全（3.6）；由此新增的"未经核实"事项一律并入文末未核实清单。

TL;DR

Python 工程五件套（uv、Ruff、Pyright、pytest、pre-commit）是碎片化工具链收敛的产物：PEP 把配置收敛进 pyproject.toml，Rust 重写把检查压到秒级，Astral 以 ruff→uv→ty 完成一体化。2026-10-31 截面上五个槽位四个一边倒，本组合即最优默认解；最重的双向选择是类型检查——VS Code 选 Pyright，忌 Node 选 Mypy；钩子运行器是配置零修改的可换项——默认 pre-commit，在意 commit 速度与磁盘换 prek（裁定见 2.6）。对 Windows 单人项目性价比处历史最高点，两条命令换来自动质量防线：① 装 uv 一条 powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"，② 项目内 uv sync 一条；两份配置即 pyproject.toml 与 .pre-commit-config.yaml（口径说明见 2.7）。风险是 uv/Ruff 仍 0.x、默认值破坏性演进，模板应锁版本、显式声明规则，以 pre-commit run --all-files 兜底。

一、纵轴：发展脉络——五件套是怎么凑齐的

组合实践的五个成员不是同期出生的。它们跨越 Python 工程化二十余年历史，各自先解决一个长期痛点，最后才在 2024 年前后作为"一个组合"齐装满员。纵轴要回答的问题是：为什么是这五个工具、为什么是现在。

1.1 今日快照（2026-10-31 勘定版本）

版本来源：纵轴稿第 0 节版本表 + 横轴稿槽位总表；本次综合于 2026-10-31 用 PyPI JSON API 重新查询裁定（curl https://pypi.org/pypi/<包名>/json，实测：ruff 0.17.3、pytest 9.2.0、uv 0.13.6、pre-commit 4.7.0、pyright 1.1.414），并用 GitHub API 核实了 Ruff 0.17.0（2026-10-09）、0.17.3（2026-10-27）、0.16.0（2026-07-23）与 uv 0.13.6 的发布时间。加粗两项为对纵轴稿版本的勘误，详见文末勘定记录。

\* Pyright 行注：版本号 1.1.414 经 PyPI 实查属实，但其 releases 页不显示年份，"2026-09-09"中的年份部分系按版本顺序与上下文推断（见 1.6 节注与文末勘定记录），非本报告直接核实。

1.2 阶段〇（2004–2021）：史前史——五个痛点，五次先行解决

• pytest（2004）：Holger Krekel 创建的 py.test，最初是 pylib 的一部分，后独立发展（初稿所记"为测试 PyPy 而写""Armin Rigo 参与早期开发"两个细节超出本行所引两个通用来源的覆盖范围，未经核实，见文末未核实事项）。凭"无样板代码 + fixture + 断言重写"逐步取代 unittest 树与 nose（nose 后来无人维护，pytest 成事实标准）。来源：Python Wiki 测试工具分类（https://wiki.python.org/moin/PythonTestingToolsTaxonomy ）、pytest 官方文档（https://docs.pytest.org/ ）。
• pre-commit（2014）：Anthony Sottile 在 Yelp 期间创建，首次公开发布约 2014 年 5 月——他在 Talk Python to Me #282 中回忆："The first public version of pre-commit, I believe, was May of 2014"。它把散落各处的 git hooks 变成可版本化、可共享、跨语言的配置文件。1.0.0 发布于 2017-09-07，2.0.0 发布于 2020-01-28。来源：https://talkpython.fm/episodes/show/282/pre-commit-framework 、https://github.com/pre-commit/pre-commit/blob/main/CHANGELOG.md 。
• Pyright（2019）：2019 年 3 月，Microsoft 的 Eric Traut 发布开源静态类型检查器 Pyright——TypeScript 编写、面向 VS Code 生态、主打大代码库高性能，与 mypy 形成双雄。2020 年其引擎被产品化为闭源的 Pylance 语言服务器。来源：Hacker News 发布讨论（https://news.ycombinator.com/item?id=19473631 ）、https://github.com/microsoft/pyright 。
• 生态地基（2016–2021）：PEP 518（2016，pyproject.toml 声明构建依赖）、PEP 517（构建后端接口：规定 pyproject.toml 如何声明构建系统、后端以标准钩子产出 sdist/wheel）、PEP 621（2021，项目元数据）逐步把散落在 setup.py、requirements*.txt、setup.cfg 里的配置收敛进一个 TOML 文件。没有这一步，"五件套共享同一配置面"的组合实践无从谈起。来源：https://peps.python.org/pep-0518/ 、https://peps.python.org/pep-0621/ 。
• 模板时代前身（2020）：cjolowicz 的 cookiecutter-hypermodern-python 是"组合实践"第一个成熟范式：Poetry + black + isort + mypy + pre-commit + nox + GitHub Actions。它证明了"一套标准工具链 + 一个脚手架"的价值，也暴露了痛点——工具太多、配置分散、链路脆弱，该仓库现已归档无人维护。来源：https://github.com/cjolowicz/cookiecutter-hypermodern-python 。

阶段驱动因素：工具链碎片化（lint 有 flake8 十几个插件、格式化有 black、排序有 isort、环境有 virtualenv/pyenv/pipx/poetry 各管一摊）让单人项目和中小团队维护成本高企，"整合"的土壤已经成熟。

1.3 阶段一（2022–2023）：Ruff 崛起，整合的苗头

• 2022 年年中，Charlie Marsh（其后创立 Astral）发布 Ruff：Rust 编写的极快 Python linter，聚合 flake8、isort、pyupgrade 等工具的数百条规则，替代"flake8 + 插件全家桶"。2022 年 11 月已密集移植 flake8 插件规则（如 flake8-pyi，见 issue #848）。来源：https://github.com/astral-sh/ruff 、https://github.com/astral-sh/ruff/issues/848 。
• 2023-01-23，pre-commit 3.0.0 发布。
• 2023-10，Ruff formatter 以 beta 亮相——官方宣称比 Black 快 30 倍以上、兼容率 99.9% 以上（https://x.com/charliermarsh/status/1716861072374657497 ）。Pyright 同期以 1.1.x 稳定迭代。

变化驱动：Rust 重写带来数量级性能红利，加上一家公司（Astral）以"用 Rust 重做一遍 Python 工具链"为统一战略。快不只是体验问题：单人项目只有当检查快到无感时，才愿意每次提交都跑——这句判断是后文交叉洞察的伏笔。

1.4 阶段二（2024）：五件套成型之年

• 2024-01，pytest 8.0.0 发布，移除 nose 风格 setup()/teardown() 兼容层（弃用始于 7.2）。来源：https://docs.pytest.org/en/stable/deprecations.html 、https://docs.pytest.org/en/stable/changelog.html 。
• 2024-02 中旬，Astral 发布 uv 0.1.0：Rust 写的 pip/pip-compile 替代品，安装提速 8–10 倍、部分解析场景可达百倍，全球缓存 + 并行下载。来源：https://astral.sh/blog/uv 。
• 2024-02-29，Ruff 0.3.0：formatter 去掉"Beta"标签正式稳定（对齐 Black 24.1.0 stable style）。来源：https://github.com/astral-sh/ruff/blob/main/changelogs/0.3.x.md 、https://astral.sh/blog/ruff-v0.3.0 。
• 2024-08，uv 0.3.0（官方博文"Unified Python packaging"）是关键一跃：uv python install（替代 pyenv）、uvx/uv tool run（替代 pipx）、uv init + uv.lock + workspace（项目管理）。一个 Rust 二进制覆盖 pip/pip-tools/virtualenv/pyenv/pipx/poetry 的大部分场景，明确支持 macOS、Linux、Windows。来源：https://astral.sh/blog/uv-unified-python-packaging 。
• 2024 年初，DetachHead 分叉 Pyright 创建 basedpyright：把闭源 Pylance 特性带回开源语言服务器，并提供 pre-commit 集成。来源：https://github.com/DetachHead/basedpyright 。
• 2024-10-05，pre-commit 4.0.0 发布（框架自身要求 Python 3.9+）。同年 PEP 735（dependency-groups）被接受，uv 在 0.4.x 末尾支持 [dependency-groups]，dev 依赖从此有了标准归宿。来源：https://peps.python.org/pep-0735/ 。

变化驱动：pyproject.toml 全面收敛（PEP 723 内联脚本元数据 2023 年接受后，单文件脚本也能声明依赖）；"一个工具干掉五个工具"的降本诉求；Astral 以 Ruff 积累的信誉背书 uv，社区迁移阻力骤降。

1.5 阶段三（2025）：组合实践成为默认答案

• 2025-04，uv 0.7.0：Astral 实行"约每 30 个版本集中一次破坏性变更"的政策。来源：https://github.com/astral-sh/uv/blob/main/changelogs/0.7.x.md 、https://github.com/astral-sh/uv/issues/10808 。
• 2025-05，Astral 将自研类型检查器 Red-Knot 更名 ty 并公开推进——Pyright/mypy 之外出现第三个重量级选项，且与 ruff/uv 同门。来源：Talk Python #506（https://talkpython.fm/episodes/show/506/ty-astrals-new-type-checker-formerly-red-knot ）。
• 2025 年夏，uv 0.8.0 起将 uv_build 设为 uv 管理项目的默认构建后端。来源：https://github.com/astral-sh/uv/blob/main/changelogs/0.8.x.md 。
• 2025-10-07，双发布：Ruff 0.14.0 默认目标切到 Python 3.14；uv 0.9.0 把 Python 3.14 设为默认稳定版、自由线程变体免显式 opt-in——两者同步吃下 2025-10 发布的 Python 3.14 红利。来源：https://github.com/astral-sh/ruff/blob/main/changelogs/0.14.x.md 、https://github.com/astral-sh/uv/blob/main/changelogs/0.9.x.md 。
• 2025-11，pytest 9.0.0 发布：最低要求 Python 3.10+（3.9 于 2025-10 EOL），历史弃用项转错误。来源：https://docs.pytest.org/en/stable/changelog.html 。
• 2025 年，prek（j178 用 Rust 重写的 pre-commit 兼容实现）走红：单二进制零依赖、启动约 26ms 对 pre-commit 约 177ms（约 7 倍）、钩子环境省约 50% 磁盘。pre-commit 的 .pre-commit-config.yaml 格式经 prek 反向确认为"事实标准"。来源：https://github.com/j178/prek 。
• 模板收敛：2025 年的社区模板几乎清一色是 uv + ruff + pytest + pre-commit +（pyright/mypy/ty 三选一）：monologg/python-template（https://github.com/monologg/python-template ）、copier-astral（https://github.com/ritwiktiwari/copier-astral ，围绕 Astral 工具链的 Copier 模板，本次修订已补源；其中"后改用更快的 prek"一说未在仓库页核实到，未经核实）、pytemplate-uv 2.0（https://github.com/yuxuzi/pytemplate-uv · https://pypi.org/project/pytemplate-uv ，本次修订已补源；"2025-01"发布时间未经核实），另有《Effective Python Developer Tooling》（2024-12）等指南定调（本次修订补源：实为 Tim Hopper 的文章"Effective Python Developer Tooling in December 2024"而非书，https://pydevtools.com/blog/effective-python-developer-tooling ）。

变化驱动：默认值收紧（默认规则集、默认 Python 版本随 3.14 提升）；"uv 一把梭 + pre-commit 把关"成为单人/小项目省心解；Astral 全家桶形成平台效应。

1.6 阶段四（2026-01 – 2026-10-31）：一体化、安全化与"开箱即严"

• Ruff 0.15.0（2026-02-03）：2026 formatter style、块级抑制注释；至 0.15.22（2026-07-16）持续加入 preview 规则。来源：https://github.com/astral-sh/ruff/blob/main/changelogs/0.15.x.md 。
• uv 0.10.0（2026-02 初）：又一轮集中破坏性变更（0.10.12，2026-03-19）。来源：https://github.com/astral-sh/uv/blob/main/changelogs/0.10.x.md 。
• uv 0.11.0（2026-03-23）：网络栈重构（reqwest 0.13 + rustls-platform-verifier + aws-lc）；系列内出现 uv audit（预览，JSON/SARIF 输出）、uv check 直接调用 ty 做类型检查——包管理与类型检查在 CLI 层合流的标志性一步；另支持 PEP 803（abi3t：为自由线程构建引入的新稳定 ABI——PyObject 结构不透明化、Py_TARGET_ABI3T 编译开关、abi3t wheel 标签与 Py_mod_abi 运行时 ABI 检查槽位；uv 支持它值得记，因为安装器要能识别 abi3t 标签的 wheel，自由线程解释器才有可用的扩展分发通道——此"支持"的具体含义未在 changelog 逐条核对，见文末未核实事项），至 0.11.33（2026-07-28）。来源：https://github.com/astral-sh/uv/blob/main/changelogs/0.11.x.md 。
• Ruff 0.16.0（2026-07-23，GitHub API 本次核实）：最大的一次默认行为变更——默认规则集从 59 条扩到 413 条（同时移除 18 条固执的 pycodestyle/pyflakes 规则）；默认格式化 Markdown 文件中的 Python 代码块；推出 ruff: ignore 抑制体系。至 0.16.10（2026-10-01）加入 Python 3.15 支持；0.17.0 于 2026-10-09 发布（本次 GitHub API 核实，纵轴稿撰写时 changelog 尚未收录 0.17 系列），当前最新 0.17.3（2026-10-27）。来源：https://github.com/astral-sh/ruff/blob/main/changelogs/0.16.x.md 、https://github.com/astral-sh/ruff/releases 。
• uv 0.12.x（2026-07-28 起）：uv init 默认生成 uv_build 构建系统；0.12.12（2026-09-09）Windows/macOS 可执行文件开始代码签名与公证；0.12.18（2026-09-22）修复 Windows 安装 wheel 时的路径穿越漏洞（GHSA-2cv4-cqwr-gwf7）；0.12.24（2026-10-08）。当前最新 0.13.6（releases 页为第一来源；main 分支 changelogs/ 下暂无 0.13.x.md，0.13.x 明细未逐条核对）。来源：https://github.com/astral-sh/uv/blob/main/changelogs/0.12.x.md 、https://github.com/astral-sh/uv/releases 。
• Pyright：1.1.407（2025-10，默认 Python 版本 3.13→3.14）→ 1.1.410（2026-05，更快 tokenizer、Node 升至 22.x）→ 1.1.412（2026-08，实现 PEP 800《Disjoint bases in the type system》的 disjoint-base 语义——该 PEP 由 Jelle Zijlstra 提出、面向 Python 3.15，用 @typing.disjoint_base 装饰器标记不相交基类，两个拥有不同不相交基类的类不能有共同子类，帮类型检查器做可达性、无效多继承与重载安全分析；TypeForm 收尾、新增独立 Type Server Protocol 服务器）→ 1.1.414（2026-09-09，pyright-typeserver 发布到 npm）。Eric Traut 仍主导维护（另有个人开发分叉 erictraut/pyright2）。注：Pyright releases 页不显示年份，上述年份按版本顺序与上下文推断。来源：https://github.com/microsoft/pyright/releases 、https://github.com/erictraut/pyright2 。
• pre-commit 4.7.0（2026-10-12）：原生框架仍在活跃维护，与 prek 生态并行。来源：https://github.com/pre-commit/pre-commit/blob/main/CHANGELOG.md 。

变化驱动：Astral 把"lint/格式化（ruff）+ 包管理（uv）+ 类型检查（ty）"统一到一个 CLI 体验下；默认安全水位提高（签名、漏洞响应）；Ruff 用"默认规则大扩容"把最佳实践变成出厂设置。

1.7 Windows 专项：从二等公民到一等公民的十年

• pre-commit 的 Windows 修复史说明它能用但需留意版本：0.4.0 才有"MVP Windows support"，此后陆续修 node hooks（1.5.0）、docker hooks（1.18.0）、subst 盘符（2.9.3/2.11.0）、批处理命令长度（2.12.0）、shebang（2.17.0）、R.exe 选择（2.21.0）、cygwin 兼容（2.7.1/2.8.0）。来源：https://github.com/pre-commit/pre-commit/blob/main/CHANGELOG.md 。
• uv 消灭了 Windows 上最疼的三件事：装 Python——uv python install 自带独立 CPython 构建（含 Windows 构建），不污染系统 Python，而 pyenv 在 Windows 上只有残缺的第三方移植 pyenv-win；建环境——uv run 免激活，PowerShell venv activate 的种种别扭不复存在；装依赖——Rust 并行下载 + uv.lock 跨机复现。Windows 官方安装路径一应俱全：powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"、winget install --id=astral-sh.uv -e、scoop install main/uv，并文档化 PowerShell 自动补全。来源：https://docs.astral.sh/uv/getting-started/installation/ 。
• uv 的 Windows 安全化：0.12.12 起二进制签名/公证（企业策略与 SmartScreen 更友好）；0.12.18 修复路径穿越漏洞——工具链在 Windows 上已进入"有安全团队盯"的阶段。
• 类型检查在 Windows：Pyright 本体 TypeScript 编写，经 npm 或 PyPI 包装器（自动获取 Node）分发均可运行；编辑器内可用 Pylance（闭源）或 basedpyright（开源、含 Pylance 特性）。来源：https://github.com/microsoft/pyright 、https://github.com/DetachHead/basedpyright 。

1.8 贯穿全程的驱动因素（六条）

1. 性能即采纳率：Ruff/uv 的 Rust 重写把"分钟级"变"秒级"，直接改变单人项目"愿不愿意每次提交都跑检查"的行为模式。
2. 标准化收敛：pyproject.toml 及配套 PEP——518（声明构建依赖）、517（构建后端接口，见 1.2 节括注）、621（项目元数据）、723（内联脚本元数据，见 1.4 节）、735（依赖组，见 1.4 节）——让五个工具共用同一配置面，模板才能"一个文件说清全部"（工具链同时跟进的还有非配置类 PEP：面向 Python 3.15 的 PEP 800 类型系统与 PEP 803 自由线程稳定 ABI，均见 1.6 节括注）。
3. 一体化战略：Astral 用 ruff→uv→ty 三步统一 lint、包管理、类型检查，uv 0.11 的 uv check 调 ty 是 CLI 层合流标志。
4. 默认值即最佳实践：Ruff 0.16 默认 413 条规则、pytest 9 强制 3.10+、uv 默认 uv_build——"开箱即严"降低单人项目做对事情的门槛。
5. 安全与信任水位：uv 的签名公证与漏洞修复节奏、pre-commit 长达十年的 Windows 修复史，说明工具链同时面向个人桌面与企业环境。
6. Windows 从二等公民到一等公民：uv 原生三平台、签名、漏洞响应，加上 pre-commit 逐年修平刺点，"Windows 单人项目"第一次能和 macOS/Linux 团队共享同一套模板。

二、横轴：横向对比——2026-10-31 时间截面

2.1 方法：把"组合实践"拆成五个能力槽位

本课题不是单一工具，而是一条工程工具链的组合方案。正确的对比做法不是找"五合一"竞品（不存在），而是把组合拆成五个能力槽位，逐槽位找出竞品与替代方案，再回到组合整体层面与替代路线对比。

版本来源：横轴稿当日 PyPI JSON API 实查，本次综合已复核（见 1.1 节）。竞品版本（Poetry 2.5.1、Mypy 2.4.1 等）沿用横轴稿 2026-10-31 实查值，本次未逐一复核。

生态热度（GitHub API 实测，横轴稿 2026-10-31 采集）：astral-sh/uv 91,367 stars、astral-sh/ruff 50,337、pypa/poetry 34,323、python/mypy 20,712、astral-sh/ty 19,991、microsoft/pyright 15,720、pre-commit/pre-commit 15,672、pytest-dev/pytest 14,656、j178/prek 8,705；所有核心仓库在截面前 24 小时内均有提交，整条工具链处于高强度维护状态——这是"组合实践"可行性的一项基础事实。

2.2 槽位一：包管理——uv vs Poetry / PDM / Hatch / pixi / pip-tools

要点：uv 的核心竞争力是一个工具覆盖五个工具的职责（1.4 节已述发展过程，此处不再重复）。生态热度差已达 2.7 倍量级（91,367 vs 34,323 stars）；2026 年多篇对比文章指出 uv 的 PyPI 月下载量约为 Poetry 的 2.8 倍（https://pratikpathak.com/uv-vs-pdm-vs-poetry-2026-comparison 、https://stackharbor.com/en/knowledge-base/python-poetry-pdm-uv-comparison ）；JetBrains/PSF 2024 官方开发者调查（3 万+ 受访者，2025-08-18 发布）显示 uv 首年即达 11% 采用率（https://lp.jetbrains.com/python-developers-survey-2024 ）。PDM 标准遵循度最好（https://www.loopwerk.io/articles/2024/trying-pdm ）。

结论：多人团队需要长期稳定 → Poetry 仍是保守正确解；conda 科学计算栈 → pixi；单人新项目、Windows 环境 → uv 几乎没有对手——uv python install 直接下发预编译 CPython 这一点，在本课题场景下最难被替代。风险：0.13.x 仍 <1.0，CLI 与锁文件格式仍可能调整。

2.3 槽位二：Lint + 格式化——Ruff vs 传统四件套

要点：ruff check / ruff format 一对命令替代传统四件套。规则面两个数字的关系：表内"800+ 条"是内置规则总量口径（横轴稿口径，未逐条清点），1.6 节的"59→413 条"是 0.16+ 的默认开启数——"默认到底开多少条"的答案是 413 条，默认开的是子集，其余按 lint.select 显式加。格式化以 Black 兼容为目标，从 Black 迁移几乎零 diff 成本（https://docs.astral.sh/ruff/changelog/ ）；1.6 节所记 0.15 引入的"2026 formatter style"与这一 Black 兼容基线的关系（默认启用哪个 style、与 Black stable style 的差异范围）本报告未逐条核实——迁移策略因此不赌默认值：从 Black 存量代码迁移先跑 ruff format --diff 看改动面再定。风险在默认值演进：0.16.0 的默认规则集变更造成过升级破坏——模板中应显式固定 target-version 与规则选择，而不是依赖默认值。Ruff 已实现 Flake8/Pylint 绝大多数常用规则，但个别深度语义检查（如 Pylint 部分重构建议类检查）仍无对应实现，需要时可以 Ruff + Pylint 按需补位而非全量替换。

结论：个人与中小项目 Ruff 全量替代几乎无争议；超大存量代码库、强依赖 Pylint 特定检查的团队渐进迁移。Ruff 是五个工具里对 Windows 最"无感"的一个——纯原生二进制，不碰 shell、不碰路径坑。

2.4 槽位三：类型检查——Pyright vs Mypy vs ty vs Pyrefly（最重的双向选择；钩子运行器则是配置零修改的可换项，见 2.6）

要点：四者都查 PEP 484 类型标注，"能不能查出错"差异不大；差异在严格模式默认值、增量检查、与编辑器的关系。Pyright 的独特优势是 Pylance：VS Code 的 Python 开箱体验就是 Pyright 引擎，"编辑器所见即检查所得"，CI 里跑同引擎命令行零规则漂移。成本项是 Node 运行时依赖——npm 安装需要 Node；PyPI 的 pyright 包装器会自动获取 Node，缓解但不消除该外部依赖（https://microsoft.github.io/pyright/ 、https://pynions.com/mypy-vs-pyright ）。Pyrefly 已于 2026-05-12 发布 1.0，宣称是 Instagram 2000 万行代码库的默认检查器（https://pyrefly.org/blog/v1.0 ）；ty 仍处 beta，官方博客明确 1.0 目标在 2026 年内（https://astral.sh/blog/ty 、https://pypi.org/project/ty ）。

速度口径专项（本次修订核实）：初稿表内"官方称比 mypy 快 3–5x""2026 年基准称大型库冷启动 5–10x"两说均无法溯源——Pyright 官方 README 只有"为高性能与大代码库设计"的定性表述、无任何倍数，"2026 基准"匿名无链接，两说已删。Pyright 官方实际维护的是每周更新的基准页（https://microsoft.github.io/pyright/typecheck-benchmark/ ，对比 pyright/pyrefly/ty/mypy/zuban，指标为失败数/总耗时/中位耗时/峰值 RSS，页面自警跨 runner 耗时"是独立趋势而非最快排名"）；2026-10-31 抽查该页：总耗时 pyright 463.5s vs mypy 341.5s、中位耗时 pyright 26.0s vs mypy 41.0s——互有胜负，任何"Pyright 比 mypy 快 X 倍"的一概而论本报告不采信。

⚠️ 横轴稿检索中出现"OpenAI 于 2026 年收购 Astral"的说法，仅见于非官方汇总文，未能从任何一手来源证实，本报告不采信。若属实将显著影响 uv/Ruff/ty 走向，属需跟踪的高影响变量。

结论：Windows 单人项目在 VS Code 里工作 → Pyright 是默认正确解（与 Pylance 同引擎）；Django 重度插件需求或不想引入 Node → Mypy；追求极致速度且能接受前沿风险 → 观察 ty 1.0 后切换。

2.5 槽位四：测试框架——pytest vs unittest / nose2 / Robot Framework

结论：这是五个槽位中本课题方案就是行业默认、替代讨论最没有信息量的一个（https://qaskills.sh/blog/alternatives-to-pytest-python-testing-frameworks 、https://blog.jetbrains.com/pycharm/2024/03/pytest-vs-unittest ）。单人项目唯一真实的取舍是"是否为省一个 dev 依赖而用 unittest"——pytest 的 fixture 与参数化在单人维护场景下节省的时间远超一个依赖的安装成本，结论明确：不值得省。pytest 纯 Python 实现，无平台特异问题，uv run pytest 一条命令即可在无全局污染的环境运行。

2.6 槽位五：Git 钩子框架——pre-commit vs prek / lefthook / 裸钩子 / CI-only

要点：pre-commit 的价值主张是"声明式、跨语言、可复用的钩子配置"，15,672 stars 仍是最大生态；prek 是 Rust 重写的 drop-in 替代——配置文件不变、不需要 Python、更快更省磁盘（https://github.com/j178/prek ），2026 年已有多篇实际迁移记录，处于快速上升期。pre-commit 在 Windows 上成本最高：有明确功能性问题记录（https://github.com/pre-commit/pre-commit/issues/2322 ），且 Windows 上 GUI Git 客户端存在静默绕过或吞掉钩子输出的实测案例（Cursor 3.15.6 强制 core.hooksPath 致钩子失效：https://forum.cursor.com/t/git-hooks-silently-skipped-for-all-source-control-operations-since-3-15-6-git-extension-forces-core-hookspath-dev-null/167719 ；VS 不显示钩子输出：https://developercommunity.visualstudio.com/t/git-integration-does-not-show-local-hooks-output/153462 ）。

prek 星级口径（本次修订补足）：上表给 prek 的 Windows ★★★★☆ 衡量的是运行时体验——单二进制免 Python，绕开 pre-commit 十年 Windows 修复史所对应的 Python on Windows 摩擦面（1.7 节），配置全兼容；prek 自身的 Windows 专项修复记录本报告未逐一核实，且本节两条 Windows 风险证据（#2322、GUI 吞输出）均出自 pre-commit 生态，故该星级是推断而非实绩。

结论：多人协作、钩子配置需团队流通 → pre-commit（最大公约数）；单人项目、在意 commit 速度与磁盘 → prek 是 2026 年更优解，配置零修改、随时可切回；lefthook 适合前端混合栈或 Go 生态团队。

裁定（本报告为何默认 pre-commit，而不直接采纳上句"prek 是 2026 年更优解"）：该结论的前提是"在意 commit 速度与磁盘"，但作为报告级默认，本报告仍选 pre-commit——① pre-commit 4.7.0 已成熟稳态，Windows 十年修复史完整（1.7 节），坑有据可查；② prek 仍 0.5.9，快速上升期本身即风险；③ 两者读同一份 .pre-commit-config.yaml，切换配置零修改、随时可逆，默认不必赌新的。执行口径：默认 pre-commit，在意速度与磁盘即换 prek（3.6 第 5 条同此裁定）。

2.7 组合整体 vs 四条替代路线

口径说明（"两条命令、两份配置"落地）：① 命令一——装 uv：powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"（或 winget install --id=astral-sh.uv -e，见 1.7 节官方安装路径）；② 命令二——项目内 uv sync：按入库的 uv.lock 一键重建含 dev 依赖的完整环境。两份配置即 pyproject.toml 与 .pre-commit-config.yaml；3.6 骨架中的 .gitattributes 是 git 仓库属性（换行策略声明）且为可选加固项，不属工具链配置文件，故不计入此数。

逐项：相对 B，五件套的本质收益是收敛——7–9 个工具收敛为 5 个、4–6 份配置收敛为 2 份、安装/解析/检查三个慢环节全部数量级提速；这在单人项目里被放大而非缩小，因为没有同事帮你发现"requirements.txt 又忘了更新"。相对 C，Poetry 只解决包管理，其余槽位仍需选型，在 uv 已成事实标准的 2026 年只剩"团队存量惯性"一个理由。相对 D，仅当依赖 conda-only 二进制包（CUDA 工具链、GDAL 等）时才有不可替代性。相对 E，单人 + AI 助手编程模式下"不配工具"的实际代价是每次让 AI 改代码后靠肉眼复查——五件套把复查自动化，且全链路快到"钩子不拖慢 commit"。

三、交叉洞察：两轴合起来说明了什么

单独看，纵轴是一串版本号，横轴是一堆对比表；合起来，才能回答"这对一个要动手的人意味着什么"。

3.1 洞察一：组合的主导地位是结构性的，不是时尚

纵轴给出的三个结构因素——标准化（PEP 518/621/735 把配置面收敛到一个文件）、性能（Rust 重写把检查压到秒级）、平台化（Astral 三步一体化）——在横轴上对应的结果是：五个槽位中四个呈一边倒，连 pre-commit 的配置格式都被 prek"反向确认为事实标准"。反过来，纵轴上的失败者（nose 无人维护、cookiecutter-hypermodern-python 归档、老式九件套）失败的共同原因不是功能不够，而是协调成本：工具越多、配置越散，单人维护者越养不起。两轴互证：五件套的胜利本质是"把协调成本压到接近零"的胜利，因此只要这个结构因素不变，组合地位短期不会被单个新工具推翻——能推翻它的只有结构变化本身（如 ty 1.0 重组类型检查槽位，或 prek 类兼容层整体取代钩子框架运行时）。

3.2 洞察二：速度改变的不是体验，而是行为

纵轴在阶段一埋下的判断——"单人项目只有当检查快到无感时，才愿意每次提交都跑"——在横轴稿关于单人场景的三个判断中得到呼应。三个判断在此列全（其在本报告中的引述位置随注）：① 单人没有 code review，pre-commit 钩子是"无人值守防线"（见本报告 2.6、3.4 节）；② "工具速度直接决定 AI 辅助开发的迭代频率，分钟级反馈在单人 + AI 模式下会被实际弃用（工具被关掉等于没配）"；③ "未来自己是协作者"——锁文件和统一格式化的价值是六个月后 clone 回来十分钟恢复（见本报告 3.4 节）。两轴合起来说明：Rust 化工具链真正的产品不是"更快的 linter"，而是"不需要意志力的工程纪律"。当 lint/类型/测试全链路亚秒级，pre-commit 钩子才第一次在单人场景里成为"无人值守防线"而不是"被人嫌烦关掉的开关"。对用户而言这意味着：选型时把"单次运行耗时"当作一票否决项，而不是性能加分项——慢工具在单人场景里的终局是被关闭。

3.3 洞察三：默认值即最佳实践，但默认值也是最大的破坏性来源

纵轴的事件线（Ruff 0.16 默认规则 59→413 条、pytest 9 强制 3.10+、uv 默认 uv_build、Astral"每 30 个版本集中破坏一次"的政策）与横轴的教训（"模板应显式固定 target-version 与规则选择，而不是依赖默认值"）是同一枚硬币的两面："开箱即严"降低了做对事的门槛，代价是升级时的行为漂移。对单人项目这不致命（没有下游用户），但会打断"六个月后 clone 回来十分钟恢复可运行"的承诺。结论落在模板纪律上：锁版本（uv.lock 入库 + CI/钩子里用固定版本号）、显式声明规则集与 target-version、升级时主动读 changelog 而非被动等报错。

3.4 洞察四：Windows × 单人，正是该组合价值最大化的交点

本报告 1.7 节（纵轴 Windows 专项）记录了 Windows 从二等公民到一等公民的十年修复史（pre-commit 的 0.4.0 MVP → 2.7.1/2.8.0 的 cygwin 兼容（至 2.21.0 的 R.exe 选择）；uv 的原生构建 → 签名公证 → 路径穿越漏洞应急）；本报告 2.6 节（钩子框架横评）记录了 Windows 上的残留风险（#2322、GUI 客户端静默绕过钩子）。两轴合起来的结论是："单人 + Windows"曾是工程化性价比最低的人群——团队模板默认 macOS/Linux、CI 资源向团队倾斜、钩子框架在 Windows 坑最多；而现在五件套恰好把这个人群变成受益最大的：单人没有 code review，pre-commit 就是第二双眼睛（横轴稿"无人值守防线"判断，见本报告 3.2 节）；单人没有运维，uv sync + uv.lock 就是恢复环境（本报告 1.7 节 Windows 专项）；单人没有预算，全免费开源工具链没有许可成本。横轴稿的"未来自己是协作者"判断（锁文件和统一格式化的价值是六个月后 clone 回来十分钟恢复，见本报告 3.2 节）就是纵轴"复现性"红利的单人版表述。

3.5 洞察五：组合仍未"定型"，0.x 尾部风险要用配置纪律对冲

横轴勘定的版本表暴露了组合的年龄结构：pytest（2004 起源，9.x）与 pre-commit（2014 起源，4.x）已步入成熟稳态，Pyright 稳定迭代，而 uv（0.13.x）、Ruff（0.17.x）、ty（0.0.95 beta）、prek（0.5.9）仍处 0.x/前期——组合里最年轻、变化最快的恰恰是价值密度最高的三个槽位（包管理、lint、以及候补的类型检查）。这不是缺陷而是阶段：Astral 的策略是用快速迭代换地盘。对用户的含义是双重的：享受默认值红利的同时，把"随时可能破坏"写进预期——配置同文件（.pre-commit-config.yaml）让 prek 与 pre-commit 可随时互换、uv.lock 锁定依赖侧、规则显式声明锁定 lint 侧，三道锁把 0.x 尾部风险从"不可控"降为"可逆"。

3.6 对用户的判断与建议

选型决策（按槽位）：

1. 包管理/环境/解释器：uv，无需纠结；仅 conda-only 依赖（CUDA、GDAL 等）选 pixi。
2. Lint + 格式化：Ruff；在 pyproject.toml 里显式写 [tool.ruff] 的 target-version 与 lint.select，不依赖默认值；个别 Pylint 深度检查按需补位。
3. 类型检查（最重的双向选择）：VS Code 用户选 Pyright（编辑器与 CI 零漂移，PyPI 包装器免手动装 Node）；不想引入 Node 或需要 Django/SQLAlchemy 特化插件选 Mypy；ty 待 1.0 后重估。
4. 测试：pytest，不要为省一个 dev 依赖用 unittest。
5. Git 钩子：配置写 .pre-commit-config.yaml；运行器默认 pre-commit（4.x 成熟、Windows 十年修复史完整，见 1.7 节；prek 仍 0.5.9），在意 commit 速度与磁盘换 prek（配置零修改）——这是类型检查之外的第二处分岔，但属"配置零修改的可换项"级分岔，裁定理由见 2.6。

2026-10 版 Windows 单人项目模板骨架（综合两稿，每项均有前文来源；pre-commit 本体的安装与声明、Pyright 配置落点、钩子 rev 固定示例、uv check 取舍为本次修订补全）：

1. uv init（0.12+ 自带 uv_build）。
2. dev 依赖一条声明进 PEP 735 [dependency-groups]：uv add --dev pytest ruff pre-commit pyright——pre-commit 本体与 pyright 都作为 dev 依赖声明（而非全局散装安装），保证"六个月后 clone 回来"可复现；随后 uv run pre-commit install 把钩子写入 .git/hooks。偏爱全局工具者可 uv tool install pre-commit，但共享场景以 dev 依赖声明为准。
3. 类型检查：日常与 CI 用 uv run pyright（PyPI 包装器自动获取 Node，见 2.4），一次性试跑才用 uvx pyright 或 basedpyright（后者含 Pylance 特性，见 1.4）。配置落点二选一：pyproject.toml 的 [tool.pyright]（推荐——与"一个文件说清全部"的收敛目标一致）或独立 pyrightconfig.json（字段更全，含 include/exclude 等部分 pyproject 不支持的选项）。
4. .pre-commit-config.yaml，rev 一律锁定具体版本（呼应 3.3 锁版本纪律），示例：

   repos:
     - repo: https://github.com/astral-sh/ruff-pre-commit
       # Ruff version.（ruff-pre-commit 的 rev 与 Ruff 版本号一一对应，此处锁 1.1 节勘定版本）
       rev: v0.17.3
       hooks:
         - id: ruff-check    # 旧版该 id 为 ruff，以仓库 README 为准
         - id: ruff-format
     - repo: https://github.com/pre-commit/pre-commit-hooks
       rev: v6.0.0           # 锁定该仓库 releases 页当日最新 tag，勿用 main
       hooks:
         - id: trailing-whitespace
         - id: mixed-line-ending

（启用 args: [--fix] 自动修复时，ruff-check 钩子应放在 formatter 之前——README 明言 fix 产出的改动可能需要重新格式化。）

1. 仓库放 .gitattributes 固定 * text=auto eol=lf（git 仓库属性、可选，不计入 2.7 的"两份配置"），本机 git config core.longpaths true 并开启 Windows 长路径支持（pre-commit 至今无官方路径长度钩子，issue #760：https://github.com/pre-commit/pre-commit/issues/760 ）。
2. 把 uv run pre-commit run --all-files（或 prek run --all-files）写成习惯性兜底命令，对冲 GUI Git 客户端静默跳过钩子的风险（见 2.6）。
3. uv check（0.11 起调 ty，见 1.6、1.8）与 Pyright 的取舍：两者实现独立、规则不互通，钩子/CI 里只跑其一，不要双跑——双跑既慢，又可能给出不一致的结论。模板主引擎仍定 Pyright（2.4 结论：Pylance 同源零漂移）；uv check 截至 uv 0.13.6 的可用性与覆盖面本报告未实测（本次修订仅在本机 uv 0.10.8 验证其不存在，与"0.11 起引入"的记载一致），故仅作观察项，待 ty 1.0 后重估（见下"未来变量"①）。
4. CI 可选（单人项目钩子已覆盖大部分场景）。

四个需要盯住的未来变量（横轴结论，纵轴佐证）：① ty 的 1.0（若 2026 年内落地且 uv check 深度整合，类型检查槽位可能重构）；② uv/Ruff 默认值的破坏性演进节奏（每 30 个版本一次集中破坏）；③ prek 对 pre-commit 的替代进度（8,705 stars 快速上升）；④ Astral 归属传闻（未经证实，若证实为高影响事件）。

什么情况下不要用本组合：项目深度绑定 conda 生态 → pixi 路线；团队已有一套运转多年的 Poetry/hook 体系且无痛点 → 迁移收益不抵扰动；强依赖 Pylint 特定深度检查的存量代码库 → Ruff 渐进迁移而非全量替换。

四、两稿矛盾勘定记录

本次综合用当日一手查询裁定两稿之间的全部矛盾，命令与结果如下（均于 2026-10-31 实际执行）：

其余交叉核对一致项：uv 0.13.6、Pyright 1.1.414、pre-commit 4.7.0 两稿版本一致且本次 PyPI 查询吻合；ty 状态两稿兼容（2025-05 更名公开、2025-12 进 beta、目标 2026 年内 Stable、uv check 已可在 CLI 层调用）；prek 数据两稿兼容（约 7 倍启动提速、省约 50% 磁盘、0.5.9、8,705 stars）。

未核实事项（如实声明，沿袭两稿标注；★ 为本次修订新增）：

• "OpenAI 于 2026 年收购 Astral"仅见于非官方汇总文，无一手来源，不采信。
• "GitHub Octoverse 2025 将 uv 列为贡献者增长最快的开源项目之一"出自纵轴稿搜索结果摘要，未核对 Octoverse 原报告。
• Pyright releases 页不显示年份，1.1.405–1.1.414 对应年份（2025-10 至 2026-09）为按版本顺序与上下文推断（1.1 表已加脚注）。
• ty 截至 2026-10 未见 1.0/GA 官方公告；Ruff 官方 1.0 亦未发布（截至 0.17.3）。
• PEP 518/621/723/735 接受年份依据 PEP 官方页与搜索结果，未逐字核对 PEP 正文；pytest 8.0.0 的"2024-01"发布月份来自既有知识，仅核实过其"移除 nose 兼容"的内容。
• 横轴稿的竞品版本号（Poetry 2.5.1、Mypy 2.4.1、prek 0.5.9、lefthook 2.2.2 等）与其 GitHub star 数为横轴稿 2026-10-31 当日 API 实查值，本次综合仅复核了五件套本身的版本号，未逐一复核全部竞品。
• ★ 1.2 节 pytest 起源中"为测试 PyPy 而写、Armin Rigo 参与早期开发"超出所引两个通用来源的覆盖范围，正文已标注"未经核实"。
• ★ 初稿 2.4 表"官方称比 mypy 快 3–5x""2026 年基准称大型库冷启动 5–10x"两说无法溯源（官方文档主页与 README 均无此数，"2026 基准"匿名无链接），终稿已删，改引官方每周基准页并附 2026-10-31 抽查数字（见 2.4 速度口径专项）。
• ★ uv check（调 ty）截至 uv 0.13.6 的可用性与覆盖面未实测；本次修订仅在本机 uv 0.10.8 实测 uv check 报 unrecognized subcommand，与"0.11 起引入"的记载一致。
• ★ prek 的 Windows 专项修复/适配记录未逐一核实，2.6 节星级已注明为"运行体验推断"。
• ★ Ruff 0.15 "2026 formatter style" 与 Black 兼容基线的关系（默认启用哪个 style、与 Black stable style 的 diff 范围）未逐条核实，2.3 节已注明并给出不赌默认值的迁移策略。
• ★ copier-astral"后改用更快的 prek"、pytemplate-uv 2.0 的"2025-01"发布时间：两者本体已核实存在并补源（1.5 节与第五节），这两个子细节未核实。
• ★ uv 对 PEP 803 的"支持"具体指什么（如 abi3t wheel 标签的识别与安装）系按 PEP 内容的合理推断，未在 uv changelog 逐条核对。

五、参考来源

本次综合新增的一手核对（2026-10-31 实际执行）

• PyPI JSON API：https://pypi.org/pypi/{ruff,pytest,uv,pre-commit,pyright}/json（裁定 Ruff 0.17.3、pytest 9.2.0）
• GitHub REST API：https://api.github.com/repos/astral-sh/ruff/releases?per_page=8（0.17.x/0.16.10 发布时间）、https://api.github.com/repos/astral-sh/ruff/releases/tags/0.16.0（2026-07-23）、https://api.github.com/repos/astral-sh/uv/releases?per_page=3（0.13.6）

本次修订新增的一手核对（2026-10-31 实际执行）

• Pyright 速度口径：https://microsoft.github.io/pyright/ （README 无倍数声明）、https://github.com/microsoft/pyright （README 定性表述）、https://microsoft.github.io/pyright/typecheck-benchmark/ （官方每周基准页，2026-10-31 抽查）
• ruff-pre-commit 钩子 id 与 rev 对应关系：https://github.com/astral-sh/ruff-pre-commit （README 示例 rev: v0.17.3、id: ruff-check / ruff-format）
• pre-commit-hooks 最新 tag：https://github.com/pre-commit/pre-commit-hooks/releases （v6.0.0）
• PEP 800/803：https://peps.python.org/pep-0800/ （Disjoint bases in the type system）、https://peps.python.org/pep-0803/ （abi3t: Stable ABI for Free-Threaded Builds）
• 模板/指南补源：https://github.com/ritwiktiwari/copier-astral · https://github.com/yuxuzi/pytemplate-uv · https://pypi.org/project/pytemplate-uv · https://pydevtools.com/blog/effective-python-developer-tooling
• 本机实测：uv 0.10.8 无 uv check 子命令（uv check --help → unrecognized subcommand）

纵轴稿来源

• uv releases：https://github.com/astral-sh/uv/releases · changelogs：https://github.com/astral-sh/uv/blob/main/changelogs/0.7.x.md · https://github.com/astral-sh/uv/blob/main/changelogs/0.8.x.md · https://github.com/astral-sh/uv/blob/main/changelogs/0.9.x.md · https://github.com/astral-sh/uv/blob/main/changelogs/0.10.x.md · https://github.com/astral-sh/uv/blob/main/changelogs/0.11.x.md · https://github.com/astral-sh/uv/blob/main/changelogs/0.12.x.md
• Ruff changelog：https://github.com/astral-sh/ruff/blob/main/changelogs/0.3.x.md · https://github.com/astral-sh/ruff/blob/main/changelogs/0.14.x.md · https://github.com/astral-sh/ruff/blob/main/changelogs/0.15.x.md · https://github.com/astral-sh/ruff/blob/main/changelogs/0.16.x.md
• Pyright：https://github.com/microsoft/pyright/releases · https://github.com/erictraut/pyright2 · https://news.ycombinator.com/item?id=19473631
• pytest：https://docs.pytest.org/en/stable/changelog.html · https://docs.pytest.org/en/stable/deprecations.html · https://docs.pytest.org/
• pre-commit：https://github.com/pre-commit/pre-commit/blob/main/CHANGELOG.md · Talk Python #282：https://talkpython.fm/episodes/show/282/pre-commit-framework · Talk Python #506：https://talkpython.fm/episodes/show/506/ty-astrals-new-type-checker-formerly-red-knot
• Astral 官方博文：https://astral.sh/blog/uv · https://astral.sh/blog/uv-unified-python-packaging · https://astral.sh/blog/ruff-v0.3.0 · https://x.com/charliermarsh/status/1716861072374657497
• PEP：https://peps.python.org/pep-0518/ · https://peps.python.org/pep-0517/ · https://peps.python.org/pep-0621/ · https://peps.python.org/pep-0723/ · https://peps.python.org/pep-0735/ · https://peps.python.org/pep-0800/ · https://peps.python.org/pep-0803/
• 其他：https://wiki.python.org/moin/PythonTestingToolsTaxonomy · https://github.com/cjolowicz/cookiecutter-hypermodern-python · https://github.com/astral-sh/ruff/issues/848 · https://github.com/astral-sh/uv/issues/10808 · https://github.com/DetachHead/basedpyright · https://github.com/DetachHead/basedpyright/issues/27 · https://github.com/j178/prek · https://github.com/monologg/python-template · https://github.com/ritwiktiwari/copier-astral · https://github.com/yuxuzi/pytemplate-uv · https://pydevtools.com/blog/effective-python-developer-tooling · https://docs.astral.sh/uv/getting-started/installation/ · https://github.com/pre-commit/pre-commit-hooks · https://stackoverflow.com/questions/15223290/ · https://github.com/pre-commit/pre-commit/issues/760

横轴稿来源

• PyPI JSON API（横轴稿 2026-10-31 实查）：https://pypi.org/pypi/{uv,ruff,mypy,pre-commit,pytest,pyright,prek,ty,pyrefly,poetry,pdm,hatch,pixi,lefthook,flake8,pylint,black,isort}/json
• GitHub REST API（横轴稿 2026-10-31 实查）：https://api.github.com/repos/{astral-sh/uv, astral-sh/ruff, microsoft/pyright, pytest-dev/pytest, pre-commit/pre-commit, python/mypy, j178/prek, pypa/poetry, astral-sh/ty}
• 包管理对比：https://pratikpathak.com/uv-vs-pdm-vs-poetry-2026-comparison · https://stackharbor.com/en/knowledge-base/python-poetry-pdm-uv-comparison · https://www.loopwerk.io/articles/2024/trying-pdm · https://pydevtools.com/handbook/reference/uv
• 采用率调查：https://lp.jetbrains.com/python-developers-survey-2024
• Ruff：https://docs.astral.sh/ruff/changelog/ · https://github.com/astral-sh/ruff/releases
• 类型检查对比：https://pynions.com/mypy-vs-pyright · https://microsoft.github.io/pyright/ · https://astral.sh/blog/ty · https://pypi.org/project/ty · https://pyrefly.org/blog/v1.0
• 测试框架对比：https://qaskills.sh/blog/alternatives-to-pytest-python-testing-frameworks · https://blog.jetbrains.com/pycharm/2024/03/pytest-vs-unittest
• 钩子框架：https://github.com/j178/prek · https://github.com/pre-commit/pre-commit/issues/2322 · https://forum.cursor.com/t/git-hooks-silently-skipped-for-all-source-control-operations-since-3-15-6-git-extension-forces-core-hookspath-dev-null/167719 · https://developercommunity.visualstudio.com/t/git-integration-does-not-show-local-hooks-output/153462 · https://github.com/astral-sh/ruff-pre-commit