PHP 5.6+默认校验SSL证书，自签名或过期证书会报错；file_get_contents()发POST需匹配Content-Type与请求体格式；PHP 7.0+废弃部分cURL常量；响应编码需手动检测转换。
curl_init() 发送 POST 时遇到 “SSL certificate problem” 错误
PHP 5.6+ 默认启用 SSL 证书验证，老接口若用自签名证书或过期证书，curl_init() 会直接报错中断。这不是代码写错了，是安全策略升级带来的兼容性断裂。
实操建议：
- 临时调试可用
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false)关闭验证（仅限测试环境） - 生产环境应更新 CA 证书包，通过
curl_setopt($ch, CURLOPT_CAINFO, '/path/to/cacert.pem')指向最新证书文件 - PHP 7.4+ 更推荐用
CURLOPT_SSL_VERIFYHOST => 2（默认值），别设成0或1，后者已废弃且不安全
file_get_contents() + stream_context_create() 模拟 POST 的参数陷阱
用 file_get_contents() 发 POST 看似简洁，但 http_build_query() 和原始 JSON 体不能混用——前者生成 application/x-www-form-urlencoded，后者需手动设 Content-Type: application/json 且传 raw 字符串。
常见错误现象：接口返回 “invalid json” 或 “missing parameter”，其实是请求体格式和 header 不匹配。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
-
表单提交：用
http_build_query(['a'=>1,'b'=>2])，header 中必须含Content-Type: application/x-www-form-urlencoded - JSON 接口：直接传
json_encode(['a'=>1,'b'=>2])，header 中设Content-Type: application/json - 别漏掉
Content-Length，PHP 一般自动计算，但某些代理或 Nginx 配置下会丢，可显式加上
PHP 版本差异导致的 curl_setopt() 参数失效
PHP 7.0 废弃了 CURLOPT_SSLVERSION 的部分常量值，比如 CURL_SSLVERSION_TLSv1_0 在 PHP 7.3+ 才支持；而老项目若硬编码 CURL_SSLVERSION_TLSv1，在 PHP 8.0+ 会静默降级为 TLSv1.2，导致对接某些只认 TLSv1.0 的银行/政务接口失败。
实操建议：
- 检查目标接口文档明确要求的 TLS 版本，再查对应 PHP 版本支持的常量名（如 PHP 7.2 用
CURL_SSLVERSION_TLSv1_1，不是TLSv1_1） - 避免依赖未声明的 magic number，用
defined('CURL_SSLVERSION_TLSv1_2') ?: define('CURL_SSLVERSION_TLSv1_2', 6)做兜底 - 用
curl_version()输出实际生效的 SSL 库（OpenSSL / GnuTLS），不同库对 TLS 版本的支持粒度不同
接口返回乱码或空响应的字符编码盲区
不是所有接口都返回 UTF-8。有些老系统用 GBK、ISO-8859-1，而 PHP cURL 默认不处理响应编码转换，file_get_contents() 返回的字符串直接 echo 可能显示，json_decode() 会失败并返回 null。
实操建议：
- 先读响应头：
curl_getinfo($ch, CURLINFO_CONTENT_TYPE)，看是否有charset=gbk这类提示 - 没明确声明时，用
mb_detect_encoding($response, ['UTF-8','GBK','BIG5'], true)粗略判断（注意第三个参数必须为true） - 转换后再处理：
$utf8 = mb_convert_encoding($response, 'UTF-8', 'GBK')，之后再json_decode()或正则提取
版本兼容不是加个 if (PHP_VERSION_ID >= 70400) 就完事——关键在 SSL 行为、常量定义、编码推断这三处，稍不留意，请求就发出去了，但对方根本没收到有效数据。
