Python 3.15.0 candidate 1 已经到来。对普通应用开发者来说，这是一次提前发现依赖问题的机会；对库作者和构建基础设施维护者来说，摘要中的“Get those wheels rolling!”指向了更具体的任务：尽快验证源码包和二进制 Wheel，避免正式版本发布后用户才遇到安装失败。
为什么 Wheel 兼容性需要提前检查
纯 Python 包通常更容易跨版本运行，但只要项目包含 C/C++、Rust 或 Cython 扩展，新的 Python 版本就可能暴露编译错误、已移除接口、ABI 假设或构建工具不兼容等问题。
候选版本阶段适合检查三层兼容性：
- 源码兼容性：代码能否在 Python 3.15 下导入并通过测试。
- 构建兼容性：
pip、build、后端构建工具和原生编译器能否生成发行包。 - 分发兼容性：生成的 Wheel 标签、平台架构和依赖声明是否正确，用户能否直接安装。
这里需要区分“项目测试通过”和“Wheel 可用”。测试可能一直在源码目录中运行，却没有覆盖隔离构建、打包后的文件清单和全新环境安装。候选版本验证应把这些步骤串起来。
可以这样实践：在隔离环境中完成构建与安装
下面是一套可以直接改造的本地检查流程。请将 python3.15 替换为候选版本解释器的实际命令；如果本机尚未安装该版本，可以在 CI 或容器环境中执行等价步骤。
set -eux
python3.15 -m venv .venv315
. .venv315/bin/activate
python -m pip install --upgrade pip build twine
python -m build
python -m twine check dist/*
# 强制从本次生成的 Wheel 安装，避免误用源码目录。
python -m pip install --force-reinstall dist/*.whl
python -m pip check
python -c "import your_package; print(your_package.__file__)"
运行前需要把 your_package 改成项目真实的导入名。若 dist/ 中同时存在多个平台或 Python 版本的 Wheel，应显式指定当前 Python 3.15 对应的文件，而不是依赖通配符。
还应在项目目录之外执行一次测试，确认导入的是已安装产物，而不是工作区源码：
set -eux
TMP_DIR="$(mktemp -d)"
cd "$TMP_DIR"
/path/to/project/.venv315/bin/python -c \
"import your_package; print(your_package.__file__)"
对于包含原生扩展的项目，可以进一步禁止 pip 回退到源码构建，从而确认 Wheel 确实可安装：
python -m pip install \
--only-binary=:all: \
--no-index \
--find-links=dist \
your-distribution-name
其中 your-distribution-name 是发布到包索引时使用的发行名称，它可能与 Python 的导入名不同。
把 Python 3.15 加入 CI，但先允许试验性失败
来源没有给出特定 CI 平台或镜像名称，因此下面是一个可按项目环境调整的 GitHub Actions 示例。它假设运行器已经能够通过 actions/setup-python 获取相应的 3.15 预发布解释器；实际可用性需要以执行时的平台支持为准。
name: Python 3.15 compatibility
on:
workflow_dispatch:
pull_request:
jobs:
python315:
runs-on: ubuntu-latest
continue-on-error: true
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.15"
allow-prereleases: true
cache: pip
- name: Install build and test tools
run: python -m pip install --upgrade pip build pytest
- name: Build distributions
run: python -m build
- name: Install the wheel
run: python -m pip install dist/*.whl
- name: Run tests outside the source tree
run: |
cd "$(mktemp -d)"
python -m pytest "$GITHUB_WORKSPACE/tests"
continue-on-error: true 适合刚开始收集信号时使用，但不应永久保留。确认工具链和关键依赖已经支持 Python 3.15 后，应移除它，让兼容性回归真正阻止合并。
如果项目通过 cibuildwheel 构建跨平台二进制包，还需要等待或确认其 Python 3.15 标识与镜像支持，再将目标版本加入构建矩阵。不要猜测具体标识；以当前工具版本的文档和实际构建日志为准。
常见失败不只来自业务代码
遇到失败时，可以按构建链路定位，而不是立即修改应用代码：
pip install阶段失败：检查构建后端、锁定版本以及依赖是否发布了兼容包。- 编译原生扩展失败：检查已废弃或移除的 CPython API、编译器参数和生成代码版本。
- Wheel 构建成功但无法导入：检查动态库、平台标签和包文件清单。
- 测试只在源码目录通过：检查遗漏的数据文件、模块或错误的打包配置。
- 安装时退回源码包：使用
--only-binary=:all:暴露 Wheel 覆盖缺口。
候选版本本身仍处在正式发布之前，因此不宜直接替换生产环境解释器。它更适合作为独立 CI 任务、预发布镜像或维护者工作站中的额外解释器。
发布前的维护清单
现在接入 Python 3.15 验证时，建议完成以下事项：
- 在全新虚拟环境中运行完整测试，而不只测试核心模块。
- 同时构建 sdist 和 Wheel，并用
twine check检查元数据。 - 从构建产物重新安装，在源码目录之外验证导入与测试。
- 对原生扩展覆盖 Linux、macOS、Windows 以及项目实际支持的架构。
- 检查依赖的 Python 版本声明，避免过早宣称支持或无意阻止安装。
- 将发现的问题反馈给直接依赖和构建工具维护者，并附上最小复现与完整日志。
Python 3.15.0 candidate 1 的价值不在于催促生产升级，而在于给生态系统留出修复窗口。越早滚动构建 Wheels，正式版本发布时留给最终用户的安装意外就越少。