正确链路是path仓库+symlink+dev版本别名；prefer-stable需配合minimum-stability: dev实现“稳中求活”。
本地包改了代码，vendor 里没变，不是 Composer 坏了，是没走对路——path 仓库 + symlink + dev 版本别名才是实时调试的正确链路；而 prefer-stable 不是用来“锁稳定”的开关，它是和 minimum-stability: dev 配合用的“稳中求活”策略。
怎么让 Composer 找到并链接本地包
Composer 默认只认 Packagist 和配置的远程仓库，本地目录不在搜索范围内。必须靠 repositories 显式声明一个 path 类型源，并确保它写在主项目 composer.json 的根级（和 require 同级），否则静默失效。
-
url必须是相对路径，以./或../开头，不能带file://、尾部斜杠（如"../pkg/"）、或绝对路径 - 目标路径下必须存在合法的
composer.json，且其中name字段要和require中写的**逐字节一致**（大小写、分隔符、vendor 名全敏感） - 必须启用符号链接：在
repositories条目里加"options": {"symlink": true}；Windows 用户需管理员权限运行终端，否则链接创建失败且无提示 - 首次引入必须用
composer update vendor/name，composer install不重建链接
require 时该写什么版本号才生效
path 类型仓库不走语义化版本解析，只认分支别名。写 ^1.0 或 1.2.3 会直接报 Could not find package。
- 本地包
composer.json里version是"dev-main"，require就得写"vendor/name": "dev-main" - 如果本地没 Git，建议显式设
"version": "dev-main"，否则 Composer 可能推断不出分支名 - 必须配合
"minimum-stability": "dev"（顶层配置），否则dev-main被过滤掉；再加"prefer-stable": true，可兼顾核心依赖的稳定性 - 改完
composer.json后，删掉vendor/和composer.lock，再跑composer install—— 缓存可能跳过新仓库
改了本地包代码，为什么 vendor 没更新
因为 path 仓库启用 symlink 后，vendor/vendor/name 是个软链接，指向你本地目录；但 Composer 不监控文件变更，也不会自动刷新。
- 改完本地包代码后，只需运行
composer update vendor/name（推荐），它会重映射链接，保持指向最新内容 -
composer dump-autoload只刷新自动加载映射，不更新链接本身 - 千万别删
vendor/后composer install—— 这会让 Composer 把本地包完整复制进去，失去“改即生效”的意义 - 验证是否成功：进
vendor/vendor/name目录，ls -l看是不是软链接（Unix）或检查属性（Windows）
prefer-stable 到底该在哪设、怎么用
prefer-stable 是排序策略，不是准入开关。它只在满足所有依赖约束的前提下，优先选 stable 版本；dev 版本依然可用，只是排在后面。
- 长期项目推荐在
composer.json根级写"prefer-stable": true，配合"minimum-stability": "dev"，做到“全局允许开发版，关键包默认稳” - 临时加固（比如 CI 流水线）可用命令行参数：
composer update --prefer-stable，它会覆盖配置项 - 不要用
@stable锁单个包——它太死板，想测 beta 时还得手动删，不如--stability=beta针对性更强 - 如果
composer show --all里看不到你期望的 stable 版本，说明约束冲突或minimum-stability设得太严，prefer-stable此时根本没机会起作用
最易被忽略的是 repositories 的位置和 symlink 的显式开启——错一个，整个链路就断在无声无息处；prefer-stable 的价值也只在 minimum-stability 放宽之后才真正浮现。
