composer install仅检查php扩展（如ext-curl、ext-openssl）是否启用，不验证系统底层库（如openssl、libc）版本；报错“ssl routines:ssl_choose_client_version:unsupported protocol”实为php扩展运行时由底层openssl抛出，需通过重装php、调整openssl.cafile等解决。
composer install 本身不读取系统底层库
它根本不会去查 libc、openssl 或 libcurl 的版本，也不关心你系统里装的是 OpenSSL 1.1 还是 3.0。Composer 是纯 PHP 实现的依赖管理器，所有网络、文件、压缩操作都走 PHP 扩展（比如 ext-curl、ext-zip、ext-openssl），而不是直接调用系统 C 库。
真正和系统底层库发生关系的，是 PHP 解释器启动时加载的那些扩展——而 composer install 只会检查这些扩展是否存在、是否启用，不会验证其背后的系统库 ABI 兼容性或补丁级别。
它只检查 PHP 扩展可用性，不是系统库版本
执行 composer install 前，Composer 会做几项关键检查：
- 是否启用了
ext-curl（用于 HTTP 请求）或ext-openssl（用于 HTTPS 证书校验） - 是否启用了
ext-zip（解压下载的 PHAR 包） - 是否启用了
ext-json（解析composer.json和composer.lock） - PHP 版本是否满足
composer.json中声明的require.php约束
这些检查全靠 extension_loaded() 和 PHP_VERSION_ID，不涉及 ldd、pkg-config 或 openssl version -a 这类系统命令。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么有时会报“SSL routines:ssl_choose_client_version:unsupported protocol”？
这不是 Composer 报的错，而是 PHP 的 ext-curl 或 ext-openssl 在发起 HTTPS 请求时，由底层 OpenSSL 库抛出的运行时错误。常见原因包括：
- 系统 OpenSSL 太旧（如 CentOS 7 默认的 1.0.2），不支持 TLS 1.2+，而 Packagist 强制要求 TLS 1.2
- PHP 编译时链接的 OpenSSL 版本与系统 runtime 库不匹配（例如 PHP 静态链接了 OpenSSL 1.1，但系统升级到了 3.0）
-
curl.cainfo指向的 CA 证书路径不存在或过期
这类问题必须通过调整 PHP 编译参数、重装 PHP、或设置 openssl.cafile 来解决，composer install 自身无法绕过或修复。
想确认底层库实际被谁使用，得用 strace 跟踪 PHP 进程
因为 composer install 是 PHP 脚本，要看到它到底调用了哪些系统库函数，必须让 strace 进入 PHP 子进程：
- 不能只跑
strace composer install—— 这只会看到 shell fork 出 php，然后就停了 - 必须用
strace -f -e trace=openat,connect,sendto,recvfrom php /usr/bin/composer install -
-f是关键：Composer 会 fork 出 git、curl、unzip 等子进程，不加就看不到它们的系统调用 - 输出里出现的
connect(…, AF_INET, …)或openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", …)才是真实发生的底层行为
注意：which composer 输出的路径可能不是 PHAR 文件本身（比如是 shell wrapper），最好用 php $(readlink -f $(which composer)) install 确保调到真正的入口。
