签名验证应放在中间件，因其能统一拦截所有请求、避免控制器遗漏校验；算法须用hash_hmac('sha256', $data_string, $secret)，$data_string需字典序排序拼接且剔除sign字段；原始请求体须通过Request::raw()或php://input获取。
签名逻辑该放在哪里：Controller 还是中间件？
签名验证必须在业务逻辑执行前完成，否则参数可能已被篡改后参与运算。ThinkPHP 6+ 推荐用中间件（Middleware），不是因为“更高级”，而是它天然拦截所有请求、不依赖控制器是否继承基类或是否漏写校验。
常见错误现象：app\controller\User::update() 里手动调 checkSign()，结果 app\controller\Pay::notify() 忘了加，攻击者直接伪造回调参数绕过校验。
- 中间件能统一处理
GET、POST、JSON请求体，避免各处重复解析 - 若用 Controller，必须确保所有入口方法都调用同一套校验逻辑，且不能跳过
__construct()或前置钩子 - ThinkPHP 5.1 的
filter参数过滤机制不校验签名，仅做类型转换，别混淆
签名算法怎么选：md5 + secret 还是 hmac_sha256？
用 md5($params . $secret) 是典型错误——它无法防重放、易被长度扩展攻击，且 secret 若拼在末尾，攻击者可构造 param1=a¶m2=b%00...&sign=xxx 绕过（部分框架对 %00 截断）。
正确做法是用 hash_hmac('sha256', $data_string, $secret)，其中 $data_string 是按 key 字典序排序后拼接的 key=value 对（不含 sign 字段），并统一用 & 连接。
立即学习“PHP免费学习笔记（深入）”；
- 必须剔除
sign字段再参与签名，否则形成循环依赖 - 时间戳字段（如
timestamp）建议强制要求，且服务端只接受 ±5 分钟内的请求，防重放 - 不要把
nonce存数据库做去重——高并发下性能差；可用 RedisSETNX+ 过期时间，键为nonce:{value}
如何兼容 JSON 和表单提交：input() 拿不到原始数据？
ThinkPHP 的 input() 默认返回已解析的数组，但签名必须基于原始请求体（尤其是 JSON）。直接对 input('post.') 签名会失败——它已转义、已合并 GET/POST、丢失原始顺序和空格。
正确路径是读原始输入流：file_get_contents('php://input')，再根据 Content-Type 分支处理。注意：该流只能读一次，后续 input() 仍可用，但中间件里别反复读。
- 当
Content-Type: application/json，直接用file_get_contents('php://input')得到原始 JSON 字符串 - 当
Content-Type: application/x-www-form-urlencoded或未设置，用$_POST+$_GET合并后按规则排序拼接，但需还原原始编码（如空格是+还是%20） - ThinkPHP 6 的
Request::raw()可替代file_get_contents，更安全，但同样不可重复调用
调试签名失败时，最容易忽略的三个点
90% 的签名失败不是算法错，而是环境或细节偏差。比如本地测试通过，上线就失败，大概率卡在这三处。
-
$_GET和$_POST中的键名大小写敏感：前端传UserId，PHP 接收却是userid（尤其 Nginx + FastCGI 配置不当） - URL 中的
+被自动转成空格，而签名时没 decode：应统一用urldecode()处理所有 value 再拼接 - Windows 开发环境换行符是
\r\n，Linux 是\n，若签名字符串含多行文本（如 base64 图片），会导致哈希值不同
复杂点在于：签名本身不难，难的是所有环节——前端拼参、传输编码、服务端解析、排序规则、secret 存储方式、时钟同步——必须严丝合缝。少一个环节对不上，整个链路就断掉。
