推荐使用Composer的path资源类型调试依赖包：将目标包复制到项目外目录，在composer.json中添加path配置指向该目录，运行composer update后Composer会创建符号链接，实现代码实时生效，调试完成移除配置即可恢复远程版本。
在开发中，有时需要调试或修改 Composer 依赖包的代码，但直接改 vendor 目录下的文件不仅不规范，而且一旦执行 composer install 或 update，修改就会被覆盖。以下方法可以在不修改 vendor 目录的前提下临时调试依赖包。
1. 使用 Composer 的 path 资源类型（推荐）
这是最实用且安全的方式：将你本地的包源码通过软链接挂载到项目中，Composer 会自动使用本地目录代替远程包。
操作步骤：- 将要调试的包从 vendor 中复制出来，放到项目外（例如放在
../local-packages/your-vendor/your-package） - 在项目的
composer.json中添加 repositories 配置：
"repositories": [
{
"type": "path",
"url": "../local-packages/your-vendor/your-package"
}
]
- 然后运行
composer update your-vendor/your-package - Composer 会自动创建符号链接（symlink），指向你本地的目录
- 此时你在本地目录中修改代码，项目中就能实时生效
调试完成后，移除 repositories 配置并重新安装即可恢复使用远程版本。
2. 手动替换为 Git 开发分支
如果你有权限修改该包，可以 fork 包并指向自己的分支进行调试。
- 在 GitHub/GitLab 上 fork 目标仓库
- 在
composer.json中指定 git 地址和分支：
"repositories": [
{
"type": "git",
"url": "https://github.com/yourname/package-name"
}
],
"require": {
"your-vendor/your-package": "dev-your-debug-branch"
}
- 这样你可以自由提交调试代码，适合长期调试或准备提 PR 的场景
3. 利用 Xdebug + IDE 断点调试
即使不修改代码，也可以通过断点查看执行流程。
- 在 IDE（如 PhpStorm、VS Code）中配置 Xdebug
- 直接在
vendor目录中的包文件里下断点 - 虽然不能保存修改，但可观察变量、调用栈、执行路径
- 结合日志输出，足以完成大部分调试任务
4. 临时复制类并重命名测试（快速验证）
对于只想验证某段逻辑是否可行的情况：
- 把 vendor 中的关键类复制到
app/Extensions或类似目录 - 修改命名空间和类名避免冲突
- 在项目中临时调用这个“副本”验证逻辑
- 确认无误后再决定是否向原包提 issue 或 PR
基本上就这些方法。path 映射方式最适合日常调试，既不影响协作，又能高效定位问题。
