答案是本地包未真正建立符号链接且autoload映射未指向源码路径，导致修改无效；需确认本地包composer.json含"options":{"symlink":true}、终端有管理员权限、主项目dump-autoload后检查autoload_ps4.php中映射是否正确。
本地包改了代码却没生效，90% 是 symlink 没真正建立，而不是 Composer 配置错了。
为什么 require 本地包后 composer show --all 看不到它
Composer path 仓库不会自动“注册”包名，它只在 require 字段中出现对应 name 时才尝试加载。常见错误包括：
-
name字段大小写或分隔符不一致：本地包composer.json里写的是"acme/utils"，但主项目require写成"Acme/utils"或"acme_utils"，直接忽略 -
url指向的不是含composer.json的目录：比如写成"../my-pkg/src"（错），正确应是"../my-pkg"（该目录下有合法composer.json） - 路径末尾加了
/："url": "../my-pkg/"会导致整个仓库被静默跳过，Windows 下尤其敏感 - 本地包
composer.json语法错误：比如尾逗号、单引号、中文引号，composer validate能立刻暴露问题
怎么确认 symlink 是否真的生效
符号链接没建成功，Composer 就会 fallback 到 copy 模式——你改本地源码，vendor/ 里还是旧副本，调试完全失效。
- Linux/macOS：运行
ls -la vendor/acme/utils，看到箭头指向外部路径（如../my-pkg）才算成功 - Windows：运行
dir vendorcmeutils，看到JUNCTION或SymLink字样才是 symlink；若显示普通文件夹，说明 fallback 成 copy - 关键不在主项目配置
"symlink": true，而在于**本地包自己的composer.json必须含"options": {"symlink": true}** - Windows 用户必须以管理员身份运行终端；Docker 容器需加
--cap-add=SYS_ADMIN并挂载支持 symlink 的卷
autoload 更新后类仍找不到
path 仓库让包“存在”，但类能否 new 或 use，取决于 autoload 映射是否包含真实路径。Composer 不会自动继承本地包的 autoload 配置到主项目。
立即学习“PHP免费学习笔记（深入）”；
- 主项目运行
composer dump-autoload -o后，检查vendor/composer/autoload_psr4.php里是否有本地包的命名空间映射 - 如果没映射，说明主项目
composer.json的autoload段没覆盖它；要么手动加一条 PSR-4 映射，要么确保本地包的autoload在主项目中被识别（需其name与require完全一致） - 本地包若用 PSR-4，其
"psr-4": {"Acme\": "src/"}中的命名空间前缀必须和实际 PHP 文件里的namespace Acme;逐字匹配（含反斜杠数量）
最隐蔽的问题永远藏在 symlink 是否真实存在、autoload 映射是否指向本地源码路径这两处——其他配置都对，这两点一错，所有调试就变成在旧代码上打转。
