用途：面向 Python 单仓库的跨包层架构，即一个仓库内由 uv workspace 管理多个可安装包（成员），通常是一个共享库加一个或多个应用/CLI 成员。它处理包与包之间的决策：库与应用边界在哪、依赖允许指向哪个方向、工具无法强制时如何保持边界、各成员对外暴露什么、共享测试放哪、如何从现有包中抽出共享库而不破坏它。不涉及包内模块布局（all、分层结构）或一般 uv 用法（uv add/uv run、锁文件）。
主要能力：判断是否该拆分；配置 uv workspace；诊断或预防循环导入与依赖纠缠；从应用/CLI 中抽取共享逻辑；定义成员在包边界的公共 API 及消费方导入方式。
使用方式：在根 pyproject.toml 用 [tool.uv.workspace] 声明 members 与可选 exclude；成员通过普通依赖加 [tool.uv.sources] 中 <name> = { workspace = true } 指向工作区。整个工作区共享一个 uv.lock 与一个虚拟环境，uv lock 作用于整个工作区，uv run / uv sync 默认根目录并用 --package <member> 指定成员；工作区依赖为可编辑。依赖图必须是 DAG 且向内指向共享库：应用/CLI 依赖共享库，应用之间不互相依赖，共享库不依赖任何应用。消费方只通过成员的公共 API（init/all）导入，不碰 _internal 模块。测试由各成员自己的 tests/ 与 conftest.py 负责，真正共享的 fixture 通过测试支持包加 pytest_plugins 共享。抽取共享代码时先保证现有测试全绿，再移动模块、重指导入，最后测试仍须全绿。
适用场景：两个应用需要同一领域逻辑、一个应用是薄壳、需要可独立测试的核心时拆分；只有一个可部署物且无复用、成员需要冲突依赖版本或不同 requires-python 时不应使用工作区（改用路径依赖或分仓库）。
限制：uv 无法阻止成员导入兄弟成员声明的依赖，边界靠约定与代码审查，可选 import-linter 在 CI 中强制；整个工作区只能有一个 requires-python（取各成员交集）；不要过早拆分或过度拆分；忘记 [tool.uv.sources] 会导致 uv 从 PyPI 解析而失败。具体命令与配置示例以资料为准，此处不展开。