唯一可靠方式是修改 composer.json 的 repositories 为 path 类型源：在根级添加数组，路径相对当前文件、含合法 name/version，本地包需有 Git 仓库；Composer 默认软链而非复制，改本地包后需主项目执行 dump-autoload；CI 应禁用 path 源，上线前必须删除。
怎么让 composer require 装本地代码而不是 Packagist
直接改 composer.json 的 repositories，加一个 path 类型源。这是唯一可靠方式，composer install 或 require 才会认本地路径。
常见错误是只改了 autoload 或手动 symlink，结果包管理器完全不感知——版本冲突、更新失败、CI 构建报错全由此来。
-
repositories必须是数组，且放在根级（和require同级），顺序无关但建议放最前 - 路径必须是相对当前
composer.json的，比如"../my-package"，不能用~/或绝对路径 - 本地包自己的
composer.json必须有合法name（格式如vendor/name）和version（可写"dev-main"） - 如果本地包没提交 Git，Composer 会拒绝加载——加个空
.git目录或运行git init && git add . && git commit -m "init"
为什么 path 源装出来是符号链接而不是复制文件
这是 Composer 的默认行为，不是 bug。它把本地包软链进 vendor/，方便你边改边测，改完直接生效。
但这也意味着：你在本地包里删文件、改命名空间、删 autoload 配置，下游项目立刻报错——因为没重新 dump-autoload，也没触发重链接。
- 改完本地包的
composer.json（比如加了个新psr-4映射），必须在主项目运行composer dump-autoload - 如果想强制重新链接（比如怀疑软链损坏），删掉
vendor/vendor/name再composer update vendor/name - CI 环境通常禁用
path源，所以要配config.platform或用COMPOSER_DISALLOW_PLUGINS=1避免意外加载
path 源和 vcs 源混用时的版本解析陷阱
Composer 默认优先匹配 path 源，哪怕你 require 的是 "^1.2"，只要本地路径存在，就无视 Packagist 上的真实版本号。
这会导致：本地包 composer.json 里写的是 "version": "dev-feat-x"，但主项目 require 写的是 "^1.2" ——Composer 不报错，但实际装的是 dev-feat-x，且不会做版本兼容性检查。
- 确保本地包的
version字段和主项目require的约束能对上，比如都用"dev-main" - 调试时用
composer show vendor/name看实际加载来源，输出里有source: path /xxx才算生效 - 上线前务必删掉
repositories里的path条目，否则部署会因找不到路径失败
Windows 下路径分隔符和权限问题
Windows 用户遇到 Could not scan for classes inside "src/" 或 failed to open dir，八成是路径斜杠或权限导致的。
Composer 在 Windows 上对 path 源的处理比 Linux 更敏感：反斜杠会被转义，长路径可能被截断，UAC 还可能阻止软链创建。
- 一律用正斜杠：
"../my-package"，别写"..\my-package" - 避免路径含中文、空格、括号；如果必须，整个路径用双引号包裹并在
composer.json中转义为"../my package" - 以管理员身份运行终端执行
composer update，否则mklink可能失败
vendor 里多出一堆失效链接，或者 CI 日志里反复刷着 Package not found。 
