path仓库配置后会被ci构建拒绝，因为ci环境无本地路径上下文，相对路径（如"../my-pkg"）在构建机上不存在，导致source path not exist错误；必须移除type: "path"条目，改用vcs或私有packagist源。
Path仓库配置后为什么会被CI构建拒绝？
因为CI环境默认没有本地路径上下文，url指向的相对路径（如"../my-pkg"）在构建机上根本不存在。这不是权限问题，是路径语义失效。
常见错误现象：Source path ../my-pkg does not exist，但本地一切正常。
- 上线前必须从
repositories中移除所有type: "path"条目，改用vcs或私有Packagist - CI脚本里禁止出现
composer install前未清理repositories的逻辑 - 若必须保留（如集成测试），请用
composer config --unset repositories显式清除，再通过COMPOSER_AUTH注入私有源
为什么不能把vendor目录暴露在Web根下？
vendor/autoload.php被直接访问时，旧版Composer会输出类映射结构，泄露内部命名空间、文件路径和依赖拓扑；新版虽收敛了输出，但PHP解析失败仍会泄漏绝对路径——这是典型的信息泄露入口。
- Nginx配置必须加
location ^~ /vendor/ { return 403; } - Apache需确保
.htaccess生效且含Deny from all - 严禁将整个项目根目录设为DocumentRoot；正确做法是仅把
public/设为Web根，vendor/、src/、composer.json全部置于其外 - 检查CI部署脚本，禁用
cp -r vendor public/这类操作
Path仓库启用symlink的真实风险点在哪？
启用"options": {"symlink": true}本身不危险，危险在于它让本地代码变更**绕过版本控制与锁文件约束**，直接反映到运行时。这在CI/CD中等于关闭了依赖可重现性底线。
- Windows需管理员权限或开启“开发者模式”，否则静默fallback为copy，你以为改了代码，实际跑的是旧副本
- Docker容器内挂载宿主机目录时，
--cap-add=SYS_ADMIN不是可选而是必需，否则symlink创建失败 - 验证是否真走symlink：执行
ls -la vendor/vendor/name（Linux/macOS）或dir vendor\vendor\name（Windows），看到->或JUNCTION才有效 - 切勿在生产环境或CI中保留symlink配置；
composer.lock中该包的"source": {"type": "path"}必须被替换为"git"或"dist"
Path仓库的name字段拼错会触发什么安全后果？
拼错name（大小写、分隔符、vendor名任一不符）不会报错，而是让Composer静默跳过本地仓库，转头去Packagist.org拉取同名公开包——你认为在调试自己的SDK，实际加载的是别人发布的恶意同名包。
-
name必须与require中字符串逐字一致：例如"acme/utils"≠"Acme/utils"≠"acme_utils" - 本地包
composer.json必须存在且语法合法（无尾逗号、全双引号），否则该仓库被完全忽略 - 路径末尾不可加
/："url": "../my-pkg/"会导致仓库静默失效 - 验证是否命中本地仓库：运行
composer show --all | grep vendor/name，没输出说明没加载成功
