layui全局加签必须用$.ajaxprefilter，因其可在每次请求前动态读取url、data等上下文生成签名；layui.config仅支持静态headers，无法满足时间戳、随机串、body哈希等实时计算需求。
layui 全局加签必须用 $.ajaxPrefilter，layui.config 不支持动态签名
因为加签依赖实时参数（如时间戳、随机串、body 内容哈希），而 layui.config({ ajax: { headers: {} } }) 只接受静态对象，无法在每次请求时重新计算签名。哪怕你写成 'X-Sign': sign()，函数也只在 config 执行时调用一次，后续所有请求都复用这个过期签名。
真正可行的方案是 $.ajaxPrefilter —— 它在每次 jQuery 请求发出前触发，能读取 options.url、options.data、options.type 等完整上下文，适合构造动态签名。
- 必须在
layui.use(['jquery'], callback)回调内执行，确保使用的是 Layui 封装的$ - 建议加域名白名单判断，避免对 CDN、统计接口等非业务请求误加签
- 签名逻辑里要区分
GET和POST/PUT：前者拼 query，后者需先序列化data或提取原始options.contentType判断是否已为 JSON 字符串 - 若后端要求签名包含请求体（body）哈希，且前端用
contentType: 'application/json'，则需在options.data是对象时手动JSON.stringify后再哈希；若为字符串则直接参与计算
加签字段该放 headers 还是 data？看后端约定
绝大多数中电联、金融或政企类协议要求签名放在请求头（如 X-Sign、X-Timestamp、X-Nonce），而非请求体。这是因为：
- 请求体可能被网关或代理修改（如 gzip、重写），导致验签失败
- 签名头可被反向代理统一审计，不侵入业务逻辑
- GET 请求无 body，只能靠 headers 携带签名元数据
所以优先往 options.headers 上挂：options.headers['X-Sign'] = signStr、options.headers['X-Timestamp'] = Date.now().toString()、options.headers['X-Nonce'] = Math.random().toString(36).substr(2, 8)。
如果后端强制要求签名塞进 data（比如老系统改造未动接口层），则需根据 options.type 分支处理：GET 改用 options.url += '&sign=' + signStr；POST 若 contentType 是 application/x-www-form-urlencoded，就把 sign 合并进 options.data 对象；若是 application/json，就得先 JSON.parse(options.data)（注意判空和类型）、合并后再 JSON.stringify 回去。
table.render 和 form.on('submit') 的加签会失效？检查是否漏了 contentType 和 beforeSend
Layui 的 table 和 AJAX 模式的 form 默认发请求时，contentType 是 application/x-www-form-urlencoded，但很多加签逻辑默认按 JSON 处理 data，结果算出来的签名和后端不一致。
- 对
table.render，必须显式配置contentType: 'application/json'，并在beforeSend里手动序列化data，否则$.ajaxPrefilter拿到的options.data是对象，后端收到的却是 form 表单字符串 - 对
form.on('submit')，若没设contentType，jQuery 会自动把对象转成 query string 并设 header，此时加签用的data必须是同样格式（可用$.param(options.data)），不能直接 JSON.stringify - 如果后端要求签名覆盖整个 HTTP 报文（含 headers），那仅靠
$.ajaxPrefilter不够——它无法拿到最终发出的 header 字符串，此时必须降级到beforeSend钩子，在请求真正发出前补全签名
签名密钥怎么安全存？别硬编码，也别全放 localStorage
加签密钥（如 appSecret）绝不能写死在 JS 里，也不该全量存在 localStorage —— XSS 一打就穿。实际可选路径只有两条：
- 登录成功后，后端返回一个短期有效的加签 Token（如
sign_token），有效期 30 分钟，每次加签前先校验本地是否存在且未过期；过期则静默刷新（用 refresh_token 换新），失败则跳登录 - 敏感操作（如支付、启停充电）前，单独拉一次「加签票据」接口，返回一次性
nonce + signature，前端只负责透传，不参与密钥运算
第二条更安全，但增加 RTT；第一条更常用，需配合内存缓存（如 sessionStorage 存 timestamp，避免反复读 localStorage）。无论哪种，签名函数本身都不该直接接触原始密钥，而是通过封装好的 getSignParams() 获取运行时参数。
真正容易被忽略的是签名时间窗口校验：前端生成的 X-Timestamp 和后端当前时间差超过 5 分钟，后端应直接拒收。这意味着你得定期校准前端时间（比如登录时从服务端同步一个 serverTimeOffset），否则设备时钟偏差会导致批量验签失败。
