必须在主项目composer.json的repositories中配置{"type":"path","url":"../my-bundle"}并设"options":{"symlink":true}，再执行composer update vendor/my-bundle；require字段不支持路径，只认vendor/name格式，且仅从已声明的repositories中查找包。
用 composer.json 的 repositories 配 {"type":"path","url":"../my-bundle"}，再 composer require vendor/my-bundle:dev-main —— 这是唯一能边改边试的路径；直接 require 本地路径或写死绝对路径，100% 失败。
为什么 composer require ../my-bundle 会报 “Could not find package”
Composer 不支持在 require 字段里填路径。它只认 vendor/name 格式，并去所有 repositories 里查有没有匹配的 name 和版本。你没在 repositories 里声明源，它根本不会打开你的本地目录看一眼。
-
repositories必须写在主项目（即 Symfony 项目的根目录）的composer.json里，不能写在 Bundle 自己的composer.json中 -
url必须是相对路径，比如"../my-bundle"；Windows 上用绝对路径（如"C:/dev/my-bundle"）会静默失败 - 本地 Bundle 目录下必须有合法的
composer.json，且其中name（如"acme/demo-bundle"）要和require里写的完全一致（大小写敏感） - 版本必须用分支名，如
dev-main或dev-develop；1.0.0这类语义化版本在path源下被忽略
改了 Bundle 代码，主项目里没生效？默认是复制，不是链接
Path 仓库默认行为是把整个本地目录「复制」进 vendor/，所以你改 ../my-bundle/src/，vendor/acme/demo-bundle/src/ 还是旧文件。必须显式启用符号链接。
- 在主项目
composer.json的repositories条目里加："options": {"symlink": true} - 或者，在 Bundle 自己的
composer.json里加同样字段（效果等价） - 执行
composer update acme/demo-bundle（不是install或dump-autoload）才会重建 symlink - 验证：Linux/macOS 下运行
ls -la vendor/acme/demo-bundle，应看到箭头指向源目录；Windows 下用dir vendor\acme\demo-bundle看是否为“快捷方式”类型 - Windows 用户需开启“开发者模式”或以管理员权限运行终端，否则
symlink创建失败且无提示
path 仓库 vs package 仓库：为什么 Bundle 开发必须选前者
package 类型需要手动写全包元数据（name、version、autoload、require 等），它不读本地 composer.json，也就无法继承自动加载规则、脚本、平台配置等——Bundle 的 bin/console 命令、config/bundles.php 启用逻辑、src/ 下的 PSR-4 自动加载都会失效。
-
path类型直接读取本地composer.json，完整支持 autoload、scripts、extra、minimum-stability 等所有字段 -
path类型跳过网络请求，离线可用，速度极快，适合高频调试 -
path类型对 Git 分支敏感：切换main→feature/x后，composer update会自动拉取新分支 HEAD，无需改composer.json - 团队协作时，避免硬编码
../my-bundle；可结合环境变量（如${BUNDLE_PATH}）或 CI 脚本动态注入
最易被忽略的一点：Bundle 的 composer.json 里如果写了 "type": "symfony-bundle"，它本身不触发任何特殊行为，但会影响 Packagist 显示和某些静态分析工具；真正起作用的是 config/bundles.php 中的注册逻辑和 src/ 下的 Bundle 类——这些都得靠 path 仓库原样加载，而不是被 package 手动截断。
