thinkphp接口签名验证的核心是服务端严格复现客户端sign生成逻辑：参数须k排序且过滤空值，禁用自动转义，json请求需读原始流，密钥须隔离存储并分渠道管理，时间戳校验需容错±5分钟。
ThinkPHP 做接口签名验证，核心不是套用某个“签名中间件”，而是理解签名本质：服务端必须能复现客户端生成的 sign，且所有参与计算的参数、密钥、排序规则、哈希方式必须严格一致。只要有一处不一致，验证就失败——这恰恰是绝大多数人卡住的地方。
签名参数必须全局统一排序并过滤空值
ThinkPHP 默认接收参数是无序的（input() 或 $request->param() 返回关联数组，键顺序不保证），而签名要求参数按 key 字典序升序排列后拼接。不显式排序，本地测试可能偶尔通过，上线后因 PHP 版本或 SAPI 差异直接失效。
- 必须用
ksort()对参数数组排序，且仅对非空、非null、非''的值参与签名（例如filter_var($val, FILTER_DEFAULT)不够，需手动if ($val !== '' && $val !== null && $val !== [])） - 注意排除签名本身（
sign）、时间戳（timestamp）、随机串（nonce）等不参与签名计算但随请求传入的字段 - 常见错误：把
$_GET和$_POST分开处理，漏掉 URL 查询参数；或用http_build_query()但未指定PHP_QUERY_RFC3986，导致空格编码成+而非%20，和服务端不一致
think\facade\Request 获取参数时要禁用自动过滤
ThinkPHP 5.1+ 默认对输入参数做 htmlspecialchars 转义（default_filter 配置），如果客户端原始参数含 &、=、+ 等字符，服务端拿到的是转义后字符串，签名必然失败。
- 签名前务必用
$request->param('', '', false)（第三个参数设为false）跳过所有过滤 - 或者在配置中临时关闭：
'default_filter' => ''，但仅限签名验证逻辑内生效，不可全局关闭 - 特别注意：JSON 请求体（
Content-Type: application/json）需用$request->getInput()读原始流再json_decode($raw, true)，不能依赖$request->param()，否则会丢失原始结构
签名密钥不能硬编码或写死在配置里
密钥（app_secret）一旦泄露，攻击者可伪造任意请求。ThinkPHP 没有内置密钥轮换机制，必须自己设计隔离策略。
- 密钥应存在独立配置文件（如
config/api_sign.php），且该文件禁止 Web 直接访问（Nginx/Apache 需屏蔽.php在 config 目录下的执行） - 不同 APP 或渠道分配不同密钥，通过请求头
X-App-Key或参数app_key查表获取对应app_secret，避免单点泄露影响全部业务 - 严禁把密钥写进控制器或模型里——哪怕只是临时测试；更不要用
md5('your_secret')这种弱混淆，MD5 可逆
时间戳校验必须严格且带时区容错
签名中通常含 timestamp 参数用于防重放，但 ThinkPHP 默认使用 time()（UTC 时间戳），若客户端设备时间偏差 > 5 分钟，验证即失败，用户无法使用。
- 服务端校验时，用
abs(time() - (int)$params['timestamp']) ，而非 <code>time() > $params['timestamp'] + 300，避免客户端时间慢于服务端时误判 - 若客户端为移动端，建议服务端返回当前标准时间（如 ISO8601 格式），由客户端自行校准，而不是强求设备时间精准
- 注意：PHP
time()返回的是系统时间戳，确保服务器 NTP 同步（ntpq -p检查），否则全站签名都会漂移
真正难的不是写几行 hash_hmac('sha256', $str, $secret)，而是参数来源是否干净、排序是否确定、密钥是否隔离、时间是否可信——四个环节任一松动，签名就形同虚设。线上出问题，先抓包比对客户端原始请求体和服务端 var_dump($request->param('', '', false)) 的输出，差一个空格都得重算。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
