type: "path"是唯一支持本地文件系统调试的类型，需配置"url"以./或../开头、本地包含name匹配的composer.json，启用"config": {"symlink": true}并验证符号链接状态。
type: "path" 是唯一支持本地文件系统调试的类型
Composer 不会把任意目录当包用，type: "path" 才是专为本地开发设计的仓库类型。它不走 Git 克隆、不查远程元数据，只在 require 明确命中时，直接链接或复制本地目录内容到 vendor。其他类型（比如 type: "vcs"）哪怕 URL 写成 ../my-pkg，也会被当成 Git 地址去尝试克隆——失败就静默跳过。
-
url必须以./或../开头，例如"url": "../my-package"✅；"url": "my-package"或"url": "/abs/path"❌ - 本地包根目录下必须有合法的
composer.json，且其中name字段要和主项目require里写的**逐字一致**，大小写、斜杠都不能错 - 不需要初始化 Git 仓库，也不需要 commit ——
type: "path"完全绕过 Git
如何让 symlink 生效并验证是否真在用本地代码
默认情况下 Composer 对 type: "path" 是 copy 行为，改代码后得重新 composer install。要实时联动，必须显式启用符号链接：
- 在主项目的
composer.json根级加配置："config": { "symlink": true } - 运行
composer install或composer require vendor/name后，检查vendor/vendor/name是否为符号链接（Linux/macOS）或 junction（Windows） - 加
-vvv参数运行命令，日志中应出现类似Installing vendor/name (dev-main): Symlinking from ../my-package - 修改本地包里的 PHP 文件，直接在主项目中调用，看变更是否立即生效 —— 这比看日志更可靠
常见静默失败原因：路径对不上、autoload 没刷、权限拦路
最常遇到的情况是：composer install 没报错，但 vendor 里没东西，或者类加载失败。根本原因往往不是配置错，而是路径或 autoload 落空：
- 本地包的
composer.json中autoload配置（如psr-4）路径是相对于它自身根目录的，若写成"App\": "src/"，就要确保../my-package/src/真有文件 - 改完本地包代码后，必须在主项目中运行
composer dump-autoload，否则新类或命名空间不会进自动加载映射 - Windows 下若提示 “Operation not permitted” 类错误，大概率是启用了 Windows Defender 实时防护，临时关闭或添加排除目录即可
- 如果主项目用了
autoload-dev加载测试类，而本地包的测试类也放在那里，composer install --no-dev会导致这些类彻底不可见
别混淆 path 和 vcs：调试选 path，交付选 vcs
很多人试图用 type: "vcs" + 本地路径来“快速调试”，结果白忙活。两者定位完全不同：
-
type: "path"：无协议、无版本解析、无元数据合并，纯路径映射。适合改一行代码立刻验证逻辑，但不能打 tag、不能 push 到私有 Git 服务 -
type: "vcs"：必须是合法 Git 地址（支持git@、https://、../relative），Composer 会 clone、checkout、匹配 tag/branch。适合长期维护、CI 构建、多环境部署 - 混用风险：若同时配置了同名包的
path和vcs，Composer 只认path（因为 require 匹配优先），但一旦删掉path配置，又会自动 fallback 到vcs—— 这个切换是隐式的，容易在上线前漏检
实际调试时最容易忽略的是 autoload 更新时机：本地包改了类，主项目不 dump-autoload，连 class_exists() 都返回 false，但错误信息里完全不提 autoload，只报 Class not found。
