开发工具构建工具【免费下载链接】hatchModern, extensible Python project management项目地址https://gitcode.com/gh_mirrors/ha/hatch点击查看免费下载本篇技术指南聚焦 Hatch 的锁文件lockfile能力Hatch 可以基于 PEP 751 为每个环境生成pylock.toml锁定文件记录所有依赖的精确解析版本与哈希值从而在不同机器和 CI 流水线上实现可复现的安装。读完本文你将掌握锁定环境的配置方式locked/lock-envs、三大锁定命令hatch env lock、hatch dep lock、hatch lock的完整用法、从锁文件同步环境hatch dep sync、自动锁定、依赖升级、同步校验与自定义导出等全部实战操作并了解内置 pip / uv 两种 locker 的底层实现原理。为什么需要锁文件常规的依赖声明如pyproject.toml中的dependencies只描述版本约束区间例如pytest7。不同的机器在不同的时间点解析可能得到不同的具体版本导致在我机器上能跑的经典问题。锁文件则把每个依赖的精确版本和哈希固化下来保证任何机器、任何时间安装结果一致可复现安装CI 与本地开发环境使用同一组依赖版本依赖被供应链篡改或上游意外发布坏版本时哈希校验能及时发现。Hatch 生成的锁文件遵循 PEP 751由于 PEP 751 规定文件名只允许一个点环境名中的.会被替换为-。配置需要锁定的环境锁文件不是对所有环境默认开启的。你需要先在配置中显式声明哪些环境需要锁定。按环境开启locked true在环境配置中设置locked trueHatch 就会在创建环境或依赖变化时自动维护该环境的锁文件[tool.hatch.envs.test] locked true dependencies [ pytest, ]全局开启lock-envs如果希望所有环境默认都锁定可以在[tool.hatch]顶层设置lock-envs true。它相当于每个环境locked选项的默认值单个环境locked的默认值是false除非被lock-envs覆盖详见 环境配置—Locking 小节。[tool.hatch] lock-envs true全局开启后单独退出lock-envs true并不强制所有环境锁定个别环境仍可通过显式locked false退出[tool.hatch] lock-envs true [tool.hatch.envs.docs] locked false生成锁文件hatch env lock锁定全部或指定环境不带参数执行时hatch env lock会为所有配置了locked true的环境生成锁文件$ hatch env lock Locking environment: default Wrote lockfile: /path/to/project/pylock.toml Locking environment: test Wrote lockfile: /path/to/project/pylock.test.toml也可以按名称锁定单个环境$ hatch env lock test Locking environment: test Wrote lockfile: /path/to/project/pylock.test.toml注意按名称锁定单个环境时该环境必须已配置locked true。若想为未配置为 locked 的环境生成锁文件请使用--export标志。命名规则default环境产出pylock.toml其余环境产出pylock.ENV_NAME.toml遵循 PEP 751 命名约定。矩阵环境matrix和其他命名同样按 Hatch 的环境展开机制处理参见run_lock_workflow中expand_environments与矩阵展开逻辑tests/cli/env/test_lock.py 有矩阵锁定测试。hatch dep lock与hatch lock锁定当前活动环境对于通过-e/HATCH_ENV选中的环境参见 CLI 说明可以使用hatch dep lock—— 与env lock共享相同的解析器选项--upgrade、--upgrade-package、--export、--export-all、--checkhatch lock——hatch dep lock的简写形式。从源码看顶层 hatch lock 与 hatch dep lock 都直接调用同一个run_dep_lock工作流共享dependency_lock_click_options定义的选项集合src/hatch/cli/env/lock.pyclick.option(--upgrade, -U, is_flagTrue, helpUpgrade all packages) click.option(--upgrade-package, -P, multipleTrue, helpUpgrade specific package(s)) click.option(--export, export_path, typeclick.Path(), defaultNone, helpExport lockfile to a custom path) click.option(--export-all, export_all_path, typeclick.Path(), defaultNone, helpExport lockfiles for all environments to a directory) click.option(--check, is_flagTrue, helpCheck if lockfile is up-to-date)--export-all会把所有已配置环境锁定到指定目录行为与hatch env lock --export-all一致。注意在run_dep_lock中--export与--export-all同时给出会直接报错中止src/hatch/cli/env/lock.py。从锁文件同步环境hatch dep sync会对活动环境执行所选 locker 的apply_lock步骤例如使用 UV locker 时执行uv pip sync使环境安装的包与锁文件完全一致。前提有两个环境必须配置了locked锁文件必须已存在——先运行hatch dep lock或hatch env lock生成。如果违反上述前提命令会直接中止。源码中 dep sync 命令 的实现清晰地体现了这一点环境未locked时提示 The active environment is notlocked...锁文件不存在时提示 No lockfile at ...。底层流程为dep sync→environment.sync_dependencies()→apply_lock_with_locker→ 所选 locker 类的apply_lock见 apply_lockfile_to_environment。自动锁定配置了locked true的环境在hatch env create或hatch run时会自动生成锁文件触发条件为锁文件尚不存在环境的依赖发生了变化。这套机制确保你在日常开发中无需手动维护锁文件——一旦依赖声明变动下一次运行就会自动重新解析并更新锁。判断环境是否有可锁定的输入由environment_has_lock_inputssrc/hatch/env/lock.py完成环境依赖、附加依赖、feature/dependency-groups、项目安装项等任一存在即有内容可锁若没有任何可锁输入自动锁定会跳过生成。升级锁定的依赖锁文件固定了版本但依赖可以升级——这由解析器的--upgrade系列选项控制升级所有包到其允许范围内的最新版本$ hatch env lock test --upgrade只升级指定包可重复指定$ hatch env lock test --upgrade-package requests --upgrade-package urllib3对应选项在底层会透传给解析器pip locker 将其映射为pip lock --upgrade / --upgrade-packagesrc/hatch/env/lockers/pip.pyuv locker 则映射为uv pip compile --upgrade / --upgrade-packagesrc/hatch/env/lockers/uv.py。检查锁文件是否最新在hatch env lock、hatch dep lock或hatch lock上使用--check可以验证锁文件与当前依赖输入是否同步重新解析并与现有文件对比。如果该环境没有任何可锁内容--check只检查文件是否存在——这正是lockfile_in_sync中state is None时return output_path.is_file()的逻辑src/hatch/env/lock.py。$ hatch env lock test --check Lockfile is up to date: /path/to/project/pylock.test.toml这个选项在 CI 中尤其有用确保锁文件已被提交入库并且与pyproject.toml/ 环境依赖保持一致防止有人绕过锁文件直接改了依赖声明。底层的对比方式是先在临时目录重新生成一份锁文件再与现有文件逐字节比较pip 与 uv 的in_sync实现均如此见 src/hatch/env/lockers/pip.py 与 src/hatch/env/lockers/uv.pytests/cli/env/test_lock.py 中的test_check_lockfile_stale正是验证锁文件内容过时则检测失败的端到端测试。导出锁文件有两种需要导出而非常规锁定的场景为未配置locked true的环境生成锁文件将锁文件写到自定义位置。使用--export指定输出路径$ hatch env lock default --export locks/default.lock使用--export-all把所有环境的锁文件导出到一个目录$ hatch env lock --export-all locks/注意--export与--export-all互斥不能同时使用。另外按名称锁定环境时必须配置locked true的限制在--export场景下同样放宽源码中run_lock_workflow只有在未使用 export 且未配置 locked时才中止src/hatch/cli/env/lock.py。自定义锁文件名任何环境都可以用lock-filename选项覆盖默认文件名[tool.hatch.envs.test] lock-filename requirements-test.lock该选项支持上下文格式化——resolve_lockfile_path会先应用环境上下文再解析路径因此可以使用{env_name}、{matrix:...}等占位符src/hatch/env/lock.py。例如配置lock-filename locks/{env_name}/pylock.toml会把锁文件分散到按环境命名的子目录tests/cli/env/test_lock.py 中有对应测试。多个环境共享同一锁文件当多个矩阵环境共享同一个lock-filename时Hatch 会合并它们的依赖并只生成一次锁文件。合并逻辑在merge_environment_lock_inputssrc/hatch/env/lock.py单环境时直接使用该环境自身配置多环境时去重合并全部依赖、union 所有 features 与 dependency-groups不同 Python 版本的环境共享同一锁文件是非法的python配置不一致时会直接中止并提示 A single lockfile cannot be valid across different Python versions. Use distinctlock-filenamevalues对应测试见 test_lock_groups_with_different_python_versions_abort使用 UV 且项目存在pyproject.toml且任一环境需要安装项目时采用分层合并layered merge。安装器集成与 locker 选择锁文件的实际生成与应用由locker插件完成。默认情况下Hatch 会根据环境的安装器自动选择一个内置 lockerlocker 名称默认选用场景生成命令说明pip默认非 UV 安装器pip lock要求 pip 25.1仅支持扁平依赖列表不支持 extras/dependency-groups 分层锁定apply_lock尚未实现见下文uv虚拟环境 UV 安装器uv pip compile带哈希uv pip sync应用锁支持分层锁定extras、dependency-groups、pyproject.toml选择逻辑见get_locker_plugin_classsrc/hatch/env/lock.py优先取环境级locker配置其次取全局tool.hatch.locker都未设置时按UV 安装器选uv否则选pip推断。可以通过配置覆盖默认选择。全局默认[tool.hatch] locker uv按环境覆盖优先于全局[tool.hatch.envs.docs] locker pip完整的插件接口定义在 LockerInterface每个 locker 需要实现三个核心抽象方法generate根据 PEP 508 依赖行可选带 extras/groups 分层输入解析并写出锁文件in_sync判断现有锁文件是否与当前依赖输入匹配重新生成后逐字节对比apply_lock按锁文件安装包使环境与锁文件一致。自定义 locker 通过hatch_register_locker钩子注册详见 依赖锁定插件文档 中的注册示例与插件发现机制。pip locker 的限制需要特别注意内置piplocker 目前没有实现apply_lock其实现直接抛出LockerUnsupportedError并提示使用 UVsrc/hatch/env/lockers/pip.py。因此生成锁文件pippip lock与 uv 都可以从锁文件同步安装dep sync/ 锁定环境的安装目前必须使用 uv locker将安装器设为uv或显式locker uv。此外 pip locker 不支持分层锁定——传入 extras 或 dependency-groups 会直接报错 The pip locker does not support layered locks with extras or dependency-groups; use installer uvsrc/hatch/env/lockers/pip.py。相关行为也有测试覆盖test_dep_sync_aborts_without_lockfile与 pip locker 的 unsupported 报错tests/cli/dep/test_dep_lock.py。uv locker 的生成细节UV locker 的generate最终拼装出类似下面的命令src/hatch/env/lockers/uv.pyuv pip compile requirements文件 [pyproject.toml] \ --generate-hashes --no-header --output-file 输出路径 \ [--extra extras]... [--group groups]... \ [--upgrade] [--upgrade-package pkg]... \ [--python-version 版本]值得注意的细节始终生成哈希--generate-hashes并去除头部注释--no-header保证锁文件内容稳定、可校验分层锁定layered时除依赖文件外还会把pyproject.toml作为编译输入并通过--extra/--group纳入项目 extras 与依赖组环境配置了python时会追加--python-version确保解析结果针对目标 Python 版本apply_lock使用uv pip syncsrc/hatch/env/lockers/uv.py并且install_matches_lock通过uv pip sync --dry-run判断环境是否已经与锁文件一致src/hatch/env/lockers/uv.py用于锁定环境下跳过不必要的重复安装。端到端验证与测试覆盖仓库的测试为上述功能提供了完整的端到端验证可以作为深入学习的入口tests/cli/env/test_lock.py覆盖锁文件命名与写入位置、--check过期检测、--export/--export-all、矩阵环境锁定、共享lock-filename的合并生成与 Python 版本冲突中止、环境依赖被实际编译进锁文件test_lockfile_records_some_env_dependencies、Git 修订号被固定test_lockfile_resolves_git_revision_pin等tests/cli/dep/test_dep_lock.py覆盖dep lock/dep sync的报错路径未锁定环境、锁文件缺失、pip locker 不支持 apply_lock。如果你正在为项目引入可复现的依赖管理推荐的落地顺序是先在[tool.hatch.envs]中为关键环境设置locked true或全局lock-envs true运行hatch env lock生成锁文件并提交到版本库在 CI 中通过hatch env lock --check确保锁文件始终与依赖声明同步如果需要从锁文件精确还原环境例如部署或流水线将对应环境配置为 UV 安装器并使用hatch dep sync。赞分享开发工具构建工具【免费下载链接】hatchModern, extensible Python project management项目地址https://gitcode.com/gh_mirrors/ha/hatch点击查看免费下载相关推荐Hatch 依赖锁定Locker插件开发与配置完整指南基于 PEP 751 的 pylock.toml 生成、校验与同步Hatch 依赖锁定Locker插件开发与配置完整指南基于 PEP 751 的 pylock.toml 生成、校验与同步 本指南围绕 Hatch 的 lo开发工具构建工具Argo CD v2.10 升级至 v2.11 完全指南initiatedBy 操作溯源、Redis Egress 网络策略与新健康检查Argo CD v2.10 升级至 v2.11 完全指南initiatedBy 操作溯源、Redis Egress 网络策略与新健康检查 本篇升级指南以 Ar开发工具构建工具Hatch v1.17.0 实战PEP 751 锁文件pylock.toml与统一质量检查命令 hatch checkHatch v1.17.0 实战PEP 751 锁文件pylock.toml与统一质量检查命令 hatch check 本文围绕 Hatch v1.17.开发工具构建工具上一篇终极Hazel Engine排坑指南编译与运行时错误速解方案下一篇OpenCore Legacy Patcher终极解析让旧Mac重获新生的完整技术指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hatch 环境锁定文件（pylock.toml）完全指南：配置、生成、同步与升级
开发工具构建工具【免费下载链接】hatchModern, extensible Python project management项目地址https://gitcode.com/gh_mirrors/ha/hatch点击查看免费下载本篇技术指南聚焦 Hatch 的锁文件lockfile能力Hatch 可以基于 PEP 751 为每个环境生成pylock.toml锁定文件记录所有依赖的精确解析版本与哈希值从而在不同机器和 CI 流水线上实现可复现的安装。读完本文你将掌握锁定环境的配置方式locked/lock-envs、三大锁定命令hatch env lock、hatch dep lock、hatch lock的完整用法、从锁文件同步环境hatch dep sync、自动锁定、依赖升级、同步校验与自定义导出等全部实战操作并了解内置 pip / uv 两种 locker 的底层实现原理。为什么需要锁文件常规的依赖声明如pyproject.toml中的dependencies只描述版本约束区间例如pytest7。不同的机器在不同的时间点解析可能得到不同的具体版本导致在我机器上能跑的经典问题。锁文件则把每个依赖的精确版本和哈希固化下来保证任何机器、任何时间安装结果一致可复现安装CI 与本地开发环境使用同一组依赖版本依赖被供应链篡改或上游意外发布坏版本时哈希校验能及时发现。Hatch 生成的锁文件遵循 PEP 751由于 PEP 751 规定文件名只允许一个点环境名中的.会被替换为-。配置需要锁定的环境锁文件不是对所有环境默认开启的。你需要先在配置中显式声明哪些环境需要锁定。按环境开启locked true在环境配置中设置locked trueHatch 就会在创建环境或依赖变化时自动维护该环境的锁文件[tool.hatch.envs.test] locked true dependencies [ pytest, ]全局开启lock-envs如果希望所有环境默认都锁定可以在[tool.hatch]顶层设置lock-envs true。它相当于每个环境locked选项的默认值单个环境locked的默认值是false除非被lock-envs覆盖详见 环境配置—Locking 小节。[tool.hatch] lock-envs true全局开启后单独退出lock-envs true并不强制所有环境锁定个别环境仍可通过显式locked false退出[tool.hatch] lock-envs true [tool.hatch.envs.docs] locked false生成锁文件hatch env lock锁定全部或指定环境不带参数执行时hatch env lock会为所有配置了locked true的环境生成锁文件$ hatch env lock Locking environment: default Wrote lockfile: /path/to/project/pylock.toml Locking environment: test Wrote lockfile: /path/to/project/pylock.test.toml也可以按名称锁定单个环境$ hatch env lock test Locking environment: test Wrote lockfile: /path/to/project/pylock.test.toml注意按名称锁定单个环境时该环境必须已配置locked true。若想为未配置为 locked 的环境生成锁文件请使用--export标志。命名规则default环境产出pylock.toml其余环境产出pylock.ENV_NAME.toml遵循 PEP 751 命名约定。矩阵环境matrix和其他命名同样按 Hatch 的环境展开机制处理参见run_lock_workflow中expand_environments与矩阵展开逻辑tests/cli/env/test_lock.py 有矩阵锁定测试。hatch dep lock与hatch lock锁定当前活动环境对于通过-e/HATCH_ENV选中的环境参见 CLI 说明可以使用hatch dep lock—— 与env lock共享相同的解析器选项--upgrade、--upgrade-package、--export、--export-all、--checkhatch lock——hatch dep lock的简写形式。从源码看顶层 hatch lock 与 hatch dep lock 都直接调用同一个run_dep_lock工作流共享dependency_lock_click_options定义的选项集合src/hatch/cli/env/lock.pyclick.option(--upgrade, -U, is_flagTrue, helpUpgrade all packages) click.option(--upgrade-package, -P, multipleTrue, helpUpgrade specific package(s)) click.option(--export, export_path, typeclick.Path(), defaultNone, helpExport lockfile to a custom path) click.option(--export-all, export_all_path, typeclick.Path(), defaultNone, helpExport lockfiles for all environments to a directory) click.option(--check, is_flagTrue, helpCheck if lockfile is up-to-date)--export-all会把所有已配置环境锁定到指定目录行为与hatch env lock --export-all一致。注意在run_dep_lock中--export与--export-all同时给出会直接报错中止src/hatch/cli/env/lock.py。从锁文件同步环境hatch dep sync会对活动环境执行所选 locker 的apply_lock步骤例如使用 UV locker 时执行uv pip sync使环境安装的包与锁文件完全一致。前提有两个环境必须配置了locked锁文件必须已存在——先运行hatch dep lock或hatch env lock生成。如果违反上述前提命令会直接中止。源码中 dep sync 命令 的实现清晰地体现了这一点环境未locked时提示 The active environment is notlocked...锁文件不存在时提示 No lockfile at ...。底层流程为dep sync→environment.sync_dependencies()→apply_lock_with_locker→ 所选 locker 类的apply_lock见 apply_lockfile_to_environment。自动锁定配置了locked true的环境在hatch env create或hatch run时会自动生成锁文件触发条件为锁文件尚不存在环境的依赖发生了变化。这套机制确保你在日常开发中无需手动维护锁文件——一旦依赖声明变动下一次运行就会自动重新解析并更新锁。判断环境是否有可锁定的输入由environment_has_lock_inputssrc/hatch/env/lock.py完成环境依赖、附加依赖、feature/dependency-groups、项目安装项等任一存在即有内容可锁若没有任何可锁输入自动锁定会跳过生成。升级锁定的依赖锁文件固定了版本但依赖可以升级——这由解析器的--upgrade系列选项控制升级所有包到其允许范围内的最新版本$ hatch env lock test --upgrade只升级指定包可重复指定$ hatch env lock test --upgrade-package requests --upgrade-package urllib3对应选项在底层会透传给解析器pip locker 将其映射为pip lock --upgrade / --upgrade-packagesrc/hatch/env/lockers/pip.pyuv locker 则映射为uv pip compile --upgrade / --upgrade-packagesrc/hatch/env/lockers/uv.py。检查锁文件是否最新在hatch env lock、hatch dep lock或hatch lock上使用--check可以验证锁文件与当前依赖输入是否同步重新解析并与现有文件对比。如果该环境没有任何可锁内容--check只检查文件是否存在——这正是lockfile_in_sync中state is None时return output_path.is_file()的逻辑src/hatch/env/lock.py。$ hatch env lock test --check Lockfile is up to date: /path/to/project/pylock.test.toml这个选项在 CI 中尤其有用确保锁文件已被提交入库并且与pyproject.toml/ 环境依赖保持一致防止有人绕过锁文件直接改了依赖声明。底层的对比方式是先在临时目录重新生成一份锁文件再与现有文件逐字节比较pip 与 uv 的in_sync实现均如此见 src/hatch/env/lockers/pip.py 与 src/hatch/env/lockers/uv.pytests/cli/env/test_lock.py 中的test_check_lockfile_stale正是验证锁文件内容过时则检测失败的端到端测试。导出锁文件有两种需要导出而非常规锁定的场景为未配置locked true的环境生成锁文件将锁文件写到自定义位置。使用--export指定输出路径$ hatch env lock default --export locks/default.lock使用--export-all把所有环境的锁文件导出到一个目录$ hatch env lock --export-all locks/注意--export与--export-all互斥不能同时使用。另外按名称锁定环境时必须配置locked true的限制在--export场景下同样放宽源码中run_lock_workflow只有在未使用 export 且未配置 locked时才中止src/hatch/cli/env/lock.py。自定义锁文件名任何环境都可以用lock-filename选项覆盖默认文件名[tool.hatch.envs.test] lock-filename requirements-test.lock该选项支持上下文格式化——resolve_lockfile_path会先应用环境上下文再解析路径因此可以使用{env_name}、{matrix:...}等占位符src/hatch/env/lock.py。例如配置lock-filename locks/{env_name}/pylock.toml会把锁文件分散到按环境命名的子目录tests/cli/env/test_lock.py 中有对应测试。多个环境共享同一锁文件当多个矩阵环境共享同一个lock-filename时Hatch 会合并它们的依赖并只生成一次锁文件。合并逻辑在merge_environment_lock_inputssrc/hatch/env/lock.py单环境时直接使用该环境自身配置多环境时去重合并全部依赖、union 所有 features 与 dependency-groups不同 Python 版本的环境共享同一锁文件是非法的python配置不一致时会直接中止并提示 A single lockfile cannot be valid across different Python versions. Use distinctlock-filenamevalues对应测试见 test_lock_groups_with_different_python_versions_abort使用 UV 且项目存在pyproject.toml且任一环境需要安装项目时采用分层合并layered merge。安装器集成与 locker 选择锁文件的实际生成与应用由locker插件完成。默认情况下Hatch 会根据环境的安装器自动选择一个内置 lockerlocker 名称默认选用场景生成命令说明pip默认非 UV 安装器pip lock要求 pip 25.1仅支持扁平依赖列表不支持 extras/dependency-groups 分层锁定apply_lock尚未实现见下文uv虚拟环境 UV 安装器uv pip compile带哈希uv pip sync应用锁支持分层锁定extras、dependency-groups、pyproject.toml选择逻辑见get_locker_plugin_classsrc/hatch/env/lock.py优先取环境级locker配置其次取全局tool.hatch.locker都未设置时按UV 安装器选uv否则选pip推断。可以通过配置覆盖默认选择。全局默认[tool.hatch] locker uv按环境覆盖优先于全局[tool.hatch.envs.docs] locker pip完整的插件接口定义在 LockerInterface每个 locker 需要实现三个核心抽象方法generate根据 PEP 508 依赖行可选带 extras/groups 分层输入解析并写出锁文件in_sync判断现有锁文件是否与当前依赖输入匹配重新生成后逐字节对比apply_lock按锁文件安装包使环境与锁文件一致。自定义 locker 通过hatch_register_locker钩子注册详见 依赖锁定插件文档 中的注册示例与插件发现机制。pip locker 的限制需要特别注意内置piplocker 目前没有实现apply_lock其实现直接抛出LockerUnsupportedError并提示使用 UVsrc/hatch/env/lockers/pip.py。因此生成锁文件pippip lock与 uv 都可以从锁文件同步安装dep sync/ 锁定环境的安装目前必须使用 uv locker将安装器设为uv或显式locker uv。此外 pip locker 不支持分层锁定——传入 extras 或 dependency-groups 会直接报错 The pip locker does not support layered locks with extras or dependency-groups; use installer uvsrc/hatch/env/lockers/pip.py。相关行为也有测试覆盖test_dep_sync_aborts_without_lockfile与 pip locker 的 unsupported 报错tests/cli/dep/test_dep_lock.py。uv locker 的生成细节UV locker 的generate最终拼装出类似下面的命令src/hatch/env/lockers/uv.pyuv pip compile requirements文件 [pyproject.toml] \ --generate-hashes --no-header --output-file 输出路径 \ [--extra extras]... [--group groups]... \ [--upgrade] [--upgrade-package pkg]... \ [--python-version 版本]值得注意的细节始终生成哈希--generate-hashes并去除头部注释--no-header保证锁文件内容稳定、可校验分层锁定layered时除依赖文件外还会把pyproject.toml作为编译输入并通过--extra/--group纳入项目 extras 与依赖组环境配置了python时会追加--python-version确保解析结果针对目标 Python 版本apply_lock使用uv pip syncsrc/hatch/env/lockers/uv.py并且install_matches_lock通过uv pip sync --dry-run判断环境是否已经与锁文件一致src/hatch/env/lockers/uv.py用于锁定环境下跳过不必要的重复安装。端到端验证与测试覆盖仓库的测试为上述功能提供了完整的端到端验证可以作为深入学习的入口tests/cli/env/test_lock.py覆盖锁文件命名与写入位置、--check过期检测、--export/--export-all、矩阵环境锁定、共享lock-filename的合并生成与 Python 版本冲突中止、环境依赖被实际编译进锁文件test_lockfile_records_some_env_dependencies、Git 修订号被固定test_lockfile_resolves_git_revision_pin等tests/cli/dep/test_dep_lock.py覆盖dep lock/dep sync的报错路径未锁定环境、锁文件缺失、pip locker 不支持 apply_lock。如果你正在为项目引入可复现的依赖管理推荐的落地顺序是先在[tool.hatch.envs]中为关键环境设置locked true或全局lock-envs true运行hatch env lock生成锁文件并提交到版本库在 CI 中通过hatch env lock --check确保锁文件始终与依赖声明同步如果需要从锁文件精确还原环境例如部署或流水线将对应环境配置为 UV 安装器并使用hatch dep sync。赞分享开发工具构建工具【免费下载链接】hatchModern, extensible Python project management项目地址https://gitcode.com/gh_mirrors/ha/hatch点击查看免费下载相关推荐Hatch 依赖锁定Locker插件开发与配置完整指南基于 PEP 751 的 pylock.toml 生成、校验与同步Hatch 依赖锁定Locker插件开发与配置完整指南基于 PEP 751 的 pylock.toml 生成、校验与同步 本指南围绕 Hatch 的 lo开发工具构建工具Argo CD v2.10 升级至 v2.11 完全指南initiatedBy 操作溯源、Redis Egress 网络策略与新健康检查Argo CD v2.10 升级至 v2.11 完全指南initiatedBy 操作溯源、Redis Egress 网络策略与新健康检查 本篇升级指南以 Ar开发工具构建工具Hatch v1.17.0 实战PEP 751 锁文件pylock.toml与统一质量检查命令 hatch checkHatch v1.17.0 实战PEP 751 锁文件pylock.toml与统一质量检查命令 hatch check 本文围绕 Hatch v1.17.开发工具构建工具上一篇终极Hazel Engine排坑指南编译与运行时错误速解方案下一篇OpenCore Legacy Patcher终极解析让旧Mac重获新生的完整技术指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考