最可控的私有组件复用方式是path仓库+语义化版本+独立composer.json；需确保路径为相对主项目根目录的绝对路径、包名完全一致、用composer update 包名精准更新、组件独立测试与PSR-4自动加载、提交自身composer.lock、严格遵循SemVer打tag并引用如^2.1。
直接说结论：用 path 类型仓库 + 语义化版本 + 独立 composer.json 是最可控、最易调试的私有组件复用方式，别一开始就搞 Satis 或私有 Packagist。
本地路径仓库怎么配才不翻车
很多人在主项目 composer.json 里加完 repositories 就跑 composer install，结果报错 Could not find package vendor/my-component。根本原因是路径没对齐或包名不匹配。
-
url必须是相对主项目根目录的**绝对路径**（从composer.json所在位置算起），比如本地包在../my-component，就写"url": "../my-component"，不能写./../my-component或my-component - 本地包自身的
composer.json中name字段必须和主项目require的键完全一致，包括大小写和 vendor 名，比如"name": "acme/utils"，主项目就得写"acme/utils": "*" - 执行
composer update acme/utils比composer update更安全——它只刷新这个包的符号链接，不会意外升级其他依赖
为什么不能把私有组件直接塞进主项目的 src/
看起来省事，但会快速演变成“代码沼泽”：类之间耦合变硬、无法独立测试、改一个功能要跑全量 CI、别人想复用你这段逻辑时得手动复制粘贴。
- 私有组件应有自己完整的
tests/目录和phpunit.xml，能单独运行vendor/bin/phpunit - 自动加载必须走 PSR-4，且命名空间前缀不能和主项目重叠（比如主项目用
App\，组件就该用Acme\Utils\） - 组件内禁止直接
require_once主项目的文件；所有交互必须通过接口或明确传参，否则一拆就崩
composer.lock 在私有组件里要不要提交
要，而且必须提交。这不是可选项，是协作底线。
- 私有组件本身是个“库”，不是“应用”，它的
composer.lock只用于**验证自身开发环境一致性**（比如确保 CI 跑测试时用的phpunit版本和你本地一样） - 主项目安装这个组件时，**完全忽略**组件里的
composer.lock—— Composer 只认主项目的 lock 文件 - 组件的
composer.json中require应尽量宽泛（如"php": "^8.1"），require-dev则可锁定具体版本（如"phpunit/phpunit": "^10.5"）
版本号不按 SemVer 来，迟早出事
用 "dev-main" 或 "1.0" 这种模糊版本看似方便，实则让主项目失去控制权：下次 composer update 可能拉到一个未测试的破坏性变更。
- 私有组件发版必须打 Git tag，比如
v2.1.0，然后在composer.json里写"version": "2.1.0"（或靠git describe自动推导） - 主项目引用时，别用
"*"，改用"^2.1"—— 这样既允许安全的小版本更新，又不会跨主版本踩坑 - 如果组件还没稳定，用
dev-前缀加分支名，比如"dev-feature/auth"，但上线前必须切到正式 tag
最常被忽略的一点：私有组件的 autoload 配置一旦提交，就不能随便改路径或命名空间，否则所有依赖它的项目都会 Class not found。改之前，先想清楚下游有没有人已经在用了。
