Composer怎么禁止包的覆盖？保护基础库的安全策略【指南】-composer-PHP中文网

直接修改 vendor 文件会被覆盖，正确做法是 fork 原包并通过 repositories 指向私有仓库，禁用 packagist 需设置顶层 "packagist": false，并配合 audit 与签名验证保障安全。

composer怎么禁止包的覆盖？保护基础库的安全策略【指南】

直接改 vendor 文件一定会被覆盖，别试了

Composer 的 vendor/ 目录是只读缓存区，不是你的工作区。任何手动修改（比如 patch 一个类、加日志、改配置）在下次 composer install 或 composer update 时都会被还原——这不是 bug，是设计使然。

常见错误现象包括：CI 构建后调试日志消失、团队成员提交了 vendor 文件导致行为不一致、甚至因权限问题报 file_put_contents(/path/to/vendor/autoload.php): Permission denied。

不要把 vendor/ 加进 Git，确保 .gitignore 里有 /vendor/
不要在 vendor/autoload.php 里写自定义逻辑，它每次都会重生成
想临时验证修改？用 "type": "path" 映射本地副本，而不是碰 vendor

用 fork + 自定义仓库替代手动改包

长期方案必须脱离 vendor 修改。最干净的做法是 Fork 原包，提交你的改动，再通过 repositories 指向它。

关键点在于：repositories 必须显式声明，且不能和镜像源混写；私有包要独立条目，排在镜像源前面，否则仍可能被同名外部包 fallback 覆盖。

composer.json 中添加：

"repositories": [
  {
    "type": "vcs",
    "url": "https://github.com/your-org/package-name"
  }
],
"require": {
  "vendor/package": "dev-main"
}

确保该 Fork 仓库包含你所有必要改动，并打上可复用的分支或 tag

不要用 "type": "package" + dist 指向 git clone，除非你明确控制 tarball 构建流程

禁用 packagist.org 需顶层开关，不是删 repositories

很多人以为清空 repositories 数组就能关掉默认源，其实不行。真正生效的是 "packagist": false 这个布尔开关，它必须放在 composer.json 根层级，不能嵌套、不能带参数。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

设成 true 或写成 "packagist.org": false 都无效；一旦启用，所有包都必须由你显式声明的仓库提供，否则 require 就会失败。

错误写法："repositories": []、"packagist.org": false、{"repositories": [{"packagist": false}]}
正确写法："packagist": false（与 require、autoload 同级）
配套动作：在 repositories 里单独声明私有源（type: "composer" 或 type: "package"），并确认其 URL 不是镜像地址