成功与否，直接看vendor/下是否为符号链接：Linux/macOS用ls -la查看含“->”指向本地绝对路径，Windows用dir查看含JUNCTION或SymbolicLink；若为普通文件夹则fallback至copy模式，未生效。
成功与否，直接看 vendor/ 下是不是符号链接——不是文件夹，不是空目录，更不是一堆复制出来的 PHP 文件。
检查 vendor 目录是否为符号链接
这是最快、最不可绕过的验证动作。Composer 的 path 仓库机制本质就是创建软链接（Linux/macOS）或目录联接（Windows），不是拷贝。
- Linux/macOS：运行
ls -la vendor/vendor/name，输出中必须含->及指向你本地绝对路径的字符串，例如../my-package - Windows：运行
dir vendor\vendor\name，看到JUNCTION或SymbolicLink字样才算成功；若显示 - 如果
vendor/vendor/name是普通文件夹（含src/、composer.json等），基本等于没生效——你改本地代码，运行时加载的仍是这份静态副本
确认 composer.lock 中 source.type 为 path
composer.lock 是安装行为的“判决书”，它记录了包真实来源。光看 vendor/ 不够，得确认 Composer 认定它是本地来的。
- 打开
composer.lock，搜索你的包名，在对应区块下找"source": { "type": "path", "url": "/absolute/path/to/your/package" } -
url值必须是绝对路径（Windows 如C:/dev/my-package，Linux/macOS 如/home/user/my-package），相对路径（如../my-package）只在repositories.url中合法，在 lock 文件里出现即为异常 - 若
source.type是git或package，说明配置被忽略或被其他仓库覆盖了（比如 repositories 顺序错、type 写成composer）
运行时验证 class_exists() 是否返回 true
符号链接存在 ≠ 类能被自动加载。autoload 映射可能没刷、命名空间不匹配、或本地包自己的 autoload 配置未被主项目识别。
- 在项目根目录临时加一行：
php -r "var_dump(class_exists('Vendor\Package\SomeClass'));"，返回bool(true)才算真正可用 - 执行前务必先跑
composer dump-autoload -o（加-o强制优化，避免 OPCache 缓存旧映射） - 若返回
false，再查vendor/composer/autoload_psr4.php，搜索你的命名空间前缀，确认映射路径是否指向你本地包的src/（而不是 vendor 里的副本） - 注意：本地包的
autoload规则不会自动继承到主项目，必须靠dump-autoload扫描并写入主项目的 autoload 文件
执行 composer show 查看包元信息
composer show 是唯一能告诉你“Composer 当前如何看待这个包”的命令，比翻 composer.json 或猜更可靠。
- 运行
composer show vendor/package-name，若报Package not found，说明根本没进依赖图；若正常输出，重点看两行： -
versions : * dev-main (alias for dev-main)—— 表示用了分支别名，非远程 tag -
source : path /your/local/path—— 明确标识来源类型和路径，缺一不可 - 如果版本显示为
v1.2.3或带dist字样，说明走的是 zip 包安装路径，path配置完全失效
最容易被跳过的点：本地包自己的 composer.json 必须含 "options": {"symlink": true}，否则 Windows 和 Docker 下默认 fallback 到 copy；而主项目 composer.json 里写这句毫无作用。
