composer 不支持分级加密分发本地依赖，因其仅负责包发现而非访问控制与解密；应使用私有 packagist 类服务实现基于角色的版本可见性策略，并通过独立配置文件和命名区分权限边界。
Composer 本身不支持“分级加密分发”本地依赖——这不是它设计的职责，硬要实现只会把问题复杂化、引入不可控风险。
为什么不能用 Composer 做本地依赖的分级加密分发
Composer 的 repositories 配置（比如 path 或 package 类型）只解决“从哪找包”，不提供访问控制、权限校验或密钥解密能力。所谓“分级加密”，实际要解决的是：dev-team-a 能装 internal/logging-sdk v1.2，dev-team-b 只能装 v1.0，且 v1.2 的代码对 b 团队不可见——这超出了 Composer 的协议边界。
常见错误尝试包括：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在
composer.json中写"repositories": [{"type": "package", "package": {...}}]并手动替换 dist URL —— URL 一旦泄露，加密即失效 - 用私有 Git 仓库 + SSH 密钥控制访问，再配
git@...地址 —— 这只是“按团队分 repo”，不是“同一包不同版本分级”，且密钥管理分散，CI 环境难同步 - 把加密后的内容塞进
dist.reference字段，指望 Composer 自动解密 ——composer install完全忽略该字段，也不会执行任何解密逻辑
真正可行的替代路径：用私有 Packagist + 权限策略
分级分发必须由包注册中心（而非 Composer 客户端）承担鉴权和过滤责任。推荐组合：
- 部署
Private Packagist或开源替代Satis/ClanCats/PackageRepository，它们支持基于团队/角色的包可见性策略 - 每个团队有自己的 Composer 配置文件（如
composer.team-a.json），通过COMPOSER=composer.team-a.json composer install切换上下文 - 在私有源中为同一包发布多个版本（如
internal/logging-sdk:1.0.0-team-b,1.2.0-team-a），用命名区分权限边界，而非加密 - CI 流水线中强制校验
composer config --global repos.packagist.org.allow false，禁用公共源，避免误拉
本地开发时如何安全引用内部包
开发阶段需兼顾便利性与隔离性，关键点在于：不把敏感包路径硬编码进主 composer.json，也不让 path 类型仓库进入生产 lock 文件。
- 用
composer require internal/logging-sdk:dev-main --repository-url=file:///path/to/team-a-pkg临时安装，完成后立即删掉该repository配置 - 团队统一约定：所有本地
path仓库仅出现在composer-dev.json，并通过COMPOSER=composer-dev.json composer install启动开发环境 - 禁止在
composer.lock中出现"type": "path"记录 —— 它会导致composer install在 CI 中失败（路径不存在），也违背 lock 文件“可重现”本质 - 若必须调试本地修改，用
composer link（需全局启用）替代path，它不写入 lock，且可随时composer unlink撤销
真正麻烦的从来不是怎么“加密”，而是谁有权看到什么版本、变更如何审计、上线前如何确认没混入未授权包——这些必须靠中心化源+权限模型兜底，而不是在 composer.json 里加几行配置糊弄过去。
