PHP无法直接抓取加密数据，需逆向分析前端JS加解密逻辑；对JS混淆页面应优先用无头浏览器或提取JS中密钥复现；反爬校验需模拟UA、Cookie及Sec-Fetch头；AES解密关键在正确获取密钥与IV。
PHP 本身不能直接“抓取加密数据”——网页加密（比如 JS 加密、Token 校验、动态密钥）是前端或服务端主动做的防护，PHP 的 cURL 或 file_get_contents 只能拿到它被允许返回的原始响应。所谓“解密”，其实是逆向还原对方的加解密逻辑。
遇到 document.write 或 eval(unescape(...)) 型混淆页面怎么办
这类页面不是真加密，是把 HTML 内容用 JS 编码后延迟写入，curl 直接请求只拿到空壳或混淆字符串。
- 先用浏览器开发者工具看 Network → Response，确认是否真有加密内容，还是只是 JS 渲染后才出现
- 如果 Response 里有
eval、document.write、atob、unescape等调用，说明内容被编码过，但解码逻辑就在源码里 - 不要试图在 PHP 里重写整个 JS 解码器；优先用 headless 浏览器（如 Puppeteer + PHP 调用 Node.js）或直接提取 JS 中的密钥/算法再用 PHP 复现
- 常见坑：
escape在现代 JS 已废弃，对应的是encodeURI或encodeURIComponent，PHP 用urldecode不一定对得上
file_get_contents 返回空或 403，但浏览器能打开
服务器通过 User-Agent、Referer、Cookie、甚至 JS 计算出的 __ts 或 _token 字段做校验，不是加密，是反爬。
- 用
curl_setopt($ch, CURLOPT_USERAGENT, ...)模拟真实 UA（比如 Chrome 最新版） - 必须带上完整 Cookie，尤其是
PHPSESSID、csrftoken这类会话标识；用浏览器复制Request Headers → Cookie字段最稳妥 - 如果响应头含
Set-Cookie，记得用curl_setopt($ch, CURLOPT_COOKIEJAR, ...)和CURLOPT_COOKIEFILE维持会话 - 容易忽略：某些站点校验
Sec-Fetch-*头（如Sec-Fetch-Mode: navigate），cURL 默认不发，需手动加curl_setopt($ch, CURLOPT_HTTPHEADER, [...])
看到 AES / RSA / Base64 混合加密的 JSON 接口怎么处理
这类接口通常返回一段密文（如 {"data":"U2FsdGVkX1..."}），真正的难点不在 PHP 解密函数，而在密钥来源和初始化向量（IV）获取方式。
立即学习“PHP免费学习笔记（深入）”；
- Base64 解码后才是 AES 输入，别直接对字符串 aes_decrypt —— 先
base64_decode($data) - AES 密钥往往来自前端 JS：搜索页面源码里的
localStorage.getItem('key')、const KEY = '...'或从登录响应中提取 token 后拼接 - IV 常见位置：响应头
X-Iv、JSON 字段iv、或固定值（如全 0 的 16 字节）；PHP 的openssl_decrypt必须传对$iv参数，否则返回 false - 典型错误：
openssl_decrypt返回空字符串 ≠ 解密失败，可能是 padding 错误或编码问题；加OPENSSL_ZERO_PADDING并手动处理 PKCS#7 补位更可控
真正卡住人的从来不是 openssl_decrypt 调用不对，而是密钥怎么来、IV 怎么变、时间戳或随机数是否参与计算——这些逻辑都藏在前端 JS 里，不读透就写不出稳定解密代码。
