答案是：必须在主项目composer.json的repositories中配置{"type":"path","url":"../my-package"}并添加"options":{"symlink":true}，再执行composer update acme/utils；本地包需有合法composer.json且name与require逐字一致、url为相对路径、版本用dev-main、目录已git init并commit。
能快速调试本地包，前提是配置走对了 path 仓库 + symlink 路径映射这条路；其他方式（比如手动拷贝、require dev branch、改 vendor）都会导致改代码不生效、autoload 断掉、或每次改完要 commit+push+update，根本谈不上“快速”。
为什么 composer require 一直报 “Could not find package”
这不是网络问题，是 Composer 根本没“看见”你的本地目录。它只从主项目 composer.json 的根级 repositories 字段读配置，其他地方写的全无效。
-
repositories必须和require同级，不能塞进config、autoload或任何嵌套字段里 -
url必须指向一个含合法composer.json的目录，且是相对于主项目composer.json的路径（如"../my-package"），不能以/结尾，也不能用file://或~ - 本地包的
composer.json中name字段（如"acme/utils"）必须与主项目require里写的**逐字一致**：大小写、短横线-、斜杠方向全部敏感 - 版本必须显式指定：
"acme/utils": "@dev"或"acme/utils": "dev-main"；写"*"或不写版本，Composer 会跳过本地源，去 Packagist 查
改了本地代码，vendor 里还是旧文件？
大概率 symlink 没真正建起来，Composer 静默 fallback 到了 copy 模式——这是最隐蔽的坑，改完代码完全没反应，还查不出错。
- 关键不是主项目配
"symlink": true，而是**本地包自己的composer.json里必须有"options": {"symlink": true}** - Windows 用户必须以管理员身份运行终端；Docker 容器需加
--cap-add=SYS_ADMIN并确认挂载支持 symlink - 本地包目录必须已
git init且至少有一个commit，否则 Composer 拒绝创建 symlink - 验证是否成功：
ls -la vendor/acme/utils（macOS/Linux）应显示->；Windows 上用dir vendorcmeutils，看到<symlinkd></symlinkd>才算对
Class not found？autoload 没更新，不是 dump-autoload 就能解决的
composer dump-autoload 只刷新映射，它不解决包未安装、路径未识别、命名空间不匹配这三类根本问题。
- 本地包的
autoload段必须正确声明 PSR-4 映射，例如："psr-4": {"Acme\Utils\": "src/"}—— 注意双反斜杠和末尾斜杠 - 如果测试类在
tests/下，autoload-dev映射末尾也必须带反斜杠："Acme\Tests\": "tests/" - 改完
autoload后，必须手动运行composer dump-autoload --dev，否则vendor/composer/autoload_dev.php不更新 - 入口文件第一行必须是
require __DIR__ . '/vendor/autoload.php';，路径错一点（比如写成./vendor/autoload.php）在 CLI 和 Web 下行为就不一致
真正卡住人的从来不是“怎么配”，而是 symlink 创建失败时 Composer 一声不吭，autoload 映射写错时 PHP 报错信息又不指明根源——这些静默失败点，才是本地包调试最耗时间的地方。
