直接编辑vendor代码不安全且不可复现，因其是Composer只读输出区，手动修改会在下次install/update时被覆盖，且不入Git历史；正确做法是配置path仓库使用本地副本，满足repositories位置、url路径、name一致、Git初始化四条件，并完成autoload声明、require指定分支、dump-autoload三步闭环。
直接改 vendor 里的代码不安全，也留不下痕迹；用 path 仓库配本地副本才是可复现、可提交、可协作的调试方式。
为什么不能直接编辑 vendor 中的包
vendor 目录是 Composer 的“只读输出区”，任何手动修改都会在下次 composer install 或 composer update 时被覆盖。更危险的是：这些改动不会出现在 Git 历史里，别人拉代码后完全无法复现你的调试路径，线上出问题也查不到根源。
- 你加的日志、断点、临时
var_dump()全部丢失 - IDE 可能因 vendor 内容变动频繁而索引错乱，跳转失效
- 若误提交了 vendor 下的修改，会污染整个团队的依赖状态
配置 path 仓库前必须满足的 4 个硬性条件
缺一不可，否则 composer require 会静默失败，连报错都没有。
-
repositories字段必须写在主项目composer.json的最外层，和require同级——写进config、extra或嵌套对象里都无效 -
url必须是相对路径（如"../my-forked-package"），不能带file://、~、尾部斜杠或 Windows 绝对路径 - 本地目录下必须存在合法的
composer.json，且其中name字段（如"monolog/monolog"）要和主项目require中写的**逐字一致**（大小写、分隔符全敏感） - 本地包目录必须已初始化 Git 仓库（
git init && git add . && git commit -m "init"），否则 Composer 默认拒绝加载（这是安全限制）
让本地副本真正生效的三步闭环
光配好 repositories 不等于类能自动加载，必须走完这三步才算调试环境就绪。
- 在本地包的
composer.json中声明autoload（如"psr-4": {"Monolog\": "src/"}），路径必须相对于该包根目录，不是主项目根目录 - 在主项目中执行
composer require monolog/monolog:dev-main（注意用dev-分支名，不是*或^2.0） - 执行
composer dump-autoload -o，确保新 autoload 映射写入vendor/composer/autoload_psr4.php
验证是否成功：运行 ls -la vendor/monolog/monolog，看到 -> /absolute/path/to/my-forked-package 才算符号链接生效；再跑 php -r "var_dump(class_exists('MonologLogger'));" 返回 true 才算真正可加载。
调试时最容易忽略的权限与缓存陷阱
即使所有配置都对，也会卡在这几个隐形环节上。
- 某些 IDE（如 PHPStorm）会缓存 vendor 下的符号链接状态，改完配置后需手动触发 “Reload project from composer.json” 或清掉
.idea/misc.xml中的旧索引 - 如果本地包的
composer.json里没写"options": {"symlink": true}，Composer 在部分系统上可能 fallback 到复制模式（尤其 Windows + WSL 混合环境） -
composer.lock里该包的source.type必须是path，source.url必须是绝对路径——相对路径在这里会被自动转义，但一旦写错格式，composer install --dry-run就会显示Installing...而非Skipping...
真正安全的调试，不是“让它跑起来”，而是“让每一次改动都能被追踪、被共享、被回滚”。本地副本的价值，恰恰在于它把原本散落在 vendor 里的临时修补，变成了可 commit、可 review、可 CI 验证的正式开发流。
