直接运行composer install会失败，因Composer强制要求PHP CLI模式下openssl扩展已启用且运行时生效；需通过php --ini确认CLI配置路径、php -m | grep openssl验证加载、php -i | grep "OpenSSL Support"检查状态，Windows须确保php_openssl.dll及libssl/libcrypto DLL存在且extension_dir正确，Linux/Docker需安装对应php-openssl包，临时禁用TLS仅限调试且有安全风险。
直接运行 composer install 会失败，因为 Composer 强制要求 openssl 扩展可用 —— 不是“能凑合用”，而是根本不会启动下载流程。你得先让 PHP CLI 真正加载上这个扩展，或者临时绕过（仅限调试）。
确认 CLI 模式下 openssl 是否真正启用
很多人改了 php.ini 却没生效，是因为编辑的是 Apache/Nginx 用的配置，而 composer 走的是 PHP CLI。必须验证命令行环境：
- 执行
php --ini，看输出的 “Loaded Configuration File” 路径，这才是你要改的php.ini - 执行
php -m | grep openssl，有输出才表示已加载；没输出说明没启，或启了但加载失败（比如 DLL 缺失） - 执行
php -i | grep "OpenSSL Support"，返回enabled才算成功；disabled或无结果都代表失败
Windows 下 openssl 加载失败的典型硬伤
不是注释没去掉，而是依赖文件根本没到位。尤其在 PHP 官方 ZIP 包、Wamp、XAMPP 环境里：
-
php.ini中写的是extension=openssl（PHP 7.4+），不是extension=php_openssl.dll（旧版） -
extension_dir必须指向正确的目录，比如ext，且该目录下要有php_openssl.dll - PHP 根目录下必须存在
libssl-1_1-x64.dll和libcrypto-1_1-x64.dll（版本号可能不同），缺一个就静默失败 - 改完配置后，必须关闭并重新打开 CMD/PowerShell，否则
php -v还读旧内存缓存
Linux/macOS/Docker 环境常见漏点
你以为装了系统级 openssl 就够了？错。PHP 需要自己编译时链接或运行时能找到对应扩展：
- Debian/Ubuntu：装
php-openssl包，不是openssl；执行sudo apt install php-openssl - CentOS/RHEL：用和 PHP 同源仓库的
php-opcache套件，确保php --modules输出含openssl - Docker Alpine：musl libc 不兼容标准 OpenSSL 扩展，换
debian:slim或显式安装php7-openssl（Alpine 包名） - phpbrew/asdf 切换版本后：新版本很可能没编译
--with-openssl，重装时加参数或查构建日志
临时禁用 TLS 的风险与操作边界
只在本地调试、离线环境或 CI 测试阶段考虑，生产环境绝对禁止：
- 命令行临时关：
composer install --no-verify-peer（新版 Composer 可能拒绝） - 全局关 TLS：
composer config -g -- disable-tls true（注意空格，不是--disable-tls） - 这会让所有 HTTPS 请求降级为 HTTP，包可能被中间人篡改；私有源如 Artifactory/Satis 会直接拒绝连接
- PHP 8.2+ 已废弃
CURLOPT_SSL_VERIFYPEER，部分 Composer 版本会直接报错退出
最常被忽略的一点：即使 phpinfo() 页面显示 OpenSSL enabled，CLI 模式下仍可能未加载 —— 因为 Web 和 CLI 使用两套 php.ini，且 Windows 下 DLL 依赖缺失时不会报错，只会静默跳过扩展。验证必须用 php -m，而不是浏览器页面。
