stream_context_create中verify_peer_name必须显式设为false：verify_peer=>false仅关闭证书链校验，verify_peer_name=>false才跳过域名匹配，二者缺一不可且须同在'ssl'子数组中。
stream_context_create 中 verify_peer_name 必须显式设为 false
PHP 7.4+ 默认开启 verify_peer_name，即使你已设 verify_peer => false，只要没写明 verify_peer_name => false，仍会校验域名并报错 “unable to connect to ssl host”。这不是 bug，是 PHP 的安全加固行为。
-
verify_peer => false只关证书链信任校验 -
verify_peer_name => false才真正跳过主机名匹配（等效于 cURL 的CURLOPT_SSL_VERIFYHOST = 0） - 二者缺一不可，且必须同时出现在
'ssl'子数组里，不能放在'https'或顶层
正确写法：
$context = stream_context_create([
'ssl' => [
'verify_peer' => false,
'verify_peer_name' => false,
]
]);
$result = file_get_contents('https://self-signed.local/api', false, $context);
cURL 请求中 CURLOPT_SSL_VERIFYHOST 必须传整数 0
在 PHP 7.0.16+，CURLOPT_SSL_VERIFYHOST 接受的值不再是布尔型 —— 设 false 或 true 会被静默转为 1，而 1 已被废弃且不生效，实际退化为严格模式（等同于 2），导致自签名或域名不匹配时仍失败。
- 必须用整数
0：curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0) -
CURLOPT_SSL_VERIFYPEER可用布尔false，但推荐也写成0保持语义一致 - 若只关
VERIFYPEER没关VERIFYHOST，错误可能表现为 “SSL: no alternative certificate subject name matches target host name”
file_get_contents 和 curl_exec 报错不互通，别混用调试逻辑
同一个 HTTPS 地址，file_get_contents() 失败不代表 curl_exec() 也会失败，反之亦然。因为二者底层 SSL 上下文来源不同：
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
立即学习“PHP免费学习笔记（深入）”；
-
file_get_contents()完全依赖stream_context_create()配置，不受php.ini中curl.cainfo影响 -
curl_exec()优先读php.ini的curl.cainfo，其次 fallback 到系统 CA 路径；手动设CURLOPT_CAINFO会覆盖前者 - 调试时若两者表现不一致，先确认你改的是哪条路径：是上下文、cURL option，还是全局 ini 配置？
例如：file_get_contents() 报 “peer certificate CN=`localhost` did not match expected CN=`api.example.com`”，说明 verify_peer_name 没关；而 curl_exec() 报 “unable to get local issuer certificate”，大概率是 curl.cainfo 没配或路径错。
生产环境禁用证书校验等于裸奔，临时方案必须加注释和条件开关
所有跳过验证的代码都该带运行环境判断，不能裸写 false 或 0。PHP 没有编译期宏，靠运行时判断最稳妥：
- 用
getenv('APP_ENV') === 'local'或defined('WP_DEBUG') && WP_DEBUG类似方式包裹 - 在
curl_setopt或stream_context_create前加明确注释，如// ⚠️ DEV ONLY: skip SSL verify for self-signed test API - CI/CD 流水线中可加检查：grep -r "CURLOPT_SSL_VERIFYPEER.*false" --include="*.php" . || true，配合告警
真正棘手的不是怎么跳过，而是跳过后请求成功了，却忘了上线前删掉 —— 这类疏漏在交接或紧急修复时高频发生。
