🔗 包依赖关系
本文档列出的 import 关系全部来自源码 grep 实测（非推测），反映 pkg/ 与 cmd/ 各包之间真实的内部依赖。
依赖关系图
pkg/domain 标黄突出 —— 它是中立枢纽，被多个 SDK 包依赖，自身却不依赖任何项目内包。
实测 import 清单
🖥️ 应用层 → SDK / 基础层
| 包 | 内部依赖 |
|---|---|
cmd/composer-skills | pkg/client、pkg/composer、pkg/domain |
🔌 SDK 层 → 基础层
| 包 | 内部依赖 |
|---|---|
pkg/composer | pkg/detector、pkg/installer |
pkg/client | pkg/domain |
pkg/repository | pkg/domain |
🧱 基础层 → 基础层
| 包 | 内部依赖 |
|---|---|
pkg/installer | pkg/composerutils、pkg/composerutils/mock、pkg/detector |
pkg/detector | 无（仅标准库） |
pkg/composerutils | 无（仅标准库） |
pkg/domain | 无（仅标准库） |
关键观察 🔍
pkg/domain是中立枢纽 🎯 —pkg/client与pkg/repository都依赖它定义返回类型，但pkg/domain自身不依赖任何项目内包。pkg/composer不依赖pkg/domain⚠️ — CLI 封装返回的结构化类型（AuditInfo、OutdatedInfo等）定义在pkg/composer内部，与pkg/domain的 API 模型是两套独立类型。pkg/installer是基础层中依赖最多的包 📦 — 它需要检测（detector）、下载与文件操作（composerutils）、以及测试用的 mock。- 应用层只依赖三个包 ✅ —
cmd/composer-skills透过pkg/composer与pkg/client即可获得全部能力，不直接触碰基础层。
验证方法
本表的依赖关系可用以下命令复现：
bash
grep -rh 'github.com/scagogogo/composer-skills/pkg/' pkg/ cmd/ --include='*.go' | grep -v _test.go | sort -u无循环依赖
依赖严格自上而下（应用层 → SDK 层 → 基础层），基础层永不反向 import 上层，整个项目无循环导入 —— Go 编译器会拒绝任何真实循环。