技术博客
Composer 本身**不会对每个下载的 .zip/.tar 包执行 GPG 解签名**——它不内置 GPG 引擎，也不要求包作者上传 .sig 文件。所谓“签名验证”，实际是三层防御：HTTPS 连接加密 + 服务器证书可信（TLS 验证）+ composer.lock 中记录的 dist.shasum 哈希比对。这三者缺一不可，但都不是传统意义的“数字签名”。
Go 语言没有内置的枚举类型，但 iota 提供了一种简洁、可读性强且类型安全的方式来模拟枚举行为。它不是关键字，而是预声明的标识符，专用于常量声明块中，自动递增生成序列值。
Composer 本身不支持在 auth.json 里直接写“多域名共享同一套账号”的通配规则，每个域名必须单独声明。你不能写 "*.example.com": { … }，它会忽略或报错。
本文详解 php 与 javascript 混合开发中变量传递的关键要点，重点纠正引号嵌套错误、解释服务端与客户端执行时序，并提供安全、可维护的实践方案。
长事务会持有锁时间过长，阻塞其他事务，同时 undo log 持续增长，影响 purge 线程效率。常见于把整个批量导入、报表生成或跨服务操作包在一个事务里。
CI 环境没用户交互、没缓存、网络策略严，composer install 默认行为很容易崩。比如它会试图读取 auth.json、触发脚本、检测平台扩展，而这些在容器里全不可用。
PHP里的public不是“共享文件夹”，而是“谁都能伸手拿、也能随手改”的开放接口。它不校验调用方身份，也不拦截非法赋值——只要在作用域内，$obj->prop就能读写，连类型都不拦。
核心是改 composer.json 的 repositories 配置，把默认的 packagist.org 关掉，再加你的私有源。不关默认源的话，Composer 会先去公网找——哪怕你写了私有地址，它也可能绕过你直接连外网。
默认情况下，composer 的网络请求超时是 300 秒（5 分钟），但实际遇到慢源（比如国内直连 packagist.org）、代理不稳定或大包下载时，经常在 Downloading… 阶段卡死，最终抛出类似 Connection timed out 或 cURL error 28: Operation timed out 的错误。
这不是 Composer 自身的问题，而是 Xdebug 的递归限制被 Composer 的依赖解析器（特别是 composer/composer 内部的 AST 解析和插件加载逻辑）意外触发。Xdebug 默认的 xdebug.max_nesting_level=256 在处理大型项目（比如含 dozens 个插件、嵌套 require-dev、或使用 path repository 的 monorepo）时很容易耗尽。